18:00:02 <nirik> #startmeeting FESCO (2014-03-19)
18:00:02 <zodbot> 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 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
18:00:02 <nirik> #meetingname fesco
18:00:02 <nirik> #chair abadger1999 dgilmore mattdm mitr notting nirik pjones t8m sgallagh mmaslano jwb
18:00:02 <nirik> #topic init process
18:00:02 <zodbot> The meeting name has been set to 'fesco'
18:00:02 <zodbot> Current chairs: abadger1999 dgilmore jwb mattdm mitr mmaslano nirik notting pjones sgallagh t8m
18:00:16 <mitr> Hello
18:00:29 <notting> hey
18:00:29 <abadger1999> Greetings
18:00:33 <sgallagh> I'm mostly here (splitting my attention)
18:00:35 <jwb> hi
18:00:50 <dgilmore> hi
18:01:09 * mattdm waves
18:02:29 <nirik> ok, we have a reasonably full docket today, so lets go ahead and dive in.
18:02:39 <nirik> #topic ticket #1221 Product working group activity reports
18:02:39 <nirik> .fesco 1221
18:02:39 <nirik> https://fedorahosted.org/fesco/ticket/1221
18:02:41 <zodbot> nirik: #1221 (Product working group activity reports) – FESCo - https://fedorahosted.org/fesco/ticket/1221
18:02:46 <pjones> hello
18:02:54 <nirik> anything we want to discuss or note from this week on working group activity?
18:03:19 <mattdm> let's just info the stuff in the ticket really quickly?
18:03:26 <sgallagh> Do we want to weigh in on the Env/Stacks question about the Playground repo?
18:03:38 <mattdm> #info cloud is going through the list of changes we said we would file, finding owners, and filing them.
18:03:49 <jwb> question: i thought that was supposed to be every other week?
18:04:08 <nirik> jwb: indeed it is. Sorry
18:04:13 <mitr> Yes, and we god desynchronized wrt which week it seems
18:04:18 <mattdm> #info cloud also discussing Fedora Atomic / ostree (for Docker-focused image, not general one)
18:04:18 <sgallagh> jwb: It is, but I can never remember which week we're on, so I update either way
18:04:35 <jwb> ok, fine.
18:04:53 <notting> is env-and-stacks one vs. many question actually being posed to fesco for an opinion?
18:04:59 <mattdm> should we just declare this the right week and go on from here (eg skip next week)?
18:05:06 <nirik> #info env and stacks working on proposal for playground repo
18:05:30 <nirik> #info server working group is working on role d-bus api
18:05:32 <mattdm> #info base design has no big news but is reviewing tech specs
18:06:05 <mattdm> jwb wanna add anything really quick?
18:06:15 <jwb> no
18:06:16 <sgallagh> 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 <nirik> notting: unsure.
18:06:29 <sgallagh> Or at least, defining whether "playground" has the same rule there
18:06:43 <mattdm> jwb ok :)
18:06:43 <nirik> sgallagh: it doesn't need to be in a package tho, does it?
18:07:07 <nirik> hey copr, give me all repo files marked 'playground' and for f20-x86_64 in a tar.gz, thanks!
18:07:08 <mitr> 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 <sgallagh> Well, it needs to be managed in a way that is fundamentally the same as a package
18:07:28 <notting> 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 <abadger1999> 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 <sgallagh> notting: Which "it". please?
18:07:49 <mattdm> notting +1
18:08:02 <notting> sgallagh: many small repos, sorry.
18:08:06 <sgallagh> ok
18:08:25 <nirik> 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 <notting> under that many-repo proposal, is it anything other than 'a curated set of coprs'?
18:08:39 <mitr> 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 <mitr> If name conflicts were prohibited, the question of 1 repo / multiple repos would, I think, basically disappear
18:10:14 <abadger1999> 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 <notting> 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 <nirik> it may be difficult to detect or prohibit name conflicts.
18:11:20 <mitr> notting: I'm not sure that they are equivalent but AFAIK both are going in the same direction (OBS signing service)
18:11:21 <abadger1999> 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 <abadger1999> I don't know what followup on that question was done this week.
18:11:49 <notting> ok
18:11:55 <mitr> nirik: A git commit hook that limits all binary packages to be $git-repo-name{,-with-optional-suffixes}?
18:12:07 <notting> (i'm good to move on if we want to wait for a specific env-and-stacks query)
18:12:10 <nirik> git commit to what?
18:12:23 <pjones> mitr: problem being coprs are built from a list of urls
18:12:29 <abadger1999> yeah, there's no git commit in coprs.
18:12:39 <mitr> Ah, this doesn't involve dist-git.
18:13:03 <abadger1999> Probably best to talk to env and stacks directly if you're seeing flaws in what they want to design.
18:13:11 <nirik> 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 <jreznik> 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 <abadger1999> mmaslano hasn't been joining us in fesco recently.
18:13:22 <mitr> Yes; move on?
18:13:42 <nirik> ok, moving on...
18:13:47 <sgallagh> abadger1999: She was voted out last cycle
18:14:05 <nirik> #topic #1243 Consider release blocking status of KDE spin(?) for Fedora 21 in .next decision-making
18:14:05 <nirik> .fesco 1243
18:14:05 <nirik> https://fedorahosted.org/fesco/ticket/1243
18:14:06 <zodbot> 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 <nirik> did we wish to defer this further?
18:14:30 <jreznik> we will be ready by next week's fesco meeting
18:14:31 <mattdm> 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 <abadger1999> sgallagh: I know -- but she's the fesco liason to the env and stacks team.
18:14:52 <pjones> nirik: I kind of thought "1-2 weeks" pretty obviously means "2 weeks", yes ;)
18:15:04 <mattdm> pjones lol yes
18:15:17 <nirik> indeed, it always does. Unless it means 3. ;)
18:15:35 <nirik> proposal: defer to next week
18:15:35 <jreznik> pjones: that's why I did not promise 1 week :)
18:15:41 <mattdm> +1 move on
18:16:00 <mattdm> note that there's another mini-thread about this on the devel list too
18:16:13 * nirik nods.
18:16:22 <dgilmore> +1 move on
18:16:23 <nirik> #info more discussion on this on devel list currently
18:16:27 <abadger1999> +1
18:17:26 <nirik> more votes? just one more? ;)
18:17:28 <mitr> +1
18:17:32 <nirik> #agreed defer to next week
18:17:39 <nirik> #topic ticket #1250 F21 Self Contained Changes
18:17:39 <nirik> .fesco 1250
18:17:39 <nirik> https://fedorahosted.org/fesco/ticket/1250
18:17:40 <zodbot> nirik: #1250 (F21 Self Contained Changes) – FESCo - https://fedorahosted.org/fesco/ticket/1250
18:18:22 <nirik> 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 <nirik> and we have new ones this week also there.
18:19:17 <jreznik> also note there are more changes for this week
18:20:06 <hansg> and I'm here in case you've any more questions ...
18:20:13 <nirik> 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 <dgilmore> i am +1 to all three
18:22:02 <mitr> +1
18:22:04 <sgallagh> +1 to all three
18:22:27 <abadger1999> +1
18:22:36 <nirik> #agreed all 3 self contained changes approved. (+7,0,0)
18:22:39 <mattdm> i'm +1 to all three too
18:22:41 <mattdm> sorry
18:22:46 <nirik> #undo
18:22:46 <zodbot> Removing item from minutes: AGREED by nirik at 18:22:36 : all 3 self contained changes approved. (+7,0,0)
18:22:50 <nirik> #agreed all 3 self contained changes approved. (+8,0,0)
18:22:54 <nirik> #topic ticket #1253 requesting exception for linking cscppc and cswrap with glibc-static
18:22:54 <nirik> .fesco 1253
18:22:54 <nirik> https://fedorahosted.org/fesco/ticket/1253
18:22:56 <zodbot> nirik: #1253 (requesting exception for linking cscppc and cswrap with glibc-static) – FESCo - https://fedorahosted.org/fesco/ticket/1253
18:23:19 <pjones> I'm kind of torn no this
18:23:27 <pjones> on the one hand, they could just scrape ldd and copy more libs in
18:23:45 <pjones> but that would also mean more stuff that's not what's being tested going on inside the chroot
18:23:52 <nirik> yeah
18:24:10 <mattdm> (sorry -- note on the last one -- I expect that the plan jwb gives of waiting until 3.15 will be followed)
18:24:39 <pjones> mattdm: yeah, I was taking that as given
18:24:44 <mitr> 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 <pjones> mitr: plugins and whatnot are not covered by the request
18:25:24 <pjones> mitr: in fact it kind of implies there aren't?
18:25:41 <mitr> pjones: I was thinking specifically nss, but that's probably not an issue
18:25:45 <pjones> 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 <nirik> I wonder... could the package build both static and dyanmic?
18:25:48 <pjones> well, okay
18:26:06 <dgilmore> would they expect to use a f21 build version on rhel5?>
18:26:09 <nirik> then at least when the dynamic one needed to be rebuilt they would know to rebuild the static one too
18:26:10 <pjones> nirik: why? either we grant the exception or we don't.
18:26:17 <mitr> 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 <dgilmore> i would think that the version used will have been build on the running OS
18:26:31 <pjones> nirik: that's what we have the magic Requires: for static libs for
18:26:41 <notting> 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 <pjones> er
18:26:54 <pjones> Provides: rather
18:27:00 <pjones> "Provides: bundled(openssl) = 0.9.8w" and similar
18:27:17 <nirik> but these arent libs...
18:27:27 <pjones> o_O
18:27:35 <mitr> 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 <nirik> it only BR's BuildRequires: glibc-static
18:28:17 <pjones> nirik: I think somehow we're completely talking around each other
18:28:29 <pjones> Oh, I see what you're saying, I think.
18:28:32 <nirik> pjones: yeah, could be...
18:28:58 * nirik isn't sure why dgilmore's query isn't true now tho...
18:29:21 <pjones> I mean, yeah, the whole point is that they're pulling the library from the host OS
18:29:33 <notting> 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 <notting> kind of like dockerinit
18:29:41 <nirik> yes, but why?
18:29:51 <nirik> why not install it from the chroot repo?
18:30:05 <dgilmore> nirik: I think I didnt grok things right the first time
18:30:23 <pjones> 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 <dgilmore> I think really the best solution is to have them install the tools from the target os
18:30:27 <nirik> dgilmore: then I am misunderstanding the same way now. ;)
18:30:31 <pjones> rtdl even
18:30:53 <mitr> 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 <mitr> pjones: Yes, bumping symbol versions in glibc happens fairly frequently.
18:32:31 <mitr> 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 <mitr> Anyhow.... proposal: approve exception
18:32:48 <abadger1999> 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 <notting> mitr: #3 is *uuuugh*
18:32:53 <abadger1999> *hang up
18:33:16 <dgilmore> mitr: well glibc in rhel6 and fedora 14 up requires a 2.6.32 kernel
18:33:26 <notting> mitr: i don't see any practical options other than your #1 above, or approving the exception
18:33:47 <mitr> 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 <nirik> mitr: epel?
18:34:01 <abadger1999> mitr: but... epel.
18:34:08 <dgilmore> mitr: mock is in epel,
18:34:14 * mattdm is not fast enough at typing epel
18:34:20 <dgilmore> mitr: we can add the tools to epel
18:34:21 <mitr> dgilmore: Good point.
18:34:38 <pjones> 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 <pjones> mitr: +1
18:34:59 <nirik> proposal: ask why not do option 1 to submittor, revisit next week with their answer?
18:35:06 <abadger1999> nirik: +1
18:35:15 <dgilmore> nirik: +1
18:35:20 <mitr> nirik: Yeah, we should be asking about epel
18:35:20 <abadger1999> 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 <pjones> it /is/ a much higher maintenance burden?
18:35:35 <pjones> but... yeah, okay
18:35:37 <pjones> nirik: +1
18:35:37 <mitr> 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 <dgilmore> 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 <notting> nirik: sure, +1
18:36:24 <pjones> mitr: that's my point, yes.
18:36:50 <nirik> #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 <mattdm> +1
18:37:01 <nirik> #topic ticket #1255 girara+zathura: update policy exception request
18:37:01 <nirik> .fesco 1255
18:37:01 <nirik> https://fedorahosted.org/fesco/ticket/1255
18:37:02 <zodbot> nirik: #1255 (girara+zathura: update policy exception request) – FESCo - https://fedorahosted.org/fesco/ticket/1255
18:37:08 <nirik> sorry mattdm
18:37:09 <mattdm> grr. network problems.
18:37:13 <mattdm> glitchy glitchy
18:37:32 * mattdm is not worried about noncontroversial vote counting
18:37:35 <nirik> +1 this exception.
18:37:52 * pjones +1 too
18:37:57 <mattdm> +1
18:38:12 <mitr> +1
18:38:19 <dgilmore> +1 to the exception
18:38:26 <notting> given the key "there is no software that I know of using girara except zathura. " statement, +1
18:38:47 <pjones> notting: yeah, exactly.
18:39:01 <nirik> #agreed exception granted (+6,0,0)
18:39:02 <abadger1999> +1
18:39:11 <nirik> #topic ticket #1256 non responsive maintainer fast track
18:39:11 <nirik> .fesco 1256
18:39:11 <nirik> https://fedorahosted.org/fesco/ticket/1256
18:39:11 <sgallagh> +1
18:39:12 <zodbot> 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 <mattdm> nirik I'm in favor of meeting speed over accuracy :)
18:39:57 <dgilmore> im okay to fast tracking this
18:39:57 <nirik> :)
18:40:07 <mattdm> +1 fast track
18:40:11 <notting> +1 fast track
18:40:12 <pjones> yeah, +1 here - it's not even non responsive maintainer at this point
18:40:13 <dgilmore> seems based on the comment he doesnt plan to do any fedora work
18:40:17 <pjones> we have confirmation he said we could do it
18:40:25 <mitr> +1
18:40:29 * nirik nods.
18:40:32 <nirik> +1 here
18:40:37 <abadger1999> +1
18:40:40 <dgilmore> +1 to be clear
18:40:47 <notting> pjones: which i suppose makes it less 'fast track' and more just 'using admin powers to do it'
18:41:10 <nirik> #agreed will orphan packages and allow other maintainers to pick things up (+7,0,0)
18:41:19 <nirik> #topic ticket #1257 F21 System Wide Change: u-boot syslinux by default - https://fedoraproject.org/wiki/Changes/u-boot_syslinux
18:41:20 <nirik> .fesco 1257
18:41:20 <nirik> https://fedorahosted.org/fesco/ticket/1257
18:41:22 <zodbot> 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 <nirik> I dunno, who is this dgilmore person anyhow? ;)
18:41:55 <nirik> +1
18:42:04 <pjones> sure, +1
18:42:06 <mattdm> +1
18:42:19 <mitr> +1
18:42:33 <mattdm> especially since pjones is in and syslinux is his package :)
18:42:33 <sgallagh> =1
18:42:34 <abadger1999> +1
18:42:40 <sgallagh> +1, of course
18:42:42 <pjones> mattdm: note that syslinux isn't actually being /used/
18:43:02 <dgilmore> mattdm: its not involving syslinux package
18:43:22 <dgilmore> mattdm: u-boot has its own implementation of syslinux config file parsing
18:43:25 <pjones> mattdm: it's just uboot supporting the config file format and us using that format on the uboot devices
18:43:33 <notting> dgilmore: can we rename the feature to "syslinux-style configuration for u-boot by default", perhaps?
18:43:37 <notting> in any case, +1
18:43:47 <dgilmore> notting: sure.
18:43:50 <nirik> #agreed change approved (+8,0,0)
18:44:09 <nirik> #topic ticket #1258 Coordinate FESCo at Flock 2014
18:44:09 <nirik> .fesco 1258
18:44:09 <nirik> https://fedorahosted.org/fesco/ticket/1258
18:44:10 <zodbot> nirik: #1258 (Coordinate FESCo at Flock 2014) – FESCo - https://fedorahosted.org/fesco/ticket/1258
18:44:22 <sgallagh> 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 <mitr> I hope so
18:45:26 <dgilmore> mitr: its a 2 hour drive, you should  be there :)
18:45:50 <mattdm> sgallagh I assume the Fedora.next.next talk is your proposal?
18:45:55 <sgallagh> mattdm: It is
18:45:58 <jreznik> dgilmore: with that famous highway...
18:46:03 * dgilmore needs to run in 10 minutes to pick up daughter from preschool
18:46:13 <dgilmore> jreznik: improving highways :)
18:46:20 <sgallagh> mattdm: As is the Server one
18:46:38 <mattdm> so, do we want to do what I said in the ticket?
18:46:46 <mattdm> that is, what we did at devconf:
18:46:47 <nirik> sure, sounds fine to me.
18:46:50 <mattdm> I can do an overview of Fedora.next followed by 3-minute-each WG summaries followed by moderated discussion.
18:46:56 <mattdm> Then, later (different day?), "Meet your FESCo" panel.
18:47:00 <sgallagh> mattdm: Yes, I think that was very useful at DevConf
18:47:15 <sgallagh> And Flock is a more targeted audience.
18:47:21 <mattdm> I think that this is _separate_ from the fedora.next.next part -- talk/discussion instead of workshop
18:47:27 <sgallagh> We may want to actually get that booked in keynote space, actaully
18:47:30 <mattdm> is that clear enough?
18:47:45 <Viking-Ice> interesting...
18:48:17 <mattdm> sgallagh do you want to moderate the panel discussion again, or does anyone else want to raise their hand for that?
18:48:18 <nirik> anyhow, mattdm: +1
18:48:25 <sgallagh> mattdm: I'll volunteer
18:48:55 <pjones> that actually raises an interesting question
18:49:10 <sgallagh> pjones: What does?
18:49:19 <pjones> given the f21 schedule, I forget - have we made plans for an intervening election /before/ then?
18:49:23 <pjones> sgallagh: meet your fesco
18:49:43 <mattdm> sgallagh do you want to submit the panel part? I can do both, I just don't want mid-air collisions
18:49:53 <dgilmore> pjones: not seen any plans for an election
18:49:58 <mattdm> and likewise should i submit Meet Yor FESCo?
18:50:00 <nirik> pjones: not that I am aware of. We may want to discuss that (seperate from this)
18:50:19 <pjones> 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 <dgilmore> abadger1999: if so was before me
18:51:14 <nirik> we may want to look back for that discussion...
18:51:32 <sgallagh> 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 <sgallagh> That'll make it easier to schedule together as well
18:52:00 <mattdm> 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 <sgallagh> 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 <mattdm> #action mattdm will talk to flock planners about scheduling fedora.next talk and discussion as keynote
18:52:37 <nirik> (or not too many of them)
18:52:53 <sgallagh> nirik: I'm talking about the .next review and panel
18:53:08 <mattdm> I'm also okay with  meet-your-fesco as not keynote
18:53:12 <nirik> yeah, ok... I was replying to the "schedule together" part.
18:53:21 <mattdm> so people who don't care about politics have something to do.
18:53:41 <mattdm> is anyone else itching to submit the meet your fesco proposal?
18:53:43 <sgallagh> nirik: The talk and discussion should be back-to-back. That's what I meant about scheduling them together
18:53:45 <mattdm> otherwise i will do it.
18:53:48 <sgallagh> Sorry, too many conversations at once
18:54:04 <nirik> sgallagh: ah, ok. I saw that as 'one thing'
18:54:17 <mattdm> nirik there are three things. two of them are one.
18:54:25 <nirik> clear as mud
18:54:42 <nirik> anyhow, anything else we want to discuss here? or vote on? or shall we move on?
18:54:58 <mattdm> #action mattdm will also schedule fesco panel
18:55:12 <sgallagh> AFter the schedule is announced, we should coordinate attendance at key talks
18:55:19 <sgallagh> But that's obviously for later
18:55:22 <nirik> yeah.
18:55:27 <dgilmore> moving on?
18:55:35 <nirik> #topic ticket #1259 F21 System Wide Change: jQuery - https://fedoraproject.org/wiki/Changes/jQuery
18:55:35 <nirik> .fesco 1259
18:55:35 <nirik> https://fedorahosted.org/fesco/ticket/1259
18:55:36 <zodbot> nirik: #1259 (F21 System Wide Change: jQuery - https://fedoraproject.org/wiki/Changes/jQuery) – FESCo - https://fedorahosted.org/fesco/ticket/1259
18:56:03 <mattdm> 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 <nirik> it's gonna be a lot of work yeah...
18:56:23 <mattdm> good luck to them :)
18:56:25 <nirik> but sure, +1
18:56:26 <mattdm> so +1
18:56:27 <mitr> +1
18:56:30 <sgallagh> +1
18:56:32 <dgilmore> +1 same thoughts
18:56:47 * dgilmore needs to run and pick up daughter, back in 15 minutes
18:56:55 <notting> +1
18:57:25 <abadger1999> +1
18:57:36 <nirik> #agreed change is approved (+7,0,0)
18:57:43 <nirik> #topic ticket #1260 F21 System Wide Change: Xorg without root rights - https://fedoraproject.org/wiki/Changes/XorgWithoutRootRights
18:57:43 <nirik> .fesco 1260
18:57:43 <nirik> https://fedorahosted.org/fesco/ticket/1260
18:57:44 <zodbot> 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 <nirik> +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 <mattdm> +1 awesome
18:57:56 <abadger1999> +1
18:58:00 <mitr> +1
18:58:05 <pjones> I've actually got some questions about this
18:58:15 <notting> lots of question marks in the the dependencies section. but +1 to the idea.
18:58:39 <pjones> 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 <pjones> (sorry, only came up with these right before the meeting or I'd have asked them in the ticket.)
18:59:15 <nirik> 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 <pjones> that too
18:59:34 <pjones> so proposal: give this another week and nirik and I will ask those things on the ticket?
18:59:42 <jreznik> hansg: still here?
18:59:49 <pjones> or if he's around that'll work too
19:00:37 <nirik> it may be the wrapper is needed for startx? not sure, but yeah, good to know.
19:01:10 <mattdm> i'm okay with waiting another week for more info
19:01:25 <hansg> jreznik, yes
19:01:25 <pjones> 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 <mattdm> 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 <hansg> pjones, nope. systemd is not involved in starting X at all
19:02:32 <nirik> pjones: you might be thinking of the breakage on vt switch?
19:02:42 <hansg> X talks to systemd-logind over dbus, and logind hands it fds for things like keyboard mouse and /dev/dri/card0
19:03:36 <pjones> 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 <hansg> 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 <pjones> (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 <hansg> pjones, you're talking about X modules here ?
19:04:13 <pjones> yes
19:05:24 <hansg> 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 <mitr> pjones: I'd expect the current setuid X to not allow arbitrary modules either
19:05:48 <hansg> 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 <pjones> mitr: yeah, I'm just wanting to make sure that this hasn't really changed that
19:06:29 <hansg> WRT arbitrary modules only modules in %{libdir}/xorg/modules are ever loaded
19:06:39 <pjones> 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 <pjones> alright, as long as that's still the case I've got no major concerns.
19:07:13 <nirik> ok, we are at +5 then I guess?
19:07:18 * pjones +1
19:07:22 <sgallagh> +1
19:07:31 * notting is/was +1
19:07:35 <hansg> 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 <nirik> 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 <nirik> (well, when it's ready for that obviously)
19:08:24 <hansg> 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 <nirik> #agreed change approved (+7,0,0)
19:08:41 <nirik> hansg: cool. or just the change wiki page is fine.
19:09:05 <nirik> #topic Chair next week
19:09:09 <nirik> who wants it?
19:09:34 <mitr> I haven't been a chair in a while, I'll take it
19:09:46 <sgallagh> I may not be around next week, but I'll take it on the 2nd
19:09:46 <nirik> thanks mitr
19:09:54 <nirik> #info mitr to chair next week
19:10:13 <nirik> #info sgallagh wants to chair the following week.
19:10:19 <nirik> #topic Open Floor
19:10:23 <nirik> any items for open floor?
19:10:30 <abadger1999> I think I found the elections discussion
19:10:43 <abadger1999> It was for the post-f20 election rather than the post-f21 election.
19:11:47 <nirik> 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 <mattdm> abadger1999 we tend to never make long term decisions when solving the immediate issue will do :)
19:12:48 <notting> wouldn't this be, in some way, a project decision, not a fesco one?
19:13:02 <abadger1999> 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 <nirik> yeah, oddly fesco has controlled it's own election policy, which may well be unwise... ;)
19:13:21 <nirik> but we could ask the board.
19:13:33 <abadger1999> fesco predates the board... likely why things are that way.
19:13:37 <dgilmore> and back
19:14:24 <pjones> abadger1999: right, the discussion was actually for the election we just /had/
19:14:38 <pjones> but we didn't realize that the schedule was likely to make a time-based election schedule include /another/.
19:14:39 <abadger1999> <nod>
19:15:32 <nirik> abadger1999: I think I am in the same camp, but wider discussion would probibly be good.
19:15:41 <abadger1999> <nod>
19:15:41 * jreznik thinks elections should be and are release based
19:15:44 <pjones> Maybe we should, I dunno, ask our constituents?
19:15:59 <pjones> 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 <jreznik> pjones: last one was still scheduled based on the rules...
19:17:06 <jreznik> that delay was organization failure (/me was part of)
19:17:41 <mitr> yeah, shall we file a ticket and give us time to review and discuss the history and think about the options?
19:17:50 <abadger1999> mitr: +1
19:18:01 <nirik> yep. +1
19:18:34 * jreznik can coordinate it with board/broader community
19:18:36 <sgallagh> mitr: +1
19:20:05 <notting> mitr: sounds good
19:20:15 <nirik> who's doing the ticket filing? ;)
19:20:56 <nirik> I guess I can. ;)
19:21:12 <nirik> any other open floor items? or can we call it a meeting?
19:21:42 <dgilmore> I have nothing
19:22:21 <nirik> alright. Thanks for coming everyone!
19:22:23 <nirik> #endmeeting