[00:01] Searching. (It takes a little while since it has to download all the build logs.) [00:02] Bet it's faster than you clicking through all of them, though. :-) [00:02] yes, thanks [00:02] Were you build-testing them as well, or just throwing them back against the wall? [00:03] so what do people think of a sudo upload for bug #982684 and bug #979319? [00:03] Launchpad bug 982684 in sudo "sudo doesn't apply global environment settings from /etc/environment" [Medium,Triaged] https://launchpad.net/bugs/982684 [00:03] Launchpad bug 979319 in sudo "[FFe] sudo do not remember password when std(in|out|err) are not connected to a terminal" [Low,Triaged] https://launchpad.net/bugs/979319 [00:03] cjwatson: test building one arch first [00:04] OK, I'll not bother :) [00:04] If they fail, at least the new reason will be visible to all [00:04] buildds are empty enough [00:41] micahg: done gconjugue gshutdown gtkmm-utils gxine lasso luakit medit monkey-bubble mrtrix mrwtoppm netams ofono olpc-kbdshim opensync pan pinot psimedia ruby-gnome2 sagasu scenic sigx strongswan tomoe so far [00:42] script still seems to be running so I guess there might be some more [00:45] but I'm off back to bed now, so if you have more, ask somebody else :) [00:45] cjwatson: ok, thanks for your help [00:45] oh, I think that's it, it had started on superseded ones (it's not very smart) [01:03] cjwatson: Yeah, I noticed it had been committed after I asked. [02:02] oh bah, sudo doesn't call pam_getenvlist(); I guess I can't fix that one so easily [02:31] By the way, no one copy eglibc to the release pocket until gcc-4.6 is also ready to go. [03:21] infinity: how's eglibc itself coming on armhf? [03:21] documented on the pad [03:37] ^ that fix took me a while to figure out [03:38] cjwatson: when you get up, can you do a a search in the rebuild for 'libgtk2.0-dev : Depends: libgtk2.0-0 (= 2.24.10-0ubuntu6) but it is not going to be installed' and retry? [03:44] * micahg regrets not killing sqlite2 for precise [04:24] Good morning [04:25] infinity: the apport workaround fully fixes the problem for apport [04:25] infinity: the GTK+ patch was reviewed upstream, I'll commit it upstream and merge it into today's GTK .1 upload [04:25] infinity: as we have similarly large dupe lists in software-center and other places; I'll reassign those bugs and dupe them [04:25] infinity: mvo's patch seems fine [04:26] infinity: sru-release -r does the -proposed -> release copying, it's in lp:ubuntu-archive-tools [04:26] stgraber: yes, our CDs have plenty of space now that linux-firmware went on a 5 MB diet :) [04:31] * pitti starts with the GNOME 3.4.1 packaging, see last Friday's release meeting [05:31] ^ FTR, I used --no-lp for the sync, as I uploaded to Debian and Ubuntu at the same time [06:02] anyone who could review my GNOME 3.4.1 -proposed uploads? === doko_ is now known as doko [06:05] pitti: I don't feel like I'm in the loop on this - you say these uploads were approved at the release meeting? [06:06] well, not in the sense of pre-reviewing the chhanges [06:06] only that we'll land the gnome 3.4.1 bits today [06:06] as it's being released today, and tarballs come in [06:07] the .1 tarballs are traditionally on a tight schedule [06:07] yeah [06:08] glib/gtk have bigger changes, as expected; the others should be mostly harmless [06:08] e. g. gdk-pixbuf is rather simple (and has a nice security fix, too) [06:25] self-rejecting glib2.0, need to check something [07:18] pitti: unity ready ^ [07:52] pitti: and the compiz-plugins-extra rebuilds for c-p-m ABI break ^ [07:52] didrocks: cheers [07:52] pitti: thanks :-) [07:52] ok, now that the morning ping is ended, let's finish the week-end email backlog :) [08:35] ok with this fix: https://bugs.launchpad.net/compiz-compizconfig-gconf/+bug/979770 ? quite safe, tested by seb128 and I [08:35] Launchpad bug 979770 in compizconfig-backend-gconf "[regression] Precise: GNOME Classic starts without any compiz plugins loaded for Guest and new users" [High,In progress] [08:35] didrocks, I continued running that over the w.e, I confirm it works ;-) [08:35] great! ;) [08:37] seb128: if only we had a glib which would provide g_free(), g_strdup0(), and all that stuff.. [08:37] err, didrocks ^ [08:37] didrocks: LGTM [08:38] pitti: life would have been wonderful right? But such things can't exist! :) [08:41] pitti: uploaded! (more seriously as they wanted to be desktop agnostic, they didn't want to use glib even if it's widespread in kde… but well…) [08:42] didrocks, right, though it's cc-gconf and gconf uses glib :p [08:42] seb128: ironic, isn't it? ;) [08:59] pitti, I think it's time to remove zope2.12 and python2.6, could you do that? bug 979923 [08:59] Launchpad bug 979923 in xpyb "Python 2.6 and several virtual packages are still available in 12.04" [Undecided,Fix released] https://launchpad.net/bugs/979923 [08:59] \o/ [09:01] doko: hm, do we have a newer zope in precise/ [09:01] ? [09:01] -- precise/universe i386 deps on zope2.12: [09:01] zope-maildrophost [09:01] zope-mysqlda [09:01] zope-replacesupport [09:01] I can't find zope2.13 or zope2.14 [09:04] doko: ah, the description says; I guess those three should be removed along then? [09:05] pitti, I don't understand ... [09:05] doko: I mean, above three packages depend on zope2.14 | zope2.13 | zope2.12 | zope2.11 | zope2.10 | zope2.9 | zope2.8 [09:05] doko: but AFAICS we don't have any other zope version packaged, so shoudl I just remove these three rdepends, too? [09:06] well, in fact we don't have the zope2.12 binary either, so they are uninstallable anyway [09:07] doko: both removed, blacklisted, bug updated [09:08] +* Excessive dependencies have been culled from Requires: lines [09:08] + in .pc files. Dependent modules may have to declare dependencies [09:08] + that there were getting 'for free' in the past. [09:08] pitti: ^--- That's a scary change for a .1 ... [09:10] pitti, which rdepends are you talking about? [09:10] ahh, zope-* [09:10] infinity: I think that's catching up with changes that we already have; the actual diff doesn't change the .pc [09:10] yes, I think so [09:10] pitti: Kay, fair enough. [09:10] doko: kidn of a false postiive; as zope2.12 never actually built, these were uninstallable already [09:11] doko: but I guess we can still remove them, but not blacklist? [09:11] pitti: Other bits of the upstream changelog don't instill confidence either (behaviour changes that "may affect applications doing [X]"), but I don't know GTK+ well enough to know if any of it matter to the real world. [09:12] infinity: where do you read this? [09:13] infinity: I don't see it in NEWS? [09:13] pitti: README. [09:13] +* GtkApplication no longer uses the gtk mainloop wrappers, so [09:13] + it is no longer possible to use gtk_main_quit() to stop it. [09:13] +* GTK+ now uses instead of in keyboard accelerators, [09:13] + for improved cross-platform handling. This should not affect [09:13] + applications, unless they parse or create these accelerator [09:13] + manually. [09:13] infinity: ah, same thing -- that's catchign up with changes that were introduced way earlier [09:14] Those two both look like "we don't think people do this anyway, so no big deal" gotchas that might explode other people's code. :P [09:14] all those changes would indeed be qutie scary for a .1 [09:14] pitti: Ahh, alright. Fair enough. [09:14] I'm going to upload 55 kde-l10n packages to import the translations into launchpad, ok to upload to precise? [09:14] they don't have build skew, so no need for -proposed IMHO [09:15] pitti: I hadn't gotten to auditing source yet, I just found the README in the sea of gettext poop. ;) [09:15] infinity: so you started with the hardest package first :) [09:15] infinity: (gdk-pixbuf and screensaver are trivial against that, for consolation) [09:15] ;) [09:16] gtk's probably not that bad, I just need to download the diff and pipe it through filterdiff. [09:17] All the autogenerated crap makes it impossible to manage in a browser. [09:17] infinity: oh, indeed; I usually use "queuediff", and look at it in vim [09:17] much easier to jump around with /^--- [09:18] Yeah, I need a browser extension to allow some simple regexes (actually, just the ^ anchor would be enough) in firefox text searches. [09:18] This seems like it would be trivial to write. For someone who spoke XUL. Which I don't. [09:26] potential spamming in process [09:28] Ugh. [09:28] stgraber: queuebot needs to learn to ignore kde-l10n-* [09:29] infinity: happy for me to accept these? [09:30] Riddell: Already done. [09:30] lovely [09:30] And now we'll get spammed again. :P [09:30] kick the bot for a minute :P [09:34] thanks infinity [09:36] Hrm. Won't this metacity change mean that people who have their terminal application set to something !gnome-terminal will get a different behaviour on C-A-t? [09:36] Or does GNOME no longer let you set a preferred terminal? :P [09:37] infinity: that too [09:37] infinity: I also left a comment in the bug and in the pad that this breaks translations [09:41] pitti: Rejected for now, and noted why in the bug. [09:45] infinity: now ignoring kde-l10n-* [09:45] * infinity hugs queuebot. [09:48] bonjour stgraber [09:54] Dearest soyuz, where did you put my eglibc binaries? [09:54] Finished 7 hours ago (took 5 hours, 12 minutes, 7.4 seconds) (on armhf) [09:54] libc6 | 2.15-0ubuntu7 | precise | amd64, armel, armhf, i386, powerpc [09:54] ^-- No armhf [09:54] libc6 | 2.15-0ubuntu9 | precise-proposed | amd64, armel, i386, powerpc [09:55] WTF? [09:55] hm, nothing in NEW [09:56] * infinity goes to look at publisher logs... [09:56] I bet http://launchpadlibrarian.net/102105469/3Ixhqwb17uQG7eDWJryLXayy4i.txt relates. :/ [09:56] o_O [09:57] And it's killing the publisher. \o/ [10:00] * infinity works on getting that fixed. [10:07] Okay, publisher should be fixed, but at ~60s per kde-l10n queue entry, it'll take a while to run. :P [10:07] Hallo pitti [10:08] * pitti applauds infinifixitall [10:10] pitti: Oh, after this publisher run, there's a preeeeetty fair chance that britney will explode and tell you that armhf is a mess of uninstallable packages (and image builds will have the same issue). [10:10] pitti: It'll all normalize once gcc-4.6/eglibc get copied. [10:10] infinity: oh, more missing armhf binaries? [10:10] I thought they were only missing in -proposed [10:11] pitti: (Unfortunate side effect of having to seed the world with a bootstrap archive, so anything newly-built on armhf depends libc6 (>= 2.15-0ubuntu8), which isn't in the archive yet) [10:11] ah [10:11] I just won't look for the next couple of hours then :) [10:12] 7 or 8 hours, probably, given that gcc-4.6 on armel has a way to go. [10:12] But yeah, it'll sort itself. [10:12] Not an issue for the buildd pipeline, since those packages ARE available there, at least. :P [10:13] Holy crap, Rosetta, why are you such utter fail? [10:13] *sigh* [10:13] Seriously, a minute per kde-l10n-* binary. [10:14] pitti: You still care deeply about all thing translation, right? Maybe you should look at that some day. ;) [10:14] in my CFT [10:14] Ed Zachary. [10:15] On the plus side, maybe gcc-4.6/armel will finish before the publisher does? :P === yofel_ is now known as yofel === greyback is now known as greyback|lunch [11:30] can someone remind me where release note tasks go ? [11:40] is the final release notes page somewhere to edit? === greyback|lunch is now known as greyback [11:50] https://wiki.ubuntu.com/PrecisePangolin/TechnicalOverview [11:50] you can copy https://wiki.ubuntu.com/PrecisePangolin/TechnicalOverview/Beta2 and then edit [11:51] (please don't edit /Beta2) [12:15] infinity: FTR, giving allspice back to amd64 [12:15] pitti: Mmkay. [12:16] pitti: Did ev file an MIR for syslinux-legacy (or are we just assuming that since syslinux is in main, it's okay to promote)? [12:17] I'm not in the MIR team any more, but I'd say it's ok, as it's not really new code [12:18] new gnome 3.4.1 tarballs coming in, fortunately mostly trivial (translation updates only) [12:18] Oh, there's an MIR anyway. [12:18] * infinity reads. [12:20] * infinity promotes. [12:22] ^ one .po file update only [12:24] * pitti eeks at http://people.canonical.com/~ubuntu-archive/component-mismatches.svg [12:24] Daviey: ^ is that under way, or will it be unseeded again? [12:24] pitti: Just don't look at britney output. ;) [12:33] ^ one simple bug fix, translation updates [12:33] pitti: still targeted.. there should be open MIR's. [12:33] *suck* [12:34] pitti: Just one po file, eh? [12:34] pitti: Did you forget the part where the 3 previous releases aren't in the archive? ;) [12:35] infinity: err? [12:35] infinity, did you forget the part where the queue diff stuff is buggy? ;-) [12:35] I diffed locally [12:35] there's autoconf noise, of course [12:35] infinity: are you looking at http://launchpadlibrarian.net/102164255/gnome-desktop3_3.4.0-0ubuntu1_3.4.1-0ubuntu1.diff.gz ? [12:35] it is using the last proposed upload [12:36] Ahh. Special. [12:36] that's a bit buggy,stupid [12:36] it's picking the wrong version as Laney said [12:36] that indeed looks sad [12:36] it did the same on friday with gnome-control-center and some others [12:36] * infinity downloads and diffs manually. [12:37] yay for having good tools [12:37] dget && debdiff for the win ;-) [12:37] * infinity nods. [12:38] still, there's something wrong if it's harder to check a package than to package it in the first place :) === bulldog98_ is now known as bulldog98 [12:39] That flashplugin-nonfree upload is just version/hash bumps to match the partner upload. [12:57] argh, stuff fails on arm* now because gtk+3.0 arm{el,hf} is not published yet; I guess that might take a while if the publisher is broken for longer [12:59] pitti: Should get picked up in the :03 run. [12:59] infinity: ah, did it catch up with the kde-l10n* stuff? [12:59] Yeah. [13:00] cool [13:00] I'll retry stuff after that [13:03] ^ gtksourceview: upstream did a large patch to fix whitespace in the code, which balloons the diff [13:04] Because point releases are always the best time for whitespace cleanups. [13:04] well, better than breaking that silly and incomprehensible garbage _between_ the whitespace :-P [13:05] I never look at that stuff. [13:05] I just check to make sure everything's pretty. [13:05] it's all *.bf anyway, isn't it? [13:05] that would actually be fun: a brainfuck source with comments which translate the logic to C [13:07] You have an odd sense of fun. [13:08] Oh, FFS, argument wrapping too? [13:08] I'm just going to assume those are all the same arguments on new lines, cause I really don't want to compare every one... [13:08] Oh, I guess it wasn't that much. [13:09] * infinity stops whining. [13:10] I do wonder if I'm the only person who finds argument wrapping less readable, though. [13:10] I personally prefer it if a single line spills over my screen line length [13:10] since "nicely wrapped" >> "arbitrarily wrapped" [13:11] Yeah, being dyslexic, you'd think I'd have the same argument. [13:12] Cause for actual reading (like, fiction, websites, whatever), I can't handle long lines. [13:12] For some reason, it irks me to wrap function calls, though. :P [13:12] I might just be insane. [13:14] * infinity waits impatiently on those last two compiler builds so he can upload 10 more. [13:14] oh, I need to squeeze a glib in between that [13:15] What's wrong with the glib that's building right now? :P [13:15] http://git.gnome.org/browse/glib/commit/?id=6560b37450cd19c4a7c7b690e279fe97b7bfdcaa [13:15] we want to revert that [13:15] it's causing unnecessary spewage on package installation [13:15] http://paste.ubuntu.com/932482/ [13:15] sorry, I missed that before [13:15] Ahh. [13:15] it doesn't really break, but looks ugly [13:15] Yeah, noisy upgrades make me a sad panda. [13:16] and we won't fix all pacakges now [13:16] that's something for the start of next cycle [13:16] * infinity nods. [13:16] Are there plans to actually cleanse glib includes in all of universe next cycle, so we can stop re-adding-and-reverting the single-include stuff every 3 months? [13:17] I think we should, yes [13:17] I fix them when I run into them for other reasons, but we should probably just compile a list and go to town. [13:17] The single-include fixy shell script works wonders. [13:17] Debian is fixing those [13:17] we can drop that patch next cycle [13:20] pitti: Well, let's see that new glib, and we'll score it through the roof on PPC and get it in. [13:20] And then I'll eat the buildds with compiler uploads in a couple of hours. ;) [13:21] * ogra_ hands infinity some ketchup [13:21] Om nom nom? [13:21] or do you prefer buildds with mustard ? [13:21] Mayo. [13:24] pitti: gtk+3.0 on ARM should be happy on ftpmaster now, retry away. [13:30] infinity: thanks, all poked [13:32] Oh dear. [13:32] Almost the entire mousetweaks diff is someone using a different version of diffstat. \o/ [13:33] ok, glib being quiet now [13:33] I did a local build/install/test for paranoia's sake [13:33] What's this "testing" you speak of? [13:34] install, reboot, check that boot, lightdm, session works, and that sudo apt-get install --reinstall shotwell is quiet now [13:35] it's just changing glib-compile-schemas, but oh well, with all those new compilers flying around.. :-) [13:35] You didn't want to feel left out? ;) [13:35] what do you think of bug 982719 ? [13:35] Launchpad bug 982719 in mutter "FFe: Add Unity's window keyboard shortcuts to GNOME Shell" [Undecided,New] https://launchpad.net/bugs/982719 [13:37] jbicha: This would affect nothing but gnome-shell? [13:38] at least mutter is not being used in unity, gnome classic, xfce, KDE, etc. [13:38] jbicha: (The followup question would be "why isn't the Ctrl-Alt-t shortcut from the upload I rejected being handled in the same fashion?) [13:38] ? [13:38] Err. Typing hard. [13:39] infinity: right [13:40] the Ctrl+Alt+T shortcut is more challenging since GNOME has dropped the run_command_terminal shortcut [13:41] Oh, it's not configurable anymore? [13:41] Boy, I <3 GNOME. [13:42] they didn't think it was important enough to clutter up the keyboard shortcuts panel [13:42] I mean who uses terminals these days any way? [13:42] ... [13:42] I have, like, 70 of them open. [13:43] didn't we patch metacity to assing ctrl+alt+T by defualt? [13:43] that's still working [13:43] I'd notice very fast if not [13:44] pitti: it works every where except for GNOME Shell, & it'll stop working when we do the gsettings switch next cycle [13:45] jbicha: So, could we make (for this cycle) just GNOME Shell launch gnome-terminal on c-a-t? [13:45] jbicha: And then we can argue later about how to make this globally sane. [13:45] infinity: I'm not sure, I'll have to test that [13:49] Anyhow, I have no issues with #982719. [13:50] But trying to work the terminal shortcut into the same changeset might be nice. [13:50] Two birds, one stone, no breaking other desktops (for now). [13:51] pitti: You lost kov in the last 12 hours? ;) [13:51] (or however long it's been between glib uploads...) [13:52] debclean getting in the way again? it keeps updating Maintainers: [13:52] Yeah, no big deal. [13:52] But I found it funny that he was removed from Uploaders in such a short window. :P [13:55] skaet: pitti: infinity: FYI, bug #981168 on my radar, seems pretty serious (on netbooks only until now, but on 945GMA card which are widespread) [13:55] Launchpad bug 981168 in unity "Regression: Installing apps causes a terrible visual glitch on netbooks-- have to restart X.org." [Critical,Confirmed] https://launchpad.net/bugs/981168 [13:57] didrocks: Sounds fun. :/ [13:57] it is, trying to get dx people working on it [13:58] * infinity nods. [13:58] Keep us posted. [13:58] didrocks, ack. [13:58] will do :) [13:58] If it's a readable and reviewable fix (and soon!), we can totally get it in, otherwise, it's clearly SRU material. [13:58] skaet: infinity: the other change has just landed btw, with automated tests, I tried to trick it a lot as well ;) [13:58] infinity: that's what I told them [14:03] Erm. [14:03] So much for waiting for all arches before accepting binary NEW? [14:03] Not that that's strictly required. [14:03] erk, ppc missing; sorry about that [14:04] that was me [14:04] No big deal. [14:04] It doesn't actually break anything except my mental ref counter. [14:09] jibel, https://bugs.launchpad.net/ubuntu/+source/casper/+bug/982876, trying to figure out if this is just isolated to french or is a pervasive problem for the non-english languages? [14:09] Launchpad bug 982876 in casper "Wrong keyboard layout in Live Session (French)" [Undecided,New] [14:10] skaet, I haven't tested with another language. I have only french and US keyboards [14:11] jibel, fair enough. does gema have a spanish one? [14:11] * skaet only has us english... :( [14:11] jibel: that's bug 960096 [14:11] Launchpad bug 960096 in libxklavier "Live session started with wrong layout" [Medium,Confirmed] https://launchpad.net/bugs/960096 === ralsina is now known as ralsina_doctor [14:12] jibel: something tells me mterry's workaround (calling gsettings through dbus-launch) only reduced the race, didn't fix it [14:13] stgraber, it looks like it but it is 'fix released' [14:13] jibel: and it's also causing some more side effects (quite a few dbus-launch running for no good reason) [14:13] jibel: yeah, we need a "workaround releases" status in LP :) [14:13] jibel: feel free to mark yours as a duplicate and move back to Triaged and assigned to me [14:13] stgraber, ack [14:14] jibel: I doubt I'll have a real fix for it because ultimately it's a desktop bug, but I thought of another workaround we might try which may give better results than the current one [14:14] (I'm off today/tomorrow but I'm happy to have a look at it on Wednesday) [14:16] skaet: would you like me to try and dig out a tester with a non french & US keyboard? [14:18] phillw, thanks for the offer. jibel, is it needed? or does it sound like we've got the confirmation. [14:19] skaet, that's fine, stgraber knows the problem. thanks phillw ! [14:20] you really don't need a different keyboard ;) you just need someone to select Italian/French/whatever and check that the layout is non-US :) [14:20] but based on existing comments and jibel's new bug, I'm pretty sure we confirmed that the workaround proposed by mterry wasn't enough [14:21] (I'm usually testing these changes with French/German/Italian/Spanish/Swiss-french/Swiss-german/US/US-intl on a machine with a physical US keyboard, you just need to remember the different layouts) [14:22] Does xkb still ship that handy utility that draws pictures of layouts? [14:22] I forget what it was called. [14:22] But handy for this sort of thing, cause you can just compare the picture to what's mapped where on your physical keyboard. [14:22] yeah, you can get a picture of your layout by clicking a "show layout" (or similar) option in the keyboard indicator [14:23] you can also access that option in the keyboard layout option in the system settings [14:31] is mutter one of the universe packages that is translatable in LP? [14:32] pitti: So, I estimate that gcc-4.6 should be happy and ready for me to copy in ~2 hours, will you be around to review the next round of compilers I have to upload after that? :) [14:32] infinity: unfortunately not, I'll be at TKD then [14:32] but I will afterwards [14:32] we have TB meeting at an abysmally late hour today [14:32] Ahh, kay. No big deal, I'm sure I can get slangasek to do it. [14:32] so I can append another nightshift after sport and dinner [14:33] I just want it all in and out of the queue as quickly as I can, as it probably represents a couple of days of build time. [14:33] Have I mentioned lately how much I adore bikesheds? [14:34] infinity, pitti - we may want to be careful around the builds of this to not block up the other critical stuff that needs to land in main. [14:35] (or at least score it so it behaves nicely, once its uploaded) [14:35] it should [14:35] It'll be fine. [14:35] I suppose most of whaht infinity wants to upload is the -cross stuff? [14:35] which is universe, and thus schedules itself [14:35] Thanks pitti for the Studio-related uploads! [14:35] pitti: gcj* cross* clang gdc gccgo gnat... [14:36] astraljava: YW [14:36] infinity: you do like the fun stuff, don't you [14:36] Sure do. :/ [14:36] infinity: so, I'll be back around 2000 UTC [14:36] Has anyone confirmed that python-qt4 in proposed fixes UbuntuOne yet? [14:36] and will have a full hour to spend until TB, so plenty of time for pushing buttons [14:38] pitti: How often is pending-sru.html updated? [14:38] infinity: every 30 mins, after the publishers [14:39] Mmkay. [14:39] I suppose that makes some sense. [14:41] infinity: there's again tons of ppc FTBFS due to arch skew, I'll retry them later [14:41] pitti: I've just been looking at those. Don't worry about it. ;) [14:42] oh, thanks [14:42] pitti: Do you actually prefer the ubuntu//+source URLs over the ubuntu/+source ones? [14:42] (Drives me nuts that this page sends me to the series one, not the base one) [14:42] infinity: actually I don'ot [14:43] * pitti changese in lp:u-a-t [14:43] Well, it also drives me nuts that those two UIs are different in soyuz... [14:44] pitti: Same for the ones that go to +source/, the non-series URL is much saner (IMO). [14:44] full ack, changing [14:46] infinity: committed and rolled out, next refresh should have it [14:46] * infinity wonders why we've had NEW source in oneiric's queue since December, and if there's a reason no one's rejected it... [14:48] I think I pinged zul about them the other day, but didn't get or forgot the response [14:48] I'm going to go out on a limb and say that if it's been there for more than 4 months, no one cares. [14:48] Plus, at least one of them claimed it was "targetted to precise", which it wasn't. [14:48] ah, and live-manual was new, accepting that one [14:49] Kinda curious about the process fail behind a partner package being stuck in there since October... [14:49] Surely, someone should have complained about that one? [14:50] TBH I don't really know how the partner archive works process-wise [14:51] People upload, we accept after very cursory reviews, life goes on. [14:51] But you'd think something that's been stuck for six months would have led to an inquiry by... Someone? [14:51] yeah [14:52] chrisccoulson: Are you planning to upload new flashplugin-nonfree packages to *-proposed to match your adobe-flashplugin bumps to partner, or should one of us do that? (I already did precise) [14:55] Holy crap, what kind of magic is that, Etherpad? [14:55] When you block copy and paste, it keeps the author colors. [14:55] That's awesome. [15:02] infinity: wrt. pyqt4, I don't know what it fixes in U1; I asked the U1 girls/guys [15:03] the bug description and dupes don't explain [15:03] pitti: Perfect. Yeah, I have no idea what it was breaking either. ScottK might know, I dunno. [15:04] looks like a good patch either way, and there's confirmation that it fixes the original bug [15:04] infinity: hah, alecu _is_ the U1 guy :) [15:04] * pitti rubberstamps in the pad [15:05] * pitti copies over [15:06] * highvoltage also does an action [15:07] pitti: I don't know dbus well enough to know if it's a good patch. To me, it looked like an attempt to shrink a race window, rather than close it. [15:07] yes, the "if NULL" check certainly doesn't fix the root cause, but it looks regression proof to me [15:08] Oh, it's certainly not worse than it was before, that's why I accepted it to proposed. [15:08] do you guys have an opinion on https://code.launchpad.net/~charlesk/libunity/lp-981309/+merge/101998 (leak fix in libunity) for release or as SRU? [15:10] That diff confirms my bias against Vala once again... [15:10] seb128: I'm told that the unity folks are still working on some other last-minute fixes or some such? [15:10] infinity, the .C part you mean? ;-) [15:11] infinity, well libunity is a different source [15:11] seb128: Ahh, so there's nothing in the works for libunity? [15:11] err, wouldn't it be easier to show the actual vala diff? [15:11] pitti: The vala diff is at the bottom.. It's a merge proposal. :P [15:11] And the vala diff is vile. [15:11] pitti, it's in there [15:12] ok, that looks a bit magic [15:12] Double-casting the same variable to try to make it generate sane code. [15:13] I'm off for now, cu in some 5 hours [15:13] seb128: The fix looks sane to me (in as much as fooling Vala into doing what you want ever looks "sane") [15:13] I have no strong opinion on release versus updates for it. [15:13] infinity, ok, thanks, i'm trying to figure how much is leaked and will come with an upload if it turns to be "enough that we want it fixed for release" [15:13] But if we're doing other unity updates too, throw it at proposed, and see if it sticks? :P [15:14] ok ;-) [15:39] hi infinity. sorry, just went to do exercise [15:39]