=== nxvl_ is now known as nxvl_work
=== nxvl is now known as Guest68601
=== nxvl_work is now known as nxvl
[03:18] <pipop> anyone here familiar with dual boot in Vista?
[03:18] <ion_> I’m not quite sure how that’s relevant to the development of Ubuntu.
[03:19] <pipop> oh, sorry
[04:46] <bliZZardz> pitti: hi..you around?
[04:47] <bliZZardz> pitti : apparently just realized that python has an interface(as in inbuilt module) to dbus by which handles to various events can be obtained - this is glorious!
=== LucidFox is now known as WebstripFox
=== WebstripFox is now known as LucidFox
[08:37] <orbisvicis> any reasons for packaging cdemu ?
[12:53] <maxb> mercurial in hardy-backports is currently not installable because the arch-any mercurial package has been placed into the archive but the depended-upon arch-all mercurial-common package is missing
[12:55] <maxb> https://launchpad.net/ubuntu/+source/mercurial/1.0.1-2~hardy1 shows the i386 build as "Successfully built  (NEW)" rather than "Successfully built  (DONE)"
[12:55] <maxb> What is the correct place to report this?
[13:03] <Hobbsee> jdong: ^
[13:03] <cjwatson> maxb: yes, that sort of thing happens sometimes when new packages are added - they need explicit archive admin approval to get into the archive. I've processed it now, thanks.
[13:03] <cjwatson> Hobbsee: jdong can't do anything about that
[13:03] <Hobbsee> oh, i'ts an archive admin job.
[13:04] <cjwatson> maxb: (may be an hour or two before the results of my action are visible)
[13:06] <maxb> cjwatson: Ah, thanks. I didn't think of it being "NEW" in that sense. But now I realize it is new to hardy, so it all makes sense. Do you think it's worth adding a note to the UbuntuBackports wiki page suggesting people check for this issue and note the need for the NEW-acceptance in the backport bug?
[13:07] <cjwatson> no, not particularly, it's a routine part of archive admin and not something backporters should need to worry about
[13:07] <maxb> ok
[13:07] <cjwatson> besides, it takes some time between archive admin processing the backport request itself (and hence the bug) and the binaries appearing for processing
[13:07] <cjwatson> so the bug wouldn't be a very good place for it anyway
[13:08] <cjwatson> I've processed the rest of the archive *-backports queues while I was at it
[13:09]  * ogra sighs ...
[13:09] <ogra> so if i want proper progress output from dd i have to send a USR1 signal regulary to it ...
[13:10] <laga> i read "dd i" as "d-i" and hoped you were working on that LTSP script ;)
[13:11] <ogra> thats doable by using a shell wrapper around my python gui that execs "watch -n1 -- pkill -USR1 ^dd$" before pening the gui and kills the watch after the gui is closed ...
[13:11] <ogra> anyone have a more elegant solution ?
[13:11] <ogra> *opening
[13:12] <laga> cjwatson: thanks for taking care of mercurial, i've had someone report this problem in the mythbuntu forums
[13:15] <laga> ogra: why don't you use python to send the signal?
[13:16] <ogra> laga, i'm not in my masochistic phase atm :) working on the LTSP udeb somewhat requires you to want to beat up yourself before starting :)
[13:16] <laga> oh, really. :)
[13:16] <ogra> laga, i thought about a gtk timeout or so, but thats still massively ugly
[13:17] <ogra> (and essentially the same)
[13:18] <ogra> though what bothers me is less the pinging in a certain frequency, but that it will affect all dd's that are currnently running
[13:19] <ogra> hmm
[13:19] <laga> well, did you spawn dd?
[13:19] <stgraber> ogra: if you start it with subprocess or something similar you can get the pid
[13:19] <stgraber> and then send the signal to that pid
[13:19] <ogra> i need its output, so i use subprocess.Popen
[13:19] <laga> it'd be surprised if you can't get the pid with that. or send signal
[13:19] <laga> s
[13:20] <ogra> you can get the pid ... but in a blocking way afaik ... i.e. after it finished
[13:20] <ogra> i would need it in advance, establish the pinger and *then* run dd
[13:21]  * laga goes to look at python docs
[13:21] <laga> anything is better than studying. ;)
[13:22] <stgraber> laga: :)
[13:22] <ogra> heh
[13:22] <stgraber> well, you are actually studying but probably not what you were supposed to study
[13:23] <laga> kinda, yes. python won't help me with phonetics. :)
[13:24] <laga> the subprocess docs are surprisingly unhelpful :)
[13:27] <bdrung_> cjwatson: Bug #37750 should be an duplicate of Bug #47238 and not the other way round. Do you agree?
[13:27] <ubottu> Launchpad bug 37750 in ubiquity "doesn't ask if BIOS time is in UTC" [Medium,Confirmed] https://launchpad.net/bugs/37750
[13:27] <ubottu> Launchpad bug 47238 in ubiquity "add UTC/local time checkbox (dup-of: 37750)" [Wishlist,Confirmed] https://launchpad.net/bugs/47238
=== bdrung_ is now known as bdrung
[13:28] <laga> ogra: well, "kill" in the os module might work..
[13:29] <cjwatson> bdrung: why do you feel that the direction matters?
[13:30] <ogra> there is some module to use procps i think, i'll look into that
[13:30] <cjwatson> bdrung: and no, I don't agree anyway
[13:31] <laga> ogra: also, os.process can return the PID, but subprocess can probably do the same
[13:31] <bdrung> the bug is that you cannot set the hardware clock to UTC or local time while installing. correct?
[13:31] <cjwatson> yes
[13:32] <bdrung> so it is a feature request to add an option to do it.
[13:32] <cjwatson> some bugs are resolved by adding features
[13:32] <cjwatson> in this case I regard it as a bug that the feature is not present
[13:33] <cjwatson> in any case, why would that make the direction of duplication important?
[13:33] <cjwatson> if you don't like the state of 37750, change it, rather than generating lots of confusing mail for little value by switching the duplication around
[13:34] <bdrung> ok, thats an argument
[13:34] <bdrung> is there someone working on this bug?
[13:34] <cjwatson> not at present
[13:38] <bdrung> adding a checkbox is no big work, so someone should do it. have a look at bug #239782.
[13:38] <ubottu> Launchpad bug 239782 in ubuntu "Time zone bug in Ubuntu (dup-of: 37750)" [Undecided,Incomplete] https://launchpad.net/bugs/239782
[13:38] <ubottu> Launchpad bug 37750 in ubiquity "doesn't ask if BIOS time is in UTC" [Medium,Confirmed] https://launchpad.net/bugs/37750
[13:40] <cjwatson> bdrung: thank you for your recommendation, but please bear in mind that we have many many things to do
[13:40] <cjwatson> the checkbox itself is not difficult but it comes with a requirement to test all the stuff behind it, which is actually rather complex and fragile
[13:41] <cjwatson> if you feel you can tackle it, then you're welcome to send a patch and we'll review it
[13:42] <bdrung> cjwatson: i know. if i had more time, i would have a look at it.
[13:42] <cjwatson> goes for so many things :)
[13:42] <bdrung> yes. :)
[13:43] <bdrung> my list with things i want to do is very long.
[13:43] <cjwatson> bear that in mind next time you ask why something hasn't been done ;-)
[13:45] <bdrung> if it's not done then it is your fault. i you have no time you have to recruit someone to do it. ;)
[13:46] <cjwatson> thank you for your kind remarks
[13:46] <cjwatson> they are, however, not terribly helpful
[13:46] <bdrung> this is why i add a smiley
[13:46] <cjwatson> that's not generally much of an excuse
[13:46] <cjwatson> "I was only joking"
[13:48] <laga> "stop bleeding now, please"
[13:52] <ogra> laga, stgraber https://launchpad.net/usb-imagewriter btw ...
[13:55] <stgraber> ogra: so that's a GUI for dd if=blah.img of=/dev/sdX ? Looks really good
[13:55] <laga> ogra: can't you simulate dd's functionality in python?
[13:55] <ogra> yeah, i was actually expecting it to be a lot more trivial than that bloat it became :)
[13:56] <laga> open image, open device node, copy 512 byte chunks?
[13:56] <ogra> laga, there are several options, yes, but none gives me any info about the current amount of copied data without really heavy hacking
[13:56] <laga> well, count the 512byte chunks? ;)
[13:57] <ogra> i would need to parse the stream throuh anything ... dd is reliable and proven ... so i decided to keep it as backend
[13:57] <cjwatson> same reason ubiquity doesn't just call cp -a ...
[13:57] <ogra> the only thing bothering me is the missing progress output ...
[13:57] <ogra> i tried sdd since that has such an option, but thats not much help either
[13:58] <ogra> (it drops dots on stderr for every written block
[13:59] <ogra> (but does that in one single line which is hard to parse at runtime)
[14:01] <laga> is it? can't you just get single bytes from stdin instead of reading the whole line?
[14:02] <cjwatson> I was going to say, what's wrong with .read(1)
[14:02] <laga> most of the programming i've done in the last three months has been in java, so i'm probably spoiled.
[14:02] <cjwatson> stderr is usually unbuffered
[14:02] <ogra> hmm
=== evalles_ is now known as effie_jayx
=== asac_ is now known as asac
=== luisbg_ is now known as luisbg
=== edson is now known as epct
=== Kopfgeldjaeger2 is now known as Kopfgeldjaeger
=== geser_ is now known as geser
[19:55] <tgm4883_laptop> I'm looking at having more options during install for partitioning (more than just guided and manual).  I've tried adding custom recipes in the recipes folder as well as preseeding them, but neither way makes them show up in ubiquity during partitioning.  Could someone at least point me in the right direction?
[19:56] <laga> cjwatson: ^^ aren't you the ubiquity guy?
[20:13] <ogra> laga, evand is
[20:17] <emgent> hello there
[20:20] <ogra> emgent, hey, something to promote for the netbookers ... https://launchpad.net/usb-imagewriter it needs translators and code contributions (TODO included) :) a package sits in the intrepid NEW queue
[20:20] <ogra> (there are screenshots linked from the LP site)
[20:23] <laga> tgm4883_laptop: you need to bother evand ;)
[20:23] <tgm4883_laptop> laga, will do, thanks
[20:24] <emgent> ok nice ogra
[20:25] <emgent> ogra: py+GTK ?
[20:25] <ogra> and glade, yes
[20:25] <laga> ogra: how did you solve the progress bar
[20:26] <emgent> ok nice
[20:26] <ogra> some shell that should be replaced by python
[20:26] <laga> yuck :)
[20:26] <ogra> laga, nope, i wrapped a shellscript around it for now so it works for a start ....
[20:26] <laga> yeah, still yuck. ;)
[20:27] <ogra> its one of my hit and run projects that i do for fun ... i have many of these that only last a weekend and produce proof of concept code for others to enhance ;)
[20:27] <ogra> http://people.ubuntu.com/~ogra/LightBrowser/ or http://people.ubuntu.com/~ogra/MightyMailApp are such things :)
[20:28] <laga> ogra: nice that you pushed it into intrepid then.
[20:28] <ogra> well, it does the job
[20:28] <laga> and thanks for the ltsp-build-client progress bar we stole ;)
[20:28] <ogra> heh
[20:28] <ogra> feel free :)
[20:30] <ogra> but unlike the two others above i want the usb-imagebuilder to actually be used ... having to tell people who want to install a netbook or mobile device to use dd in a console just feels odd :)
[20:30] <ogra> hese are typically endusers and should get a gui for the task
[20:30] <ogra> *these
=== Amaranth_ is now known as Amaranth
[21:36] <bigon> rmadison libtotem-plparser10
[21:36] <bigon> libtotem-plparser10 | 2.22.2-0ubuntu1 |         hardy | amd64, i386
[21:36] <bigon> libtotem-plparser10 | 2.22.3-0ubuntu1 |      intrepid | amd64, i386
[21:36] <bigon> libtotem-plparser10 | 2.22.3-0ubuntu2 | hardy-updates | amd64, i386
[21:37] <bigon> the version in hardy-update is greater than the version in intrepid
[21:42] <Nafallo> indeed
[21:43] <geser> I guess it gets fixed when totem get updated to 2.23.x
[21:47] <bigon> oh right
[21:47] <bigon> btw brasero needs a rebuilt
[22:46] <lool> bigon: This happens commonly; some new upstream releases of GNOME updates are first pushed to hardy-updates while we directly jump to the dev release for intrepid