| hggdh | infinity: I finally have the armada under control, tomorrow I will start coding & running the kernel tests on it | 03:12 |
|---|---|---|
| infinity | cjwatson: Hrm. I wonder if the whole "having to override everything again after copy from proposed to release" thing might actually have something to do with the race between britney both deleting and copying at the same time. | 03:40 |
| infinity | cjwatson: Maybe leaving it no pubs to copy the overrides from? | 03:41 |
| cjwatson | infinity: Mm, possibly. FromExistingOverridePolicy.calculateSourceOverrides does include "SourcePackagePublishingHistory.status.is_in(active_publishing_status)". | 03:58 |
| cjwatson | We could drop it if we caused something (sru-report?) to deal with the removals automatically. I don't want it to be manual. | 03:59 |
| * cjwatson -> bed, finally | 04:00 | |
| === doko_ is now known as doko | ||
| === yofel_ is now known as yofel | ||
| Laney | that reminds me | 10:14 |
| infinity | Err. | 10:17 |
| infinity | You accepted it with that version number? Really? | 10:17 |
| infinity | Ick. | 10:17 |
| infinity | Oh, you're the one who uploaded it with that version. :P | 10:18 |
| Laney | that's the backports versioning scheme | 10:18 |
| Laney | ick away | 10:18 |
| infinity | It... Is? | 10:18 |
| infinity | With two ubuntus? | 10:18 |
| Laney | yeah | 10:18 |
| infinity | 0.8.0~rc1-4ubuntu38~12.04.1 makes more sense, surely. | 10:18 |
| infinity | Where is this scheme documented? | 10:19 |
| Laney | the second is for sorting purposes | 10:19 |
| Laney | probably on some mailing list, and in the code for backportpackage | 10:19 |
| infinity | For sorting against what? Uploads that have a-t words there? | 10:19 |
| Laney | We used to use ~SERIES<number>, then had the foresight to fix that before we wrapped around the alphabet (and before we got to 'u'-series) | 10:20 |
| infinity | I recall being involved in this conversation. | 10:21 |
| infinity | And pointing out that switching to ~<number> solves it fine, since backports are backports of new versions... | 10:21 |
| infinity | So 1.2.3-1~oneiric1 will still be << 1.2.3-2~11.10.1 | 10:22 |
| infinity | Which is fine. | 10:22 |
| infinity | And right. | 10:22 |
| infinity | Any clash that ~ubuntu11.10.1 is trying to solve doesn't actually exist. | 10:22 |
| Laney | All I can think of is re-backporting over the top of existing ones. Dunno. I didn't have these conversations - IIRC it was Colin and Evan at UDS-Q. | 10:28 |
| Laney | or P? | 10:28 |
| === mmrazik is now known as mmrazik|lunch | ||
| Riddell | cjwatson: remember that conversation about removing owncloud and how it can't be done? seems I did remove it as far as launchpad is concerned in precise but not as you said from the archive https://launchpad.net/ubuntu/+source/owncloud | 11:13 |
| infinity | Riddell: Sure, it can be removed from LP, but precise won't ever be republished, so that's meaningless. | 11:18 |
| infinity | Riddell: But, why did you do such a thing? :P | 11:18 |
| Riddell | infinity: lots of security issues in owncloud and upstream asked for it to be removed | 11:19 |
| infinity | It would seem to me that the solution to "upstream says it's insecure" is to fix it, not delete it. | 11:19 |
| infinity | Since deleting it doesn't magically get it off people's systems. | 11:19 |
| Riddell | upstream's solution is to upgrade to the latest | 11:19 |
| Riddell | but a backport isn't possible even if ~ubuntu-sru would be happy to do that as an update | 11:20 |
| cjwatson | Riddell: That was, I think, what I said :) | 11:20 |
| infinity | Not possible? | 11:20 |
| cjwatson | Nothing will *ever* republish the release pocket indices | 11:21 |
| infinity | cjwatson: Sorry, that "not possible" was to Riddell's assertion that the package can't be backported. | 11:21 |
| cjwatson | So yes, OK, at one point LP forgot to sanity-check removal | 11:21 |
| infinity | Riddell: Why is it "not possible"? | 11:21 |
| cjwatson | infinity: Yeah, I understood | 11:21 |
| Riddell | infinity: too many third party modules needed which all need to be updated too many of which require other dependencies to be updated | 11:21 |
| === mmrazik|lunch is now known as mmrazik | ||
| infinity | Riddell: Is upstream willing to hilight what these security holes are, instead of just saying "iz broke, update it"? | 11:22 |
| infinity | Riddell: And do they have, I dunno, some sort of VCS where perhaps they fixed these things? | 11:23 |
| Riddell | infinity: yes, but no patches http://owncloud.org/security/advisories/ | 11:23 |
| infinity | Oh lord, it's PHP. | 11:24 |
| infinity | Cause I've never seen badly-written PHP before. | 11:24 |
| Riddell | right | 11:24 |
| infinity | Looks like their recent advisories actually point to git commits. | 11:25 |
| infinity | Divining the fixes for the older ones from logs might not be too hard. | 11:25 |
| doko | infinity, next eglibc give back? | 11:32 |
| infinity | doko: *sigh*.. Yes. Different test failed this time. The previous one passed. If it explodes one more time, I'll reupload with the suite checker disabled (since I know it's fine) so gcc can build. | 11:34 |
| doko | thanks | 11:34 |
| infinity | But not happy about this. Need. Real. ARM. Hardware. That. Isn't. Cell phones. | 11:34 |
| ogra_ | chromebooks for the DC ! | 11:38 |
| === chilicuil is now known as chilicuil_away | ||
| ogra_ | hmm, so do i add the slideshow back to the arm images at the risk of having nexus7 get to big or not ... | 11:40 |
| cjwatson | tumbleweed: I've belatedly merged and deployed your madison-lite cache locking fix; thanks! I made one correction; you'd missed a take_cache_read_lock call when constructing the cache for a Sources file. | 12:15 |
| cjwatson | So hopefully rmadison will be faster now. | 12:16 |
| Daviey | cjwatson: still intolerably slow? Will it take a while for the cache to be hot? | 12:22 |
| Daviey | Ooo, first attempt was 17 seconds.. second was 3 | 12:22 |
| cjwatson | It still has to recache any time the archive changes. | 12:25 |
| cjwatson | But it won't forkbomb lillypilly in the process. | 12:25 |
| Daviey | cjwatson: well that is good news | 12:39 |
| tumbleweed | cjwatson: ah, so I did | 13:00 |
| tumbleweed | cjwatson: still seems dog slow, though :/ | 13:02 |
| cjwatson | It's certainly not a panacea | 13:03 |
| tumbleweed | I could have just been the first caller after a publish | 13:03 |
| tumbleweed | it seems snappier now | 13:03 |
| didrocks | so, we have some kind of on ongoing debate and trying to understand how the promotion/demotion list works… | 14:34 |
| didrocks | if I take gstreamer0.10-plugins-base-doc, it's not installed by default and the rdepends doesn't seem as well | 14:34 |
| didrocks | (and it's in main) | 14:34 |
| didrocks | it's not on the demotion list: http://people.canonical.com/~ubuntu-archive/component-mismatches.txt | 14:35 |
| didrocks | but on this list, there is libatk-adaptor-data | 14:35 |
| didrocks | which has its source in main and other binary package of this source rdepending/seeded | 14:35 |
| didrocks | so while this binary package (which hasn't a rdepends in main) is in this list, and not the -doc? | 14:35 |
| didrocks | is there a special filters for -doc, -dbg? | 14:36 |
| didrocks | (the debates is about if we promote some -utils/debug tools, do we need to add it to a seed or not and promoting the whole source, but first, I would prefer to understand the rule for something being on the promotion/demotion list ;)) | 14:38 |
| cjwatson | see seeds/ubuntu.raring/supported | 14:38 |
| cjwatson | libatk-adaptor-data should be seeded explicitly somewhere if you want it in main | 14:39 |
| cjwatson | Anything that matches the Extra-Include patterns in the supported seed doesn't need to be seeded explicitly | 14:39 |
| didrocks | ah ok, so there is indeed some pattern for -doc, -dbg and so on in this Extra-Include | 14:40 |
| didrocks | thanks for the explanation cjwatson :) | 14:40 |
| cjwatson | Please note that the promotion/demotion list isn't calculated that way directly - it's a delta between the current state of the archive and what germinate says should be in main. It's quite important to understand this otherwise you'll get confused (e.g. you might think that things currently in main are treated differently somehow) | 14:40 |
| * didrocks reread | 14:41 | |
| cjwatson | If you're adding things explicitly then they may perhaps want to go somewhere like platform.raring/supported-SOMETHING-desktop instead of directly in supported | 14:41 |
| cjwatson | This is used for a crazy scheme to try to autogenerate vaguely correct support lifetimes | 14:41 |
| didrocks | cjwatson: I don't want to touch this libatk-adaptor-data (I'll let it to Luke), but I wanted to understand the difference between this one and the -doc and others one ;) | 14:42 |
| cjwatson | Yeah, I can understand how it might not be obvious | 14:42 |
| didrocks | cjwatson: I still don't get the "it's a delta between current state of the archive and what germinate says should be in main" | 14:42 |
| didrocks | the only diff is a lag of one day? (well, since last daily iso) | 14:43 |
| cjwatson | No | 14:43 |
| cjwatson | There's no lag | 14:43 |
| cjwatson | forget about ISOs, they're irrelevant | 14:43 |
| * didrocks forgets ;) | 14:43 | |
| cjwatson | the publisher runs germinate at the end of every run | 14:43 |
| cjwatson | this takes the seeds and dependency-expands them with respect to the current archive (considering all components) | 14:44 |
| didrocks | until then, makes sense | 14:44 |
| cjwatson | component-mismatches takes the output of the part of that germinate run for the Ubuntu seed collection | 14:45 |
| cjwatson | (i.e. not Kubuntu etc. - only ubuntu.raring is currently constrained to be in main) | 14:45 |
| cjwatson | and says "OK, all packages in the output of germinate for Ubuntu should be in main" | 14:46 |
| cjwatson | then it compares that against what's actually in main in the archive, and the output of that comparison is what you see | 14:46 |
| didrocks | yeah, that was my understanding :) so I think I missed a possible steps of misunderstanding you were afraid I had? | 14:47 |
| didrocks | like, you need to be attach to a seed "root node" (or calling it something like that) | 14:47 |
| didrocks | it's not only checking relationships betweens package in main, they need to be "attached" to this tree | 14:47 |
| cjwatson | OK, so one confusion that sometimes arises is with virtual packages | 14:48 |
| cjwatson | let's say you depend on a virtual package which is provided by real packages in main and in universe | 14:49 |
| cjwatson | sometimes people believe that the one in main will be preferred, because it's in main | 14:49 |
| cjwatson | but that isn't the case - germinate (at least in the publisher configuration) doesn't care, because it's the *output* of germinate that determines what goes in main | 14:49 |
| cjwatson | it's certainly also true that a package can't stay in main without being referred to either directly or indirectly by the Ubuntu seed collection | 14:50 |
| didrocks | ah ok, I've alread fallen into that trap few years ago ;) so used to it and knowing it needs to be explicit | 14:50 |
| cjwatson | (where that indirectness includes build-dependencies) | 14:50 |
| didrocks | yeah, there are deps and build-deps as relationship | 14:51 |
| cjwatson | and recommends | 14:51 |
| didrocks | indeed :) | 14:51 |
| cjwatson | (usually) | 14:51 |
| didrocks | cjwatson: everything is crystal clear! Thanks a lot for all the precisions | 14:51 |
| ogra_ | sigh, i wish FRAMEBUFFER for the initrd could be somehow decoupled from pulling plymouth in | 14:52 |
| cjwatson | NP. I look forward to your germinate patches? ;-) | 14:52 |
| cjwatson | Grr, why is linux-signed-* *still* not on the precise images | 14:53 |
| didrocks | cjwatson: ahah, there was a trap! I was sure about it ;) (more seriously, is there some area (I guess tricky if you didn't get to them yet) where some work is needed?) | 14:54 |
| stgraber | cjwatson: oh, that reminds me that I need to test the new images to confirm that they now boot on my system. Will do that after our weekly meeting. | 14:55 |
| cjwatson | Actually the code is pretty solid nowadays; the main problem is that documentation consists of "ask Colin how it works" | 14:55 |
| cjwatson | germinate is python3-compatble and has a test suite and everything ... | 14:55 |
| cjwatson | the main outstanding problem is that there's some hysteresis in the publisher | 14:55 |
| didrocks | nice ;) yeah, doc, as usual… | 14:56 |
| cjwatson | germinate is run at the end of each publisher run, and is an input to the *next* publisher run | 14:56 |
| didrocks | hysteresis? really? | 14:56 |
| cjwatson | so in theory it's unstable | 14:56 |
| didrocks | ah | 14:56 |
| didrocks | yeah | 14:56 |
| cjwatson | also, the publisher doesn't necessarily notice that germinate output has changed and so it needs to republish | 14:56 |
| cjwatson | the fix is to call germinate in the middle of the publisher, with package data directly from the Launchpad DB | 14:56 |
| cjwatson | I tried that a while ago but it was hopelessly slow because I was a bit naïve about how to do bulk DB operations | 14:57 |
| cjwatson | need to try again | 14:57 |
| didrocks | interesting project, but yeah, calling every package with launchpad regular APIs… I can imagine it beeing very slow | 14:57 |
| === mmrazik is now known as mmrazik|otp | ||
| cjwatson | didrocks: Well, it wouldn't be the API, it'd be direct database access | 15:09 |
| cjwatson | Or at most a special-purpose internal API | 15:09 |
| cjwatson | Package copies (including promotions from raring-proposed to raring) are going to be queued for a while due to a hardware upgrade of the relevant script server | 15:20 |
| cjwatson | Package copies should be back no | 16:03 |
| cjwatson | w | 16:03 |
| cjwatson | (for a while actually) | 16:04 |
| cjwatson | ^- part of the SB extravaganza - could somebody review? | 16:51 |
| Riddell | what's the secret to uploading to quantal-security? | 16:58 |
| cjwatson | Riddell: You can't upload directly; only the security team is allowed to copy into it | 17:03 |
| cjwatson | get them to issue a USN etc. | 17:03 |
| Riddell | ] | 17:05 |
| Riddell | ## | 17:05 |
| Riddell | ]=44~=;;;########## | 17:05 |
| Riddell | # | 17:05 |
| Laney | (look how much he hates talking to the security team) | 17:07 |
| xnox | Riddell: patches on a bug + subscribe ubuntu-security | 17:07 |
| xnox | Riddell: or ubuntu-security-sponsors something like that. | 17:08 |
| === rickspencer3_ is now known as rickspencer3 | ||
| === henrix_ is now known as henrix | ||
| === henrix is now known as henrix_ | ||
| === henrix_ is now known as henrix | ||
| === rtg is now known as rtg-afk | ||
| === henrix is now known as henrix_ | ||
| slangasek | cjwatson: appmenu-gtk/precise accepted now.. but I see that the quantal one is still in the queue :) | 19:54 |
| slangasek | (along with some other, older ones) | 19:54 |
| seb128 | slangasek, great, one SRU in, only 90 to go, you can do it ;-) | 19:56 |
| slangasek | heh | 19:56 |
| ogra-cb | is this a sprint ? | 19:56 |
| seb128 | ogra-cb, it's a competition between the sponsoring queue and the SRU queue | 19:56 |
| seb128 | dholbach is leading by a small margin | 19:56 |
| slangasek | if my wife stops making me get on planes on my SRU days, I should be able to make some progress | 19:56 |
| * ogra-cb looks for his pompoms to cheer from the side | 19:57 | |
| seb128 | we need to stop the 6 months cycle madness and just keep the LTSes | 19:58 |
| * seb128 got annoyed recently about the number of SRU requests for quantal, the rational behind them makes sense but it's a lot of efforts spent | 19:59 | |
| slangasek | seb128: not all SRU requests need to be accepted? | 20:00 |
| stgraber | seb128: rationale being that they want those in quantal so they can push to precise? | 20:00 |
| seb128 | slangasek, it's hard to say not to request to fix an obvious stopper bug in a stable release | 20:00 |
| ogra-cb | slangasek, but processed | 20:00 |
| seb128 | not->no | 20:01 |
| ogra-cb | or at least looked at | 20:01 |
| ScottK | seb128: Probably fewer SRUs if people follow the release schedule and land features on time so that stuff can get fixed before release. | 20:01 |
| seb128 | ScottK, well, at lot of those are from !canonical, e.g GNOME in my case | 20:01 |
| ogra-cb | ScottK, nah, that kills all the fun of releasing with bugs | 20:01 |
| ScottK | seb128: True, but many of them are also self inflicted. | 20:01 |
| seb128 | right, but those are mostly fine, the unity guys are doing regular bug fixe releases so it's contained on a few component (e.g mostly unity and compiz and sometime some lenses) | 20:02 |
| seb128 | slangasek, I just did a libvirt SRU today because XDG_RUNTIME_DIR broke it and it was late and we didn't notice before release :p | 20:03 |
| seb128 | well, anyway if good faith if we roll stable release we need to fix obvious bugs | 20:03 |
| seb128 | doing that on 6 months basis is high cost ... looking forward the day we can do rolling release between LTSes ;-) | 20:04 |
| ScottK | Rolling release is an oxymoron. | 20:04 |
| seb128 | well, do it the debian way if you prefer | 20:06 |
| seb128 | e.g keep rolling on the unstable cycle for 1.5 years than take 6 month to do a solid release | 20:06 |
| ScottK | Might as well use Debian then. | 20:06 |
| ScottK | Having the regular releases is one of the main reasons I initially chose Ubuntu over Debian. | 20:07 |
| seb128 | like the only thing Ubuntu is doing is to snapshot Debian every 6 months? | 20:07 |
| ogra-cb | not really | 20:07 |
| ogra-cb | we develop features through applying different glue, the snapshotting is only a minimal part of a cycle imho | 20:08 |
| seb128 | well anyway, I didn't want to start an heated discussion | 20:08 |
| seb128 | but I've been annoyed by the numbers of SRUs I had to do to quantal recently | 20:09 |
| seb128 | I wish we only had precise and raring to care about at this point | 20:09 |
| ogra-cb | yes, we simply shouldnt do SRUs for non LTS by policy | 20:10 |
| xnox | seb128: lucky you with desktop lts. I was working on sponsoring server sru's into lucid the other day..... | 20:10 |
| slangasek | seb128: IMHO that's a decision you should be empowered to make | 20:10 |
| seb128 | well, it's embarassing to have a "release" out with things broken in a so obvious way | 20:10 |
| ogra-cb | xnox, well, that difference is gone now | 20:10 |
| seb128 | xnox, that time is over since precise | 20:11 |
| xnox | ogra-cb: true. but it will only be evident past 2015 april. | 20:11 |
| ogra-cb | indeed | 20:11 |
| xnox | ogra-cb: the ticking bomb has been set off =) | 20:11 |
| seb128 | slangasek, I can't in good faith ignore those bugs in a stable release... we flagged quantal as being one so we need to deal with it | 20:11 |
| ogra-cb | hehe | 20:11 |
| seb128 | xnox, well, lucid is still supported on the desktop as well... | 20:12 |
| xnox | seb128: true.... but i take it doesn't have many desktop sru requests? | 20:13 |
| seb128 | xnox, likely not | 20:14 |
| seb128 | desktop people tend to like more the shiny stuff | 20:14 |
| seb128 | so they tend to update | 20:14 |
| * xnox is sad, I upgraded to raring to get python3.3 by default..... that counts as shiny, right?! | 20:17 | |
| ogra-cb | does it wobble if you move it ? | 20:18 |
| ogra-cb | s/does/can/ | 20:18 |
| slangasek | anyone know what happened with gst-plugins-good1.0 landing in component-mismatches? | 20:19 |
| ogra-cb | not MIRed yet ? | 20:19 |
| slangasek | ogra-cb: in main since forever | 20:19 |
| ogra-cb | 1.0 ? | 20:19 |
| slangasek | ah, looks like the armel-only binaries have been demoted to universe for some reason | 20:19 |
| ogra-cb | note that gstreamer carries the version in the package names ... 1.0 is pretty new | 20:20 |
| slangasek | ogra-cb: oh, so it is | 20:20 |
| slangasek | ok | 20:20 |
| cjwatson | slangasek: 'queuediff -s quantal-proposed appmenu-gtk' is confusing - what was going on with ubuntu1.1 there? | 20:28 |
| jbicha | having an Ubuntu release before the GNOME .1 release is a good way to cause more SRU work | 20:30 |
| cjwatson | it looks OK, and I think is what we agreed - just rather oddly formatted | 20:30 |
| cjwatson | oh, I see, that version was removed | 20:30 |
| cjwatson | never mind | 20:30 |
| slangasek | yep | 20:30 |
| ScottK | jbicha: The Ubuntu releases land at the KDE .1 or (usually) .2 and I've always thought that was a good thing. | 20:31 |
| jbicha | I just think the maverick early October experiment has outlived its usefulness | 20:32 |
| cjwatson | that wasn't even useful when it happened | 20:32 |
| seb128 | ogra-cb, slangasek: we decided that gst1 doesn't need MIRs since it's the same source that gst0.10, only a new revision ... same as gtk2 and gtk3 | 20:34 |
| seb128 | but yeah it got promoted today | 20:35 |
| slangasek | yes, agreed | 20:35 |
| slangasek | I was just confused that 1.0 != 0.10 ;) | 20:35 |
| cjwatson | there you go | 20:36 |
| slangasek | ta :) | 20:38 |
| infinity | jbicha: You're TIL on user-mode-linux, any plans to rev it to 3.7.0? | 21:37 |
| jbicha | infinity: I only touched it becuase it was NBS, you're welcome to grab it if you like | 21:57 |
| infinity | jbicha: Sure, I wasn't sure if you had a vested interest in it or if it was a +1 drive-by. | 21:58 |
| infinity | I'd suggest Ubuntu needs a concept of a "QA Upload", like Debian, except that would litter about 98% of our changelogs. | 21:58 |
| infinity | So, probably not useful. :P | 21:58 |
| ScottK | If the same person uploads more than N times in a row to Ubuntu, ask them before you touch it ... | 22:32 |
| infinity | ScottK: That's my general rule. UML gets uploaded so infrequently, though, it's hard to tell if it has a primary maintainer in any meaningful way. | 22:33 |
| infinity | (And the answer seems to be "no", which is fine) | 22:34 |
| cjwatson | Could somebody have a look at livecd-rootfs/precise-proposed, please? Part of the SB backport work and I'd like to get it into tomorrow's image builds. | 23:34 |
| infinity | cjwatson: Will poke. | 23:49 |
| infinity | cjwatson: Needs a reupload with -v to catch the previous changelog, but I'll do that on your behalf if I like the rest of it. | 23:50 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!