17:30:01 <nirik> #startmeeting FESCO (2011-04-27)
17:30:01 <zodbot> Meeting started Wed Apr 27 17:30:01 2011 UTC.  The chair is nirik. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:30:01 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
17:30:01 <nirik> #meetingname fesco
17:30:01 <zodbot> The meeting name has been set to 'fesco'
17:30:01 <nirik> #chair mclasen notting nirik SMParrish kylem ajax cwickert mjg59 mmaslano
17:30:01 <nirik> #topic init process
17:30:01 <zodbot> Current chairs: SMParrish ajax cwickert kylem mclasen mjg59 mmaslano nirik notting
17:30:39 <mjg59> Afternoon
17:30:48 * notting is here
17:31:34 * mmaslano here
17:31:38 <ajax> come on party people, throw your hands in the air
17:31:54 <gholms> Going to go for the third <20m meeting in a row?
17:32:01 <ajax> yesplz
17:32:06 <nirik> I think they are nice, yes. ;)
17:32:13 <mjg59> As long as nobody brings up systemd
17:32:13 * mclasen is here
17:32:21 <gholms> mjg59: Shh!  :P
17:32:21 <mjg59> (Oh no!)
17:32:47 <nirik> cwickert said he would be a bit late...
17:33:11 <nirik> lets start with an easy one:
17:33:15 <nirik> #topic #585 Plan date for dist-git branch renames
17:33:15 <nirik> .fesco 585
17:33:17 <zodbot> nirik: #585 (Plan date for dist-git branch renames) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/585
17:33:59 <mjg59> Oxf13: You around?
17:34:03 <nirik> this looks like a short outage. I'm happy to have it done whenever.
17:34:08 <nirik> sooner better than later I guess.
17:34:17 <Oxf13> that I am
17:34:40 <Oxf13> the outage is short, what I'm looking for is guidance and thought on how long we should wait for the proper fedpkg packages to "soak" in stable
17:34:48 <Oxf13> for a reasonable amount of people to have them installed
17:34:57 <mjg59> Oxf13: Are they in every relevant release now?
17:35:05 <ajax> f15 final change deadline is May 9
17:35:11 <Oxf13> I do also need to create or have help creating a wiki landing page that we can direct people to to help them through the transition.
17:35:24 <Oxf13> mjg59: I believe they're still in testing for el5/6
17:35:32 <ajax> so, presumably, that would be a point after which nobody needs to use git to fix things for f15
17:35:36 <Oxf13> but went stable elsewhere lastweek/this week
17:35:55 <mjg59> Oxf13: tbh, I don't think there's any real soak test required if the code is already available to people
17:36:03 <mjg59> They're not going to be pushing to git unless they have network access...
17:36:06 <Oxf13> unfortunately I'm buried this week trying to finish a presentation for a conference.
17:36:17 <Oxf13> mjg59: that is true.
17:36:27 <mjg59> So I'm happy with it once they're stable everywhere
17:36:33 <Oxf13> and push attempts to the old path will be stopped by the ACL system, pointing them to a wiki page
17:36:35 * notting would prefer after f15 is frozen
17:36:40 <Oxf13> said wiki page would say "Download the update, run the fixbranches"
17:36:55 <mjg59> If there's any other infrastructure outages in the near future then doing it alongside one of them would be nice
17:36:55 <mclasen> we just want to avoid changing branch names before the fixed fedpkg is available via yum update on all releases, I guess
17:37:28 <nirik> well, I am hoping to have an outage next week on db01 to upgrade/move to new hardware.
17:37:50 <ajax> notting: may 10 then?
17:38:00 <nirik> that would affect wiki/smolt/wordpress/zarafa... so not really related to this. ;)
17:38:29 <Oxf13> heh
17:38:29 <notting> ajax: something like that, yes.
17:38:39 <Oxf13> the mid-may timeline is fine by me.
17:38:56 <Oxf13> gives me time to create/polish the wiki page and the patch to the ACL system.
17:39:17 <nirik> note that that is in infrastructures change freeze, but we can get an exception for it. ;)
17:39:27 <Oxf13> nod
17:39:34 * cwickert is here
17:39:53 <nirik> so, shall we tenatively say 10th? or thats summit, and go later in that week?
17:40:06 <nirik> no, thats the week before, nevermind
17:40:31 <ajax> 10th.
17:40:58 <mclasen> +1
17:41:07 <mjg59> +1
17:41:28 <notting> +1
17:41:31 <mmaslano> +1
17:41:37 <Oxf13> worksforme
17:41:53 <nirik> ok, cool.
17:42:03 <nirik> #action 2011-05-10 scheduled for the change.
17:42:18 <nirik> anything more on this topic?
17:43:06 <Oxf13> just a note
17:43:28 <Oxf13> that after this, there won't likely be any feature development on fedpkg for a while, as I'll be working on a massive overhaul to make it work with multiple sites
17:43:41 <Oxf13> (to use it in part for the internal Red Hat infrastructure)
17:43:52 <Oxf13> I'll still do bugfixes though.
17:44:15 <nirik> ok, thanks for all the work on it. ;)
17:44:43 <nirik> #topic #515 Investigate a "features" repo for stable releases
17:44:43 <nirik> .fesco 515
17:44:44 <zodbot> nirik: #515 (Investigate a "features" repo for stable releases) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/515
17:44:47 <nirik> cwickert: any news on this one?
17:44:53 <cwickert> nope
17:44:54 <cwickert> :(
17:45:21 <rsc> nirik: is this EPEL or Fedora?
17:45:32 <nirik> fedora.
17:45:34 <rsc> ok
17:45:52 <nirik> althought I suppose a similar setup could be used in epel perhaps.
17:46:15 <cwickert> once we have resolved the issues
17:46:30 <nirik> right
17:46:39 <cwickert> the biggest problem is how to resolve BuildRequires
17:46:57 <cwickert> I'm afraid we will run into a lot of buildroot overwrite requests
17:47:05 <cwickert> and cause a lot of work for rel-eng
17:47:38 <nirik> well, work is ongoing to automate/self service those. ;)
17:47:44 <nirik> hopefully that will land soon.
17:47:55 <cwickert> cool
17:48:11 <nirik> anyhow, moving on I guess...
17:48:11 <cwickert> in this case one of my biggest problems is solved
17:48:17 <cwickert> yeah, lets move
17:48:18 <nirik> cool. ;)
17:48:25 <nirik> #topic #563 suggested policy: all daemons must set RELRO and PIE flags
17:48:25 <nirik> .fesco 563
17:48:29 <zodbot> nirik: #563 (suggested policy: all daemons must set RELRO and PIE flags) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/563
17:48:29 <nirik> no kylem...
17:48:39 <nirik> so, I guess we are still waiting for data here.
17:49:48 <nirik> #topic Open Floor
17:49:53 <nirik> ok, anything for open floor?
17:50:14 <gholms> So much for a sub-20m meeting.
17:50:36 <nirik> will try harder next time. ;)
17:50:40 <gholms> Heh
17:50:50 <gholms> This time there was actually a topic with news.
17:51:38 <nirik> so, f15 is coming closer... how does everyone feel about it's readyness? :) Looking ok?
17:51:56 <mjg59> Shell is in a much better state than I expected
17:52:17 <ajax> i've got a few things in mesa still to shake out, but i'm reasonably confident in them
17:52:42 <ajax> if anyone wants to help me out with that, https://admin.fedoraproject.org/updates/llvm-2.8-11.fc15 could use some love
17:52:53 <gholms> Anyone have any thoughts/opinions about the fact that one can't remove packagekit any more without ripping out the entire desktop stack?
17:53:26 * cwickert thinks that F15 will be the worst release ever
17:53:35 <cwickert> gholms: good point
17:53:39 <nirik> sadly, deps sometimes grow... but I haven't looked at that case.
17:53:51 <cwickert> it could be fixed easily
17:53:51 <nirik> cwickert: why so?
17:54:04 <cwickert> because of the gnome fallout on all of us
17:54:08 <mclasen> gholms: I think thats just fine
17:54:24 <nirik> ah. I think the fallout is somewhat overblown, but I guess we will see.
17:54:40 <nirik> anyhow, if nothing else, will close out the meeting in a minute.
17:54:51 <mjg59> If it's resulting in non-gnome environments ending up with lots of gnome, that's a problem. If it's resulting in gnome environments requiring packagekit, I don't think that's a problem at all.
17:55:02 <cwickert> take the look of GTK3 vs. GTK2 for example
17:55:33 <cwickert> or the fact that we have no update notifications in Xfce and LXDE because of the changes in libnotify
17:55:33 <gholms> Thanks for sharing your thoughts on that, people.
17:55:42 <mclasen> mjg59: that is true
17:56:14 <cwickert> all: for the packagekit bug please see https://bugzilla.redhat.com/show_bug.cgi?id=699348
17:56:16 <nirik> cwickert: :( I thought panu had a patch to help with that, but I guess it never went to a conclusion.
17:56:34 <cwickert> and for background discussion https://bugzilla.redhat.com/show_bug.cgi?id=699263
17:57:08 <cwickert> nirik: panu didn't write a patch but a new update notification icon for Xfce
17:57:18 <mclasen> cwickert: if it was up to me, I'd close that notabug
17:57:35 <cwickert> mclasen: then look at the number of people cc please
17:57:39 <mclasen> the updates plugin is not an optional part of g-s-d
17:58:04 <cwickert> mclasen: why not? why can it not be packaged separately?
17:58:22 <cwickert> and what is the use of the plugin if gnome-packagekit is not installed?
17:58:43 <mclasen> the plugin gives you notification about available updates
17:58:59 <cwickert> and then? how to install them without gnome-packagekit?
17:59:29 <mjg59> If there's no impact on non-gnome environments then I don't think this is a fesco issue and I don't think we need to discuss it here
17:59:41 <notting> surely the fix is that PackageKit-glib should not require PackageKit (c.f. NetworkManager-glib?
18:00:08 <cwickert> mjg59: there is, other spins are using gdm for example and gdm requires g-s-d
18:00:11 <mclasen> mjg59: there is indirect impact via g-s-d running in the gdm login session
18:00:33 <mjg59> Ok, then there's an argument for working out some way to relax that constraint
18:00:42 <mclasen> not sure how many non-gnome spins still use gdm, though
18:00:49 <cwickert> at least one, Xfce
18:01:25 <mjg59> But the right way to fix this isn't to dictate that the maintainer removes something that they feel is a dependency
18:01:28 <cwickert> the plugin should be in gnome-packagekit and not in g-s-d, but this is something that needs to happen in GNOME 3.2 upstream
18:01:58 <mjg59> So if people want to work with upstream on that, I think that makes sense
18:02:10 <cwickert> mjg59: the dependency is only half of what we need. strictly speaking we need to have a dep on gnome-packagkit, too
18:02:12 <notting> cwickert: how so? perhaps the fix is a different update UI in 3.2 that doesn't use gpk?
18:02:27 <mjg59> What does the overhead end up being?
18:02:36 <mjg59> ie, how much of gnome gets pulled in?
18:03:09 <cwickert> not much GNOME but PackageKit
18:03:14 <mjg59> Oh
18:03:18 <mjg59> Well, that doesn't seem so bad
18:03:48 <cwickert> well, but pulling in PackageKit is only half of what we need because we also need gnome-packagekit
18:04:01 <cwickert> and people don't want that
18:04:08 <notting> huh?
18:04:14 * notting didn't parse that
18:04:23 <cwickert> ok, lemme explain again
18:04:48 <cwickert> the updates plugin of g-s-d is useless without gnome-packagkit
18:04:54 <cwickert> so we need to require it
18:05:02 <cwickert> understood?
18:05:30 <mjg59> So g-s-d should require gnome-packagekit?
18:05:45 <cwickert> no, my suggestion is: have the updates plugin be a sub-package of g-s-d and that package can then require gnome-packagekit
18:05:52 <cwickert> everybody happy then
18:05:55 <mjg59> Why is this better?
18:06:00 <cwickert> and no changes upstream required
18:06:21 <gholms> mjg59: Then the xfce spin doesn't end up with gnome-packagekit?
18:06:25 <nirik> some people want just g-s-d and some people want the updates plugin + gnome-packagekit?
18:06:36 <mjg59> gholms: And why is that a problem?
18:06:40 <cwickert> mjg59: because we git rid of the dep on PackageKit for the people who don't want it and can add a dep on gnome-packagekit for those who want it
18:06:56 <mjg59> I'm trying to work out why "The people who don't want it" is something we care about in the slightest
18:07:01 <gholms> mjg59: Doesn't it drag in a bunch of other gnome deps?
18:07:05 <cwickert> gholms: the Xfce spin has gnome-packagekit anyway
18:07:13 <mjg59> Who are these people? What are they trying to accomplish?
18:07:14 <gholms> Oh, cool.
18:07:29 <cwickert> mjg59: because there are quite a number of them and some of them are honored Fedora Red Hat developers
18:07:33 * notting notes that PackageKit itself is pulled into @base
18:07:40 <mjg59> Could a precise description of actual real problems other than "We have packagekit installed and don't want it" be made?
18:08:01 <mjg59> Because if it's just that, I don't think this is our problem at all
18:08:07 <cwickert> mjg59: we install something that does not work
18:08:18 <mjg59> Why does it not work?
18:08:37 <cwickert> it does not work for the people who don't have gnome-packagekit installed
18:08:48 <mjg59> So it should depend on gnome-packagekit?
18:08:58 <gholms> If the problem is just that the deps are wrong you can bring that up with the maintainer.
18:09:01 <nirik> cwickert: so, the people who want to install g-s-d but DON't want gnome-packagekit are who?
18:09:07 <cwickert> mjg59: only the sub-package
18:09:09 <nirik> or why is better
18:09:14 <mjg59> cwickert: There is no sub-package
18:09:18 <gholms> nirik: Hi, I'm one of those people.
18:09:28 <cwickert> nirik: people like gholms or rwmjones
18:09:29 <mjg59> cwickert: I'm asking what the *current* problem is
18:09:34 <nirik> ok, why?
18:09:40 <nirik> whats the usage?
18:10:04 <cwickert> mjg59: the current problem is that if you install g-s-d you don't necessarily get gnome-packagekit
18:10:19 <nirik> which could be fixed by adding a dep
18:10:32 <mjg59> cwickert: Right, so g-s-d should depend on gnome-packagekit.
18:10:44 <mjg59> cwickert: What problem does that result in?
18:10:58 <cwickert> that people DO NOT WANT it
18:11:09 <mjg59> I don't give a fuck whether people want it or not
18:11:12 <mjg59> What problem does it cause?
18:11:25 <cwickert> there are several package managers out there, why should we force people to install one?
18:11:36 <mjg59> Because that's the one that the entire gnome platform is based around
18:11:49 <mjg59> I can't swap out gtk with qt, either
18:11:52 <nirik> they wish gnome-settings-daemon, but not gnome-packagekit?
18:12:07 <cwickert> mjg59: GNOME is not *based* on gnome-packagekit
18:12:10 <nirik> I don't doubt there could be a use case here, I just don't understand what it is.
18:12:11 <mjg59> We don't cater to everyone's requirements
18:12:17 <notting> mjg59: potentially an issue for users of g-s-d without the updates plugin enabled (gdm session, live users)
18:12:22 <gholms> nirik: I don't want PK to grab the yum lock whenever it decides to update itself or to show me any GUI notifications.
18:12:28 <cwickert> you cannot compare GTK to gnome-packagekit
18:12:39 <gholms> nirik: For all I know those are fixable with config, but historically I've fixed those by removing PK.
18:12:46 <mjg59> cwickert: The gnome maintainers have decided that gnome-packagekit is part of their platform
18:12:53 <mjg59> That's their decision to make
18:13:01 <nirik> gholms: ok, and you are running gnome or gdm?
18:13:03 <notting> gholms: try disabling the service?
18:13:07 <cwickert> mjg59: upstream or downstream?
18:13:13 <gholms> nirik: Yep
18:13:15 <mjg59> cwickert: Either
18:13:38 <rwmjones> mjg59: basically if we could make packagekit not run (don't really care if it's installed), that would be good
18:13:39 <mjg59> If it's a decision that our maintainers agree with, I definitely see no reason to attempt to overrule them
18:14:11 <cwickert> I think saying that GNOME is based on PackageKit is nonsense. There are other package managers out there and most distributions don't even ship PackageKit
18:14:21 <cwickert> it is an optional component
18:14:33 <cwickert> and it could be made optional with a little change in packaging
18:14:34 <nirik> ok, so that makes sense. So subpackaging out the part that deps on gnome-packagekit would be a solution, or alternately have a way to disable gnome-packagekit from running easily if it's installed.
18:14:41 <mjg59> Anyway, I see nothing here for fesco to rule on
18:15:02 <gholms> nirik: Either of those would perfectly fine with me.
18:15:09 <cwickert> mjg59: cutting dependency bloat is a fesco effort
18:15:14 <nirik> right, it's down to convincing the owners...
18:15:16 <gholms> I would be underinformed, for all I know.
18:15:21 <gholms> *could
18:15:26 <mjg59> cwickert: Where dependency bloat causes real problems, yes. I see no real problems here.
18:15:40 <notting> cwickert: http://git.gnome.org/browse/jhbuild/tree/modulesets/gnome-suites-core-3.0.modules
18:15:47 <mjg59> "I want to be able to configure packagekit not to run" seems like a valid discussion to have with the maintainer
18:15:49 <cwickert> mjg59: but there is quite a lot of people who disagree with you
18:15:55 <mjg59> cwickert: And they're wrong and I'm right
18:16:05 <cwickert> ah, sorry, I forgot this
18:16:11 <notting> cwickert: gnome-packagekit is in the core gnome 3 modules
18:16:17 <nirik> I'd suggest we should talk with maintainers and try and advocate for one of those 2 things...
18:16:22 <notting> cwickert: so, saying it's based on it is *not* nonsense
18:16:37 * gholms reluctantly agrees with mjg59
18:17:15 <notting> nirik: you could also drop the dependency between PackageKit-glib and PackageKit; this would allow PK to be removed, while keeping the plugin around
18:17:28 <mjg59> cwickert: It's not fesco's job to second guess decisions of maintainers unless those decisions have a significant impact upon the rest of the distribution
18:17:36 <cwickert> notting: it is *included* in the default selection but not *based*. we don't ship other modules either
18:17:53 <mjg59> Where that effect is limited to "I have some packages installed and I don't use them" I really don't think it's up to us to overrule decisions
18:18:28 <cwickert> so what is so bad about my proposed solution? does it hurt anybody?
18:18:32 * nirik thinks more discussion with maintainers should be done. If nothing at all can be worked out, revisit if needed.
18:18:41 <cwickert> does it cause problems for anybody?
18:18:46 <nirik> cwickert: I don't think so...
18:19:01 <mjg59> cwickert: I have no problem with that solution if the maintainers choose to implement it. But I strongly disagree with it being something that we should attempt to enforce.
18:19:34 <cwickert> it is a fact that especially our GNOME maintainers don't give much about the rest of the distribution
18:19:35 <gholms> mjg59: The question for me is more along the lines of "PK introduces delays when I want to run yum."  If that's fixable with a config file that's fine with me, but if I can't stop that from happening it's a distro integration problem fesco has to address.
18:20:20 * nirik doesn't in fact see any comment yet from the owner on that issue...
18:20:51 * mclasen was away for a bit, sorry
18:21:03 <gholms> nirik: Most of the discussion is in bug 699263.
18:21:20 * nirik looks.
18:21:26 <cwickert> I think we are facing a deeper problem here: what if developers don't give much about user requests? it's not the first time that the developer completely ignores what people say
18:21:45 <mclasen> cwickert: 'what people say'
18:21:51 <mclasen> you are just unhappy that we ignore you :-)
18:22:09 <cwickert> mclasen: no, I am unhappy that *many* people get ignored
18:22:21 <gholms> They do?
18:22:21 <cwickert> not only in Fedora but also in other bug trackers
18:22:38 <cwickert> take a look at https://bugzilla.redhat.com/show_bug.cgi?id=485846
18:22:43 <cwickert> same maintainer/developer
18:23:01 <cwickert> and the complainants are not only in our bugzilla but also in GNOME's or in launchpad
18:23:26 <cwickert> and the very same maintainer also introduced installation of packages for non-root users
18:23:33 <mclasen> same complainer too
18:23:56 <cwickert> mclasen: but at least I have people supporting me, richard doesn't
18:24:02 <notting> FESCo is not an I DON'T LIKE WHAT UPSTREAM IS DOING MAKE THEM DO WANT I WANT button
18:24:08 * mclasen not very interested in this level of discussion
18:24:17 <mclasen> I agree that we have a practical problem with the gdm dependencies
18:24:25 <mclasen> send a patch and we'll get it solved
18:24:37 <cwickert> ok
18:24:45 <nirik> I think there are some valid usecases that would be served by subpackaging the updates plugin in g-s-d.
18:25:08 <nirik> at least until a better upstream solution is created.
18:25:09 * mclasen has done package splits for xfce that he personally disagreed with before
18:25:39 <nirik> great, so, lets communicate and solve things and close out the meeting?
18:25:50 * nirik doesn't see any fesco action items here. ;)
18:26:14 <cwickert> ok, lets stop this discussion here,
18:26:27 <cwickert> thanks everybody for their time, I really don't want to waste it
18:26:31 <nirik> ok, thanks for coming everyone.
18:26:42 <nirik> #endmeeting