[00:06] stgraber: 1796KB> that + 2MB is much less than the 7MB we were over, so that's much better than expected, no? [00:12] slangasek: indeed. The dailies were 7MB bigger than the 12.04 release, but we were quite a bit below the limit at that time. So now with infinity's fix we are at 6MB more than at 12.04 which is 1.8MB more than the CD limit. [00:12] ah [00:13] so, did package size analysis show where the rest of the bytes have gone? [00:15] I guess this is infinity's pastebin from earlier: http://paste.ubuntu.com/1133208/ [00:17] .3MB growth in linux-image; .1MB+.3MB growth in linux-headers; .1MB growth in mdadm, which is probably just the deliberate addition of mdmon so nothing we can do about it; libreoffice-help-en-us: .5MB; firefox: 1.0MB; thunderbird: 1.4MB; libreoffice-base-core: .8MB [00:17] those should probably all be looked at [00:18] the last is particularly interesting, the .8MB delta is a 900% increase :P [00:19] ah, the package size in precise release was anomalous [00:23] - readd move of libdbalo.so to -base-core (closes: #670350) [00:24] that's from libO changelog; deliberate change [00:24] * micahg would like to know how to generate stats like the above for xubuntu images [00:25] micahg: let me check whether the script is shared somewhere [00:26] thanks, xubuntu has issues with space and it would be nice to see what exactly happened between precise and quantal [00:26] it is not; for some reason it's not even checked into bzr :/ [00:27] and the libO change is both deliberate and correct (AFAICS), the .so was moved from libreoffice-base which is not on the CD, to libreoffice-base-core which is [00:27] * micahg will accept an e-mail copy or /path/to/foo on some internal server if it's not publicly shareable [00:28] can be later, I won't have time to use it until later in the week anyways [00:28] micahg: mailed [00:28] slangasek: thanks [01:58] stgraber: I take it the live-build test was a success? [01:59] stgraber: Ahh, yes, I see your verification on the bug; thanks. [06:27] Hi gang, sorry I've been a bit absent lately. I understand we're supposed to test the 12.04.1 images, correct? I'll whip up some testing on Xubuntu, and look after Studio as well. === jpds_ is now known as jpds === lynxman- is now known as lynxman [09:08] there is no i386 build for Precise and Quantal core, desktop and wubi for the last 3 days [09:09] for wubi, amd64 is on cdimage.u.c but not the checksum files [09:10] the i386 builder is broken [09:10] rt #55115 [09:12] ok, thanks [09:15] could somebody put bug #969359 back from private? [09:15] users should been able to lock random bugs this way, some random user set it as a security and private bug [09:15] when it's neither of those [09:15] it's a g-s-d using cpu bug [09:15] * Laney can't see it [09:17] ask webops on #launchpad-ops internal [09:19] shouldn't* [09:19] cjwatson, thanks === doko__ is now known as doko === seb128_ is now known as seb128 [11:06] skaet: kubuntu 12.04.1 daily images are good from the testing http://iso.qa.ubuntu.com/qatracker/milestones/204/builds [13:23] cjwatson: Is the package set update script somewhere where someone like me could run it and see what would be added to the (for example) kubuntu package set if you did an update? [13:28] ScottK: lp:~cjwatson/+junk/packageset - fetch http://people.canonical.com/~cjwatson/packagesets, run ./packageset-push.py -n packagesets [13:28] it's, er, not exactly productised [13:28] Sure. Thanks. [13:29] is that much different from running update.sh in the metapackage ? [13:30] Entirely. [13:30] It's dealing with package sets, not metapackages. [13:30] k [13:30] The latter will probably be a subset of the former. Ish. [13:35] I'm going to hazard a guess it's been awhile since you ran that ... [13:39] It didn't actually pick up the ones I hoped it would (ktp-*), so I'm not in a great rush though. [14:00] Yeah [14:00] Let me go and poke it now [14:07] Thanks Riddell. :) [14:12] ScottK: done [14:12] Thanks. [14:16] thanks astraljava, yes, testing of the 12.04.1 daily images right now to make sure no surprises would be appreciated. [14:22] cjwatson: I synced ghc to proposed this morning. Ideally I'd like to do the whole transition there and then copy over. Do you think it's feasible to do that given the size of the stack? [14:22] We'll also need to teach ben about proposed too. [14:25] Ahaha. Um. [14:26] Tracking it will be hell for somebody. [14:26] yeah? [14:27] I don't know anything about how good the tools there are. [14:27] They aren't. [14:27] hoho [14:27] TBH this seems like exactly the kind of thing we can't feasibly do yet. [14:28] Needs britney-style automation. [14:31] I wondered whether ben's output would be good enough [14:41] Laney: "ben" being the transition tracker? It might be good enough to get by for this. Not that the neverending ghc transition ever seems to be in perfect shape anyway. :/ [14:42] yes. [14:42] it does get done when someone applies enough force to it [15:37] Do release notes exist for dot releases? [15:37] yes [15:37] Thanks [15:38] There will be some arriving soon :) [15:38] rbasak: ok :) I don't think the wiki page was created yet, but it's on skaet's todo for this week I believe [15:38] rbasak: will probably be at https://wiki.ubuntu.com/PrecisePangolin/ReleaseNotes/12.04.1 [15:40] This is for a couple of highbank kernel bugs that have fixes but may not make the release. Is adding ubuntu-release-notes tasks ok until the page is ready? [15:41] yep, IIRC we have a 12.04.1 milestone available on the ubuntu-release-notes project [15:42] Thanks [15:42] rbasak, release notes exist. I've snapshotted off the 12.04 original ones, so feel free to edit the release note pages in the standard spot now. [15:43] https;//wiki.ubuntu.com/PrecisePangolin and then put the details in the product specifically. [15:43] * skaet will get that email sent out tomorrow [15:48] rbasak, for server - put changes: https://wiki.ubuntu.com/PrecisePangolin/ReleaseNotes/UbuntuServer [15:50] rbasak, original release notes are now at: https://wiki.ubuntu.com/PrecisePangolin/ReleaseNotes/UbuntuServer/UbuntuServer-12.04 [15:50] for instance [16:09] skaet: rbasak: here's the release notes bug - https://bugs.launchpad.net/eilt/+bug/1034042 [16:09] Ubuntu bug 1034042 in ubuntu-release-notes "Calxeda ESX-1000 kernel disk detection and network reliability caveats for 12.04.1" [Undecided,New] [16:09] mahmoh: you should probably add the linux task to that too? [16:11] it needs a milestone/release added, which I cannot do [16:13] * skaet kicking off a rebuild of the ubuntu desktop on nusakan to see if its picking up the i386 builds properly now. [16:14] * skaet should have put ARCHES on... sorry. [16:45] /ws/ws 17 [16:45] grrr [16:47] infinity: looking at http://people.canonical.com/~ubuntu-archive/transitions/ghc.html it might not be worth bothering doing it in proposed [16:48] any opinion? [16:49] mahmoh, I've added a milestone to it. [16:51] Laney: Yeah, that was what I was refering to when I said it wasn't in the best shape. [16:52] infinity: It'll be a fair bit worse. But I doubt it matters. [16:52] fancy copying it over? [16:53] Laney: Sure. [16:53] ta [16:53] Done. [16:53] let the games begin [16:55] and may the odds be ever in your favor. [16:55] * infinity heads out for a bit. [16:57] * Laney offloads the rebuilds to jocarter [16:59] Laney: I'm happy to help out a bit as a "spare time" thing after-hours. I'm pretty good at robotic rebuilds and transitions. :P [17:01] skaet: thx [17:05] infinity: Nice, thanks. I tend to prefer to sync where possible, but perhaps there isn't so much of that due to the freeze. You might find that some of the API changes for 7.4 have not have made it over yet. === seb128_ is now known as seb128 [17:22] slangasek: been looking into the size delta for firefox and thunderbird, it's mostly two files (libxul and omni.ja) that are taking an extra 2MB, so not much we can do there I guess [17:23] I also did a few tests at rebuilding the biggest packages in /pool with xz but that'd only save around 5kB so not really worth it [17:36] stgraber: rebuilding with xz also doesn't help at all for live CDs [17:36] oh, you mean the ones in /pool [17:36] yeah [17:36] slangasek, infinity: looks like we'd be saving 2.0MB of compressed squashfs size if we were to drop the -updates, -proposed and -security lists entry in /var [17:36] but keeping these for the release pocket [17:36] ok [17:36] that would be enough to get us over, yeah? [17:37] yep [17:37] we'd have an extra 300KB that might end up being used with the refreshed slideshow (potentially extra translations) [17:38] so if there's no big downsides you can think of, it looks like this would work [17:38] I'm assuming these pockets will be changing just a few days after release if not even before release, so most people will need to re-download anyway [17:39] do check that the installer still works right if you do that [18:29] -rw-r--r-- 1 root root 735830016 Aug 7 14:29 iso.iso [18:29] repacked iso without the lists [18:29] will do a test install to confirm ubiquity doesn't explode with that [18:40] SRU TEAM: We have the following uploads in the precise queue that are on the 12.04.1 list: light-themes (requested by Edubuntu), network-manager, dnsmasq, mythtv (MRE and exception granted yesterday by TB) [18:41] when doing reviews, please start by these, then continue with these uploaded before 21:00 UTC on the 2nd of August [18:44] stgraber: well, RAOF is on Tuesdays and it's no longer Tuesday there ;) I guess I can take a look at some today [18:44] thanks slangasek [18:44] slangasek: yeah, and I somehow assumed RAOF would be on paternity leave, haven't checked canonicaladmin though [18:45] ah, good point [18:45] ScottK, do you have some bandwidth to help trim down the queue today for the SRUs? [18:46] I should also have a live-build change uploaded soonish, might try to get infinity to take a look at the change before uploading though [18:46] * skaet nods [18:47] I'm almost done with an install using out-of-media langpacks + updates + extras, will then run another run without connectivty. I suppose that should be enough testing for that change. [18:47] skaet: Neither the time kind nor the network kind (getting my car serviced and stuck connecting via a 3G tether). [18:48] stgraber: Did you just do the purging in the cruft-removal hook (where dbus IDs and other junk get purged)? [18:48] cjwatson: Given that we used to purge apt lists in livecd-rootfs, unless ubiquity has since developed a dependency on not doing so, it shouldn't break. [18:49] (But definitely worth double-checking) [18:50] ScottK, ack. [18:50] infinity: yeah, plan was to use ./scripts/build/lb_chroot_hacks though I'm not sure whether we want to check for something in the environment or just always do it [18:51] stgraber: Always. [18:51] stgraber: Otherwise, we could inadvertently make the installer depend on post-release pockets in the devel release and be unpleasantly surprised when we don't in a point release. [18:54] stgraber: "rm -f /var/lib/apt/lists/*-{updates,security,proposed}*" should do it. [18:54] stgraber: Which is totally not POSIX shell, so pre-expand that. :P [18:55] infinity: http://paste.ubuntu.com/1134752/ [18:56] stgraber: -security_ (etc) [18:56] stgraber: Otherwise, you whack source with security/proposed/updates in the hostname or path. [18:57] good point [18:57] (Not an issue for official media, but could be for someone doing a home-brew thing) [18:58] stgraber: Also, where't the bug closure, and the upload to quantal? Slacker. ;) [18:58] infinity: hehe, making sure it works first ;) still one test install to go [19:01] stgraber: Anyhow, if it breaks, it's a ubiquity bug anyway, since there's no way it should be doing an apt-get install without first doing an update. [19:01] stgraber: As the lists on the media could have been stale. [19:02] indeed [19:02] infinity: mind moving the current live-build to -updates? it's clearly been tested and it's very unlikely anyone else would be using it from -proposed [19:04] stgraber: Sure. [19:05] stgraber: Done. [19:08] infinity: live-build uploaded to precise and quantal [19:14] stgraber: Is queuebot dead? [19:15] stgraber: Anyhow, reviewed and accepted. [19:16] stgraber: You'll probably want to prod webops to install that by hand on kapok for another round of testing. [19:16] stgraber: roseapple should spit out a .deb momentarily. [19:17] infinity: will do [19:18] looks like we've got i386 build capacity again, anyone waiting on a specific image before the next round of dailies? [19:18] not me. I'll be interested by a round of rebuilds when we get the new live-build to confirm we're no longer oversized [19:19] stgraber: And built: https://launchpad.net/ubuntu/+source/live-build/3.0~a24-1ubuntu32.2/+build/3708989/+files/live-build_3.0%7Ea24-1ubuntu32.2_all.deb [19:19] jibel: any more info on bug 1029531? it's the next one on my list of potential critical issues for 12.04.1 to investigate [19:19] Launchpad bug 1029531 in update-manager "cdromupgrade from Lucid to Precise failed with unmet dependencies without network connection" [Critical,Confirmed] https://launchpad.net/bugs/1029531 [19:24] second test install without the extra lists worked fine (installing in a foreign language with extras and no connectivity) [19:24] stgraber: mythtv SRU processed [19:25] slangasek: thanks [19:25] stgraber: NB: I didn't say accepted ;P [19:26] slangasek: what was wrong with it? [19:26] stgraber: includes SRU-inappropriate changes to the packaging [19:27] including one change not mentioned in the changelog at all, and another only relevant for python3 apport [19:27] MRE doesn't cover random packaging changes [19:27] ok [19:27] (commented in bug #1029522) [19:27] Launchpad bug 1029522 in mythtv "Newer version of MythTV fixing some major bugs needs an SRU" [Undecided,Fix released] https://launchpad.net/bugs/1029522 [19:30] skaet: FYI I queued an amd64 daily-live build of ubuntu on precise to test the new live-build (webops just deployed it on kapok for testing) [19:37] stgraber: what ensures that other sessions are not affected by the changes in light-themes? [19:38] (the comment in bug #955376) [19:38] Launchpad bug 955376 in salience "Text color under Ambiance in top panel of GNOME Classic is dark gray instead of white" [Undecided,In progress] https://launchpad.net/bugs/955376 [19:38] jbicha: ^ [19:41] slangasek: I believe that only gnome-session-fallback uses gnome-panel and the matching css class, but I'm not a user of that myself, so jbicha should be able to confirm or give more details on that [19:41] ok [19:41] slangasek: Yeah, that element isn't used by the default unity-ish session. [19:41] so there are other changes besides adding the :backdrop [19:42] (This does, I think, also fix a bug with trying to use ambiance with xfce, which I long ago gave up on trying to do) [19:44] slangasek: You mean the changes for #986988? [19:44] Edubuntu is mostly interested by that line "-PanelMenuBar-icon-visible: true;" the rest was already stacked for SRU and so ended up going with the same upload [19:44] Yeah, the lack of Application menu icon is a bit of wart. [19:45] infinity: bug #955376 [19:45] Launchpad bug 955376 in salience "Text color under Ambiance in top panel of GNOME Classic is dark gray instead of white" [Undecided,In progress] https://launchpad.net/bugs/955376 [19:46] slangasek: Right, but you said there were other changes too. [19:46] infinity: yeah and I was only made aware of that issue 4 days before release (not using that alternate gnome session myself), so didn't really want to respin the world for an Edubuntu specific issue in a secondary desktop environment ;) [19:47] infinity: see the diff? [19:47] slangasek: Yeah, I'm looking at it. [19:48] slangasek: Half of it is fixing the color issues, the other half is fixing the missing panel icon. [19:48] slangasek: (And then the dropping of the patch that wasn't being applied anyway) [19:49] slangasek: Seems sane to me, for all that my GTK3 theming is a bit sketchy. [19:49] infinity: half of it is *changing* colors in a context not specific to the :backdrop class. What's missing is the rationale for why this is guaranteed to be a fix for all users, and not a regression for some [19:49] is there any plan from the SRU team to review packages uploaded before the .1 freeze soon? [19:49] the patch doesn't match the description of the patch [19:49] we should probably get them moving to users if we want them validated on time [19:49] seb128: yep, some of that is being done nowish [19:49] great [19:49] seb128: do you have specific packages in mind? [19:49] seb128: well, starting by these that are specifically targeted to the point release, then rest of the queue [19:50] I intentionally skipped over totem and rhythmbox because these do not appear to be high-priority or targeted to the point release [19:50] slangasek, totem rhythmbox sqlite3 xserver-xorg-video-intel gst0.10-python transmageddon [19:50] those were not all uploaded before the freeze [19:50] slangasek, I think they are trivial and would make an consequent user impact [19:50] slangasek: Oh, all the stuff for the .button classes? [19:50] the only ones still in the queue that were uploaded before the freeze are rpcbind, rhythmbox, totem [19:50] slangasek, they = totem rhythmbox [19:51] slangasek, no, sqlite3 was uploaded before the freeze, I made sure of that [19:51] like 1 hour before, but before ;-) [19:51] seb128: I looked at them and did not reach the same conclusion that they were trivial [19:51] slangasek: I'd assumed they exposed that it was always broken/wrong when they actually put a button on the panel. But you're right, it seems to be lacking some description. [19:51] seb128: heh, ok; last week when I looked, LP told me it was uploaded just after the freeze deadline, but maybe it lied. I can review it [19:51] slangasek, they just add a one line "Keyword" line to their .desktop for dash searchability ... was is non trivial? [19:51] slangasek, well totem does [19:52] seb128: um, let me double-check [19:52] rhythmbox does include another fix to get mp3 encoding to default to an ok quality format [19:52] rb would require a freeze exception for gst0.10-python [19:52] which I uploaded after the deadline [19:52] not sure what process we have for .1 freeze exceptions [19:52] which is linked to the gst0.10-python transmageddon fixes [19:53] slangasek, diff from 3.3.4-0ubuntu1~precise1 to 3.0.1-0ubuntu21.1 (1.5 MiB) [19:53] the queue is on crack [19:53] slangasek: To be honest, the gnome-panel theming with ambiance in precise is so awful, I can't see how any change could be called a regression. :P [19:53] not sure what is 3.3.4-0ubuntu1~precise1 come from [19:53] slangasek: Even if they decide to make it pink and flashing. [19:53] but precise has 3.0.1-0ubuntu21 [19:53] seb128: yes, I looked at the actual diff, not just the crack one [19:54] slangasek, let me know if I screwed up, the diff should be a one line Keywords added to the .desktop [19:54] seb128: right; the totem one is trivial, but the bug is also marked 'low' importance - which means it's at the end of my priority list [19:54] I can put it High if that helps :p [19:54] the rhythmbox one is non-trivial [19:54] it's low priority but trivial with a real user impact [19:55] I don't see why it should be disgarded, I made sure it was uploaded on time [19:55] because it's not a priority [19:55] stgraber: How goes the test on kapok? [19:55] slangasek, want me to tweak the bug settings? ;-) [19:55] why didn't you tweak them /before/? [19:56] I think you're being disingenuous to suggest now that this is a priority for the point release [19:56] because I though things specifically targetted to .1 were targetted for a reason [19:56] I think the fact that no one targeted it to .1, or marked it as priority higher than 'low', reflects the real priority [19:56] i.e that the milestone itself was enough of a reason [19:56] this wasn't targeted [19:56] doh, forgot to milestone it? [19:56] * jocarter learns a nice new word [19:56] I didn't that now [19:57] slangasek, well, it's not a priority but as said it's a trivial fix with a real impact on the user experience [19:57] I honestly though that any upload made before freeze would be considered [19:57] if it's not a priority, I'm not spending time on it, trivial or otherwise [19:57] that's why I didn't bother more with bug settings [19:57] well, I spent time on it making sure it was uploaded on time [19:57] I guess we have a communication issue there [19:58] I assumed that anything uploaded before freeze would be considered [19:59] I wouldn't have worked on it if I didn't want it to be in .1, especially not time while I was not at work (I did took an hour at GUADEC to get those uploaded) [19:59] stgraber: Oh, it's stuck behind a DVD build, I see. :P [19:59] the light-themes patch has been in quantal for more than 2 months & I haven't heard any complaints that it caused any problems [20:00] stgraber: I'm not disputing that you want it in; I'm saying that by my reading it's a misprioritization, and that your decision to upload it doesn't impose on the release team an obligation to include a low-prio bugfix in the point release [20:00] slangasek, I guess that was for me? [20:00] jbicha: however, that's not the threshold for SRUs [20:00] seb128: er yes, sorry [20:01] slangasek: have you tried GNOME Classic w/ Compiz in Precise? it's obviously rather broken [20:01] slangasek, ok, noted, I will not argue over that, I will know for next time that the freeze limit is "freeze for what rt considers important" and not "freeze for uploads", my mistakes [20:01] I was addressing the regression potential [20:01] -s [20:02] jbicha: I haven't and won't. The point is that I don't think you've established that this won't regress for those using the theme in other contexts [20:02] slangasek, that's different from the freeze rule for normal release btw [20:02] "no one has complained" doesn't establish that there are no regressions [20:02] usually we don't punish uploaders because reviewers are behind [20:03] light-themes is actually one of the oldest pending precise SRU's; it was kicked out of -proposed because of paperwork [20:04] seb128: I don't think reviewers being behind was an issue here at all. Based on the dates, it looks to me like these two packages were skipped over by several reviewers - probably for similar reasons that I've given for my own skipping [20:04] slangasek, the rules (for unstable cycles at least) has always be "things uploaded before the freeze date will be considered" [20:04] jbicha: and I think the paperwork is still not in order, because you're saying "Other sessions could not be affected" and I don't see why that's true [20:05] seb128: I considered it [20:05] "consider" != "accept" [20:05] slangasek: Well, it can only affect sessions that run gnome-panel... [20:05] well, usually consider is accept or reject with a reason [20:05] not "let it sit there ignored and miss the target" [20:05] infinity, jbicha: oh! Sorry, I completely missed the *filename* [20:06] infinity, jbicha: pardon my blindness [20:07] (Or things that pretend to be gnome-panel, which some other desktop environment sometimes do, but I assure you that they are SO broken with Ambiance/Radiance, that they can't be made worse) [20:07] But Unity definitely does no such pretending anywhere. [20:07] slangasek, anyway enough arguing, it's your call at the end, I will feel free to made a comment if one of the .1 reviews says that typing DVD in the dash returns nothing ;-) [20:07] make [20:08] seb128: if you'd prefer, I can reject the totem one as not meeting the SRU criteria because it doesn't fix a "high-impact bug"; I was being nice by leaving it in the queue for future consideration [20:08] seb128: Well, it's not like it can't be accepted immediately post-.1 anyway. [20:09] infinity, well I just find it sad that a one line fix for an obvious usability uploaded a week before the given freeze date doesn't make it [20:09] I guess it's my fault for trusting the date we were given [20:10] seb128: I'm staying out of point release madness mostly intentionally, the above was mostly just an attempt to calm the tone of the channel. ;) [20:10] that failed :-p [20:10] Evidently. [20:11] seb128: if you think it's a high priority bug, mark it as such and stand by the claim. But you won't succeed in talking me into treating it as a high priority if you don't consider it so yourself [20:11] slangasek, define high priority, I think the cost-benefit ratio is High [20:11] or rather the opposite, the benefit-cost ratio is High [20:11] it's a one liner making a real usability impact [20:12] seb128: the SRU guidelines require both a high benefit-cost ratio, and also a high absolute benefit [20:12] this is sensible, because the SRU process itself has an opportunity cost [20:12] slangasek, being able to find the Ubuntu DVD player for users, is that an High bug? [20:12] seb128: you tell me ;) [20:13] I've no datas to backup my claim [20:13] but I believe that typing "DVD" in the dash and having no result is a real usability issue [20:13] we have so many bugs so I'm not sure I would rank up at the top of the list though [20:13] but I consider it worth fixing [20:13] deciding on bug settings is hard ;-) [20:14] if marking the bug 'high' in LP feels wrong to you, then accepting it as an SRU feels wrong to me [20:14] if you think calling it a 'high' bug is reasonable, I have no problem processing it instantly [20:14] it's a matter of perspective [20:15] (the rhythmbox one, though, was not trivial and I wasn't comfortable trying to get that in before .1) [20:15] I guess the design guys would put it at least High [20:15] as an engineer I tend to put non segfault or data lost bugs a bit lower [20:15] slangasek: If that little stack of SRUs isn't going in for some time, could you please remove transmageddon from proposed? [20:16] slangasek, ok, well, pondering the cost-benefit I put it high [20:16] slangasek, it's somewhat back to importance,priority meaning in bugs trackers and launchpad not having that [20:17] slangasek, it's not always easy to conciliate different factors in one setting ;-) [20:17] [20:17] Laney, slangasek: the mp3 is a bit more embarassing but I agree it's late [20:17] Laney: transmageddon seemed to be correct per se and I accepted the first iteration; is the second one somehow dependent on the rhythmbox changes? [20:17] it basically means anyone converting a CD to mp3 will get crappy music [20:17] It was sadly not correct [20:18] Laney: but it doesn't need to block on rhythmbox? In that case I expect it will be processed [20:18] it blocks on gst0.10-python which is on media so I expect will wait until after the point release [20:18] unless RB gets pushed in, which will necessarily flush it out [20:19] ah, ok [20:19] Laney: so you want the existing one removed from -proposed, and the next one stays in the queue? [20:19] please [20:20] Laney: done [20:20] thanks [20:23] infinity: seems like there are at least 3 builds fighting for kapok on nusakan, so I guess I'll have test results somewhere in the next 3 hours ;) [20:26] infinity: do you know what's happening with the X packages in quantal-proposed? [20:28] slangasek: Staging an xorg ABI transition, still not done. [20:28] what's not yet done? [20:28] last upload was 5 days ago [20:28] slangasek: They missed some drivers in their first pass, I already chastised them for it this morning. [20:28] other than the ones they said they would drop? [20:28] slangasek: They're also waiting on a new nvidia binary blob that's in the works, I believe. [20:29] hmm [20:29] slangasek: Yeah, they missed a few that they're not dropping. [20:29] ok [20:29] (Like the ARM-specific ones, one in multiverse... Maybe others) [20:29] * slangasek reads his scrollback [20:29] ok cool [20:29] Scrollback would be in #-devel [20:29] yep, just read it :) [20:31] tumbleweed: Who do I whine to about the fact that reverse-depends(1) doesn't take virtual packages into account? [20:32] * infinity had to fall back on checkrdepends to look for xorg-abi-whatever rdeps. [20:40] hmmmm unity's v-done and in the queue for 14 days [20:40] are people afraid to pull the trigger on that SRU? ;) [20:46] slangasek: No, I would have released it yesterday, but I was, y'know, not at work. [20:47] slangasek: I poked at it on the weekend, and it looked good to go, I believe, just didn't want to do a weekend release. [20:48] wow, it's been a while I haven't installed 10.04, the desktop and installer really changed quite a bit since then ;) [20:48] stgraber: Hey, ubuntu/precise is finally building on kapok. :P [20:49] yay! [20:51] stgraber: as the 12.10 are stable, what chances do you think 12.10 server will get broken? I'm just about to install a VM and am willing to use it. [20:53] phillw: 12.10 is still Alpha so no promises things won't break [20:54] jbicha: which is the classic "chicken & egg". I believe that they are stable enough to be used, how else can we confirm that they are? [20:56] sure, how critical is it that your server stays up? how difficult would it be for you to fix things if they go wrong? [20:56] phillw: By all means, use and test away. My number one rule for testing pre-release is "never on hardware I don't have physical access to". So, a VM certainly qualifies as "access" to the "hardware". [20:57] if the answer to both is "not very" then please go ahead and test :) [20:57] it is going to be running a test installation of a mail server. [20:58] I have always wanted to install http://flurdy.com/docs/postfix/ onto a system, i now have a reason to do so. [21:26] + install -m 644 debian/dnsmasq.conffiles debian/daemon/DEBIAN/conffiles [21:26] speeewwww [21:26] "copy-package -s precise -p kubuntu-ppa --ppa-name=staging -b --to-suite=precise --to-ppa=kubuntu-ppa --to-ppa-name=ppa kdeplasma-addons" seems a bit unwieldy. Would it be reasonable to assume from/to suite and from/to PPA owner are the same unless specified? That'd tighten that up to "copy-package -s precise -p kubuntu-ppa --ppa-name=staging -b --to-ppa-name=ppa kdeplasma-addons", which seems almost reasonably compact. [21:27] If that seems OK, I'll make the change, but I thought it merited discussion. [21:27] I think that would be sensible. I've hit the same annoyance with the "partner" options [21:28] ScottK: I think assuming they're the same unless one of either to/from is specified makes sense. [21:29] infinity: "one of", not "both of"? [21:29] because that's the current problem; you have to specify both to+from when you want them to be the same but not equal to the default [21:29] It does slightly change the semantics since now that would copy to quantal. [21:30] for partner it's worse, it defaults to the main archive and you get an error about cross-partner copies being disallowed :-P [21:30] slangasek: Oh, right. [21:30] But the change seems more sensible to me. [21:30] I sort of assumed it worked the way I'm proposing and ended up having to delete about 50 packages out of quantal for the target PPA. [21:34] cyphermox, stgraber: confusion on the dnsmasq SRU. The dbus.conf I see here says only users root and dnsmasq are allowed to own the name; the NM instance runs as user nobody; how does the dbus policy actually do what it does? [21:35] cyphermox, stgraber: also, doesn't the NM dnsmasq instance owning the dbus name imply the possibility that an instance of the service started from the dnsmasq (not dnsmasq-base) package will regress because the name is taken? [21:35] or vice-versa, actually [21:44] slangasek: I'll let cyphermox answer the dbus policy question. I'm running the test packages here and it's definitely working (running as nobody) [21:45] slangasek: for the potential conflict, yeah, that's unfortunately an issue as we can't get multiple servers to listen at the same address. I believe cyphermox is discussing with upstream to make that configurable so NM's dnsmasq can have a different dbus path or something along those lines. [21:46] slangasek: the default setup as shipped by dnsmasq doesn't have dbus turned on and that package isn't shipped by default on any flavour, so yeah, there's a potential for breakage there but it should be extremely limited [21:47] not to mention that this scenario was completely broken at 12.04's release as it's only been a few weeks since we started introducing dnsmasq hooks in all packages using it to prevent conflicts with the one shiped in the dnsmasq package [21:47] stgraber: kapok upgraded with your live-build fix, if you want to test-spin again. [21:47] infinity: thanks. started [21:48] stgraber: If it verifies for us, I think I'll just push it through, so the other buildds auto-upgrade, since that's functionally no different than manually upgrading them all anyway. :P [21:49] sounds good to me, the sooner we have non-oversized images, the better [21:50] stgraber: ok; I'm not thrilled about introducing this prospective regression in SRU. What are the odds we could get support for different dbus path as part of this SRU round? [21:50] I'd rather see us defer this until we can get it exactly right, than accept it with a known regression and then have to go back and redo it, now with conffile upgrade handling [21:51] slangasek: cyphermox should be able to answer that, though my guess is that it's unlikely to happen for 12.04.1 as it sounded like it'd need quite a bit of work on dnsmasq upstream's side [21:53] stgraber, cyphermox: oh, incidentally, now that I've looked at which NM bug this is for... I think I feel rather strongly that this is a wrong fix... the real bug, AFAICS, is that NM thinks *at all* that it needs to get involved each time there's an ipv6 route advertisement [21:53] I must admit not being thrilled by the fix for 12.04.1, I'd have much preferred fixing the real issue (NM badly interpreting some netlink events and respawning DNS when there's no config change) but was assured by cyphermox that fixing these would lead to backporting a huge chunk of NetworkManager that wouldn't be suitable for SRU [21:53] hmm [21:53] glad we agree ;) [21:54] so basically we'd fix the dnsmasq flapping problem [21:54] but would still leave users with unnecessarily full kernel routing tables [21:54] correct and that's all we'd be fixing [21:54] we'd still be getting extra routes in the routing table as that's considered "harmless" (I still don't like it...) [21:56] fortunately not a whole lot of people are being hit by that bug, but for these who are (like anyone on a network I manage), it's causing dozen of DNS failures a day as firefox seems to be surpringly good at poking dnsmasq exactly during the time it's being restarted by NM [21:57] heh [21:59] not to mention my average syslog is at 8k lines per day ;) [21:59] (a bit over 500 dnsmasq respawns) [22:01] -rw-rw-r-- 1 cdimage cdimage 738504704 2012-08-07 20:58 20120807.3/precise-desktop-amd64.iso [22:01] -rw-rw-r-- 1 cdimage cdimage 736407552 2012-08-07 22:00 20120807.4/precise-desktop-amd64.iso [22:01] stgraber: ^-- That what you were hoping for? [22:01] my local one is 735830016 but yeah, close enough [22:03] Might want to spin an i386 for paranoia's sake, since we haven't had one in a while. [22:04] And amd64+mac looks like it should be identical in size, once respun. [22:04]