[00:01] <cjwatson> Searching.  (It takes a little while since it has to download all the build logs.)
[00:02] <cjwatson> Bet it's faster than you clicking through all of them, though. :-)
[00:02] <micahg> yes, thanks
[00:02] <cjwatson> Were you build-testing them as well, or just throwing them back against the wall?
[00:03] <slangasek> so what do people think of a sudo upload for bug #982684 and bug #979319?
[00:03] <ubot2> Launchpad bug 982684 in sudo "sudo doesn't apply global environment settings from /etc/environment" [Medium,Triaged] https://launchpad.net/bugs/982684
[00:03] <ubot2> 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] <micahg> cjwatson: test building one arch first
[00:04] <cjwatson> OK, I'll not bother :)
[00:04] <cjwatson> If they fail, at least the new reason will be visible to all
[00:04] <micahg> buildds are empty enough
[00:41] <cjwatson> 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] <cjwatson> script still seems to be running so I guess there might be some more
[00:45] <cjwatson> but I'm off back to bed now, so if you have more, ask somebody else :)
[00:45] <micahg> cjwatson: ok, thanks for your help
[00:45] <cjwatson> oh, I think that's it, it had started on superseded ones (it's not very smart)
[01:03] <infinity> cjwatson: Yeah, I noticed it had been committed after I asked.
[02:02] <slangasek> oh bah, sudo doesn't call pam_getenvlist(); I guess I can't fix that one so easily
[02:31] <infinity> By the way, no one copy eglibc to the release pocket until gcc-4.6 is also ready to go.
[03:21] <slangasek> infinity: how's eglibc itself coming on armhf?
[03:21] <slangasek> documented on the pad
[03:37] <jbicha> ^ that fix took me a while to figure out
[03:38] <micahg> 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] <pitti> Good morning
[04:25] <pitti> infinity: the apport workaround fully fixes the problem for apport
[04:25] <pitti> infinity: the GTK+ patch was reviewed upstream, I'll commit it upstream and merge it into today's GTK .1 upload
[04:25] <pitti> infinity: as we have similarly large dupe lists in software-center and other places; I'll reassign those bugs and dupe them
[04:25] <pitti> infinity: mvo's patch seems fine
[04:26] <pitti> infinity: sru-release -r does the -proposed -> release copying, it's in lp:ubuntu-archive-tools
[04:26] <pitti> 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] <pitti> ^ FTR, I used --no-lp for the sync, as I uploaded to Debian and Ubuntu at the same time
[06:02] <pitti> anyone who could review my GNOME 3.4.1 -proposed uploads?
[06:05] <slangasek> 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] <pitti> well, not in the sense of pre-reviewing the chhanges
[06:06] <pitti> only that we'll land the gnome 3.4.1 bits today
[06:06] <pitti> as it's being released today, and tarballs come in
[06:07] <pitti> the .1 tarballs are traditionally on a tight schedule
[06:07] <slangasek> yeah
[06:08] <pitti> glib/gtk have bigger changes, as expected; the others should be mostly harmless
[06:08] <pitti> e. g. gdk-pixbuf is rather simple (and has a nice security fix, too)
[06:25] <pitti> self-rejecting glib2.0, need to check something
[07:18] <didrocks> pitti: unity ready ^
[07:52] <didrocks> pitti: and the compiz-plugins-extra rebuilds for c-p-m ABI break ^
[07:52] <pitti> didrocks: cheers
[07:52] <didrocks> pitti: thanks :-)
[07:52] <didrocks> ok, now that the morning ping is ended, let's finish the week-end email backlog :)
[08:35] <didrocks> ok with this fix: https://bugs.launchpad.net/compiz-compizconfig-gconf/+bug/979770 ? quite safe, tested by seb128 and I
[08:35] <ubot2> 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] <seb128> didrocks, I continued running that over the w.e, I confirm it works ;-)
[08:35] <didrocks> great! ;)
[08:37] <pitti> seb128: if only we had a glib which would provide g_free(), g_strdup0(), and all that stuff..
[08:37] <pitti> err, didrocks ^
[08:37] <pitti> didrocks: LGTM
[08:38] <didrocks> pitti: life would have been wonderful right? But such things can't exist! :)
[08:41] <didrocks> 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] <seb128> didrocks, right, though it's cc-gconf and gconf uses glib :p
[08:42] <didrocks> seb128: ironic, isn't it? ;)
[08:59] <doko> pitti, I think it's time to remove zope2.12 and python2.6, could you do that?  bug 979923
[08:59] <ubot2> 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] <pitti> \o/
[09:01] <pitti> doko: hm, do we have a newer zope in precise/
[09:01] <pitti> ?
[09:01] <pitti> -- precise/universe i386 deps on zope2.12:
[09:01] <pitti> zope-maildrophost
[09:01] <pitti> zope-mysqlda
[09:01] <pitti> zope-replacesupport
[09:01] <pitti> I can't find zope2.13 or zope2.14
[09:04] <pitti> doko: ah, the description says; I guess those three should be removed along then?
[09:05] <doko> pitti, I don't understand ...
[09:05] <pitti> doko: I mean, above three packages depend on zope2.14 | zope2.13 | zope2.12 | zope2.11 | zope2.10 | zope2.9 | zope2.8
[09:05] <pitti> doko: but AFAICS we don't have any other zope version packaged, so shoudl I just remove these three rdepends, too?
[09:06] <pitti> well, in fact we don't have the zope2.12 binary either, so they are uninstallable anyway
[09:07] <pitti> doko: both removed, blacklisted, bug updated
[09:08] <infinity> +* Excessive dependencies have been culled from Requires: lines
[09:08] <infinity> +  in .pc files. Dependent modules may have to declare dependencies
[09:08] <infinity> +  that there were getting 'for free' in the past.
[09:08] <infinity> pitti: ^--- That's a scary change for a .1 ...
[09:10] <doko> pitti, which rdepends are you talking about?
[09:10] <doko> ahh, zope-*
[09:10] <pitti> infinity: I think that's catching up with changes that we already have; the actual diff doesn't change the .pc
[09:10] <doko> yes, I think so
[09:10] <infinity> pitti: Kay, fair enough.
[09:10] <pitti> doko: kidn of a false postiive; as zope2.12 never actually built, these were uninstallable already
[09:11] <pitti> doko: but I guess we can still remove them, but not blacklist?
[09:11] <infinity> 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] <pitti> infinity: where do you read this?
[09:13] <pitti> infinity: I don't see it in NEWS?
[09:13] <infinity> pitti: README.
[09:13] <infinity> +* GtkApplication no longer uses the gtk mainloop wrappers, so
[09:13] <infinity> +  it is no longer possible to use gtk_main_quit() to stop it.
[09:13] <infinity> +* GTK+ now uses <Primary> instead of <Control> in keyboard accelerators,
[09:13] <infinity> +  for improved cross-platform handling. This should not affect
[09:13] <infinity> +  applications, unless they parse or create these accelerator
[09:13] <infinity> +  manually.
[09:13] <pitti> infinity: ah, same thing -- that's catchign up with changes that were introduced way earlier
[09:14] <infinity> 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] <pitti> all those changes would indeed be qutie scary for a .1
[09:14] <infinity> pitti: Ahh, alright.  Fair enough.
[09:14] <Riddell> I'm going to upload 55 kde-l10n packages to import the translations into launchpad, ok to upload to precise?
[09:14] <pitti> they don't have build skew, so no need for -proposed IMHO
[09:15] <infinity> pitti: I hadn't gotten to auditing source yet, I just found the README in the sea of gettext poop. ;)
[09:15] <pitti> infinity: so you started with the hardest package first :)
[09:15] <pitti> infinity: (gdk-pixbuf and screensaver are trivial against that, for consolation)
[09:15] <infinity> ;)
[09:16] <infinity> gtk's probably not that bad, I just need to download the diff and pipe it through filterdiff.
[09:17] <infinity> All the autogenerated crap makes it impossible to manage in a browser.
[09:17] <pitti> infinity: oh, indeed; I usually use "queuediff", and look at it in vim
[09:17] <pitti> much easier to jump around with /^---
[09:18] <infinity> Yeah, I need a browser extension to allow some simple regexes (actually, just the ^ anchor would be enough) in firefox text searches.
[09:18] <infinity> This seems like it would be trivial to write.  For someone who spoke XUL.  Which I don't.
[09:26] <Riddell> potential spamming in process
[09:28] <infinity> Ugh.
[09:28] <infinity> stgraber: queuebot needs to learn to ignore kde-l10n-*
[09:29] <Riddell> infinity: happy for me to accept these?
[09:30] <infinity> Riddell: Already done.
[09:30] <Riddell> lovely
[09:30] <infinity> And now we'll get spammed again. :P
[09:30] <Laney> kick the bot for a minute :P
[09:34] <pitti> thanks infinity
[09:36] <infinity> 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] <infinity> Or does GNOME no longer let you set a preferred terminal? :P
[09:37] <pitti> infinity: that too
[09:37] <pitti> infinity: I also left a comment in the bug and in the pad that this breaks translations
[09:41] <infinity> pitti: Rejected for now, and noted why in the bug.
[09:45] <stgraber> infinity: now ignoring kde-l10n-*
[09:45]  * infinity hugs queuebot.
[09:48] <pitti> bonjour stgraber
[09:54] <infinity> Dearest soyuz, where did you put my eglibc binaries?
[09:54] <infinity> Finished 7 hours ago (took 5 hours, 12 minutes, 7.4 seconds) (on armhf)
[09:54] <infinity>      libc6 | 2.15-0ubuntu7 |       precise | amd64, armel, armhf, i386, powerpc
[09:54] <infinity> ^-- No armhf
[09:54] <infinity>      libc6 | 2.15-0ubuntu9 | precise-proposed | amd64, armel, i386, powerpc
[09:55] <infinity> WTF?
[09:55] <pitti> hm, nothing in NEW
[09:56]  * infinity goes to look at publisher logs...
[09:56] <infinity> I bet http://launchpadlibrarian.net/102105469/3Ixhqwb17uQG7eDWJryLXayy4i.txt relates. :/
[09:56] <pitti> o_O
[09:57] <infinity> And it's killing the publisher.  \o/
[10:00]  * infinity works on getting that fixed.
[10:07] <infinity> Okay, publisher should be fixed, but at ~60s per kde-l10n queue entry, it'll take a while to run. :P
[10:07] <stgraber> Hallo pitti
[10:08]  * pitti applauds infinifixitall
[10:10] <infinity> 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] <infinity> pitti: It'll all normalize once gcc-4.6/eglibc get copied.
[10:10] <pitti> infinity: oh, more missing armhf binaries?
[10:10] <pitti> I thought they were only missing in -proposed
[10:11] <infinity> 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] <pitti> ah
[10:11] <pitti> I just won't look for the next couple of hours then :)
[10:12] <infinity> 7 or 8 hours, probably, given that gcc-4.6 on armel has a way to go.
[10:12] <infinity> But yeah, it'll sort itself.
[10:12] <infinity> Not an issue for the buildd pipeline, since those packages ARE available there, at least. :P
[10:13] <infinity> Holy crap, Rosetta, why are you such utter fail?
[10:13] <infinity> *sigh*
[10:13] <infinity> Seriously, a minute per kde-l10n-* binary.
[10:14] <infinity> pitti: You still care deeply about all thing translation, right?  Maybe you should look at that some day. ;)
[10:14] <pitti> in my CFT
[10:14] <infinity> Ed Zachary.
[10:15] <infinity> On the plus side, maybe gcc-4.6/armel will finish before the publisher does? :P
[11:30] <apw> can someone remind me where release note tasks go ?
[11:40] <knome> is the final release notes page somewhere to edit?
[11:50] <pitti> https://wiki.ubuntu.com/PrecisePangolin/TechnicalOverview
[11:50] <pitti> you can copy https://wiki.ubuntu.com/PrecisePangolin/TechnicalOverview/Beta2 and then edit
[11:51] <pitti> (please don't edit /Beta2)
[12:15] <pitti> infinity: FTR, giving allspice back to amd64
[12:15] <infinity> pitti: Mmkay.
[12:16] <infinity> 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] <pitti> 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] <pitti> new gnome 3.4.1 tarballs coming in, fortunately mostly trivial (translation updates only)
[12:18] <infinity> Oh, there's an MIR anyway.
[12:18]  * infinity reads.
[12:20]  * infinity promotes.
[12:22] <pitti> ^ one .po file update only
[12:24]  * pitti eeks at http://people.canonical.com/~ubuntu-archive/component-mismatches.svg
[12:24] <pitti> Daviey: ^ is that under way, or will it be unseeded again?
[12:24] <infinity> pitti: Just don't look at britney output. ;)
[12:33] <pitti> ^ one simple bug fix, translation updates
[12:33] <Daviey> pitti: still targeted.. there should be open MIR's.
[12:33] <Daviey> *suck*
[12:34] <infinity> pitti: Just one po file, eh?
[12:34] <infinity> pitti: Did you forget the part where the 3 previous releases aren't in the archive? ;)
[12:35] <pitti> infinity: err?
[12:35] <seb128> infinity, did you forget the part where the queue diff stuff is buggy? ;-)
[12:35] <pitti> I diffed locally
[12:35] <pitti> there's autoconf noise, of course
[12:35] <pitti> infinity: are you looking at http://launchpadlibrarian.net/102164255/gnome-desktop3_3.4.0-0ubuntu1_3.4.1-0ubuntu1.diff.gz ?
[12:35] <Laney> it is using the last proposed upload
[12:36] <infinity> Ahh.  Special.
[12:36] <seb128> that's a bit buggy,stupid
[12:36] <seb128> it's picking the wrong version as Laney said
[12:36] <pitti> that indeed looks sad
[12:36] <seb128> it did the same on friday with gnome-control-center and some others
[12:36]  * infinity downloads and diffs manually.
[12:37] <pitti> yay for having good tools
[12:37] <seb128> dget && debdiff for the win ;-)
[12:37]  * infinity nods.
[12:38] <pitti> still, there's something wrong if it's harder to check a package than to package it in the first place :)
[12:39] <infinity> That flashplugin-nonfree upload is just version/hash bumps to match the partner upload.
[12:57] <pitti> 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] <infinity> pitti: Should get picked up in the :03 run.
[12:59] <pitti> infinity: ah, did it catch up with the kde-l10n* stuff?
[12:59] <infinity> Yeah.
[13:00] <pitti> cool
[13:00] <pitti> I'll retry stuff after that
[13:03] <pitti> ^ gtksourceview: upstream did a large patch to fix whitespace in the code, which balloons the diff
[13:04] <infinity> Because point releases are always the best time for whitespace cleanups.
[13:04] <pitti> well, better than breaking that silly and incomprehensible garbage _between_ the whitespace :-P
[13:05] <infinity> I never look at that stuff.
[13:05] <infinity> I just check to make sure everything's pretty.
[13:05] <pitti> it's all *.bf anyway, isn't it?
[13:05] <pitti> that would actually be fun: a brainfuck source with comments which translate the logic to C
[13:07] <infinity> You have an odd sense of fun.
[13:08] <infinity> Oh, FFS, argument wrapping too?
[13:08] <infinity> 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] <infinity> Oh, I guess it wasn't that much.
[13:09]  * infinity stops whining.
[13:10] <infinity> I do wonder if I'm the only person who finds argument wrapping less readable, though.
[13:10] <pitti> I personally prefer it if a single line spills over my screen line length
[13:10] <pitti> since "nicely wrapped" >> "arbitrarily wrapped"
[13:11] <infinity> Yeah, being dyslexic, you'd think I'd have the same argument.
[13:12] <infinity> Cause for actual reading (like, fiction, websites, whatever), I can't handle long lines.
[13:12] <infinity> For some reason, it irks me to wrap function calls, though. :P
[13:12] <infinity> I might just be insane.
[13:14]  * infinity waits impatiently on those last two compiler builds so he can upload 10 more.
[13:14] <pitti> oh, I need to squeeze a glib in between that
[13:15] <infinity> What's wrong with the glib that's building right now? :P
[13:15] <pitti> http://git.gnome.org/browse/glib/commit/?id=6560b37450cd19c4a7c7b690e279fe97b7bfdcaa
[13:15] <pitti> we want to revert that
[13:15] <pitti> it's causing unnecessary spewage on package installation
[13:15] <pitti> http://paste.ubuntu.com/932482/
[13:15] <pitti> sorry, I missed that before
[13:15] <infinity> Ahh.
[13:15] <pitti> it doesn't really break, but looks ugly
[13:15] <infinity> Yeah, noisy upgrades make me a sad panda.
[13:16] <pitti> and we won't fix all pacakges now
[13:16] <pitti> that's something for the start of next cycle
[13:16]  * infinity nods.
[13:16] <infinity> 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] <pitti> I think we should, yes
[13:17] <infinity> 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] <infinity> The single-include fixy shell script works wonders.
[13:17] <seb128> Debian is fixing those
[13:17] <seb128> we can drop that patch next cycle
[13:20] <infinity> pitti: Well, let's see that new glib, and we'll score it through the roof on PPC and get it in.
[13:20] <infinity> And then I'll eat the buildds with compiler uploads in a couple of hours. ;)
[13:21]  * ogra_ hands infinity some ketchup 
[13:21] <infinity> Om nom nom?
[13:21] <ogra_> or do you prefer buildds with mustard ?
[13:21] <infinity> Mayo.
[13:24] <infinity> pitti: gtk+3.0 on ARM should be happy on ftpmaster now, retry away.
[13:30] <pitti> infinity: thanks, all poked
[13:32] <infinity> Oh dear.
[13:32] <infinity> Almost the entire mousetweaks diff is someone using a different version of diffstat. \o/
[13:33] <pitti> ok, glib being quiet now
[13:33] <pitti> I did a local build/install/test for paranoia's sake
[13:33] <infinity> What's this "testing" you speak of?
[13:34] <pitti> install, reboot, check that boot, lightdm, session works, and that sudo apt-get install --reinstall shotwell is quiet now
[13:35] <pitti> it's just changing glib-compile-schemas, but oh well, with all those new compilers flying around.. :-)
[13:35] <infinity> You didn't want to feel left out? ;)
[13:35] <jbicha> what do you think of bug 982719 ?
[13:35] <ubot2> Launchpad bug 982719 in mutter "FFe: Add Unity's window keyboard shortcuts to GNOME Shell" [Undecided,New] https://launchpad.net/bugs/982719
[13:37] <infinity> jbicha: This would affect nothing but gnome-shell?
[13:38] <pitti> at least mutter is not being used in unity, gnome classic, xfce, KDE, etc.
[13:38] <infinity> 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] <infinity> ?
[13:38] <infinity> Err.  Typing hard.
[13:39] <jbicha> infinity: right
[13:40] <jbicha> the Ctrl+Alt+T shortcut is more challenging since GNOME has dropped the run_command_terminal shortcut
[13:41] <infinity> Oh, it's not configurable anymore?
[13:41] <infinity> Boy, I <3 GNOME.
[13:42] <jbicha> they didn't think it was important enough to clutter up the keyboard shortcuts panel
[13:42] <jbicha> I mean who uses terminals these days any way?
[13:42] <infinity> ...
[13:42] <infinity> I have, like, 70 of them open.
[13:43] <pitti> didn't we patch metacity to assing ctrl+alt+T by defualt?
[13:43] <pitti> that's still working
[13:43] <pitti> I'd notice very fast if not
[13:44] <jbicha> pitti: it works every where except for GNOME Shell, & it'll stop working when we do the gsettings switch next cycle
[13:45] <infinity> jbicha: So, could we make (for this cycle) just GNOME Shell launch gnome-terminal on c-a-t?
[13:45] <infinity> jbicha: And then we can argue later about how to make this globally sane.
[13:45] <jbicha> infinity: I'm not sure, I'll have to test that
[13:49] <infinity> Anyhow, I have no issues with #982719.
[13:50] <infinity> But trying to work the terminal shortcut into the same changeset might be nice.
[13:50] <infinity> Two birds, one stone, no breaking other desktops (for now).
[13:51] <infinity> pitti: You lost kov in the last 12 hours? ;)
[13:51] <infinity> (or however long it's been between glib uploads...)
[13:52] <pitti> debclean getting in the way again? it keeps updating Maintainers:
[13:52] <infinity> Yeah, no big deal.
[13:52] <infinity> But I found it funny that he was removed from Uploaders in such a short window. :P
[13:55] <didrocks> 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] <ubot2> 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] <infinity> didrocks: Sounds fun. :/
[13:57] <didrocks> it is, trying to get dx people working on it
[13:58]  * infinity nods.
[13:58] <infinity> Keep us posted.
[13:58] <skaet> didrocks,  ack.
[13:58] <didrocks> will do :)
[13:58] <infinity> If it's a readable and reviewable fix (and soon!), we can totally get it in, otherwise, it's clearly SRU material.
[13:58] <didrocks> skaet: infinity: the other change has just landed btw, with automated tests, I tried to trick it a lot as well ;)
[13:58] <didrocks> infinity: that's what I told them
[14:03] <infinity> Erm.
[14:03] <infinity> So much for waiting for all arches before accepting binary NEW?
[14:03] <infinity> Not that that's strictly required.
[14:03] <pitti> erk, ppc missing; sorry about that
[14:04] <pitti> that was me
[14:04] <infinity> No big deal.
[14:04] <infinity> It doesn't actually break anything except my mental ref counter.
[14:09] <skaet> 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] <ubot2> Launchpad bug 982876 in casper "Wrong keyboard layout in Live Session (French)" [Undecided,New]
[14:10] <jibel> skaet, I haven't tested with another language. I have only french and US keyboards
[14:11] <skaet> jibel,  fair enough.   does gema have a spanish one?
[14:11]  * skaet only has us english... :(
[14:11] <stgraber> jibel: that's bug 960096
[14:11] <ubot2> Launchpad bug 960096 in libxklavier "Live session started with wrong layout" [Medium,Confirmed] https://launchpad.net/bugs/960096
[14:12] <stgraber> jibel: something tells me mterry's workaround (calling gsettings through dbus-launch) only reduced the race, didn't fix it
[14:13] <jibel> stgraber, it looks like it but it is 'fix released'
[14:13] <stgraber> jibel: and it's also causing some more side effects (quite a few dbus-launch running for no good reason)
[14:13] <stgraber> jibel: yeah, we need a "workaround releases" status in LP :)
[14:13] <stgraber> jibel: feel free to mark yours as a duplicate and move back to Triaged and assigned to me
[14:13] <jibel> stgraber, ack
[14:14] <stgraber> 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] <stgraber> (I'm off today/tomorrow but I'm happy to have a look at it on Wednesday)
[14:16] <phillw> skaet: would you like me to try and dig out a tester with a non french & US keyboard?
[14:18] <skaet> phillw,  thanks for the offer.   jibel,  is it needed? or does it sound like we've got the confirmation.
[14:19] <jibel> skaet, that's fine, stgraber knows the problem. thanks phillw !
[14:20] <stgraber> 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] <stgraber> 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] <stgraber> (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] <infinity> Does xkb still ship that handy utility that draws pictures of layouts?
[14:22] <infinity> I forget what it was called.
[14:22] <infinity> 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] <stgraber> yeah, you can get a picture of your layout by clicking a "show layout" (or similar) option in the keyboard indicator
[14:23] <stgraber> you can also access that option in the keyboard layout option in the system settings
[14:31] <jbicha> is mutter one of the universe packages that is translatable in LP?
[14:32] <infinity> 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] <pitti> infinity: unfortunately not, I'll be at TKD then
[14:32] <pitti> but I will afterwards
[14:32] <pitti> we have TB meeting at an abysmally late hour today
[14:32] <infinity> Ahh, kay.  No big deal, I'm sure I can get slangasek to do it.
[14:32] <pitti> so I can append another nightshift after sport and dinner
[14:33] <infinity> 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] <infinity> Have I mentioned lately how much I adore bikesheds?
[14:34] <skaet> 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] <skaet> (or at least score it so it behaves nicely, once its uploaded)
[14:35] <pitti> it should
[14:35] <infinity> It'll be fine.
[14:35] <pitti> I suppose most of whaht infinity wants to upload is the -cross stuff?
[14:35] <pitti> which is universe, and thus schedules itself
[14:35] <astraljava> Thanks pitti for the Studio-related uploads!
[14:35] <infinity> pitti: gcj* cross* clang gdc gccgo gnat...
[14:36] <pitti> astraljava: YW
[14:36] <pitti> infinity: you do like the fun stuff, don't you
[14:36] <infinity> Sure do. :/
[14:36] <pitti> infinity: so, I'll be back around 2000 UTC
[14:36] <infinity> Has anyone confirmed that python-qt4 in proposed fixes UbuntuOne yet?
[14:36] <pitti> and will have a full hour to spend until TB, so plenty of time for pushing buttons
[14:38] <infinity> pitti: How often is pending-sru.html updated?
[14:38] <pitti> infinity: every 30 mins, after the publishers
[14:39] <infinity> Mmkay.
[14:39] <infinity> I suppose that makes some sense.
[14:41] <pitti> infinity: there's again tons of ppc FTBFS due to arch skew, I'll retry them later
[14:41] <infinity> pitti: I've just been looking at those.  Don't worry about it. ;)
[14:42] <pitti> oh, thanks
[14:42] <infinity> pitti: Do you actually prefer the ubuntu/<series>/+source URLs over the ubuntu/+source ones?
[14:42] <infinity> (Drives me nuts that this page sends me to the series one, not the base one)
[14:42] <pitti> infinity: actually I don'ot
[14:43]  * pitti changese in lp:u-a-t
[14:43] <infinity> Well, it also drives me nuts that those two UIs are different in soyuz...
[14:44] <infinity> pitti: Same for the ones that go to +source/<version>, the non-series URL is much saner (IMO).
[14:44] <pitti> full ack, changing
[14:46] <pitti> 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] <pitti> I think I pinged zul about them the other day, but didn't get or forgot the response
[14:48] <infinity> 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] <infinity> Plus, at least one of them claimed it was "targetted to precise", which it wasn't.
[14:48] <pitti> ah, and live-manual was new, accepting that one
[14:49] <infinity> Kinda curious about the process fail behind a partner package being stuck in there since October...
[14:49] <infinity> Surely, someone should have complained about that one?
[14:50] <pitti> TBH I don't really know how the partner archive works process-wise
[14:51] <infinity> People upload, we accept after very cursory reviews, life goes on.
[14:51] <infinity> But you'd think something that's been stuck for six months would have led to an inquiry by... Someone?
[14:51] <pitti> yeah
[14:52] <infinity> 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] <infinity> Holy crap, what kind of magic is that, Etherpad?
[14:55] <infinity> When you block copy and paste, it keeps the author colors.
[14:55] <infinity> That's awesome.
[15:02] <pitti> infinity: wrt. pyqt4, I don't know what it fixes in U1; I asked the U1 girls/guys
[15:03] <pitti> the bug description and dupes don't explain
[15:03] <infinity> pitti: Perfect.  Yeah, I have no idea what it was breaking either.  ScottK might know, I dunno.
[15:04] <pitti> looks like a good patch either way, and there's confirmation that it fixes the original bug
[15:04] <pitti> 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] <infinity> 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] <pitti> yes, the "if NULL" check certainly doesn't fix the root cause, but it looks regression proof to me
[15:08] <infinity> Oh, it's certainly not worse than it was before, that's why I accepted it to proposed.
[15:08] <seb128> 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] <infinity> That diff confirms my bias against Vala once again...
[15:10] <infinity> seb128: I'm told that the unity folks are still working on some other last-minute fixes or some such?
[15:10] <seb128> infinity, the .C part you mean? ;-)
[15:11] <seb128> infinity, well libunity is a different source
[15:11] <infinity> seb128: Ahh, so there's nothing in the works for libunity?
[15:11] <pitti> err, wouldn't it be easier to show the actual vala diff?
[15:11] <infinity> pitti: The vala diff is at the bottom.. It's a merge proposal. :P
[15:11] <infinity> And the vala diff is vile.
[15:11] <seb128> pitti, it's in there
[15:12] <pitti> ok, that looks a bit magic
[15:12] <infinity> Double-casting the same variable to try to make it generate sane code.
[15:13] <pitti> I'm off for now, cu in some 5 hours
[15:13] <infinity> seb128: The fix looks sane to me (in as much as fooling Vala into doing what you want ever looks "sane")
[15:13] <infinity> I have no strong opinion on release versus updates for it.
[15:13] <seb128> 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] <infinity> But if we're doing other unity updates too, throw it at proposed, and see if it sticks? :P
[15:14] <seb128> ok ;-)
[15:39] <chrisccoulson> hi infinity. sorry, just went to do exercise
[15:39] <chrisccoulson> mdeslaur_ has been handling the flashplugin-nonfree updates, but i can do that if i need to. i can't copy it to -security though ;)
[15:39]  * jdstrand would be happy to sponsor them
[15:52] <infinity> chrisccoulson: Oh, if you've got a process of some sort, I won't bug you. :P
[15:53] <infinity> chrisccoulson: I just didn't want to accept all the partner uploads without matching ubuntu uploads.
[15:53] <chrisccoulson> infinity, sure
[15:57] <chrisccoulson> infinity, mdeslaur isn't around today. i'm just trying to sort out what's happening with it :)
[15:59] <chrisccoulson> infinity, ok, we're sorted. could you approve the uploads to partner?
[16:01] <infinity> chrisccoulson: Sure thing.
[16:01] <chrisccoulson> thanks
[16:09] <infinity> And since I beat queuebot to it, eglibc was in that sync/accept cycle too.
[16:14] <skaet> thanks infinity
[16:35] <stgraber> jibel: any chance you can do a few more tests for bug 960096?
[16:35] <ubot2> Launchpad bug 960096 in libxklavier "Live session started with wrong layout" [Medium,Confirmed] https://launchpad.net/bugs/960096
[16:35] <stgraber> jibel: my current guess is that it's racy, so would be great if you could confirm that
[16:37] <slangasek> oh fun, why's upstart FTBFS on arm*?
[16:39] <slangasek> infinity: what's changed on meissa and iara since April 10, or what's different about them from chort and caph, that would cause test failures when building upstart?
[16:39] <infinity> Nothing, and nothing.
[16:42]  * infinity tests locally...
[16:42]  * slangasek throws one back to see if it's reproducible
[16:51]  * SpamapS re-posts
[16:51] <SpamapS> is precise-proposed 0-day SRU's now?
[16:51] <SpamapS> or are we still using it to stage up things?
[16:51] <slangasek> it's both
[16:52] <slangasek> SpamapS: if you accept something into -proposed with the intent that it not go to -release, please document this on http://pad.ubuntu.com/ubuntu-frozen-archive so the release team knows
[16:53] <infinity> (Mention it on IRC too, please)
[16:53] <ScottK> infinity and pitti: Thanks for taking care of python-qt4.
[16:56] <SpamapS> I think I'll just hold off then
[16:56] <SpamapS> its not clear with any of the uploads
[17:00] <slangasek> pitti: I'd like to kick defoma out of main; it's currently held there via fontconfig + x-ttcidfont-conf, x-ttcidfont-conf is only in main because of a spurious recommends from pango and two fonts - it's dead weight that doesn't actually provide anything interesting for us.  Do you think an upload of pango+fontconfig+2 fonts to kill it off would be ok?
[17:01] <infinity> That frees up CD space too.
[17:01] <infinity> I can't see how that's possibly bad. :P
[17:02] <infinity> (But without x-ttcidfont-conf installed, don't some X bits lost access to defoma-using fonts?)
[17:03] <infinity> Which could be non-obvious, if we still have such things in universe and they appear to "not work anymore".
[17:03] <infinity> s/lost/lose/
[17:04] <slangasek> there are no X bits that *care* about defoma-using fonts
[17:04] <infinity> slangasek: And your rebuild worked.  Disconcerting.
[17:04] <slangasek> ok, grand
[17:05] <slangasek> infinity: if anything in X cared about defoma, there'd be a much better revdep pulling it in than pango, which a) has nothing to do with X, b) is pulling it in spuriously as an option for managing a config file that no longer exists
[17:05] <infinity> Hah.
[17:05] <infinity> That convinces me, then. :P
[17:05] <slangasek> now, I should still look closely at fontconfig's usage before I chop it up
[17:05] <infinity> I know what x-ttcidfont-conf used to do, I'm not up on the current state of fontery.
[17:05] <slangasek> since fontconfig does integrate a bit better with X
[17:06] <slangasek> OTOH, fontconfig supersedes defoma, so
[17:07] <slangasek> hmm, pango /did/ have an ubuntu-desktop branch, but the current package's Vcs fields don't point to it and it hasn't been updated since oneiric... UDD it is then
[17:08] <slangasek> ah, and the UDD branch is stale due to an import failure, how droll
[17:09]  * infinity is a big fan of apt-get source. :P
[17:12] <slangasek> hmm
[17:12] <slangasek> ok, looking closely I see that /var/lib/defoma/x-ttcidfont-conf.d/dirs/TrueType is on the X server's compile-time font path
[17:12] <slangasek> so anything using X fonts *might* care about this
[17:12] <slangasek> OTOH, what actually cares nowadays?
[17:14] <infinity> Probaby nothing in main.
[17:15] <slangasek> a further argument: pango in testing has already dropped ttcid, Debian bug #660062.
[17:15] <ubot2> Debian bug 660062 in libpango1.0-0 "libpango1.0-0: please remove recommends on x-ttcidfont-conf" [Wishlist,Fixed] http://bugs.debian.org/660062
[17:16] <infinity> And fontconfig?
[17:21] <phillw> hi, there is abug being tracked (and for the life of me, i cannot find it) which would require the testing kernel to be used. Is this going to happen?
[17:22] <infinity> ?
[17:22] <infinity> "The testing kernel"?
[17:22] <phillw> it is a proposed kernel, from what I read of the bug report.
[17:23] <infinity> We're pretty unlikely to have another pre-release kernel upload, unless there's a dire issue.
[17:23] <phillw> as I cannot find the bug in my logs, I was wondering if any of you were aware of a possible last minute kernel change.
[17:25] <phillw> infinity: of that I am very aware of, but as the bug mentioned it as a fix - I have the lubuntu-qa team on stand by in case it happens. I really wish I could find the bug number! I just know it is someone from kernel team dealing with it.
[17:29] <infinity> slangasek: ^--- Those 8 should be the last compiler uploads, now I just need to unbreak d-i.
[17:29] <slangasek> infinity: "and fontconfig" - defoma dep still there in unstable, and it's the only one.  I'll have to look further.
[17:30] <slangasek> infinity: compilers> ack; will review shortly.  since these are going to -release and need to be in sync by release date, do you have an estimate of the combined build time?
[17:31] <infinity> slangasek: Well, they'll build mostly in parallel on arm*, so not a big deal there, I'd give it maybe an average of 3h per package on PPC?
[17:31] <infinity> slangasek: At worst, a day for everything to catch up, I'd figure.
[17:31] <slangasek> infinity: and is ppc itself caught up-ish right now?
[17:32] <infinity> Yeah, PPC is caught up.
[17:32] <slangasek> ok
[17:33] <infinity> Well, modulo a couple of tiny packages.
[17:33] <infinity> But basically caught up.
[17:34] <hallyn> stgraber: ok, pushed a new lxc with utlemming's fix for cloud image creation of guests older than precise
[17:35] <stgraber> hallyn: ok, I'll take a look when it hits the queue
[17:37] <ScottK> stgraber: Didn't see your note here and accepted it.
[17:38] <slangasek> infinity: analysis in bug #983274; dunno if you have anything to add
[17:38] <ubot2> Launchpad bug 983274 in pango1.0 "pango should drop the recommends on x-ttcidfont-conf" [Medium,New] https://launchpad.net/bugs/983274
[17:40] <infinity> slangasek: The "it's gone from Debian and no one seems to care" argument is pretty strong.
[17:40]  * slangasek nods
[17:41] <infinity> slangasek: Given that Debian users/developers are far more likely to care about old skool X font rendering than Ubuntu users are.
[17:41] <slangasek> I checked the bugs filed against xorg-server, which was how I found the one requesting dropping it from the font path
[17:41] <slangasek> el subproceso s'ha instaŀlat el script pre-removal se mató con la señal
[17:42] <slangasek> grr, stupid word-by-word translations
[17:42] <infinity> Does it require any code mangling, or it is really just dropped a Recommend?
[17:42] <infinity> s/dropped/dropping/
[17:42] <slangasek> infinity: just the recommend
[17:42] <infinity> Cause if it's just mangling a relationship, I'm convinced.  Go for it.
[17:42] <slangasek> ok
[17:42] <infinity> If it turns out to be a Very Bad Thing, it's pretty trivial to revert. :P
[17:43] <slangasek> yeah; uploaded, I'll be sure to do some testing today here with defoma+x-ttcidfont-conf purged to make sure nothing regresses
[17:44] <infinity> Yeah, I'll dump it here and go for my semi-annual reboot, and see if my XFCE desktop gets wonky.
[17:44] <stgraber> ScottK: ok, thanks for the review
[17:46] <infinity> Oh, I was about to say "what about fontconfig", but that's only a suggests.
[17:48] <slangasek> infinity: suggests but also a build-dep
[17:48]  * infinity notices that he's hungry, and decides to do something about that.
[17:48] <slangasek> I'll get there though - one thing at a time
[17:48] <infinity> slangasek: Oh, I didn't check the source.
[17:51] <micahg> infinity: reverse-depends -c main src:defoma -b :)
[17:56] <infinity> Oh, shiny, someone reimplemented checkrdepends.
[17:56] <infinity> Cause you can never have too many of the same tool!
[17:58] <micahg> infinity: checkrdepends needs a local copy of the packages files :), this is service based
[17:58]  * infinity nods.
[17:59] <micahg> also, this one doesn't bother with in-source dependencies
[18:00] <slangasek> micahg: neither does the current checkrdepends?
[18:00] <micahg> slangasek: ah, I must have an outdated version then :)
[18:11] <ScottK> Riddell: Do you want to respin the Kubuntu images now so we can double check for sizing?  That was if it's not fixed enough we have another shot today.
[18:11] <infinity> roaksoax: Why sure, an FFe for #983091 seems reasonable, thanks for asking!
[18:31] <Riddell> ScottK: doing
[18:33] <infinity> slangasek: The buildds are bored and want compilers.  They told me.
[19:05] <slangasek> infinity: in they go
[19:06] <micahg> whoops ^^ ppa version
[19:07] <slangasek> Daviey: ^^ rejecting that based on the version number
[19:23] <roaksoax> infinity: could you please reject the maas upoad I just did please?
[19:24] <roaksoax> or anyone else in the release team :)
[19:24] <roaksoax> ah its done already, never mind
[19:24] <infinity> The one that was already rejected?
[19:24] <roaksoax> thanks :)
[19:25] <ScottK> It was pre-rejected.
[19:25]  * roaksoax needs to update dput.cfg :(
[19:55] <pitti> slangasek: defoma kicking> +10 from me; most defoma stuff was already killed ages ago, seems we dropped the ball on the last meters
[20:00]  * pitti clears the compiler stuff
[21:11] <jibel> stgraber, I got 960096 systematically on a mac mini and an eeepc. but it works on another machine.
[23:34]  * skaet just bumped into another timeout on the pad... grumble.