[00:12] slangasek: Quickie review and accept of my 6-character grub-installer change? [00:13] fyi: today's unity regression: bug 862743 [00:13] Launchpad bug 862743 in unity (Ubuntu) "Desktop drawn with offset (affects: 22) (dups: 6) (heat: 144)" [Undecided,Confirmed] https://launchpad.net/bugs/862743 [00:14] mdeslaur: by 'today' do you actually mean 'today'? I don't see a new unity today [00:14] infinity: looking [00:14] mdeslaur: That's not using positive language. Unity doesn't regress, it just improves in reverse. [00:14] slangasek: unity (4.20.0-0ubuntu1), 5 hrs ago [00:14] hmm [00:15] lol [00:15] infinity: sorry...unity's present incremental improvement [00:15] infinity: you're saying that unity is wizard, but the wizard is Merlin? [00:15] but look at all those bugs fixed today in Compiz/Unity! [00:15] infinity: points off for misspelled changelog [00:15] jbicha: there you go, 20 fixed, and only 1 introduced, we're still ahead! [00:16] slangasek: Wait, really? Am I that tired? [00:16] slangasek: Reject, I'll fix. :P [00:16] SUPRIOUS! [00:16] Wow. [00:18] slangasek: Reuploaded. :P [00:18] :) [00:20] infinity: accepted [00:21] infinity: does this explain the ubiquity FTBFS? I wasn't clear on how ubiquity FTBFS on 2 of 4 archs [00:23] oh right, because grub-installer is only used on two of those archs [00:23] hmm [00:29] slangasek: can't reproduce the plymouth issue, sorry [00:29] mdeslaur: lucky you, given that my followup was going to be to ask you to run plymouthd under valgrind :) [00:30] slangasek: heh, sounds like fun :P [00:43] slangasek: Yeah, once ubiquity is refreshed with the new grub-installer, it will build happily. [00:43] (which is my next move, once it publishes) [00:50] Oh, that mksh upload reminds me... [00:51] slangasek: I needed to review a dietlibc sync request today. You cool with that going in if it looks alright to me? [00:51] (And then we can reject mksh) [00:52] infinity: yes, no objections for dietlibc [00:57] slangasek: Alright, I'll sync it after I resurrect a machine and do some local testing. [00:57] * infinity rejects mksh for now. [01:45] slangasek: Well, nevermind the dietlibc bump. GCC ICEs while building it. [01:46] slangasek: \o/ [01:53] infinity: re: "Ugh. This habit of doing major version bumps on Canonical-originating packages ..." see my response to Allison's call for UDS inputs on that very topic. Since you'll (I imagine) be there, you can push it forward. [01:56] sladen: FYI, UVFe is a term it's been a few years since we used. [01:57] infinity: Also, thanks re Dapper server. That was the first one I ran. [02:14] slangasek: ubiquity inc. [02:34] ScottK: Can I get a review/accepct of ubiquity? I'd like to build some images some day. ;) [02:34] Depends on how complicate it is. [02:34] Not very. [02:35] You can skip everything under d-i, since it's just source package copies. [02:35] The ubiquity changes are pretty small. [03:02] Done. [03:02] Sorry, had $WORK to finish first. [03:03] Or not. (Error ID: OOPS-2099BB11) [03:03] https://lp-oops.canonical.com/oops.py/?oopsid=2099BB11 [03:03] Fourth try's the charm. It's in. [03:04] Danke. [03:05] That oops has a pleasantly repetitive serial. [03:39] It does. [03:39] I hadn't noticed, I guess that makes you more autistic than me. [03:40] ;-0 [03:41] I didn't realise it was a competition. [03:47] Laney: Did you intend your changing the status of Bug 854264 to be an FFe approval? It's nice to put a word or two in there so others know why you changed the status. [03:47] 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,Fix released] https://launchpad.net/bugs/854264 [04:12] I suppose we'll need another armel abi bump in d-i for http://people.canonical.com/~ubuntu-archive/nbs.html? [04:12] * pitti looks at fixing med-imaging-dev [04:23] at this point I'm inclined to just remove eclipse binaries on armel and powerpc [04:23] (FTBFS there) [04:43] Sounds reasonable. [04:44] +queue has teh debian-med diff now [04:44] I'm not sure why blends-dev shuffled the recommends: line on rebuild [04:44] but I think it just removed packages which got removed [04:44] Looking before I go crash. [04:45] at least it did that for the other blends packages I touched recently [04:45] It's late. I've very tired. I'm willing to believe you. [04:46] (I don't think anyone in Ubuntu uses the blends packages anyway ....) [04:46] Good night. [04:46] sleep well! [04:46] Thanks. 4:59 until I have to be up again. [05:04] pitti: d-i needs a rebuild anyway. But yeah, need to bump omap4 kernels. [05:06] pitti: Probably safe to do the d-i bump later in your day, if you want. I was just waiting on the archive to settle. [05:06] infinity: yes, not particularly urgent; I just looked at NBS to see what remains [05:06] infinity: FYI, bug 862743 is a real sucker [05:06] Launchpad bug 862743 in unity (Ubuntu Oneiric) (and 2 other projects) "Desktop drawn with offset (affects: 51) (dups: 15) (heat: 314)" [Critical,Fix committed] https://launchpad.net/bugs/862743 [05:07] building a test package now, will upload in a bit [05:08] Yeah, Unity's special. [05:33] infinity: dpm was asking for getting the libgrip HTML documentation installed; I fixed the source to install it into libgrip-dev, does that sound acceptable to upload at this point? [05:33] infinity: (for http://developer.ubuntu.com) [05:33] I'm not really familiar with how developer.ubuntu.com fits into the grand scheme of things... [05:34] But what's wrong with -doc packages? :P [05:34] infinity: nothing in particular, but (1) binNEW, and (2) small package [05:34] there's loads of packages which just install their docs into -dev to avoid excessive split-o-mania [05:35] Yeah. Fails if you later want to multiarch, though, doesn't it? [05:35] But fair enough. Docs ahoy. [05:35] infinity: oh, how so? [05:35] it's static file [05:35] s [05:36] No per-arch generation at all? [05:36] Might be alright, then. [05:36] Still a bit icky. ;) [05:36] But whatever. [05:36] infinity: nope, docs are generated by make dist [05:36] that's the common case these days with gtk-doc [05:37] (same for glib, gtk, and all the other libs) [05:37] much faster, and there's no real reason to regenerate docs each time [05:37] mind all those wasted entropy! [05:37] Yeah, I remember this from doing telepathy release engineering. [05:37] s/those/this/ (was going to write "electrons") [05:37] Was a constant source of annoyance, actually. :P [05:38] unity and libgrip uploaded; whee! [05:38] a non-broken desktop, and already TWO WEEKS before release! [05:39] It'll break still. [05:39] See the sponsorship request in -devel. ;) [05:39] yes, we are good at that [05:42] infinity: sponsoring libcanberra, too, that looks good [05:46] pitti: Need some reviews? [05:47] infinity: if you are in the mood, that'd be nice [05:48] I'm just fixing my local mirrors, happy to review when the diffs rolls in. [05:48] s/rolls/roll/ [05:48] infinity: argh, forgot bug ref in libgrip; want me to reupload? [05:49] Well, you just rejected it, so sure. :P [05:49] er, what? [05:49] Unless that was someone ninja accepting? [05:49] Man, I wish this thing had an audit trail. [05:49] I accepted David's libcanberra [05:49] Oh. [05:49] Grip, canberra. [05:49] THEY BOTH START WITH LIB. [05:49] yeah, hard to distinguish [05:50] I stop reading after the first 3 characters. [05:50] * pitti uploads libcranberry [05:50] As for the bug ref, I don't care if you close it manually. [05:51] ack, will do that then [05:52] Argh. The unity people really need to stop using this silly tool. :( [05:52] "Hey look, we moved all our packaging from one debian-foo.patch blob to another, happy diffing." [05:52] eww, yes; the actual diff is just a two-liner [05:52] infinity: http://bazaar.launchpad.net/~unity-team/unity/trunk/revision/1677 [05:53] (slightly easier to read) [05:53] Yeah, I've learned to read these messes. [05:53] And thanks to their magic packaging crazy, I prefer to review the actual source package instead of a branch. [05:53] Cause I don't trust it. [05:53] 3.0 (quilt) just doesn't play well with bzr maintained pacakges [05:54] for mine I just keep 1.0, it's so much better for upstream/packaging in bzr [05:54] * pitti asks didrocks to do that [05:55] 3.0 (quilt) works fine, you just have to actually keep patches in bzr. [05:55] yes, that's just silly if you already have everythign in proper revision control [05:55] I did quilty packages in maemo git all the time. [05:55] *shrug( [05:55] what you want to do is "bzr merge ", not stuff everything into patches again [05:55] pitti: well, I haven't done the transition to source 3 on purpose, seb128 did when I wasn't there despite my warning… I'll revert for P [05:55] In a Debian system, the source package is ALWAYS authoritative, nothing is ever in proper revision control. :P [05:56] And people who think it is keep dropping changes. [05:56] right, the two concepts are fundamentally incompatible [05:56] pitti: maybe not dropping for an SRU, or is it ok? [05:56] but with source 1.0, you get a big diff.gz, but at least it's policy compliant (apt-get source gets you what is built), and doesn't break bzr [05:57] didrocks: oh, for P is fine [05:57] ok [05:57] pitti: I actually used to like that I could keep cherrypicks in debian/patches and not have random changes in my source, but to each their own. [05:57] pitti: Made it more obvious (to me) when an upstream cherrypicked change got merged in. [05:57] infinity: not exactly the same when upstream is in bzr and you can bzr merge [05:58] pitti: Cause it's basically silent if you've picked INTO your tree and then merge. [05:58] infinity: right; but then "bzr merge" just DTRT without you having to mess with debian/patches and the like [05:58] pitti: Whereas you get a nice "hey, the patch doesn't apply anymore" when it's external, and you remember to, like, document it. [05:58] infinity: we never do that for patches that are not upstream [05:58] infinity: for those, it's debian/patches [05:59] didrocks: I did this for a long time with upstream in git and maemo building directly from git. [05:59] But, like I said, others preferred your method. [05:59] Both work. [05:59] I'm not picky. [05:59] Though maemo also had clever ways to nominate tags as upstream versions, etc, so you could re-roll a pristine orig from git at any time. [06:00] And yet, if we get there soon with all the UDD/bzr stuff, I really hope I can still just blat a normal source package at an ftp server too. [06:00] I'll be miffed if I can't. [06:03] are you not just referring to pristine-tar, which UDD uses? [06:03] slangasek: Dunno. Am I? [06:03] couldn't say for sure; pristine-tar is joeyhware, dunno if maemo would've been using that [06:03] slangasek: Well, I can't be referring to whatever UDD uses precisely, because we still have to have an original orig. [06:04] you have to have an orig.tar.gz when you upload to the archive [06:04] but you can synthesize it from the UDD branch at any time [06:04] slangasek: The maemo trick was that on a new upstream version, you say "this tag is the orig", this tag is the -1, and it would construct and upload for you. [06:04] slangasek: (After that, of course, it hung on to the one it created and worked as a normal Debian archive would) [06:05] The downside is that maemo's orig's never match the sums of upstream drops. [06:05] Which annoys me. [06:05] oh [06:05] then yeah, not pristine-tar, because *that* is what pristine-tar gives you [06:06] It took me a long time to really get into a new workflow where "tagging is uploading" too. [06:59] didrocks: Having converted eucalyptus from bzr merging to quilt, i can say i did not enjoy it. [06:59] It's near imposible to reconcile once changes have been tweaked, bzr blame is of little help. [07:00] Let alone measure the delta. [07:00] Daviey: well, we cherry-pick a lot from the unity trunk, not sure how often you need this [07:01] Hmm, although, that was slightly different - because the distro version was a fork, with out own orig tarball (not my choice.) [07:01] Daviey: Ew. [07:01] infinity: yah [07:02] I'm told bzr looms is the 'right' fix for this issue. [07:02] yeah, I need to give bzr looms a try at some point :) [07:03] I'd just like bzr to suck in quilt patches, and generate them again at export/build-deb. [07:03] and i want a pony. [07:03] Then you want the precursor to the precursor to UDD, back when Keybuk was working on it and it never actually became anything. [07:04] Every patch was a branch, and it de/re-constructed on the fly. [07:04] And there's no real reason a simple wrapper still couldn't do that, it would be much easier now that we have a standard (3.0 quilt) for this. [07:05] http://wiki.bazaar.canonical.com/Documentation/LoomAsSmarterQuilt [07:28] ScottK: no, I mashed it to Triaged and then back to New [07:28] didn't it take? [07:29] yes, it did [07:29] I was trying to undo the auto-confirmation... [07:33] Oh, FFS. unity is skewed now, no ARM images for me. :/ [07:34] * pitti feeds the armel buildd hamsters [07:34] I wonder if powerpc ever catches up [07:35] now that the "needs build" queue is down to 4, we got a LibO update coming :) [07:35] but we better get that in today, so that it can build over the weekend [07:52] infinity: ^ armel FTBFS fix, if you are so inclined [08:00] tjaalton: I don't see the forward_pass change in your diff [08:02] Laney: oops, good catch [08:02] pitti: A reverse debian diff? Well done. [08:02] infinity: screw UDD and its pre-applied patches [08:03] hmpf [08:03] a million ways to get it wrong, one undiscoverable one to get it right :( [08:03] s/and.*// [08:03] pitti: I always, always debdiff my uploads against a pristine apt-get source of the current archive version. Pretty much because I don't trust anything. Or myself. :P [08:04] * ogra_ wonders why we have no code that recognizes zram swap and makes sure we don't offer hibernate on that [08:04] * Laney trojans debdiff [08:04] Laney: new one attached [08:04] ty [08:05] damn [08:05] the reason why it wasn't there was that I changed the priority [08:05] so I need to revert that too :) [08:07] so it's either keep the current pam-auth-update priority and add forward_pass, or change the priority (which then matches upstream suggestion of always having it below pam_unix) [08:07] * infinity blinks. [08:07] Package: libreoffice-gcj [08:07] -Architecture: alpha amd64 armel armhf hppa i386 ia64 mips mipsel s390 s390x sparc kfreebsd-amd64 kfreebsd-i386 [08:07] +Architecture: hppa kfreebsd-amd64 kfreebsd-i386 [08:07] Section: java [08:08] Ahh, the changelog is enlightening. :P [08:08] that seems like an interesting upload for after Final Freeze [08:08] tjaalton: I'm minded to approve the current diff [08:09] Laney: if I change the priority backt to what it was? [08:09] -t [08:10] so, add forward_pass, keep priority, and re-think about it for P [08:10] right [08:10] cool [08:10] get it picked back up in Debian for P :-) [08:11] of course, I'll merge the packaging [08:11] as soon as I'm accepted to collab-maint :) [08:11] looks like it's being maintained by nmu anyway these days [08:11] yeah [08:12] alright, approving [08:12] thanks! [08:13] there we go [08:15] Laney: subscribed ;) [08:15] pitti: libreoffice seems reasonable to me, BTW. [08:16] pitti: If you weren't also reviewing it already. :P [08:16] pitti: (Then again, you probably know it better, so carry on) [08:17] infinity: can do [08:17] I already checked the debdiff when sponsoring [08:17] accepted === NCommander is now known as Guest93709 [08:46] the world is one again [08:46] yeah [08:47] please accept sssd (ffe granted) [09:22] Laney: done [09:28] please accept ghdl [09:32] ScottK: pitti: so, agateau has a new patch for Qt, hopefully this time really fixing bug #805303 [09:32] Launchpad bug 805303 in xorg-server (Ubuntu Oneiric) (and 7 other projects) "Gtk-CRITICAL **: IA__gtk_widget_style_get: assertion `GTK_IS_WIDGET (widget)' failed with the default qt4 gui (affects: 148) (dups: 46) (heat: 670)" [Critical,Invalid] https://launchpad.net/bugs/805303 [09:35] pitti: Can you give alsa-lib some love? Fixes sound on Pandaboards. [09:36] Can i ask for a server re-twirl please? [09:36] * cjwatson -> out for a while, need to take daughter to speech therapy [09:37] infinity: ... harder? (there was alreayd a fix yesterday) -- sure, looking [09:37] pitti: basically, there is 2 choices: either agateau patch Qt, either readd a removed symbol in gtk [09:38] pitti: Yeah, I know. I fail at replicating my test system in my uploads, apparently. [09:39] pitti: Danke. [09:40] didrocks: for the scrollbar "huge widget" bug? [09:40] pitti: yeah, that one [09:41] didrocks: I'm afraid I don't know which is better [09:41] agateau: any preference? why did you remove the first symbol draft? [09:41] agateau: because you prefered set(enabled/disabled) ? [09:42] didrocks: yes, it felt more in line with gtk api [09:42] didrocks: updating the Qt patch is more elegant, updating the GTK patch is probably less build resource intensive [09:43] Don't care about build resources, but correct and sane would be nice. [09:43] pitti: agreed then, Qt upload? ^ [09:43] sorry for armel builders, once again… [09:43] We'll live. :P [09:44] didrocks: Qt it is [09:45] really, powerpc is a lot more worries right now [09:45] we've got loads of armel builders, but the two powerpc ones haven't caught up for a week or more [09:45] pitti: oh? with universe stuff? previous Qt is already built on it [09:45] didrocks: yes, with anything [09:45] (not the case for armel) [09:46] universe keeps being pushed after main ones, of course [09:46] yeah [09:46] ok, bzr bd -S, and dput in 20 minutes then [09:46] PPC keeps getting slammed by kernel PPAs. :/ [09:46] But it's never more than a few hours behind, so it's not the end of the world. [10:03] Did someone trigger the server rebuild? [10:23] need to get offline for an hour or so, I'll be back on the train [10:30] Accepted qt4 based on what pitti said earlier. [10:30] Sooner started is sooner finished. [10:33] OK. I would have if LP hadn't timed out. [10:33] Now it's done. [11:13] back === ara is now known as Guest50889 [12:34] The akonadi upload is a bugfix update from upstream. Akonadi/kdepim is shaping up to be a complete disaster this cycle, so I want every fix in I can get. I'd appreciate it if someone would review (we're waiting on Qt anyway). [12:37] didrocks; we have a big problem with the dash search filters. A range of problems that were supposed to be resolved by yesterday's release have not been fixed, and basically the 'filter results' section is a bit mangled. ;-( I have raised a number of new bugs, the bugs in question are: #863252 #863246 and #863240 [12:38] didrocks; I think we need to get these fixed for a day 0 SRU? [12:38] bug #863252, bug #863246 and bug #863240 [12:38] Launchpad bug 863252 in unity (and 1 other project) "Dash - in the search filters, the "All" button should always be in the selected state when no other option in that filter category is selected (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/863252 [12:38] Launchpad bug 863246 in unity (and 1 other project) "Dash - the options in the "filter results" section are the wrong size, aligned incorrectly, and the button outline width is incorrect (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/863246 [12:38] Launchpad bug 863240 in unity (and 1 other project) "Dash - the "Filter results" text is the wrong size, wrong font weight, and aligned incorrectly in both the vertical and horizontal axis (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/863240 [12:38] It would be nice if people didn't develop right up until final freeze. [12:38] JohnLea: I think those bugs will need an image about before/after (from the description, there are quite a lot of changes) [12:39] JohnLea: anyway, I guess it's the release team/SRU team which can discuss if those bugs can qualifies or not [12:42] didrocks; I've attached the images to the bugs, I have to go into a meeting now, speak soon [12:43] didrocks; (also updated bug description) [12:43] JohnLea: sure, thanks [12:53] So... Feature Freeze was a month and a half ago, and UI Freeze was a month ago. I'm having a hard time finding sympathy for new bugs introduced by new features that turn out to have broken your UI that was still being worked on. [12:54] (Not trying to sound harsh here, but this can't and won't work this way for the LTS cycle) [12:54] JohnLea / didrocks: ---^ [12:54] infinity: thanks for the webkit upload [12:55] dobey: Thanks for the fix. :) [13:18] infinity: If you want release team support for reverting stuff, I'm with you. [13:23] ScottK: it hasn't been pushed, it's just design still wanting some UI adjustement. I told JohnLea it was out of question before finale and to discuss himself with you for a SRU [13:23] I'm just passing the message around to ensure I don't find any agressive merge in trunk that I have to revert for next upload [13:24] I'm not on the SRU team, so it's not my call, but I don't think "Oh, we'd like to tweak the U/I" fits the SRU criteria. [13:24] ScottK: agreed as well, even if I'm not in that team [13:25] Actually none of those bugs are even listed as affecting Ubuntu right now, so not yet our concern. [13:25] I prefer to warn dx/design before the changes are done, hence I asked him to raise the discussion here [13:25] Good. [13:25] Although considering how well they generally manage to understand the concept of feature freeze, I'm not sure how much it will help. [13:26] ScottK: I guess and hope those kind of discussion can help them to raise the awareness… [13:27] this package fix an overwrite issue btw ^ (missing epoch) [13:31] I'll look at. [13:31] infinity: Would you please press the "I believe" button on my akonadi upload? [13:38] Someone beat me to it. [13:39] didrocks: It's in. [13:39] infinity: Thanks. [13:39] ScottK: thanks [13:39] (wasn't me) [13:39] * infinity raises hand. [13:39] thanks to whoever acked it :-) [13:39] It was a 2-second review. :P [13:39] ;) [13:39] indeed [13:39] One line changelog, 2-character fix. We need more of those. [13:39] infinity: I was thinking, it'd be nice if we had an audit trail on who accepted stuff. [13:39] Isn't that a nice idea. [13:40] infinity: even better would be one line change log, two character fix, 12 hour build .... [13:40] ScottK: I've been up all night, we've had this conversation before, and you're just being ironic, right? [13:40] infinity: Yes. Highly. [13:40] Sorry. [13:40] Check. [13:42] has someone filed a bug for that? [13:43] No idea. [13:43] I'd guess there's been one since around the same time /+queue was first made public. [13:43] But I have no idea. [13:44] Someone else can review nautilus. On the one hand, the changelog screams "we want this upload", on the other hand, I'm too tired to do it proper justice. That's a fair few fixes to pore over. [13:44] * infinity goes to try to nap. [13:49] probably covered by bug #42831 [13:49] Launchpad bug 42831 in launchpad "Mail notifications for administrative actions (dups: 1) (heat: 2)" [High,Triaged] https://launchpad.net/bugs/42831 [13:51] Keep in mind in LP terms "High" means "We think we'll get to it someday". [13:51] well, I did note the bug number [13:52] I'm sure there are people who can cause priorities to be reassessed if they are so inclined [13:53] Laney: Not really. [13:53] Laney: Not without really irritating escalation processes and the like. [13:55] I can believe there is bureaucracy there [13:58] So. I'm looking at this Ubuntu font package. [13:58] Which leads me to http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=603157#20 [13:58] Debian bug 603157 in wnpp "ITP: ttf-ubuntu-font-family -- Ubuntu Font Family, sans-serif typeface hinted for clarity" [Wishlist,Open] [14:01] So is it a bug that you can't actually modify the source without non-free tools and it's in Main or does Ubuntu allow that? [14:01] indeed, I understand that's the file format of a proprietary application called FontLab [14:02] if http://www.ubuntu.com/project/about-ubuntu/licensing is policy, then I don't see any such requirement [14:03] Right, so it can be "Free" even if you need non-free tools to excercise it. [14:04] then again, I don't see such a statement on the face of the DFSG either [14:08] True. I could find it in DFSG #3 if I stare at it a bit though. [14:08] I think Policy 2.2.1 is typically invoked [14:09] 2.2.1 doesn't specify editing though. [14:09] plus a bit of FTP master case law [14:09] see Joerg's statement further down in that thread [14:09] Right. [14:10] That was mostly about the license though. [14:10] it has a bit about modification [14:12] anyway, being signed up to the DFSG, I do agree with that interpretation [14:17] Looking at the package, it doesn't appear to use the shipped source to build the ttfs, so I think you're right. [15:22] Anyone from the release team arround? I get a lot of pressure from Ghostscript upstream (See http://ghostscript.com/irclogs/, search backwards for tkamppeter, starting at the point of now) about not using libcms1 as it is discontinued upstream and full of bugs. Instead I should use their heavily patched version, which fixes many segfaults (not only Apple-generated figures) but also color incorrectness. [15:34] Could the release manager of p-series be set so I can target bugs to it? [15:36] bdmurray: done [15:36] cjwatson: thanks [15:39] Did anyone see my request for a server re-twirl? [15:40] Daviey: apparently not. Running now [15:41] cjwatson: Thanks! [15:41] Anyone has anything to say on my Ghostscript issue? Or better SRU? [15:46] tkamppeter: Probably better in "P" to get it fixed properly. [15:49] ScottK, so I will start a test program when P opens and if an O use complains he gets a personal fix from me (through a PPA). OK? [15:50] For oneiric, I think if there are specific issues, fixable with a specific patch they should go through SRU. [15:50] Daviey: you've closed bug #529714 without addressing the reason I reopened it... [15:50] Launchpad bug 529714 in samba (Ubuntu Oneiric) (and 9 other projects) "rhythmbox crashed with SIGSEGV in _nss_wins_gethostbyname_r() (affects: 104) (dups: 37) (heat: 670)" [Critical,Fix released] https://launchpad.net/bugs/529714 [15:50] It's too late to update the library for oneiric. [15:50] ScottK, simply let us not advertize color management for printing, it is still in grow-in-and-stabilize phase. [15:51] ScottK, or can I post the move from the broken stock LCMS1 to the fixed Ghositscript-upstream-LCMS1 as an SRU? [15:53] ScottK, the library (lcms package) will not get updated on such a fix, GS will use a statically linked version supplied by Ghostscript upstream and tested by their commercial customers. [15:54] ScottK, this version is color-adjusted and anti-crash-proved on thousandfs of test files. [15:55] slangasek: Ah, apologies - did not. [15:57] tkamppeter: There are 44 reverse build-depends for liblcms1-dev. Fixing it for ghostscript isn't enough. [15:58] ScottK, I will not touch the lcms1 package nor lcms1-dev. I will only switch the ghostscript package from using the lcms package to bringing its own internal lcms1 code which will get built into Ghostscript and only used by Ghostscript itself. [15:59] ScottK, so no other package can get broken by that. [15:59] If that one is better, why not use that for everything? [15:59] slangasek: zul is *on* *the* *case*. [16:01] ScottK, getting it into GS now is a simple flick of a ./configure script. Ghostscript works with it as it got already tested by the commercial customers of Artifex. Putting the changes into the general, shared library can easily break the interface to the other apps which use lcms1. [16:01] Code copies suck. [16:01] Someone should do something about this. [16:02] ScottK, this copy is short-termed as GS upstream already works on the LCMS2 switchover and then they will be able to upstreamize their patches to upstream LCMS. [16:04] argh, disconnect; replying, sorry if you got this twie [16:04] infinity, ScottK, cjwatson: whoever reviews the lightdm upload: it's a fairly large patch, please feel free to ask me about details; the AA profile is copied from gdm-guest-session (where it has worked for several cycles), except the update for /run [16:04] sorry for landing this late, I just took over the bug assignment today, it slightly fell off the radar so far [16:04] I tested it fairly thoroughly, though [16:04] infinity: FYI, I pinged Sweetshark for the LibO failed to upload (missing pre-depends for xz compression); let's hope he's still online to get a fix today for building over weekend, I'll try calling him, too [16:04] That's pretty unlikely to be me reviewing it. [16:05] So don't anyone else wait hoping I will. [16:05] I hope infinity can get to it [16:06] now that lightdm allows running a guest session without a prior "real" user login, allowing the guest session to read all home dirs is pretty bad [16:06]