[06:02] <ScottK> pitti: Looking at http://people.canonical.com/~ubuntu-archive/pending-sru.html is seems that the KDE SC 4.7.3 SRU only got partially copied over.  A big chunk of them are in -updates, but all the ones listed against bug #901975  should have been copied together.  Not sure what happened.
[06:05] <RAOF> ScottK: I'm not sure pitti's here; can I do anything to help?  I was planning on running through the SRUs before ending the day; it looks like all the ones you're concerned about should be picked up in my normal processing?
[06:14] <ScottK> RAOF: The concern I have is that it looks like half of KDE got moved and half didn't.
[06:14] <ScottK> I doubt it will cause a problem, but it was tested together, so it's better, IMO, to get it all moved as close to one time as possible.
[06:14] <RAOF> So, that's easily resolved by me moving the other half, plus the language packs, right?
[06:15] <ScottK> Yes.
[06:18] <ScottK> RAOF: Thanks for looking into it.  I'm off to bed.
[06:18] <RAOF> No problem.
[06:19] <RAOF> l10n done.
[07:09] <jbicha> anyone want to rebuild gnome-shell for oneiric (bug 903382)? my upload rights aren't sufficient for that :(
[07:11] <broder> jbicha: just a no-change rebuild to oneiric-proposed? i can do that
[07:13] <jbicha> broder: yes, thank you!
[07:15] <micahg> jbicha: can you merge gnome-shell from Debian so there are no more issues please :)
[07:15] <broder> jbicha: done. i've opened an oneiric task as well so you can target things appropriately
[07:16] <pitti> Good morning
[07:16] <pitti> ScottK: uh, sorry, I thought I caught them all; looking
[07:18] <pitti> ScottK: I see four which are missing; I guess they again timed out and I missed them; copied now
[07:44] <pitti> wow, https://jenkins.qa.ubuntu.com/view/Precise/ looks great today
[07:44] <pitti> now, nobody break anything over the holidays :)
[07:56] <dholbach> good morning
[07:57] <pitti> hey dholbach
[07:57] <dholbach> hey pitti
[09:24] <pitti> infinity, lamont: FYI, I'm uploading new natty-proposed langpacks; I temporarily switched allspice and crested to i386 and updated the notes/description accordingly
[09:24] <pitti> will switch back once the flood is over
[09:24] <pitti> (or if we get a lot of other uploads which need amd64)
[09:28] <pitti> infinity, lamont: ah, nevermind, we copy binaries from the PPA these days, switching back
[11:09] <Laney> pitti: that email was interesting, thanks!
[11:10] <pitti> Laney: I'm glad it is; took me over an hour to write, after all :)
[11:10] <pitti> Laney: now that I've been through it I wonder how we did that in the past
[11:10] <Laney> sweating blood around milestones? :-)
[11:10] <pitti> well, partially it was spread over all developers, but for the most part we simply ignored them
[11:11] <Laney> also ignoring stuff, yes
[11:11] <pitti> and then taking the mass removal club before release time, yes
[11:14] <cjwatson> pitti: thanks, indeed!
[11:14] <cjwatson> Laney: can I remove the ghc-ghci r(b)deps on armel/armhf/powerpc?
[11:14] <cjwatson> binaries, I mean
[11:14] <cjwatson> I think that would clean up http://people.canonical.com/~ubuntu-archive/transitions/ghc.html somewhat
[11:14] <Laney> if they no longer build, then yes please
[11:14] <Laney> are built* — I was going to ask for that at some point
[11:15] <cjwatson> haskell-clientsession haskell-convertible-text haskell-data-accessor-template haskell-file-embed haskell-hamlet haskell-haxr haskell-hledger-web haskell-path-pieces haskell-quickcheck haskell-syb-with-class haskell-type-level haskell-web-routes-quasi
[11:15] <cjwatson> is the list, I believe
[11:15] <cjwatson> oh, maybe not haskell-quickcheck
[11:17] <dantti> cnd: ping
[11:19] <cjwatson> actually it looks like just haskell-clientsession haskell-file-embed
[11:20] <Laney> not sure which of the list has OOD binaries
[11:22] <cjwatson> just those two by the looks of things
[11:22] <cjwatson> done now
[11:22] <cjwatson> (and only on powerpc)
[11:24] <cjwatson> hm, may be some others for other reasons though
[11:24] <Laney> bbs
[11:25] <cjwatson> ah yes, I need to hit checkrdepends recursively
[11:26] <mok0> ls
[11:29] <ScottK> pitti: Thanks.
[11:30] <cjwatson> ... that doesn't yield any more packages to remove, though, so good
[11:30] <mok0> Who is familiar with Mesa?
[11:30] <mok0> ... or rather mesa-glw
[11:32] <ajmitch> pitti: great writeup in that email :)
[11:42] <mok0> In Debian, the package libglw-mesa comes from source package mesa_7.11.2-1, but in Ubuntu it comes from source package mesa-glw. What is the reason for this?
[11:44] <mok0> The package provides the library libGLw.so, which is broken on Ubuntu
[11:44] <mok0> but fixed in Debian Re: BTS #624156
[11:46] <mok0> I also see that Ubuntu has its own version of mesa: 7.11-0ubuntu4
[11:47] <TiMiDo> hi guy's
[11:47] <TiMiDo> good Morning
[11:53] <ogra> mok0, try #ubuntu-x
[11:53] <mok0> ogra, thx, I will
[11:54] <ogra> just guessing, but its probably a universe/main issue that there is a separate source package
[11:57] <TiMiDo> python 2.7 sure look nice ;)
[11:57] <TiMiDo> very powerful
[11:58] <mok0> TiMiDo: What makes you say that? Very few changes from 2.6
[11:58] <cjwatson> built-in collections.OrderedDict is nice
[11:58] <cjwatson> tedious to write directly
[11:59] <TiMiDo> yeah correct mok0
[11:59] <mok0> ... Now 3000K *is* powerful. Wish all extensions could be updated soon
[12:00] <TiMiDo> more fun ;) we'll have
[12:00] <mok0> Numpy for example
[12:00] <TiMiDo> django is a cool small project
[12:00] <mok0> he
[12:00] <TiMiDo> but at the same time powerful
[12:00] <mok0> You call that "small"?
[12:01] <TiMiDo> yeah I seen pythons applets or apps reaching the 2GB
[12:01] <TiMiDo> in my class ;)
[12:02] <mok0> TiMiDo: Those are huge. Django is big
[12:02] <mok0> In my world
[12:02] <TiMiDo> oh in my class i seen bigger apps
[12:02] <TiMiDo> so that's why
[12:02] <mok0> Since you can do an incredible amount of stuff in just a few hundred lines of Python
[12:03] <jml> I can't switch to my lucid schroot since upgrading to precise
[12:03] <jml> $ schroot -c lucid-amd64
[12:03] <jml> E: 10mount: mount: unknown filesystem type 'aufs'
[12:03] <jml> E: lucid-amd64-2cb56580-9dfe-41be-a214-44663808dca9: Chroot setup failed: stage=setup-start
[12:03] <TiMiDo> yeah mok0
[12:03] <TiMiDo> mok0, where ya from?
[12:04] <mok0> TiMiDo: Aarhus, Denmark
[12:04] <TiMiDo> let me guess germany?
[12:04] <cjwatson> jml: you may need to switch union-type to overlayfs
[12:04] <TiMiDo> oh nice ;)
[12:04] <mok0> TiMiDo: Close but no cigar :-)
[12:04]  * TiMiDo from Miami Florida
[12:04] <cjwatson> jml: and possibly amend union-mount-options
[12:04] <mok0> TiMiDo: what are you doing in front of the computer :-)
[12:05] <mok0> TiMiDo: get out and fight some alligators
[12:05] <TiMiDo> hahahaha yeah
[12:05] <mok0> :-)
[12:05] <TiMiDo> i was creating a small plugin for audacious
[12:05] <jml> cjwatson: thanks. will try that.
[12:05] <TiMiDo> that can control eq's at the same time some pitching libraries is not bad.
[12:06] <mok0> TiMiDo: nice
[12:06] <TiMiDo> man i feel like taking a small trip to Europe
[12:06] <TiMiDo> i need some vacations.
[12:08] <cjwatson> jml: we're probably stuck with this kind of thing until such time as one of the union filesystems actually makes it upstream; overlayfs is the most plausible candidate right now, I think
[12:16] <jml> cjwatson: changing union-type fixes the issue, thanks.
[12:17] <cjwatson> you're welcome.  (I don't use unioning with schroot as yet so hadn't noticed that myself.)
[12:18] <cjwatson> I ought to sort out moving from pbuilder to sbuild, which would benefit from union-mounting.
[12:46] <jml> cjwatson: Well, essentially all I did was run mk-sbuild in relative ignorance, in an attempt to get set up for backporting things to lucid
[14:12] <kirkland> pitti: howdy
[14:20] <doko> pitti: packages like magics++ still ftbfs :-/
[14:20] <pitti> doko: yes, on ppc :(
[14:21] <doko> and arm*
[14:24] <doko> pitti: so the archive (at least main) should be in a pretty consistent shape?
[14:25] <pitti> it is right now; I hope it doesn't completely fall apart over the holidays
[16:08] <wip> Does gtk_status_icon_new still works on Unity?
[16:08] <wip> the new indicator (blacklist / whitelist) is causing me trouble with wxWidgets applications
[16:08] <wip> see http://groups.google.com/group/wx-users/browse_thread/thread/e688d6d188003f87 for an explanationb
[17:20] <doko> tgall_foo, pitti: please see https://launchpad.net/~doko/+archive/toolchain for the libjpeg-turbo and libjpeg8-empty packages
[17:20] <tgall_foo> doko, great thanks
[17:20] <doko> updates work for me, and the system doesn't explode, but I'd like you to verify
[17:20] <tgall_foo> shall do
[17:22] <slangasek> pitti: are you planning to take care of the libverto build-dep switch?
[17:48] <pitti> doko: trying now; why do we need -empty, though?
[17:49] <pitti> slangasek: it's a little more than just the b-dep switch; it needs some packaging changes, build a new binary, drop the old one, and then test krb5 against that
[17:49] <pitti> slangasek: as I'm on holiday, and AFK from tomorrow on, I can do it in January, but not this week any more
[17:49] <slangasek> pitti: are you sure that changing the build-dep changes the ABI of libverto itself?
[17:49] <pitti> still need to get the new lucid/maverick langpacks settled with micag, so no promises for this year
[17:50] <pitti> slangasek: I hope it won't
[17:50] <slangasek> pitti: anyway, if you're not taking it that's perfectly fine, krb5 wasn't actually an autosync but a sync I did manually so I bear some responsibility ;)
[17:50] <doko> pitti: this source package defines the libjpeg8* dependency packages; didn't want to change libjpeg8 yet, in case we have to revert the change. with this setup, we can just re-upload libjpeg8, and remove libjpeg8-turbo
[17:50] <slangasek> right; if it doesn't change libverto's ABI, then no need to change the package names
[17:50] <pitti> slangasek: but I'd at least build krb5 against it and see whether it runs some tests, etc.
[17:50] <slangasek> sure
[17:50] <slangasek> or I could just build krb5 against it, install it, and check whether my entire home network falls apart ;)
[17:50] <pitti> slangasek: well, it currently builds libverto-libev and libverto-libglib variants; I suppose it should build a libverto-libevent variant then
[17:51] <slangasek> I look into it
[17:51] <slangasek> I'll
[17:51] <pitti> I have NFC about the package, so it might be that you need to specify the backend in some constructor call or what not
[17:51]  * slangasek suppresses his inner Russian
[17:52] <pitti> doko: I installed libjpeg-turbo8 now, and at least eog foo.jpg still works; but I notice it doesn't divert the original library, so if I'd purge -turbo again my system will be hosed
[17:52] <pitti> doko: do you still plan to add that?
[17:52]  * pitti reboots in the meantime to test it more system-wide
[17:53] <doko> pitti, no, therefore the dependency package. the diversion is gone
[17:54] <pitti> doko: what's wrong with the diversion? I don't see how the dependency package will fix that
[17:55] <pitti> doko: anyway, I still see icons and background images, etc., so it seems to work here
[17:56] <doko> pitti, wasted space, and afaicr cjwatson_ argued against using the diversion
[17:56] <pitti> well, in this case I think we should really just apply the patch to libjpeg itself
[17:56] <pitti> because this just breaks libjpeg8
[17:57] <pitti> phone, bbl
[17:57] <doko> pitti, why should it break?
[17:58] <pitti> you can't remove libjpeg-turbo8 any more (but nothing in the packaging system stops you from it)
[17:58] <pitti> no biggie, but just want to mention it
[17:59] <pitti> I apt-get install --reinstall libjpeg8 now, so it's fine
[17:59] <doko> well, ok. I'll add a dependency on the new libjpeg8
[18:10] <broder> jml: fyi, mdeslaur patched mk-sbuild to use overlayfs as of u-d-t 0.136, so new chroots should use it
[18:11] <broder> mdeslaur: do you think it makes sense for, say, an schroot postinst to try and migrate aufs chroots to overlayfs?
[18:12] <jml> broder: good to know, thanks.
[18:14] <mdeslaur> broder: hrm, maybe...I don't have a strong opinion, it's users are typically power users anyway
[18:17] <mdeslaur> broder: it currently probes the running kernel to decide on overlayfs vs. aufs, so the postinst would need to do that too I guess
[18:18] <broder> hmm...maybe the better solution would be to have a "union-type=default" or something and have schroot pick the right one for the system
[18:18] <slangasek> blast, the patch in bug #874774 isn't even addressing the right bug
[18:18] <broder> that + a useful error if you set union-type={aufs,overlayfs} and it can't start because the fs isn't available
[18:23] <tumbleweed> broder: yeah, the probing was a quick hack
[18:23] <tumbleweed> (debian doesn't have overlayfs yet)
[18:24] <broder> right, but as jml pointed out, the upgrade experience kind of sucks atm
[18:24] <cjwatson> sbuild.postinst doesn't work well as a place for it, because you might upgrade sbuild then the kernel
[18:24] <cjwatson> in fact you probably will in a one-shot upgrade
[18:24] <cjwatson> (I mean, upgrade sbuild then reboot into the new kernel)
[18:25] <tumbleweed> cjwatson: see broder's next suggestion
[18:25] <cjwatson> yes, that would work better
[18:26] <tumbleweed> of course, for sbuild chroots, the easiest upgrade path is to blow them away and rebuild them
[18:26] <broder> yeah, i think this is actually pretty simple - you need to change the C++ verification code to accept union-type=auto, but after that i think you can do everything from /etc/schroot/setup.d/10mount
[18:27] <broder> tumbleweed: sed -i -e 's/union-type=aufs/union-type=overlayfs/g' /etc/schroot/chroot.d/* is pretty easy
[18:27] <dobey> will there be a DMB meeting on jan 2?
[18:27] <tumbleweed> broder: oh, that too :P
[18:27] <tumbleweed> dobey: we've said "if enough people turn up, and it sounds likely"
[18:27] <tumbleweed> err s/,/",/
[18:28] <broder> i'm planning to sign up for the 1/2 meeting, since the alternative is waiting 2 weeks *and* having to be awake at 6 AM my time :)
[18:29] <dobey> tumbleweed: well, i'm about to propose a new delegated team for ubuntuone related packages, so would like to get through that process as quickly as possible to make things work more smoothly :)
[18:32] <tumbleweed> dobey: that'd be a new packageset, right?
[18:32] <dobey> yes
[18:32] <tumbleweed> send a mail, and the discussion can begin
[18:33] <dobey> yeah, was planning on that; just wanted to make sure of when i need to be on IRC, since the wiki page says "DMB, at its next meeting…" :)
[18:56] <infinity> mvo: I should learn to just never give you ideas, shouldn't I?
[18:56] <infinity> mvo: I think you ruined my holidays by automating that hack. ;)
[19:50] <mvo> infinity: ahaha
[19:50] <mvo> infinity: I like it
[19:50] <mvo> infinity: (sort of ;)
[21:06] <doko> cyphermox, you synced libnl3 without providing a MIR for xmlstarlet
[21:08] <stgraber> doko: bug 906982
[21:09] <doko> stgraber, hmm, I didn't get the ubuntu-mir email ...
[21:11] <cyphermox> doko: sorry, had missed that xmlstarlet, I created the mir as soon as I found out (then spoke to jdstrand since there were cves for xmlstarlet in the past)
[21:46] <lumio> hello… there seems to be a bug in ubuntu 11.10 with unity: when I press the super-key aka win-key when the screen is locket, the unity interface appears. I won't be able to click anything, but I can see what apps are open and of course the unity menu
[21:59] <broder> mvo: ping? vmware-view-client shows up in software-center for me, but it's not multiarch installable to amd64 on oneiric
[22:00] <mvo> broder: and you run a amd64 system?
[22:00] <broder> yeah
[22:00] <broder> it complains about libpcsclite1:i386, libxml2:i386, libxtst6:i386, and zenity:i386
[22:00] <mvo> broder: right - you have partner already enabled, correct?
[22:00] <broder> yep (i turned it on from s-c, which was pretty slick, btw)
[22:01] <mvo> broder: glad to hear (that it was slick)
[22:01] <broder> ...oh wait...maybe not?
[22:01] <broder> ah yes - it's there
[22:02] <broder> http://paste.ubuntu.com/776841/
[22:02] <slangasek> broder: I guess the point is that software-center should suppress the display of the package on amd64, since the deps are not multiarch-ready in oneiric?
[22:02] <broder> that's probably the best solution at this point
[22:03] <broder> though offering an amd64 build would be a nice alternative
[22:03] <mvo> slangasek: yeah, I think that is the best option for now, we are in contact about a amd64 build, but I haven't heard back yet
[22:03] <mvo> broder: --^
[22:03]  * broder nods
[22:04] <mvo> but I need to call it a day for now, its rather late here
[22:04]  * mvo aves
[22:04]  * mvo waves
[22:04] <broder> mvo: do you want me to file a bug somewhere so you don't forget?
[22:04] <mvo> broder: please do!
[22:04] <broder> where would you like it?
[22:04] <mvo> broder: and assign to me please
[22:05] <mvo> broder: software-center
[22:05] <mvo> please
[22:05] <broder> kk
[22:05] <mvo> thanks!
[22:15] <slangasek>  vmware-view-client:i386 : Depends: libpcsclite1:i386 but it is not going to be installed
[22:15] <slangasek>                            Depends: zenity:i386 but it is not going to be installed
[22:15] <slangasek> aw, still not installable on precise either
[22:15] <broder> zenity is clearly bogus
[22:16] <slangasek> well, it needs to be marked M-A: foreign
[22:16] <broder> (i.e. should be m-a: foreign)
[22:16]  * slangasek nods
[22:16] <broder> pcsclite could be tricky because i believe it communicates with a separate daemon
[22:16] <slangasek> s/tricky/fun for broder/
[22:16] <broder> <3 you too, slangasek :-P
[22:16] <slangasek> :)
[22:18] <slangasek> well, there are only 17 packages left for ia32-libs, so we'll have to find *some*thing to keep you entertained in the new year
[22:23] <broder> well, it looks like the protocol is bittedness agnostic. not sure yet if it's endianness agnostic, though
[22:24] <broder> looks like it's almost certainly not
[22:25] <broder> is that considered a blocker for multiarch?
[22:29] <infinity> Ick, endian-specific protocols?  Fix, fix!
[22:29] <infinity> Didn't even dbus learn that lesson and fix its issues?
[22:30] <broder> well, more "moderately ad-hoc protocol consisting of shoving structs into sockets"
[22:30]  * infinity shivers.
[22:30] <infinity> That could end up being even arch-specific, let alone endian-specific.
[22:31] <broder> it's not arch-specific - the struct headers all use uint32_t et al.
[22:31] <infinity> Ahh.
[22:34] <broder> but the members of the struct are assigned to without any endianness conversion
[22:35] <RAOF> There's no guarantee that the stucture packing is consistent across archs, either, is there?
[22:36]  * RAOF discovers the --eatmydata option to mk-sbuild.  Joy!
[22:37] <broder> oh yeah, you might be right
[22:38] <RAOF> C structs as your IPC protocol: Just Say No :)
[22:39] <ajmitch> RAOF: let's use XML instead? :)
[22:39] <RAOF> Yes!
[22:39] <dobey> you could use JSON; where everything is a C struct defined by string literals :)