=================================== #fedora-meeting: FESCO (2011-04-27) =================================== Meeting started by nirik at 17:30:01 UTC. The full logs are available at http://meetbot.fedoraproject.org/fedora-meeting/2011-04-27/fesco.2011-04-27-17.30.log.html Meeting summary --------------- * init process (nirik, 17:30:01) * #585 Plan date for dist-git branch renames (nirik, 17:33:15) * ACTION: 2011-05-10 scheduled for the change. (nirik, 17:42:03) * #515 Investigate a "features" repo for stable releases (nirik, 17:44:43) * #563 suggested policy: all daemons must set RELRO and PIE flags (nirik, 17:48:25) * Open Floor (nirik, 17:49:48) Meeting ended at 18:26:42 UTC. Action Items ------------ * 2011-05-10 scheduled for the change. Action Items, by person ----------------------- * **UNASSIGNED** * 2011-05-10 scheduled for the change. People Present (lines said) --------------------------- * cwickert (71) * nirik (65) * mjg59 (49) * gholms (22) * Oxf13 (19) * mclasen (18) * notting (16) * ajax (8) * zodbot (7) * mmaslano (2) * rsc (2) * rwmjones (1) * SMParrish (0) * kylem (0) -- 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
Attachment:
signature.asc
Description: PGP signature
-- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
