18:00:02 #startmeeting FESCO (2014-03-19) 18:00:02 Meeting started Wed Mar 19 18:00:02 2014 UTC. The chair is nirik. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:00:02 Useful Commands: #action #agreed #halp #info #idea #link #topic. 18:00:02 #meetingname fesco 18:00:02 #chair abadger1999 dgilmore mattdm mitr notting nirik pjones t8m sgallagh mmaslano jwb 18:00:02 #topic init process 18:00:02 The meeting name has been set to 'fesco' 18:00:02 Current chairs: abadger1999 dgilmore jwb mattdm mitr mmaslano nirik notting pjones sgallagh t8m 18:00:16 Hello 18:00:29 hey 18:00:29 Greetings 18:00:33 I'm mostly here (splitting my attention) 18:00:35 hi 18:00:50 hi 18:01:09 * mattdm waves 18:02:29 ok, we have a reasonably full docket today, so lets go ahead and dive in. 18:02:39 #topic ticket #1221 Product working group activity reports 18:02:39 .fesco 1221 18:02:39 https://fedorahosted.org/fesco/ticket/1221 18:02:41 nirik: #1221 (Product working group activity reports) – FESCo - https://fedorahosted.org/fesco/ticket/1221 18:02:46 hello 18:02:54 anything we want to discuss or note from this week on working group activity? 18:03:19 let's just info the stuff in the ticket really quickly? 18:03:26 Do we want to weigh in on the Env/Stacks question about the Playground repo? 18:03:38 #info cloud is going through the list of changes we said we would file, finding owners, and filing them. 18:03:49 question: i thought that was supposed to be every other week? 18:04:08 jwb: indeed it is. Sorry 18:04:13 Yes, and we god desynchronized wrt which week it seems 18:04:18 #info cloud also discussing Fedora Atomic / ostree (for Docker-focused image, not general one) 18:04:18 jwb: It is, but I can never remember which week we're on, so I update either way 18:04:35 ok, fine. 18:04:53 is env-and-stacks one vs. many question actually being posed to fesco for an opinion? 18:04:59 should we just declare this the right week and go on from here (eg skip next week)? 18:05:06 #info env and stacks working on proposal for playground repo 18:05:30 #info server working group is working on role d-bus api 18:05:32 #info base design has no big news but is reviewing tech specs 18:06:05 jwb wanna add anything really quick? 18:06:15 no 18:06:16 notting: Well, the "many" answer implies that FESCo would have to go back on an earlier ruling about including copr repo files in packages 18:06:17 notting: unsure. 18:06:29 Or at least, defining whether "playground" has the same rule there 18:06:43 jwb ok :) 18:06:43 sgallagh: it doesn't need to be in a package tho, does it? 18:07:07 hey copr, give me all repo files marked 'playground' and for f20-x86_64 in a tar.gz, thanks! 18:07:08 notting: The purpose of this ticket is to some extent to give FESCo the option to raise concerns about things that weren't explicitly given to FESCo to decide... 18:07:10 Well, it needs to be managed in a way that is fundamentally the same as a package 18:07:28 sgallagh: i guess my concern would be that while it does seem to make sense given some of the constraints/desires of the playground repo, it makes the playground repo value prop much less just over coprs itself 18:07:35 sgallagh: Repos could still be vetted ... so probably need to wait for env and stacks to figure out what they want to do before revisiting. 18:07:46 notting: Which "it". please? 18:07:49 notting +1 18:08:02 sgallagh: many small repos, sorry. 18:08:06 ok 18:08:25 yeah, I don't want us to go barging in before they have worked up the proposal really... I'm fine with us adding our concerns/ideas to them directly until they want us to review the proposal. 18:08:29 under that many-repo proposal, is it anything other than 'a curated set of coprs'? 18:08:39 Yeah, the "problems with 1 big repo" section seems to assume multiple packages with the same name existing "within playground", which is not obviously necessary to fulfill the primary mission of the playgorund repo 18:09:29 If name conflicts were prohibited, the question of 1 repo / multiple repos would, I think, basically disappear 18:10:14 notting: I don't think so... but I can only attend half the meetings and this was the week I wasn't there. 18:10:17 * jreznik is here, sorry for being a bit late - re-reading backlog 18:10:43 abadger1999: ok, then you may or may not be able to answer this - was the signing discussion intended to cover coprs as well as playground 18:10:48 it may be difficult to detect or prohibit name conflicts. 18:11:20 notting: I'm not sure that they are equivalent but AFAIK both are going in the same direction (OBS signing service) 18:11:21 notting: two weeks ago it was discussed whether the signing had to be tied to coprs or if it could be implemented separately. 18:11:34 I don't know what followup on that question was done this week. 18:11:49 ok 18:11:55 nirik: A git commit hook that limits all binary packages to be $git-repo-name{,-with-optional-suffixes}? 18:12:07 (i'm good to move on if we want to wait for a specific env-and-stacks query) 18:12:10 git commit to what? 18:12:23 mitr: problem being coprs are built from a list of urls 18:12:29 yeah, there's no git commit in coprs. 18:12:39 Ah, this doesn't involve dist-git. 18:13:03 Probably best to talk to env and stacks directly if you're seeing flaws in what they want to design. 18:13:11 anyhow, shall we simply ask folks to talk to env-and-stacks and move on? or is there something we want to do? 18:13:11 well the idea between one repo was to start with something easier/doable now and it wasn't one repo for all the times but more like more repos serving different usecases but start 18:13:16 mmaslano hasn't been joining us in fesco recently. 18:13:22 Yes; move on? 18:13:42 ok, moving on... 18:13:47 abadger1999: She was voted out last cycle 18:14:05 #topic #1243 Consider release blocking status of KDE spin(?) for Fedora 21 in .next decision-making 18:14:05 .fesco 1243 18:14:05 https://fedorahosted.org/fesco/ticket/1243 18:14:06 nirik: #1243 (Consider release blocking status of KDE spin(?) for Fedora 21 in .next decision-making) – FESCo - https://fedorahosted.org/fesco/ticket/1243 18:14:17 did we wish to defer this further? 18:14:30 we will be ready by next week's fesco meeting 18:14:31 jreznik what I don't want to see is multiple repos with the same use cases but you have to pick one to avoid coonflicts 18:14:33 sgallagh: I know -- but she's the fesco liason to the env and stacks team. 18:14:52 nirik: I kind of thought "1-2 weeks" pretty obviously means "2 weeks", yes ;) 18:15:04 pjones lol yes 18:15:17 indeed, it always does. Unless it means 3. ;) 18:15:35 proposal: defer to next week 18:15:35 pjones: that's why I did not promise 1 week :) 18:15:41 +1 move on 18:16:00 note that there's another mini-thread about this on the devel list too 18:16:13 * nirik nods. 18:16:22 +1 move on 18:16:23 #info more discussion on this on devel list currently 18:16:27 +1 18:17:26 more votes? just one more? ;) 18:17:28 +1 18:17:32 #agreed defer to next week 18:17:39 #topic ticket #1250 F21 Self Contained Changes 18:17:39 .fesco 1250 18:17:39 https://fedorahosted.org/fesco/ticket/1250 18:17:40 nirik: #1250 (F21 Self Contained Changes) – FESCo - https://fedorahosted.org/fesco/ticket/1250 18:18:22 we had deferred this due to the one change we wanted more info on... 18:18:47 * jreznik asked hans and he added updates to the ticket 18:19:14 and we have new ones this week also there. 18:19:17 also note there are more changes for this week 18:20:06 and I'm here in case you've any more questions ... 18:20:13 Allwinner sunxi, add amd map parser to autofs, CUPS Journal Logging 18:21:02 * nirik is fine with all of them. 18:21:10 * notting is +1 to all three 18:21:32 * pjones also +1 on all three of those 18:22:00 i am +1 to all three 18:22:02 +1 18:22:04 +1 to all three 18:22:27 +1 18:22:36 #agreed all 3 self contained changes approved. (+7,0,0) 18:22:39 i'm +1 to all three too 18:22:41 sorry 18:22:46 #undo 18:22:46 Removing item from minutes: AGREED by nirik at 18:22:36 : all 3 self contained changes approved. (+7,0,0) 18:22:50 #agreed all 3 self contained changes approved. (+8,0,0) 18:22:54 #topic ticket #1253 requesting exception for linking cscppc and cswrap with glibc-static 18:22:54 .fesco 1253 18:22:54 https://fedorahosted.org/fesco/ticket/1253 18:22:56 nirik: #1253 (requesting exception for linking cscppc and cswrap with glibc-static) – FESCo - https://fedorahosted.org/fesco/ticket/1253 18:23:19 I'm kind of torn no this 18:23:27 on the one hand, they could just scrape ldd and copy more libs in 18:23:45 but that would also mean more stuff that's not what's being tested going on inside the chroot 18:23:52 yeah 18:24:10 (sorry -- note on the last one -- I expect that the plan jwb gives of waiting until 3.15 will be followed) 18:24:39 mattdm: yeah, I was taking that as given 18:24:44 pjones: there may be runtime dependencies, plugins loaded from the main system, ... for Really Clean, the wrappers should be added to the respective old repos, but that's not really an option 18:25:13 mitr: plugins and whatnot are not covered by the request 18:25:24 mitr: in fact it kind of implies there aren't? 18:25:41 pjones: I was thinking specifically nss, but that's probably not an issue 18:25:45 since, I mean, we don't have some rule that says you can't statically link your own plugins or something. Why would you have a plugin system if you wanted to statically link them? 18:25:48 I wonder... could the package build both static and dyanmic? 18:25:48 well, okay 18:26:06 would they expect to use a f21 build version on rhel5?> 18:26:09 then at least when the dynamic one needed to be rebuilt they would know to rebuild the static one too 18:26:10 nirik: why? either we grant the exception or we don't. 18:26:17 Considering that this is explicitly a development tool that doesn't cross a privilege boundary, statically linking with an old glibc shouldn't be a security issue. 18:26:27 i would think that the version used will have been build on the running OS 18:26:31 nirik: that's what we have the magic Requires: for static libs for 18:26:41 nirik: the package should be *able* to be built that way for debugging purposes, at least. but i don't know that it needs to be built that way all the time 18:26:52 er 18:26:54 Provides: rather 18:27:00 "Provides: bundled(openssl) = 0.9.8w" and similar 18:27:17 but these arent libs... 18:27:27 o_O 18:27:35 If glibc-static dropped support for the old kernels, this would break... but that's up to the package maintainer really (they would get the bugrports), not a reason for us to prohibit the exception AFAICT 18:27:41 it only BR's BuildRequires: glibc-static 18:28:17 nirik: I think somehow we're completely talking around each other 18:28:29 Oh, I see what you're saying, I think. 18:28:32 pjones: yeah, could be... 18:28:58 * nirik isn't sure why dgilmore's query isn't true now tho... 18:29:21 I mean, yeah, the whole point is that they're pulling the library from the host OS 18:29:33 nirik: my understanding of the arch is that the version of cs* lives in the host OS just like mock does, and gets copied into the testing chroot 18:29:40 kind of like dockerinit 18:29:41 yes, but why? 18:29:51 why not install it from the chroot repo? 18:30:05 nirik: I think I didnt grok things right the first time 18:30:23 I think the worry is that we'll have one of those times where the glibc abi breaks between versions, so they won't be able to do ltdr against glibc in the chroot 18:30:27 I think really the best solution is to have them install the tools from the target os 18:30:27 dgilmore: then I am misunderstanding the same way now. ;) 18:30:31 rtdl even 18:30:53 nirik: There are three basic alternatives to the proposal: 1) add a new package to the old OS release that isn't quite under our control, 2) for each target OS, create a new tool-specific repo and add it to mock configuration, 3) for each target OS, build the wrapper and copy the binary into the f21 RPM package 18:31:49 pjones: Yes, bumping symbol versions in glibc happens fairly frequently. 18:32:31 The attraction of this proposal is that (as long as the kernel doesn't break ABI and glibc doesn't drop support for old kernels), there is only one build to create and manage, unlike the 2/3 cases 18:32:39 Anyhow.... proposal: approve exception 18:32:48 mitr: Yeah, that matches with what I was thinking -- so what's the hand up with doing (1)? Are those packages already in RHEL-proper? 18:32:49 mitr: #3 is *uuuugh* 18:32:53 *hang up 18:33:16 mitr: well glibc in rhel6 and fedora 14 up requires a 2.6.32 kernel 18:33:26 mitr: i don't see any practical options other than your #1 above, or approving the exception 18:33:47 abadger1999: At this point in the lifecycle, adding packages to RHEL is pretty much impossible in general, let alone for an experimental development tool 18:33:54 mitr: epel? 18:34:01 mitr: but... epel. 18:34:08 mitr: mock is in epel, 18:34:14 * mattdm is not fast enough at typing epel 18:34:20 mitr: we can add the tools to epel 18:34:21 dgilmore: Good point. 18:34:38 I think I'm okay with approving the exception; most of our objection against static linking is things like zlib in programs with high attack surface. the attack surface here is quite minimal. 18:34:59 mitr: +1 18:34:59 proposal: ask why not do option 1 to submittor, revisit next week with their answer? 18:35:06 nirik: +1 18:35:15 nirik: +1 18:35:20 nirik: Yeah, we should be asking about epel 18:35:20 I'm not opposed to a static lib exception if there's a reason... just don't see the reason yet. 18:35:26 * mitr widthdraws his proposal for now 18:35:31 it /is/ a much higher maintenance burden? 18:35:35 but... yeah, okay 18:35:37 nirik: +1 18:35:37 pjones: There really isn't an attack surface. The attack surface is the mock/outside-of-mock boundary in the tool that pulls the logs out of the chroot. 18:35:53 I really dont see the reason, I think we can add to epel/fedora and just have them installed into the chroot 18:36:06 nirik: sure, +1 18:36:24 mitr: that's my point, yes. 18:36:50 #agreed ask submittor if they cannot just build for any branches they need support for and revisit next week. (+6,0,0) 18:36:56 +1 18:37:01 #topic ticket #1255 girara+zathura: update policy exception request 18:37:01 .fesco 1255 18:37:01 https://fedorahosted.org/fesco/ticket/1255 18:37:02 nirik: #1255 (girara+zathura: update policy exception request) – FESCo - https://fedorahosted.org/fesco/ticket/1255 18:37:08 sorry mattdm 18:37:09 grr. network problems. 18:37:13 glitchy glitchy 18:37:32 * mattdm is not worried about noncontroversial vote counting 18:37:35 +1 this exception. 18:37:52 * pjones +1 too 18:37:57 +1 18:38:12 +1 18:38:19 +1 to the exception 18:38:26 given the key "there is no software that I know of using girara except zathura. " statement, +1 18:38:47 notting: yeah, exactly. 18:39:01 #agreed exception granted (+6,0,0) 18:39:02 +1 18:39:11 #topic ticket #1256 non responsive maintainer fast track 18:39:11 .fesco 1256 18:39:11 https://fedorahosted.org/fesco/ticket/1256 18:39:11 +1 18:39:12 nirik: #1256 (non responsive maintainer fast track) – FESCo - https://fedorahosted.org/fesco/ticket/1256 18:39:18 * nirik keeps going too fast. Sorry. 18:39:43 nirik I'm in favor of meeting speed over accuracy :) 18:39:57 im okay to fast tracking this 18:39:57 :) 18:40:07 +1 fast track 18:40:11 +1 fast track 18:40:12 yeah, +1 here - it's not even non responsive maintainer at this point 18:40:13 seems based on the comment he doesnt plan to do any fedora work 18:40:17 we have confirmation he said we could do it 18:40:25 +1 18:40:29 * nirik nods. 18:40:32 +1 here 18:40:37 +1 18:40:40 +1 to be clear 18:40:47 pjones: which i suppose makes it less 'fast track' and more just 'using admin powers to do it' 18:41:10 #agreed will orphan packages and allow other maintainers to pick things up (+7,0,0) 18:41:19 #topic ticket #1257 F21 System Wide Change: u-boot syslinux by default - https://fedoraproject.org/wiki/Changes/u-boot_syslinux 18:41:20 .fesco 1257 18:41:20 https://fedorahosted.org/fesco/ticket/1257 18:41:22 nirik: #1257 (F21 System Wide Change: u-boot syslinux by default - https://fedoraproject.org/wiki/Changes/u-boot_syslinux) – FESCo - https://fedorahosted.org/fesco/ticket/1257 18:41:35 * dgilmore is obviously in favour of this 18:41:54 I dunno, who is this dgilmore person anyhow? ;) 18:41:55 +1 18:42:04 sure, +1 18:42:06 +1 18:42:19 +1 18:42:33 especially since pjones is in and syslinux is his package :) 18:42:33 =1 18:42:34 +1 18:42:40 +1, of course 18:42:42 mattdm: note that syslinux isn't actually being /used/ 18:43:02 mattdm: its not involving syslinux package 18:43:22 mattdm: u-boot has its own implementation of syslinux config file parsing 18:43:25 mattdm: it's just uboot supporting the config file format and us using that format on the uboot devices 18:43:33 dgilmore: can we rename the feature to "syslinux-style configuration for u-boot by default", perhaps? 18:43:37 in any case, +1 18:43:47 notting: sure. 18:43:50 #agreed change approved (+8,0,0) 18:44:09 #topic ticket #1258 Coordinate FESCo at Flock 2014 18:44:09 .fesco 1258 18:44:09 https://fedorahosted.org/fesco/ticket/1258 18:44:10 nirik: #1258 (Coordinate FESCo at Flock 2014) – FESCo - https://fedorahosted.org/fesco/ticket/1258 18:44:22 First question: who is going? 18:44:27 * sgallagh will be there 18:44:33 * abadger1999 should be there 18:44:38 * mattdm will be there 18:44:43 * pjones thinks so. 18:44:51 * dgilmore believes he will be there 18:44:52 * notting has no idea 18:44:56 * jreznik can help with it during flock as he's local to prepare it etc 18:44:59 * nirik should be there. 18:45:08 I hope so 18:45:26 mitr: its a 2 hour drive, you should be there :) 18:45:50 sgallagh I assume the Fedora.next.next talk is your proposal? 18:45:55 mattdm: It is 18:45:58 dgilmore: with that famous highway... 18:46:03 * dgilmore needs to run in 10 minutes to pick up daughter from preschool 18:46:13 jreznik: improving highways :) 18:46:20 mattdm: As is the Server one 18:46:38 so, do we want to do what I said in the ticket? 18:46:46 that is, what we did at devconf: 18:46:47 sure, sounds fine to me. 18:46:50 I can do an overview of Fedora.next followed by 3-minute-each WG summaries followed by moderated discussion. 18:46:56 Then, later (different day?), "Meet your FESCo" panel. 18:47:00 mattdm: Yes, I think that was very useful at DevConf 18:47:15 And Flock is a more targeted audience. 18:47:21 I think that this is _separate_ from the fedora.next.next part -- talk/discussion instead of workshop 18:47:27 We may want to actually get that booked in keynote space, actaully 18:47:30 is that clear enough? 18:47:45 interesting... 18:48:17 sgallagh do you want to moderate the panel discussion again, or does anyone else want to raise their hand for that? 18:48:18 anyhow, mattdm: +1 18:48:25 mattdm: I'll volunteer 18:48:55 that actually raises an interesting question 18:49:10 pjones: What does? 18:49:19 given the f21 schedule, I forget - have we made plans for an intervening election /before/ then? 18:49:23 sgallagh: meet your fesco 18:49:43 sgallagh do you want to submit the panel part? I can do both, I just don't want mid-air collisions 18:49:53 pjones: not seen any plans for an election 18:49:58 and likewise should i submit Meet Yor FESCo? 18:50:00 pjones: not that I am aware of. We may want to discuss that (seperate from this) 18:50:19 nirik: yeah, guess that can go at the end 18:50:31 * abadger1999 thought we had discussed and decided to keep i bound to post-fedora release rather than a time. 18:50:56 abadger1999: if so was before me 18:51:14 we may want to look back for that discussion... 18:51:32 mattdm: Why don't we talk directly to Ruth and Tom about that? I think we want that in as a keynote-type thing instead of a standard talk 18:51:38 That'll make it easier to schedule together as well 18:52:00 sgallagh okay. I'll do that. 18:52:28 * nirik doesn't think meet your fesco needs a keynote slot... perhaps people don't care to meet their fesco. ;) 18:52:35 mattdm: Because we pretty much want the entire attendance present for that (and I suspect anything booked against it would be poorly attended) 18:52:35 #action mattdm will talk to flock planners about scheduling fedora.next talk and discussion as keynote 18:52:37 (or not too many of them) 18:52:53 nirik: I'm talking about the .next review and panel 18:53:08 I'm also okay with meet-your-fesco as not keynote 18:53:12 yeah, ok... I was replying to the "schedule together" part. 18:53:21 so people who don't care about politics have something to do. 18:53:41 is anyone else itching to submit the meet your fesco proposal? 18:53:43 nirik: The talk and discussion should be back-to-back. That's what I meant about scheduling them together 18:53:45 otherwise i will do it. 18:53:48 Sorry, too many conversations at once 18:54:04 sgallagh: ah, ok. I saw that as 'one thing' 18:54:17 nirik there are three things. two of them are one. 18:54:25 clear as mud 18:54:42 anyhow, anything else we want to discuss here? or vote on? or shall we move on? 18:54:58 #action mattdm will also schedule fesco panel 18:55:12 AFter the schedule is announced, we should coordinate attendance at key talks 18:55:19 But that's obviously for later 18:55:22 yeah. 18:55:27 moving on? 18:55:35 #topic ticket #1259 F21 System Wide Change: jQuery - https://fedoraproject.org/wiki/Changes/jQuery 18:55:35 .fesco 1259 18:55:35 https://fedorahosted.org/fesco/ticket/1259 18:55:36 nirik: #1259 (F21 System Wide Change: jQuery - https://fedoraproject.org/wiki/Changes/jQuery) – FESCo - https://fedorahosted.org/fesco/ticket/1259 18:56:03 this seems like a lot of work for minimal gain and probably a lot of fighting upstream. but if someone wants to do it.... 18:56:20 it's gonna be a lot of work yeah... 18:56:23 good luck to them :) 18:56:25 but sure, +1 18:56:26 so +1 18:56:27 +1 18:56:30 +1 18:56:32 +1 same thoughts 18:56:47 * dgilmore needs to run and pick up daughter, back in 15 minutes 18:56:55 +1 18:57:25 +1 18:57:36 #agreed change is approved (+7,0,0) 18:57:43 #topic ticket #1260 F21 System Wide Change: Xorg without root rights - https://fedoraproject.org/wiki/Changes/XorgWithoutRootRights 18:57:43 .fesco 1260 18:57:43 https://fedorahosted.org/fesco/ticket/1260 18:57:44 nirik: #1260 (F21 System Wide Change: Xorg without root rights - https://fedoraproject.org/wiki/Changes/XorgWithoutRootRights) – FESCo - https://fedorahosted.org/fesco/ticket/1260 18:57:48 +1 here 18:57:51 * abadger1999 notes if patches wants to force the older, insecure jquery bundling out, he can ask fesco to approve something as well. 18:57:52 +1 awesome 18:57:56 +1 18:58:00 +1 18:58:05 I've actually got some questions about this 18:58:15 lots of question marks in the the dependencies section. but +1 to the idea. 18:58:39 not least: does startx still work, and is there any way to specify arbitrary modules/drivers for it to load on the command line? 18:59:07 (sorry, only came up with these right before the meeting or I'd have asked them in the ticket.) 18:59:15 It would be nice to link to bugs on each of the DM's so we could see what status was on them. 18:59:20 that too 18:59:34 so proposal: give this another week and nirik and I will ask those things on the ticket? 18:59:42 hansg: still here? 18:59:49 or if he's around that'll work too 19:00:37 it may be the wrapper is needed for startx? not sure, but yeah, good to know. 19:01:10 i'm okay with waiting another week for more info 19:01:25 jreznik, yes 19:01:25 well, presumably if startx is still made to work, it means it's doing some magic systemd invocation instead of, you know, running /usr/bin/X 19:01:51 I assumethat that's covered under "For Fedora 21 there likely will be a fallback mode where the xserver will do the device-management itself when not started from a display-manager which starts it inside a user-session. " 19:02:02 pjones, nope. systemd is not involved in starting X at all 19:02:32 pjones: you might be thinking of the breakage on vt switch? 19:02:42 X talks to systemd-logind over dbus, and logind hands it fds for things like keyboard mouse and /dev/dri/card0 19:03:36 hansg: so the question is: do you get to pass the server arbitrary module paths on the command line, and get some module you've asked to be loaded an fd to /dev/dri/card0 ? 19:03:39 logind will only do this if X is part of a systemd-logind managed user session, which mean that dm-s like gdm need to first start a pam login session, and then start Xorg in there, iow Xorg becomes just another user process like any other user process 19:03:59 (I'm sort of proxying a conversation I had with ajax earlier here, but I think I understand what he was wondering.) 19:04:09 pjones, you're talking about X modules here ? 19:04:13 yes 19:05:24 So the path is X does udev probing, sees in the udev db there is a /dev/dri/card0, then asks logind to open it, logind passed fd to X, X then continues with its usual autoconfigure, so it will see that it needs to load xf86-video-intel, and it also throws in xf86-ivdeo-modesetting as fallback 19:05:34 pjones: I'd expect the current setuid X to not allow arbitrary modules either 19:05:48 It then calls xf86-video-intel's probe method first passing in the fd, if that likes the fd, that is where things end 19:06:01 mitr: yeah, I'm just wanting to make sure that this hasn't really changed that 19:06:29 WRT arbitrary modules only modules in %{libdir}/xorg/modules are ever loaded 19:06:39 mitr: mostly just avoiding the theory of "well, X is rootless, how much can it hurt" while it's got an ioctl that can do arbitrary DMAs. 19:06:55 alright, as long as that's still the case I've got no major concerns. 19:07:13 ok, we are at +5 then I guess? 19:07:18 * pjones +1 19:07:22 +1 19:07:31 * notting is/was +1 19:07:35 Nope that has not changed, most codepaths are unchanged the only difference is that drivers no longer open device ndoes themselves instead they get passed in an fd, which the xserver gets from logind on behalf of the drivers 19:07:36 hansg: can you note bugs against the DM's in there to add support/changes? that would make it easier to see where everything is at... 19:07:58 (well, when it's ready for that obviously) 19:08:24 nirik, then I would first need to file bugs for that, but yes that is a good idea, I'll put filing those on my todo for tomorrow and then I'll drop links to them in the fesco trac ticket 19:08:31 #agreed change approved (+7,0,0) 19:08:41 hansg: cool. or just the change wiki page is fine. 19:09:05 #topic Chair next week 19:09:09 who wants it? 19:09:34 I haven't been a chair in a while, I'll take it 19:09:46 I may not be around next week, but I'll take it on the 2nd 19:09:46 thanks mitr 19:09:54 #info mitr to chair next week 19:10:13 #info sgallagh wants to chair the following week. 19:10:19 #topic Open Floor 19:10:23 any items for open floor? 19:10:30 I think I found the elections discussion 19:10:43 It was for the post-f20 election rather than the post-f21 election. 19:11:47 I think we may want to think about it and come up with proposals. The obvious ones are: election after f21 is out, or election in the time when f21 would have normally been out (time or schedule based) 19:11:54 abadger1999 we tend to never make long term decisions when solving the immediate issue will do :) 19:12:48 wouldn't this be, in some way, a project decision, not a fesco one? 19:13:02 I'm definitely in the post-f21 camp. It makes sense as a "This fesco produced this thing. Next fesco can worry about producing the next one." 19:13:13 yeah, oddly fesco has controlled it's own election policy, which may well be unwise... ;) 19:13:21 but we could ask the board. 19:13:33 fesco predates the board... likely why things are that way. 19:13:37 and back 19:14:24 abadger1999: right, the discussion was actually for the election we just /had/ 19:14:38 but we didn't realize that the schedule was likely to make a time-based election schedule include /another/. 19:14:39 19:15:32 abadger1999: I think I am in the same camp, but wider discussion would probibly be good. 19:15:41 19:15:41 * jreznik thinks elections should be and are release based 19:15:44 Maybe we should, I dunno, ask our constituents? 19:15:59 jreznik: there's sort of an argument that the last one wasn't... 19:16:32 * nirik doesn't think we will solve this today in open floor. ;) 19:16:33 pjones: last one was still scheduled based on the rules... 19:17:06 that delay was organization failure (/me was part of) 19:17:41 yeah, shall we file a ticket and give us time to review and discuss the history and think about the options? 19:17:50 mitr: +1 19:18:01 yep. +1 19:18:34 * jreznik can coordinate it with board/broader community 19:18:36 mitr: +1 19:20:05 mitr: sounds good 19:20:15