| === hyperair is now known as Guest93522 | ||
| === Tonio__ is now known as Tonio_ | ||
| === jsgotangco is now known as greeneggsnospam | ||
| === greeneggsnospam is now known as jsgotangco | ||
| === juliux_ is now known as juliux | ||
| === unimix_ is now known as unimix | ||
| === Seeker`_ is now known as Seeker | ||
| === Seeker is now known as Seeker` | ||
| === jamie_ is now known as JamieBennett | ||
| === soren_ is now known as soren | ||
| === txwikinger2 is now known as txwikinger | ||
| === yofel_ is now known as yofel | ||
| robbiew | kees: meeting today? | 18:01 |
|---|---|---|
| kees | robbiew: yup! just gathering notes | 18:01 |
| 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:02 |
| mdeslaur | It doesn't save me a thing | 18:03 |
| kees | yeah | 18:03 |
| kees | okay, starting... | 18:03 |
| 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:04 |
| 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:05 |
| 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:06 |
| 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:07 |
| 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:08 | |
| 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:09 |
| 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:10 |
| * jdstrand was just thinking the same thing | 18:11 | |
| mdeslaur | I also want to document the actions/rights permissions in Ubuntu | 18:11 |
| kees | mdeslaur: oh! yeah, that's really cool. I'm looking forward to that. | 18:13 |
| 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:15 |
| 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:16 |
| 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:17 |
| 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:18 |
| 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:19 |
| 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:20 |
| 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:21 |
| 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:22 |
| 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:23 |
| 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:24 |
| 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:25 |
| jdstrand | anyway, that chown thing needs to be looked at more/fixed, probably by the server team | 18:26 |
| jdstrand | that is it from me, though I have two items to discuss | 18:27 |
| mdeslaur | shoot | 18:27 |
| jdstrand | ok. I'm not totally satisfied with universe triage | 18:28 |
| 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:29 |
| 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:30 |
| 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:31 |
| 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:33 |
| 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:34 |
| 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:35 |
| 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 |
| ubottu | Launchpad bug 314432 in malone "It's impossible to see all the bugs that affect a BugTarget if some bugs are targeted to one or more series and the Master task is closed" [High,Triaged] https://launchpad.net/bugs/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:36 |
| 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:37 |
| 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:38 |
| 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:39 |
| 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:40 |
| 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:41 |
| 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:42 |
| 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:43 |
| 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:44 |
| 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:45 |
| 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:46 |
| 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:47 |
| 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:48 |
| 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:49 |
| 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:50 | |
| 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:51 |
| 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:52 |
| 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:53 |
| 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:54 |
| 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:55 |
| 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:56 |
| 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:57 |
| 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:58 | |
| 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 | 18:59 |
| 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:00 |
| 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:01 |
| jdstrand | let's summarize our discussion (I'll do it) | 19:02 |
| kees | jdstrand: here or offline? | 19:02 |
| 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:03 |
| 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:04 |
| 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:05 |
| 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:06 |
| 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:07 |
| 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:08 |
| jdstrand | ok, on '3': use Debian version as 'upstream: released (<debian version>)' where appropriate | 19:09 |
| kees | jdstrand: why prefer Debian over Upstream? | 19:09 |
| 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:10 |
| 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:11 |
| 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:12 | |
| jdstrand | alright, I'll add all this to UCT/README and we can finetune from there. I think this has taken enough time | 19:13 |
| 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:14 |
| 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:15 |
| 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:16 |
| 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:17 |
| mdeslaur | ok, I'll check it out | 19:18 |
| 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:19 |
| 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:20 |
| 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:21 |
| 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:22 |
| 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:23 | |
| 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:24 |
| 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:25 |
| 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:26 |
| 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:27 | |
| 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:28 |
| 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:29 |
| 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:30 |
| jdstrand | kees: do you have deb-src lines for everything? | 19:31 |
| jdstrand | eg | 19:32 |
| kees | jdstrand: I do, yes. | 19:32 |
| 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:33 |
| kees | meeting over, thanks everyone! :) | 19:34 |
| * genii makes a large pot of coffee, hands out the mugs | 23:58 | |
| 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 ;) | 23:59 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!