[01:04] <ScottK> RAOF: Which browser?
[01:05] <RAOF> ScottK: Chromium is what's set up, and if it's running then the URL goes to the right place.
[01:05] <ScottK> OK.  I was curious since I haven't seen that.  I may just not have been looking.
[02:04] <cjwatson> Sarvatt,RAOF: hm, so if mesa no longer provides the mesa-utils binary package, what are things like gnome-shell supposed to do which use glxinfo?  there are a couple of other reverse dependencies listed in http://people.canonical.com/~ubuntu-archive/NBS/mesa-utils
[02:04] <cjwatson> ogasawara: could we have an upload of linux-meta-mvl-dove to match the 410 ABI?
[02:04] <RAOF> cjwatson: Yeah, I just got reminded about that with bug #648401.
[02:05] <cjwatson> RAOF: ah, doko beat me to it - thanks
[02:05] <cjwatson> (I don't agree with his "option for maverick-updates", though - the archive needs to be consistent for release)
[02:06] <RAOF> mesa-demos got split out of the main mesa source tree and put into a separate repository.  I knew about this a couple of months ago, and just plain forgot when the 7.9 FFe came through :/
[02:07] <RAOF> I'm not sure whether re-munging the mesa-demos tarball into our mesa tarball is the way to go, or whether to go with the separate packaging I've got lying around.
[02:08] <cjwatson> I don't think it matters too much from the archive point of view (FWIW)
[02:09] <RAOF> It's probably easier from a review standpoint to re-munge the tarballs.
[02:09] <RAOF> That does seem a bit like cheating, though.
[02:10] <cjwatson> RAOF: sounds like a pain to compare either way actually
[02:10] <cjwatson> so go with what makes most sense to you
[02:11] <RAOF> Separate packging it is, then.
[02:31] <TheMuso> 8/c
[02:32] <RAOF> Good morning :)
[02:38] <TheMuso> Hey RAOF.
[02:39] <RAOF> Howdie TheMuso.  How's Sydney's springtime treating you?
[02:40] <TheMuso> RAOF: Not too bad, unseasonally warm unfortunately, but cooler weather is on its way, at least temporarily.
[02:41]  * RAOF wouldn't mind just a *little* bit of unseasonable warmth :)
[02:41] <RAOF> It's decided to be really really windy, instead.
[02:41] <TheMuso> heh
[02:42] <RAOF> I'm not yet sure what sounds from the roof to be alarmed at, either.
[07:27] <ogasawara> cjwatson: just uploaded linux-meta-mvl-dove <IP_ADDRESS>0.2
[07:33] <amitk> ogasawara: why are you up at this hour?
[07:33] <ogasawara> amitk: am actually just going to go to bed now.
[07:34] <amitk> ogasawara: good night, take care :)
[08:19] <pitti> Good morning
[08:22] <micahg> good morning pitti
[08:25] <micahg> pitti: would it be possible to accept gjs into lucid-proposed
[08:31] <\sh> pitti: stupid question who is responsible for the partner archive of C.?
[08:57] <pitti> micahg: I'll have a round of SRUs next
[08:57] <micahg> pitti: awesome thank you
[08:58] <pitti> micahg: Brian Thomason (iamfuzz)
[08:58] <micahg> pitti: ?
[08:58] <StevenK> pitti: \sh asked that :_)
[08:58] <pitti> oops, sorry ;)
[09:00] <ogra> RAOF, hey
[09:02] <\sh> pitti: thx :)
[09:03] <\sh> and btw...cdbs is broken, eventually doing some black magic to DEB_MAKE_INVOKE settting -C without setting $(DEB_BUILDDIR_$(cdbs_curpkg)) that's why libapache-mod-fastcgi is FTBSing in maverick...I wonder how to fix cdbs for that...
[09:05] <\sh> without declaring DEB_MAKE_INVOKE = $(MAKE) inside the package rules file, there is no other way to fix it...and I'm not a cdbs specialist...
[09:06] <\sh> I think makefile-vars.mk:DEB_MAKE_INVOKE = $(DEB_MAKE_ENVVARS) $(MAKE) $(if $(DEB_MAKE_MAKEFILE), -f $(DEB_MAKE_MAKEFILE),) -C $(DEB_BUILDDIR) $(DEB_MAKE_EXTRA_ARGS) is the bugger in makefile-vars.mk
[09:09] <\sh> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=596950 <- debian bug report
[09:16] <RAOF> ogra: Howdie.
[09:16] <ogra> RAOF, i have a weird X input problem with a weird setup i run here
[09:16] <RAOF> Good, good.  Do go on :)
[09:17] <ogra> i run an ubuntu chroot on top of an android kernel on unsupported HW and cant get keyboard input to work under X
[09:17] <RAOF> Iiiiiiinteresting.
[09:17] <ogra> (i cant tell if it would work in console though since the kernel has no framebuffer console builtin)
[09:18] <RAOF> Does the android kernel provide evdev devices?
[09:18] <ogra> i see garbage if i cat /dev/input/event0 and type on the keyboard
[09:18] <ogra> i'm not sure
[09:18] <RAOF> That looks quite likely to be an evdev device.
[09:18] <ogra> i also cant run udev on the system since i cant start upstart
[09:19] <RAOF> Ok.  Well, that will certainly freak X's input autodetection out.
[09:19] <ogra> so i have to live with xorg.conf for input devices ... for the touchpad that works fine
[09:19] <ogra> and i see the kbd being detected too in the log
[09:19] <ogra> but ...
[09:19] <ogra> there are queue overrun errors all the time
[09:20] <ogra> i was wondering if you have any idea if there is a achnce to make it work
[09:20] <ogra> *chance
[09:20] <RAOF> That would be queue overruns in dmesg?
[09:20] <ogra> (note thats only my private toy project, not work related or something ...)
[09:20] <ogra> no, in Xorg.0.log
[09:20] <RAOF> EQ overflows?
[09:21] <ogra> let me get the device (i dont have it near me ...) gimme 10min
[09:22] <RAOF> I'm not confident that I'll be particularly helpful, but sure :)
[09:28] <ogra> RAOF, [ 18128.824] Generic KBD: dropping event due to full queue!
[09:28] <ogra> thats the error i see
[09:28] <RAOF> Hm.  And you've set up your keyboard to be driven by evdev, or kbd?
[09:29] <ogra> evdev
[09:29] <ogra> since we dont have kbd in maverick
[09:29] <ogra> do we have a package of the old kbd driver anywhere =
[09:29] <ogra> ?
[09:29] <ogra> i'd happily recompile it for arm and try if that fixes it
[09:30] <RAOF> You could probably grab one from Debian; they still need it, because it's useful on !linux
[09:30] <ogra> ah
[09:31] <ogra> yes, it apparantly is :) (/me considers android to be !linux) :)
[09:31] <RAOF> I'm not _sure_ whether “ubuntu chroot on android kernel” is sufficiently not-linux to qualify :)
[09:32] <ogra> well, there runs a minimal android so ubuntu is effectively run as a chroot in a java VM :)
[09:32] <ogra> its more than the kernel
[09:32] <ogra> (as i said, really odd setup)
[09:32] <RAOF> Heh.
[09:40] <directhex> i'd say android is !linux if one defines linux as "os with linux kernel and gnu userland". chroots are getting into a grey area
[09:43] <ogra> directhex, well, the java vm runs partitally inside the kernel
[09:43] <directhex> dalvik is a monstrous creation
[09:43] <ogra> there is a lot of GNU userland still
[09:44] <ogra> like busybox :)
[09:44] <kklimonda> a lot?
[10:03] <pitti> RAOF: ugh, that mesa upload looks scary at this point
[10:07] <cjwatson> ogasawara: thanks
[10:11] <\sh> pitti: there are two more ftbfs fixes mgltools-{support,volume}, can you approve them?
[10:12] <pitti> \sh: currently looking at the queue, yes
[10:12] <\sh> pitti: thx :) I'll try to push more ftbfs fixes today...working down the list from lucas
[10:12] <pitti> \sh: many thanks!
[10:12] <pitti> so, I processed the queue, all except mesa
[10:13]  * pitti re-reads the diff again; there seems to be a lot of noise due to the renaming of a backend
[10:15] <pitti> RAOF: the solution for bug 633406 isn't clear yet according to the bug trail, and that mesa upload changes a lot of other things; has this verrsion been tested at a larger scale?
[10:15] <\sh> hmm..what happend to pkg sablotron in maverick?
[10:16] <pitti> smb: how do you feel about the current lucid-proposed kernel?
[10:16] <smb> pitti, Another day another try. What do you think of the current Lucid proposed? Beside the no-op ALSA updates that failed verification there are now some more successful verifications and it has been in proposed for more than three weeks now without people screaming. Beside it has some very nice to have IO performance enhancements.
[10:16] <smb> pitti, Hehe
[10:16] <smb> I was just thinking on that
[10:16] <pitti> smb: right, that was my impression, too
[10:17] <smb> pitti, Cool. Yeah, I think it should be good to move
[10:17] <pitti> smb: good, will do; thanks
[10:17] <smb> pitti, \o/ Thanks you :)
[10:17] <pitti> I'll reopen the failed bugs then
[10:17] <\sh> micahg: sablotron is deleted, regarding LP you requested this...(LP #636333)
[10:18] <\sh> micahg: what about caudium, which needs libsablot0*, should we remove it before release as well?
[10:18] <happyaron> pitti: ping
[10:18] <pitti> smb: hm, there's only the main kernell, no -ec2 and armel friends; what happened to them?
[10:18] <micahg> \sh: yes, oh..let's see
[10:18] <pitti> happyaron: pong
[10:19] <happyaron> pitti: excuse me, have you read my email about language packs in kubuntu/xbuntu live cd?
[10:19] <pitti> happyaron: I got it, yes; I didn't have time yet to respond
[10:19] <happyaron> pitti: thanks
[10:19] <smb> pitti, Pending in transfer. I am currently transferring stable things over to Steve and Brad and they got delayed for re-upload for various reasons
[10:20] <pitti> ok
[10:20] <micahg> \sh: yes, it's been removed from Debian
[10:20] <smb> pitti, We upload them soon and then could go over to updates as well
[10:20] <micahg> \sh: do you want me to file the bug?
[10:21] <\sh> micahg: yes please
[10:21] <micahg> \sh: k, thanks for catching that
[10:21] <\sh> micahg: np...just working down lucas ftbfs list
[10:21] <micahg> \sh: fabrice_sp already beat us to it
[10:22] <\sh> ah yes :)
[10:23] <lifeless> cjwatson: hi; https://bugs.edge.launchpad.net/ubuntu/+source/grub2/+bug/648638 may be of interest (or may not)
[10:26] <smb> cjwatson, Hi Colin, it seems sconklin has only be given upload rights for the Maverick package set but would need the same for Dapper, Hardy, Jaunty, Karmic and Lucid
[10:27] <pitti> jibel: do you know if anyone tested fglrx on jaunty? I didn't see feedback there
[10:27] <pitti> jibel: I'm inclined to just push it, since it's rather urgent, and the same patch worked everywhere else
[10:28] <jibel> pitti, no. I can give it a try.
[10:28] <lifeless> anyone else with an x201s had a jumpy cursor, edge scrolling not working, that sort of thing?
[10:28] <pitti> not on my x201 (non-s)
[10:29] <pitti> lifeless: sounds like the touchpad is picked up by the wrong x input driver?
[10:29] <lifeless> I'd assume so
[10:29] <pitti> there has been some bugs in the utouchification
[10:29] <pitti> lifeless: is that with the touchpad?
[10:29] <pitti> I'm usually running this machine docked (with usb mouse)
[10:29] <lifeless> I'm half way through an ubuntu-bug ginput-device-settings report for this
[10:29] <lifeless> pitti: yeah trackpad
[10:29] <lifeless> pitti: the nipple is fine
[10:30] <lifeless> s/trackpad/touchpad/
[10:31] <pitti> lifeless: nope, touchpad works fine here
[10:31] <lifeless> pitti: its finding it as SynPS/2 Synaptics TouchPad
[10:31] <lifeless> which sounds right
[10:31] <pitti> *nod*
[10:31] <pitti> [    16.085] (II) config/udev: Adding input device SynPS/2 Synaptics TouchPad (/dev/input/event10)
[10:31] <pitti> [    16.085] (**) SynPS/2 Synaptics TouchPad: Applying InputClass "evdev touchpad catchall"
[10:32] <pitti> [    16.085] (**) SynPS/2 Synaptics TouchPad: Applying InputClass "touchpad catchall"
[10:32]  * pitti redirects you to RAOF then
[10:32] <lifeless> thanks
[10:32] <lifeless> hah, details...
[10:32] <lifeless> (II) config/udev: Adding input device SynPS/2 Synaptics TouchPad (/dev/input/mouse0)
[10:32] <lifeless> (**) SynPS/2 Synaptics TouchPad: always reports core events
[10:32] <lifeless> (**) SynPS/2 Synaptics TouchPad: Device: "/dev/input/mouse0"
[10:32] <lifeless> (EE) ioctl EVIOCGNAME failed: Inappropriate ioctl for device
[10:32] <lifeless> (II) UnloadModule: "evdev"
[10:32] <lifeless> (EE) PreInit returned NULL for "SynPS/2 Synaptics TouchPad"
[10:33] <pitti> lifeless: oh, interesting
[10:33] <pitti> [    16.583] (II) config/udev: Adding input device SynPS/2 Synaptics TouchPad (/dev/input/mouse1)
[10:33] <pitti> [    16.583] (II) No input driver/identifier specified (ignoring)
[10:33] <pitti> lifeless: so on mine it tries to pick up both, but mouse1 is blacklisted somewhre
[10:34] <pitti> lifeless: do you have a synaptics stanza for the corresponding evdev device, too?
[10:34] <lifeless> mouse1 in the nipple for me; I have no input devices in xorg.conf
[10:35] <cjwatson> lifeless: your boot loader is incorrectly installed
[10:35] <cjwatson> lifeless: (I haven't looked at the bug yet but that's what that error basically means.  see my blog for details)
[10:36] <lifeless> cjwatson: I'll look at your blog; the concerning thing for me was that following the advice resulted in both no-error and no-boot.
[10:36] <cjwatson> lifeless: as far as I can see you read the help text precisely backwards
[10:36] <cjwatson>  Note: It is possible to install GRUB to partition boot records as well, and
[10:36] <cjwatson>  some appropriate partitions are offered here.  However, this forces GRUB to
[10:36] <cjwatson>  use the blocklist mechanism, which makes it less reliable, and therefore is
[10:36] <cjwatson>  not recommended.
[10:36] <pitti> smb: oh argh, l-b-m is still in the unapproved queue, with the fix to make the gobi_loader rules ABI specific
[10:36] <cjwatson> and yet you interpreted this as saying that installing to sda was a bad idea?
[10:37] <pitti> smb: would you mind reuploading this with just the top changelog, and we'll try to push that to -updates fast?
[10:37] <cjwatson> what it actually says is that installing to sda1 may be a bad idea ...
[10:37] <lifeless> cjwatson: *blink*
[10:38] <lifeless> cjwatson: Perhaps it would be clearer to provide the good-idea bad-idea hint in the list - either as two lists [recommended] and [not recommended], or as a marker in the list ?
[10:38] <smb> pitti, I could, but compared to what is in updates for that package all the changes in the log are in. So why only the last one?
[10:38] <cjwatson> can't provide two lists, debconf doesn't support it
[10:38] <lifeless> cjwatson: (yes, clearly I did read it backwards, for which I have no excuse)
[10:38] <cjwatson> I'll transform your bug into a recommendation to put a marker in the list
[10:39] <pitti> smb: http://launchpadlibrarian.net/56311364/linux-backports-modules-2.6.32_2.6.32-25.24_source.changes -> 25.23 is in -updates now
[10:39] <pitti> smb: so now it's just -25.24 which is new
[10:39] <smb> pitti, Ah ok, got it
[10:39] <pitti> smb: (rejected the current upload)
[10:39] <smb> pitti, Ok, will do a quick repackaging. Just a second
[10:39] <pitti> smb: sorry, we probably should have accepted and tested this one first, and then moved to -updates
[10:40] <pitti> but as long as we don't get a new ABI, it should be fine
[10:40] <pitti> oh, and the new ABI will have the custom path anyway
[10:40] <cjwatson> lifeless: interesting that you saw the dialog at all; I suspect you previously had removable devices plugged in and perhaps had asked for grub to be installed to one of them (maybe without noticing)?
[10:41] <smb> pitti, Probably would have been more convenient for the gobi_loader users. But the update from that won't clash and the abi doesn't change as well. So maybe its not that bad after all
[10:41] <lifeless> cjwatson: I don't think so; this is my x201s (last machine to be upgraded)
[10:41] <cjwatson> lifeless: do you need repair assistance?
[10:41] <lifeless> cjwatson: it was a fresh install 6 months ago
[10:41] <smb> pitti, Just the current update may require people to remove the old package...
[10:42] <pitti> smb: right, it shouldn't cause problems, but I'd still like to have this change in, just in case
[10:42] <lifeless> cjwatson: no, I'm good now; live-cd;chroot;reconfigure grub-pc and select both options on the theory that it was probably user error of some sort.
[10:42] <lifeless> pitti: appears that update-manager didn't update the evdev package correctly.
[10:43] <cjwatson> lifeless: you can/should just select sda
[10:43] <cjwatson> (selecting sda1 as well is technically harmless but may cause confusion later)
[10:43] <lifeless> ok, I'll reconfigure again next time I'm about to reboot
[10:44] <cjwatson> the partition options are there for the minority (but not negligible minority) who have some other custom boot loader in the MBR
[10:44] <lifeless> cjwatson: yeah, I can certainly understand the need and tradeoffs
[10:44] <lifeless> I did a good job of foot-shooting
[10:45] <directhex> cjwatson: tri-booting my imac also needed a partition install of grub
[10:46] <cjwatson> right, weird hardware another reason :)
[10:47] <smb> pitti, lucid-lbm re-uploaded (will probably take one or two more minutes to show up in lp)
[10:48] <pitti> smb: cheers
[10:48] <\sh> hmmm...I'm stucked ...
[10:48] <\sh> libmed-dev : Depends: libmed1 (= 2.3.6-2) but it is not going to be installed
[10:48] <\sh>  libmedc-dev : Depends: libmedc1 (= 2.3.6-2) but it is not going to be installed
[10:48] <\sh> but apt-get install those files on a standard maverick, works as expected, only sbuild chroots means "no this doesn't work"
[10:49] <lifeless> pitti: appears the xorg stack is mid transition or something; xserver-xorg-input-7 conflits with xserver-xorg-core ><
[10:51] <\sh> oh wow...ecs is broken
[10:57] <jibel> tkamppeter, mvo, another package blocking the upgrade because of the change to foomatic-db-compressed-ppds: bug 647460
[10:59] <mvo> jibel: thanks
[11:07] <cjwatson> smb: sconklin> fixed
[11:08] <pitti> cjwatson: I want to do some no-change rebuilds for NBS cleanup; do you prefer to review them, or can I just accept them myself?
[11:11] <cjwatson> no-change rebuilds should be fine as long as they aren't packages with giant buildd times
[11:11] <cjwatson> (I meant to type "build" but that's good enough ...)
[11:11] <cjwatson> pitti: which packages?
[11:12] <pitti> cjwatson: I didn't start yet
[11:12] <cjwatson> note that libopensync-plugin-gnokii needs a non-trivial source change
[11:12] <cjwatson> I'm not sure if anyone is looking at the opensync cluster
[11:15] <lifeless> I ran screaming
[11:15] <cjwatson> it wasn't obvious to me that there were huge numbers of no-change uploads available from NBS any more (doko has been cleaning a lot of stuff up), but absolutely go ahead if you find some
[11:15] <cjwatson> my suspicion is that most of the rest require source work
[11:15] <lifeless> I think my name is still on part of it simply because it hasn't been uploaded outside of experimental, or some such.
[11:15] <pitti> I'll see how far I'll get
[11:15] <lifeless> night all
[11:16] <pitti> cjwatson: but I guess stuff like libavutil49, libindicator0, libvala0 should be triviall
[11:16] <pitti> I'll just start from the top
[11:16] <cjwatson> libvala0 is just libvala-dev and those are all build-deps
[11:16] <cjwatson> libindicator0 is just ubiquity which is already in progress
[11:16] <cjwatson> libavutil49 not sure, it's different between architectures so will require some analysis
[11:17] <pitti> libvala-dev is NBS itself; I'll check the rdepends for having alternatives to libvala-0.10-dev
[11:18] <cjwatson> right
[11:18] <cjwatson> pitti: BTW, I rewrote checkrdepends over the weekend - it has a slightly different argument syntax now
[11:18] <pitti> I noticed
[11:18] <cjwatson> though that wasn't the point, the point was to get cron.NBS runtime down to a minute
[11:19] <pitti> it's using launchpadlib now?
[11:19] <cjwatson> no
[11:19] <hemanth> ImportError: No module named nautilus, even after installing python-nautilus, any suggestions?
[11:19] <pitti> perhaps we should add this to ubuntu-archive-tools bzr
[11:19] <cjwatson> it's still analysing Packages/Sources directly, but it's a lot faster to do that inline in python rather than repeatedly calling grep-dctrl
[11:20] <cjwatson> sure, if you like, though we don't have that checked out anywhere on cocoplum right now
[11:20] <pitti> nice
[11:20] <cjwatson> faster> well, at least if you're asking about large numbers of packages at once
[11:21] <cjwatson> also, I just made it look at main/installer-*/current/images/udeb.list, so it can now spot when d-i is still using a given kernel ABI and create an artificial dependency
[11:21] <cjwatson> which should save us from future accidents
[11:22] <pitti> ah, right, we use /srv/archive-scripts/bin bzr right now
[11:23] <pitti> hm, it would be easier if libvala0.10-dev would Provides: libvala-dev..
[11:23] <pitti> didrocks: ^ WDYT?
[11:24] <didrocks> pitti: I think it's safe to do that, right
[11:24] <didrocks> I don't see any reason that people want to build with previous buggy vala version
[11:24] <pitti> didrocks: I mean it's easier than adding alternative build-deps to http://people.canonical.com/~ubuntu-archive/NBS/libvala-dev
[11:25] <didrocks> pitti: yeah, I agree, do you want to do the change? I'll report it to debian then.
[11:26] <pitti> didrocks: would be nice; thanks!
[11:26] <didrocks> pitti: thank to you :)
[11:26] <pitti> didrocks: actually, no
[11:26] <pitti> didrocks: Debian didn't rename them that way
[11:26] <pitti> they just use unversioned packages
[11:27] <pitti> I'm not quite sure why we went through the hassle of versioning them
[11:27] <cjwatson> could somebody look at bug 648469 and check what the right fix is?  then we can remove python-gnome2-desktop and python-gnomeprint
[11:27] <pitti> I'll just add the provides:, and NBS libvala{0,-dev}
[11:28] <pitti> cjwatson: for powerpc specific FTBFSes which block NBS removal, I guess we'll just remove them anyway and say "*shrug*"?
[11:28] <cjwatson> if they're leaf packages we can do that
[11:28] <didrocks> pitti: debian did it in 0.9.5-1 IIRC
[11:29] <cjwatson> is dpm on holiday or something?
[11:29] <pitti> didrocks: no, see http://packages.qa.debian.org/v/vala.html
[11:29] <cjwatson> pitti: one thing only you can do, since dpm doesn't seem to be around; there are several uninstallable language packs
[11:30] <pitti> cjwatson: will look at those
[11:31] <cjwatson> thanks
[11:31] <pitti> vala uploaded with the new provides:; it's not a no-change upload, so I'll let someone else review it
[11:31] <pitti> didrocks: ^
[11:32] <didrocks> pitti: I think I don't understand :) I didn't do the merge (was in vacation) but it seems nevertheless, they have a libvala-0.10-dev package shown in http://packages.debian.org/source/experimental/vala or is there something I'm missing?
[11:33] <pitti> didrocks: ah, in experimental only; I see
[11:33] <pitti> didrocks: ok, thanks for forwarding
[11:33]  * didrocks is not crazy (yet!) :p
[11:36] <pitti> cjwatson: did dpm happen to talk to you about the final maverick langpack set?
[11:36] <\sh> pitti: could you approve ecs pls, thx :)
[11:37] <cjwatson> pitti: no
[11:37] <cjwatson> (I don't think so)
[11:38] <pitti> cjwatson: ok, thanks; we'll need a fresh -base rebuild and thus a full export
[11:38] <pitti> it's too late to squeeze it into the RC for Thursday, but I'll request one now and build them locally, so that we can upload them right after RC
[11:38] <pitti> cjwatson: ^ sounds okay to you?
[11:39] <pitti> current langpacks cause an extra 7 MB on the alternates, and make them overflow, but we can just drop a langpack there for the RC
[11:40] <cjwatson> OK for after RC, yes
[11:40] <Riddell> pitti: the LanguagePackTranslationDeadline is Sep 30th
[11:40] <cjwatson> what about the current uninstallables?  do those need that fresh rebuild?
[11:40] <pitti> that, too
[11:40] <cjwatson> they're causing some livefs build failures
[11:41] <cjwatson> so we'll need to work around that
[11:41] <pitti> the -kde variant for those is newer than the main one
[11:41] <cjwatson> at least edubuntu-dvd
[11:41] <pitti> we could drop the strict dependency from -kde-base to -base
[11:41] <pitti> in fact, I think I can make this change in the langpack-o-matic templaltes
[11:41] <pitti> but that will only get effective at the next upload, of course
[11:43] <cjwatson> or we could exclude those language packs from the build
[11:43] <cjwatson> I think that's preferable for RC
[11:43] <pitti> for RC, yes
[11:43] <pitti> and after that it'll fix itself
[11:43] <cjwatson> right, we won't need the langpack-o-matic hack
[11:45] <cjwatson> \sh: accepted
[11:46] <pitti> didrocks: so you'll do the yelp update for bug 605577? I'll manually fix the -gnome-en langpack now, then
[11:47] <didrocks> pitti: oh, as you wish. I've assigned to me before you told you wanted to handle it, but if you want to do both, please do :)
[11:47] <pitti> didrocks: ok, I'll have a look
[11:48] <didrocks> pitti: thanks :)
[11:48] <\sh> cjwatson: thx
[12:02] <pitti> seb128: why do we carry a manual patch 07_rosetta_translations_update.patch in yelp?
[12:05] <pitti> seb128: especially because this patch isn't in the series?
[12:09] <didrocks> pitti: the patch isn't in the series during unstable update IIRC to avoid having to refresh it at each new ustream version. It should be added back in final upload
[12:09] <didrocks> (just using my memory, not 100% sure about it but that should be that :))
[12:09] <pitti> didrocks: ok; I fixed the patch, but I won't upload it right now, since it's not currently cuasing trouble
[12:10] <pitti> bug updated as well; so we just need to accept the new -gnome-en-base, and everything is well again
[12:21] <cjwatson> pitti: accepted
[12:21] <pitti> cheers
[12:23] <jibel> latest python-virtkey is broken in maverick. bug 648695
[12:27] <seb128> pitti, sorry I was at lunch
[12:27] <seb128> pitti, what didrocks say on the serie
[12:27] <pitti> seb128: ok, thank you
[12:27] <seb128> pitti, we carry the patch because translated xml are generated on build
[12:27] <seb128> so they don't work with langpacks
[12:27] <pitti> ah, I see
[12:34] <RAOF> pitti: Re: mesa - it's been tested by me, Sarvatt, ScottK, and mvo thus far, and is now actually from the 7.9 release branch.
[12:44] <doko> RAOF: btw, what is the replacement for the dropped mesa-utils?
[12:45] <RAOF> doko: The split-out mesa-demos on revu http://revu.ubuntuwire.com/p/mesa-demos
[12:46] <RAOF> Upstream dropped the code we shipped in mesa-utils from the main mesa tree between 7.8 & 7.9
[12:47] <RAOF> mesa-demos is exactly that code, now released as a separate project.
[12:47] <doko> RAOF: somebody reviewing this currently?
[12:48] <RAOF> No.
[12:48] <doko> ok, looking at it
[12:49] <RAOF> Thanks.
[12:51] <\sh> doko: could you push sun-java6 6.21dlj to c. partner repo? you could use the package from https://edge.launchpad.net/~sun-java-community-team/+archive/sun-java6
[12:51] <\sh> for maverick that is...dunno if someone else can do this
[12:51] <doko> \sh: I'll have a look
[12:51] <\sh> doko: thx a lot :)
[12:58] <doko> RAOF: is the complete 11MB source really needed?
[12:59] <RAOF> doko: I could repack the tarball and strip everything we don't ship out, for Maverick.
[13:00] <RAOF> For Natty I want to ship *all* the demos in a separate package, as they're useful for users to pinpoint problems in mesa.
[13:01] <doko> ok, then it makes sense
[13:06] <doko> RAOF: uploaded, waiting in NEW
[13:06] <RAOF> doko: Awesome, thanks.
[13:07] <doko> RAOF: needed for http://people.canonical.com/~ubuntu-archive/NBS/mesa-utils (openened a bug for mesa, although bryce2 did tag it as ppc, don't know why)
[13:08] <RAOF> That'd be an arsenal script, probably grabbing from the powerpc in the text of the bug.
[13:09] <RAOF> I closed that mesa bug in the changelog, right?
[13:09] <RAOF> Yes, there it is.  Good :).
[13:29] <RAOF> I'm off to bed now.  If you want to discuss mesa with someone pitti I'll point you at Sarvatt for the next 10 hours or so :).
[13:30] <pitti> RAOF: ok, thanks
[13:48] <jibel> pitti, fglrx-installer verified in jaunty too.
[13:48] <pitti> jibel: nice, thanks
[13:48]  * pitti moves to -updats
[14:00] <\sh> hmm...can someone translate this buildlog for me? It says, FTBFS but everything is ok it seams
[14:00] <\sh> seems even: http://launchpadlibrarian.net/56574998/buildlog_ubuntu-maverick-amd64.emerald_0.7.2-0ubuntu5_FAILEDTOBUILD.txt.gz
[14:01] <wgrant> \sh: Look at the end of the log.
[14:01] <wgrant> The implicit pointer conversion thing.
[14:02] <\sh> wgrant: yeah I saw it, but the reason seems to be a bit misleading..the package builds perfectly, eventually LP needs to be trained to give another reason for arch problems
[14:03] <cjwatson> \sh: it's a recognised hack
[14:04] <\sh> cjwatson: I mean the subject of the mail , that was irritating me :)
[14:05] <cjwatson> sure, like I say, it's not a particularly clean hack and everyone involved in creating it knew this :-)
[14:07] <corecode> hey
[14:08] <corecode> the last gnome-terminal update on lucid changes some useful defaults
[14:14] <jibel> pitti, I've added a bugpattern for the current virtkey issue but it's not pushed to http://people.canonical.com/~pitti/bugpatterns/ . Are commits to the lp branch still rolled out every 15mn ?
[14:19] <pitti> jibel: they should, yes
[14:19] <pitti> */15 * * * * env LC_ALL=C bzr pull -q -d ~/public_html/bugpatterns >/dev/null
[14:19] <pitti> should have happened 4 mins ago, let me check
[14:19] <pitti> jibel: it's at r147 for bug 642518
[14:20] <pitti> jibel: a manual pull doesn't bring anything new; did you push?
[14:31] <jibel> pitti, yes I've pushed it, but can't find it anywhere and I'm still at r147 :/ probably another pebkac, retrying. sorry
[15:21] <pitti> jibel: worked now
[15:23] <jibel> pitti, yes, thank you. I really don't know where my previous push is gone.
[15:24] <tkamppeter> pitti, hi
[15:24] <pitti> jibel: to the place whe all the lost socks and pens go?
[15:24] <pitti> hey tkamppeter
[15:24] <jibel> pitti, very likely :)
[15:26] <tkamppeter> pitti, last week I got a patch from Japan for the pdftopdf filter so that it builds with Poppler 0.15.x without loosing compatibility with older Poppler versions. I have applied it only to the upstream CUPS add-on package but not (yet) to the BZR at Debian.
[15:27] <tkamppeter> pitti, now I want to ask whether I can already apply it to the BZR (withoutbeing packaged for Maverick) or whether I should wait for Maverick being released.
[15:27] <pitti> tkamppeter: is that important for maverick? we already have the new poppler, after all?
[15:27] <pitti> tkamppeter: oh, please push it; it's the Debian unstable development tree, after all
[15:27] <pitti> tkamppeter: if we need another maverick change, we'll branch it
[15:34] <tkamppeter> pitti, thanks, I wll push it.
[15:44] <tkamppeter> pitti, done.
[16:14] <pitti> Riddell: does the dbus you just uploaded differ in any way to the one from 2 hours ago?
[16:16] <tkamppeter> pitti, can you have a look at bug 647369? It is probably a problem caused by the upstartification of CUPS?
[16:17] <pitti> tkamppeter: very unlikely -- it seems it can't find /usr/bin/lpstat, but I wouldn't know why
[16:17] <pitti> it's in cups-client, which is installed
[16:17] <\sh> ttx: will you give libspring-2.5-java a new punch to actually build on maverick? ;)
[16:18] <tkamppeter> pitti, the "lpstat: no such file or directory" is caused by lpstat being called to quickly after CUPS being started. In that moment CUPS has not yet created the socket file /var/run/cups/cups.sock
[16:18] <pitti> ah
[16:18] <tkamppeter> pitti, if lpstat is not found, one would get "Command not found".
[16:18] <ttx> \sh: *sigh*
[16:19] <tkamppeter> pitti, simply try "sudo stop cups; sudo start cups; ls -l /var/run/cups/cups.sock"
[16:19] <\sh> ttx: there are some packages which are in need of it ;)
[16:19] <pitti> right, that'd start in the background
[16:20] <Riddell> pitti: fixed .symbols file
[16:20] <pitti> Riddell: ah, so I'll reject the previous upload
[16:20] <pitti> Riddell: (done)
[16:20] <tkamppeter> pitti, formerly, the "invoke-rc.d cups force-reload" exited only after CUPS was ready and so the next line in the script could already use CUPS.
[16:21]  * ttx punches
[16:22] <\sh> ttx: rocking :)
[16:22] <tkamppeter> pitti, so the backward compatibility commands, like "invoke-rc.d", "service", "/etc/initd.*" should wait for the service getting ready before exiting.
[16:22] <pitti> yes, indeed
[16:23] <tkamppeter> pitti, should I move the bug to upstart and target it for Maverick?
[16:23] <pitti> so this would require a rather ugly while status cups | grep -q start/running loop
[16:23] <tkamppeter> pitti, in the gutenprint postinst script works adding
[16:23] <tkamppeter>  for i in 1 2 3 4 5; do if [ -r /var/run/cups/cups.sock ]; then break; fi; sleep 1; echo -n "."; done; echo;
[16:24] <pitti> ah, I see; but 5 seconds wasn't enough there?
[16:24] <tkamppeter> but this fixes only the reported problem with Gutenprint, there are probably many more.
[16:24] <pitti> Keybuk: ^ would it be realistic to have invoke-rc.d (on an upstart job) wait until the servie is "start/running"?
[16:25] <tkamppeter> pitti, the loop breaks as soon as the file appears, for me always after one second, but there can be slower systems.
[16:25] <pitti> that might break tasks, though?
[16:25] <Keybuk> pitti: a better question would be to ask why invoke-rc.d doesn't wait for that right now
[16:26] <tkamppeter> pitti, "start/running" is perhaps not even enough, as I get
[16:26] <tkamppeter> till@till:~/ubuntu/gutenprint$ sudo stop cups; sudo start cups; ll /var/run/cups/cups.sock
[16:26] <tkamppeter> cups stop/waiting
[16:26] <tkamppeter> cups start/running, process 23356
[16:26] <tkamppeter> ls: cannot access /var/run/cups/cups.sock: No such file or directory
[16:26] <tkamppeter> till@till:~/ubuntu/gutenprint$
[16:26] <tkamppeter> pitti, so a start/running is reported but the file is still not there.
[16:26] <pitti> tkamppeter: hm, but that's something that the original init script didn't do either
[16:27] <Keybuk> pitti: blocking is the default behaviour for "start"
[16:27] <Keybuk> to *avoid* start blocking until its start/running, you'd need --no-wait
[16:28] <pitti> Keybuk: ah, thanks; so it's probably unrelated (see above, we need to wait on the socket to appear)
[16:28] <Keybuk> right
[16:28] <Keybuk> you can use a post-start script for that
[16:28] <Keybuk> e.g.
[16:28] <Keybuk> post-start script
[16:28] <Keybuk>    while [ ! -e /var/run/cups/cups.sock ]
[16:28] <pitti> cups has one already for the coldplugging
[16:28] <Keybuk>   do
[16:28] <Keybuk>     :
[16:28] <Keybuk>   done
[16:28] <Keybuk> end script
[16:28] <Keybuk> right
[16:29] <pitti> (perhaps a sleep .5)
[16:29] <Keybuk> well, yes, a sleep in there would be less "my cpu! mine!"
[16:29] <pitti> Keybuk: and actually giving the CPU to cupsd to start :)
[16:29] <tkamppeter> pitti, with
[16:29] <tkamppeter> sudo killall cupsd; sudo /usr/sbin/cupsd; ll /var/run/cups/cups.sock
[16:30] <pitti> tkamppeter: this indeed seems conceptually unrelated to the upstartification, but the different timing behaviour might have made it more probable
[16:30] <pitti> tkamppeter: so, I'm fine with cups' upstart script waiting until the daemon is ready
[16:30] <tkamppeter> one never gets "no such file or directory". And this is what the old init script did.
[16:30] <pitti> ah, right; previously we had cupsd take care of the forking
[16:31] <pitti> now we call it with -f and have upstart do the fork
[16:31] <cjwatson> \sh,ttx: libspring-2.5-java needs a manual build; we have a sysadmin ticket open for it and they will do it this week
[16:31] <tkamppeter> "cupsd -f" should only be used for debugging not for regular use.
[16:32] <ttx> cjwatson: arh, ok
[16:32] <ttx> cjwatson: looked like a transient error
[16:32] <pitti> tkamppeter: hang on
[16:39] <Riddell> sladen: how's that font package doing?
[16:43] <pitti> tkamppeter: pushed to r906
[16:43] <pitti> tkamppeter: I'll create a maverick branch (which we will also use for SRUs) and cherrypick it there
[16:45] <pitti> tkamppeter: lp:~ubuntu-printing/cups/maverick
[16:46] <sladen> Riddell: sabdfl is working on licencing at the moment, or was until robbiew filed a higher-priority interupt
[16:46] <tkamppeter> pitti, thanks.
[16:47] <sladen> Riddell: so whenever that's finalised plus some number of hours to implement
[16:50] <Riddell> sladen: are you doing the implementing?
[16:50] <pitti> tkamppeter: uploaded; needs someone else to review now
[16:54] <tkamppeter> pitti,
[16:54] <tkamppeter> sudo stop cups; sudo start cups; ll /var/run/cups/cups.sock
[16:54] <tkamppeter> works for me now, but
[16:54] <pitti> tkamppeter: I ran that in a loop for about 10 minutes
[16:55] <tkamppeter> sudo /var/lib/dpkg/info/cups-driver-gutenprint.postinst  configure
[16:55] <tkamppeter> still does not work.
[16:57] <pitti> tkamppeter: I just get a complaint about invoke-rc.d being out of date, and
[16:57] <pitti> lpstat: No destinations added.
[16:57] <pitti> tkamppeter: what do you see?
[16:57] <tkamppeter> pitti, I get the originally reported
[16:58] <tkamppeter> lpstat: No such file or directory
[16:58] <pitti> # while true; do stop cups; sleep 0.5; start cups; lpstat -p; done
[16:58] <pitti> that's what I'm running
[16:59]  * pitti refines to # while true; do stop cups; start cups; lpstat -p 2>&1|grep -q "No destinations" || exit 1; done
[16:59] <pitti> tkamppeter: you are using my updated upstart script now?
[17:00] <tkamppeter> pitti, can it be that this post-install script does a "reload" of CUPS instead of stopping and starting it?
[17:00] <tkamppeter> pitti, in which way does upstart this "reload" of CUPS?
[17:00] <pitti> perhaps; I'm not sure what reload does, hang on
[17:00] <pitti> so, above loop works fine for me
[17:01] <cjwatson> 'man reload' tells you what upstart's reload does
[17:02] <sladen> Riddell: yes
[17:02] <pitti> tkamppeter: ah, right, it SIGHUPs the daemon
[17:02] <Riddell> sladen: ok let me know when you're starting that.  and robbiew stop distracting Mark :)
[17:02] <tkamppeter> pitti, try it with "reload cups" instead of "stop cups; sleep 0.5; start cups;".
[17:02] <pitti> tkamppeter: right, I can reproduce it there
[17:03] <tkamppeter> pitti, the "reload" does not stop and start CUPS it simply HUPs at it.
[17:03] <pitti> tkamppeter: but that's what the init.d script did as well
[17:03] <pitti> tkamppeter: so in this regard the upstartification should make no differernce
[17:05] <pitti> Riddell: erm, upgrading dbus from 1.2 to 1.4 at this time? this is an awfully big diff for a such a critical service
[17:05] <Riddell> pitti: yes, I realise it's a long shot
[17:05] <Riddell> but it does stop random crashes happening in threaded apps which use dbus
[17:05] <tkamppeter> pitti, so you have fixed an independent problem which also had to get fixed and I should add a wait loop to the postinstall script of Gutenprint?
[17:05] <pitti> can't we backport the race condition fix?
[17:06] <pitti> tkamppeter: yes, I think so; can you please add back a gutenprint task then?
[17:06] <Riddell> pitti: I'm told we can't, the patch isn't reliable in the 1.2 version
[17:08] <pitti> I remember that we discussed that earlier on around beta time, and back then we thought it was too intrusive
[17:09] <Riddell> pitti: well at least I can tell upstream I tried :)
[17:09] <pitti> bjf: you uploaded linux-mvl-dove to maverick-proposed instead of final, was that intended?
[17:10] <bjf> pitti, no
[17:10] <pitti> bjf: ok, I guess I should reject it then, and you'll reupload to maverick?
[17:10] <bjf> pitti, yes, please reject it
[17:23] <tkamppeter> pitti, new gutenprint package uploaded.
[17:23] <pitti> tkamppeter: thanks, will review in a bit
[17:35] <smb> pitti, That upload of mvl-dove should have been made by Tim. But please reject the fsl-imx51 in Karmic
[17:36] <pitti> smb: done
[17:36] <smb> thanks
[17:50] <sladen> Riddell: realistically, tomorrow at the earliest
[17:51] <Riddell> sladen: we'll be frozen for RC by then
[17:52] <Riddell> it'll need to wait until Thursday
[17:52] <maco> cjwatson: these quality status emails keep making me go "must buy cjwatson a $beverage"
[17:59]  * cjwatson wonders how he's managing that; perhaps sync processing
[19:24] <bdrung_> doko_: why did you close bug #640732?
[19:26] <doko_> bdrung_: glibc patch not accepted upstream?
[19:29] <bdrung_> doko_: according to audacious upstream it's fixed in gcc-4.5, but not in gcc-4.4
[19:31] <doko_> bdrung_: and why do thy send a pointer to a glibc patch? and what needed fixing in gcc?
[19:33] <bdrung_> doko_: quote: "This is a duplicate of AUDPLUG-241. It was ruled to be a bug in the STL shipped by GCC 4.4, which has been fixed by GCC 4.5."
[19:34] <doko> bdrung_: sorry, do *you* understand the reasons for "It was ruled to be a bug" ?
[19:35] <dapal> doko: (OT: care to reply to DBTS #573745 ?)
[19:36] <bdrung_> doko: i don't understand the bug.
[19:36] <bdrung_> doko: let's make the test if it works with gcc-4.5
[20:01] <didrocks> urgh, seems amd64 builders have some issues, known?
[20:01] <bdrung_> doko: it works if i am using CXX=g++-4.5, but it fails if g++-4.4 is used
[20:16] <didrocks> seems there are really an issue, second fail: https://launchpad.net/ubuntu/+source/unity-place-files/0.5.30-0ubuntu1/+build/1977028/+files/buildlog_ubuntu-maverick-amd64.unity-place-files_0.5.30-0ubuntu1_FAILEDTOBUILD.txt.gz
[20:18] <seb128> didrocks, those are an arch all,any mistmatch issue
[20:18] <seb128> libunity-dev : Depends: libunity0 (= 0.2.44-0ubuntu1)
[20:18] <seb128> didrocks, it seems you just need to have unity published on amd64 and retry
[20:19] <didrocks> seb128: urgh, I stopped too early, just stucked at sh: gcc: not found
[20:19] <didrocks> sorry, yeah
[20:20] <didrocks> well, new unity release upladed soon…
[20:21] <doko> chrisccoulson_: please use dh_python2 for future python packaging (instead of python-central)
[20:21] <dapal> doko: re-ping?
[20:24] <doko> dapal: ?
[20:25] <dapal> [20:35:47] <dapal> doko: (OT: care to reply to DBTS #573745 ?)
[20:26] <doko> how does the affect ubuntu?
[20:26] <dapal> doko: I prefixed that with OT, and I see you're active here, and never replied to any mail directly sent to you
[20:27] <dapal> doko: so I just caught the chance to ping you here. I could've also done that privately.
[20:28] <doko> not today, sorry
[20:28] <dapal> doko: can I have an ETA?
[20:31] <dapal> doko: also, that bug is open since March, I would expect much more consideration from a fellow DD
[21:05] <lifeless> is there a blessed way to check if a process is running ?
[21:06] <ogra_ac> pgrep ?
[21:11] <lifeless> mmm, api wise I meant - its in python
[21:12] <ogra_ac> oh, k
[21:12] <ogra_ac> :)
[21:26] <soren> lifeless: os.kill(pid, 0)
[21:26] <soren> lifeless: I suppose.
[21:26] <soren> lifeless: Whether it's the process you're expecting it to be... That's a different story.
[21:27] <lifeless> yeah
[21:27] <soren> lifeless: ..but kill(2) with a signal 0 checks if there's such a process.
[21:27] <lifeless> there is some dodgy code in lp's test runner
[21:27] <lifeless> to delete it entirely is the long term goal, but its going to be an iterative thing; gotta get it into a nicer layout, then build on that to get better isolation, then the old cruft can go
[21:27] <soren> lifeless: If you start the process yourself, you can keep track of its cmdline and check /proc/blah/cmdline (assuming the process doesn't alter that).
[21:33] <ebroder> If it's a child process you could wait4() on it with WNOHANG
[21:34] <lifeless> it wouldn't be, but thanks
[23:28] <mar> my ubuntu clock freezed at 00:01. What do I do? :)
[23:29] <ogra_ac> wind it up
[23:30] <mar> in ubuntu even clock doesn't work right :/
[23:42] <sladen> mar: please take a screenshot
[23:43] <sladen> mar: please file it at  http://launchpad.net/ubuntu/+source/gnome-panel/+filebug
[23:43] <sladen> mar: including information about your timezone
[23:45] <micahg> mar: actually, running 'ubuntu-bug gnome-panel' will probably be better
[23:47] <mar> i changed settings a little and seems that it's running now
[23:48] <mar> it happened a lot to me for a few days so i'll try to catch it later