=== tkamppeter__ is now known as tkamppeter [01:04] RAOF: Which browser? [01:05] ScottK: Chromium is what's set up, and if it's running then the URL goes to the right place. [01:05] OK. I was curious since I haven't seen that. I may just not have been looking. [02:04] 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] ogasawara: could we have an upload of linux-meta-mvl-dove to match the 410 ABI? [02:04] cjwatson: Yeah, I just got reminded about that with bug #648401. [02:04] Launchpad bug 648401 in mesa (Ubuntu Maverick) "mesa-utils still referenced by packages" [High,Confirmed] https://launchpad.net/bugs/648401 [02:05] RAOF: ah, doko beat me to it - thanks [02:05] (I don't agree with his "option for maverick-updates", though - the archive needs to be consistent for release) [02:06] 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] 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] I don't think it matters too much from the archive point of view (FWIW) [02:09] It's probably easier from a review standpoint to re-munge the tarballs. [02:09] That does seem a bit like cheating, though. [02:10] RAOF: sounds like a pain to compare either way actually [02:10] so go with what makes most sense to you [02:11] Separate packging it is, then. [02:31] 8/c [02:32] Good morning :) === hunger is now known as Guest13487 [02:38] Hey RAOF. [02:39] Howdie TheMuso. How's Sydney's springtime treating you? [02:40] 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] It's decided to be really really windy, instead. [02:41] heh [02:42] I'm not yet sure what sounds from the roof to be alarmed at, either. === nigelbabu is now known as nigelb === almaisan-away is now known as al-maisan === fabbione_vac is now known as fabbione === al-maisan is now known as almaisan-away === almaisan-away is now known as al-maisan === al-maisan is now known as almaisan-away === almaisan-away is now known as al-maisan [07:27] cjwatson: just uploaded linux-meta-mvl-dove 2.6.32.410.2 [07:33] ogasawara: why are you up at this hour? [07:33] amitk: am actually just going to go to bed now. [07:34] ogasawara: good night, take care :) [08:19] Good morning [08:22] good morning pitti [08:25] 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] micahg: I'll have a round of SRUs next [08:57] pitti: awesome thank you [08:58] micahg: Brian Thomason (iamfuzz) [08:58] pitti: ? [08:58] pitti: \sh asked that :_) [08:58] oops, sorry ;) [09:00] RAOF, hey [09:02] <\sh> pitti: thx :) === spike_ is now known as spikeWRK [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:10] Debian bug 596950 in cdbs "makefile-vars.mk need $(cdbs_make_curbuilddir) from makefile.mk" [Serious,Fixed] [09:16] ogra: Howdie. [09:16] RAOF, i have a weird X input problem with a weird setup i run here [09:16] Good, good. Do go on :) [09:17] 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] Iiiiiiinteresting. [09:17] (i cant tell if it would work in console though since the kernel has no framebuffer console builtin) [09:18] Does the android kernel provide evdev devices? [09:18] i see garbage if i cat /dev/input/event0 and type on the keyboard [09:18] i'm not sure [09:18] That looks quite likely to be an evdev device. [09:18] i also cant run udev on the system since i cant start upstart [09:19] Ok. Well, that will certainly freak X's input autodetection out. [09:19] so i have to live with xorg.conf for input devices ... for the touchpad that works fine [09:19] and i see the kbd being detected too in the log [09:19] but ... [09:19] there are queue overrun errors all the time [09:20] i was wondering if you have any idea if there is a achnce to make it work [09:20] *chance [09:20] That would be queue overruns in dmesg? [09:20] (note thats only my private toy project, not work related or something ...) [09:20] no, in Xorg.0.log [09:20] EQ overflows? [09:21] let me get the device (i dont have it near me ...) gimme 10min [09:22] I'm not confident that I'll be particularly helpful, but sure :) === tkamppeter_ is now known as tkamppeter === asac_ is now known as asac [09:28] RAOF, [ 18128.824] Generic KBD: dropping event due to full queue! [09:28] thats the error i see [09:28] Hm. And you've set up your keyboard to be driven by evdev, or kbd? [09:29] evdev [09:29] since we dont have kbd in maverick [09:29] do we have a package of the old kbd driver anywhere = [09:29] ? [09:29] i'd happily recompile it for arm and try if that fixes it [09:30] You could probably grab one from Debian; they still need it, because it's useful on !linux [09:30] ah [09:31] yes, it apparantly is :) (/me considers android to be !linux) :) [09:31] I'm not _sure_ whether “ubuntu chroot on android kernel” is sufficiently not-linux to qualify :) [09:32] well, there runs a minimal android so ubuntu is effectively run as a chroot in a java VM :) [09:32] its more than the kernel [09:32] (as i said, really odd setup) [09:32] Heh. [09:40] 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] directhex, well, the java vm runs partitally inside the kernel [09:43] dalvik is a monstrous creation [09:43] there is a lot of GNU userland still [09:44] like busybox :) [09:44] a lot? [10:03] RAOF: ugh, that mesa upload looks scary at this point [10:07] ogasawara: thanks [10:11] <\sh> pitti: there are two more ftbfs fixes mgltools-{support,volume}, can you approve them? [10:12] \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] \sh: many thanks! [10:12] 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] 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] Launchpad bug 633406 in mesa (Ubuntu Maverick) "Display freeze when changing kwin effects settings if effects are active" [High,Confirmed] https://launchpad.net/bugs/633406 [10:15] <\sh> hmm..what happend to pkg sablotron in maverick? [10:16] smb: how do you feel about the current lucid-proposed kernel? [10:16] 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] pitti, Hehe [10:16] I was just thinking on that [10:16] smb: right, that was my impression, too [10:17] pitti, Cool. Yeah, I think it should be good to move [10:17] smb: good, will do; thanks [10:17] pitti, \o/ Thanks you :) [10:17] I'll reopen the failed bugs then [10:17] <\sh> micahg: sablotron is deleted, regarding LP you requested this...(LP #636333) [10:17] Launchpad bug 636333 in sablotron (Ubuntu) "Please remove sablotron from archive" [Wishlist,Fix released] https://launchpad.net/bugs/636333 [10:18] <\sh> micahg: what about caudium, which needs libsablot0*, should we remove it before release as well? [10:18] pitti: ping [10:18] smb: hm, there's only the main kernell, no -ec2 and armel friends; what happened to them? [10:18] \sh: yes, oh..let's see [10:18] happyaron: pong [10:19] pitti: excuse me, have you read my email about language packs in kubuntu/xbuntu live cd? [10:19] happyaron: I got it, yes; I didn't have time yet to respond [10:19] pitti: thanks [10:19] 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] ok [10:20] \sh: yes, it's been removed from Debian [10:20] pitti, We upload them soon and then could go over to updates as well [10:20] \sh: do you want me to file the bug? [10:21] <\sh> micahg: yes please [10:21] \sh: k, thanks for catching that [10:21] <\sh> micahg: np...just working down lucas ftbfs list [10:21] \sh: fabrice_sp already beat us to it [10:22] <\sh> ah yes :) [10:23] cjwatson: hi; https://bugs.edge.launchpad.net/ubuntu/+source/grub2/+bug/648638 may be of interest (or may not) [10:23] Launchpad bug 648638 in grub2 (Ubuntu) "grub_xputs not found after answering question as recommended during upgrade to maverick" [Undecided,New] [10:26] 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] jibel: do you know if anyone tested fglrx on jaunty? I didn't see feedback there [10:27] jibel: I'm inclined to just push it, since it's rather urgent, and the same patch worked everywhere else [10:28] pitti, no. I can give it a try. [10:28] anyone else with an x201s had a jumpy cursor, edge scrolling not working, that sort of thing? [10:28] not on my x201 (non-s) [10:29] lifeless: sounds like the touchpad is picked up by the wrong x input driver? [10:29] I'd assume so [10:29] there has been some bugs in the utouchification [10:29] lifeless: is that with the touchpad? [10:29] I'm usually running this machine docked (with usb mouse) [10:29] I'm half way through an ubuntu-bug ginput-device-settings report for this [10:29] pitti: yeah trackpad [10:29] pitti: the nipple is fine [10:30] s/trackpad/touchpad/ [10:31] lifeless: nope, touchpad works fine here [10:31] pitti: its finding it as SynPS/2 Synaptics TouchPad [10:31] which sounds right [10:31] *nod* [10:31] [ 16.085] (II) config/udev: Adding input device SynPS/2 Synaptics TouchPad (/dev/input/event10) [10:31] [ 16.085] (**) SynPS/2 Synaptics TouchPad: Applying InputClass "evdev touchpad catchall" [10:32] [ 16.085] (**) SynPS/2 Synaptics TouchPad: Applying InputClass "touchpad catchall" [10:32] * pitti redirects you to RAOF then [10:32] thanks [10:32] hah, details... [10:32] (II) config/udev: Adding input device SynPS/2 Synaptics TouchPad (/dev/input/mouse0) [10:32] (**) SynPS/2 Synaptics TouchPad: always reports core events [10:32] (**) SynPS/2 Synaptics TouchPad: Device: "/dev/input/mouse0" [10:32] (EE) ioctl EVIOCGNAME failed: Inappropriate ioctl for device [10:32] (II) UnloadModule: "evdev" [10:32] (EE) PreInit returned NULL for "SynPS/2 Synaptics TouchPad" [10:33] lifeless: oh, interesting [10:33] [ 16.583] (II) config/udev: Adding input device SynPS/2 Synaptics TouchPad (/dev/input/mouse1) [10:33] [ 16.583] (II) No input driver/identifier specified (ignoring) [10:33] lifeless: so on mine it tries to pick up both, but mouse1 is blacklisted somewhre [10:34] lifeless: do you have a synaptics stanza for the corresponding evdev device, too? [10:34] mouse1 in the nipple for me; I have no input devices in xorg.conf [10:35] lifeless: your boot loader is incorrectly installed [10:35] lifeless: (I haven't looked at the bug yet but that's what that error basically means. see my blog for details) [10:36] 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] lifeless: as far as I can see you read the help text precisely backwards [10:36] Note: It is possible to install GRUB to partition boot records as well, and [10:36] some appropriate partitions are offered here. However, this forces GRUB to [10:36] use the blocklist mechanism, which makes it less reliable, and therefore is [10:36] not recommended. [10:36] 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] and yet you interpreted this as saying that installing to sda was a bad idea? [10:37] smb: would you mind reuploading this with just the top changelog, and we'll try to push that to -updates fast? [10:37] what it actually says is that installing to sda1 may be a bad idea ... [10:37] cjwatson: *blink* [10:38] 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] 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] can't provide two lists, debconf doesn't support it [10:38] cjwatson: (yes, clearly I did read it backwards, for which I have no excuse) [10:38] I'll transform your bug into a recommendation to put a marker in the list [10:39] 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] smb: so now it's just -25.24 which is new [10:39] pitti, Ah ok, got it [10:39] smb: (rejected the current upload) [10:39] pitti, Ok, will do a quick repackaging. Just a second [10:39] smb: sorry, we probably should have accepted and tested this one first, and then moved to -updates [10:40] but as long as we don't get a new ABI, it should be fine [10:40] oh, and the new ABI will have the custom path anyway [10:40] 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] 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] cjwatson: I don't think so; this is my x201s (last machine to be upgraded) [10:41] lifeless: do you need repair assistance? [10:41] cjwatson: it was a fresh install 6 months ago [10:41] pitti, Just the current update may require people to remove the old package... [10:42] smb: right, it shouldn't cause problems, but I'd still like to have this change in, just in case [10:42] 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] pitti: appears that update-manager didn't update the evdev package correctly. [10:43] lifeless: you can/should just select sda [10:43] (selecting sda1 as well is technically harmless but may cause confusion later) [10:43] ok, I'll reconfigure again next time I'm about to reboot [10:44] the partition options are there for the minority (but not negligible minority) who have some other custom boot loader in the MBR [10:44] cjwatson: yeah, I can certainly understand the need and tradeoffs [10:44] I did a good job of foot-shooting [10:45] cjwatson: tri-booting my imac also needed a partition install of grub [10:46] right, weird hardware another reason :) [10:47] pitti, lucid-lbm re-uploaded (will probably take one or two more minutes to show up in lp) [10:48] 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] 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] tkamppeter, mvo, another package blocking the upgrade because of the change to foomatic-db-compressed-ppds: bug 647460 [10:57] Launchpad bug 647460 in update-manager (Ubuntu) "Upgrade from 10.04 to 10.10: printconf is blocking the upgrade." [High,Triaged] https://launchpad.net/bugs/647460 [10:59] jibel: thanks [11:07] smb: sconklin> fixed [11:08] 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] no-change rebuilds should be fine as long as they aren't packages with giant buildd times [11:11] (I meant to type "build" but that's good enough ...) [11:11] pitti: which packages? [11:12] cjwatson: I didn't start yet [11:12] note that libopensync-plugin-gnokii needs a non-trivial source change [11:12] I'm not sure if anyone is looking at the opensync cluster [11:15] I ran screaming [11:15] 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] my suspicion is that most of the rest require source work [11:15] 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] I'll see how far I'll get [11:15] night all [11:16] cjwatson: but I guess stuff like libavutil49, libindicator0, libvala0 should be triviall [11:16] I'll just start from the top === diwic is now known as diwic_afk [11:16] libvala0 is just libvala-dev and those are all build-deps [11:16] libindicator0 is just ubiquity which is already in progress [11:16] libavutil49 not sure, it's different between architectures so will require some analysis [11:17] libvala-dev is NBS itself; I'll check the rdepends for having alternatives to libvala-0.10-dev [11:18] right [11:18] pitti: BTW, I rewrote checkrdepends over the weekend - it has a slightly different argument syntax now [11:18] I noticed [11:18] though that wasn't the point, the point was to get cron.NBS runtime down to a minute [11:19] it's using launchpadlib now? [11:19] no [11:19] ImportError: No module named nautilus, even after installing python-nautilus, any suggestions? [11:19] perhaps we should add this to ubuntu-archive-tools bzr [11:19] 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] sure, if you like, though we don't have that checked out anywhere on cocoplum right now [11:20] nice [11:20] faster> well, at least if you're asking about large numbers of packages at once [11:21] 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] which should save us from future accidents [11:22] ah, right, we use /srv/archive-scripts/bin bzr right now [11:23] hm, it would be easier if libvala0.10-dev would Provides: libvala-dev.. [11:23] didrocks: ^ WDYT? [11:24] pitti: I think it's safe to do that, right [11:24] I don't see any reason that people want to build with previous buggy vala version [11:24] didrocks: I mean it's easier than adding alternative build-deps to http://people.canonical.com/~ubuntu-archive/NBS/libvala-dev [11:25] pitti: yeah, I agree, do you want to do the change? I'll report it to debian then. [11:26] didrocks: would be nice; thanks! [11:26] pitti: thank to you :) [11:26] didrocks: actually, no [11:26] didrocks: Debian didn't rename them that way [11:26] they just use unversioned packages [11:27] I'm not quite sure why we went through the hassle of versioning them [11:27] 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] Launchpad bug 648469 in labyrinth (Ubuntu Maverick) "depends on NBS python-gnome2-desktop" [High,New] https://launchpad.net/bugs/648469 [11:27] I'll just add the provides:, and NBS libvala{0,-dev} [11:28] cjwatson: for powerpc specific FTBFSes which block NBS removal, I guess we'll just remove them anyway and say "*shrug*"? [11:28] if they're leaf packages we can do that [11:28] pitti: debian did it in 0.9.5-1 IIRC [11:29] is dpm on holiday or something? [11:29] didrocks: no, see http://packages.qa.debian.org/v/vala.html [11:29] pitti: one thing only you can do, since dpm doesn't seem to be around; there are several uninstallable language packs [11:30] cjwatson: will look at those [11:31] thanks [11:31] vala uploaded with the new provides:; it's not a no-change upload, so I'll let someone else review it [11:31] didrocks: ^ [11:32] 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] didrocks: ah, in experimental only; I see [11:33] didrocks: ok, thanks for forwarding [11:33] * didrocks is not crazy (yet!) :p [11:36] 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] pitti: no [11:37] (I don't think so) [11:38] cjwatson: ok, thanks; we'll need a fresh -base rebuild and thus a full export [11:38] 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] cjwatson: ^ sounds okay to you? [11:39] 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] OK for after RC, yes [11:40] pitti: the LanguagePackTranslationDeadline is Sep 30th [11:40] what about the current uninstallables? do those need that fresh rebuild? [11:40] that, too [11:40] they're causing some livefs build failures [11:41] so we'll need to work around that [11:41] the -kde variant for those is newer than the main one [11:41] at least edubuntu-dvd [11:41] we could drop the strict dependency from -kde-base to -base [11:41] in fact, I think I can make this change in the langpack-o-matic templaltes [11:41] but that will only get effective at the next upload, of course [11:43] or we could exclude those language packs from the build [11:43] I think that's preferable for RC [11:43] for RC, yes [11:43] and after that it'll fix itself [11:43] right, we won't need the langpack-o-matic hack [11:45] \sh: accepted [11:46] didrocks: so you'll do the yelp update for bug 605577? I'll manually fix the -gnome-en langpack now, then [11:46] Launchpad bug 605577 in language-pack-gnome-en-base (Ubuntu Maverick) "Help contents title bar shows cubes with numbers instead of a proper title" [High,In progress] https://launchpad.net/bugs/605577 [11:47] 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] didrocks: ok, I'll have a look [11:48] pitti: thanks :) [11:48] <\sh> cjwatson: thx [12:02] seb128: why do we carry a manual patch 07_rosetta_translations_update.patch in yelp? [12:05] seb128: especially because this patch isn't in the series? [12:09] 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] (just using my memory, not 100% sure about it but that should be that :)) [12:09] didrocks: ok; I fixed the patch, but I won't upload it right now, since it's not currently cuasing trouble [12:10] bug updated as well; so we just need to accept the new -gnome-en-base, and everything is well again === diwic_afk is now known as diwic [12:21] pitti: accepted [12:21] cheers [12:23] latest python-virtkey is broken in maverick. bug 648695 [12:23] Launchpad bug 648695 in virtkey (Ubuntu) "package python-virtkey (not installed) failed to install/upgrade: file does not exist: /usr/lib/python2.6/dist-packages/python_virtkey-0.60.0.egg-info" [Critical,Triaged] https://launchpad.net/bugs/648695 [12:27] pitti, sorry I was at lunch [12:27] pitti, what didrocks say on the serie [12:27] seb128: ok, thank you [12:27] pitti, we carry the patch because translated xml are generated on build [12:27] so they don't work with langpacks [12:27] ah, I see === doko__ is now known as doko [12:34] 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] RAOF: btw, what is the replacement for the dropped mesa-utils? [12:45] doko: The split-out mesa-demos on revu http://revu.ubuntuwire.com/p/mesa-demos [12:46] Upstream dropped the code we shipped in mesa-utils from the main mesa tree between 7.8 & 7.9 [12:47] mesa-demos is exactly that code, now released as a separate project. [12:47] RAOF: somebody reviewing this currently? [12:48] No. [12:48] ok, looking at it [12:49] 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] \sh: I'll have a look [12:51] <\sh> doko: thx a lot :) === MacSlow is now known as MacSlow|lunch [12:58] RAOF: is the complete 11MB source really needed? [12:59] doko: I could repack the tarball and strip everything we don't ship out, for Maverick. [13:00] 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] ok, then it makes sense [13:06] RAOF: uploaded, waiting in NEW [13:06] doko: Awesome, thanks. [13:07] 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] That'd be an arsenal script, probably grabbing from the powerpc in the text of the bug. [13:09] I closed that mesa bug in the changelog, right? [13:09] Yes, there it is. Good :). [13:29] 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] RAOF: ok, thanks === diwic is now known as diwic_afk [13:48] pitti, fglrx-installer verified in jaunty too. [13:48] 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] \sh: Look at the end of the log. [14:01] 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 === bilalakhtar_ is now known as bilalakhtar [14:03] \sh: it's a recognised hack [14:04] <\sh> cjwatson: I mean the subject of the mail , that was irritating me :) [14:05] sure, like I say, it's not a particularly clean hack and everyone involved in creating it knew this :-) [14:07] hey [14:08] the last gnome-terminal update on lucid changes some useful defaults === MacSlow|lunch is now known as MacSlow [14:14] 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] jibel: they should, yes [14:19] */15 * * * * env LC_ALL=C bzr pull -q -d ~/public_html/bugpatterns >/dev/null [14:19] should have happened 4 mins ago, let me check [14:19] jibel: it's at r147 for bug 642518 [14:19] Launchpad bug 642518 in fglrx-installer (Ubuntu Karmic) "[MASTER] package fglrx 2:8.723.1-0ubuntu4 failed to install/upgrade: Kernel fix for CVE-2010-3081 breaks fglrx" [High,Fix released] https://launchpad.net/bugs/642518 [14:20] jibel: a manual pull doesn't bring anything new; did you push? === bilalakhtar_ is now known as bilalakhtar [14:31] pitti, yes I've pushed it, but can't find it anywhere and I'm still at r147 :/ probably another pebkac, retrying. sorry === ara_ is now known as ara === dendro-afk is now known as dendrobates [15:21] jibel: worked now === ivoks-afk is now known as ivoks-zombie [15:23] pitti, yes, thank you. I really don't know where my previous push is gone. [15:24] pitti, hi [15:24] jibel: to the place whe all the lost socks and pens go? [15:24] hey tkamppeter [15:24] pitti, very likely :) === bjf[afk] is now known as bjf [15:26] 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] 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] tkamppeter: is that important for maverick? we already have the new poppler, after all? [15:27] tkamppeter: oh, please push it; it's the Debian unstable development tree, after all [15:27] tkamppeter: if we need another maverick change, we'll branch it [15:34] pitti, thanks, I wll push it. [15:44] pitti, done. === deryck is now known as deryck[lunch] [16:14] Riddell: does the dbus you just uploaded differ in any way to the one from 2 hours ago? [16:16] pitti, can you have a look at bug 647369? It is probably a problem caused by the upstartification of CUPS? [16:16] Launchpad bug 647369 in gutenprint (Ubuntu) "gutenprint: postinst: lpstat: no such file or directory" [Undecided,Incomplete] https://launchpad.net/bugs/647369 [16:17] tkamppeter: very unlikely -- it seems it can't find /usr/bin/lpstat, but I wouldn't know why [16:17] 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] 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] ah [16:18] pitti, if lpstat is not found, one would get "Command not found". [16:18] \sh: *sigh* [16:19] 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] right, that'd start in the background [16:20] pitti: fixed .symbols file [16:20] Riddell: ah, so I'll reject the previous upload [16:20] Riddell: (done) [16:20] 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] pitti, so the backward compatibility commands, like "invoke-rc.d", "service", "/etc/initd.*" should wait for the service getting ready before exiting. [16:22] yes, indeed [16:23] pitti, should I move the bug to upstart and target it for Maverick? [16:23] so this would require a rather ugly while status cups | grep -q start/running loop [16:23] pitti, in the gutenprint postinst script works adding [16:23] 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] ah, I see; but 5 seconds wasn't enough there? [16:24] but this fixes only the reported problem with Gutenprint, there are probably many more. [16:24] Keybuk: ^ would it be realistic to have invoke-rc.d (on an upstart job) wait until the servie is "start/running"? [16:25] pitti, the loop breaks as soon as the file appears, for me always after one second, but there can be slower systems. [16:25] that might break tasks, though? [16:25] pitti: a better question would be to ask why invoke-rc.d doesn't wait for that right now [16:26] pitti, "start/running" is perhaps not even enough, as I get [16:26] till@till:~/ubuntu/gutenprint$ sudo stop cups; sudo start cups; ll /var/run/cups/cups.sock [16:26] cups stop/waiting [16:26] cups start/running, process 23356 [16:26] ls: cannot access /var/run/cups/cups.sock: No such file or directory [16:26] till@till:~/ubuntu/gutenprint$ [16:26] pitti, so a start/running is reported but the file is still not there. [16:26] tkamppeter: hm, but that's something that the original init script didn't do either [16:27] pitti: blocking is the default behaviour for "start" [16:27] to *avoid* start blocking until its start/running, you'd need --no-wait [16:28]