=== rickspencer3 is now known as rickspencer3-afk [01:23] apachelogger: thanks a lot. :) [02:15] 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] morfic, ubuntu/arm hardware will be in the shops for xmas [02:18] i'd be happy to just keep ubuntu on this device if ubuntu is supporting it for a while [03:05] jcastro: in http://identi.ca/notice/9803393 did you mean you were trying to _raise_ your vrms score? :) [03:36] kees: he's an instigator like that :) [03:36] I suspected. :) === shtylman__ is now known as shtylman [03:42] I wonder how high I can get mine? [03:42] that's the meme I'm working on now. ;) [03:43] darn, only 0.7% [03:43] how the heck am I gonna tick off the FSF with that low of a score!! [03:44] 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] i dont think it's fair to count the modaliases [03:45] they're flat text files, nothing non-free about them [03:45] you need all the sun java stuff to really make a difference [03:46] Does anyone know of a python programme that uses policy kit? [03:47] I'm attempting to install all of multiverse and partner. ;) [03:48] so if I install all of multiverse I can get to 30% [03:48] what we really need is a web-vrms that looks for non-free web apps [03:48] 342 non-free packages, 15.2% of 2252 installed packages. [03:48] 172 contrib packages, 7.6% of 2252 installed packages. [03:49] nice [03:49] 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] [reed]: vrms [03:50] <[reed]> ah [03:53] I'd love to run vrms on the Windows Vista desktop I just got today for work [03:53] I'm sure I'd have a slightly higher score ;-) [06:28] good morning [07:04] so i ibus taking over for xorg for input? [07:04] now any keyboard and mouse issues should be attempted to be debugged through it? [07:21] Does anyone else have Applications->Accessories->gedit instead of Applications->Accessories->Text editor? [07:28] i have gedit [07:47] doko: thanks for the fix for bug 392355, i'll test it [07:47] Launchpad bug 392355 in bzr "C extensions placed in wrong directory on karmic" [High,Confirmed] https://launchpad.net/bugs/392355 === cjwatson_ is now known as cjwatson [08:45] hm. one of my syncs seems to have evaporated [08:46] 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:46] Ubuntu bug 426759 in mono "Sync mono 2.4.2.3+dfsg-2 (main) from Debian unstable (main)." [Wishlist,Fix released] [08:58] 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] (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] ogra: can you use bzr log / bzr diff? the patch is fairly simple [09:05] if you read the diff and still don't understand, then ask me :) [09:07] blarg, why is my system so much less stable post-format? [09:08] you should have installed warty and upgraded [09:09] this system has never had warty [09:09] thats your problem right there [09:10] * Laney runs [09:10] Good morning [09:13] 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? === dholbach_ is now known as dholbach [09:14] simon-o: for what package and bug? [09:15] mvo: bug 376400 package graphviz [09:15] Launchpad bug 376400 in graphviz "dot2gxl gets segfault even with simple graph" [Undecided,Confirmed] https://launchpad.net/bugs/376400 [09:15] simon-o: subscribing ubuntu-main-sponsors is probably a good idea then [09:16] to ensure it is picked up by the sponsoring queue [09:16] mvo: thanks, I just subscribed them. [09:21] simon-o: thank you for working on it! [09:23] 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:24] Launchpad bug 424503 in grub2 "Boot fails with Out of Range Pointer error" [High,Confirmed] https://launchpad.net/bugs/424503 [09:25] slytherin: you could try a stick image...but those are larger than the CD [09:25] so not really ;) [09:25] ahh, I will download the CD image. [09:26] 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] you can use the netboot image to rescue [09:29] in a pinch [09:29] http://cdimage.ubuntu.com/netboot/ [09:35] cjwatson: I will try when I go home. Thanks for info. [09:35] cjwatson: mini.iso is the image, right? [09:37] yeah [09:55] mvo: hello [09:55] mvo: is there any list of small tasks that 3rd parties could help you with the app store? [09:56] zyga: I have a "TODO" file in the source, there is also the "bitesize" tag in the bugreport [09:56] zyga: the bugreports of software-store [09:56] mvo: let me check that! :-) [09:56] zyga: there are quite a few smallish UI bits that are not done exactly as the spec says [09:56] :) [09:56] mvo: is it possible to do development on jaunty? [09:57] zyga: difficult, it uses aptdaemon and that is not available on jaunty [09:57] 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] zyga: then it can be run under jaunty just fine AFAICS [09:57] zyga: that would be a nice task, something like the backend/ dir in update-manager [09:58] mvo: I'm fine with karmic kvm but I'll reinspect in a second - I need to find & fetch sources first [09:58] zyga: bzr get lp:software-store should do the trick [09:59] * mvo hugs zyga - great to have you back here :) [09:59] :-) [09:59] I'm ill so I have some time off from my regular work [10:00] mvo: I've got it - let me have a look at what's already there [10:02] cjwatson: hola [10:02] cjwatson: You might remember chaning usplash to use the native kms resolution [10:02] zyga: oh, get well [10:02] cjwatson: (I do see that usplash is not that much relevant anymore but still) [10:02] cjwatson: You actually changed the init/shutdown scripts to not pass -x / -y [10:03] cjwatson: But that causes usplash to try to modeset to the first res in the linked list of themes [10:03] cjwatson: Which is 640x400 [10:03] cjwatson: So we're actually using 640x400 [10:03] 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] cjwatson: And result was nice [10:04] 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] lool: I thought that it would normally simply use the boot resolution [10:04] the intent was that it would do so [10:04] usplash does only what you tell it :) [10:04] and uses 640x400 if you dont tell it anything [10:04] that isn't really true, when it comes up bogl_xres is set to the native resolution [10:05] something slightly odd is happening if that isn't the case [10:05] 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] ok, that was not my expectation. feel free to fix [10:05] cjwatson: Ok thanks [10:05] 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] cjwatson: Do you see any issues with reading these values from /sys? [10:05] I do, it's ugly :) [10:05] cjwatson: I absolutely agree [10:06] 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] I'd absolutely be in favour of such a change [10:06] Ok [10:06] 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] getdimensions [10:08] mvo: is it possible to replace aptdaemon with something like packagekit? [10:08] ah, right, i see it [10:08] mvo: I'm just wondering how to run it right now [10:08] mvo: is it conceptually the same thing? [10:13] zyga: yeah, packagekit, synaptic, aptdaemon, its just the install backend [10:14] zyga: ideally it should be a backend class so that the backend can easily be switched [10:14] mvo: it looks like atpdaemon is used everywhere, including the ui [10:14] 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] I'll probably move to karmic to get aptdaemon though [10:15] i'll be easier this way [10:15] mvo: is there any particular abstract interface thingy you like (like from abc import ... ) ? [10:16] 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] zyga: no preferences here [10:16] mvo: okay [10:28] 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] lool: svga is used on x86 [10:29] lool: for arm you don't need to worry [10:43] Pff bogl does a kernel ioctl with xres/yres set to the defaults of 0 and this is kernel driver specific [10:49] I've got karmic :-) [11:12] 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] real reason for the split. [11:24] kees: yes, I do mind [11:29] 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] there will be a new upstream release rsn, I will package that as soon as it's out [11:29] so be patient [11:29] we are not releasing *tomorrow*, there is plenty of time [11:43] I'm looking for other opinions from other devs on https://code.launchpad.net/~statik/ubuntu/karmic/couchdb/fix-bug427036/+merge/11543 [11:46] 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] 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] ogra: ? [11:49] ogra: I'll show you what I have [11:49] ok [11:49] keybuk: Do you have time to review the current mountall patches? [11:49] i have the code pretty much in my head (how i would do it) [11:50] lets see if we match :) [11:50] ogra: http://paste.ubuntu.com/269076/ [11:50] ogra: I'm still finishing it, there's a typo (res instead of virtual_size) [11:50] even better than mine (i wouldnt have touched colins part :) ) [11:51] yours fixes both :) [11:51] 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] But I intend to remove the /sys checks when I'm done [11:52] yeah [11:52] hacing it all in the C code will even make usplash.conf obsolete :) [11:52] *having [11:52] ion: not yet; I'm working on the network stuff [11:53] ion: but I did briefly look through them and they looked ok [11:53] ion: can't find the URL? [11:54] 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] james_w: replied in the merge request [11:55] thanks pitti [11:56] pitti: tangential question, could you tell me what led you to vote "Abstain" on that request [11:56] lool, yeah, thats redundant [11:56] (so I can pass on the feedback to the LP devs as I think this is a failing in the UI) [11:58] keybuk: http://heh.fi/patches/mountall/ [11:58] 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] Huh [11:58] I'm not convinced it's not PEBCAK [11:59] james_w: there wasn't anything else that said "I just want to add a comment" === MacSlow is now known as MacSlow|lunch [11:59] james_w: perhaps I should just have left it as "Select.." [11:59] did you use one of the "Reply" links, or something from the table at the top? [12:00] james_w: "reply" [12:01] ok [12:01] thank [12:01] s [12:02] james_w: in retrospect I should probably have voted "needs fixing", but I set it first before typing the comment [12:05] Can usplash.conf have anything else than xres and yres? [12:05] like verbose or something [12:06] I think not but perhaps I'm wrong [12:06] * ogra thinks not either [12:06] verbose is a grub boot line thing [12:06] afaik usplash only has those two options [12:07] well, usplash has three more options beyond -x and -y [12:07] but i dont think it is able to read any of them from usplash.conf [12:08] (only -p and -c would be relevant at all even) [12:08] ah, no -v probably too :P [12:10] lool, the code in libusplash.c only reads x/y it seems [12:34] ion: they look ok to me [12:34] thanks for your hard work on that [12:35] I shall merge those in once I've finished the network testing :D [12:35] np [12:35] Aye :-) [12:41] hii [12:58] 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] 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] ogra: sure, seems like a kernel bug, though it would really be best to take it up with upstream [13:07] hmm [13:09] 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] ogra: it won't work [13:12] the interpreter will look for files in the host system if you do that [13:13] online boxing game http://www.kobox.org/kobox-fande-Nourine.html === MacSlow|lunch is now known as MacSlow === elky` is now known as elky [13:31] pitti: I see you were working on usplash changes; FYI I pushed some changes [13:31] pitti: is this for A6? [13:32] lool: maybe, need to wait on some input from design team [13:32] lool: I don't mind it being uploaded now, though === cprov-afk is now known as cprov [13:33] pitti: So your changes are uploadable? [13:33] lool: yes, they are [13:33] Ok cool === marjomercado is now known as marjo [14:10] cjwatson, https://bugs.launchpad.net/linux/+bug/427863 in case you are intrested (linked to the upstream report) [14:10] Launchpad bug 427863 in linux "binfmt allows breaking out of chroots due to not respecting namespaces" [Undecided,New] [14:11] pitti: did you get a chance to look at Bug #426724 ? [14:11] Launchpad bug 426724 in gnome-control-center "login-screen has no user-pictures" [Wishlist,In progress] https://launchpad.net/bugs/426724 [14:11] kirkland: still on my list; I reviewed the patch and left a comment there [14:11] kirkland: I'm way too busy today, I'm afraid, but I hope I can slip it in next week [14:11] pitti: cool [14:12] pitti: hmm, for some reason, LP didn't email your comments [14:12] https://edge.launchpad.net/ubuntu/+source/kvm O_o disapears from karmic? [14:12] pitti: i'll drop the asprintf part, and resubmit [14:13] pitti, seb128: where's the gnome-session type (vanilla vs. stratiatella) selected (in which file)? [14:13] 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] pitti: i couldn't immeidately find that code ... [14:14] MacSlow: argh, I think stracciatella-session still needs porting to the new gdm as well [14:14] pitti: the part that reads/writes dmrc. .face was much more obvious [14:14] 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] MacSlow: but it should actually be pretty easy, it's just dropping a new file into /usr/share/xsessions/ [14:14] pitti: alrighty, i'll take another look while i'm fixing asprintf() [14:14] pitti, ah ok [14:15] thanks [14:16] bigon: qemu-kvm === robbiew-afk is now known as orbbiew [14:18] cjwatson: oh right thx [14:18] :) [14:20] kirkland: cheers === thekorn_ is now known as thekorn [14:32] pitti: okay, i found the dmrc load and save code, that's pretty straightforward [14:32] kirkland: so if you can read ~/.dmrc, use that, otherwise fall back to ~/.ecryptfs/.dmrc? [14:32] pitti: unfortunately, though, we don't have the user's name easily on hand at that point, only their home [14:33] hmm, that should work [14:33] pitti: thanks === orbbiew is now known as robbiew === lamont` is now known as lamont [14:37] Hi, how often are updates of ubuntu translations from launchpad distributed? [14:38] cjwatson: Uh... I'm not sure to be honest. [14:38] 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] dpm: Thanks for the info :) [15:14] 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] jdstrand, it's probably a gvfs issue [15:15] can you open a bug with a gvfs-mount -li log and maybe a testcase? [15:15] ok [15:42] Keybuk, are there plans to pull insserv in ? seemingly debootstrap adds a dep on it ( NCommander told me ) [15:42] (fwiw this is not something that is up to debootstrap, it's just the messenger) [15:42] upstart depends on it as well, doesn't it? By way of sysvinit or something? [15:43] soren, it looks like it's been living in universe though [15:43] NCommander: It's a new dependency,presumably. [15:44] 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] sysv-rc Depends: insserv; perhaps a mismerge [15:44] cjwatson: I'm not sure. Keybuk recently uploaded a new insserv, so it's definitely on his radar :) [15:44] cjwatson, update-rc.d tries to call it :-/ [15:44] * debian/sysv-rc.postinst: Don't try and use insserv by default, though [15:44] everything's in place for you to try if you like. It can be activated [15:44] with: [15:44] USEINSSERV=yes dpkg-reconfigure sysv-rc [15:45] so I think the dependency and the attempt of update-rc.d to use it is a mistake [15:45] Ah. [15:45] definately :) [15:45] I'm not going to touch it at the moment though, leave it to Scott :) [15:46] :-) [15:46] since there's a sysvinit in the ubuntu-boot PPA [15:55] cjwatson: do you know who is building Empathy packages for Karmic? [15:56] 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] https://launchpad.net/ubuntu/+source/empathy says bigon was the last uploader [15:57] k [15:58] thanks. still working on the first cuppa, so LP is too much for my fingers just yet. :) [16:04] mneptok, what architecture do you use? [16:04] seb128: amd64 [16:04] seb128: i had trouble finding a HPPA laptop [16:04] :/ [16:04] was probably an arch all any mismatch [16:04] use a sparc one [16:05] ogra: i tried. Larry Ellison came in the night and stole it. [16:05] bah, bad guy [16:08] mneptok: some pkg are still stuck in new queue [16:10] seb128: did you had the time to let pass empathy trough the new queue? [16:13] bigon: d'accord. j'attend. [16:17] fta: can you have a look at https://bugs.launchpad.net/ubuntu/+source/prism/+bug/246822 ? [16:17] Launchpad bug 246822 in prism "Prism should be updated to new upstream version 1.0b1" [Wishlist,Confirmed] [16:38] bigon, mneptok: done now [16:39] 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] seb128: thanks. waiting for it to trickle down, i guess. no updates to install here. [16:39] mneptok, right, you need to wait an hour for next publisher run [16:41] seb128: you expect an American to *wait*?! ;) [16:42] * mneptok scrambles the bombers [16:58] cjwatson: I am either doing something wrong or mass-sync/backport.py is busted: http://paste.ubuntu.com/269246/ [16:58] cjwatson: hi btw! [16:58] cjwatson: I tried with '-l production' too, but got the same error [16:58] err, blink, didn't see that when I last used it [16:59] * jdstrand scratches head [17:00] cjwatson: I did just get python upgraded on my machine... [17:00] jdstrand: who's the requestor of this particular bug? (LP id) [17:00] cjwatson: dobey [17:00] cjwatson: bug #397431 [17:00] Launchpad bug 397431 in jaunty-backports "Please backport python-oauth 1.0~svn1053-0ubuntu1 from Karmic to Hardy" [Wishlist,In progress] https://launchpad.net/bugs/397431 [17:01] cjwatson: my backport.py invocation is in the paste [17:02] slangasek had an interest in that one too. [17:02] it's not just backport.py anyway [17:02] >>> launchpad.people['dobey'].preferred_email_address [17:02] Traceback (most recent call last): [17:02] so it's either a launchpadlib (or deps) bug or an LP bug [17:03] yeah, hmm [17:03] I hate those [17:03] cjwatson: ok, thanks. I'll get this to the attention of the right people [17:03] ta [17:04] doko: lp:~lool/glibc/eglibc-vfp-testsuite-updates [17:04] doko: Could you please merge this when you upload ubuntu9? [17:04] I created an ubuntu10 on top === MacSlow is now known as MacSlow|capoeira [17:04] doko: Fixes testsuite failures on armel [17:05] NCommander: ^ [17:07] Keybuk: Can you help with the insserv MIR? LP #427709 [17:07] Launchpad bug 427709 in insserv "[MIR] insserv" [Critical,Triaged] https://launchpad.net/bugs/427709 [17:07] 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] you could as well just shove it in and write "because" [17:18] 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] lool: done [17:39] doko: thanks! [17:39] doko: Are you uploading this today BTW? [17:39] doko: Or shall we revert the glib changes on armel [17:39] stgraber: sabayon was removed from Debian, with "ROM; almost completely broken"; should we follow suit? are you using it in edubuntu? [17:39] it doesn't have any rdepends [17:39] ./ubuntu.karmic/dvd: * sabayon # desktop profile management [17:39] ./edubuntu.karmic/supported: * sabayon # desktop profile management [17:39] that's it [17:39] seb128: ^ [17:40] lool: I'll upload, just finished testing on lpia [17:43] cjwatson: fyi, the backport.py issue is bug #319432 [17:43] Launchpad bug 319432 in launchpadlib "RelativeURIError when trying to access an redacted object" [Low,Triaged] https://launchpad.net/bugs/319432 [17:43] doko: ok thanks! [17:44] thanks [17:44] mvo: do you have any idea what it is that causes all these "Package foo is already installed and configured" bug reports? [17:49] 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] RainCT, don't bother doing a transitional package no if was never in stable [17:50] Removing candidates: [17:50] ia32-libs-tools 14 in karmic [17:50] ment: (From Debian) RoThe Project; Most idiotic breakage ever [17:50] oops :/ [17:50] * pitti wonders whether to remove it from karmic as well [17:50] cjwatson, slangasek: does that touch our multiarch efforts? ^ [17:50] seb128: Great, so I can just rename it with the next revision? [17:51] yes [17:51] 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] seb128: ok, thanks :) [17:53] jdstrand: you could always edit the script temporarily and hardcode an e-mail address :) [17:53] cjwatson: right [17:54] 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] pitti: doesn't affect us in the least [17:59] hi. what is the default theme for karmic gnome desktop? [18:00] still human? [18:00] 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] Launchpad bug 412933 in eglibc "bayonne FTBFS with g++-4.4: wrong prototype for strchr()" [Medium,Triaged] https://launchpad.net/bugs/412933 [18:00] (I'll look at fixing that in eglibc today) [18:02] slangasek: I'd be happy to stop it, but LP timeouts loading the relevant page at the moment [18:03] heh, ok [18:03] geser: ^^ :) [18:04] 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] obviously that makes no sense in C :-) [18:08] it appears to have been a change made for ISO C++ conformance [18:11] oh, really? [18:12] cjwatson: is backport.py supposed to be able to handle backporting to a suite where the package doesn't already exist? [18:12] cjwatson: eg, foo is in karmic, but not in hardy. should backport.py be able to put foo in hardy-backports? [18:12] cjwatson: "foo already install and configured"> I think I have a fix in bzr [18:12] 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] cjwatson: it doesn't now, and I am deciding if I should error out more clearly or fix it so it works [18:14] jdstrand: it ought to just land in NEW; if it doesn't, that's a bug [18:14] cjwatson: ok, thanks [18:14] mvo: yay, I'd been wondering about that. Where, update-manager or elsewhere? [18:14] slangasek: no, I'm just inferring from the fact that the relevant prototypes are guarded by #ifdef __CORRECT_ISO_CPP_STRING_H_PROTO === robbiew is now known as robbiew-afk === robbiew-afk is now known as robbiew_ [18:15] 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] cjwatson: in apt itself, it seems to mis-interpret a dpkg state [18:16] I think when I was looking at it before, I didn't even notice the difference in the argument type [18:16] 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] oops [18:16] mvo: oh, neat [18:16] geser: right - sorry for steering you wrong [18:17] slangasek: so I can continue fixing it? [18:17] 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] geser: yes [18:17] geser: and I need to re-do a fix to kismet, reopen a bug, and apologize to quadrispro when I see him :) [18:18] slangasek: and you could also sponsor bug #427791 [18:18] Launchpad bug 427791 in cwidget "[FTBFS] error: invalid conversion from 'const char*' to 'char*'" [Undecided,New] https://launchpad.net/bugs/427791 [18:18] 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] or the error, rather [18:19] hi doko, i'm having some problems with the latest python2.6 upload, bug #428004 [18:19] geser: ack [18:19] Launchpad bug 428004 in ubuntuone-servers "building of python C extensions is broken" [Critical,Confirmed] https://launchpad.net/bugs/428004 [18:19] (it's being assigned to a char *) [18:19] 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] 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] statik: hmm, poolie did acknowledge that something like this was fixed with the recent upload [18:20] slangasek: *nod* just spelling it out since I'd gone to the effort of looking :-) [18:20] geser: ack, will grab after I unblock some folks waiting on FFes [18:20] hello everybody [18:20] doko, yes thats what is so interesting about it! building in place was working fine for my team until today/yesterday [18:21] statik: will try to look at the weekend. I'm away now [18:21] (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] ) [18:22] bug 396700 [18:22] Bug 396700 on http://launchpad.net/bugs/396700 is private [18:27] pitti, Does apport include the contents of the DCD file in bug reports? [18:27] cjwatson: I hope you didn't manage to stop the rebuild [18:34]