15:00:37 #startmeeting Fedora Base Design Working Group (2013-11-29) 15:00:37 Meeting started Fri Nov 29 15:00:37 2013 UTC. The chair is pknirsch. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:00:37 Useful Commands: #action #agreed #halp #info #idea #link #topic. 15:00:50 #meetingname Fedora Base Design Working Group 15:00:50 The meeting name has been set to 'fedora_base_design_working_group' 15:01:04 Hello and good day everyone! 15:01:18 Not sure how many we have for todays meeting due to Thanksgiving in the US 15:01:24 * masta is here 15:01:29 heya masta ! 15:01:34 #chair masta 15:01:34 Current chairs: masta pknirsch 15:02:41 jreznik already told me he's on PTO today as well and won't be able to join. 15:03:08 so that leaves probably only haraldh and dgilmore i think 15:03:18 <- 15:03:24 heya haraldh :) 15:03:29 #chair haraldh 15:03:29 Current chairs: haraldh masta pknirsch 15:05:06 So we can do a quick and mainly informative meeting today if you like. I've put together a small table on https://fedoraproject.org/wiki/Base#Details with a few repoqueries to find out a bit more about what packages we would need for different scenarios 15:05:22 Mainly looking at only kernel, yum and rpm 15:05:26 then adding gcc 15:05:32 then adding pungi resp. anaconda 15:05:43 the numbers were quite interesting i think 15:05:48 systemd? 15:06:22 is already pulled in via requirements by kernel/rpm/yum 15:06:27 hmm, ok, kernel requires systemd anyway, IIRC 15:06:29 yes 15:06:30 syep 15:06:49 ~$ rpm -q --requires kernel 15:06:49 fileutils 15:06:49 systemd >= 203-2 15:06:49 dracut >= 027 15:06:51 ... 15:06:52 ok 15:07:07 should that be something else? 15:07:12 i mean 15:07:14 nono 15:07:30 kernel rpm yum gcc anaconda 713 15:07:36 sounds pretty good 15:07:47 i see one of our tasks as well to go through those lists in detail and figure our if there are any things we could prune or correct 15:07:56 but, is it enough to build itsselves? 15:08:06 i'd need to double check that 15:08:11 probably not 15:08:25 do we want mock etc.? 15:08:32 i'll send out an email to bill to ask how he determined the 2000+ packages needed for self hosting 15:08:37 hm, true 15:08:44 let me run that quickly 15:09:28 [root@power03 ~]# repoquery --arch=ppc64,noarch --requires --resolve --recursive kernel yum rpm mock | sort -u | wc 15:09:28 138 138 4349 15:09:31 not bad 15:10:27 what i found really nice was that without anaconda but with pungi for creating installer images we're only at about 230 packages 15:10:52 better than expected 15:11:11 #action pknirsch to ping notting about how he queried self hosting package set 15:11:16 yep 15:11:32 but i fear that the self hosting requirement will pull in quite a few more packages and nasty chains 15:11:40 which is what bill last week mentioned 15:11:52 most likely the whole documentation chain itself with texlive etc 15:12:44 ah, yes 15:13:25 shouldn't documentation be shipped kind of precompiled? 15:14:00 it does for some projects while others do it during their builds 15:14:15 but yeah, we should also declare that as our goal 15:14:27 -> work to minimize buildreqs 15:14:31 mhm 15:15:01 as a small and build complete base will make things a lot easier for other people to use it 15:15:01 start with low hanging fruits 15:15:45 maybe even ship a simple copy/installer script with base :) 15:15:47 it's kinda boring janitorial work, but i don't think we've done a lot of that in the psat years 15:16:16 base "clone" installer :) 15:16:34 might just use pungi for that? 15:16:36 that does it 15:17:02 though hm, that probably pulls in anaconda into the image 15:17:08 but could write other templates i guess 15:17:09 yeah 15:17:18 anywayx 15:18:14 #info One potential goal for the committee should be janitorial work on build require cleanup. Mark for topic for one of the next meetings 15:20:20 shouldn't systemd&dracut be part of the Base ? 15:20:28 key packages? 15:20:40 I mean PID 1 ... 15:21:14 I would guess they are in Base 15:21:23 assume even 15:21:25 https://fedoraproject.org/wiki/Base#Details 15:21:59 ah, sure, please add them 15:22:07 so it's officially documented 15:22:20 done 15:22:23 cheers 15:22:43 now we can bootup :) 15:22:46 heh 15:22:47 ye 15:22:57 and run rpm :) 15:23:01 jup 15:23:12 add a shell? 15:23:20 who needs a shell? ;) 15:23:34 right 15:23:38 e.g. take a really pure desktop system 15:23:44 that might not ever need a shell 15:23:44 right 15:23:50 e.g. android 15:24:05 (though i suspect they have one) 15:24:10 they do 15:24:13 mhm 15:24:29 selinux? 15:24:46 hm 15:25:43 from a broad perspective, no. e.g. embedded systems might not need them and it would have a relatively big performance impact there 15:25:49 I think most of the other WG define products which need it 15:25:50 does systemd work without selinux? 15:25:55 yea 15:26:10 systemd is linked ofc with the libraries 15:26:15 but works fine without 15:26:25 even if linked with the libs 15:26:25 if most or all WGs need selinux i think it should be in Base 15:27:47 I think, we should make a list with "minimal" and "base" 15:27:52 at least thats how i see it: Base should provide those fundamental functionalities that are being used by all or almost all WGs 15:27:54 whereas selinux is in "base" 15:27:58 mhm 15:28:52 hmm 15:29:06 "minimal" for containers is different 15:29:28 perhaps only "glibc" :) 15:30:34 haraldh: that is a good idea. by the way, do we also control the idea of minimal or just base? 15:30:35 let me see what that produces actually 15:30:50 15 packages, no kernel :) 15:31:25 well, any WG can define their "minimal" set of packages 15:31:32 masta, well, I see it as my goal to define "minimal" 15:31:37 but for Base i think it would be really good to do so 15:31:44 and keep it as "minimal" as it can be 15:31:50 for different scenarios that we see Base being useful for 15:31:55 e.g. the glibc case 15:31:59 or the kernel only one 15:32:29 not that i'd encourage it, but i could see someone wanting to use a very minimalistic fedora and then use apt or debpkg on top of it 15:32:37 hmm, kernel only without modules is not so much working 15:33:11 doesn't the kernel package include all the modules? 15:33:19 * pknirsch may be a bit behind on that 15:33:27 yeah, but something has to load them 15:33:31 ohhh 15:33:33 hehe 15:34:00 ofc, one could go with kernel and kmod alone 15:34:10 and his own PID1 15:34:27 udev is not needed even 15:34:54 that would be rather minimalistic 15:35:02 as minimal as it can be 15:35:10 booting a machine 15:35:36 but ye, lets collect those different things and provide info about them. and maybe one or the other is useful for someone 15:36:03 e.g. imagine a hpc cluster with thousands of machines. a very lightweight minimal system for them would be really good, too 15:36:29 I'll make graph, what is needed for what minimal stage, until next week 15:36:35 ^ a 15:36:36 thanks! 15:38:02 for minimal things I always thing maybe util linux, core utils, systemd/udev, selinux, auditing, rpm 15:38:08 grub2/gummiboot/syslinux .. any thoughts? 15:38:12 doh, i forgot the #topic again at the start :) 15:38:59 masta: would that reflect your embedded systems? 15:39:05 even with selinux? 15:39:10 oh yes 15:39:14 hm, ok 15:39:19 auditd? 15:39:45 I think I discovered audit stuff is required at some point 15:40:18 but we don't have to say audit stuff is required here 15:40:33 mhm 15:40:44 I don't think auditd is technically required 15:40:48 but still that would be interesting info where your requirement for audit came from? 15:41:07 actually scratch that, auditd was not required actually, just the AUDITSYSCALL kernel parameter was required for systemd 15:41:14 ah 15:41:15 ok 15:41:17 ah 15:41:17 sry about that 15:41:18 ye 15:41:21 no worries :) 15:42:54 and as mentioned, feel free to add your info to the wiki, either with a separate use case or under the details or where you see the fit 15:43:43 having more review of the base system is definitively a precursor to how everything will look like later 15:43:50 and what we can share with the other WGs 15:44:34 well I like the idea we put some of these down in the minimal, and we just bring in minimal to make Base... so we define both. I'm surprised all the other WGs get to redefine minimal 15:45:26 well, they can if they think it's useful for their specific variant 15:45:32 imagine a Workstation 15:45:45 you could think of a minimal workstation as well 15:45:49 X would be part of their minimal 15:45:52 mhm 15:46:00 maybe with a login and a desktop manager 15:46:20 and anything after that is not really minimal anymore for them 15:46:41 maybe i expressed myself a bit wrong there, those minimal sets would be for their variant, not for Base 15:46:59 same for Server 15:47:05 hmm 15:47:29 they might decide a Server has to have some functionality, e.g. ssh, config mgmt, IPA 15:48:44 and maybe (and thats just an crazy idea here now) the minimal set for Base would then be the set of packages shared by all variants/products in their minimal representations 15:49:08 it shouldn't be much different from what we're looking at right now i suspect 15:49:17 ok 15:49:34 but again, thats just my view 15:49:38 :) 15:51:44 we might end up defining Base differently, depending on what and how other WGs see us. I'll get more involved over the next week with them to see a bit more about their concrete requirements and views of Base 15:52:01 right 15:52:17 but that does not stop us from working on the real minimal sets 15:52:22 exactly 15:52:25 right now 15:52:28 as thats something we will definitely need 15:52:39 no matter what any of the WGs decide to need in addition to that 15:52:46 correct 15:52:57 seems right 15:53:05 very well put haraldh :) 15:53:22 Btw, what are our super powers right now? 15:53:31 why dont you just keep the core to something as small as what makes up mir or tizen? 15:53:32 LAZOR BEAMS! 15:53:37 Do we have to do the work? Do we have to file BZs? 15:54:04 Viking-Ice: so how small is mir or tizen then? 15:54:06 http://releases.merproject.org/~carsten/mer-core-i586.ks 15:54:46 @Mer Core 15:54:53 well, that's the point :) 15:54:55 http://gitweb.merproject.org/gitweb?p=mer/project-core.git;a=tree;f=patterns;hb=HEAD 15:55:22 you can see there in the raw output what exactly is in mer-core 15:55:26 Viking-Ice, we come automatically to that point :) 15:55:40 as we work our work up 15:55:51 as we work our way up 15:56:00 in the dependency foodchain 15:56:38 yeah but it's unavoidable from a logical sense that the other WG's will have to define their own base since the needs on server ( or cloude ) != the same needs on workstation 15:56:48 sure 15:57:30 hence I proposed 3 layer solution 1 core ( what you define ) one base ( which was mutual for each server role ) then each role by itself 15:58:23 if you call it Base-"base" or "1 core" does not matter 15:58:47 the same can be applied to the workstation group if they stop fighting amongst themselves and come to the only logical conclusion one base ( mutual for each DE ) then each DE by itself 15:58:52 additional to Base-"base", I also want to have a Base-"minimal" :) 15:59:09 right Viking-Ice 15:59:19 thats what i meant with my minimal sets for each variant 16:00:37 haraldh, I dont think you should split the "core" to core - minimal and or core - extras etc 16:00:58 since as soon as you start doing that you will start more headache for us in QA 16:01:34 then atleast I see us wanting 16:01:49 as you'd then have to test all the variants in Base, right Viking-Ice ? 16:01:57 or at least would feel inclined to do so 16:02:20 thereby blowing up the whole test matrix 16:02:31 got a hard stop, must go now. =( 16:02:34 bye all 16:02:36 cya masta ! 16:02:59 pknirsch, yeah the way forward that I will be proposing for us to do in QA is to that we try to move into grouped updates and test them as well as build an QA community layer on top of that 16:03:27 mhm 16:03:30 "grouped updates" - yes, plz 16:03:40 that's what I proposed with my release cycle 16:04:31 grouped "base" updates 16:04:42 yep 16:04:43 therefore "base" has to be pretty self containing 16:05:21 the length of the release cycle in your proposal was bit off but yes we need to approach this as group in QA we already discussed all that before the the current RH team dedicate to Fedora QA 16:05:22 and probably even self buildable 16:05:48 * pknirsch nods 16:05:51 yes but getting there is well way in the future 16:06:14 doesn't hurt to set it as a long term goal 16:06:33 i might have something i can throw at this, we'll see 16:06:48 once I have finished the community proposal I will work on a new build system proposal what David A. said made sense as an future approach to such system 16:06:49 been putting together a bunch of scripts for automated rebuilds and composes 16:07:13 David A? 16:08:36 David Airlie 16:09:27 ah, ok 16:09:39 the next gen community platform I currently working on requires new bugzilla/build system ( or modification to existing ones ) thus it makes sense to design a new system and or get discussion going between distros about that 16:10:44 sure 16:11:17 in anycase that community platform might be suited for Fedora or Fedora not ready for such distro agnostic approach and change ( which was one of the reason I walked out of the serverWG ) 16:11:28 might not be I mean 16:11:36 ( suited for ) 16:12:34 mhm, i know what you mean 16:14:11 anywho just few notes to this meeting... 16:14:15 * Viking-Ice goes back to work 16:14:53 alright, think we're done anyway. or haraldh, anything else from you? 16:14:57 so, pknirsch, let's make some decisions :) Ready to vote? :) 16:15:00 hahaha 16:15:15 yeah.. done 16:15:44 oki, thanks masta and haraldh and Viking-Ice for being here today! and have a great weekend! 16:15:51 u2 16:15:57 #endmeeting