[01:23] <ArneGoetje> apachelogger: thanks a lot. :)
[02:15] <morfic> is ARM here to stay? somehow had the idea i read ubuntu dropped ARM support, i would love to be totally wrong on this though :)
[02:17] <directhex> morfic, ubuntu/arm hardware will be in the shops for xmas
[02:18] <morfic> i'd be happy to just keep ubuntu on this device if ubuntu is supporting it for a while
[03:05] <kees> jcastro: in http://identi.ca/notice/9803393 did you mean you were trying to _raise_ your vrms score?  :)
[03:36] <greg-g> kees: he's an instigator like that :)
[03:36] <kees> I suspected.  :)
[03:42] <LaserJock> I wonder how high I can get mine?
[03:42] <kees> that's the meme I'm working on now.  ;)
[03:43] <LaserJock> darn, only 0.7%
[03:43] <LaserJock> how the heck am I gonna tick off the FSF with that low of a score!!
[03:44] <LaserJock> and 1/2 of my score is from ATI/nvidia drivers, which I don't need
[03:45]  * kees is waiting for a massive apt-get to finish...
[03:45] <superm1> i dont think it's fair to count the modaliases
[03:45] <superm1> they're flat text files, nothing non-free about them
[03:45] <jcastro> you need all the sun java stuff to really make a difference
[03:46] <stooj> Does anyone know of a python programme that uses policy kit?
[03:47] <kees> I'm attempting to install all of multiverse and partner.  ;)
[03:48] <LaserJock> so if I install all of multiverse I can get to 30%
[03:48] <LaserJock> what we really need is a web-vrms that looks for non-free web apps
[03:48] <kees>   342 non-free packages, 15.2% of 2252 installed packages.
[03:48] <kees>   172 contrib packages, 7.6% of 2252 installed packages.
[03:49] <greg-g> nice
[03:49] <greg-g> LaserJock: that sounds like a great Fx plugin: "Sorry, vrms says that this site has non-free javascript and runs on .NET, you can't go here"
[03:50] <[reed]> kees: what program is that?
[03:50] <kees> [reed]: vrms
[03:50] <[reed]> ah
[03:53] <LaserJock> I'd love to run vrms on the Windows Vista desktop I just got today for work
[03:53] <LaserJock> I'm sure I'd have a slightly higher score ;-)
[06:28] <dholbach> good morning
[07:04] <billybigrigger> so i ibus taking over for xorg for input?
[07:04] <billybigrigger> now any keyboard and mouse issues should be attempted to be debugged through it?
[07:21] <YokoZar> Does anyone else have Applications->Accessories->gedit instead of Applications->Accessories->Text editor?
[07:28] <billybigrigger> i have gedit
[07:47] <poolie> doko: thanks for the fix for bug 392355, i'll test it
[08:45] <directhex> hm. one of my syncs seems to have evaporated
[08:46] <directhex> https://bugs.launchpad.net/ubuntu/+source/mono/+bug/426759 is "Fix Released", but I can't find it on the package publishing history nor the karmic queue
[08:58] <ogra> cjwatson, "Run usplash at the native resolution if KMS is available." where does usplash get the info about the theme/resolution to use for that ?
[08:59] <ogra> (i'm trying to convince it to use the matching framebuffer res on armel without defaulting to 640x480 and without making Keybuk unhappy by looking for a file that holds the res from initramfs)
[09:04] <cjwatson> ogra: can you use bzr log / bzr diff? the patch is fairly simple
[09:05] <cjwatson> if you read the diff and still don't understand, then ask me :)
[09:07] <directhex> blarg, why is my system so much less stable post-format?
[09:08] <Laney> you should have installed warty and upgraded
[09:09] <directhex> this system has never had warty
[09:09] <Laney> thats your problem right there
[09:10]  * Laney runs
[09:10] <pitti> Good morning
[09:13] <simon-o> Hi, I fixed a bug and uploaded the branch. It is enough to file a merge proposal or do I need to subscribe ubuntu-main-sponsors to the bug?
[09:14] <mvo> simon-o: for what package and bug?
[09:15] <simon-o> mvo: bug 376400 package graphviz
[09:15] <mvo> simon-o: subscribing ubuntu-main-sponsors is probably a good idea then
[09:16] <mvo> to ensure it is picked up by the sponsoring queue
[09:16] <simon-o> mvo: thanks, I just subscribed them.
[09:21] <mvo> simon-o: thank you for working on it!
[09:23] <slytherin> are there any rescue images for karmic? I got a unbootable PC because of bug 424503 and I don't want to download whole karmic daily CD. :-(
[09:25] <YokoZar> slytherin: you could try a stick image...but those are larger than the CD
[09:25] <YokoZar> so not really ;)
[09:25] <slytherin> ahh, I will download the CD image.
[09:26] <slytherin> sad thing is I didn't even have backup of old cd image (2 days old). So I can not even use jigdo/zsync.
[09:29] <cjwatson> you can use the netboot image to rescue
[09:29] <cjwatson> in a pinch
[09:29] <cjwatson> http://cdimage.ubuntu.com/netboot/
[09:35] <slytherin> cjwatson: I will try when I go home. Thanks for info.
[09:35] <slytherin> cjwatson: mini.iso is the image, right?
[09:37] <cjwatson> yeah
[09:55] <zyga> mvo: hello
[09:55] <zyga> mvo: is there any list of small tasks that 3rd parties could help you with the app store?
[09:56] <mvo> zyga: I have a "TODO" file in the source, there is also the "bitesize" tag in the bugreport
[09:56] <mvo> zyga: the bugreports of software-store
[09:56] <zyga> mvo: let me check that! :-)
[09:56] <mvo> zyga: there are quite a few smallish UI bits that are not done exactly as the spec says
[09:56] <mvo> :)
[09:56] <zyga> mvo: is it possible to do development on jaunty?
[09:57] <mvo> zyga: difficult, it uses aptdaemon and that is not available on jaunty
[09:57] <mvo> zyga: it would be a good idea to isolate that into a common class that can then be exchanged for a Mock class (or even a synaptic backend ;)
[09:57] <mvo> zyga: then it can be run under jaunty just fine AFAICS
[09:57] <mvo> zyga: that would be a nice task, something like the backend/ dir in update-manager
[09:58] <zyga> mvo: I'm fine with karmic kvm but I'll reinspect in a second - I need to find & fetch sources first
[09:58] <mvo> zyga: bzr get lp:software-store should do the trick
[09:59]  * mvo hugs zyga - great to have you back here :)
[09:59] <zyga> :-)
[09:59] <zyga> I'm ill so I have some time off from my regular work
[10:00] <zyga> mvo: I've got it - let me have a look at what's already there
[10:02] <lool> cjwatson: hola
[10:02] <lool> cjwatson: You might remember chaning usplash to use the native kms resolution
[10:02] <mvo> zyga: oh, get well
[10:02] <lool> cjwatson: (I do see that usplash is not that much relevant anymore but still)
[10:02] <lool> cjwatson: You actually changed the init/shutdown scripts to not pass -x / -y
[10:03] <lool> cjwatson: But that causes usplash to try to modeset to the first res in the linked list of themes
[10:03] <lool> cjwatson: Which is 640x400
[10:03] <lool> cjwatson: So we're actually using 640x400
[10:03] <lool> cjwatson: I tried an ugly patch to use the /sys values from the native kms virtual size and pass these as usplash xres/yres
[10:03] <lool> cjwatson: And result was nice
[10:04] <lool> cjwatson: So I wanted to double check whether it was intentional or not to use 640x400 (ogra suggested it might be to get the 640x400 centered around black)
[10:04] <cjwatson> lool: I thought that it would normally simply use the boot resolution
[10:04] <cjwatson> the intent was that it would do so
[10:04] <ogra> usplash does only what you tell it :)
[10:04] <ogra> and uses 640x400 if you dont tell it anything
[10:04] <cjwatson> that isn't really true, when it comes up bogl_xres is set to the native resolution
[10:05] <cjwatson> something slightly odd is happening if that isn't the case
[10:05] <lool> cjwatson: if there's no -x/-y and no usplash.conf, usplash uses the first theme res as default xres/yres and modesets to that
[10:05] <cjwatson> ok, that was not my expectation. feel free to fix
[10:05] <lool> cjwatson: Ok thanks
[10:05] <cjwatson> I don't think you should use /sys though; it would be better to have an option to usplash to use whatever resolution the framebuffer is currently in
[10:05] <lool> cjwatson: Do you see any issues with reading these values from /sys?
[10:05] <cjwatson> I do, it's ugly :)
[10:05] <lool> cjwatson: I absolutely agree
[10:06] <cjwatson> usplash is perfectly capable of figuring out the current fb resolution - it's just a matter of picking a theme based on that
[10:06] <cjwatson> I'd absolutely be in favour of such a change
[10:06] <lool> Ok
[10:06] <lool> It's not a 5 minutes change like reading from /sys though but I agree it's the right thing to do
[10:08]  * ogra only sees usplash_bogl_set_resolution(int xres, int yres) but no "get_resolution" in usplash_bogl.c
[10:08] <cjwatson> getdimensions
[10:08] <zyga> mvo: is it possible to replace aptdaemon with something like packagekit?
[10:08] <ogra> ah, right, i see it
[10:08] <zyga> mvo: I'm just wondering how to run it right now
[10:08] <zyga> mvo: is it conceptually the same thing?
[10:13] <mvo> zyga: yeah, packagekit, synaptic, aptdaemon, its just the install backend
[10:14] <mvo> zyga: ideally it should be a backend class so that the backend can easily be switched
[10:14] <zyga> mvo: it looks like atpdaemon is used everywhere, including the ui
[10:14] <zyga> mvo: if that's what you want I could try to hack it to move all stuff to backend and just glue the current code to use that backend
[10:15] <zyga> I'll probably move to karmic to get aptdaemon though
[10:15] <zyga> i'll be easier this way
[10:15] <zyga> mvo: is there any particular abstract interface thingy you like (like from abc import ... ) ?
[10:16] <mvo> zyga: ok, my plan is to eventually move the aptdaemon stuff all out into a single place, but I have not had time for that, so just using karmic is easier for now :)
[10:16] <mvo> zyga: no preferences here
[10:16] <zyga> mvo: okay
[10:28] <lool> cjwatson: the svga backend (but not the bogl backend) sets the res on init; should I care about that backend or is it ok if I only cover the bogl one?  I dont know whether the SVGA backend is actively used and whether it's important that it sets the res
[10:29] <cjwatson> lool: svga is used on x86
[10:29] <cjwatson> lool: for arm you don't need to worry
[10:43] <lool> Pff bogl does a kernel ioctl with xres/yres set to the defaults of 0 and this is kernel driver specific
[10:49] <zyga> I've got karmic :-)
[11:12] <geser> looking at http://launchpadlibrarian.net/31587515/buildlog_ubuntu-karmic-amd64.cmake_2.6.4-1ubuntu2_FAILEDTOBUILD.txt.gz I wonder what's the right fix. Move the missing header file from libxmlrpc-c3-dev to libxmlrpc-core-c3-dev or merge both -dev packages again as it was split so libxmlrpc-core-c3-dev could get into main but currently both libxmlrpc-c3 and libxmlrpc-core-c3 are in main so there is no
[11:12] <geser>  real reason for the split.
[11:24] <Keybuk> kees: yes, I do mind
[11:29] <Keybuk> kees: pulling random patches makes it hard to test things, and in general I do not want any patches in the Ubuntu package - we should only ship the upstream releases with no changes
[11:29] <Keybuk> there will be a new upstream release rsn, I will package that as soon as it's out
[11:29] <Keybuk> so be patient
[11:29] <Keybuk> we are not releasing *tomorrow*, there is plenty of time
[11:43] <james_w> I'm looking for other opinions from other devs on https://code.launchpad.net/~statik/ubuntu/karmic/couchdb/fix-bug427036/+merge/11543
[11:46] <lool> cjwatson: (I'm moving ogra's /sys reading from initramfs-tools to usplash but still intend to replace that stuff with proper usplash code)
[11:47] <ogra> lool, but please remove the dependency on mxcfb (else you need to read /proc/cmdline again from the usplash script) and make it look more like cjwatson's fix
[11:49] <lool> ogra: ?
[11:49] <lool> ogra: I'll show you what I have
[11:49] <ogra> ok
[11:49] <ion> keybuk: Do you have time to review the current mountall patches?
[11:49] <ogra> i have the code pretty much in my head (how i would do it)
[11:50] <ogra> lets see if we match :)
[11:50] <lool> ogra: http://paste.ubuntu.com/269076/
[11:50] <lool> ogra: I'm still finishing it, there's a typo (res instead of virtual_size)
[11:50] <ogra> even better than mine (i wouldnt have touched colins part :) )
[11:51] <ogra> yours fixes both :)
[11:51] <lool> Well I know it's ugly but at least it's consistent and will use the right res immediately for everybody and we used to check /sys for kms already
[11:51] <lool> But I intend to remove the /sys checks when I'm done
[11:52] <ogra> yeah
[11:52] <ogra> hacing it all in the C code will even make usplash.conf obsolete :)
[11:52] <ogra> *having
[11:52] <Keybuk> ion: not yet; I'm working on the network stuff
[11:53] <Keybuk> ion: but I did briefly look through them and they looked ok
[11:53] <Keybuk> ion: can't find the URL?
[11:54] <lool> ogra: I dont really know why we bother with usplash.conf in the usplash init-top and _down scripts since usplash will parse the .conf by itself if we dont set it on the cmdline
[11:54] <pitti> james_w: replied in the merge request
[11:55] <james_w> thanks pitti
[11:56] <james_w> pitti: tangential question, could you tell me what led you to vote "Abstain" on that request
[11:56] <ogra> lool, yeah, thats redundant
[11:56] <james_w> (so I can pass on the feedback to the LP devs as I think this is a failing in the UI)
[11:58] <ion> keybuk: http://heh.fi/patches/mountall/
[11:58] <Keybuk> ion: yeah found it
[11:58]  * Keybuk has a weird issue where if I reply to a mail, it appears to get deleted
[11:58] <ion> Huh
[11:58] <Keybuk> I'm not convinced it's not PEBCAK
[11:59] <pitti> james_w: there wasn't anything else that said "I just want to add a comment"
[11:59] <pitti> james_w: perhaps I should just have left it as "Select.."
[11:59] <james_w> did you use one of the "Reply" links, or something from the table at the top?
[12:00] <pitti> james_w: "reply"
[12:01] <james_w> ok
[12:01] <james_w> thank
[12:01] <james_w> s
[12:02] <pitti> james_w: in retrospect I should probably have voted "needs fixing", but I set it first before typing the comment
[12:05] <lool> Can usplash.conf have anything else than xres and yres?
[12:05] <lool> like verbose or something
[12:06] <lool> I think not but perhaps I'm wrong
[12:06]  * ogra thinks not either
[12:06] <Amaranth> verbose is a grub boot line thing
[12:06] <Amaranth> afaik usplash only has those two options
[12:07] <ogra> well, usplash has three more options beyond -x and -y
[12:07] <ogra> but i dont think it is able to read any of them from usplash.conf
[12:08] <ogra> (only -p and -c would be relevant at all even)
[12:08] <ogra> ah, no -v probably too :P
[12:10] <ogra> lool, the code in libusplash.c only reads x/y it seems
[12:34] <Keybuk> ion: they look ok to me
[12:34] <Keybuk> thanks for your hard work on that
[12:35] <Keybuk> I shall merge those in once I've finished the network testing :D
[12:35] <ion> np
[12:35] <ion> Aye :-)
[12:41] <sridhar> hii
[12:58] <cjwatson> soren: do the walrus/cluster/sc have to be running in order to register them, or is it better if they aren't?
[13:04] <ogra> cjwatson, what do we do about the binfmt/mono/chroot issue, do you agree its worth having a bug for it ? (probably even security flagged)
[13:07] <cjwatson> ogra: sure, seems like a kernel bug, though it would really be best to take it up with upstream
[13:07] <ogra> hmm
[13:09] <ogra> i still need to do a proof of concept first before i like to go upstream (set the interpreter in binfmt/cli to $chroot/$path_to_interpreter instead of /$path_to_interpreter to trigger teh right magic bit)
[13:12] <cjwatson> ogra: it won't work
[13:12] <cjwatson> the interpreter will look for files in the host system if you do that
[13:13] <pacopil> online boxing game http://www.kobox.org/kobox-fande-Nourine.html
[13:31] <lool> pitti: I see you were working on usplash changes; FYI I pushed some changes
[13:31] <lool> pitti: is this for A6?
[13:32] <pitti> lool: maybe, need to wait on some input from design team
[13:32] <pitti> lool: I don't mind it being uploaded now, though
[13:33] <lool> pitti: So your changes are uploadable?
[13:33] <pitti> lool: yes, they are
[13:33] <lool> Ok cool
[14:10] <ogra> cjwatson, https://bugs.launchpad.net/linux/+bug/427863 in case you are intrested (linked to the upstream report)
[14:11] <kirkland> pitti: did you get a chance to look at Bug #426724 ?
[14:11] <pitti> kirkland: still on my list; I reviewed the patch and left a comment there
[14:11] <pitti> kirkland: I'm way too busy today, I'm afraid, but I hope I can slip it in next week
[14:11] <kirkland> pitti: cool
[14:12] <kirkland> pitti: hmm, for some reason, LP didn't email your comments
[14:12] <bigon> https://edge.launchpad.net/ubuntu/+source/kvm O_o disapears from karmic?
[14:12] <kirkland> pitti: i'll drop the asprintf part, and resubmit
[14:13] <MacSlow> pitti, seb128: where's the gnome-session type (vanilla vs. stratiatella) selected (in which file)?
[14:13] <pitti> kirkland: right, that's the easy part; I need to do the same for ~/.dmrc (feel free to beat me to it, of course)
[14:13] <kirkland> pitti: i couldn't immeidately find that code ...
[14:14] <pitti> MacSlow: argh, I think stracciatella-session still needs porting to the new gdm as well
[14:14] <kirkland> pitti: the part that reads/writes dmrc.  .face was much more obvious
[14:14] <pitti> kirkland: hm, I don't know it off-hand either, I'm afraid (I'm not very familiar with the gdm code base yet)
[14:14] <pitti> MacSlow: but it should actually be pretty easy, it's just dropping a new file into /usr/share/xsessions/
[14:14] <kirkland> pitti: alrighty, i'll take another look while i'm fixing asprintf()
[14:14] <MacSlow> pitti, ah ok
[14:15] <MacSlow> thanks
[14:16] <cjwatson> bigon: qemu-kvm
[14:18] <bigon> cjwatson: oh right thx
[14:18] <bigon> :)
[14:20] <pitti> kirkland: cheers
[14:32] <kirkland> pitti: okay, i found the dmrc load and save code, that's pretty straightforward
[14:32] <pitti> kirkland: so if you can read ~/.dmrc, use that, otherwise fall back to ~/.ecryptfs/.dmrc?
[14:32] <kirkland> pitti: unfortunately, though, we don't have the user's name easily on hand at that point, only their home
[14:33] <kirkland> hmm, that should work
[14:33] <kirkland> pitti: thanks
[14:37] <cumulus007> Hi, how often are updates of ubuntu translations from launchpad distributed?
[14:38] <soren> cjwatson: Uh... I'm not sure to be honest.
[14:38] <dpm> cumulus007: for development releases, every few days, unless there is a freeze in between. For stable releases, approx. monthly. You might also want to check out the #ubuntu-translators channel if you're interested in Ubuntu translations
[14:39] <cumulus007> dpm: Thanks for the info :)
[15:14] <jdstrand> seb128: this may not be your area, it might be devicekit's, but nautilus shows under Places all my schroots that are under /dev/mapper. This is somewhat undesirable as I have 13 of them. Is this a known bug? is there a preference I can set somewhere?
[15:15] <seb128> jdstrand, it's probably a gvfs issue
[15:15] <seb128> can you open a bug with a gvfs-mount -li log and maybe a testcase?
[15:15] <jdstrand> ok
[15:42] <ogra> Keybuk, are there plans to pull insserv in ? seemingly debootstrap adds a dep on it ( NCommander told me )
[15:42] <cjwatson> (fwiw this is not something that is up to debootstrap, it's just the messenger)
[15:42] <soren> upstart depends on it as well, doesn't it? By way of sysvinit or something?
[15:43] <NCommander> soren, it looks like it's been living in universe though
[15:43] <soren> NCommander: It's a new dependency,presumably.
[15:44] <NCommander> soren, right. As it stands, modules-tools-init fails to configure since update-rc.d tries to use insserv, and boom, broken base system
[15:44] <cjwatson> sysv-rc Depends: insserv; perhaps a mismerge
[15:44] <soren> cjwatson: I'm not sure. Keybuk recently uploaded a new insserv, so it's definitely on his radar :)
[15:44] <NCommander> cjwatson, update-rc.d tries to call it :-/
[15:44] <cjwatson>   * debian/sysv-rc.postinst: Don't try and use insserv by default, though
[15:44] <cjwatson>     everything's in place for you to try if you like.  It can be activated
[15:44] <cjwatson>     with:
[15:44] <cjwatson>         USEINSSERV=yes dpkg-reconfigure sysv-rc
[15:45] <cjwatson> so I think the dependency and the attempt of update-rc.d to use it is a mistake
[15:45] <soren> Ah.
[15:45] <ogra> definately :)
[15:45] <cjwatson> I'm not going to touch it at the moment though, leave it to Scott :)
[15:46] <NCommander> :-)
[15:46] <cjwatson> since there's a sysvinit in the ubuntu-boot PPA
[15:55] <mneptok> cjwatson: do you know who is building Empathy packages for Karmic?
[15:56] <mneptok> Empathy was removed during a dist-upgrade >12h ago due to a shared lib problem. no sign of a rebuilt version based on the newer libs.
[15:57] <cjwatson> https://launchpad.net/ubuntu/+source/empathy says bigon was the last uploader
[15:57] <mneptok> k
[15:58] <mneptok> thanks. still working on the first cuppa, so LP is too much for my fingers just yet. :)
[16:04] <seb128> mneptok, what architecture do you use?
[16:04] <mneptok> seb128: amd64
[16:04] <mneptok> seb128: i had trouble finding a HPPA laptop
[16:04] <mneptok> :/
[16:04] <seb128> was probably an arch all any mismatch
[16:04] <ogra> use a sparc one
[16:05] <mneptok> ogra: i tried. Larry Ellison came in the night and stole it.
[16:05] <ogra> bah, bad guy
[16:08] <bigon> mneptok: some pkg are still stuck in new queue
[16:10] <bigon> seb128: did you had the time to let pass empathy trough the new queue?
[16:13] <mneptok> bigon: d'accord. j'attend.
[16:17] <Turl> fta: can you have a look at https://bugs.launchpad.net/ubuntu/+source/prism/+bug/246822 ?
[16:38] <seb128> bigon, mneptok: done now
[16:39] <kees> Keybuk: argh, sorry, I had already uploaded.  I only did it because it was causing me a lot of problems in my VMs (since all the signal handlers where broken, and doing dist-upgrades over ssh was tanking)
[16:39] <mneptok> seb128: thanks. waiting for it to trickle down, i guess. no updates to install here.
[16:39] <seb128> mneptok, right, you need to wait an hour for next publisher run
[16:41] <mneptok> seb128: you expect an American to *wait*?! ;)
[16:42]  * mneptok scrambles the bombers
[16:58] <jdstrand> cjwatson: I am either doing something wrong or mass-sync/backport.py is busted: http://paste.ubuntu.com/269246/
[16:58] <jdstrand> cjwatson: hi btw!
[16:58] <jdstrand> cjwatson: I tried with '-l production' too, but got the same error
[16:58] <cjwatson> err, blink, didn't see that when I last used it
[16:59]  * jdstrand scratches head
[17:00] <jdstrand> cjwatson: I did just get python upgraded on my machine...
[17:00] <cjwatson> jdstrand: who's the requestor of this particular bug? (LP id)
[17:00] <jdstrand> cjwatson: dobey
[17:00] <jdstrand> cjwatson: bug #397431
[17:01] <jdstrand> cjwatson: my backport.py invocation is in the paste
[17:02] <ScottK> slangasek had an interest in that one too.
[17:02] <cjwatson> it's not just backport.py anyway
[17:02] <cjwatson> >>> launchpad.people['dobey'].preferred_email_address
[17:02] <cjwatson> Traceback (most recent call last):
[17:02] <cjwatson> so it's either a launchpadlib (or deps) bug or an LP bug
[17:03] <jdstrand> yeah, hmm
[17:03] <jdstrand> I hate those
[17:03] <jdstrand> cjwatson: ok, thanks. I'll get this to the attention of the right people
[17:03] <cjwatson> ta
[17:04] <lool> doko: lp:~lool/glibc/eglibc-vfp-testsuite-updates
[17:04] <lool> doko: Could you please merge this when you upload ubuntu9?
[17:04] <lool> I created an ubuntu10 on top
[17:04] <lool> doko: Fixes testsuite failures on armel
[17:05] <lool> NCommander: ^
[17:07] <lool> Keybuk: Can you help with the insserv MIR?  LP #427709
[17:07] <lool> I can guess the rationale etc. but it's a bit weird that I document why it's needed myself and then tend to the review
[17:08] <ogra> you could as well just shove it in and write "because"
[17:18] <NCommander> doko, this is low priority, but I'll see if I can do something to help fix powerpc failures (I'm not sure if I'll have any free cycles in the near future to look at it :-/)
[17:35] <doko> lool: done
[17:39] <lool> doko: thanks!
[17:39] <lool> doko: Are you uploading this today BTW?
[17:39] <lool> doko: Or shall we revert the glib changes on armel
[17:39] <pitti> stgraber: sabayon was removed from Debian, with "ROM; almost completely broken"; should we follow suit? are you using it in edubuntu?
[17:39] <pitti> it doesn't have any rdepends
[17:39] <pitti> ./ubuntu.karmic/dvd: * sabayon            # desktop profile management
[17:39] <pitti> ./edubuntu.karmic/supported: * sabayon            # desktop profile management
[17:39] <pitti> that's it
[17:39] <pitti> seb128: ^
[17:40] <doko> lool: I'll upload, just finished testing on lpia
[17:43] <jdstrand> cjwatson: fyi, the backport.py issue is bug #319432
[17:43] <lool> doko: ok thanks!
[17:44] <cjwatson> thanks
[17:44] <cjwatson> mvo: do you have any idea what it is that causes all these "Package foo is already installed and configured" bug reports?
[17:49] <RainCT> seb128: Hey. I've got a question. The Zeitgeist binary package is currently called 'zeitgeist-core' but I think I'd better have it as just 'zeitgeist' now, any opinions on this? (basically what I'm wondering is whether a transitional package would be needed)
[17:49]  * pitti chuckles
[17:50] <seb128> RainCT, don't bother doing a transitional package no if was never in stable
[17:50] <pitti> Removing candidates:
[17:50] <pitti> ia32-libs-tools 14 in karmic
[17:50] <pitti> ment: (From Debian) RoThe Project; Most idiotic breakage ever
[17:50] <pitti> oops :/
[17:50]  * pitti wonders whether to remove it from karmic as well
[17:50] <pitti> cjwatson, slangasek: does that touch our multiarch efforts? ^
[17:50] <RainCT> seb128: Great, so I can just rename it with the next revision?
[17:51] <seb128> yes
[17:51] <cjwatson> ia32-libs-tools is the ia32-apt-get thing, isn't it? I didn't think that we'd changed our ia32-libs to use that (intentionally not)
[17:52] <RainCT> seb128: ok, thanks :)
[17:53] <cjwatson> jdstrand: you could always edit the script temporarily and hardcode an e-mail address :)
[17:53] <pitti> cjwatson: right
[17:54] <pitti> cjwatson: no, we didn't, we still have the usual mega-.deb with the .so files included
[17:54]  * pitti kills it, easy enough to revive
[17:55] <slangasek> pitti: doesn't affect us in the least
[17:59] <ulaas_> hi. what is the default theme for karmic gnome desktop?
[18:00] <ulaas_> still human?
[18:00] <slangasek> cjwatson: geser is reporting that a large number of the rebuild failures are false positives due to bug #412933; can we stop the rebuild run if it's ongoing, and do another one once that's fixed?
[18:00] <slangasek> (I'll look at fixing that in eglibc today)
[18:02] <cjwatson> slangasek: I'd be happy to stop it, but LP timeouts loading the relevant page at the moment
[18:03] <slangasek> heh, ok
[18:03] <slangasek> geser: ^^ :)
[18:04] <cjwatson> I don't get it though, eglibc is clearly trying to arrange for C++ strchr(const char *) -> const char * and strchr(char *) -> char *, and the prototypes look right for that. What's wrong with it?
[18:05] <cjwatson> obviously that makes no sense in C :-)
[18:08] <cjwatson> it appears to have been a change made for ISO C++ conformance
[18:11] <slangasek> oh, really?
[18:12] <jdstrand> cjwatson: is backport.py supposed to be able to handle backporting to a suite where the package doesn't already exist?
[18:12] <jdstrand> cjwatson: eg, foo is in karmic, but not in hardy. should backport.py be able to put foo in hardy-backports?
[18:12] <mvo> cjwatson: "foo already install and configured"> I think I have a fix in bzr
[18:12] <slangasek> cjwatson: do you have a reference handy?  (And if that's the reason, why is the eglibc code #if gcc_4_4'ed?)
[18:13] <jdstrand> cjwatson: it doesn't now, and I am deciding if I should error out more clearly or fix it so it works
[18:14] <cjwatson> jdstrand: it ought to just land in NEW; if it doesn't, that's a bug
[18:14] <jdstrand> cjwatson: ok, thanks
[18:14] <cjwatson> mvo: yay, I'd been wondering about that. Where, update-manager or elsewhere?
[18:14] <cjwatson> slangasek: no, I'm just inferring from the fact that the relevant prototypes are guarded by #ifdef __CORRECT_ISO_CPP_STRING_H_PROTO
[18:15] <cjwatson> slangasek: note that /usr/include/c++/4.4.1/cstring does stuff with that definition as well, so I infer that glibc and libstdc++ needed to cooperate on it, which is probably why it's specific to g++ 4.4
[18:15] <mvo> cjwatson: in apt itself, it seems to mis-interpret a dpkg state
[18:16] <slangasek> I think when I was looking at it before, I didn't even notice the difference in the argument type
[18:16] <geser> slangasek: might not be the best reference but http://www.cplusplus.com/reference/clibrary/cstring/strchr/ talks also about two declarations for strchr() in C++
[18:16] <slangasek> oops
[18:16] <cjwatson> mvo: oh, neat
[18:16] <slangasek> geser: right - sorry for steering you wrong
[18:17] <geser> slangasek: so I can continue fixing it?
[18:17] <doko> lool: I don't rush the upload now, I'm going to upload gcc-4.4 before the glibc build. will do that tomorrow, leaving now
[18:17] <slangasek> geser: yes
[18:17] <slangasek> geser: and I need to re-do a fix to kismet, reopen a bug, and apologize to quadrispro when I see him :)
[18:18] <geser> slangasek: and you could also sponsor bug #427791
[18:18] <cjwatson> right, so the problem in bayonne is that strchr(tone, '/') returns const char * - i.e. the warning is regarding the return value, not the first argument
[18:18] <cjwatson> or the error, rather
[18:19] <statik> hi doko, i'm having some problems with the latest python2.6 upload, bug #428004
[18:19] <slangasek> geser: ack
[18:19] <cjwatson> (it's being assigned to a char *)
[18:19] <slangasek> cjwatson: yes, now that I've been pointed at the real difference between the difference in the prototypes, I grok why it's a bug
[18:20] <statik> doko, i don't know enough about setuptools to fix it myself, but i think that bug report shows exactly what is failing
[18:20] <doko> statik: hmm, poolie did acknowledge that something like this was fixed with the recent upload
[18:20] <cjwatson> slangasek: *nod* just spelling it out since I'd gone to the effort of looking :-)
[18:20] <slangasek> geser: ack, will grab after I unblock some folks waiting on FFes
[18:20] <oussama> hello everybody
[18:20] <statik> doko, yes thats what is so interesting about it! building in place was working fine for my team until today/yesterday
[18:21] <doko> statik: will try to look at the weekend. I'm away now
[18:21] <cjwatson> (p.s. I *love* being able to do https://code.launchpad.net/ubuntu/+source/bayonne rather than having to download the whole source
[18:21] <cjwatson> )
[18:22] <lamont> bug 396700
[18:27] <cody-somerville> pitti, Does apport include the contents of the DCD file in bug reports?
[18:27] <geser> cjwatson: I hope you didn't manage to stop the rebuild
[18:34] <ScottK> statik: I can build C extenstions that don't use setuptools, FYI.
[18:34] <cjwatson> mvo: have lots of duplicates ;-)
[18:34] <lool> pitti: Pushing new glib2.0 without --enable-assert-messages on armel as doko indicated he will only upload eglibc tomorrow
[18:34] <cjwatson> geser: no
[18:34] <slangasek> wgrant: I don't suppose http://people.ubuntuwire.org/~wgrant/rebuild-ftbfs-test/test-rebuild-20090909.html has a way to incorporate successful archive builds from later versions of the package?  (i.e., auto-detect that the bugs have been fixed)
[18:37] <geser> slangasek: unless uploads to the main archive propagate also to this rebuild archive, a change in the script would be needed to check if there is newer version in the main archive than the rebuild archive and omit those packages
[18:38] <slangasek> geser: sure - that seems like an obviously beneficial change to make to the script, though :)
[18:42] <ogra> pitti, you guys discussed sabayon today ? i know sbalneav puts a lot of time into it but doesnt know much about packaging, it would be a shame to lose it
[18:43] <ogra> pitti, he does all his work upstream and provides ppa's with our packages including his patches, i know it works fine for many people from his ppa, he just needs someone to spnsor and do the packaging from the motu crowd
[18:43] <geser> can anyone advise me what would be the best fix for http://launchpadlibrarian.net/31643733/buildlog_ubuntu-karmic-i386.cmake_2.6.4-1ubuntu2_FAILEDTOBUILD.txt.gz? libxmlrpc-c3-dev got split into libxmlrpc-c3-dev and libxmlrpc-core-c3-dev to let libxmlrpc-core-c3-dev into main. cmake build-depends on libxmlrpc-core-c3-dev and the missing header is in libxmlrpc-c3-dev. The options are now to move the
[18:43] <geser> missing header to -core-c3-dev or merge the both -dev packages again as both are now in main (don't know why)
[18:43] <cjwatson> mvo: should we consider a stable update for that apt bug at some point, perhaps?
[18:47] <mvo> cjwatson: yeah, I think that is a good idea, lets see if its really fully fixed or if there are other corner cases too
[18:50] <jdstrand> cjwatson: fyi, updated backport.py to workaround the bug we discussed earlier and fixed synclib.py to handle NEW packages. backport.py and mass-sync both are working now
[18:50] <jdstrand> (commits 68 and 69)
[18:53] <cjwatson> jdstrand: thanks
[18:53] <mneptok> bigon: FYI, i needed to manually re-install Empathy once the libs were updated.
[18:56] <cjwatson> mvo: would you expect to see that bug on a package that does *not* have triggers itself?
[19:01] <cjwatson> mvo: I've found lots on packages shipping triggers, which are presumably the same thing - but also lots on packages that don't seem to have triggers of their own
[19:01] <cjwatson> mvo: I just searched for "already installed and configured" on https://bugs.launchpad.net/ubuntu
[19:02] <mvo> cjwatson: the bug for packages that are shipping triggers (like man-db) should be fixed with bug #414631 (in bzr)
[19:02] <mvo> cjwatson: the others will need extra analysis
[19:02] <cjwatson> ok, I won't dup those
[19:02]  * mvo looks at the output
[19:03] <mvo> uh, many
[19:04] <statik> ScottK: ah thanks for pointing that out about non-setuptools, I'll amend the bug summary
[19:04] <mvo> cjwatson: I can do that monday, sorry that I have not gotten around to that apt upload yet :(
[19:05] <cjwatson> no problem, thanks
[19:21] <lool> jdstrand: I dont get the changes in 427663??
[19:22] <jdstrand> lool: no, you wouldn't. the reporter was paulliu
[19:22] <jdstrand> lool: if you ack I'll process
[19:23] <jdstrand> lool: heh, that didn't come out quite right
[19:23] <jdstrand> lool: I was answering your question in the bug:
[19:23] <lool> jdstrand: oh sorry
[19:23] <jdstrand> Jamie, I'm core dev so I dont think I need universe-sponsors?
[19:24] <jdstrand> 13:22 < jdstrand> lool: no, you wouldn't. the reporter was paulliu
[19:24] <lool> jdstrand: I mixed it with my own syncs
[19:24]  * jdstrand didn't mean to come of snarky :)
[19:24] <lool> jdstrand: let me approve it hold on
[19:24] <jdstrand> off
[19:25] <lool> jdstrand: approved thanks
[19:25] <lool> jdstrand: and sorry
[19:25] <jdstrand> lool: sure! glad to help :)
[19:27] <paulliu> lool: thanks.
[19:50] <NCommander> Does anyone know how big the entire archive is ATM?
[19:52] <sebner> NCommander: ah good to see you, Did you get my mail a couple of days ago (about vtk) ?
[19:52] <NCommander> sebner, no
[19:52] <sebner> :(
[19:53] <sebner> NCommander: I wrote to sonicmctails@gmail.com
[19:53] <NCommander> sebner, might have missed it (all the LP bug mail goes there)
[19:53] <NCommander> sebner, what was it?
[19:53] <RainCT> Uhm.. Somehow knows how I can get apport to catch crashes of unpackaged stuff?
[19:53] <NCommander> RainCT, package it :-)?
[19:54] <sistpoty> RainCT: use gdb :P
[19:54] <RainCT> NCommander: Heh. No, I want it for stuff under development
[19:54] <RainCT> sistpoty: Tried that, but gdb loves freezing my session when the app it's running crashes
[19:55] <sebner> NCommander: vtk ftbfs on armel, lpia and powerpc and at least there seems to exist a fix in debian bts for armel and I asked if you can take a look at it. (and maybe the other platforms (They ftbfs on another position))
[19:55] <sebner> huhi sistpoty =)
[19:55] <sistpoty> hi sebner
[19:55] <sistpoty> RainCT: oh, that doesn't sound healthy for gdb
[19:55] <sebner> sistpoty: debian websvn telle me: Prepare nexuiz 2.5.1! \o/
[19:56] <sebner> *tells
[19:56] <sistpoty> sebner: heh... must admit I've lost track a little bit of nexuiz
[19:56] <NCommander> sebner, looks like an EJAVAPROBLEM
[19:56] <RainCT> sistpoty: at least it's doing that for both gnome-shell and gnome-voice-control. Maybe it only happens with panel-related stuff :P
[19:56] <NCommander> sebner, got a debdiff? I'll sposnor it
[19:56] <NCommander> (after confirming a test build on armel or powerpc)
[19:56] <sebner> NCommander: nothing yet because I don't have an armel machine to test so I wrote you a mail ;)
[19:56] <sistpoty> RainCT: you could set a limit for coredumpsize (with limit) and look at the core dump?
[19:56] <sebner> sistpoty: no worries, the commit message is 1h old ^^
[19:57] <NCommander> sebner, hrm, odd
[19:57] <NCommander> sebner, it was marked as NEW, but I didn't see it in my inbox
[19:57] <sebner> NCommander: heh, no worries :)
[19:57] <sebner> NCommander: I make a debdiff and you testbuild it? deal?
[19:58] <NCommander> sebner, how big of a diff do we have from Debian?
[19:58] <NCommander> sebner, I rather just NMU in Debian and sync it
[19:59] <sebner> NCommander: aha! I just noticed that it seems debian fixed the issues
[19:59] <sebner> NCommander: will need a merge though
[20:00] <sebner> NCommander: dependency thing and python2.6
[20:00] <RainCT> sistpoty: uhm I've done "ulimit -c 1000000", now what?
[20:00] <NCommander> sebner, do that, I'll sponsor the change
[20:01] <sebner> NCommander: well, you can review if you want, I can sponsor myself ^^
[20:03] <NCommander> sebner, :-P
[20:03] <sebner> NCommander: you are just the "armel" guy :P
[20:04] <NCommander> and the powerpc, ia64, and sparc guy
[20:04]  * NCommander kicks debbugs
[20:04]  * sebner hugs NCommander :)
[20:06] <sistpoty> RainCT: yep, then you should get a coredump if you start it from a shell and it crashes. You can then inspect the coredump with gdb
[20:06] <sistpoty> RainCT: unless there's another limit that you also need to set, and which I constantly forget *g*
[20:07] <RainCT> sistpoty: ah, where is this file supposed to appear? didn't get anything in the cwd
[20:08] <sistpoty> RainCT: in cwd actually
[20:08] <geser> ulimit -c?
[20:09] <RainCT> 1000000
[20:09] <sistpoty> RainCT: works for me at least: zsh: segmentation fault (core dumped)  ./test.bin
[20:10] <sistpoty> RainCT: unless the program you try to debug has its own segfault handler
[20:12] <geser> sistpoty: what's your value for /proc/sys/kernel/core_pattern?
[20:12] <sistpoty> geser: core
[20:12] <geser> RainCT: and you?
[20:13] <sistpoty> (I don't have apport installed, maybe that makes a difference?)
[20:13] <RainCT> geser: |/usr/share/apport/apport %p %s %c
[20:13] <geser> set it to core
[20:13] <geser> see man 5 core
[20:14] <sistpoty> geser: nice, thanks for the info
[20:14] <geser> if you pipe it to a command it doesn't get written to disk
[20:15] <RainCT> maybe it just doesn't work with shell (it has a wrapper script and works as a plugin upon mutter or some weird stuff), I'll try it with gnome-voice-control but first I've got to eat something :P
[20:15] <RainCT> sistpoty, geser: thanks for your help :)
[20:16] <sistpoty> np ;)
[20:22] <sebner> NCommander: http://paste.ubuntu.com/269358/ <-- if you are fine with it I'll upload it after a testbuild
[20:29] <NCommander> sebner, uploading to my PPA
[20:32] <sebner> NCommander: I don't have any space left on / so pbuilder dies. Let's wait for your ppa ^^
[20:33] <NCommander> sebner, one of the joys of having a devirtualized PPA is that I can test it on all architectures at once
[20:34] <sebner> NCommander: that's why you are the guy whom I wrote a mail :P
[20:34] <NCommander> sebner, ;-)
[20:37] <ScottK> NCommander: Would you please rescore r-cran-timedate?  I'm very curious to know if my sparc hack worked or not.
[20:38] <NCommander> ScottK, https://edge.launchpad.net/ubuntu/+source/r-cran-timedate/290.85-1ubuntu1/+build/1238939
[20:39] <ScottK> NCommander: That should be enough.  Thanks.
[20:39] <ScottK> BTW, edge doesn't show the build score anymore.  Someone should complain about that
[20:39] <NCommander> ScottK, I see it
[20:39] <NCommander>     *   Start in 1 minute (7098709) Rescore build
[20:39]  * ScottK looks again
[20:39] <dutchie> is this the right place to poke my branch getting merged?
[20:40] <ScottK> Urgh.  Started already
[20:40] <NCommander> ScottK, if it still fails, I'll have to look at it manually; my SPARC box crashed while updating upstart
[20:40] <NCommander> the upshot is it doesn't boot anymore
[20:41] <soren> dutchie: Depends on what it's a branch of.
[20:42] <dutchie> update-manager
[20:43] <ScottK> NCommander: If you want to work on sparc, figure out why xvfb segfaults (see the previous revision's build log)
[20:43] <soren> mvo: ^^ That's your cue :)
[20:43] <NCommander> ScottK, sparc a miserable pile of fail ATM sadly
[20:43] <NCommander> ScottK, I'm trying to work out why silo is crying in the corner
[20:43] <dutchie> https://code.edge.launchpad.net/~jshholland/update-manager/string-fixes
[20:43] <ScottK> That's definitely I higher priority
[20:44] <ScottK> I/A
[22:00] <mvo> dutchie: I'm having a look at the branch now
[22:16] <mvo> dutchie: could you mail the translators too that some strings change due to this? Or maybe manual unfuzzing in the po files is enough, it seems that not many user affect strings are affected (just ~3?)
[22:20] <dutchie> mvo: is that a translator's team?
[22:21] <mvo> dutchie: there is a mailing list, give me a sec
[22:21] <mvo> dutchie: https://lists.ubuntu.com/mailman/listinfo/ubuntu-translators
[22:22] <mvo> dutchie: that is the mailing list - I upload the new pot to rosetta now
[22:22] <mvo> dutchie: thanks very much for the branch, its merged now
[22:22] <dutchie> \o/
[22:23] <dutchie> i think that's my first contribution to a FOSS project that's been merged
[22:23] <mvo> *woooohhh*
[22:23]  * mvo hugs dutchie
[22:43] <wgrant> slangasek: That's on my todo-list after I finish exams and stuff in a few hours.
[22:43] <slangasek> wgrant: cheers :)
[22:57] <simon-o> cody-somerville: bug 428104: I don't know why --without-ssl was in debian/rules and why it worked before
[22:58] <cody-somerville> simon-o, I noticed that as well. autotools bug or something maybe
[23:01] <zegusty> Does anyone know the driver level keyboard buffer size?
[23:07] <cody-somerville> simon-o, ah, I see why
[23:07] <cody-somerville> simon-o, new version of gnutls no longer ship libgnutls-extra-config
[23:08] <cody-somerville> however, lftp doesn't FTBFS it just happily continues with ssl support dropped.
[23:09] <simon-o> cody-somerville: ok, I see. but the --without-ssl is still nonsense. It should be --without-openssl
[23:09]  * cody-somerville nods.
[23:09] <cody-somerville> simon-o, just about to say that :)
[23:16] <simon-o> cody-somerville: I don't see where libgnutls-extra-config is used. Just libgnutls-config (which was also dropped)
[23:17] <cody-somerville> simon-o, sorry, I meant to say libgnutls-extra-config and libgnutls-config
[23:17] <cody-somerville> Just libgnutls-config is used
[23:17] <cody-somerville> I have a patch but I'm having trouble running autoreconf
[23:26] <simon-o> cody-somerville: ftp://ftp.yar.ru/lftp/devel/lftp-3.99.14.tar.gz You can also check that package, it uses pkg-config to check for gnutls
[23:26] <simon-o> let me know if I can help out
[23:27]  * cody-somerville nods.
[23:27] <cody-somerville> Thats how I'm doing it.
[23:28] <cody-somerville> running autoreconf on that results in the same errors so I think there is a bug in autotools or something
[23:29] <cody-somerville> I'll have to patch configure its self I guess
[23:31] <sistpoty> cody-somerville: can you pastebin the errors (for my experience, usually it's not autotools that produce the error, but rather broken Makefile.am's or configure.ac's)