Summary/Minutes for todays FESCo meeting (2010-04-13)

Kevin Fenzi kevin at
Tue Apr 13 20:46:57 UTC 2010

#fedora-meeting: FESCO (2010-04-13)

Meeting started by nirik at 19:00:09 UTC. The full logs are available at

Meeting summary
* init process  (nirik, 19:00:09)

* #351 Create a policy for updates  (nirik, 19:02:54)
  * LINK:
    defines the set of things that should be considered critical path.
    (nirik, 19:10:56)
  * LINK:
    (nirik, 19:19:41)
  * AGREED: add critical-path-group-<desktop> groups to comps,
    SIGs/releng can populate as needed in regards to the criteria
    already laid down.  (nirik, 19:28:34)
  * AGREED: submitter's vote does not count  (nirik, 19:43:23)
  * AGREED: updates can set the karma level to +1  (nirik, 19:50:14)

* #363 Proposal: auto sign pkgs in koji  (nirik, 19:55:27)
  * AGREED: the proposal is approved.  (nirik, 20:14:14)

* FES tickets update  (nirik, 20:14:35)
  * LINK:
    (nirik, 20:15:26)

* F13 Beta  (nirik, 20:21:01)

* Open Floor  (nirik, 20:22:38)
  * AGREED: Discussion on devel list to try and solve metacity deps in
    anaconda and firstboot  (nirik, 20:32:15)
  * LINK:   (skvidal, 20:35:09)
  * skvidal re-ran the potentially unmaintained script again, results at  (nirik, 20:35:21)
  * LINK:
    (skvidal, 20:38:00)
  * LINK:
    (cwickert, 20:39:12)
  * LINK:
    (cwickert, 20:39:22)

Meeting ended at 20:44:38 UTC

19:00:09 <nirik> #startmeeting FESCO (2010-04-13)
19:00:09 <nirik> #meetingname fesco
19:00:09 <zodbot> Meeting started Tue Apr 13 19:00:09 2010 UTC.  The chair is nirik. Information about MeetBot at
19:00:09 <nirik> #chair dgilmore notting nirik skvidal Kevin_Kofler ajax pjones cwickert mjg59
19:00:09 <nirik> #topic init process
19:00:10 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
19:00:13 <zodbot> The meeting name has been set to 'fesco'
19:00:14 <zodbot> Current chairs: Kevin_Kofler ajax cwickert dgilmore mjg59 nirik notting pjones skvidal
19:00:18 * skvidal is here
19:00:20 * cwickert is here
19:00:50 <Kevin_Kofler> Present.
19:00:57 <pjones> oh crap it is that time again.
19:01:05 * notting is here
19:02:23 <nirik> I guess we have 6 folks, so can go ahead and start in.
19:02:54 <nirik> #topic #351 Create a policy for updates
19:03:07 <nirik> I added some outstanding questions from implementation to the ticket.
19:03:11 <mjg59> Here
19:03:27 <nirik> Kevin_Kofler: you noted that @kde-desktop is big... is there a subset of that that would be good to consider instead?
19:04:15 <ajax> i think so, brain, but if we didn't have ears we'd look like weasels.
19:04:27 <Kevin_Kofler> Well, kdebase-workspace, kdm and their deps might be a starting point.
19:04:44 <Kevin_Kofler> (That'll also include kdelibs and kdebase-runtime.)
19:04:51 <Kevin_Kofler> I'll also note that even that set includes many, many libs.
19:04:51 <cwickert> also kicker?
19:04:59 <Kevin_Kofler> There's no more kicker.
19:05:03 <cwickert> erm, sry
19:05:04 <Kevin_Kofler> It's Plasma and it's part of kdebase-workspace.
19:05:07 <cwickert> ok
19:05:14 <nirik> notting: have you had a chance to look anymore about how we populate critpath? or were you still looking at that?
19:05:25 <Kevin_Kofler> For example, deps of kdebase-workspace include even eet.
19:05:43 <Kevin_Kofler> kdebase-workspace requires qedje (optional dep, but compile-time optional) and qedje requires eet.
19:05:53 <nirik> .fesco 351
19:05:55 <zodbot> nirik: #351 (Create a policy for updates) - FESCo - Trac -
19:06:02 <cwickert> Kevin_Kofler, I think that kdeplasma-addons is also necessary, without you have no desktop
19:06:15 <notting> nirik: i know how we populate it. we can set a group for kde like we have for gnome now.
19:06:21 <Kevin_Kofler> Uh, plasma-desktop works fine without kdeplasma-addons.
19:06:29 <Kevin_Kofler> Only plasma-netbook requires (parts of) it.
19:06:36 <cwickert> Kevin_Kofler, it didn't start for me
19:06:39 <nirik> notting: and for xfce/lxde as well?
19:06:49 <Kevin_Kofler> We usually don't ship kdeplasma-addons on live images for space reasons.
19:06:54 <nirik> so, they could be seperate? or would be part of crit-path?
19:06:54 <Kevin_Kofler> They still work fine.
19:07:33 <notting> nirik: either or. we can calculate new crit-path to include those functionalities for lxde/xfce. it's just a comps tweak.
19:07:52 <Kevin_Kofler> That said, a bug in kdeplasma-addons, or any other plasmoid for that matter, CAN crash the entire plasma-desktop.
19:08:14 <Kevin_Kofler> Plasmoids run in process.
19:08:20 <Kevin_Kofler> (at least C++ plasmoids)
19:08:21 <nirik> if we just put all these in critpath, it's easier to implement. If we want them to be a seperate "important packages" set, it will require some changes in bodhi/pkgdb
19:08:34 <skvidal> sorry my network just fell over
19:08:38 <skvidal> did anyone ping at me?
19:08:42 <pjones> okay, so why's there not a comps group for this?
19:08:59 <nirik> pjones: for which?
19:09:04 <notting> pjones: there is, for the older definition of critical-path
19:09:07 <nirik> skvidal: just to join the meeting. ;)
19:09:12 <skvidal> nirik: okay - good
19:09:35 <pjones> nirik: "the things we want from kde in this set", I guess?
19:10:28 <nirik> well, first question: Should we just add everything we want in 'Important packages' to critical path? Or should we have another group seperate of critical path for this?
19:10:42 <skvidal> well per-spin critpaths?
19:10:56 <nirik> defines the set of things that should be considered critical path.
19:11:07 <nirik> adding "important packages" to it, expands it's scope.
19:11:12 <Kevin_Kofler> And shouldn't it be up to the SIG owning the spin to define its critical path?
19:11:50 <nirik> we do have a @critical-path-gnome now I guess.
19:11:56 <skvidal> nirik: right
19:12:12 <nirik> Kevin_Kofler: I would hope/think so.
19:12:15 * cwickert likes to point out that is still incorrectly considering xfce4-notifyd and it's deps as crit path
19:12:20 <mjg59> Kevin_Kofler: No, not if the SIG ends up with definitions of critpath that don't match everyone elses
19:12:36 <pjones> mjg59: if they do that, they get a useless spin... what's the problem?
19:12:38 <mjg59> Ideally that won't be an issue
19:12:48 <mjg59> pjones: Reflects badly on the rest of the distribution regardless, sadly
19:12:50 <notting> cwickert: would have the check the script - it's perhaps pulling all providers
19:12:54 <skvidal> mjg59: I think the general criteria of critpath should be the same, yes
19:12:55 <pjones> mjg59: true, but...
19:13:04 <Kevin_Kofler> mjg59: It's still the spin owners' business.
19:13:25 <Kevin_Kofler> I don't see why all the decisions in Fedora need to go through the central bureaucracy.
19:13:28 <nirik> ok, so sounds like people would prefer we add @critical-path-$otherdesktop groups?
19:13:34 <skvidal> mjg59: for the spins my general opinion is critpath == fedora critpath + whatever makes the spin work
19:13:41 <pjones> nirik: that'd be my first choice, yeah
19:14:10 <ajax> nirik: aye
19:14:27 <mjg59> nirik: I think that would be fine, but with the proviso that releng can add whatever they feel appropriate to individual critpath groups
19:14:30 <nirik> also, our proposal adds "Major desktop productivity apps" where do they fit in? another group?
19:15:30 <nirik> notting: does it pull from the groups currently? I thought it was using a hard coded list currently?
19:16:06 <notting> not sure what you mean. it pulls from the critical-path groups in comps... do you consider that a hard-coded list?
19:16:06 <abadger1999> nirik: It pulls from the groups but the generated list is hardcoded into bodhi at irregular intervals.
19:16:11 <Kevin_Kofler> I think the proposal considers way too much stuff to be critical.
19:16:45 <nirik> abadger1999: yeah. Thats what I meant... bodhi doesn't pull the changes from comps automagically...
19:16:49 <Kevin_Kofler> In fact, I don't see the extra bureaucracy added by the critical spin process as having had any practical benefits.
19:17:02 <abadger1999> nirik: nottings update will push that data into pkgdb so that the list stays in sync better.
19:17:04 <Kevin_Kofler> I sure haven't missed it for the KDE stuff which hasn't been in critpath so far.
19:17:28 <notting> abadger1999: basically, need to determine a good place to insert the process for auto-updates
19:17:32 <Kevin_Kofler> Even apps as critical, why?
19:17:35 <abadger1999> <nod>
19:17:38 <Kevin_Kofler> Apps are trivial to revert if they don't work.
19:17:45 <nirik> Kevin_Kofler: your views are well known.
19:19:13 <ajax> nirik: i'm not sure "productivity apps" is a good idea for critpath
19:19:14 <Kevin_Kofler> (Of course I meant the critical path process, there's no such thing as a "critical spin process". :-) )
19:19:31 <nirik> ajax: it's in our approved process. ;) We can of course amend it.
19:19:33 <Kevin_Kofler> ajax: Me neither.
19:19:41 <nirik>
19:19:41 <cwickert> Kevin_Kofler, it's not about reverting but about not pushing it in first place. when you have to revert something, it's already too late
19:19:54 <Kevin_Kofler> Soon we're going to declare the whole distro as "critical".
19:20:03 <Kevin_Kofler> cwickert: I mean apps are trivial for the USER to revert if they don't work for him.
19:20:19 <Kevin_Kofler> They won't make his system stop booting.
19:20:25 <cwickert> the user should not get any apps that don't work!
19:20:30 <nirik> ajax: would you like to see us remove apps there?
19:20:45 <ajax> nirik: i would.  _possible_ exception for firefox.
19:20:46 <Kevin_Kofler> Of course, our tools are less than helpful there: yum should be set up to keepcache by default and PackageKit should support downgrades!
19:20:57 <notting> ajax: the idea is that things like firefox, mail readers, etc. that greatly disrupt a users's productivity if they break should get testing
19:21:26 <ajax> notting: yeah, i just don't know how to draw a line between that, and abiword, and geda.
19:21:31 <nirik> I would expect many people would use those apps, so getting testing shouldn't be that hard...
19:21:33 <Kevin_Kofler> For KDE, the browser and the mail reader would already mean kdebase and kdepim.
19:22:03 <mcepl> notting: well, the originally was idea of critpath "whatever gives you barebone desktop", wasn't it?
19:22:20 <ajax> i'm willing to grant that firefox is exceptional, because, well, duh.
19:22:24 <nirik> mcepl: yes.
19:22:24 <skvidal> mcepl: it was actually originally - whatever makes it so you can get bits on disk
19:22:42 <skvidal> mcepl: and then we said 'oh, livecd' so the desktop bits got added to that
19:22:56 <notting> mcepl: and then regressions in firefox, thunderbird, X, etc. got enough publicity that the scope gets expanded...
19:23:05 <skvidal> nod
19:23:11 * mcepl isn't FESCO so just mumbles somethng about creeping featureritis
19:23:12 <cwickert> Kevin_Kofler, one more reason to make smaller packages ;)
19:23:35 <skvidal> mcepl: vs what? being happy with unusable releases/updates?
19:23:45 <Kevin_Kofler> cwickert: Well, for it to be helpful, we'd have to outright make separate SRPMs, from the same upstream tarballs, ugh!
19:23:46 <mcepl> notting: no, critpath shouldn't be IMHO, "whatever makes Fedora look bad" ...
19:24:17 <Kevin_Kofler> IMHO critpath should be the empty set. :-)
19:24:19 <mcepl> skvidal: please, keep the discussion about critpath from updates; what is actually "critical"?
19:24:34 <skvidal> mcepl: it has to do with updates, too
19:24:41 <nirik> so, currently we have 'firefox, thunderbird and evolution'... the kde parts are part of kde crit path already.
19:25:00 <Kevin_Kofler> Are they?
19:25:02 <cwickert> except kedpim
19:25:10 <cwickert> and kdebase is not critpath ether
19:25:17 <cwickert> kdebase-workspace is
19:25:26 <nirik> cwickert: it would be part of the kde-desktop critpath no?
19:25:37 <cwickert> not according to Kevin_Kofler
19:25:50 <pjones> kde-omgcallitsomethingdifferent-critpath, n'est pas?
19:25:51 <nirik> ok.
19:25:53 <Kevin_Kofler> I'll note that we haven't actually discussed this recently.
19:26:08 <mcepl> skvidal: yes, but when talking about "critical" we have at least some hope to discuss rationally some compromise ... if we talk about updates then "Fedora should be like RHEL" and "Fedora should be like Rawhide" groups will never agree.
19:26:09 <cwickert> Kevin_Kofler, I think kdebase really should be critpath. I consider a file manager cruciual for a desktop
19:26:27 <Kevin_Kofler> So I'm just communicating my own feelings, there hasn't been any recent KDE SIG discussion on this.
19:26:31 <skvidal> mcepl: and that's what fesco is for - to decide that argument
19:26:43 <notting> nirik: kde has no crit path at the moment. anyway....
19:26:51 <Kevin_Kofler> Last we did discuss it, we found that we don't see a need to be included in critpath at all. But that was quite some time ago.
19:26:55 <mcepl> OK, whatever, as you wish ... going to do something useful
19:27:00 * nirik sighs. Yes, thats what we are talking about creating here. ;(
19:27:21 <skvidal> mcepl: you're welcome to run for fesco
19:27:27 <notting> Proposal: add critical-path-group-<desktop> groups to comps, SIGs/releng can populate as needed in regards to the criteria already laid down.
19:27:38 <skvidal> notting: +1
19:27:43 <nirik> +1 to that.
19:27:43 <ajax> notting: ack
19:28:16 <skvidal> just need one more :)
19:28:25 <pjones> +1
19:28:27 <mjg59> +1
19:28:29 * notting acks himself
19:28:34 <nirik> #agreed add critical-path-group-<desktop> groups to comps, SIGs/releng can populate as needed in regards to the criteria already laid down.
19:29:07 <nirik> ok, I have a few more minor questions at:
19:29:19 <nirik> 3/4/5 there.
19:29:42 <cwickert> +1 just for the record
19:29:57 <ajax> nirik: 3 seems straightforward; mock install the critpath list, then rpm -qa in the chroot.
19:30:28 <mjg59> ajax: That's 2
19:30:35 <ajax> oh hey it is.
19:30:37 <mjg59> nirik: I'd go with "No", "No", "No", personally
19:30:56 <ajax> 4 and 5 are certainly mutually exclusive.
19:31:05 <nirik> true.
19:31:15 <Kevin_Kofler> I don't see 4 and 5 as mutually exclusive.
19:31:33 <Kevin_Kofler> If the submitter tested the update, why should that not be reflected in karma and thus be sufficient for a stable push?
19:31:49 <mjg59> Because we don't trust the submitter to have adequately tested
19:31:57 <nirik> for 3, I was thinking it might be nice if people could submit for stable, but it automatically pushes in a week or karma... since that would save maintainer effort of tweaking it again after a week... but that might be hard to do.
19:32:14 <Kevin_Kofler> I'd say no to 3 (autopushing always sucks, it should be the maintainer's decision), but yes to 4 and 5.
19:32:29 <pjones> I'd say "correct, it only gives them the choice", "no", and "no".
19:32:49 <pjones> I wouldn't say "yes" or "no" for 3 because there's too much ambiguity in the question for that to be a meaningful answer.
19:33:08 <Kevin_Kofler> mjg59: But why?
19:33:11 <ajax> i don't intrinsically have a problem with 3, but i think it's outside the current scope.
19:33:16 <Kevin_Kofler> The maintainer should ALWAYS be trusted!
19:33:24 <Kevin_Kofler> It should be the #1 principle we're working on.
19:33:39 <mjg59> The maintainer has demonstrated that the maintainer cannot be trusted
19:33:42 <pjones> Kevin_Kofler: that's insane
19:33:42 <Kevin_Kofler> Adding bureaucratic red tape which stops the maintainer from doing his job is counterproductive.
19:33:55 <pjones> nobody pushes something they think is broken.
19:34:06 <cwickert> Kevin_Kofler, testing is a maintainer's job
19:34:14 <pjones> by definition the submitter believes it works.
19:34:41 <cwickert> and giving people sufficient time is necessary for testing. if the maintainer is the only one to test, the testing is more or less useless
19:34:45 <nirik> there is an implied +1 from the maintainer.
19:34:49 <ajax> and i think i'm against 4, on the grounds that the maintainer wouldn't have submitted it if they thought it didn't work.
19:34:55 <ajax> ie, what nirik just said.
19:35:03 <nirik> counting it in "someone has independently verified the update" seems a bad idea to me...
19:35:07 <Kevin_Kofler> Not really. I normally didn't do ANY testing, only where I +1ed my own update I actually tested it. :-)
19:35:25 <nirik> Kevin_Kofler: ? wow.
19:35:28 <pjones> Kevin_Kofler: I'm pretty sure you're effectively unique in this regard.
19:35:41 <notting> 3. "does not autopush". no on 4. *assuming* no on #4, i could see a maybe on #5 for non-critical-path items
19:35:46 <Kevin_Kofler> Yes, I've done direct stable pushes without more testing than "it builds". Guess what: they worked, and fixed some critical issues for some people!
19:36:23 <ajax> notting: that sounds right to me.
19:36:24 <cwickert> Kevin_Kofler, they worked because you are closing all the bugs "ustream" ;)
19:36:37 <nirik> ok, so 3 seems pretty agreed.
19:37:04 <cwickert> +1 for #3
19:37:06 <Kevin_Kofler> cwickert: The bugs which we close upstream come from upstream, not from any quick fix we directly pushed to stable. :-)
19:37:56 <ajax> let's make this clearer
19:37:57 <nirik> on, 4 I am a no.
19:38:10 <nirik> so that seems like 5 for no and 1 yes on question 4.
19:38:23 <cwickert> Kevin_Kofler, I am not convinced because I have seen bigs in our KDE that are not in Debian for example. nevertheless all of my reports are closed
19:38:26 <ajax> proposal re 3: minimum time spent in updates-testing does not imply automatic push to stable
19:38:28 <Kevin_Kofler> And usually, I do wait for at least one person to have tested an update before queueing it for stable. That may or may not be me.
19:39:07 <nirik> ajax: +1 I guess.
19:39:15 <pjones> ajax: +1 to that
19:39:16 <Kevin_Kofler> Of course if it's some package like kmid2 which has hardly any user, and definitely nobody ever doing any testing, what can I do other than just pushing stuff?
19:39:30 <Kevin_Kofler> I do try to test those updates myself before pushing them, but that's all I can do.
19:39:36 <mjg59> Kevin_Kofler: And since that's the kind of behaviour we're trying to stop, it sounds like the submitter should not be able to provide enough karma to push to stable
19:39:40 <ajax> Kevin_Kofler: if it has hardly any users, then it's not critpath, is it.
19:39:50 <ajax> Kevin_Kofler: try to stick to one argument at a time.
19:40:17 <Kevin_Kofler> But you also voted to have the karma requirements apply to non-critical packages as well!
19:40:27 <cwickert> on the one hand I agree to #4, on the other it's hard for the small desktops because they only have a few users/testers
19:40:28 <nirik> ok, any other votes on 3? I don't see any desenting ones, so I think thats done with.
19:40:35 <Kevin_Kofler> I was the only one who voted for striking that section!
19:40:45 <pjones> but right now we're discussing rules for critpath stuff!
19:40:49 <cwickert> +1 for #3 (but I already said that)
19:41:15 <nirik> lets move on to question 4... votes please?
19:41:20 <cwickert> can we just vote on the numbers?
19:41:41 <pjones> for number for, I propose that the submitter's vote does not count.
19:41:46 <pjones> number four even
19:41:52 * notting agrees with pjones
19:41:53 <nirik> pjones: I agree
19:41:54 <ajax> pjones: +1
19:41:58 <skvidal> #4 -1
19:42:05 <skvidal> so I agree with pjones
19:42:07 <Kevin_Kofler> I propose that the submitter should be able to set threshold at +1 and give his own vote for that.
19:42:12 * nirik notes that it should be easy to implement this in bodhi if we like from what I understand.
19:42:14 <cwickert> +-0, because I maintain packages that hardly have any testers
19:42:28 <nirik> cwickert: can't those packages wait a week?
19:42:43 <ajax> for 4, pjones notting nirik ajax skvidal -> +5 agreed
19:42:47 <cwickert> nirik, usually they can, so count me in, +1 then
19:43:08 <mjg59> Yeah, I'm +1 to submitter not being allowed to add karma
19:43:21 <cwickert> +1 to that
19:43:23 <nirik> #agreed submitter's vote does not count
19:43:27 <Kevin_Kofler> -1 to that
19:43:31 <pjones> for #5, I propose that the submitter should not be allowed to set the threshold at +1
19:43:42 <nirik> pjones: so, that means it must be +2 or more?
19:43:50 <ajax> pjones: agreed, with the understanding that this is a critpath policy, not a general policy.
19:44:03 <Kevin_Kofler> I propose that they should be allowed to set it at +1.
19:44:14 <pjones> for #5, I propose that for critpath packages, the threshold must be +2 or higher.
19:44:16 <cwickert> i think if the maintainer is not conted, +1 means that at least one other person has tested it
19:44:19 <Kevin_Kofler> Especially if their own vote doesn't count anyway.
19:44:25 <notting> ajax: the section nirik is referring to in questions #4 and #5 is *not* the critpath section
19:44:27 <nirik> for critpath the threshold doesn't matter... it will always require a +1 from tester/rel-eng and +1 from sometone else.
19:44:35 <nirik> (at leasat thats what I understand)
19:44:44 <pjones> Oh, hrm.
19:44:51 <pjones> well, now I've got to rethink this.
19:44:53 <ajax> hurr then.
19:45:04 <pjones> okay: ready, set, discuss some more.
19:45:05 * nirik is sorry if his questions were unclear.
19:45:09 <Kevin_Kofler> So there seems to have been a misunderstanding, we must redo the vote for #4.
19:45:21 <nirik> do we?
19:45:24 * notting reiterates his prior vote on #4
19:45:26 <ajax> doesn't change my vote for #4 at all.
19:45:29 <pjones> mine either.
19:45:34 * nirik 's vote is the same for 4
19:45:40 <mjg59> Also
19:45:45 <ajax> so that's five, so no we don't.
19:45:46 <skvidal> #4 == submitter vote doesn't count
19:45:50 * cwickert still doesn't change his mind about #34
19:45:52 <skvidal> my vote is unchanged
19:45:53 <cwickert> #4
19:45:59 <pjones> okay, so we all stay the same on 4.
19:46:06 <ajax> so!  number 5.  this is "important", which is "critpath for a spin" more or less?
19:46:07 <cwickert> right, on to 5 then...
19:46:09 <ajax> is that accurate?
19:46:27 <nirik> no. This is "any update"
19:46:57 <nirik> important/crit-path packages already need at least +2... +1 from proventester +1 from other person.
19:46:58 <notting> ajax: no, he's asking for clarification on "all updates can ... reach the positive bodhi karma threshold specified by the updates submitter"
19:47:03 <cwickert> sorry, but what have spins to do with it? have i missed something? where is critpath for spins defined?
19:47:09 <mjg59> For non-critpath/important, I guess I'm ok with a +1 requirement
19:47:24 <ajax> cwickert: i was inferring it from point 1 in his 5 questions.  my bad,.
19:47:38 <Kevin_Kofler> Karma +1 is already one more than should be required.
19:47:40 <nirik> so, this is just any update. Can they set it to +1?
19:47:43 <pjones> yeah, for normal packages, I think +1 is fine
19:47:50 <pjones> as long as it isn't the maintainer.
19:47:51 <Kevin_Kofler> So I vote for yes, +1 should be enough!
19:47:59 <nirik> I am fine with them doing that since we decided #4 the way we did.
19:48:14 <ajax> +1 is fine for non-special updates, yes.
19:48:24 * notting is ok with +1 for non-critpath updates
19:48:25 <cwickert> ajax, I still don't get it, sorry. the word 'spin' is not even in the ticket...
19:48:28 <skvidal> one sec
19:48:47 <skvidal> is #5 contigent on the submitter's vote not being counted?
19:48:58 <pjones> cwickert: but it's implied with the @groups in #1
19:49:10 <ajax> cwickert: what is critpath+ at lxde-desktop if not "things that are important to the lxde spin being consumable"
19:49:13 <Kevin_Kofler> skvidal: It was just decided that the submitter's vote won't be counted.
19:49:16 <skvidal> so essentially we're saying every update needs atleast one other tester, and critpath needs more than one
19:49:20 <cwickert> pjones, so it covers the desktop groups but not the actual spin?
19:49:36 <ajax> skvidal: or, standard 1 week timeout, yes.
19:49:42 <skvidal> ajax: okay
19:49:45 <skvidal> then fine +1
19:49:49 <skvidal> to #5
19:49:55 <Kevin_Kofler> But re #4, I still don't see what difference it makes whether I tested my update or somebody else did.
19:49:59 <nirik> ok, I don't see any objections.
19:50:06 <Kevin_Kofler> In the end effect it will have been tested by 1 person.
19:50:12 <cwickert> ajax, well, many things are important for the LXDE spin, but many of them have nothing to do with the LXDE desktop
19:50:14 <nirik> #agreed updates can set the karma level to +1
19:50:26 <Kevin_Kofler> Nowhere is there any verification that I actually did test any update I queued (and I'll happily admit I often didn't).
19:50:57 <ajax> cwickert: if i was reading the questions as being about "important" updates, then my opinion on #5 is different than if it's about arbitrary updates.
19:51:12 <nirik> ok, thats my questions. Do we wish to talk any more about this topic? or do we know what we need to do now?
19:51:20 <Kevin_Kofler> Another big issue is that we'll now need one person on EACH distro to #1 the update.
19:51:31 <abadger1999> I have one clarification question
19:51:36 <Kevin_Kofler> *to +1 the update
19:51:48 <cwickert> ajax, you mean sylpheed is critical because it is the default mail client in the LXDE while it normally wouldn't considered critpach?
19:51:53 <Kevin_Kofler> I think this is very much unworkable without a way to have the +1 counted for ALL affected distros.
19:51:56 <ajax> Kevin_Kofler: oh no, you'll have to click three buttons instead of one.
19:52:03 <abadger1999> For #1: we're having different comps groups go into the process of making the critical path list. But we're fine with a single critical path list coming out of that, correct?
19:52:16 <notting> abadger1999: i am, at least.
19:52:17 <Kevin_Kofler> ajax: That's not the point at all!
19:52:21 * abadger1999 making sure there's no bodhi/pkgdb work resulting from that.
19:52:23 <nirik> abadger1999: thats what I was gathering, yes.
19:52:27 <abadger1999> Excellent.
19:52:29 <Kevin_Kofler> Testers will probably only +1 the update for the distro they tested it on.
19:52:35 <skvidal> abadger1999: I'm cool w/that
19:54:07 <nirik> Kevin_Kofler: as they should, since thats what they tested?
19:54:08 <Kevin_Kofler> So we'll end up with many broken upgrade paths due to stuff having been tested on the older distro first, many packages not getting pushed to the previous stable release etc.
19:54:08 <ajax> Kevin_Kofler: aah, i see you're finally beginning to understand quality testing.
19:54:08 <Kevin_Kofler> nirik: No.
19:54:08 <Kevin_Kofler> A +1 for one distro should be sufficient to push the update to all.
19:54:08 <Kevin_Kofler> Otherwise we end up with broken upgrade paths.
19:54:08 <Kevin_Kofler> That's one of the biggest issues with this new policy.
19:54:08 <ajax> or, you could deploy updates sensibly.
19:54:08 <ajax> that's another option.
19:54:08 <Kevin_Kofler> Updates to distros should be kept in sync.
19:54:08 <Kevin_Kofler> The same bugfix updates should go out to all supported releases at the same time.
19:54:08 <mjg59> It's almost like we'd had this conversation before
19:54:08 <cwickert> if something works on F11 it can still crash horribly on F13
19:54:14 <drago01> or we could start using distro epoch ...
19:54:15 <Kevin_Kofler> cwickert: Theoretically yes.
19:54:20 <cwickert> paractically too
19:54:24 <nirik> yes, anything further (thats new) on this topic? or shall we move on?
19:54:27 <Kevin_Kofler> In practice it's so extremely unlikely that it's just not worth worrying about.
19:54:40 <Kevin_Kofler> drago01: That'll just replace upgrade path breakage with regressions.
19:54:43 <Kevin_Kofler> Not that great a plan.
19:55:21 <nirik> ok, moving on then?
19:55:25 <cwickert> nirik, lets move please. i don't want to argue about testing with people who say they actually don't test anything
19:55:27 <nirik> #topic #363 Proposal: auto sign pkgs in koji
19:55:34 <nirik> .fesco 363
19:55:35 <zodbot> nirik: #363 (Proposal: auto sign pkgs in koji) - FESCo - Trac -
19:55:50 <drago01> that might happen if you have foo-1.0 in F-N and foo-2.0 in F-N-1 with different config file formats ... which shouldn't happen anyway
19:55:52 <drago01> Kevin_Kofler: ^^
19:56:00 <drago01> anyway offtopic here
19:56:19 <nirik> I'm fine with this proposal. I think it's a great idea.
19:56:20 <Kevin_Kofler> drago01: A bug getting fixed only in Fn-1 means that if you upgrade to Fn, you have a regression.
19:56:48 <skvidal> nirik: are you comfortable with my addendum?
19:56:53 <nirik> This is just one single 'koji' key for all non scratch builds right? not per release or anything?
19:57:01 <ajax> skvidal: "our" key.  which?
19:57:08 <notting> i don't see how the addendum necessarily follows as required. i'm ok with the original proposal
19:57:13 <skvidal> ajax: a fedora-release-specific key
19:57:21 <nirik> skvidal: sure, I think thats a good idea too... but does it need to be done before this?
19:57:40 <Kevin_Kofler> I don't understand skvidal's addendum.
19:57:48 <skvidal> it feels like it should be done - but maybe it is not required
19:57:59 <skvidal> it is just way of saying 'yes someone in fedora signed off on this as a repo'
19:58:11 <Kevin_Kofler> "repositories must be signed by our key" – which repositories?
19:58:14 <ajax> by repository, you mean repodata as well as the package, i guess?
19:58:19 <skvidal> no
19:58:29 <skvidal> so a repo has a dir repodata
19:58:32 <skvidal> which as a file repomd.xml
19:58:44 <skvidal> yum supports checking a detached signature on repomd.xml
19:58:55 <skvidal> since repomd.xml has sh256 checksums of all the metadata
19:58:59 <Kevin_Kofler> Oh, so you want the official Fedora repositories to have signed metadata?
19:59:02 <skvidal> and the metadata has sha256checksums of all the pkgs
19:59:12 <Kevin_Kofler> That's definitely a good idea!
19:59:13 <skvidal> then the trust comes down from the signed repomd.xml
19:59:36 <ajax> i'm... slightly cautious about that.
19:59:41 <skvidal> now - I see the point that maybe this is not required to implement auto-signed pkgs about keys
19:59:43 <skvidal> ajax: okay, why?
20:00:27 <Kevin_Kofler> I'm +1 to autosigning packages and +1 to signing the metadata in official Fedora repositories.
20:00:30 <skvidal> ajax: if it helps, this mechanism has been vetted by mark cox
20:00:30 <ajax> well, maybe not.  one second.
20:00:52 <Kevin_Kofler> (Third-party repositories obviously need to make their own decisions on how to handle signing.)
20:01:06 <ajax> skvidal: just trying to make sure i have the details straight.  this detached signature would be from the same key that signs the koji packages?
20:01:11 <dgilmore> skvidal: all packages for all releases will be signed via one key
20:01:11 <nirik> yeah, both sound great, but whenever either can land is fine with me. I don't think there needs to be a requirement on one for the other.
20:01:28 <notting> skvidal: i'm concerned about repomd.xml signing merely because i understand how we build repositories now and am having trouble wrapping my head around how we sanely integrate it into current processes. i'm fine with the idea. :)
20:01:28 <skvidal> ajax: no - it [wc]ould be a different signature
20:01:30 <dgilmore> skvidal: the key says this was built in fedora's koji,  nothing more nothing less
20:01:37 <nirik> dgilmore: right.
20:01:54 <skvidal> dgilmore: that key is the one signing the pkgs
20:01:58 <dgilmore> skvidal: then we would sign the repodata we push out to users and they would verify that and the koji key
20:02:22 <ajax> skvidal: then i guess i don't see what it adds.  i can pretty easily make a key that claims to be the F13 release key, and sign my repodata with that.
20:02:30 <ajax> it won't be the same key, of course.
20:02:40 <skvidal> ajax: and then you'll get that key onto the user's systems, how?
20:03:00 <skvidal> ajax: if you're proposing a MITM attack, then you'd need to get the users to trust your key.
20:03:42 <ajax> skvidal: okay, so, in your model, how do you get the user to trust the key that signs repomd.xml?
20:04:04 <skvidal> ajax: that's the key we blow on the system at install in the fedora-release pkg
20:04:46 <notting> skvidal: technically, we put both (koji and release) keys on the system @ install?
20:05:00 <skvidal> notting: that would be what we're going for here, yes.
20:05:07 <skvidal> in an IDEAL world
20:05:20 <skvidal> we would actually put a trust key on the systems
20:05:23 <notting> and we're not concerning ourselves with bug 998 yet
20:05:26 <skvidal> and yum would download the other keys
20:05:30 <skvidal> notting: no one cares about 998
20:05:38 <skvidal> verify that the other keys were signed by our trust keys
20:05:45 <Kevin_Kofler> What's bug 998?
20:05:46 <skvidal> and then agree to them
20:06:03 <nirik> Kevin_Kofler: one of the oldest still open bugs...
20:06:06 <skvidal> s/to them/to trust them/
20:06:09 <nirik> .bug 998
20:06:11 <zodbot> nirik: Bug 998 Network install/upgrade is unsafe, should check GPG signatures. -
20:06:31 <ajax> skvidal: well, okay then, that's no worse than what we've got, and doesn't imply getting the user to reflexively say yes to any more "do you trust this key" prompts
20:06:50 <Kevin_Kofler> Oh, that one. Fun…
20:07:08 <mbonnet> skvidal: would yum allow packages signed by the "Koji" key to be installed?  Do we want it to without explicit authorization?
20:07:08 <ajax> it doesn't solve my pet irritation that there's no trust cascade from Fn to Fn+1, but that's out of scope.
20:07:27 <skvidal> mbonnet: when the CA code is implemented that, in fact, would be the point
20:07:48 <skvidal> ajax: if we have a CA key then it would
20:08:04 <mbonnet> skvidal: I see a distinction between "I trust repodata signed with this key" and "I trust packages signed with this key", but maybe that's not an important distinction.
20:09:14 <nirik> ok, so where are we here?
20:09:27 <nirik> aside from at 15minutes. ;)
20:09:28 <ajax> i'm in favor of jesse's proposal.
20:09:43 * nirik didn't see any objections...
20:09:50 <ajax> i'm slightly in favor of doing skvidal's amendment at the same time, but i'm not going to insist on it either way
20:09:55 <pjones> I still think this completely erodes all actual trust, but meh.
20:10:08 * notting is in favor of both proposals, but sees no reason to tie them
20:10:21 <skvidal> I'm fine with not requiring the latter for the former
20:10:26 <Kevin_Kofler> I've been in favor of autosigning all this time, I'm +1 to it.
20:10:42 <Kevin_Kofler> And like notting, I'm also +1 to skvidal's comment, but don't see the need to do both at the same time.
20:11:08 <nirik> pjones: you have objections?
20:11:19 <nirik> oh, I suppose we need to vote to continue discussion...
20:11:26 <pjones> nirik: I think auto-signing without certs that explain what the signature means aren't terribly meaningful.
20:11:40 <pjones> isn't, rather.
20:11:57 <ajax> pjones: i think the idea is it's the same cert as we would otherwise use for the final release.
20:12:03 <nirik> pjones: it means "This was built by and is not a scratch build"
20:12:06 <ajax> which is, admittedly, theatre.
20:12:23 <skvidal> pjones: no one knows what the certs mean now - they are fundamentally a 'look my bits didn't work' functionality
20:12:38 <pjones> skvidal: fair enough.
20:12:55 <skvidal> the only benefit we get out of yum complaining about them
20:13:05 <skvidal> is we find out when something slipped out of bodhi/mash w/o being signed
20:13:07 <pjones> nevertheless, this seems to be a fine proposal, I just don't see it actually accomplishing anything.
20:13:19 <skvidal> pjones: if we allow auto-signed pkgs
20:13:25 <skvidal> then releng doesn't have to sign as a separate step
20:13:29 <ajax> pjones: if nothing else, it makes release compose a hell of a lot faster
20:13:33 <pjones> that's true.
20:13:53 <skvidal> pjones: and I like Oxf13 and jwb and I sorta like notting and I think we should be nicer to them :)
20:14:03 * skvidal grins in notting's general direction
20:14:14 <nirik> #agreed the proposal is approved.
20:14:17 <ajax> (well, amortizes release compose time over the preceeding six months.  whatever.)
20:14:35 <nirik> #topic FES tickets update
20:14:42 <nirik> mmcgrath: you have anything in general to note?
20:15:01 <mmcgrath> nirik: hey, no major work since last week, little fixes, new lists generated.
20:15:20 <nirik> I added 2 new tickets that I'd like to note here for input or scorn:
20:15:26 <nirik>
20:15:39 <nirik> Investigate implementing cross desktop support shortcuts
20:15:56 <nirik> Have some way to more easily get our end users to our support forums.
20:16:21 <mmcgrath> I saw that, I think jose took one already
20:16:25 <mmcgrath> well I assigned it :)
20:16:38 <nirik> yeah... hopefully some good will come of it. Any input welcome in the ticket.
20:17:13 <nirik> and also I filed: which is "investigate weekly Fedora gaming sessions". :)
20:17:18 <Kevin_Kofler> Putting the shortcuts into the xdg-user-dir for Desktop should be sufficient.
20:17:37 <nirik> Kevin_Kofler: oh, thats a good idea...
20:17:38 <Kevin_Kofler> KDE will show them in its default folder view applet, most other environments directly on the desktop.
20:18:02 <nirik> although they will need to figure out what DE they are running under for the right apps.
20:18:32 <nirik> I'll also note that "port syslinux isohybrid perl script to C" had a patch submitted upstream.
20:18:58 <nirik> and "Document Fedora as android devel platform" worked fine here this weekend and looks good.
20:18:59 <pjones> did somebody actually talk to hpa about that first?
20:19:04 <pjones> he tends to actually be a fan of perl.
20:19:10 <ajax> ... the nutter
20:19:12 <Kevin_Kofler> Well, .desktop files directly take at least HTTP URLs.
20:19:20 <Kevin_Kofler> Not sure about mailto or irc URLs.
20:19:39 <nirik> pjones: not sure, I think mdomsch did... ticket is at
20:19:47 <pjones> okay
20:20:50 <nirik> ok, thats all I had on that. Update/file new tickets... keep the work going. ;)
20:21:01 <nirik> #topic F13 Beta
20:21:07 <nirik> Beta went out today...
20:21:18 * skvidal 's update just finished
20:21:18 <ajax> \o/
20:21:26 <nirik> I'd like to give kudos to all who worked on it. ;)
20:21:51 <skvidal> ajax: is that a symbol for devil worship? :)
20:22:05 <Oxf13> put your hands in the air
20:22:13 <pjones> skvidal: no, that's \m/
20:22:27 <skvidal> :)
20:22:32 <nirik> Thats the surfer sign right? :)
20:22:38 <nirik> #topic Open Floor
20:22:42 <nirik> Anything for open floor?
20:22:47 <pjones> nirik: I thought the surfer sign had the thumb extended?
20:23:01 <nirik> \o(
20:23:07 <Kevin_Kofler> nirik: The surfer sign would be _rm/ :-)
20:23:08 <pjones> so it's more like >n/
20:23:11 <nirik> or )o/
20:23:14 <skvidal> pjones: did you not read the bruhaha on the ambassadors or whatever for it?
20:23:20 <cwickert> i have something on my mind
20:23:25 <pjones> skvidal: what?
20:23:26 <nirik> cwickert: go ahead.
20:23:35 <cwickert> about cleaning up the deps...
20:23:42 <pjones> skvidal: about the horns?
20:23:44 <Oxf13> that'd be the "hang loose" sign
20:23:45 <skvidal> pjones: yes
20:23:49 <cwickert> I still haven't come up with a proposal
20:23:54 <skvidal> cwickert: to clean up which deps?
20:23:56 <cwickert> but i have filed several bugs
20:23:59 <Oxf13> or "shakka"
20:24:14 <cwickert> .fesco 345
20:24:15 <zodbot> cwickert: #345 (Dependency chain painpoints) - FESCo - Trac -
20:24:16 <nirik> cwickert: the evince thing was fixed.
20:24:17 <skvidal> ah
20:24:33 <cwickert> nirik, there are even more on nautilus
20:24:35 <cwickert> and others
20:24:56 <cwickert> but I have no idea how we could make a *propsal* or a plan out of this
20:24:59 <nirik> yeah, the pidgin/evolution one is the next big one I want to see done.
20:25:17 <cwickert> I think we must file bugs and decide on a per-bugs-base
20:25:33 <nirik> yeah, I don't know what we want there. Really it should be: If you notice a bad dep, file a bug and try and get it fixed. If you run into problems escalate it?
20:25:42 <cwickert> is there a general rule of thumb that everybody agrees to?
20:25:52 <Kevin_Kofler> I think the "firstboot Requires metacity" issue is the worst.
20:26:00 <cwickert> or something we as FESCO could do to make it happen?
20:26:03 <Kevin_Kofler> It's dragging quite some unwanted GNOME stuff onto the KDE spin.
20:26:22 <cwickert> Kevin_Kofler, actually it's system-config-kexboard depending on metacity
20:26:28 <nirik> cwickert: I think it's hard to have a general rule... each case could be quite different.
20:26:43 <Kevin_Kofler> It is? Last I checked it was firstboot…
20:26:55 <cwickert> firstboot requires s-c-k
20:27:04 <nirik> firstboot does require metacity
20:27:07 <Kevin_Kofler> firstboot also uses metacity directly.
20:27:07 <ajax> need a window manager somehow.
20:27:21 <cwickert> foh, indeed
20:27:24 <nirik> s-c-k requires firstboot
20:27:24 <Kevin_Kofler> Yeah, but it could be made to use kwin on the KDE spin.
20:27:31 <ajax> it could!  PGA i'm sure.
20:27:39 <Kevin_Kofler> kwin can be run standalone as well.
20:27:40 <nirik> in the past deps like that have been solved by a virtual provide.
20:27:43 <cwickert> ajax, this is something we could do with a proposal, i will come up with one by next week
20:27:57 <nirik> Requires: somewindomanagerofsomekind
20:28:06 <Kevin_Kofler> But in Rawhide even Anaconda itself wants Metacity. :-(
20:28:28 <cwickert> is there any reason not to use a virtual provides for netwm compatible WMs?
20:28:40 <Oxf13> that's because anaconda no longer uses it's own wm
20:28:43 <Kevin_Kofler> With Metacity being deprecated even in GNOME, with gnome-shell integrating the WM, I think we really shouldn't use metacity for this purpose.
20:28:44 <Oxf13> it uses metacity
20:28:48 <ajax> cwickert: only in the sense that you don't know how to invoke them.
20:29:07 <Kevin_Kofler> I could hardcode a solution for kwin, but that won't help the other spins.
20:29:14 <cwickert> ajax, this is left up to the spins, we are already doing this for a couple of releases now
20:29:21 <ajax> Kevin_Kofler: that's a little stronger of a position than gnome is actually taking.
20:30:05 <Kevin_Kofler> cwickert: The problem is that Anaconda and Firstboot need to invoke the WM outside of the usual context.
20:30:06 <nirik> How about we try and use our devel list for a discussion of this issue and see if we can reach a solution there? (I know... trying to make the devel list used for devel topics, what am I thinking!)
20:30:15 <ajax> nirik: capital idea.
20:30:18 <Kevin_Kofler> They need a WM in their own, sorta-embedded environment.
20:30:24 <pjones> nirik: sure.
20:30:40 <cwickert> I think the wm issue is really something for a proposal. the rest needs to be decided individually
20:30:46 <cwickert> eof for now
20:30:49 <Oxf13> Kevin_Kofler: actually we need less stuff like that duplicating functionality
20:31:01 <nirik> cwickert: would you be willing to drop a post to the devel list explaining the issue in detail and possible solutions?
20:31:07 <Oxf13> there is no good reason for Anaconda to continue maintaining it's own WM duplicating features of other WMs as it needs them.
20:31:18 <notting> Oxf13: ... which is why it isn't any more
20:31:20 <cwickert> nirik, sure, if i find the time to test it
20:31:28 <Kevin_Kofler> Sure, but always dragging in the GNOME WM isn't a good solution either!
20:31:30 <nirik> anaconda should just use ratpoison. :)
20:31:32 <Oxf13> notting: right, we don't want to go back to it.
20:31:43 <cwickert> nirik, twm ftw ;)
20:31:48 <Oxf13> Kevin_Kofler: you object because it's the "gnome" wm?
20:31:51 <Oxf13> really?
20:32:00 <Kevin_Kofler> I object because it has MANY GNOME deps.
20:32:07 <Kevin_Kofler> Even stuff like libcanberra.
20:32:15 <nirik> #agreed Discussion on devel list to try and solve metacity deps in anaconda and firstboot
20:32:18 <pjones> I wouldn't mind having fewer deps.
20:32:18 <cwickert> Oxf13, no because it pulls in things like gconf etc
20:32:24 <Kevin_Kofler> This is all stuff the KDE spin ONLY ships because metacity requires it.
20:32:26 <Oxf13> now that's a different argument.
20:32:39 <Oxf13> one that's worth having, if there are ways to lessen the dep list on metacity
20:32:45 <Kevin_Kofler> We need a lighterweight WM for Anaconda and Firstboot to use.
20:32:48 <Oxf13> far better discussion than "go write your own"
20:32:52 <pjones> that being said, you're going to have some of that anyway, because we use gtk widgets.
20:32:58 <notting> nirik: .. is that the end of the agenda?
20:33:03 <nirik> notting: yes.
20:33:07 <nirik> Anything else for open floor?
20:33:11 <Kevin_Kofler> GTK+ is one thing, libcanberra, GConf etc. is another.
20:33:15 <cwickert> not from me...
20:33:18 <pjones> yeah, I said "some" for a reason.
20:33:20 * nirik will close out the meeting in a minute if nothing else comes up.
20:33:28 <cwickert> openbox ftw! ;)
20:33:35 <skvidal> one more thing
20:33:37 <skvidal> sorry
20:33:40 <nirik> skvidal: ok.
20:33:50 <skvidal> I just finished running the 'potentially unmaintained' script again
20:33:55 <skvidal> just for the fun of it
20:34:00 <cwickert> results?
20:34:06 <skvidal> it seems like we're getting an increasing number of pkgs which don't look healthy
20:34:08 <Oxf13> skvidal: I bet it got bigger.
20:34:11 <skvidal> Oxf13: :)
20:34:19 <Oxf13> we had a couple people orphan up a lot of packages recently
20:34:25 <skvidal> yah
20:34:35 <skvidal> lemme upload the by-user output
20:34:49 <nirik> oh yeah, I was wondering what happened with that.
20:35:09 <skvidal>
20:35:21 <nirik> #info skvidal re-ran the potentially unmaintained script again, results at
20:35:46 <cwickert> awjb has 61 packages, wow!
20:35:52 <skvidal> I've got 4 pkgs in there which need some love, too
20:35:56 <nirik> this is against 13?
20:36:11 <skvidal> rawhide
20:36:13 <cwickert> wft? I have 44?
20:36:33 <skvidal> any pkg that has not been rebuilt by a user since the last autorebuild
20:36:41 <skvidal> I'll have to recheck the dates - but I think I'm current on that
20:36:42 <pjones> skvidal: python-goopy probably ought to just be pkgwacked
20:36:46 <cwickert> skvidal, i had like 15 or 20 and updated some of them, but the list got even bigger for me?
20:36:49 <nirik> that time is growing since we didn't have one this cycle.
20:36:53 <drago01> there might be valid reasons for that
20:36:55 <skvidal> pjones: you'd be the guy to do that :)
20:36:59 <ajax> wooo, i'm popular.
20:37:00 <pjones> skvidal: since there's never been a single upstream update since the first release and that was several years ago and all.
20:37:22 <skvidal> pjones: I can give you the bullets, but you're going to have to pull the trigger. :)
20:37:26 <cwickert> skvidal, I thought it was "within the last year", right?
20:37:29 <pjones> skvidal: yeah
20:37:42 <skvidal> cwickert: 6months, iirc
20:37:57 <cwickert> skvidal, this is not enough IMO
20:38:00 <skvidal>
20:38:03 * Kevin_Kofler has 3 packages on the list as well.
20:38:04 <skvidal> that's the script
20:38:09 <skvidal> I'll rerun it with whatever number
20:38:11 <cwickert> when was the script run?
20:38:18 <skvidal> like 10minutes ago
20:38:23 <skvidal> so - something to keep in mind
20:38:27 <Kevin_Kofler> ksensors: dead upstream, z88dk: no upstream release in the last few months
20:38:28 <cwickert> skvidal, then it must be wring
20:38:29 <skvidal> this list is not meant to abuse anymore
20:38:30 <cwickert> wrong
20:38:36 <pjones> skvidal: a'ight, done.
20:38:46 <skvidal> as before - it's just to point out things someone might have forgotten about
20:38:55 <skvidal> or not been able to maintain for whatever reason
20:39:01 <skvidal> and sometimes the script just points out bugs :)
20:39:02 <Kevin_Kofler> flasm: not actually sure, I picked that up because pertusus said it can be useful for debugging Gnash, I don't really have a use for it myself, I have to check its upstream status.
20:39:09 <cwickert> skvidal, the list shows sakura and lilyterm, both were updated 4 days ago
20:39:12 <cwickert>
20:39:14 <nirik> sure... some of might are legit dead... some of them are just very slow to update.
20:39:19 <skvidal> cwickert: a rawhide build?
20:39:22 <cwickert>
20:39:27 <cwickert> F13 as well
20:39:40 <skvidal> cwickert: I don't see rawhide there
20:39:49 <Oxf13> neither do I
20:39:58 <cwickert> skvidal, i think it's inherited?
20:40:00 <skvidal> this is checking dist-rawhide in koji
20:40:02 <Oxf13> and the F13 one won't show up in rawhide until/unless it goes into dist-f13 stable
20:40:10 <cwickert> ah
20:40:14 <Kevin_Kofler> flasm is also up to date.
20:40:22 <Kevin_Kofler> (1.62, there's no newer upstream release.)
20:40:34 <Kevin_Kofler> So all these are false positives, they haven't been touched because upstream hasn't released anything newer.
20:40:43 <Kevin_Kofler> I'm sure many of those packages are like that.
20:40:47 <Kevin_Kofler> Not just mine.
20:40:54 <nirik> sure.
20:41:09 <Oxf13> it's a list of things to check into
20:41:09 <skvidal> anyway - I was just thinking about this - so I ran it again - some useful info to know, etc
20:41:09 <cwickert> are builds for F13 no longer inherited into rawhide automatically?
20:41:14 <Oxf13> not a definitive list of "These all have problems!"
20:41:20 <Oxf13> cwickert: only when they go stable.
20:41:26 <cwickert> i see
20:41:35 <nirik> skvidal: perhaps worth posting on devel? might get some folks thinking about things they should drop...
20:41:38 <skvidal> Oxf13: right - this is not a list of YOU ARE BAD AND DOOM - it's just a list of 'hmm, maybe go look at this'
20:41:49 <Oxf13> skvidal: sometimes it's hard to get people to realize that
20:41:50 <skvidal> nirik: fine by me - I just wanted to run this by y'all see if anything leapt out
20:42:20 <nirik> yeah, I see some of mine I keep meaning to drop... should do so.
20:42:23 <skvidal> Oxf13: I don't disagree...
20:42:34 <skvidal> pjones: thanks for killing a pkg
20:42:40 <nirik> when do we do the orphan purge this cycle? or it's already done for f13?
20:42:41 <skvidal> pjones: the repodata load thanks you
20:43:08 <Oxf13> nirik: we did it around branch time
20:43:09 <pjones> skvidal: jebus and I love you, seth.
20:43:19 <nirik> ok.
20:43:20 <skvidal> pjones: fsm, too?
20:43:25 <Kevin_Kofler> :'-( one less package…
20:43:29 <pjones> his noodly appendage too.
20:43:33 * nirik thinks he should kill gdk-pixbuf and tpb with fire.
20:43:37 * Kevin_Kofler would like to see Fedora ship everything possible and imaginable.
20:43:53 <pjones> Kevin_Kofler: and again, we're talking about a package with no upstream and no users.
20:43:54 <Kevin_Kofler> Total world domination. :-)
20:44:00 <skvidal> that's all I have
20:44:01 <nirik> ok, anything else? or shall we close the meeting now?
20:44:26 <Oxf13> I'd rather not see Fedora collapse under it's own weight of unmaintainable crap.  Leave that to Debian
20:44:34 <nirik> Thanks for coming everyone.
20:44:38 <nirik> #endmeeting
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
Url : 

More information about the devel mailing list