[00:00] And livecd-rootfs should be self-explanatory, since you reviewed the previous revision. [00:00] yep [00:00] all accepted [00:00] Danke. [00:01] Now, if I get my slideshow fix into ubiquity, I think I'm done touching ARM installers for the cycle. [00:01] I think. [00:05] * infinity starts going through the queue backlog. [00:13] infinity: can you reject atomix? I just noticed it doesn't have a build-dep on dh-autoreconf [00:14] stgraber: Gone. [00:14] infinity: I'd appreciate it if you'd look at kdeutils. It's a two line patch ... [00:14] ScottK: Getting there... [00:14] Thanks. [00:15] If it helps any, we'll be able to taunt Riddell since he's upstream for the application it fixes. [00:15] * infinity cheers for xubuntu-default-settings getting a greeter theme in just under the wire. [00:15] infinity: thanks, just uploaded a new one with the missing build-dep [00:15] I suppose if the greeter itself had not been in flux for the last 3 months, that might have been easier. :P [00:16] ScottK: Taunting Riddell is never a bad thing. [00:18] ScottK: Sorry, no kdeutils for you. Queue page times out, and I'm too lazy to log in to cocoplum. :P [00:18] * infinity logs in.. [00:39] slangasek: Oh heh, I just re-read the f-k changelog and now understand your questions. You should have rejected it based on my changelog being misleading/wrong. :P [00:39] slangasek: Oh well. The code's right, the changelog was autopilot. [07:11] slangasek: my thoughts on 759545 amount to OMG LEAVE ALONE, unless somebody tells me I have to do something about it ... [07:11] (playing with ever more config file handling is not my idea of fun) [07:11] ok :) [07:12] if you had some idea of what was going wrong, I might take a crack at it [07:12] it's doing ucf and also substituting in values from debconf [07:12] and almost certainly getting the ordering wrong one way or the other [07:13] it's awful [07:13] (and predates me, mostly) [07:21] 759545> I'd be happy to take a stab at that post-release, but that sort of thing is best not touched right before a freeze. [07:21] (I do enjoy those sorts of maintainer script / config file / crazy shit problems though) [07:24] cjwatson: I/We really, really hate grub for that. [07:25] And also the one where all cloud images provide that warning on every kernel SRU. [07:26] We release noted that bug for Natty, and i think it's ok to do the same for Oneiric.. But could we look to address it early in P? [07:26] Daviey: Like i said, I'd be happy to wrangle it post-release. [07:26] Daviey: And once I've hunted it down, even backport fixes. Though I'm more concerned about the LTS. [07:27] infinity: is it worth it post-release? [07:27] Daviey: It's worth it for P. [07:27] oh yes. [07:27] Daviey: I mean "in 2.5 weeks". [07:27] Daviey: Not in 6 months. :P [07:27] ahh, i see. [07:27] I wouldn't even mind if someone assigned it to me, so you could remember to pester me (hint, hint) [07:28] I suck at bug mail, so IRC annoyance will go a long way. :P [07:28] bug 814038 , i nacked - whilst i'd *really* like that in Oneiric.. and it seems to do the job, I'm not comfortable touching grub configs this late in the cycle. If anyone wants to overal me, i'd be most pleased. [07:28] Launchpad bug 814038 in ipxe (Debian) (and 1 other project) "Please offer a grub-ipxe.deb package (affects: 1) (heat: 6)" [Unknown,New] https://launchpad.net/bugs/814038 [07:30] Daviey: if infinity wants to take care of it, my objections are fewer than if I have to :) [07:30] lol [07:30] Daviey: but to be fair, an approach whereby cloud wasn't mangling grub's configuration files would be pretty nice too [07:31] cjwatson: I agree mangling is probbaly the cause for this :) [07:31] jhunt: ! [08:37] * ogra_ hugs cjwatson (re: rmadison) :) === ara is now known as Guest72740 [12:57] Please don't accept qt4-x11 yet. [12:58] pitti: FYI, I've moved cron.NBS to lp:ubuntu-archive-tools and made it run on lillypilly, including a bit of rearrangement of ubuntu-archive's crontab there (so cron.NBS now calls nbs-report itself) [12:59] ah, that makes it easier, thanks [12:59] ScottK: ack [12:59] pitti: I'm going to be gradually moving reports off cocoplum now that we should have the necessary facilities to run them elsewhere [13:00] since the LP/IS consensus is that ultimately we shouldn't need shell access to cocoplum [13:00] (obviously there are a lot of things to do before that's possible) [13:00] right; I'm trying myself to use +queue, sru-release, etc. as much as possible, but I still find LP timing out ridiculously often [13:01] yeah, I know it's not ideal, we need to get those fixed before we can move off [13:01] we need an API for +queue [13:01] that seems to be the worst problem for that [13:01] (I filed a bug for that, I think) [13:02] stuff like sync blacklist is already being handled, and it shouldn't be hard to rewrite lp-remove-package.py in lplib [13:02] I filed a bug for that too; the API is not quite right at the moment [13:03] or possibly I'm thinking of https://bugs.launchpad.net/launchpad/+bug/853831 [13:03] Launchpad bug 853831 in launchpad "Export SPPH.changeOverride and BPPH.changeOverride (affects: 1) (heat: 6)" [High,Triaged] [13:03] Is anyone a ruby fan on the release team? [13:03] slangasek: when you get the chance, I would appreciate your input in bug #779382 - I have a working port that should work pretty well, but its still rather late in the cycle and derivates are affected too [13:03] Launchpad bug 779382 in update-notifier (Ubuntu Oneiric) (and 9 other projects) "update-notifier not visible under unity (affects: 14) (dups: 2) (heat: 72)" [Medium,Confirmed] https://launchpad.net/bugs/779382 [13:05] I'd like to determine if someone is better placed on solving a ruby/rails issue.. or at least someone that is happy to help sort out the direction. Currently it's a mess. [13:05] aka HELP [13:05] (!) [13:11] doko: That seems to be part of the fix.. I'd like to have rejected the sync when i realised it was worse than it was. Not having that foo, and nobody listening to my cries yesterday, someone accepted it. [13:12] But.. it was broken before that. [13:13] bug 861524 [13:13] Launchpad bug 861524 in rails (Ubuntu Oneiric) (and 1 other project) "[oneiric] rails is not installable (affects: 4) (heat: 22)" [Critical,Confirmed] https://launchpad.net/bugs/861524 [13:14] There was a partial transition done in September, it seems to me that we either need to finish it, try and cherry pick enough to get it working, or versionmanagle to bring it all back to the base version. [13:14] All options are bad. [13:16] looks like syncs 2.3.14 were done? [13:16] imagine grammatical English there. [13:18] Laney: the deps [13:19] rails (2.3.14.1) was sync'd in September [13:19] it has hardcoded < deps. [13:21] m_3 has taken a stab with the depends, https://code.launchpad.net/~mark-mims - but I'm not comfortable with the impact here. [13:21] actionmailer still needs doing, but once activerecord builds (in progress now), actionpack will build and then ruby-rails-1.3 will [13:21] looks like doko just did some syncs [13:21] anyone noticed the big pile of input method related sync requests in the sponsor queue? I know nothing about that stuff... [13:25] Laney: okay, so between you and doko - you have it in hand? [13:25] I just eyed it up, haven't done anything about it [13:25] looks so. [13:25] but it looks like syncing the stack would fix things, and that doko is doing that [13:26] Laney, will your darcs upload in unstable help armel? [13:26] no [13:26] doko: So you are finishing the transition to *.14? [13:26] it didn't even fix the ftbfs in sid [13:27] Laney, https://buildd.debian.org/status/package.php?p=darcs ? [13:27] Daviey, yes [13:27] right [13:28] I don't think I changed anything that would fix arm [13:28] that said, a fix wouldn't be harmful (but would need binNEWing as I added library packages) [13:28] fix/sync [13:28] Laney: Yeah, I was thinking that finishing syncing would be A fix - but i wasn't comfortable with understanding the impact, as the stack isn't just limited to rails - is it? [13:29] doko: ruby-activerecord-2.3 (2.3.14-1) is only used with rails? [13:29] at least with ruby-rails-2.13 [14:04] didrocks, ScottK: will you ping when/if we should review qt4-x11? [14:05] pitti: hum? should be fine in the unapproved queue, isn't it? [14:06] 14:57:20 ScottK | Please don't accept qt4-x11 yet. [14:06] pitti: the patch cames from a nokia developer, adapted to 4.7.4 [14:06] ScottK: ? [14:06] and it's fix released upstream [14:06] as the upstream bug, in the DEP-3 format in the patch tells [14:47] skaet, just curious, is there a reason that 'ReleaseCandidate' is not in the right column at https://wiki.ubuntu.com/OneiricReleaseSchedule [14:47] i was confused, and basically thinking there was no RC [14:48] (i'm easily confused, though) [14:50] smoser, ReleaseCandidate is going to happen like it did in Natty, not as a formal deliverable which is what the last column is used for. We'll have a formal release candidate for the LTS :) [14:51] ok. [14:51] thanks, skaet [14:54] np [14:55] didrocks: Thanks. [14:55] I was gone longer than i expected. [14:56] didrocks: Accepted. [14:56] ScottK: thanks! [14:56] I also wanted to make sure the last upload got published on i386 first too. [14:59] pitti: re trying to use +queue and timeouts: Welcome to my world. [14:59] :-) [15:43] can someone kick partman-uboot in the queue? [15:50] NCommander, its been reviewed? [15:51] skaet: a little testing, but not a lot. I thought we weren't in final freeze yet [15:53] NCommander, fixes are getting reviewed as they go in right now. [15:53] skaet: k, let me get it re-reviewed. The scope of the fix is small (affects error messages during partitioning on netboot omap3/4) [15:53] NCommander, thanks! [15:54] skaet: will ping once its done (probably not until after final freeze, as we're in final crunch time now :-/) [15:55] NCommander, ack. [16:29] + db_set partman-uboot/boot_not_on_mmc [16:29] NCommander: what's the point of that line? partman-uboot/boot_not_on_mmc is a boolean, so that line sets it to an out-of-spec value [16:30] (i.e. the empty string - the only in-spec values for booleans are "true" and "false") [16:31] also I'd recommend that boolean templates have a Default field in the templates file of either true or false [16:32] + [$id/formatted -nt $id/filesystem ]); then [16:32] bad syntax, missing space after [ [16:33] I would prefer commit.d/format_dove_uboot and commit.d/format_omap_uboot to be merged into one script [16:34] in fact merged *back* into one script from the looks of things. it was better that way, less duplicated code [16:34] debian/files shouldn't be in the source package [16:34] nor should all the */DEBIAN/* cruft [16:35] I'm marginally confused by why this is in both active_partition and choose_method but that'd probably be clear if I looked at it [16:37] confusing indentation in init.d/uboot_omap [16:40] NCommander: ok, that's my initial review; sorry, but I'm going to have to reject this at least for the unclean source package, the syntax error, and the out-of-spec db_set; can you please fix those up? [16:41] please could somebody review icedtea-web (two upstream patches, fixed permissions), openjdk-6 (pulseaudio, permissions), and the just uploaded openjdk-7? [16:43] Just pushed edubuntu-live, ltsp and arkose to update translations and do some last minute bugfix for Edubuntu. Would appreciate it if these could make it to our next daily (if they get acked within the next 4 hours we should be good). thanks! [16:48] doko: yep, currently reviewing [16:50] NCommander: do you mind reviewing u-boot-linaro? it's two metric tons of changes which I can't judge [16:50] Laney: hey, I*ve posted the diff to sssd's debian/ dir to the bug [16:51] keeping openjdk-7, no debdiff yet; and jockey, as I uploaded that [16:51] and with that, good night! [16:55] wow, that was fast! thanks! [16:57] $ sync-source.py -b doko ruby-actionpack-2.3 [16:57] 2011-09-29 16:56:58 INFO Creating lockfile: /var/lock/launchpad-sync-source.lock [16:57] Getting binaries for oneiric... [16:57] 2011-09-29 16:57:15 ERROR Unhandled exception [16:57] -> http://launchpadlibrarian.net/81447917/bTJiQXFcef5DKR8XewCVYAGXfTW.txt (Values instance has no attribute 'moreverbose') [16:58] cjwatson, pitti: have to run ... could you have a look at these? needed for ruby-rails [16:58] Daviey, ^^^ [16:59] ahh wait, already synced :-/ [17:08] doko: Is the rails mess resolved? [17:08] Daviey: Not until it's rewritten from scratch? [17:12] ScottL, https://bugs.launchpad.net/ubuntu/+source/ubuntustudio-meta/+bug/806672, looks like its resolved now based on the comments, can you confirm? [17:12] Launchpad bug 806672 in ubuntustudio-meta (Ubuntu Oneiric) (and 1 other project) "UbuntuStudio Oneiric Alpha2 fails to install - unmet dependencies (affects: 2) (heat: 13)" [Critical,Triaged] [17:15] Daviey, please give back ruby-rails-2.3 in about 90min [17:15] tjaalton: ta, will look hopefully tonight but if not then tommorrow (or someone else can) [17:18] Laney: ok. does it need some special treatment once the final freeze is on? [17:19] it's universe unseeded (isn't it?), so not just yet [17:20] Laney: yes, indeed [17:21] Laney: fwiw, stephen gallagher is upstream [17:21] unless it wasn't obvious already :) [17:21] yeah, got that [17:26] doko: k === seb128_ is now known as seb128 [17:59] skaet: ScottK: would be nice to have latest unity release in tomorrow's image if you have time [17:59] Daviey: as well ^ [18:00] * didrocks crosses finger it's the finale release :) [18:15] didrocks: That's.... A lot of bugs fixed. [18:15] infinity: yeah, as always! :-) [18:15] didrocks: I'm sorry, it's the first time i've looked at unity code - and it's far too large for me to feel comfortable ack'ing it. [18:15] Daviey: I'm looking at it. [18:15] no worry Daviey ;) [18:15] infinity: rocking [18:15] thanks infinity [18:17] didrocks: Have you considered actual patches instead of this massive debian-changes blob? [18:17] Err, and someone just accepted it for you while I was reviewing it. :P [18:17] (who was that?) [18:17] infinity: it's how merge-upstream works :) [18:18] For some value of "works"... [18:18] infinity: still not perfect for this workflow I know [18:18] infinity: basically, the packaging branch is derived from trunk [18:18] infinity: then, you bzr merge-upstream ../tarball ../trunk --version [18:18] infinity: it takes what's in trunk, add all delta (if any) from the tarball [18:19] infinity: then, you can easily cherry-pick with bzr merge ../trunk -r rev [18:19] really handy, as you know that next release will overwrite the change [18:19] the issue is that it doesn't play well with source 3 :/ [18:19] reviewing the branch itself is way easier [18:20] * infinity really wants an audit trail on the queue... [18:20] infinity: Fancy reviewing a ~ubuntu-cdimage merge proposal? :) [18:20] Daviey: The boot menu thing? [18:20] infinity: yeah [18:20] Daviey: I've been intentionally leaving that to Colin. [18:21] gah.. I was aswell, but i imagined he was AWOL right now. [18:21] Is there a reason that needs to be in cdimage instead of wherever that sort of thing normally lives? [18:22] infinity: It replaces the code that used to be "Install UEC". [18:22] As in, there used to be something there [18:49] infinity: this is why I really want bzr merges to /be/ the queue... :) [18:49] slangasek: Or, I dunno. Auditing on who presses buttons? [18:49] slangasek: That's not rocket surgery. [18:49] infinity: oh, that part [18:49] yeah [18:50] sorry, I thought you meant "this diff is augh and not auditable" [18:50] Oh, his diff is icky, but I've seen icky VCS merges too, whatever. [18:50] No, I was complaining that I've seen a ton of (potentially controversial) accepts over the last couple of hours, and no one's actually been talking about them. :P [18:50] Well, maybe not a ton. But a few. [18:51] hey lovely release team [18:51] dobey: Whatever it is, we don't want any. [18:51] haha [18:51] how much trouble will it be to get a fix for a nasty webkit crasher into oneiric today? :) [18:52] dobey: No trouble at all, if it's an isolated and sane fix. [18:52] it is [18:52] No trouble at all as long as there's no auditing of who pushed the accept button .... [18:52] i am preparing a branch with the cherrypicked patch, right now [18:52] Or what Scott said. [18:52] Grr. [18:53] mvo: commented on bug #779382 [18:53] Launchpad bug 779382 in update-notifier (Ubuntu Oneiric) (and 9 other projects) "update-notifier not visible under unity (affects: 14) (dups: 2) (heat: 72)" [Medium,Confirmed] https://launchpad.net/bugs/779382 [18:54] mvo: really, it depends on the desktop team here; I'll do what I can to help land it cleanly if they say it has to go in before release, but seb128 seems to agree with you [18:54] thanks slangasek [19:00] mvo: Not sure where you were looking, but lubuntu and xubuntu both ship libindicator in -desktop. [19:01] Oh, libappindicator... [19:01] Wait, no, same argument. :P [19:02] mvo: libappindicator and libindicator are both there for [x|l]buntu-desktop. [19:02] Now, whether I had an indicator panel on a default Xubuntu install, or if I added it myself later, I don't recall... [19:02] But the packages were there. :P [19:03] I show indicator plugin in the panel by default in Xubuntu [19:04] charlie-tca: Thanks, I can never remember what was default and not, after how much I've hacked and slashed at my panels. [19:04] infinity, charlie-tcao: oh, cool! [19:04] that makes it all a lot easier actually [19:04] Yeah, only way I know is it is a fresh install I did to test today [19:04] Hahaha. [19:05] infinity: https://code.launchpad.net/~dobey/ubuntu/oneiric/webkit/scroll-crasher-fix/+merge/77587 <- nice small patch :) [19:05] would you mind to put that info into the bug? [19:06] mvo: Done. [19:06] slangasek: If the whitelist is in place, why bother with an SRU. There's no longer an SRU qualifying issue. [19:08] dobey: Very tiny. Locally-tested to DTRT, I assume? [19:08] dobey: (And upload away, if the answer is "yes") [19:09] infinity: yes, it fixes the crash; and i don't have upload perms for webkit [19:10] dobey: Oh. I'll sponsor it in a bit, then. :) [19:11] infinity: ok, thanks [19:11] skaet: It'd be nice if you could fill in the comment field about what's changed on your manifest edits it's be nice. The diffs for that page are incredibly hard to read. [19:12] ScottK: I'm sure I failed to comment my edits too. Apologies. [19:12] slangasek too I think, there have been a pile of them. [19:12] And they make my eyes hurt. [19:13] Stop subscribing to it; problem solved? :) [19:15] ScottK, switched two lines and cleaned up the seed references (ditto was referring to line above, and it wasn't accurate where it was.) [19:15] oops [19:15] Yep. I got that, it just took some study. [19:16] ScottK: hmm, probably true [19:18] hey, I've uploaded a new xserver-xorg-input-synaptics, which fixes a merge regression where the quirks were not getting installed. tested by cnd that it works [19:43] infinity: are you on ia32-libs? [19:44] In a call, but it's on my plate, unless you're bored. :P [19:49] I have enough excitement in my life without ia32-libs [19:49] thanks though :) [19:51] heh === robbiew is now known as robbiew-afk [21:50] I have reviewed orchestra and dovecot-metadata-plugin (as best as possible), can they be accepted pleased [21:52] slangasek: ia32-libs seems good to me, except for a bug that will make it break on ia64, which we don't build anymore. Worth pushing it back to fix and arch we don't use? :P [21:52] openjdk7 - diff from 7~b147-2.0~pre5-1 to 7~b147-2.0~pre6-1ubuntu1 (86.4 MiB) ... :/ [21:56] * infinity closes his eyes and accepts ia32-libs. [21:57] Daviey: openjdk7 is unseeded and unsupported, just grit your teeth, see if debian/changelog looks sane, and let 'er rip? [22:00] Ugh. This habit of doing major version bumps on Canonical-originating packages within hours/days of freeze needs to be rethought. [22:01] It can't be that hard to cut "5.0" at feature freeze, and then maybe ship with 5.0.7 (yay bugfixes) by release. :P [22:02] infinity: What packages are you referencing directly? [22:03] *indicator*, software-center... Possibly others. But those are the ones I've noticed this week. [22:04] Not that 2.95->3.0 (for instance) was actually a large diff. That's not my complaint. But in some projects, even just bumping a major revision number can accidentally cause a problem. I see the argument for shipping a shiny 3.0.0, but.. Who cares? [22:05] And if the versions mean anything (*cough* stability), 3.0.0 should be landing at feature freeze anyway, cause everything after that is microrelease bugfixes, right? :) [22:07] infinity: Major version numbers could just be turning the volume up to 11. [22:07] I'm sure if you ask nicely, they'll bump a minor version instead next time :) [22:07] Maybe. [22:07] But it kind of looks like this is a team policy thing. :P [22:08] Although, it does feel that crack is landing significantly later than in the last 2 cycles. [22:08] Yeah. Well. I'm back now. And I plan to be draconian about freezes and the queue for the LTS. [22:08] If I can get the other RMs to back me, we're set. ;) [22:08] (I'm sure vorlon and cjwatson will be on board with that plan) [22:09] infinity: Server has committed to not taking on anything ambitious next cycle. LTS probably being more importiant to them, than Desktop. [22:09] Which should make it easier to have crack land early. [22:10] So certianly my suport there :) [22:10] It's pretty important to desktop too. Support cycle is still twice as long. [22:10] And while we may not be the corporate desktop of choice, there ARE some large installations out there. [22:11] And you can bet they don't run the latest crack every 6 months. :) [22:11] infinity: pah, 3 years vs 5 years :) [22:11] I know. :) [22:12] And 5 still isn't long enough. [22:12] But it's much better than 18 months, so I won't complain. [22:12] infinity: don't tell anyone, but i still have some dapper servers. [22:12] sladen: Re: ubuntu-mono upload: Eww. [22:13] Daviey: I worked hard on that release, I don't mind. [22:13] Daviey: In dapper, the "server team" was, more or less, me. [22:13] Daviey: So.. You're welcome. :) [22:13] heh [22:14] sladen: wow, have you tried building in a launchpad chroot? [22:14] I'm sure shipping binaries due to a buildd issue shoudl decrement your karma [22:15] sladen: If you can build locally but not on a buildd, it's got to be a missing build-dep, or a whacky local config or something. [22:15] sladen: Surely, there's a better way. :P [22:15] Daviey: I want karma every time I press the accept button. And twice as much for reject. [22:17] Now, who did I promise I'd sponsor an upload for? [22:17] * infinity alt-tabs through the mess on his desktop. [22:18] Right. dobey, webkit. [22:31] skaet: fyi, bug 851986 needs to be SRU [22:31] Launchpad bug 851986 in firefox (Ubuntu Oneiric) (and 7 other projects) "use of Ux in ubuntu-* abstractions and profiles is too lenient and should be improved (affects: 1) (heat: 8)" [Medium,Triaged] https://launchpad.net/bugs/851986 [22:32] skaet: I updated the milestone accordingly [22:33] jdstrand, thanks. === skaet changed the topic of #ubuntu-release to: Final Freeze in effect. | http://pad.ubuntu.com/ubuntu-release | Oneiric Ocelot Release Coordination. Please don't upload things during freezes where you shouldn't, or be prepared to apologise to the release team with beer | we accept payment in cash, check or ocelot food | melior malum quod cognoscis [22:45] skaet: I'm squeezing in one more upload that I reviewed for dobey several hours ago and am merging now. :P [22:45] (if bzr will ever finish branching...) [22:45] infinity, ack. [22:47] could someone with op perms in ubuntu-devel, change the topic to reflect the fact its now past 2100 UTC, so we're final freeze now? [22:48] skaet: I already did. [22:48] infinity, Thanks! [22:48] * sladen looks around at the ceiling [22:48] are you sending out an announcement? [22:48] hi, just curious if anyone was doing anything with bug 821876 or if that will wait for P? [22:48] Launchpad bug 821876 in ubuntu-font-family-sources (Ubuntu) "FFe: New upstream version Ubuntu Font Family 0.72 (Ubuntu Mono hinted and Ubuntu Condensed hinted) (affects: 1) (heat: 8)" [Undecided,New] https://launchpad.net/bugs/821876 [22:49] seems late. [22:51] yeah, it's not my bug, but I figure the Release Team will need to do a Yes/No for it...now that OMG Ubuntu announced that it's been released [22:51] * sladen marks it as a dup of bug #854264 [22:51] Launchpad bug 854264 in ubuntu-font-family-sources (Ubuntu) "UVFe & FFe: New upstream version of Ubuntu Font Family 0.80 (affects: 2) (dups: 1) (heat: 22)" [Wishlist,Confirmed] https://launchpad.net/bugs/854264 [22:51] sladen: hi, thanks [22:52] jbicha: upstream have released 0.80. Whether it makes it into the distro (it's been uploaded) depends on the Ubuntu Release team. I suggested writing persuasive messages to the release team on the bug report [22:53] :P [22:53] sladen: No comments on the ubuntu-mono hacks? [22:53] sladen: /lastlog sladen :) [22:55] infinity: oh, this is just a mere upload of some data files. No chance that if it gets accepted there's be a theme update to switch over to using them. no, no, ho ho [22:56] sladen: Hrm? No, I assumed that. But thanks for the sanity check. [22:56] sladen: I mean comments on why you need to include pngs in your source. :P [22:56] infinity: oh, the ubuntu-mono (images, not font, sorry, name overloading) [22:57] infinity: it was a bit crunch point timewise. I hope to delete the PNG dump-over line when I figure out the exact issue [22:58] infinity: it's reproducable in a pbuilder-buildd environment, ... yes, it is likely some undeclared imagemagick randomness [22:59] sladen: Mmkay. I'll let it slide, but if you find the issue, I wouldn't actually mind it being fixed properly in the next day or two. [22:59] (hint, hint) [23:00] * sladen nods [23:08] * infinity goes crosseyed reviewing checkbox. [23:13] infinity: I think they went for a record d/changelog size. [23:15] Daviey: The changelog was alright, it was some of the code that made me quiver with fear. You know, stuff just completely inverting logic to make me have to find context, that sort of thing. [23:18] Well, Final Freeze has come and gone, and our installer still doesn't build. [23:18] I call this a success. [23:19] I wonder if Colin's adding me to ~ubuntu-installer was a subtle "go fix ubiquity" hint. [23:22] * skaet looks at the list of ubiquity bugs, and figures its was a hint. [23:22] Laney, note sent. [23:36] why does this plymouth bug report ONLY affect people who are not me? [23:39] slangasek: Which one? [23:39] infinity: the many-tentacled memory corruption one [23:39] Daviey: launchpad chroot. tell me more [23:39] which I have never seen in person [23:39] slangasek: As in video corruption? [23:39] Daviey: what magic do I need to pass to pbuilder/etc to make that work? And how does it help? [23:39] slangasek: If so, my laptop very recently developed that bug. [23:40] sladen: https://api.launchpad.net/devel/ubuntu/oneiric/amd64 [23:40] infinity: no, memory corruption; plymouth's list code is going off the deep end [23:40] sladen: (For instance) [23:40] Daviey: re: server. I'm gonna replace yo console fonts with early crack [23:40] sladen: That tarball is the exact chroot used on the buildds. [23:40] slangasek: you clearly don't own enough hardware :) [23:40] infinity: resulting in segfaults and apport bugs and augh [23:41] mdeslaur: can *you* reproduce it? [23:41] I already have a box here with an nvidia chip, just to try to catch it [23:41] slangasek: Oh. Not sure I know that one. But I kinda ignore plymouth anyway, assume my machine's just going to do ugly things on boot/shutdown, and fail to care. :/ [23:43] slangasek: remind me the bug #? I'll check [23:43] infinity: so, we are actually committed to making plymouth not-ugly, and you might stand a halfway decent chance of filing an actional bug report... if you're seeing ugliness, please report it :) [23:43] mdeslaur: bug #849414, or bug #553745, or bug #745744, or bug #542191, or any of the other places plymouth is segfaulting against its will [23:43] Launchpad bug 849414 in plymouth (Ubuntu Oneiric) (and 1 other project) "plymouthd crashed with SIGSEGV in ply_event_loop_process_pending_events() (affects: 118) (dups: 36) (heat: 666)" [High,Incomplete] https://launchpad.net/bugs/849414 [23:43] Launchpad bug 553745 in plymouth (Ubuntu Oneiric) (and 5 other projects) "plymouthd crashed with SIGSEGV in ply_event_loop_process_pending_events() (affects: 708) (dups: 77) (heat: 3100)" [High,Incomplete] https://launchpad.net/bugs/553745 [23:43] Launchpad bug 745744 in plymouth (Ubuntu) "plymouthd crashed with SIGSEGV in ply_list_remove_node() (affects: 82) (dups: 10) (heat: 393)" [High,Confirmed] https://launchpad.net/bugs/745744 [23:43] Launchpad bug 542191 in plymouth (Ubuntu) "plymouthd crashed with SIGSEGV in ply_list_remove_all_nodes() (affects: 10) (heat: 40)" [Medium,Confirmed] https://launchpad.net/bugs/542191 [23:43] slangasek: plymouth's been differently broken for me on different hardware for every release since we switched. I guess I gave up somewhere. [23:43] ubot4: whoa boy [23:43] Factoid 'whoa boy' not found [23:43] slangasek: I'll start caring again. [23:44] slangasek: (Speaking of ugly, do we have any intention of making the shutdown transition smooth? It hasn't been ever since the switch from *dm calling splash_down to the udev rule that does it "when the dms exit") [23:45] infinity: er, I fixed that last weekend? [23:45] I think that's around when I gave up. :P [23:45] slangasek: My laptop disagrees. How is it fixed? [23:45] oh sorry, by "smooth" do you mean "no modeswitch"? [23:45] And by udev, I mean upstart. My brain's not all here. ubiquity has my Us confused. [23:46] sladen: You'll have to update the sources.list and hack /CurrentlyBuilding [23:46] I don't think we ever had a flicker-free transition from gdm to splash on shutdown [23:46] h] [23:46] infinity: Unless you have finished your wrapper for CurrentlyBuilding + sbuild? [23:46] slangasek: I mean "no jarring me to a text console which may or may not have text, depending on other packages installed, before starting plymouth a second or five later". [23:46] Daviey: Nein. [23:46] now, this cycle we had a major smoothness regression on shutdown, and that one got fixed [23:47] slangasek: We never avoided a mode switch, but I know we avoided seeing a console, I wrote the code that did it. ;) [23:47] sladen: Wait, are you suggesting your team actually cares enough about server to bother replacing stuff? [23:47] infinity: yeah, we still drop to text on shutdown; there really shouldn't be any text on vt7 though unless something else is running amok [23:47] slangasek: But that all got torn out in favor of upstart triggers. [23:47] oh? I don't think that code was in effect at the time we switched to plymouth [23:47] so I think it bitrotted before that [23:47] slangasek: In a default install, vt7 won't have text, on a messier one, there can be all sorts of stuff there (always is on mine). [23:47] Daviey: oh yes. We don't you a juju logo right now(tm) [23:48] Daviey: oh yes. We're doing you a juju logo right now(tm) [23:48] infinity: there shouldn't *ever* be text on vt7 (unless maybe you boot without 'quiet'), and if you're getting some, let's fix whatever's doing it :) [23:48] slangasek: I've had output from any number of init scripts there (and sometimes errors/warnings from same). [23:49] cjwatson: will fix, but I perfer keeping the commit scripts between dove and omap separate [23:49] slangasek: And while I think it's a noble goal to fix every daemon in main/universe to shut up, it's easier (surely) to not show the vt. :P [23:49] infinity: no, the intent is to fix it so the init scripts don't have vt7 as their stdout at all [23:50] but yeah, I can't speak to the current status of this [23:50] slangasek: As in, make upstart shove it somewhere else? [23:50] yep [23:50] slangasek: I can live with that. [23:50] and, y'know, log it [23:50]