15:00:28 <pknirsch> #startmeeting Fedora Base Design Working Group (2014-08-29)
15:00:28 <zodbot> Meeting started Fri Aug 29 15:00:28 2014 UTC.  The chair is pknirsch. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:28 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:00:37 <pknirsch> #meetingname  Fedora Base Design Working Group
15:00:37 <zodbot> The meeting name has been set to 'fedora_base_design_working_group'
15:00:49 <pknirsch> Hello and welcome again everyone for our weekly meeting!
15:01:11 <pknirsch> #chair haraldh dgilmore masta msekleta vpavlin
15:01:11 <zodbot> Current chairs: dgilmore haraldh masta msekleta pknirsch vpavlin
15:01:16 <haraldh> <-
15:01:23 <msekleta> hi everyone!
15:01:41 <vpavlin> Hi all!
15:02:59 <pknirsch> alright, so first up, i'd like to give moben some time today to talk about his work on the reproducible builds and build requires reduction
15:03:05 <pknirsch> #topic Status update builrequires/reproducible builds cleanup
15:03:31 <pknirsch> As it's his last day unfortunately here in Stuttgart, he's heading back to University to continue his bachelor thesis
15:03:35 <pknirsch> (poor guy :)))
15:03:56 * masta is here
15:04:46 <msekleta> pknirsch, will moben continue to work remotely then?
15:05:29 <pknirsch> msekleta: unfortunately the internship ends as well, but maybe i've convinced him what a cool gang we are ;)
15:06:28 <moben> Believe me, I'd rather do some more of this instead of writing a thesis ;)
15:06:41 <pknirsch> heheh
15:06:50 <msekleta> moben, ohh I believe you I remember me writing mine, was feeling the same
15:07:02 <moben> But I should probably finish my degree at _some_ point
15:07:18 <moben> Also, hi everyone!
15:08:28 <moben> The last weeks I've been working on some performance optimizations for my buildreq-check tool
15:08:37 * vpavlin is glad he has his thesis done:)
15:09:56 <moben> And I've got it down to O(#buildrequires) builds, as well as streamlining the pre-build setup, thanks to some pretty neat ideas from pknirsch
15:10:05 <pknirsch> :)
15:10:14 <pknirsch> woot! i'm not completely useless ;)
15:11:13 <haraldh> what does it mean?
15:11:19 <haraldh> O(#buildrequires) builds
15:11:32 <haraldh> and what have the neat ideas been? :)
15:12:22 <moben> using some dummy packages with conflicts to make sure that the dep we want to drop isn't pulled in indirectly
15:12:54 <haraldh> hmm.. ok
15:13:09 <moben> and then after installing the builddeps replacing that dummy package with another one that has the corresponding provides to make rpmbuild happy
15:13:33 <moben> which allowed me to drop some specfile rewriting I was doing before
15:13:52 <haraldh> ah, for bootstrapping
15:13:53 <haraldh> ok
15:14:32 <haraldh> so, dirty workarounds instead of fixing the root problem? :)
15:14:55 <haraldh> or valid workarounds for a non-fixable problem?
15:15:02 <moben> the second
15:15:31 <msekleta> moben, second enhancement only does the same thing as BuildReq: rewriting in spec file or there is something more?
15:16:10 <moben> imagine foo buildreqs bar-devel and baz-devel. bar-devel requires baz-devel.
15:16:32 <moben> We are building foo, leaving out one buildreq at a time to check if any are superfluous
15:17:00 <moben> this allows me to detect that we can't leave out baz-devel as it will be pulled in by bar-devel
15:17:21 <haraldh> ah, so it's a build requirement checking tool
15:17:40 <haraldh> " buildreq-check tool"
15:17:42 <haraldh> right :)
15:17:55 <moben> haraldh: :)
15:17:59 <pknirsch> ^^
15:18:04 <haraldh> do you check, if any differences in the "configure" output happens?
15:18:22 <moben> haraldh: I compare resulting rpms
15:18:37 <haraldh> binary, I guess
15:18:40 <haraldh> cool
15:19:11 <moben> haraldh: code at http://github.com/moben/buildreq-check
15:19:25 <moben> writing a README and status of upstream work atm ;)
15:19:40 <haraldh> so, did you check the whole distribution already? :)
15:19:49 <pknirsch> heheh
15:19:52 <haraldh> and fixed all the specs?
15:19:57 <moben> haraldh: almost
15:20:02 <moben> -_-
15:20:03 <haraldh> oh.. wow
15:20:19 <moben> </sarcasm>
15:20:47 <haraldh> would be cool to dedicate a machine which just checks every package
15:20:54 <msekleta> moben, how long does it take to check packageset we have in base?
15:21:00 <haraldh> and automatically generates bugzillas
15:21:06 <moben> well until a few days ago it did way to many builds, but now it is relatively fast
15:21:08 <haraldh> or fixes the git spec file :)
15:21:36 <moben> msekleta: each package takes about count(BuildRequires)*NormalBuildtime
15:22:07 <moben> a bit less as some of the builds fail because the deps are missing ;)
15:23:15 <msekleta> moben, it is good that it is not 2^(count(buildreqs)) * normal_buildtime
15:23:42 <moben> msekleta: agreed
15:24:09 <dgilmore> hey all
15:24:17 <moben> atm there are quite a few false positives though. test-deps where tests are skipped if they are missing
15:24:34 <moben> autotools sometimes
15:25:38 <moben> and potentially 'pick at least one'-type dependencies where both are listed in the spec
15:26:24 <moben> the first two are impossible to avoid, I guess
15:27:07 <moben> the last is a result of the build-time optimizations
15:27:46 <moben> but should be relatively rare and would be catched anyway
15:28:02 <moben> This all requires reproducible builds though
15:28:22 <moben> So I've been doing some of that, mostly upstream
15:29:18 <pknirsch> upstream++
15:29:19 <pknirsch> :)
15:29:53 <moben> and I think I got most of my patches upstreamed by now, though I got one patch to rpmbuild
15:30:34 <moben> many problems were python related, but that might be selection bias due to fedoras heavy use of python
15:31:52 <moben> Last I checked about 90% of the tentative list of base-packages (as compiled by haraldh's script) had reproducible builds
15:32:04 <moben> which is already pretty neat imo
15:32:22 <haraldh> thumbs up
15:32:48 <moben> notable exceptions: kernel, gcc (among others)
15:33:23 <pknirsch> sweet!
15:33:43 <msekleta> isn't the kernel and gcc always the exception :)
15:33:45 <pknirsch> Thanks for the great work moben, this has been a really great start to our cleanup efforts
15:33:47 <pknirsch> hehehehe
15:33:55 <haraldh> yeah, thanks moben
15:34:03 <haraldh> and good luck with your thesis
15:34:08 <pknirsch> and remember, you're always welcome here!
15:34:10 <pknirsch> :)
15:34:14 <pknirsch> <HINT>
15:34:26 <moben> thanks haraldh :)
15:34:32 <moben> pknirsch: ;)
15:35:34 <pknirsch> Alright, thanks for the lengthy report moben, lets hop to the next topic though, otherwise we'll run out of time today :/
15:35:49 <moben> again :/
15:35:54 <moben> pknirsch: sure :)
15:36:01 <pknirsch> ^^
15:36:21 <masta> Thanks moben =)
15:36:26 <pknirsch> #info Buildrequires checking tool: http://github.com/moben/buildreq-check
15:36:46 <pknirsch> #topic Systemd in Docker discussion (fakesystemd/systemd-container)
15:37:10 <pknirsch> I belive that came up over the past week quite a bit and i've seen vpavlin discuss this quite a bit with msekleta and lennart.
15:37:24 <vpavlin> haraldh: Can you poke Lennart to join us?
15:37:31 <haraldh> oh
15:37:32 <pknirsch> And i just wanted to see whether there's a conclusion about this yet or if there are any loose ends
15:37:52 <vpavlin> pknirsch: Yes. There were some problems in communication
15:38:17 <vpavlin> I think the conclusion is that we won't have systemd-container in Fedora
15:38:40 <pknirsch> hm
15:38:50 <msekleta> yes, there doesn't seem to be an interest in such component and systemd upstream doesn't really want to see it either
15:38:57 <vpavlin> systemd itself should be "fixed" to run in Docker container and guys will move hwdb out of systemd to minimize the footprint
15:38:57 <haraldh> vpavlin, poked, but no answer yet
15:39:51 <vpavlin> I am still not sure about fate of fakesystemd. It's a hack but it can be usefull for Docker containers
15:40:29 <vpavlin> If you are not going to run more than one service, you don't need deadcode lying around in images
15:40:55 <vpavlin> If we are going to run multiple services in container then we really really need systemd
15:41:12 <masta> we have to assume both
15:41:16 <pknirsch> and there can be both usecases i suspect
15:41:18 <pknirsch> right?
15:41:18 <pknirsch> yea
15:41:24 <vpavlin> yes
15:41:47 <pknirsch> so would we then provide 2 docker containers? one with real systemd, one with the stripped one?
15:41:52 <msekleta> as for fakesystemd, I think it should stay, because of problems with CVEs and auditing discussed on ML
15:41:57 <pknirsch> (if we get the stripped one that is)
15:42:06 <vpavlin> On the other hand - If we decide to use systemd even in single-service containers than we can drop fakesystemd and we would get logging and other things solved out of the box
15:42:22 <pknirsch> yea, seems Lennart wasn't convinced by the argument about CVEs
15:42:41 <pknirsch> ah, right
15:42:54 <pknirsch> as systemd does provide certain features that obviously fakesystemd doesnt :)
15:43:02 * vpavlin nods
15:43:43 <msekleta> pknirsch, I get his argument but at the end of the day, when running thing in production I don't think it applies
15:44:21 <pknirsch> yea, i'd be worried in RHEL enterprise containers. Especially with the attack surface of containers today you really want to minimize it as much as possible
15:44:34 <pknirsch> and avoid recreation of the whole stack, too
15:44:35 <vpavlin> The problem is not CVE itself but the impact on user/customer and it's processes and needs
15:44:40 * pknirsch nods
15:44:47 <msekleta> btw fakesystemd doesn't really provide anything, it is just empty specfile with a lot of virtual provides
15:44:51 <pknirsch> hehe
15:44:57 <pknirsch> Ghost in a shell!
15:44:58 <msekleta> doesn't provide real API hence fake
15:44:58 <pknirsch> ;)
15:45:15 <vpavlin> msekleta: Oh it provides all directories that systemd does:D
15:46:00 <pknirsch> hehe
15:46:14 <pknirsch> So what if systemd would provide the filesystem subpackage?
15:46:19 <pknirsch> would that be already sufficient?
15:46:24 <msekleta> vpavlin, we could drop those too if we really want
15:46:42 <pknirsch> Or is it really about more of the provides of systemd, too?
15:46:46 <vpavlin> And it provides empty rpm macros so that you don't get errors on package install
15:47:07 <msekleta> vpavlin, those have to stay
15:47:37 <vpavlin> And without Provides:systemd the real systemd would be sucked in anyway - no matter if you have *-filesystem subpackage or not
15:47:44 <pknirsch> ah
15:47:45 <pknirsch> right
15:48:05 <pknirsch> and how do we avoid fakesystemd being pulled into buildroots then instead of the real on?
15:48:32 <vpavlin> I think the problem is this: http://fedoraproject.org/wiki/Packaging:ScriptletSnippets#Systemd
15:48:59 <pknirsch> ah
15:49:23 <vpavlin> pknirsch: it's now one version behind systemd in Fedora. But we haven't tried to build and image in Koji with it yet
15:50:16 <pknirsch> ah, and your docker KS specifices the exact version so that fakesystemd gets pulled in there?
15:50:18 <vpavlin> So I am not sure what happens if you do "yum update" on image - it might figure out there is newer systemd and try to replace fakesystemd with real systemd
15:50:48 <msekleta> pknirsch, fakesystemd will never be part of the @core thus whoever installing that group should always get real thing
15:51:18 <vpavlin> It does not specify fakesystemd at all yet - dgilmore, I'll send you patch for KS and ask you to try to build an image from it on Monday, ok?
15:51:39 <vpavlin> (or you can just add fakesystemd to %packages:) )
15:53:33 * pknirsch nods
15:53:42 <vpavlin> That's why I wanted to have systemd without unneeded dependencies
15:53:48 <dgilmore> vpavlin: sure
15:53:55 <pknirsch> ace
15:54:21 <vpavlin> Then we can just put it in the image and don't worry about CVE on other packages
15:54:25 <pknirsch> It's really important we don't fubar the buildroots with the fakesystemd
15:54:54 <pknirsch> otherwise i think it's be best of the suboptimal solutions if Lennart doesn't want to split up systemd
15:55:15 <vpavlin> But I understand systemd maintainers - it would be pain if they need to maintain 2 versions
15:55:22 <pknirsch> aye
15:55:33 <pknirsch> and splitting it up might be really tricky, too
15:55:46 <pknirsch> and iirc Lennart was at least already fine with moving the hwdb out, right?
15:55:53 <vpavlin> right
15:55:57 <pknirsch> (at least that's what i remembered from the thread)
15:57:06 <msekleta> there is maybe one more option
15:57:19 <msekleta> have one systemd srpm as we have now
15:58:07 <msekleta> but build twice, one normal fullblown thing and second time, really minimal with bunch of explicit --enable-*=no for ./configure
15:58:46 * vpavlin had the same idea but figured out it would be *a lot* of ifs in spec
15:58:58 <pknirsch> brrr
15:59:02 <pknirsch> that sounds quite ugly
15:59:10 <msekleta> yes that is very ugly
15:59:20 * pknirsch scratches his head
15:59:22 <vpavlin> I don't want to go into this:)
15:59:28 <pknirsch> yea
15:59:37 <pknirsch> Hm, one crazy idea:
15:59:50 <pknirsch> Are these features compiled hard into systemd?
16:00:04 <pknirsch> Or is it just binaries that systemd uses if they are available?
16:00:32 <pknirsch> Because if it's the later, you could always simply remove them in a post script after creating the docker image
16:00:56 <vpavlin> My plan - have a base image with fakesystemd which is really minimal. Have a layered image with systemd instead of fakesystemd for those who want systemd - once we see what users want, we can change the base if needed
16:01:14 <pknirsch> right
16:01:17 * msekleta nods
16:01:35 <pknirsch> we can look at the statistics and see what people use/download
16:01:36 <vpavlin> I'd like to have %post as small and simple as possible.
16:01:40 <pknirsch> sure
16:02:30 <msekleta> ok so I think we are pretty much on the same page with fakesystemd
16:02:46 <pknirsch> Yea, it's a working solution for now, so let's stick with it
16:03:02 <pknirsch> Maybe if both of you follow up once more with Lennart that might be good
16:03:04 <vpavlin> yes - we sort of need it now, but we might ditch it later if we see users doing so:)
16:03:15 <pknirsch> aye
16:03:20 <msekleta> more difficult problem to solve is that systemd-216 doesn't really work in docker containers
16:03:28 <pknirsch> ugh
16:03:36 <msekleta> I have to debug it further
16:03:49 <vpavlin> I definitely will - I owe him an apology for not talking to him about fakesystemd firts:)
16:03:50 <moben> but f21 will have 215, so there is that :)
16:03:53 <vpavlin> first
16:03:59 <moben> afaik
16:04:04 <pknirsch> right vpavlin :)
16:04:15 <pknirsch> moben: and you believe systemd won't be rebased prior to RC? ;P
16:04:17 <pknirsch> HA!
16:04:59 <vpavlin> touché
16:05:02 <vpavlin> :)
16:05:10 <msekleta> anyway, I didn't have much time to look into the issue with 216 in more detail yet
16:05:22 <msekleta> hope to have it somehow working next week
16:05:28 <pknirsch> cool, thanks msekleta !
16:06:00 <pknirsch> Ok, friday evening in a (shitty EMEA) summer, so lets close this subject, i think we covered it well enough
16:06:04 <pknirsch> #topic Open Floor
16:06:13 <pknirsch> anyone got anything for the open floor plan?
16:06:57 * vpavlin is going to finally finish his mail to devel about last week topic (sorry)
16:06:57 <haraldh> weekend, I guess :)
16:07:04 <msekleta> will report on next meeting how does it look with systemd-216 in docker
16:07:31 <vpavlin> Just one note - I'd like to see F21 image(s) ready at F21 release:)
16:07:39 <pknirsch> yar!
16:07:43 <vpavlin> hopefully both - with and without systemd
16:07:59 <msekleta> pknirsch, that maybe a point for agenda as follow-up from this mtg
16:08:12 <pknirsch> will put that up, thanks msekleta !
16:08:26 <msekleta> pknirsch, thank you
16:09:41 <pknirsch> okidokie, thanks everyone then for joining today, have a fantastic weekend and thanks again moben for your great work!
16:09:52 <haraldh> bye bye
16:09:55 <pknirsch> o/
16:10:02 <vpavlin> Thanks moben and have a great weekend
16:10:10 <msekleta> have a great weekend everyone
16:10:12 <pknirsch> #endmeeting