[18:01] <robbiew> kees: meeting today?
[18:01] <kees> robbiew: yup! just gathering notes
[18:02] <mdeslaur> yayay
[18:02] <kees> jdstrand: you ready?
[18:02]  * nxvl waves
[18:02] <kees> heya nxvl :)
[18:02] <nxvl> you finally got out of my lunchtime :D
[18:02] <kees> hehe
[18:02] <jdstrand> o/
[18:02] <kees> back to a normal time.  I dislike DST
[18:03] <mdeslaur> It doesn't save me a thing
[18:03] <kees> yeah
[18:03] <kees> okay, starting...
[18:04] <kees> I'm a day behind on triage -- I'll do a bug and CVE run this morning.  over the weekend I worked on trying to reproduce the weirdness we've seen with AppArmor kernel memory
[18:04] <mdeslaur> kees: too late, I've done it already
[18:05] <kees> mdeslaur: you did the CVEs?  you're fast!
[18:05] <mdeslaur> kees: east coast ftw
[18:05] <jdstrand> totally :)
[18:05] <kees> heh
[18:05] <kees> well, let me do the 27 bugs that're New.  At least two are embargoed issues I need to submit.
[18:06] <kees> which brings me to publications -- I'll be doing a number of embargoed publications for things this week.
[18:06] <kees> and finding syncs etc.
[18:06] <mdeslaur> syncs?
[18:06] <kees> no real news, but we should think about anything we want to put in the monthly report
[18:06] <kees> mdeslaur: fake-syncs from Debian
[18:06] <mdeslaur> oh!
[18:07] <kees> and we should start brain-storming for UDS
[18:07] <kees> we've got our very own track again.  :)
[18:07] <jdstrand> kees: re syncs> fyi, check later in the week, we should be up to date as of friday)
[18:07] <kees> jdstrand: yeah, you're all too fast for me.  :)
[18:08] <kees> I think that's it.  I might be trying to chase down beta-bugs (raid1 installs, kernel IO, aa memory, etc)
[18:08] <jdstrand> well, I did it on Friday. one could say I was too slow... I'll take the praise though
[18:08]  * mdeslaur sends some praise to jdstrand 
[18:09] <kees> heh
[18:09] <kees> mdeslaur: is up
[18:09] <jdstrand> maybe not 'too' slow, since it was within the allotted time, but slow nonetheless ;)
[18:09] <jdstrand> mdeslaur: :)
[18:09] <nxvl> kees: they are making you look slower...
[18:09]  * kees cries
[18:09] <jdstrand> oh no!
[18:09] <mdeslaur> I'll take a look at the openssl issues this week.
[18:09] <mdeslaur> I'm also on triage, so I'll be doing that also
[18:09] <jdstrand> kees does great things all the time that we aren't talking about right here :)
[18:10] <mdeslaur> and I'll take a look at Lucid cves to make sure we're all caught up
[18:10] <kees> hehe
[18:10] <mdeslaur> jdstrand: +1
[18:10] <kees> oh yeah, we should start walking the "almost released" checklist too
[18:10] <kees> it's a bit confused what with 2 betas, but still.
[18:11]  * jdstrand was just thinking the same thing
[18:11] <mdeslaur> I also want to document the actions/rights permissions in Ubuntu
[18:13] <kees> mdeslaur: oh! yeah, that's really cool.  I'm looking forward to that.
[18:15] <kees> mdeslaur:
[18:15] <kees> er
[18:15] <jdstrand> mdeslaur: shall I go?
[18:15] <kees> you done?
[18:15] <mdeslaur> oh sorry
[18:15] <mdeslaur> yes :)
[18:15] <jdstrand> hehe
[18:15] <mdeslaur> got my foot stuck in the email trap :)
[18:15] <kees> heh
[18:16] <nxvl> evil e-mail trap
[18:16] <jdstrand> ok, I'm happy place this week. I plan to pull the lever on clamav/dapper, have an erlang update, an embargoed update, a moin merge (for security update in lucid) and a little more work on apparmor-notify
[18:17] <jdstrand> apparmor-notify wasn't dealing with log rotation-- I fixed that for kern.log over the weekend, but need to fix it for when it drops privs (ie auditd)
[18:17] <kees> jdstrand: oh, I've disabled parallel profile loading for now since it makes the AA memory-pressure thing worse.  haven't uploaded it though, but it is tested.
[18:18] <jdstrand> kees: cool-- I turned on apparmor-notify too. so let's coordinate before the other wants to upload
[18:18] <jdstrand> (apparmor-notify is not installed by default and in universe, so this way, installing it will enable it)
[18:18] <jjohansen> \o/
[18:19] <kees> jdstrand: I'll put it in your court -- if you're ready to upload, go for it.  I'm set, but I'm not uploading it for a bit since jj and I are still mucking around with test kernels and stuff
[18:19] <jdstrand> we probably need to discuss whether to disable apparmor-notify before release, but me feeling is probably no, since it is opt-in at present
[18:19] <jdstrand> kees: ack
[18:19]  * kees agrees
[18:19] <jdstrand> ok
[18:19] <jdstrand> all that was the 'little stuff' for the week
[18:19] <mdeslaur> If the package doesn't get installed by default, it can be turned on by default
[18:19] <mdeslaur> +1 form me
[18:19] <jdstrand> my big effort is to fix my last 3 blueprint items for libvirt
[18:20] <jdstrand> due to upstream changes, just getting a newer version to run with apparmor took some work last week. I now have a merge of 0.7.7-4 (from Debian) that works
[18:20] <jdstrand> plan is to upstream my stuff and then to 0.7.7-4
[18:21] <jdstrand> I suggested that the server team consider my merge for lucid
[18:21] <mdeslaur> jdstrand: you want to get 0.7.7 in?
[18:21] <jdstrand> (see email in ubuntu-server@)
[18:21] <mdeslaur> jdstrand: that may require virtinst and possible virt-manager
[18:21] <jdstrand> mdeslaur: I do, but it is up to ubuntu-server
[18:21] <jdstrand> mdeslaur: I'm pretty sure it will work better with virt-manager, since you have such a newer version in lucid iirc
[18:22] <mdeslaur> the dependencies between those components are unclear to me
[18:22] <jdstrand> mdeslaur: the merge is in my ppa, please feel free to play with it, but read my email in ubuntu-server
[18:23] <mdeslaur> jdstrand: I did read your mail....and I freaked out about the "libvirt chown's the disk files to root:root for people using qemu:///system." part
[18:23] <jdstrand> I will be working with kirkland one day this week to verify it is ok. if they accept it, then I won't have to backport my patches to 0.7.5 (what is currently in lucid). otherwise, I will
[18:23] <jdstrand> mdeslaur: yeah-- I didn't much like that either :(
[18:24] <mdeslaur> "How to become root in 3 easy steps..."
[18:24] <jdstrand> mdeslaur: it seems it is part of the DAC security driver work from upstream
[18:25] <jdstrand> mdeslaur: well, if you are in the libvirtd group (ie can use qemu:///system), you have root (though not trivially)
[18:25] <jdstrand> mdeslaur: that has always been the case (see README.Debian in lucid's libvirt)
[18:26] <jdstrand> anyway, that chown thing needs to be looked at more/fixed, probably by the server team
[18:27] <jdstrand> that is it from me, though I have two items to discuss
[18:27] <mdeslaur> shoot
[18:28] <jdstrand> ok. I'm not totally satisfied with universe triage
[18:29] <kees> it's a wasteland :(
[18:29] <jdstrand> while we deal with supported packages and the community is supposed to triage universe stuff, it doesn't happen
[18:29]  * jdstrand nods
[18:29] <jdstrand> now that people are starting to discover and write about UCT, maybe there are little things we can do to at least improve the situation somewhat
[18:30] <jdstrand> I thought of two things, neither of which are perfect, but both will help some
[18:30] <jdstrand> a) unconditionally use the version mentioned in MITRE's CVE (when available) as 'upstream: release (...)'
[18:31] <mdeslaur> ugh
[18:31] <jdstrand> we can then have automation to check Ubuntu versions and mark then 'not-affected' with all others as 'needed'
[18:31] <jdstrand> mdeslaur: hold on a sec-- I'll justify this in a moment ;)
[18:31] <mdeslaur> ok :)
[18:33] <jdstrand> b) we (manually) check Debian for a fixed version and add it to upstream: released (...) through automation of some sort, and then adjust not-affected releases
[18:34] <jdstrand> ok. I totally admit that this is imperfect-- MITRE gets the versions wrong sometimes (and we would have to figure out how to deal with when they take a vendor's version and say it is affected)
[18:34] <kees> so, I already do "a" but only when the wording from Mitre is specific.  I.e. "Foo before version XYZ, is vuln..." rather than "Foo version XYZ in vuln"
[18:34] <kees> their "before version XYZ" tends to be triggered by upstreams claiming to fix stuff.
[18:34] <jdstrand> that said-- I think that putting something in there that is accurate most of the time is better than nothing in there. we/community members can adjust the CVEs as needed
[18:35] <kees> for "b" we need the changelog-CVE-scanner back online.
[18:35] <kees> when Debian fixes stuff, I'll use a debian version for the upstream: released line
[18:35] <jdstrand> kees: well, 'b' doen't have to be automatic, but it would be nice if it was
[18:35] <kees> right.
[18:35] <jdstrand> kees: re Debian version> right, so do I
[18:35] <kees> I think the big thing to help with visibility is getting cve-tracker mirrored into LP.
[18:36] <jdstrand> and when I do fake syncs I update the CVEs that they fix
[18:36] <kees> unfortunately, that's still stuck on bug 314432
[18:36] <jdstrand> I don't think as a team we do 'a' consistently
[18:36] <jdstrand> ie, there are a gagillion 'needs-triage'
[18:37] <mdeslaur> I don't do 'a', as I don't like marking things "not-affected" when the code hasn't been looked at
[18:37] <jdstrand> kees: agreed on that
[18:37] <kees> that's possible about "a".  I tend to do it, but I've found it somewhat rare for Mitre to say "before version X.Y.Z"
[18:37] <mdeslaur> too often I've seen it not fixed in the version that mitre has there
[18:37] <mdeslaur> I've been burned by that before
[18:37] <jdstrand> I see 1.6.x before 1.6.2 all the time
[18:37] <mdeslaur> and false negatives are a lot worse than false positives
[18:38] <kees> mdeslaur: oh, for those I don't mark 1.5.x not-affected.  I _really_ don't trust that.
[18:38] <jdstrand> and sure, it will have errors. but is having nothing better? maybe it is, but I think not
[18:38] <kees> I feel like forward-versions are safe.
[18:38] <mdeslaur> so you guys just mark the "upstream" line with a version?
[18:38] <jdstrand> I was talking about forward versions.
[18:38] <jdstrand> eg, 1.5.2 is fixed. therefore 1.5.3 is fixed
[18:38] <mdeslaur> what are "forward versions"?
[18:39] <mdeslaur> so you _do_ mark 1.5.3 as not-affected
[18:39] <kees> while it's sometimes wrong, most times it's correct for "it has been fixed in version X.Y.Z"  but I always leave stuff older (even unmentioned earlier release series) as needs-triage
[18:39] <jdstrand> mdeslaur: I'm proposing we do that for universe, yes
[18:40] <mdeslaur> ok, from now on, "in xyz before 1.5.3", we mark upstream as 1.5.3, and anything we have that's 1.5.3 and more recent, we mark as not-affected?
[18:40] <jdstrand> if nothing else, I think it would be a good start to formalize how we should triage these
[18:40] <kees> mdeslaur: if I see Mitre say "Foo 1.3.x before version 1.3.7 is vulnerable..."  I will mark 1.3.7 and later in the 1.3.x series as fixed, but any other versions needs-triage (i.e. 1.4.x 1.2.x)
[18:40] <jdstrand> then maybe from there, we can automate
[18:41] <kees> scripts/sync-from-versions already auto-closes stuff in the devel release if it's higher than the upstream: released version
[18:41] <mdeslaur> should we be more vigilant when the cves-run updates descriptions?
[18:41] <kees> oh, that's a good point -- I never adjust triaging from updated descriptions.
[18:41] <mdeslaur> when/who runs sync-from-versions?
[18:41] <jdstrand> I don't
[18:41] <kees> I run sync-from-versions any time I'm on triage or run sync-from-usns
[18:42] <kees> it intentionally only closes devel.
[18:42] <jdstrand> wait-- I don't sync-from-versions. I do adjust triaging from updated descriptions
[18:42] <mdeslaur> hahaha
[18:42] <mdeslaur> I don't run sync-from-versions, I don't adjust triaging from updated descriptions
[18:42] <jdstrand> heh
[18:43] <mdeslaur> and I've hit wrong "before 1.x.x" in descriptions on almost all mysql cves
[18:43] <jdstrand> well, technically, I referring to community stuff here, so it isn't horrible that we do different things
[18:43] <jdstrand> I really just want to identify if we can standardize it and see if after that we can do some things automatically
[18:43] <kees> mdeslaur: sure, I will take exception with "known poorly triaged" software.  the kernel, firefox, and mysql jump to mind.
[18:44] <jdstrand> all of those are not community supported
[18:44] <jdstrand> I am *only* talking about universe/multiverse
[18:44] <mdeslaur> so, what's the ultimate goal here? to get rid of universe CVEs automatically when old distros get retired?
[18:44] <kees> the policy I've been working under has been that universe stuff is marked as not-affected if it is the most recent series, and mitre says "before [version-from-that-series]"
[18:44] <jdstrand> mdeslaur: that already happens
[18:45] <jdstrand> mdeslaur: we do a big EOL thingamajig
[18:45] <kees> mdeslaur: to keep the devel release of ubuntu up to date as new versions of software land in the archive.
[18:45] <jdstrand> kees: I do that
[18:46] <jdstrand> what I used to do differently is that I would mark versions under that as 'needed'
[18:46] <kees> for that series, yeah, I'd do the same.
[18:46] <jdstrand> (being careful of multiple branches)
[18:46] <jdstrand> however, lately I've noticed mdeslaur doing those as needs-triage, and I've fallen into that myself
[18:47] <jdstrand> and by lately, I mean the last 6 months or so (roughly)
[18:47] <kees> i.e. if we have 1.2.4, 1.3.2, 1.3.3, 1.4.0, and mitre says "before 1.3.3", I would marked: 1.2.4: needs-triage, 1.3.2: needed, 1.3.3: not-affected, 1.4.0: needs-triage
[18:47] <mdeslaur> jdstrand: so you would blindly mark them as "needed" without actually looking at them?
[18:47] <jdstrand> kees: I like that
[18:47] <kees> sorry, "1.3.x before 1.3.3"
[18:47] <jdstrand> mdeslaur: for *universe*, I would do as kees said, yes
[18:47] <kees> if it said just "before 1.3.3", I'd mark 1.2.4 as needed too
[18:48] <jdstrand> right
[18:48] <jdstrand> I'd like to get back to that, and hopefully automate it, if possible
[18:48] <jdstrand> if not automate, the script it
[18:48] <mdeslaur> ok, I don't mind doing that
[18:48] <mdeslaur> although, I don't know what it will gain us
[18:48] <mdeslaur> but, I can do it
[18:48] <jdstrand> I think overall it will gain us more accuracy
[18:49] <jdstrand> (granted, not 100%)
[18:49] <mdeslaur> more completed, but less accurate :P
[18:49] <kees> accuracy by way of less bit-rot as we move forward in time.
[18:49] <jdstrand> I also think that if UCT says it is affected, then someone will be more likely to fix it
[18:49] <kees> i.e. filling in upstream: released future-proofs us a bit
[18:50] <mdeslaur> kees: okay, that sounds valid
[18:50] <jdstrand> practically speaking, if it says 'needs-triage', community people aren't going to look at it. if it says it is needed, then we have a chance
[18:50]  * kees nods
[18:51] <mdeslaur> well then we should change them all to needed :)
[18:51] <jdstrand> which is what I tried to get at with 'accuracy'
[18:51] <mdeslaur> ok, fair enough, so 1.2.x is needs-triage, 1.3.x is needed, 1.4.x is not-affected
[18:52] <jdstrand> (ie, needs-triage translates to 'not-affected' or 'ignored' to community folk)
[18:52] <mdeslaur> It may be worth spending a day or two to go through all the universe CVEs and actually retire a slew of them
[18:52] <mdeslaur> ie: a one-time thing
[18:52] <mdeslaur> I wouldn't mind doing that
[18:52] <kees> I wonder if we should use a UDS slot for a mass-ancient-CVE-triage-jam
[18:52] <jdstrand> as in, follow our new procedure for what is in there?
[18:53] <jdong> well what about a context with a prize for the most RMS-worthy beard?
[18:53] <jdong> errrr
[18:53] <jdong> wrong channel
[18:53] <mdeslaur> jdong: lol
[18:53] <jdstrand> I would say so ;)
[18:53] <jdong> hahaha
[18:53] <kees> omg, thank goodness because my eyes just about popped out of my head trying to jam that into context
[18:53] <jdong> new theme and active window border contrast.
[18:53] <jdong> grumble XD
[18:53] <mdeslaur> jdstrand: I would like to spend a few hours and triage the universe CVEs to get rid of half of them
[18:54] <kees> mdeslaur: do you think there are a lot that will fall into this?
[18:54] <mdeslaur> it may be easier to get some community help if we didn't have CVE-2006 stuff in there
[18:54] <mdeslaur> kees: yes, I think so
[18:54] <jdstrand> I brought this up once before, I think that as far as UCT is concerned, we should treat all universe CVEs as non-LTS
[18:54] <jdstrand> ie, dapper/universe becomes 'ignored'
[18:55] <kees> mdeslaur: well, since you're the most sceptical of this plan, I think you're the right person to do it.  :)  I don't want to get too aggressive with it, as you said, since I don't want to start losing accuracy
[18:55] <jdstrand> then people can triage them away from ignored if they want to maintain it
[18:55] <kees> jdstrand: I disagreed with you at the time, but after a few months of messing with dapper and triage, I'm convinced.
[18:55] <mdeslaur> I'm convinced also
[18:55] <mdeslaur> dapper universe = ignored
[18:56] <kees> +1
[18:56] <jdstrand> +1
[18:56] <kees> ship it! :)
[18:56] <mdeslaur> +7
[18:56] <kees> hehe
[18:56] <jdstrand> what about hardy?
[18:56] <kees> 9 votes for!
[18:56] <jdstrand> intrepid is eol on april 30th
[18:56] <kees> jdstrand: hardy isn't eol yet
[18:56] <kees> jdstrand: you must have meant something I misunderstood :)
[18:57] <mdeslaur> jdstrand: when hardy goes eol on the desktop, we should do the same
[18:57] <jdstrand> kees: if universe != LTS, then hardy/universe is EOL
[18:57]  * kees agrees.  I think it's a fine policy
[18:57] <mdeslaur> oh, hmm
[18:57] <jdstrand> mdeslaur: kde in hardy is not LTS
[18:57] <kees> jdstrand: oh! er, I understood that the way mdeslaur just said it: once desktop is EOL, then treat universe as ignored for an LTS
[18:57] <jdstrand> kees: that was most of what I was saying
[18:58] <jdstrand> however, it gets tricky with LTS
[18:58] <mdeslaur> I would rather wait for desktop to get EOL
[18:58] <jdstrand> (which is a subset of what I was getting at)
[18:58] <kees> right, so let's treat universe like desktop as far as CVE tracking goes
[18:58] <jdstrand> mdeslaur: which desktop? gnome, kde, xfce? :P
[18:58] <kees> desktop==gnome
[18:58] <mdeslaur> what's "kde" and "xfce"?
[18:58] <kees> heh
[18:58] <jdstrand> hehe
[18:58]  * mdeslaur slaps himself for saying that out loud
[18:59] <mdeslaur> we love kde
[18:59] <jdstrand> I'm fine with universe -> ignored on LTS after 3 years
[18:59] <kees> I think for triage, we should extend universe triage to match the "desktop" lifetime.
[18:59] <jdstrand> however, I think 'ignored' is more accurate
[19:00] <mdeslaur> and people can still submit debdiffs on server stuff, which we'll sponsor until the server goes EOL
[19:00] <jdstrand> (since it really is being ignored by far most of the time)
[19:00] <jdstrand> shoot, I'll sponsor *anything* if it is ok
[19:00] <kees> heh
[19:01] <mdeslaur> jdstrand: cool, I've got a gutsy open-jdk debdiff for you to review
[19:01] <kees> right, "ignored" matches the reality of it most closely.
[19:01] <mdeslaur> not
[19:01] <jdstrand> mdeslaur: that's not ok :P
[19:01] <kees> heh
[19:01] <kees> you've gone TOO FAR!  :)
[19:01] <jdstrand> hehe
[19:02] <jdstrand> let's summarize our discussion (I'll do it)
[19:02] <kees> jdstrand: here or offline?
[19:03] <kees> jdstrand: it should probably get reflected in the UCT README too
[19:03] <jdstrand> 1. universe CVEs for eol released should follow the eol for the release (ie desktop/universe is 3 years for LTS, 5 years for server/universe, and 18 months everywhere else
[19:03] <mdeslaur> kees: is there a script to set dapper universe to ignored?
[19:03] <jdstrand> kees: gosh, here-- anyone reading this will need it! :)
[19:03] <kees> jdstrand: heh yeah
[19:04] <mdeslaur> jdstrand: no, server/universe should be 3 years for LTS
[19:04] <kees> mdeslaur typed it faster
[19:04] <mdeslaur> jdstrand: we don't have a way of separating desktop from server in universe
[19:04] <kees> right
[19:04] <mdeslaur> unless someone wants to volunteer, in which case we can revert
[19:04] <kees> 1. universe CVEs for eol released should follow the eol for the release (ie desktop/universe is 3 years for LTS, 5 years for server)
[19:04] <mdeslaur> (volunteer to figure out the seeds)
[19:05] <jdstrand> 2. look carefully at MITRE versions. if it has a 'fixed in' or less than, adjust 'upstream' field accordingly. mark later versions as 'not-affected' and earlier as 'needed. be careful and leaves as 'needs-triage' if status is not clear for multiple branches (ie 1.2 vs 1.4)
[19:05] <kees> er, now we need a summary of the summary
[19:05] <mdeslaur> lol
[19:05] <kees> 2: +1
[19:05] <mdeslaur> 2: approved
[19:05] <jdstrand> 3. use Debian version as 'upstream: released' whenever possible
[19:06] <kees> 3: use Upstream version as 'upstream: released' whenever possible, but it's okay to use Debian versions too.
[19:06] <jdstrand> kees' resummary of '1': +1
[19:06] <kees> i.e. prefer Upstream over Debian, but don't be shy of Debian versions.
[19:06] <jdstrand> hmm
[19:06] <mdeslaur> kees: why prefer upstream?
[19:06] <jdstrand> ah, I didn't get to add a thought I had
[19:06] <kees> mdeslaur: because it more directly tracks to real fixes in the future.
[19:07] <jdstrand> 'upstream' can have multiple releases in it
[19:07] <jdstrand> eg:
[19:07] <kees> i.e. if 1.3.4 is fixed.  1.3.4-32940 will be fixed too
[19:07] <jdstrand> upstream: released (1.2.6, 1.4.0rc1)
[19:07] <mdeslaur> ok, I don't have a preference there
[19:07] <mdeslaur> jdstrand: won't that break scripts?
[19:07] <kees> jdstrand: yeah, we skipped that a bit.  I'm not sure how to handle it.  sync-from-versions skips anything with a comma in it.
[19:07] <jdstrand> mdeslaur: it is already supported
[19:07] <kees> is it?
[19:07] <jdstrand> oh, err
[19:08] <mdeslaur> I did not know that!</carson>
[19:08] <jdstrand> well, I can't speak to sync-from-versions
[19:08] <jdstrand> I don't use it-- multiple versions works in other places
[19:08] <kees> we could add the seris logic to sync-from-versions
[19:08] <jdstrand> (and there are plenty of examples in UCT)
[19:09] <jdstrand> ok, on '3': use Debian version as 'upstream: released (<debian version>)' where appropriate
[19:09] <kees> jdstrand: why prefer Debian over Upstream?
[19:10] <jdstrand> though in the past, if I have a choice between 1.2.3-1 and 1.2.3, I chose 1.2.3-1 every time
[19:10] <kees> that'll miss 1.2.3-0ubuntu1
[19:10] <jdstrand> kees: my resummary of '3' intended to not prefer Debian 'ie 'as appropriate')
[19:10] <kees> which is why I like Upstream
[19:11] <mdeslaur> How about debian if it's a version lower than upstream?
[19:11] <mdeslaur> ie: Upstream: 1.2.3, Debian: 1.2.2-14, prefer debian
[19:11] <jdstrand> kees: yes, but when I have done that I have looked at the version in lucid). I'm convinced though
[19:11] <jdstrand> reresummary:
[19:12] <jdstrand> 3. prefer prefer upstream version to Debian version in 'upstream', except where it is fixed in Debian and no info on upstream version is available
[19:12] <jdstrand> s/prefer//
[19:12] <kees> mdeslaur: yeah, that's cool; that's basically how it works out.  usually I use a Debian version if it says "broken in 1.2.3" (i.e. no upstream fix yet) and Debian has released 1.2.3-2 with a patch.
[19:12] <kees> 3: +1
[19:12]  * jdstrand nods
[19:13] <jdstrand> alright, I'll add all this to UCT/README and we can finetune from there. I think this has taken enough time
[19:14] <jdstrand> I have one other item that won't be nearly as contentious :)
[19:14] <kees> ready!
[19:14] <mdeslaur> just so we can get started, kees: is there a script that can mark dapper universe as ignored?
[19:14] <mdeslaur> jdstrand: shoot
[19:14] <kees> mdeslaur: there's a commandline, one sec
[19:14] <jdstrand> isn't that in UCT/README already?
[19:14] <kees> jdstrand: yeah
[19:14] <kees> mdeslaur: it's under "Stable Release Actions"
[19:14] <kees> adjust devel_ to dapper, etc
[19:15] <jdstrand> in lucid, apt is frustrating for me
[19:15] <kees> wait, sync-from-eol.py ?
[19:15]  * jdstrand waits on changing the subject
[19:15] <kees> mdeslaur: yes! check sync-from-eol.py -- it'll need adjustment
[19:16] <mdeslaur> ok, thanks
[19:16] <mdeslaur> I'll take a look
[19:16] <kees> okay, I'm ready for subject change
[19:16] <jdstrand> well, now I have a question on the last thing
[19:16] <jdstrand> what are we changing dapper/universe to? eg:
[19:17] <jdstrand> dapper_foo: needed -> dapper_foo: ignored (reached end-of-life)?
[19:17] <mdeslaur> sync-from-eol isn't mentioned in README
[19:17] <jdstrand> mdeslaur: there is an 'End of Life' section in README
[19:17] <jdstrand> it may need to be adjusted
[19:18] <mdeslaur> ok, I'll check it out
[19:19] <jdstrand> 13:16 < jdstrand> what are we changing dapper/universe to? eg:
[19:19] <jdstrand> 13:17 < jdstrand> dapper_foo: needed -> dapper_foo: ignored (reached  end-of-life)?
[19:19] <jdstrand> kees, mdeslaur: ^
[19:19] <mdeslaur> well, I wouldn't put "end-of-life" there
[19:19] <kees> jdstrand: yup, agreed.  ignored (reached end-of-life)
[19:19] <kees> oh
[19:19] <mdeslaur> I'd just set it to "ignored"
[19:19] <mdeslaur> technically, server packages in universe are not end-of-life
[19:20] <kees> sync-from-eol.py sets it to "ignored (EOL)"
[19:20] <jdstrand> mdeslaur: why? we've done '(reached end-of-life)' in the past for supported?
[19:20] <mdeslaur> jdstrand: not sure what you mean by that
[19:21] <jdstrand> kees: I think if we state the reason, we should use '(reached end-of-life)' instead of '(EOL)'. less jargony
[19:21] <kees> jdstrand: +1
[19:21] <jdstrand> mdeslaur: you want 'ignored'. I want 'ignored (reached end-of-life)'. why do you prefer yours over mine?
[19:21] <mdeslaur> on dapper, server packages in universe are not technically end of life
[19:22] <jdstrand> I now of only one that receives regular support: clamav
[19:22] <jdstrand> s/now/know/
[19:22] <jdstrand> I think 'ignored' will make people go, 'why?'
[19:23] <kees> mdeslaur: that was my original objection, but I gave in since "ignored" matches reality for it.
[19:23] <mdeslaur> hmm
[19:23] <jdstrand> we/the community can triage/retriage away from ignored if desired
[19:23] <mdeslaur> let me think a sec
[19:23] <jdstrand> this isn't set in stone or anything
[19:23]  * mdeslaur smells burning
[19:24] <jdstrand> we run sync-from-eol only once per cycle
[19:24] <mdeslaur> ok, I accept
[19:24] <mdeslaur> EOL it is
[19:24] <mdeslaur> +1
[19:24] <jdstrand> we can adjust boilerplate to ignore dapper/universe but we always have the opportunity to edit it
[19:25] <jdstrand> ok cool
[19:25] <jdstrand> so, now we are ready for my next item?
[19:25] <mdeslaur> yes!
[19:25] <jdstrand> ok
[19:25] <jdstrand> apt is frustrating to me in lucid because it tries to be too smart. maybe I am doing things wrong, but when I do this:
[19:26] <jdstrand> apt-get source foo=<earlier version than latest>
[19:26] <jdstrand> it will often (though not always) grab the latest version
[19:26] <kees> jdstrand: yes, drives me insane.
[19:26] <jdstrand> adjusting the ordering of sources.list can help somewhat, but not totally
[19:27] <jdstrand> fake-security-sync is basically broken until you hack your sources.list
[19:27] <kees> jdstrand: I worked around it with: $UST/package-tools/u-getsrc
[19:27]  * jdstrand goes to look
[19:28] <mdeslaur> is there a bug open for that issue?
[19:28] <jdstrand> mdeslaur: it is by design
[19:28] <jdstrand> it is so you can do things like:
[19:28] <jdstrand> deb http://localmirror/...
[19:28] <jdstrand> deb http://archive.ubuntu.com/...
[19:28] <kees> jdstrand: oh, perhaps it's just the addition of --only-source that fixes it?
[19:29] <jdstrand> it will get from the local mirro runless a newer version is in archive.ubuntu.com
[19:29] <mdeslaur> how the heck can that be by design if you specify a version
[19:29] <jdstrand> kees: I was going to ask about that-- it is in no way clear to me why u-getsrc works better
[19:29] <mdeslaur> the design is wrong :P
[19:29] <kees> jdstrand: can you reproduce this?  I don't see this problem.
[19:30] <jdstrand> mdeslaur: oh yes-- the changes are by design, this issue may not be and may be a bug (sorry)
[19:30] <jdstrand> kees: if I have deb-src lines for ubuntu and debian, then I can see it
[19:31] <jdstrand> kees: do you have deb-src lines for everything?
[19:32] <jdstrand> eg
[19:32] <kees> jdstrand: I do, yes.
[19:33] <jdstrand> well, I'll try to reproduce and it can be discussed outside of the meeting
[19:33] <jdstrand> I'm done
[19:33] <kees> okay, cool.  anything else?
[19:33] <mdeslaur> nopers
[19:33] <mdeslaur> anyone?
[19:33] <mdeslaur> Bueler? Bueler?
[19:34] <kees> meeting over, thanks everyone!  :)
[23:58]  * genii makes a large pot of coffee, hands out the mugs
[23:59] <DarkwingDuck> ohhh. free mugs
[23:59] <apachelogger> free coffee!
[23:59] <DarkwingDuck> my mug is ugly so I'm happy for a new one
[23:59] <paultag_> I totally just ordered an Ubuntu mug ;)