[00:07] <alex1> hi. are there some guidlines for submitting patches? I've submitted a patch to launchpad, but am not sure where to go from there...
[00:39] <norsetto> alex1: is it in debdiff format?
[00:42]  * norsetto wonders why he is talking to the wall
[00:42] <TheMuso> lol
[00:42] <TheMuso> Obviously he wasn't that concerned about the patch.
[00:43] <norsetto> TheMuso: a touch-and-go patch :-)
[00:45] <emgent> hello people.
[00:45] <norsetto> emgent: go to bed!
[00:46]  * norsetto is ...
[00:47] <emgent> hahha
[02:49] <BigPick> For anyone interested, I got around to posting up my workaround for getting boot logging fully operational until upstart's logd gets figured out.
[02:49] <BigPick> http://ubuntuforums.org/showthread.php?t=811005
[02:55] <lifeless> meh, stopping quagga during upgrade is one thing(correctness ftw), but -asking- - wtf.
[02:56] <persia_> Well, conceivably something could break if it was stopped, such as the controlling ssh session.  On the other hand not stopping/restarting could be bad.  Which is correct?
[02:58] <lifeless> persia_: the stop is mandatory
[02:58] <lifeless> persia_: but it tossed up a full screen prompt saying it had to stop it or abort the install
[02:58] <lifeless> persia_: on a headless unattended server upgrade.
[02:59] <lifeless> persia_: so I only found out when I came back to it some hours later :(
[03:00] <pwnguin> if you're not careful, you'll be a packagekit convert
[03:00] <BigPick> It should have just dropped the baby on its head and asked questions later.
[03:02] <persia_> lifeless: Hmm..  I can still see cases where restart now and restart later might be interesting, but either would be better than that.
[03:02] <lifeless> persia_: exactly
[03:03] <lifeless> anyone running a router *knows* the implications of updates
[03:03] <lifeless> if they don't, they shouldn't be running a router :)
[06:58] <Hobbsee_> afternoon all
[06:59] <TheMuso> Hey Hobbsee_.
[07:01] <Hobbsee_> TheMuso: how goes it?
[07:04] <dholbach> good morning
[07:04] <Hobbsee_> dholbach!
[07:05] <dholbach> hi hobbsee
[07:13] <pitti> Good morning
[07:13]  * pitti throws a gummybear at Hobbsee_
[07:14] <Hobbsee_> \o/
[07:14] <pitti> yay, a new full Hardy langpack
[07:14]  * Hobbsee_ throws the gummy bear to someone who will enjoy it
[07:14]  * Hobbsee_ looks for chocolate instead.
[07:14]  * pitti gives langpack-o-matic something to do
[07:15]  * pitti tosses a Ritter Sport to Hobbsee
[07:15] <StevenK> But then you'll langpack the buildds again
[07:15] <StevenK> Naughty pitti
[07:15] <pitti> asac will hurt me seriously if I don't do that soon
[07:16] <StevenK> He's closer than I am. Listen to him
[07:17] <Hobbsee_> hah
[07:48]  * pitti weeps at the OO.o FTBFS in hardy-proposed
[07:48] <Hobbsee_> pitti: you're surprised?
[07:48] <pitti> "ERROR: error 65280 occurred"
[07:48] <pitti> yeah, I hate error 65280 as well, it sucks
[07:49] <pitti> calc: ^ that needs bug fix 88432, right?
[07:49] <StevenK> calc didn't kill enough kittens before uploading again
[07:52] <pitti> argh, new LP broke python-launchpad-bugs again
[07:53]  * stgraber goes try the QA Tracker bug auto-syncer ...
[07:57] <stgraber> seems to update correctly
[07:58] <stgraber> pitti: what bit's broken in p-l-b ?
[07:58] <pitti> ValueError: Unknown error while subscribe sru-verification to  ...
[07:58] <pitti> and, in the retracers
[07:58] <pitti> launchpadbugs.bughelper_error.LPUrlError: "'Unknown error while loading https://bugs.launchpad.net/ubuntu/+bugs?field.tag=need-amd64-retrace'"
[07:59] <stgraber> ok, so that's when trying to get a list of bugs
[08:02] <thekorn> pitti, can't confirm this errors, could it be that his happened during last night's downtime?
[08:03] <pitti> thekorn: the retracer ones could be, just restarted and watching
[08:03] <pitti> thekorn: I'm currently tracking down the subscriber thing, I just ran it now
[08:06] <pitti> thekorn: ok, I have a reproducer, and tested with bzr head; I'll file a bug
[08:07] <thekorn> pitti, thanks, I'm able to reproduce it here too
[08:08] <pitti> ok, bug 235681 has the details
[08:09] <pitti> argh, "launchpadbugs.bughelper_error.LPUrlError: 'login failed https://launchpad.net/bugs/122123"
[08:09] <pitti> ^ retracers
[08:11] <thekorn> I'm working on a fix
[08:11]  * pitti hugs thekorn
[08:12]  * thekorn hugs pitti 
[08:12] <dholbach> thekorn for the win! :)
[08:13] <Hobbsee_> pitti: well, apparently API's are coming soon, so hopefully that will be a thing of the past...
[08:13] <pitti> yeah, I yearn for that day :)
[08:15] <pitti> hm, I cannot reproduce this login failure locally
[08:18] <thekorn> launchpad API for the win!
[08:32] <thekorn> pitti, something is wrong with my bzr here. I added a patch, feel free to commit it to the .main branch or I will do it later
[08:34] <thekorn> pitti, nm, it now worked, pushed to .main
[08:53] <erUSUL> hi; not sure if this is the correct place to raise this... i have proposed enabled today updates left me without openoffice programs. if i do a dist upgrade to force the instalation of ne oo packages what i loose are language-support-<isocode> is this problem known. should i file a bug report?
[09:00] <pitti> re
[09:01] <pitti> thekorn: oh, you rock!
[09:04] <pitti> thekorn: oh, new p-lp-bugs needs sqlite now?
[09:05] <asac> pitti: did you already kick off the language pack build?
[09:06] <thekorn> pitti, yes for the FF3 cookies, as cookielib does not support them yet
[09:07] <asac> thekorn: are you working on a cookies.sqlite -> cookies.txt dumper?
[09:07] <pitti> asac: yes, running now; they will be placed into the standard langpacks now, too (not -gnome any more)
[09:07] <pitti> asac: http://people.ubuntu.com/~kees/scripts/cookies-sql2txt
[09:07] <asac> pitti: great. can you approve the xulrunner patch in the meantime?
[09:08] <thekorn> asac, no, kees wrote one some time ago
[09:08] <asac> oh cool
[09:08] <pitti> asac: ok, so I'll release the lot then
[09:08] <asac> thats handy
[09:08] <asac> yeah ;)
[09:08] <asac> do you still have the list?
[09:08] <pitti> asac: sure,everything which is in the queue :)
[09:09] <asac> oh :)
[09:09] <asac> ok
[09:09] <asac> that should be enough :-P
[09:10] <pitti> thekorn: hm, I still get this nasty "login error" in the retracers; no idea why; anyway, I'll track that down later
[09:13] <pitti> doko: bug 27184 is horribly confusing; what does that soyuz bug have to do with gcc-defaults? it's in gutsy-proposed, but I don't know what to do with it
[09:14] <thekorn> pitti, maybe an expired cookie?
[09:14] <pochu> good morning
[09:14] <pitti> thekorn: it's the same cookie I used locally
[09:16] <thekorn> hmm, no idea then
[09:17] <pitti> asac: I assume the new ffox & friends have strict enough build deps for the new xulrunner? or do they need to be approved in order?
[09:24] <asac> pitti: the idea is that depends are right
[09:24] <pitti> ok, thanks
[09:30] <seb128> pochu: somebody blacklisted gtk-vnc because it was not syncing correctly apparently, not sure what the issue was though
[09:31] <seb128> pochu: I'm working on some SRUs right now but I'll look at that in a bit
[09:32] <pitti> seb128: if it's in the 'sync failure' section, and it works now, please kill it from the blacklist
[09:32] <seb128> pitti: right, I'm going to try if it's working, just finishing this sru first
[09:33] <seb128> pitti: btw I sent some other updates yesterday, I'm almost done with GNOME 2.22.2 updates and pending changes
[09:33] <seb128> pitti: next is to fix the gvfs issues which is going to be harder
[09:33] <pitti> seb128: I'm munching through the queue full steam ATM
[09:34]  * seb128 hugs pitti
[09:34] <seb128> pitti: thanks for all the work you put in reviewing all those uploads
[09:34] <pitti> haven't found time for the photo bits yet, I hope I can do that today
[09:34] <tonfa> gug
[09:34] <pitti> seb128: thanks for the updates! :)
[09:34]  * seb128 hugs pitti ;-)
[09:34] <tonfa> asac: ping
[09:37] <asac> tonfa: ?
[09:40] <tonfa> asac: I've got some problems with you nm-0.7 ppa
[09:40] <pitti> asac: oh, for audacious-plugins -- you actually *want* to drop the debian/dirs? then I rejected the wrong one
[09:40] <asac> tonfa: hmm
[09:40] <asac> tonfa: that one is really outdated
[09:41] <tonfa> can I query you ? is there a channel more appropriate ?
[09:41] <tonfa> asac: hum ok
[09:41] <asac> pitti: doesnt matter.
[09:41] <asac> pitti: i think its just the Pre-Depends
[09:41] <pitti> asac: I'm just confused which version I should accept
[09:42] <asac> oh, did i bump the version again? bad me. the last version i uploaded
[09:42] <pitti> ok, so .2 without debian/dirs
[09:42] <tonfa> asac: but I've seen a bzr branch for 0.7 which is still updated is it unrelated ?
[09:42] <pitti> I unreject it then
[09:42] <asac> yes, the one without debian/dirs should be the one
[09:43] <asac> tonfa: thats better ;) ... did you try it?
[09:43] <tonfa> asac: how do you build from it ? (I'm a noob in debian packaging) dpkg-buildpackage -uc -B ?
[09:44] <asac> tonfa: use bzr branch lp:~ubuntu-core-dev/network-manager/ubuntu.0.7
[09:44] <pitti> asac: why does the hardy-proposed xulrunner speak about intrepid workarounds?
[09:44] <asac> if you have that branch you can either build it using bzr bd ... or just debuild -b
[09:44] <tonfa> ok
[09:45] <tonfa> thanks
[09:45] <asac> pitti: let me read
[09:45] <pitti> http://launchpadlibrarian.net/14709759/xulrunner-1.9_1.9~rc1%2Bnobinonly-0ubuntu1~8.04.1_source.changes
[09:45] <pitti>    * Drop LDFLAGS workaround now that jemalloc is no longer a static lib.
[09:45] <pitti>      We still ship jemalloc as a shared lib
[09:46] <pitti> such kinds of changes in stables seem a bit weird?
[09:46] <pitti> it certainly didn't change between hardy final and now, or did it?
[09:46] <asac> pitti: jemalloc is an upstream thing
[09:47] <asac> pitti: it was broken as it shipped statically in libxul.so
[09:47] <pitti> asac: ok, so that's not related to changes in intrepid
[09:47] <pitti> asac: the intrepid bits confuse me a bit
[09:47] <asac> pitti: let me check. iirc those dont apply for gcc 4.2
[09:48] <pitti>   * Workaround multiple crashes in Intrepid (at least 3 in realpath()) caused
[09:48] <pitti>      by Intrepid shipping gcc 4.3 with -D_FORTIFY_SOURCE=2 by default.
[09:49] <pitti> oh, that's just -U_FORTIFY_SOURCE, it seems
[09:49] <pitti> well, that should be alright, it's not on in hardy anyway
[09:49] <pitti> it shouldn't be in an SRU anyway, though
[09:50] <asac> pitti: i agree on that in general. i tried to keep the branches in sync for as long as possible. if you want i can remove them now.
[09:51] <pitti> asac: well, don't rip it apart again just for this, since you already tested that uplaod
[09:51] <tonfa> asac: checking for POLKIT... configure: error: Package requirements (polkit-dbus) were not met << I couldn't find the package providing this :/
[09:53] <asac> tonfa: libpolkit-dbus-dev
[09:53] <pochu> tonfa: libpolkit-dbus-dev I guess
[09:53] <asac> :)
[09:53] <pochu> woops
[09:53] <pochu> asac: you're FAST!
[09:54] <tonfa> ok thanks
[09:55] <asac> ﻿pitti: yes, intentional. midbrowser needs to be released first :) ﻿the merge is ready, waiting for cwong or jimmy to apply two more patches i sent.
[09:55] <asac> pitti: ﻿unfortunately i lost commit rights as my new ssh keys are not yet in.
[09:55] <pitti> asac: ah, ok
[09:56] <StevenK> Does anyone know what settings controls the zooming icons as you launch something off the panel?
[09:56] <StevenK> I want to see if I can turn it on for desktop icons
[09:57] <seb128_> StevenK: what do you mean by settings? the animation? that's a gnome-panel thing
[09:57] <StevenK> seb128_: It looked compiz-ish
[09:57] <seb128_> it's not
[09:57] <StevenK> Aww
[09:58] <seb128_> StevenK: http://svn.gnome.org/viewvc/gnome-panel?view=revision&revision=10822
[09:59] <StevenK> Ahh ..
[09:59]  * pitti yays at the emptyness of https://edge.launchpad.net/ubuntu/hardy/+queue?queue_state=1&queue_text=
[10:00] <seb128> pitti: you rock!
[10:00] <seb128> pitti: does it mean we will get language pack updates too?
[10:00] <pitti> seb128: building ATM
[10:01] <seb128> rock on
[10:01] <pitti> (in langpack-o-matic, not yet uploaded)
[10:01] <pitti> oh, finished
[10:02] <\sh> good morning :)
[10:02] <pitti> asac: langpacks finished building; can I toss you the new German one for a local upgrade/install/functional test with the new ffox?
[10:08] <tonfa> asac: ok, it works now, I still have the same issues as with the debs from the ppa
[10:08] <tonfa> namely /usr/bin/nm-tool doesn't work
[10:08] <tonfa> it's not a binary
[10:09] <pitti> asac: http://people.ubuntu.com/~pitti/tmp/
[10:09] <tonfa> # nm-tool - temporary wrapper script for .libs/nm-tool
[10:09] <tonfa> # Generated by ltmain.sh - GNU libtool 1.5.26 Debian 1.5.26-1ubuntu1 (1.1220.2.493 2008/02/01 16:58:18)
[10:10] <pitti> asac: the upgrade works for me (package-/Replaces: wise), and language-pack-de-base has the Mozilla stuff
[10:11] <pitti> asac: but those translations don't work with my firefox (b5), so I'm interested in a test from you before I upload the lot
[10:13]  * pitti hovers over the trigger, waiting for asac in suspense
[10:18] <Treenaks> c
[10:20] <asac> pitti: downloading ...
[10:23] <pitti> do we have anyone here running hardy-proposed who has an USB mass-storage camera? (i. e. which is mounted as a drive, not talking through libgphoto)
[10:24] <Mithrandir> I have it at home, at least.
[10:24] <Mithrandir> (so, can't check for another five-ish hours)
[10:25] <TheMuso> pitti: I can put my hands on one if that is of any help.
[10:25] <pitti> DON'T TOUCH IT!!!!111!!
[10:25] <pitti> TheMuso: :)
[10:25] <asac> pitti: installed (i need two dpkg -i runs) ... works. remove packages again, verified that there is no cruft left; installed again and works
[10:25] <TheMuso> pitti: Roger that.
[10:25] <pitti> Mithrandir: if you plug it in, do you get a nautilus window with (a possibly broken) "open f-spot" button, or does it open the f-spot importer right away?
[10:25] <asac> so the de package appears to be ok feature/translation wise
[10:26] <pitti> Mithrandir: I tried it with a "fake" camera (DCIM/ on an usb stick), and it DTRT for me (open f-spot importer)
[10:26] <pitti> asac: \o/
[10:26] <pitti> TheMuso: ok, seems we can pull the trigger now :) do you want to have the honor?
[10:26] <TheMuso> pitti: Any way I can help...
[10:26] <pitti> TheMuso: "GIVE ME A \n!"
[10:27] <TheMuso> pitti: Ok if you need a tester, sure.
[10:27] <pitti> TheMuso: oh wait, seems I was confused; sorry
[10:27] <ogra> pitti, what do you need tested
[10:27] <pitti> TheMuso: you meant, "try camera", not "put your hand on the langpack trigger"
[10:27] <ogra> ?
[10:27] <TheMuso> pitti: lol
[10:27] <pitti> TheMuso: I though you were joking...
[10:28] <ogra> apprently my cam gets mounted fine on the desktop
[10:28] <TheMuso> pitti: I meant while I don't use the camera myself, I know it uses nautilus/is a drive, so can get it for testing.
[10:28] <pitti> TheMuso, ogra: so, I'm interested in what happens if you plug in a camera with mass-storage on current hardy; it should open the f-spot importer right away, and it should work; and if you open nautilus for the cam, you should get a working "open f-spot" button
[10:28] <ogra> it doesnt
[10:28] <Mithrandir> pitti: remind me in six hours and I can test.
[10:28] <pitti> Mithrandir: thanks
[10:29] <pitti> asac: ok, uploading the lot
[10:29] <ogra> nautilus mounts it on the desktop, no f-spot in sight (opposite to me plugging in the SD card directly to the laptop which does open f-spot just fine)
[10:29] <TheMuso> pitti: Right, I would test, but I've been informed that the non-standard USB cable is not here right now. :S
[10:29] <asac> pitti: rock!
[10:30] <pitti> ogra: do you get the button?
[10:30] <ogra> pitti, yup, i do
[10:31] <ogra> but it behaves differently on plug in
[10:31] <pitti> does it work?
[10:31] <ogra> hmm
[10:31] <ogra> clicked the button
[10:31] <ogra> no trace of f-spot
[10:32] <seb128> ogra: nautilus, preferences, media, what application is selected for camera import?
[10:32] <seb128> ogra: is your camera mounted, do you have a DCIM directory on it?
[10:32] <ogra> yes i do
[10:32] <ogra> as i said it did open the f-spot dialog before if i use the card in the builtin reader of my lappie
[10:33] <ogra> f-spot is the default for photo
[10:33] <seb128> and the camera mount has a DCIM directory?
[10:33] <ogra> yep
[10:33] <seb128> weird
[10:34] <seb128> what are the hal capabilities for the camera?
[10:34] <ogra> SANVOL/DCIM/100CASIO
[10:34] <seb128> SANVOL is the mountpoint?
[10:34] <ogra> yep
[10:34] <seb128> or a dir in the mount?
[10:34] <ogra> SANVOL is lying on my desktop atm
[10:35] <seb128> ok
[10:35] <ogra> as blockdevice
[10:35] <seb128> and the capabilities?
[10:35] <ogra> which one do you want to know
[10:35] <ogra> device manager has a lot here
[10:35] <seb128> the ones for the camera
[10:35] <seb128> maybe lshal > log before and after plugin the camera
[10:35] <seb128> and attach the diff to paste.ubuntu.com
[10:36] <ogra> that are over 50, let me script that
[10:36] <seb128> diff should be easy and efficient
[10:36] <seb128> it does the filtering for you
[10:37] <ogra> http://paste.ubuntu.com/15502/
[10:39]  * seb128 reads gvfs code
[10:39] <pitti> that's just a "block" "storage" one
[10:39] <pitti> but the heuristics should be based on seeing DCIM/*.jpg
[10:39] <pitti> my own fake uSB stick has info.capabilities = {'volume', 'block'} as well
[10:40] <ogra> but i have a subdir there
[10:40] <pitti> and f-spot opens right away
[10:40] <ogra> and i''m sure my other cam has that too
[10:40] <ogra> (have no access to the ther one atm though)
[10:40] <seb128> pitti: well, he has SANVOL/DCIM/100CASIO
[10:40] <pitti> ogra: ah, so what's the layout again? DCIM/somedir/ffoo.pic?
[10:40] <ogra> what seb128 said
[10:40] <ogra> 100CASIO hods the jpegs
[10:40] <ogra> *holds
[10:41]  * pitti changes his USB stick accordingly
[10:41] <ogra> just checked, f-spot standlone works (hjust to make sure its not f-spot's fault)
[10:42] <pitti> hm, just works for me
[10:42] <pitti> /media/PittiUSB/DCIM/100CASIO/01 - Fruehstueck.jpg
[10:43] <pitti> ogra: you are running hardy-proposed du jour?
[10:43] <pitti> gvfs (0.2.4-0ubuntu1) hardy-proposed; urgency=low
[10:44] <pitti>  -- Sebastien Bacher <seb128@canonical.com>  Tue, 27 May 2008 10:57:13 +0200
[10:44] <pitti> in particluar, that?
[10:46] <ogra_> sorry disconnect
[10:46] <ogra_>  i get the button, but no f-spot if clicking it
[10:46] <seb128> I can confirm that on an another box
[10:46] <seb128> which is not uptodate
[10:46] <seb128> upgrading gvfs now to try
[10:47] <pitti> seb128: in particular, this bug would be quite independent from using the gvfs-gphoto backend, right?
[10:49] <pitti> seb128: ogra's is recent, hm
[10:49] <pitti> so I wonder how I can reproduce that with an USB stick
[10:50] <ogra> storage.model = 'DIGITAL_CAMERA'   ... might that be something you need ?
[10:50] <seb128> ogra: did you restart your session using gvfs 0.2.4?
[10:51] <seb128> pitti: upgrading to gvfs 0.2.4 made it work on the box where it was not working
[10:51] <ogra> hmm, i didnt restart my session since prague i think, let me try
[10:51] <seb128> I still had 0.2.3 there
[10:51] <pitti> aah
[10:51] <seb128> there is one issue though
[10:51] <ogra> it should have a reboot notification or so
[10:51] <seb128> there is 2 f-spot actions listed in the nautilus properties
[10:51] <seb128> one is working, the other is not, but that's an another bug
[10:51] <pitti> right, I get these, too
[10:51] <ogra> me reboots
[10:53] <pitti> seb128: are there two .desktop files, or why are there two entries?
[10:54] <pitti> seb128: so if it works for ogra as well, I think we can set the f-spot button bug to 'fix committed'?
[10:54] <seb128> pitti: I think so
[10:54] <pitti> bug 208467
[10:55] <ogra> no go, sorry
[10:55] <seb128> hum
[10:55] <ogra> i also wonder why i dont get a nautilus window popping up
[10:55] <doko> pitti: no clue about #27184
[10:55] <pitti>  ogra: but it is mounted automatically?
[10:55] <ogra> i have to click the icon on the desktop, shouldnt tht open a window as well ?
[10:55] <ogra> yes
[10:57] <seb128> ogra: strace -e execve -f -p $(pidof nautilus)
[10:57] <seb128> and click on the "open f-spot" button
[10:58] <ogra> http://paste.ubuntu.com/15506/
[10:59]  * ogra wonders about SIGPWR
[11:00] <pitti> ogra: hm, but f-spot isn't actually opening?
[11:00] <seb128> ogra: does selecting the "other f-spot" in the nautilus properties make it work?
[11:00] <seb128> that's what I get when using the wrong one
[11:00] <pitti> I have the first one selected (if that's constant at all)
[11:01] <seb128> me too
[11:01] <pitti> confirmed here
[11:01] <pitti> if I select the other f-spot, I don't get f-spot
[11:01] <pitti> seb128, ogra: not opening a nautilus window is intended behaviour, since you are supposed to get f-spot *isntead* (not in addition)
[11:02] <pitti> so seems the actual issue is just to remove that broken f-spot from the list
[11:02] <seb128> I'm wondering why the heck f-spot is listed, it doesn't use the special mimetypes
[11:02] <seb128> maybe the code doesn't handle well 2 desktop have the same names or something
[11:03] <pitti> seb128: do you know which desktop files it looks at for assembling the list of possible applications?
[11:03] <pitti> seb128: e. g. I also have gthumb installed, would be nice to get this as an option in tha tlist, too
[11:04] <ogra> yeah, "the other" works :)
[11:05] <seb128> pitti: just add "x-content/image-dcf" to the MimeType list in gthumb.desktop to get it listed
[11:05] <pitti> ogra: yay
[11:05] <seb128> pitti: we should get the new gthumb version in hardy btw, it fixes quite some crashers and issues
[11:06] <pitti> seb128: right, that's still on my list
[11:06] <pitti> should work on this today
[11:06] <seb128> pitti: add "x-content/image-dcf", run sudo update-desktop-database and it's listed in nautilus
[11:06] <seb128> I just tried
[11:06] <ogra> now i get the f-spot popup as well ...
[11:06] <ogra> thats a quite scary window with lots of technical crap in it though
[11:07] <ogra> my mother would be scared
[11:07] <ogra> cant it just say "camera detected, do you want to import ?" instead of showing me usb device paths and numbers ?
[11:09] <seb128> ogra: it already does run the import, this dialog is f-spot which finds several camera available and do a poor job at asking which one you want to use
[11:10] <ogra> hmm
[11:10] <ogra> seems it found my builtin webcam from the laptop as device
[11:11] <ogra> thinking its a PTP one
[11:11] <ogra> and it found the PTP one twice
[11:11] <seb128> that explains why
[11:13] <pitti> seb128: nice, that works in principle (gthumb); it would need a separate .desktop for the gthumb importer, though
[11:13] <ogra> http://people.ubuntu.com/~ogra/f-spot.png
[11:13] <seb128> right
[11:13] <ogra> the second entry is strange
[11:13] <pitti> seb128: i. e. open gthumb with the right path
[11:13] <seb128> that's what we did for f-spot
[11:14] <pitti> I'll try to accomodate that into the gthumb update
[11:14] <pitti> seb128: anyway, I still have no clue where the second f-spot comes from
[11:14] <pitti> defaults.list:x-content/image-picturecd=f-spot.desktop
[11:15] <seb128> pitti: I'm looking at it, it's due to f-spot.desktop (moving it away make the entry go away too) but no idea why
[11:15] <pitti> seb128: coudl it be that one?
[11:16] <seb128> pitti: arg
[11:17] <seb128> no :-(
[11:18] <seb128> pitti: in fact yes
[11:18] <pitti> seb128: ok, so AFAICS this is basically the only real big bug now which we should fix for .1; gphoto gvfs could wait for .2 if it's too late, right?
[11:19] <seb128> pitti: right
[11:19] <seb128> pitti: fixing the double entry issue now
[11:19] <seb128> stupid bug
[11:19] <pitti> oh, you got it?
[11:20] <seb128> do we have a bug number for it?
[11:20] <seb128> pitti: yes, that's indeed the default.list which should use f-spot-import for those
[11:20] <pitti> aaaaaaaaaah
[11:20] <pitti> *headdesk*
[11:20] <pitti> desktop-file-utils: /usr/share/applications/defaults.list
[11:20] <pitti> that's a static file
[11:21] <seb128> pitti: right, that's the default list
[11:21] <seb128> pitti: ie, what we define as system default is several applications are installed
[11:22] <pitti> bug 208467 seems to be closest, I think
[11:22] <pitti> I updated the bug
[11:22] <norsetto> hi asac, news on my last email?
[11:26] <pitti> seb128: any idea how I can reset the values in the nautilus pref dialog? I don't find it in gconftool --dump nor gconf-editor
[11:28] <norsetto> asac: ok, re. gnome-mplayer and gecko-mediaplayer, let me know how you want to proceed
[11:28] <asac> norsetto: mplayer is in debian main right?
[11:28] <norsetto> asac: I think in non-free
[11:28] <asac> norsetto: anyway, we definitly need the ITP documented in changelog i guess
[11:28] <calc> pitti: probably, looking at it
[11:28] <calc> pitti: the problem with the build logs is it is running in parallel mode so has to be rebuilt without, i looked at the i386 build already (rebuilt at home without parallel)
[11:28] <asac> norsetto: http://www.debian.org/distrib/packages
[11:28] <asac> norsetto: if i search there for mplayer in unstable/non-free i get zero results
[11:28] <asac> norsetto: for unstable/main i get mplayer
[11:29] <asac> norsetto: looks like it was promoted to main in unstable
[11:29] <calc> pitti: not sure about the bug number you mentioned though, it doesn't seem to pertain to OOo?
[11:29] <norsetto> asac: yes, its in main now
[11:29] <pitti> calc: that was just a joke in response to "Error 65xxx occurred"
[11:29] <calc> pitti: ah ok
[11:30] <calc> pitti: the i386 build fails claiming -fexceptions needs to be enabled
[11:30]  * calc isn't sure why that would be disabled
[11:30] <norsetto> asac: ok, what about the gnome-mplayer itp? Its from somebody else and he already uploaded a package 1 year ago.
[11:31] <calc> pitti: ah there is a bugfix in rc1 for that
[11:31] <asac> norsetto: what happened to that package?
[11:31] <calc> pitti: i will try to spin a new build using rc1 today, was going to anyway, but appears the i386 build failure is solved by that already
[11:31] <norsetto> asac: sitting in Mentors ever since from what I could see
[11:31] <pitti> seb128: ah, great
[11:32] <calc> pitti: the sparc failure is most likely a buildd issue it works on debian (aiui) but hasn't built ooo in ubuntu for many months
[11:32] <pitti> calc: yeah, I was mainly concerned about i386, since amd64 worked, and now dist-upgrading on hardy-proposed is broken on amd64
[11:32] <calc> pitti: probably needs the language packs as well i would guess
[11:32]  * calc can upload those as well
[11:33] <pitti> right, but also -common etc.
[11:33] <calc> oh yea, i386 builds the indep packages
[11:36] <asac> norsetto: ever tried to get in contact with the initial uploader?
[11:36] <asac> ITP owner?
[11:36] <asac> norsetto: i have no clue whats going on ... didn't get the mail yet - not even in gmail :(
[11:36] <norsetto> asac: yes, but the last one was few months ago
[11:37] <norsetto> asac: perhaps I'm spammed by your ISP
[11:37] <asac> norsetto: i am looking at gmail web-interface right now
[11:38] <norsetto> asac: I can try to contact him again and tell him that we would like to bring it to debian, if he doesn't mind. If he minds than we forget about it
[11:39] <asac> norsetto: well. we should invite him to contribute if he still cares
[11:39] <pitti> seb128: gosh, I'm beginning to think that the options and selection of that photo app in nautilus is not stored in gconf; gthumb is still there, although I reset all my changes in the .desktop file, and ran update-*; very confusing
[11:39] <calc> pitti: i'll try to get it updated by tonight and built on i386/amd64 to make sure the bugs are shaken out
[11:39] <norsetto> asac: to say the truth, I tried to get him interested in Ubuntu but he left after a while
[11:39] <seb128> pitti: did you close and reopen the properties?
[11:39]  * calc is on vacation too so has to keep his wife happy ;-)
[11:39] <pitti> seb128: yes, and killall nautilus, etc.
[11:40] <seb128> pitti: weird
[11:40] <asac> norsetto: ok. just drop a short mail to ITP that we have a package ready for upload and would like to proceed. Lets look after a week. if nothing comes up we upload
[11:40] <norsetto> asac: will do
[11:40] <seb128> pitti: editing the desktop, running sudo update-desktop-database and reopening the properties is enough for me to get the list updated
[11:41] <pitti> seb128: gconftool --dump / > /tmp/old; change app in preferences; gconftool --dump / > /tmp/new; diff -u /tmp/old /tmp/new is empty
[11:41] <seb128> pitti: look in .local/share/applications
[11:41] <pitti> seb128: right, gthumb appeared that way; but it won't go away again
[11:41] <pitti> aaaaah
[11:41] <pitti> that's it
[11:42] <seb128> pitti: that change the default handler for the mimetype
[11:42] <pitti> yup, that works
[11:42]  * pitti hugs seb128
[11:42] <pitti> seb128: ok, now I can test the fix properly, thanks
[11:42] <seb128> pitti: should I upload the desktop-file-utils change then or do you want to do it since you figured where was the bug? ;-)
[11:43] <pitti> seb128: if you have it ready, please go ahead; I need to run out for a bit (see #d)
[11:43] <seb128> pitti: ok, I've it ready for upload, doing that now
[11:43]  * pitti hugs seb128
[11:43] <pitti> seb128: you ref'ed bug 208467?
[11:44] <seb128> pitti: yes
[11:44] <pitti> great
[11:46] <seb128> pitti: uploaded and bug updated
[11:54] <norsetto> asac: email sent with you in bcc (just in case you will ever receive it ...)
[12:03] <asac> norsetto: i received the gecko- mail ... what are you doing with the other mail?
[12:03] <norsetto> asac: sent it already, well before the gecko one !?
[12:06] <norsetto> asac: resent it again, stripped to the bare minimum
[12:07] <norsetto> asac: dbts:483551 is the gecko-mediaplayer itp
[12:08] <norsetto> http://bugs.debian.org/483551
[12:29] <asac> norsetto: still no more mail. you sure your mail setup works :)?
[12:30] <norsetto> asac: well, you got the gecko one
[12:30] <asac> norsetto: yes. is it the same mail account?
[12:30] <asac> norsetto: ok the ITP for gecko-mediaplayer looks good. Please document that in the changelog
[12:30] <norsetto> asac: yes, same account sent to same addresses
[12:31] <asac> norsetto: thats really strange.
[12:33] <norsetto> asac: I just redid another forward now (as attachment)
[12:34]  * norsetto <- food
[12:41] <blue-frog> hi, I am at a loss as to find where the list of directory(media) that will be listed on the desktop is kept. could you help please?
[12:41] <Keybuk> pitti: you don't have a bzr tree for dbus?
[12:42] <seb128> blue-frog: what is the question exactly?
[12:43] <seb128> blue-frog: the mounts under media and the user directory are listed
[12:44] <blue-frog> the gconf key volumes_visible when enabled shows icons of mounted folder in /media on the desktop, where can I define an extra directory?
[12:44] <blue-frog> so that things mounted in /extra would show as well
[12:44] <seb128> you can't
[12:44] <seb128> you need to do code changes to glib2.0 to do that
[12:45] <blue-frog> was afraid of that, ty for the answer
[12:55] <Gnontghol> I have fixed bug #235713 and made a new source package. How to upload it into Ubuntu?
[12:56] <cjwatson> pitti: does bug 232175 seem like a reasonable SRU candidate to you?
[12:56] <Festor> Gnontghol, upload the diff.gz
[12:56] <cjwatson> Gnontghol: only existing developers can actually upload to Ubuntu
[12:56] <soren> cjwatson: The edd option to pass to the kernel is just "edd=on", right?
[12:56] <cjwatson> Gnontghol: note that policies for maintenance of stable releases do not generally allow updating wholesale to a new upstream version
[12:56] <cjwatson> soren: yes
[12:56] <soren> cjwatson: Thanks.
[12:57] <cjwatson> Gnontghol: the individual change that fixed that bug should be extracted and backported
[12:57] <cjwatson> (yes, I know upstreams do not typically like that approach)
[12:57] <cjwatson> Gnontghol: once you've extracted the relevant patch, attach it to the bug report
[12:58] <Gnontghol> cjwatson: OK
[12:58] <seb128> Gnontghol: https://wiki.ubuntu.com/MOTU/Contributing has some informations on what to attach to the bug, how to subscribe the sponsors, etc
[12:58] <cjwatson> the exception might be if there are *no* other changes whatsoever since the version in hardy; however that doesn't seem to be the case here
[12:58] <asac> cody-somerville: does xubuntu use gconf to configure preferred applications (e.g. for mailto:, ftp: etc. schemes )?
[13:01] <seb128> Gnontghol: seems to be bug ##229000 btw
[13:16] <pitti> Keybuk: dbus is not in bzr, no
[13:17] <Keybuk> pitti: ok, I uploaded a bug fix release
[13:17] <Keybuk> all the patches are in their bugzilla
[13:18] <pitti> nice
[13:18] <Keybuk> also, I'd like to upload the following, but can you check it first? :)
[13:18] <Keybuk> http://people.ubuntu.com/~scott/dbus_1.2.1-2ubuntu3.debdiff
[13:19] <seb128> Keybuk: you don't want to upload to "hardy" ;-)
[13:19] <elmo> Keybuk: I thought you said upstart wasn't going to depend on the daemon?
[13:19] <Keybuk> seb128: ignoring that bit ;)
[13:20] <Keybuk> elmo: there's a useful bit of punctuation in the changelog called "a comma" :)
[13:20] <pitti> cjwatson: yes, very much so; misdetected partitions are nasty
[13:20] <pitti> Keybuk: ah, patch looks good; I guess that'll be neccessary soon enough for DeviceKit anyway :)
[13:21] <Keybuk> pitti: exactly
[13:21]  * pitti wants an IceCreamKit as well
[13:21] <pitti> and a KittenKit
[13:21] <Keybuk> the resulting debs match the layout of fedora's rpms
[13:23] <Keybuk> elmo: upstart doesn't depend on the daemon, it has its own dbus server internally
[13:24] <Keybuk> but userspace tools are expected to only communicate through the daemon
[13:24] <Keybuk> and since many other things like DeviceKit (and thus, udev) will be increasingly expecting the daemon to be around, it makes lots of sense to start it early
[13:24] <pitti> seb128: processed, merci
[13:24] <Keybuk> also means we can start gdm really early ;)
[13:27] <Hobbsee> pitti: you can't have a kittenkit.  we know you people like killing kittens.
[13:27] <pitti> but KittenKit is for people who love kittens!
[13:28] <Keybuk> libkit
[13:28] <soren> kitkit?
[13:28] <soren> kitkatkit?
[13:28] <Keybuk> sadly, Lennart didn't like libkit, and renamed it libmu
[13:29] <pitti> libmoo?
[13:30] <Ng> soren: we definitely need a kitkit to take care of the proliferation of other kits ;)
[13:30] <Mithrandir> and a KitFactory
[13:30] <lukehasnoname> kitmu
[13:32] <Keybuk> Ng: nobody's come up with a better name for them yet
[13:32] <mpt> BoxOfStuff
[13:33] <lukehasnoname> you must like your job, soren
[13:33] <soren> lukehasnoname: What makes you say that?
[13:33] <soren> I'm not disagreeing, I'm just curious :)
[13:34] <lukehasnoname> paid work on Ubuntu. Canonical is a small shop with big needs, so they only get the best (pure assumption). So you must enjoy your work
[13:35] <lukehasnoname> I'm here at a large subcontractor of the US govt. pinging printers
[13:35] <lukehasnoname> ofcourse this is internship.
[13:35] <soren> lukehasnoname: Yeah. My wife thinks I enjoy a bit too much :)
[13:36] <lukehasnoname> heh
[13:36] <Keybuk> "Honey, are you coming to bed?" ... "Just one more merge" ... <fx: slamming door>
[13:36] <cjwatson> damn, must get rid of that camera Keybuk installed here
[13:37] <pitti> Keybuk: you can't possibly have overheard me from your place!
[13:38] <lukehasnoname> Is $55,000 - $60,000 USD an unreasonable estimate for out-of-college pay for an MIS/CS job? I know this is off-topic, but it seems slow right now anyway.
[13:38] <pitti> pedro_: would you have some time to verify bug 228534? I tested it myself carefully, but I'm the uploader, so I need a second "thumbs up"
[13:39] <pedro_> pitti: sure, let me check
[13:39]  * pitti hugs pedro_
[13:39] <pitti> pedro_: you are too fast, you just beat me with the evince verification, too
[13:39]  * pedro_ hugs pitti back
[13:40]  * nxvl slaps pedro_ 
[13:40] <nxvl> :D
[13:40] <nxvl> pedro_: finally you upload the pictures on time!
[13:40] <pedro_> pitti: haha, i'm trying to do the more SRU's i can in order to have them included for .1 ;-)
[13:40] <pedro_> hey nxvl!
[13:40] <pitti> pedro_: right, me too; we still have a large unverified stack
[13:40] <pedro_> nxvl: haha you're like the 10 person that said me that :-P
[13:41] <pitti> persia: attacking that soon is highly appreciated
[13:41]  * pochu slaps pedro_ too :P
[13:41] <persia> pitti: tab miss?
[13:41] <nxvl> it's pedro slaps party?
[13:42] <pitti>  persiahm?
[13:42] <pedro_> haha hate you guys
[13:42] <pochu> pitti: there's a sync request for a package from Debian non-free which isn't in Ubuntu, is there any special procedure for non-free, or do I act as with any other sync requests?
[13:42] <pitti> pochu: just say that it's from non-free, otherwise it's the same
[13:43] <pochu> pitti: ok, thanks
[13:43] <pochu> nxvl: how's been your trip for Europe?
[13:43] <nxvl> pochu: i'm in Prague again, tomorrow i will fly to Madrid
[13:43] <nxvl> for one night and then to peru
[13:43] <lukehasnoname> o_o
[13:44] <lukehasnoname> where do you hail from?
[13:44] <lukehasnoname> peru?
[13:45] <pitti> persia: "tab miss"?
[13:45] <nxvl> i live in Peru, yes
[13:45] <pitti> persia: oh; yes, indeed; sorry
[13:45] <lukehasnoname> Rich people and their trans-Atlantic travel
[13:46] <persia> pitti: "﻿(21:41:01) pitti: persia: attacking that soon is highly appreciated".  I'm guessing that was a nick-completion error, and thought it confirmed when you didn't hit me with more context.
[13:46] <pitti> persia: yes, I meant "pedro"
[13:46] <persia> pitti: No problem.  Just wanted to make sure I didn't owe you something :)
[13:49] <sistpoty|work> may I ask an archive admin to process a few syncs?
[13:50] <sistpoty|work> (as in the queue is quite big again *g*)
[13:50] <pochu> sistpoty|work: better, ask an archive to process the queue ;-)
[13:50] <pochu> (as in I'm waiting for some syncs too) ;)
[13:51]  * pitti focuses on hardy today, archive day -> tomorrow
[13:51] <sistpoty|work> pochu: actually that's what I'm trying to do. just with the wrong words probably *g*
[13:51] <norsetto> nxvl: so, you survided ...
[13:51] <pitti> tomorrow is hardy.1 freeze, so we better spend our time on hardy today
[13:51] <nxvl> norsetto: yes
[13:51] <nxvl> norsetto: i almost died
[13:51] <norsetto> you got me and roak-whatever worried
[13:51] <nxvl> norsetto: they wanted to send me a Coke for 4 euros
[13:52] <nxvl> RoakSoax
[13:52] <sistpoty|work> pitti: ah, good to know.
[13:52] <nxvl> i almost get a Dehydration
[13:53] <nxvl> but i walk accross almost all Rome in one day
[13:53] <nxvl> :D
[13:53] <norsetto> nxvl: yesterday wasn't so hot actually
[13:54] <norsetto> nxvl: where did you sleep ( I mean, you slept?)
[13:55] <nxvl> norsetto: david's flat
[13:55] <nxvl> norsetto: a HORRIBLE B&B
[13:55] <lukehasnoname> rofl
[13:55] <ogra> pitti, urgh, tomorrow ?
[13:55] <norsetto> nxvl: hehe
[13:55]  * ogra totally missed that
[13:55] <pitti> ogra: so I was told
[13:56] <nxvl> it's know that some people use makeup for the photos on the web pages, but this guy is using photos from a different place
[13:56] <nxvl> it was just crazy
[13:56] <cjwatson> sistpoty|work: I'll do a bit of it at least
[13:56] <sistpoty|work> cjwatson: thanks a lot :)
[13:57] <norsetto> nxvl: at least you weren't robbed
[13:58] <nxvl> norsetto: mmm depend of you mean by robbed :D
[13:58] <lukehasnoname> So 8.04.1 comes out on my parents' 29th anniversery, and Intrepid comes out on my 20th birthday.
[13:58] <Keybuk> cjwatson: I'm doing a rebuild test atm to see what breaks with libtool 2.2
[13:58] <nxvl> norsetto: at the airport one gay just forgot to give me 5 euros back
[13:58] <nxvl> norsetto: and i realize it too late to say anything
[13:58] <Keybuk> hopefully only a few packages will require patching
[13:59] <norsetto> nxvl: well, ok, lets say you weren't physically abused ...
[13:59] <nxvl> heh
[13:59] <nxvl> yes
[14:00] <nxvl> at termini some "information" guy told me his office had a cheap hostal, start giving me indications, but when he said, "it's my office i can take you there" i just run
[14:00] <norsetto> lol
[14:00] <nxvl> to old lie for a sudaca
[14:07] <norsetto> asac: there you go: bug 235675
[14:09] <wgrant> Hmm, I'm sure that's a dupe.
[14:09] <norsetto> wgrant: there must be a dozen like that
[14:09] <cjwatson> doko: could you confirm bug 228724? it's replacing an openjdk change of yours with java-gcj-compat-dev, so I wanted to check
[14:10] <wgrant> norsetto: Rightly so.
[14:11] <doko> cjwatson: I think this is fine for now; we'll have to change this to default-jdk-builddep anyway in the future
[14:12] <cjwatson> ok
[14:12] <cjwatson> thanks
[14:13] <Keybuk> wing-commander scott% xargs
[14:13] <Keybuk> xargs: xargs.c:443: main: Assertion `bc_ctl.arg_max <= (131072-2048)' failed.
[14:13] <Keybuk> ...
[14:13] <Keybuk> didn't we fix this party?
[14:14] <seb128> Keybuk: upgrade your findutils
[14:14] <cjwatson> emgent: bug 228870: could you please say something more verbose than "Debian sync to Ubuntu" in sync requests?
[14:14] <Keybuk> seb128: that's pretty much what I was trying to do ;)
[14:14] <seb128> Keybuk: sudo apt-get install findutils
[14:15] <Keybuk> bad apt ordering I guess
[14:15] <seb128> right, that's what I was saying yesterday
[14:15] <cjwatson> emgent: in particular, the Ubuntu changelog has "Fix build failure with python2.5.
[14:15] <cjwatson> " which seems to have been dropped?
[14:15] <seb128> something needs to Pre-Depends on the new version or Breaks the old one
[14:15] <Keybuk> seb128: something about that dragged in debconf, which was what broke
[14:15] <seb128> that's the issue I got yesterday, debconf was not installing
[14:16] <cjwatson> it can't be Pre-Depends
[14:16] <cjwatson> it's not possible
[14:16] <seb128> after a sudo apt-get install findutils that was alright
[14:16] <cjwatson> findutils already Pre-Depends libc6; if libc6 Pre-Depends findutils then the world will implode
[14:16] <cjwatson> has to be Breaks
[14:16] <seb128> ok, so libc6 needs to Breaks on the old one, not sure if apt is smart enough to handle that then
[14:16] <Keybuk> pitti: did you do the sysvutils jig?
[14:16] <seb128> because they get updated in the same run
[14:17] <pitti> Keybuk: 'jig'?
[14:17] <seb128> but I'm not sure if Breaks assure than findutils will be unpacked before other things
[14:17] <cjwatson> I suppose it might need to be Conflicts although I have a bad feeling about Conflicts / Pre-Depends loops
[14:17] <seb128> mvo: ^
[14:17] <Keybuk> pitti: what we called sysvutils, Debian called something else
[14:17] <pitti> Keybuk: I didn't upload it yet, due to the Conflicts: to the current devmapper; I didn't do that one yet, since I became aware of teh hardy.1 freeze yesterday (OMGkittens)
[14:17] <cjwatson> it'd be OK until findutils' Pre-Depends needs to be bumped due to shlibdeps
[14:17] <pitti> Keybuk: yes, I did that transition
[14:17] <cjwatson> then upgrades from hardy would be absolutely wedged (if we used Conflicts)
[14:18] <pitti> Keybuk: transitional sysvutils package, and sysvinit-utils C/R/P: sysvutils (<<) and all that
[14:18] <Keybuk> I never really worked out _why_ they changed the name ;)
[14:18] <Keybuk> just Debian being contrary I guess
[14:18] <cjwatson> the Pre-Depends is at least theoretically necessary since findutils is Essential
[14:20]  * pitti reads -changes@... c'mon Keybuk, bump dbus to ubuntu20!
[14:20] <Keybuk> ubuntu20?
[14:21] <Spads> Keybuk: presumably that's when dbus gets rounded corners and tag clouds, like in Web Twenty
[14:21] <YokoZar> What's the current status of most of the blueprints drafted at UDS?  I'm trying to find a good way to tell launchpad to list them, but https://blueprints.edge.launchpad.net/sprints/uds-intrepid  lists none of them
[14:21] <pitti> Keybuk: with the current upload pace you should get there by tonight :)
[14:21] <mvo> seb128: a breaks will only deconfigure it. is it enough to upgrade from current dapper to intrepid to trigger the bug?
[14:21] <Keybuk> lol
[14:22] <cjwatson> mvo: deconfigure> bugger
[14:22] <seb128> mvo: hardy to intrepid is enough
[14:23] <seb128> mvo: the hardy xargs crash when using the intrepid libc6
[14:23] <seb128> mvo: and basically libc6 is installed first and then random things try using xargs before having the intreprid findutils unpacked
[14:24]  * mvo nods
[14:24] <asac> norsetto: ok done
[14:24] <cjwatson> oh, I know
[14:25] <cjwatson> *thinks* oops, no I don't. Whoops
[14:25] <cjwatson> I thought a stricter Pre-Depends in findutils would do it but I'm on crack
[14:25] <StevenK> You can't use the hardy findutils with the intrepid libc6, since they have different assertions about command line length
[14:26] <cjwatson> the problem is that at some point intrepid (or later)'s findutils may need some symbol in a newer libc6
[14:26] <cjwatson> at which point a Conflicts will mean *neither* order satisfies
[14:26] <Keybuk> gnargh
[14:26] <Keybuk> annoying I can't get the new devscripts
[14:26] <Keybuk> because that drags in the new Perl
[14:26] <Keybuk> which drags in PAIN
[14:27] <pitti> Keybuk: local rebuild? I don't think it actually needs the new perl?
[14:28] <norsetto> asac: I guess you still haven't got my email?
[14:30] <asac> norsetto:  *sigh* ... maybe you have another mail account? what kind of mail is it? did you send it to both email accounts from me?
[14:30]  * norsetto hit the wall with his head ... repeatedly
[14:30]  * asac scratches head
[14:30] <asac> norsetto: maybe ftp the mbox file :) ?
[14:31] <norsetto> asac: ip?
[14:31]  * erUSUL already loosed oo.org in the morning now it has loosed firefox3. He knows that proposed is likely to break things but come on
[14:31] <mvo> cjwatson: hm, wouldn't a simple depends: findutils (>= fixed-version) be enough? all we need is that findutils is unpacked and that should be guranteed. we have a dependency on findutils then of course in libc6
[14:31]  * mvo tests this theory
[14:31] <seb128> mvo: depends doesn't assure any unpack order, does it?
[14:31] <cjwatson> strictly (per policy) Depends says nothing about unpack order, but you know more about how apt would treat it than I do
[14:32] <mvo> they will be unpacked in the same dpkg run. that should be fine as apt will split it into unpack/configure and when xargs is required in configure all unpack was performed (that is the theory that I now need to test :)
[14:33] <mvo> s/unpack/unpacking/
[14:33] <cjwatson> provided xargs isn't needed in a prerm
[14:33] <cjwatson> that was the problem here, I think; debconf.prerm used xargs
[14:33] <mvo> meh, right
[14:34] <YokoZar> seb128: if we need a specific order we have to make a chain of pre-depends right?  Eg pacakage 3 pre-depends on 2 which pre-depends on 1 etc
[14:35] <seb128> YokoZar: <cjwatson> findutils already Pre-Depends libc6; if libc6 Pre-Depends findutils then the world will implode
[14:35] <pitti> doko: so I should remove gcc-defaults from hardy-proposed?
[14:36] <cjwatson> and findutils Pre-Depends libc6 because of the rule that Essential packages have to work when unconfigured
[14:36] <pitti> doko: it says "Update release number for the binary gnat packages. LP: #227184.
[14:36] <doko> pitti: no, why?
[14:36] <cjwatson> in general Essential packages have to use Pre-Depends rather than Depends for things they need in order for their essential components to work
[14:36] <pitti> doko: so if this is valid at all, the bug # is wrong, so I reject it
[14:37] <doko> pitti: ahh, you did ask for 27184
[14:37] <cjwatson> (though I don't think this is especially well-documented; it falls in the "ancient lore" category)
[14:37] <pitti> doko: right, that's what the changelog says; but that bug is very confusing, having a soyuz and a gcc-defaults tasks
[14:37] <doko> pitti: no, please accept it
[14:37] <pitti> task
[14:37] <pitti> doko: it's already in -proposed
[14:37] <pitti> doko: I mean for verification and -updates
[14:38] <pitti> it's sitting there for three weeks without anyone giving feedback, since it refers to the wrong bug, etc.
[14:38] <smagoun> asac: Do you have a few minutes to discuss midbrowser bug #230994?
[14:38] <doko> pitti: no, you did write 27184 in the first place, not 227184, therefore my confusion
[14:38] <pitti> doko: ah, sorry
[14:38] <asac> smagoun: is that a gconf issue?
[14:38] <YokoZar> Sorry if this sounds like a silly question, but I can't seem to find any information about the blueprint lifecycle for intrepid (eg, when do they need to be drafted by?  When does the technical board meet to approve, etc.)
[14:39] <smagoun> asac: I'm not sure. It's the problem in which the default homepage is the contents of midbrowserconfig.properties, i.e. "#Do NOT localize or otherwize change these values..."
[14:39] <smagoun> asac: In the bug it's labeled as being a proxy problem, but we see it without configuring a proxy. I want to know whether you know what it is, and whether there's a workaround.
[14:39] <asac> smagoun: i think the http proxy thing is done through system-prefs (aka gconf) ... i remember that jimmy added homepage to the set of settings synched from gconf.
[14:40] <asac> smagoun: can you reproduce this right now?
[14:40] <lukehasnoname> I don't know yokozar.
[14:41] <smagoun> asac: I can, yes. I have xulrunner-1.9 1.9~b5+nobinonly-0ubuntu4~8.04.0mt1.ume804 and midbrowser 0.3.0b5a-7-0ubuntu1
[14:41] <doko> pitti: the real fix is mentioned in https://bugs.edge.launchpad.net/soyuz/+bug/217661 which already is verified. 227184 is verified "by itself" because it did enter the archive without soyuz complaining
[14:42] <asac> smagoun: ok, please open midbrowser when you see this bug and open about:config
[14:42] <asac> is config.use_system_prefs enabled?
[14:42] <pitti> doko: I don't see it's verified? we only got one comment, but at that point the package wasn't even built yet, so that can't possibly have referred to the hardy-proposed .debs
[14:43] <smagoun> asac: config.use_system_prefs is enabled, yes
[14:43] <smagoun> asac: btw I don't see any midbrowser gconf keys in gconf-editor
[14:43] <asac> smagoun: please run
[14:43] <asac>  gconftool-2 -S homepage
[14:43] <asac> what do you get?
[14:44] <doko> pitti: well, the symlink is gone ...
[14:44] <smagoun> asac:  /desktop/hildon/htmlhomeplugin/homepage = flash_home.html
[14:44] <smagoun>  /schemas/desktop/hildon/htmlhomeplugin/homepage = Schema (type: `string' list_type: '*invalid*' car_type: '*invalid*' cdr_type: '*invalid*' locale: `C')
[14:45] <asac> do you have the /apps/firefox/general/homepage_url key?
[14:45] <pitti> doko: I just want one written confirmation from anyone (can be you) that the actual .debs from -proposed install and work as intended
[14:45] <pitti> (to guard against miscompilations, and other strange things...)
[14:45] <smagoun> asac: I don't have /apps/firefox or /apps/midbrowser
[14:46] <doko> pitti: done
[14:46] <asac> smagoun: ok, what do you see in about:config for browser.startup.homepage ?
[14:46] <mvo> cjwatson: we may get away with the versionized depends, so far it looks promising
[14:47] <smagoun> asac: resource:///midbrowserconfig.properties
[14:47] <pitti> doko: thanks
[14:47] <asac> is that something modified or the default setting?
[14:47] <asac> e.g. try right click and use Reset
[14:48] <smagoun> asac: it says it's 'user set'. If I reset, it goes back to 'file:///etc/midbrowser/welcome.html'
[14:48] <asac> ok
[14:48] <asac> thats interesting
[14:48] <asac> can you try if you ever get back to that bogus value?
[14:48] <asac> e.g. by disabling proxy, and so on?
[14:49] <asac> how old is your midbrowser profile?
[14:49]  * calc is doing a preliminary OOo 2.4.1rc1 build on i386 to verify it fixes the build failure
[14:49] <smagoun> asac: I will try. We don't use a proxy at all, it's never been enabled to my knowledge. My profile is about 12 hours old, I've trashed it a couple times trying to figure this one out.
[14:50] <asac> smagoun: hmm
[14:50] <ffm> Hey, who's in charge of XO devel on the XO?
[14:50] <calc> negroponte?
[14:50] <cjwatson> YokoZar: spec writing deadline is Thursday (next week)
[14:50] <asac> smagoun: please run find /usr/lib/midbrowser/ -name \*.js | xargs grep midbrowserconfig.properties
[14:51] <asac> is there anything like that in the system install?
[14:51] <ffm> s/xo devel/ubuntu/
[14:51] <smagoun> asac: That comes back with no results
[14:52] <ffm> calc: I have an XO (i'm really deep into the OLPC project) and I'm wondering if I can help with the port.
[14:52] <smagoun> asac: there is a midbrowserconfig.properties in /usr/lib/midbrowser
[14:52] <calc> ffm: oh, sorry i have no idea about an ubuntu port
[14:52] <asac> smagoun: yes. thats for sure. still its open why we end up using that one
[14:53] <asac> smagoun: is that a language pack issue?
[14:53] <asac> e.g. do you have language-pack-gnome-zh installed? did you ever run midbrowser in chinese?
[14:53] <smagoun> asac: I have heard a rumor that it is a language pack issue, but I don't know any details
[14:54] <smagoun> asac: I do have language-pack-gnome-zh and language-pack-gnome-zh-abse installed
[14:54] <doko> asac: ping?
[14:54] <asac> doko: yes?
[14:54] <sistpoty|work> doko: can you take a look at bug #202869 please?
[14:54] <YokoZar> cjwatson: thank you
[14:57] <ffm> Hey, is there a canonical channel?
[14:57] <mvo> cjwatson: yes, I'm pretty certain the depends will be fine. apt behaves different for essential packages and ensures that they get configured immedately. this gives us in effect the ordering we want (because findutils and libc6 will be unapcked in different runs of dpkg and findutils will go first because of the dependency)
[14:58] <cjwatson> ffm: what do you mean?
[14:58] <ffm> cjwatson: Well, sabdfl said he'd want to support Ubuntu on the XO. So, I'f like to help.
[14:58] <ffm> cjwatson: Since nobody here knows, I'm wondering where to go next.
[14:58] <cjwatson> I'm not sure why that would need a Canonical channel rather than an Ubuntu channel
[14:59] <cjwatson> I suspect nobody here knows because you might be the first one actively working on the XO in particular :-)
[14:59] <cjwatson> there have been discussions about systems like the XO and ones with a similar form factor, but that doesn't mean there's an active development group yet
[15:01] <cjwatson> ffm: to answer your previous question, there are Canonical IRC channels but they're generally on a private server; however I expect any XO development project would be done as part of Ubuntu and thus public
[15:03] <smagoun> asac: do you know what the issue is with the language pack? Seems odd that it would break the homepage.
[15:04] <asac> smagoun: thats what i would like to figure out
[15:05] <asac> smagoun: can you uninstall those lang packs, then start midbrowser with fresh profile and see if you can still reproduce
[15:05] <asac> if not, install lang packs and let me know if the issue reappears
[15:05] <smagoun> asac: doing that now..
[15:05] <asac> drop that info in the bug and let me know. if we know what is needed i can look closer
[15:05] <mvo> seb128, cjwatson: I added the required line to bug #234345 - do you think a upload just with that change is required?
[15:05] <asac> thanks
[15:06] <cjwatson> mvo: I don't see your comment in the log - but yes, I think it's worth fixing fairly soon in order to reduce confusion
[15:08] <mvo> cjwatson: sorry, now my comment is added (slowness on my part)
[15:10] <cjwatson> mvo: yeah, I think that's reasonable, if ugly :-)
[15:10] <cjwatson> (but the least ugly solution apparently)
[15:10] <cjwatson> can we have comments in control files?
[15:11] <pitti> pedro_: do you have a dapper test system, too? I already tested bug 69510 (that gzip still works), but since I'm the uploader, my word is not good enough
[15:11] <pitti> cjwatson: yes, # works
[15:11] <mvo> cjwatson: yeah, no question that its ugly :/ - comment in control files> no idea, I have never tried that :)
[15:11] <pitti> I commented out packages in debian/control before
[15:12] <mvo> nice
[15:12] <mvo> cjwatson: do you want to upload it or shall I do it?
[15:15] <seb128> mvo: looks good to me too
[15:17] <BenC> Any archive admins awake, and can process linux-ports into intrepid, please?
[15:17] <pitti> seb128: what do we do about bug 206227?
[15:18] <pitti> seb128: since the new version doesn't work worse than the previous one, we could copy it, but leave the bug open?
[15:18] <ffm> Any plans to backport FF3 to dapper?
[15:18] <seb128> pochu, soren: ^
[15:18] <pedro_> pitti: sadly i don't, lack of space.. sorry
[15:19] <seb128> pitti: I would copy, it seems to fix other issues and that would allow maybe to do an incremental update to fix this one next
[15:19] <pitti> pedro_: no problem
[15:19] <pochu> pitti: it fixes the other two issues?
[15:19] <pochu> pitti: if so, we could remove the patch for #206227 and leave the other two
[15:19] <pitti> pochu: one bug is verified, the other didn't get a comment
[15:19] <pitti> pochu: we can copy it as a whole, or throw it away as a whole, not remove the patch and assume that verification results still hold for a new upload
[15:20] <seb128> the patch might fix some issues but not all, I would just copy the update since nobody noticed a regression
[15:20] <seb128> and try to ping upstream about the remaining case
[15:20] <pochu> pitti: the one not verified is 207205 right? that's probably because apport is now disabled so people wasn't noticing it anymore...
[15:20] <pitti> seb128: right
[15:20] <pochu> pitti: as people reported it via apport
[15:20] <cjwatson> ffm: probably only if we're forced to by death of security support for FF2 before desktop support for 6.06 ends
[15:20] <cjwatson> ffm: it would be a lot of work
[15:21] <pitti> pochu: right, but even if it was enabled, apport doesn't report absent crashes :)
[15:21] <cjwatson> ffm: considering that there's only a year or so left to run
[15:21] <pitti> pochu: for this I'm mainly interested in collecting some "still generally works for me"
[15:21] <pochu> right
[15:22] <cjwatson> BenC: not putting 386 in ports then?
[15:22] <pochu> pitti: I'll see if I can get some more feedback about it then
[15:22] <pitti> pochu: that would be good, thanks
[15:22] <pochu> pitti: deadline tomorrow, right? so today for feedback...
[15:23] <cjwatson> mvo: do you have the source handy?
[15:23] <pitti> pochu: well, I don't think that we can't copy anything any more from tomorrow on
[15:23] <pochu> right, but for 8.04.1 :)
[15:23] <cjwatson> mvo: might want to commit to a branch of /~ubuntu-toolchain/ubuntu-toolchain/glibc-2.5-package
[15:23] <pitti> we need to be able to fix bugs in -updates regardless of the .1 freeze
[15:23] <pitti> I think the freeze mainly means "SRUs up to this date are guaranteed to make it to the .1 CDs"
[15:24] <pitti> pochu: ^
[15:24] <cjwatson> BenC: linux-ports accepted
[15:24] <BenC> cjwatson: It should be in there
[15:24] <pochu> pitti: ok. so as this is shipped in the CDs, if we make it for the deadline, great. Otherwise, let's just do it whenever we get more feedback
[15:24] <cjwatson> BenC: it wasn't in debian/control
[15:25] <cjwatson> nor apparently in debian/control.d/
[15:25] <BenC> cjwatson: looks like I missed a config option to have it in debian/control
[15:25] <BenC> cjwatson: I'll catch it on a follow-up upload, thanks
[15:25] <cjwatson> ok
[15:25] <mvo> cjwatson: I don't think I have commit access to this (I'm not part of ubuntu-toolchain) - but I can create a branch from it
[15:25] <cjwatson> yeah, I can pull it for you
[15:26] <pitti> pochu: also, since we'll build CDs from -proposed first, the deadline mainly applies to getting stuff into -proposed, not to -updates (from my POV)
[15:35] <wasabi> So, there ever going to be an official ubuntu dvd?
[15:37] <Pici> Whats wrong with the current dvd images?
[15:37] <cjwatson> like the ones sold on shop.canonical.com, let's say
[15:37] <cjwatson> not sure how they aren't official
[15:38] <lukehasnoname> I'm pretty sure they have those on the site.
[15:39] <cjwatson> (obviously the same as the downloadable version, it's just for when downloading a DVD-sized object is too painful)
[15:40] <lukehasnoname> http://ubuntu.osuosl.org/releases/releases/releases/releases/releases/releases/releases/releases/releases/releases/releases/releases/releases/releases/releases/releases/releases/releases/releases/releases/releases/releases/releases/releases/releases/releases/
[15:40] <lukehasnoname> I suppose that's an error?
[15:41] <Mirv> pitti/asac: 20080527 language packs in hardy-proposed still broken unfortunately (bug #219655)
[15:41] <cjwatson> not especially, just the sort of thing that happens when /releases is a symlink to .. for convenience
[15:41] <cjwatson> we don't care because all you can do is make extra pain for yourself ;-)
[15:42] <cjwatson> convenience> to cope with different people's mirror layouts
[15:46] <asac> Mirv: darn. i was sure i tested that. i have to go for some errands now. will look into fixing this later. thanks
[15:47] <Mirv> asac: yep, see you. rc1 in general works great, though.
[15:50] <Keybuk> pitti: is dhcdbdbdbdbdbd broken in some interesting way?
[15:50] <Keybuk> I'm getting dhcp, but NM never knows it
[15:50] <mvo> cjwatson: changes pushed to my branch, I'm doing a test build now to see if it works or if I got lost in the interessting buildsystem
[16:23] <slangasek> cjwatson: bug #234901> interesting in an "argh" sort of way, yes
[16:49] <emgent> heya
[16:57] <pitti> Keybuk: in hardy? not that I know of, works fine for me
[16:58] <Keybuk> pitti: maybe I just need a reboot
[17:00] <bdmurray> I apologize for all the ubuntu-bugs team e-mail
[17:04] <cjwatson> (defending against problems due to ChanServ going away, as per server notice)
[17:04] <jpds> stdin: there you go^
[17:04] <kirkland> bdmurray: jeez, mailbomb the messenger, huh?  :-)
[17:05]  * Mez hands cjwatson the superman cape
[17:17] <sabdfl> lukehasnoname: not so much an error as an attitude ;-)
[17:18] <Keybuk> doko: broken ooo in -proposed?
[17:20] <doko> Keybuk: -> calc, but I can have a look tomorrow if he's not yet back home
[17:20] <pitti> Keybuk: calc is already working on it
[17:20] <Keybuk> oh, right
[17:20] <Keybuk> my brain knew that
[17:21] <pitti> Keybuk: just takes two weeks for his test build to finish :-)
[17:21] <Keybuk> but clearly is over a year out of date
[17:26] <Keybuk> http://www.guardian.co.uk/technology/2008/may/22/internet.software
[17:26] <Keybuk> wow, I missed that one ;)  --  nice shot out of the window too
[17:27] <Amaranth> Keybuk: The view is not worth the hearing loss and pain going to that floor causes :P
[17:28] <kdean06> I've got a question for anyone of the kernel packagers. In packaging the kernel for a release, does Ubuntu use vanilla sources and patch as needed, or do you guys based the kernel package off of the Debian version?
[17:28] <Keybuk> Amaranth: going up isn't problem
[17:28] <Keybuk> it's when going down, and the lift doesn't stop ;)
[17:28] <Amaranth> Yeah, I went screaming all the way down
[17:28] <Keybuk> kdean06: --> #ubuntu-kernel   (though the answer is vanilla and patch)
[17:29] <Keybuk> Amaranth: you didn't visit the pool in Prague then?
[17:29] <kdean06> Thanks. :)
[17:29] <Amaranth> Keybuk: nope, didn't bring my shorts
[17:29] <Amaranth> Keybuk: and the height scared me :P
[17:30] <Keybuk> I used to be scared of heights
[17:30] <Amaranth> It scared the crap out of me when I noticed the windows that high up open
[17:31] <cjwatson> that photo at the top looks wrong somehow
[17:31] <Keybuk> Amaranth: only one of the windows at millbank opens, and that's in the emergency exit
[17:31] <cjwatson> look to the top left of Mark's laptop
[17:31] <Keybuk> cjwatson: I think it's because Mark's tray happens to cut a perfect line with the window ledge
[17:32] <Keybuk> so makes you think it's cut/pasted from two images
[17:32] <cjwatson> ah yes, that's it
[17:32] <Keybuk> (and isn't that Pete's laptop? :p)
[17:32] <cjwatson> took me a minute of staring at it
[17:38] <pitti> cjwatson, doko: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=483399#10 is an interesting question; why did we do it that way?
[17:39] <cjwatson> I think it saved creating another init script, which isn't something that comes for free
[17:39] <pitti> cjwatson: if it's the only thing that's special to the cell, I agree
[17:39] <cjwatson> been a while though
[17:40] <pitti> I just don't know which other bits we need for it
[17:40] <cjwatson> there are other things, there's an SPU support package
[17:40] <cjwatson> I don't actually recall for sure, doko might
[17:42] <pitti> cjwatson: ok, thanks
[17:42] <pitti> apt-cache search cell spu only gives the toolchain
[17:44] <cjwatson> libspe2 or whatever it is
[17:45] <cjwatson> I think maybe we didn't want to put an init script in a library package
[17:45] <cjwatson> and elfspe2 isn't required
[17:45] <doko> hmm, it was late in the release cycle, so we didn't want to touch many things. maybe libspe2 was not in main?
[17:45] <cjwatson> could be
[17:45] <pitti> right, they don't belong into SONAMEd lib packages
[17:46] <pitti> if nothing else, it must be a separate spe-support package
[17:46] <pitti> but if it would only contain the init script to mount /spu, that would be quite expensive
[17:46] <pitti> doko: so if we don't have something like spu-support, I can write back with a qualified argument
[17:46] <pitti> I just didn't know whether we do
[17:46] <pitti> that's what you get when you forward patches from other people upstream :-)
[17:47] <doko> pitti: you might want to ask arthur- how this is now solved in debian
[17:48] <pitti> arthur-: ah, you are dealing with Cell stuff in Debian? any idea whether http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=483399 is solved more elegantly in Debian somehow?
[17:48] <pitti> doko: thanks
[17:52] <pitti> ArneGoetje: I mailed back and CC'ed you
[17:52] <pitti> erm, arthur- ^, sorry
[17:54] <Keybuk> pitti: it seems to be something wrong with dbus :)
[17:54] <Keybuk> since bzr dbus-broadcast breaks too
[17:55] <pitti> Keybuk: hah; I'd bitch the last uploader if I were you
[17:55] <Keybuk> pitti: I haven't installed that package on here ;)
[17:56] <neerfri> Hi guys ! Who should I talk to here about starting to contribute in ubuntu development ?
[17:56] <geser> pitti: do you know why apache2-mpm-itk was rejected again?
[17:56] <pitti> geser: yes, I commented in the SRU bug
[17:56] <pitti> geser: there's a new apache in -proposed, so I guess it needs a new version number again?
[17:58] <pitti> Keybuk: wrt. bug 89752, do you have any idea why the 'ac' module isn't udev-automagic-loaded already when checkroot.sh runs?
[17:58] <zul> geser: for what its worth I dont think there wont be anymore apache uploads to -proposed for a while
[17:59] <geser> pitti: as this is a no-change rebuild wouldn't it be enough to hold the apache2-mpm-itk upload until apache2 got build in -proposed so it would pick the new version during build?
[18:02] <pitti> geser: ah, so it doesn't actually depend on the version of -itk itself, just on the version of the build dependencies?
[18:02] <pitti> geser: in this case I can unreject it
[18:04] <geser> pitti: during build the dependency on apache2.2-common gets added to apache2-mpm-itk
[18:04]  * lamont glares at libnss
[18:04] <lamont> valgrind id lamont on a stock hardy system --> ==21396== ERROR SUMMARY: 3 errors from 3 contexts (suppressed: 35 from 1)
[18:05] <lamont> specifically, invalid read size of 4, times 3
[18:07] <Keybuk> this "few minutes" is taking a long time ...: )
[18:08] <Keybuk> pitti: hmm
[18:08] <Keybuk> the bug number is very old
[18:08] <Keybuk> old enough that it probably predates the acpi subsystem
[18:08] <Keybuk> in fact, _I_ didn't find out about the acpi subsystem until last week ;)
[18:08] <geser> pitti: it's really only a no-change rebuild so apache2-mpm-itk gets the right dependency on apache2.2-common with which it was build
[18:09] <pochu> neerfri: hi! have a look at https://wiki.ubuntu.com/MOTU/GettingStarted
[18:09] <Keybuk> pitti: ie. the module has never been automatically loaded in the past
[18:09] <Keybuk> but probably is automatically loaded in hardy
[18:10] <Keybuk> ironically the patch there is _WRONG_ for hardy, and right for the others :p
[18:21] <pitti> Keybuk: heh, ok
[18:21] <Keybuk> in fact, in intrepid, I really must look at that whole thing
[18:22] <Keybuk> because we may be able to get rid of most of our manual modprobes
[18:22] <Keybuk> and in fact, things like our pnp loading hack
[18:23] <Ng> is pnp useful for anything in the post ISA world?
[18:24] <geser> pitti: should I upload the last apache2-mpm-itk upload again or can you unreject it?
[18:24] <pitti> geser: I can unreject it
[18:26] <pitti> geser: done
[18:26] <neerfri> pochu: thanks, I'm a programmer (mostly ruby but basically everything needed), do you think MOTU is the right starting point for me ?
[18:27] <pochu> neerfri: I think so
[18:27] <neerfri> pochu: OK, I'll have a look into it, thanks !
[18:27] <pochu> neerfri: MOTU is mostly for packaging though
[18:28] <pochu> neerfri: there's #ubuntu-motu if you have questions, and https://wiki.ubuntu.com/MOTU/TODO if you are looking for things to do ;)
[18:28] <pochu> neerfri: or alternatively, ask in -motu and someone will probably tell you things you can do
[18:29] <neerfri> pochu: I know, I thought there might be a work in the programming area that needs to be done, and I assume less people can handle it.
[18:30] <neerfri> pochu: but if you say that's the best place to start I don't mind taking a shot at it
[18:30] <mathiaz> neerfri: if you've got some ruby skills, there are some specs written up by the Server team dealing with Ruby on Rails.
[18:30] <pochu> neerfri: there's also some Ubuntu specific apps (update-manager and ubiquity for example), if you prefer to code
[18:31] <mathiaz> neerfri: you could help flushing out the best way to provide RoR in ubuntu
[18:31] <geser> pochu: they are written in ruby? I assumed it was python.
[18:31] <pochu> geser: nope, Python
[18:33] <geser> neerfri: e.g. you could check if there are easy fixable bugs in the ruby packages
[18:34] <neerfri> thanks, RoR should be my field, have any links who should I contact to collect my goals ?
[18:35] <neerfri> ﻿mathiaz: which specs ? where can I find them ?
[18:35] <Amaranth> cjwatson, Keybuk: ChanServ is back
[18:37] <mathiaz> neerfri: https://blueprints.launchpad.net/ubuntu/+spec/rubyonrails
[18:37] <mathiaz> neerfri: the spec is handled by the Ubuntu Server Team - https://wiki.ubuntu.com/ServerTeam/
[18:38] <neerfri> ﻿mathiaz: thanks ! I'll have a look at that, I think it will get me started...
[18:38] <mathiaz> neerfri: great! drop by #ubuntu-server if you have more questions or comments.
[18:38] <Keybuk> holy crap
[18:38] <Keybuk> they _really_ changed it ;)
[18:39] <pitti> Keybuk: what's 'they' and 'it'?
[18:39] <Keybuk> pitti: chanserv
[18:40] <pitti> ah
[18:40] <Keybuk> the way access is done has completely changed
[18:40] <Keybuk> and it seems to have lost the "channel password" feature
[18:40] <Amaranth> eep
[18:41] <cody-somerville> what?
[18:47] <Keybuk> it's gone all eggdrop ;)
[18:48] <Keybuk> -ChanServ- You have access flags +votsriRfAF on #ubuntu-devel.
[18:56] <cody-somerville> weirdness.
[18:57] <pochu> anybody uses vinagre and is in hardy? :)
[18:59] <Riddell> pitti: not able to MIR soprano/decibel?
[19:08] <cjwatson> Ng: as Keybuk pointed out when I asked the same question at UDS, little things like PS/2 keyboards are wired up by PNP
[19:13] <Keybuk> heh
[19:13] <Keybuk> and AT keyboards
[19:13] <Keybuk> and your serial controller
[19:13] <Keybuk> and your parallel port
[19:13] <Keybuk> THANK YOU MICROSOFT YOU TOOLS
[19:14] <cody-somerville> Keybuk, I think I'm ready.
[19:19] <asac> norsetto: cheers! i have a mail ;)
[19:23] <calc> new ooo 2.4.1rc1 builds fine on i386 :) so i will be uploading it soon
[19:23] <calc> need to rebuild on amd64 and do a few more minor things before upload though
[19:23]  * calc bbl
[19:23] <emgent> cool :P
[19:34] <evand> Is there a rough standard for versioning native package hardy-proposed uploads?  For example, if I have 1.1 in hardy and 1.2 in intrepid, and I want to pull some changes from intrepid to hardy, should I version with 1.2~8.04.1 or something else entirely?
[19:40] <geser> evand: how about 1.1ubuntu0.1?
[19:45] <norsetto> asac: halleluia!!
[19:46] <JamesG> Hi, I have a question about using valgrind which I have a feeling may be a bit beyond most of the people in the main channel. Is it appropriate to ask about it in here instead?
[19:48] <norsetto> jamesG: this is not a support channel, but if there is somebody that can asnwer your question, they will most probably do it
[19:50] <JamesG> Fair enough. The problem I'm running into is hopefully pretty simple. I'm doing performance testing with apache2, and I'm running it through valgrind using callgrind, but I'm not getting any output written to the log files. I've installed the debug symbols, so I'm really not sure what's going on.
[19:55] <JamesG> Hm, I may have solved it
[19:59] <evand> geser: that works
[19:59] <evand> thanks
[20:05] <kirkland> Keybuk: Hey, I just posted a debdiff that fixes an old bug, Bug #32216.  I'm looking for core-dev sponorship of the fix.
[20:09] <lool> YEAH for launchpad searches
[20:10] <lool> I can find bugs way faster than with https://bugs.launchpad.net/bugs/+bugs?field.searchtext=foo for some reason
[21:19] <gp> hi
[21:52] <cjwatson> geser: please note my correction in bug 125837
[22:00] <|DuReX|> Is there a way to debug a complete system lock ?
[22:00] <norsetto> Heimdal Kerberos seems almost like a sickness
[22:01] <emgent> night people, i go to sleep
[22:01] <norsetto> night emgent
[22:01] <geser> cjwatson: thanks. Good to know. Does the order of the alternatives matter?
[22:02] <|DuReX|> Starting HTTP Proxy Server...Please wait(MAX = 5 minutes)
[22:02] <|DuReX|> then complete system lock :s
[22:16] <kirkland> cjwatson: slangasek: evand: you guys seem to have uploaded grub relatively recently...  I have a debdiff looking for sponsor, fixes bug #32216
[22:16] <slangasek> kirkland: grub is maintained in bzr, please provide a mergeable branch we can pull from
[22:16] <kirkland> slangasek: okey doke
[22:30] <kirkland> slangasek: i'm fumbling around here https://edge.launchpad.net/ubuntu/+source/grub but I'm not finding a branchable bzr repo
[22:31] <slangasek> kirkland: lp:~ubuntu-core-dev/grub/ubuntu
[22:31] <kirkland> slangasek: cool, thanks
[22:46] <cjwatson> geser: Debian's buildds always take the first; Ubuntu's buildds will take the first that's satisfiable
[22:56] <kirkland> slangasek: okay, how's this?  lp:~kirkland/grub/grub.32216
[23:10] <|DuReX|> mmm
[23:10] <|DuReX|> When I run the httpd tool BEFORE x-windows/gnome loads, it seems to work, once I run it with gnome loaded, it crashes
[23:11] <|DuReX|> but if I loaded it, shutdown it, load gnome, and then run it again, it works
[23:11] <|DuReX|> wtf :X
[23:16] <|DuReX|> getting errors :P
[23:16] <|DuReX|> BUG: scheduling while atomic: archhttp64/7146/0x1000000001
[23:17] <|DuReX|> BUG soft lockup - CPU#0 stuck for 11s! [archhttp64:7146]
[23:17] <pochu> |DuReX|: please, report that at launchpad. this is not the right place
[23:18] <pochu> !bugs
[23:18] <|DuReX|> oki
[23:18] <cjwatson> if you feel it's a kernel bug that you can help with solving (i.e. you're looking for patch review or similar), #ubuntu-kernel would be the right place then
[23:20] <|DuReX|> btw, is there a way to stop that soft lockup
[23:20] <|DuReX|> without resetting ?
[23:20] <cjwatson> generally once you get a BUG entry in the log you might as well give up, reboot, and report it ASAP
[23:22] <cjwatson> even if the kernel manages to recover its state is generally a bit screwed
[23:24] <pochu> night all
[23:25] <cjwatson> the second of those messages means that the special watchdog thread on the first CPU didn't manage to get scheduled for (in processor terms) a near-eternity; this usually means that the kernel has got thoroughly stuck doing something else
[23:26] <cjwatson> presumably due to the first problem, but for that you want somebody who actually knows the scheduler rather than somebody who can read C code and guess at kernel semantics with a following wind ;-)
[23:27] <LydianKnight> good night to all, could I make a question about the latest kernel upgrade available with ubuntu 8.04 LTS? that's... 2.6.24-17
[23:28] <LydianKnight> I've been in the #ubuntu-kernel channel but nobody answered me, maybe this is a better place...
[23:28] <LydianKnight>  what I would like to know is if the latest kernel update is equal to the 2.6.24.7 kernel or it's a lower version, I keep looking at both cat /proc/version and the Makefile in the /usr/src/ hierarchy, but the only number I get is EXTRAVERSION = .3... what does this mean?
[23:28] <LydianKnight>  I need this piece of information to be able to make ubuntu serve as a compilation host for making a customized version of Linux, but I would like to use --with-kernel=current parameter, but I need to know if 2.6.24.7 and 2.6.24-17 are matching kernels or are different versions...
[23:29] <cjwatson> it's based on 2.6.24.3
[23:29] <cjwatson> (the information is in the changelog - /usr/share/doc/linux-image-2.6.24-17-generic/changelog.Debian.gz)
[23:29] <cjwatson>   * Merged 2.6.24.3
[23:29] <LydianKnight> oh, I see... thanks for the info :)
[23:30] <cjwatson> it'll differ in various ways anyway; the Ubuntu kernel is patched to various extents
[23:30] <cjwatson> distros generally don't ship completely vanilla kernels
[23:31] <LydianKnight> yes, I know, the only thing I expected is to be able to compile glibc with the --with-kernel=current to not make for any kind of compatibility or workarounds related to lower versions compared to the latest ones
[23:31] <LydianKnight> I'll have to compile a newer version, I'm afraid
[23:31] <LydianKnight> thanks anyway :)
[23:31] <cjwatson> I doubt you'll find much in the way of ABI differences between 2.6.24.3 and 2.6.24.7
[23:32] <cjwatson> do you know of anything to contradict me?
[23:32] <|DuReX|> https://bugs.launchpad.net/ubuntu/+bug/235889
[23:33] <LydianKnight> no, not really, just wanted to be sure I actually could do it without relying on lower versions, because my method for producing a custom OS is using mixed instructions for the LFS & CLFS books, hence my need for the kernel piece of info
[23:33] <cjwatson> --with-kernel=current only looks at the 2.6.24 part, as far as I can see
[23:34] <LydianKnight> not exactly, when I pass the configure flags it checks for the kernel version currently in use, it says something like: checking for kernel version... 2.6.24.7 ok
[23:34] <cjwatson> might be wrong, still digging my way through the m4 in glibc's configure.in
[23:35] <cjwatson> right, but that's when you're running a vanilla 2.6.24.7 kernel
[23:35] <LydianKnight> so under my current host, that's ubuntu, it will only do the search for the 2.6.24 part like you referred before?
[23:36] <cjwatson> I'm checking
[23:42] <cjwatson> right, I haven't actually test-run the whole thing, but from code inspection --enable-kernel=current should definitely be 2.6.24 on Ubuntu; also, while the message does say "checking for kernel header at least 2.6.24.7" (is that the one you meant?), it only actually cares about the 2.6.24 bit
[23:42] <cjwatson> which makes sense because that's all that gets exposed in the LINUX_VERSION_CODE define
[23:43] <cjwatson> /usr/include/linux/version.h just has:
[23:43] <cjwatson> #define LINUX_VERSION_CODE 132632
[23:43] <cjwatson> #define KERNEL_VERSION(a,b,c) (((a) << 16) + ((b) << 8) + (c))
[23:43] <LydianKnight> seems very reasonable, I hope it actually works, as the testing ground it's the chroot phase, if the kernels don't match I'll get a precious: error - kernel too old
[23:43] <cjwatson> and 132632 is (2<<16) + (6<<8) + (24)
[23:44] <LydianKnight> so the extraversions only means subtle corrections to the source tree not effecting the overall compilation process?
[23:46] <LydianKnight> well... I'll test tomorrow, let's hope for the best, thank you for your help :)
[23:46] <cjwatson> right
[23:46] <cjwatson> also
[23:47] <cjwatson> the newest kernel that glibc actually cares about right now (at least on i386) is 2.6.17, for the fallocate syscall
[23:48] <cjwatson> err, sorry, that should be 2.6.23 (hex != decimal)
[23:48] <cjwatson> so 2.6.24 vs. 2.6.24.y wouldn't matter even if it could detect it
[23:48] <LydianKnight> nice to hear :)
[23:48] <LydianKnight> I'll try then using this kernel for chrooting
[23:49] <LydianKnight> thanks ^_^
[23:56] <cjwatson> Keybuk: bug 235892 will surely screw you up as well
[23:58] <Keybuk> hmm
[23:58] <Keybuk> why does that break?
[23:59] <Keybuk> and why doesn't Fedora get bitten by this, grr
[23:59] <cjwatson> Keybuk: ${libdir}/dbus-1.0/include == /lib/dbus-1.0/include; dbus-arch-deps.h is in /usr/lib/dbus-1.0/include
[23:59] <cjwatson> !=
[23:59] <cjwatson> unless your question is less obvious than that :)
[23:59] <Keybuk> sed -e 's@-I${libdir}@-I${prefix}/%{_lib}@' %{buildroot}/%{_lib}/pkgconfig/dbus-1.pc > %{buildroot}/%{_libdir}/pkgconfig/dbus-1.pc
[23:59] <Keybuk> oh
[23:59] <Keybuk> they sed it
[23:59] <cjwatson> ah, I see