[09:09] <CIA-33> ubiquity: evand * r3430 ubiquity/ (50 files in 8 dirs):
[09:09] <CIA-33> ubiquity: Merged Michael Terry's plugins branch (LP: #419989). See
[09:09] <CIA-33> ubiquity: http://wiki.ubuntu.com/Ubiquity/Plugins for instructions on writing
[09:09] <CIA-33> ubiquity: new plugins.
[09:13] <evand> cjwatson: may I request permission to use one of your previous rejection notices as a template for further rejections?
[09:13] <evand> "Membership of this team confers commit access to parts of the installer, so it's only granted to people with a track record of sending good patches. Feel free to reapply after you've had a reasonable number of patches accepted."
[09:14] <ogra> evand, hey
[09:15] <ogra> evand, is there a way to make usb-creator only use it's dd functionallity ? we have the prob that it wont be usable on armel because syslinux isnt available, so i thought i'd ask if there is a way to use it without the syslinux parts before i unseed it ;)
[09:16] <cjwatson> evand: yes
[09:26] <evand> ogra: as in just dd an image to the disk, or mount the vfat filesystem, copy the files, but don't install the bootloader?
[09:26] <evand> cjwatson: thanks
[09:26] <ogra> evand, just as in dd an image to the disk
[09:27] <evand> ogra: that option is slightly broken in the devicekit backend (but works just fine in the windows backend), I'm fixing it today.
[09:27] <ogra> i'm aware it work be able to do all the stuff it does on i386, but if there is any use for it on armel i'd like to keep it
[09:28] <evand> You can either add a disk image via the Other... button or by passing the path to it on the command line using the -i option
[09:28] <ogra> hmm, you are not understanding what i mean :)
[09:28] <evand> ah, apologies
[09:28] <ogra> on armel we ship ubuntu-desktop
[09:28] <ogra> in ubuntu-desktop we seed usb-creator
[09:29] <ogra> usb-creator cant do its normal function (create a usb key from iso) because on armel syslinux isnt available
[09:29] <ogra> but usb-creator can act as dd frontend
[09:30] <ogra> if there is a way to make it act *only* as dd frontend on armel desktops we can still use it there
[09:30] <evand> hrm
[09:30] <ogra> if there is not, i need to unseed it on armel because it is uninstallable without syslinux
[09:31] <ogra> its not the end of the world to unseed it, but i wanted your opinion
[09:31]  * evand thinks of the best way to accomplish that
[09:31] <ogra> and if there would be some kind of switch we'd happily leave it in as dd frontend
[09:32] <ogra> dpkg-architecture could tell you you are on armel and switch off the iso writing behavior ... but its some work to add such a check i guess
[09:35] <evand> I wonder what the best way to replicate preprocessor ifdefs in a pygtk application is.
[09:35] <evand> ogra: I'll see what I can come up with
[09:36] <ogra> evand, ok, tell me what you decide, the deps need arch specific adjustment as well if you really do it
[09:36] <evand> my current thought is to have another desktop file that gets installed instead of the normal one in usb-creator-gtk when the build system is armel
[09:37] <evand> this desktop file would provide another parameter that enabled some sort of dd-only mode
[09:37] <ogra> sounds good
[09:38] <ogra> would help on ia64 powerpc and sparc too btw :)
[09:39] <evand> ah, indeed :)
[09:43] <CIA-33> ubiquity: evand * r3431 ubiquity/ (d-i/manifest debian/changelog):
[09:43] <CIA-33> ubiquity: Automatic update of included source packages: clock-setup
[09:43] <CIA-33> ubiquity: 0.98ubuntu2.
[10:02] <CIA-33> ubiquity: evand * r3432 ubiquity/debian/changelog: releasing version 1.99.17
[10:54] <CIA-33> ubiquity-slideshow-ubuntu: evand * r137 html/debian/changelog: releasing version 4
[13:06] <CIA-33> casper: cjwatson * r678 trunk/ (debian/changelog scripts/casper): merge lp:~tormodvolden/casper/empty-dev
[13:09] <CIA-33> casper: cjwatson * r679 trunk/ (debian/changelog scripts/casper): merge lp:~tormodvolden/casper/guard-dev-nodes
[13:10] <CIA-33> casper: cjwatson * r680 trunk/scripts/casper: move check_dev existence test up a bit to avoid problems with LIVEMEDIA_OFFSET
[13:12] <CIA-33> casper: cjwatson * r681 trunk/debian/changelog: releasing version 1.190
[13:15] <lool> evand1: Hey, around?
[13:15] <evand1> lool: yarp
[13:15] <lool> evand1: I created an USB stick with usb-creator tip
[13:15] <lool> but cant boot it on two different computers
[13:15] <lool> I used an i386 UNR ISO from an amd64 install
[13:15] <lool> I had to manually umount /media/gibberish at the end of the USB creation and issued a "sync" before removing the USB key
[13:16] <lool> Not sure whether any of this is relevant
[13:16] <lool> What happens on boot is that I see a blinking cursor, and then nothing happens
[13:16] <lool> The USB key is only blinking for a couple of seconds and then stops
[13:16] <evand1> is partition 1 marked as active/boot?
[13:16] <lool> No
[13:16] <evand1> ah, set that and see if that makes a difference
[13:16] <evand1> I just realized that I forgot to carry that over from the old branch
[13:17] <lool> Ok thanks
[13:17]  * ogra olways thought thats only relevant for dos
[13:18] <cjwatson> no, some BIOSes care
[13:18] <ogra> ah
[13:18] <lool> evand1: no difference on both computers
[13:18] <AnAnt> cjwatson: when can I ping you ?
[13:18] <evand1> hrm
[13:18] <ogra> AnAnt, you just did :P
[13:19] <AnAnt> hehe
[13:20] <AnAnt> cjwatson: last week you said you'll look at LP 416949
[13:20] <lool> evand1: I actually had the same thing last week with two USB micro SD readers and wanted to try again with a real USB stick to take that out of the equation; it seems it was truly the contents of the USB image at some level
[13:20] <AnAnt> cjwatson: I don't want to be annoying, but I know that sometimes ppl forget
[13:20] <evand1> rather than the bootloader, you mean?
[13:21] <cjwatson> AnAnt: I said I'd look when I had a moment, and I haven't yet
[13:21] <AnAnt> ok
[13:21] <cjwatson> I have not forgotten and you do not need to keep reminding me
[13:21] <lool> I was fearing the BIOS might be sensible to various types of USB devices as I want sure the micro SD adapters were mass storage or not
[13:22] <evand1> ah, I understand
[13:23] <lool> sudo syslinux /dev/sdb1
[13:23] <lool> file is read only, overwrite anyway (y/n) ?
[13:23] <lool> odd
[13:23] <lool> and ^C releases a storm in my terminal
[13:23] <evand1> oh yeah, don't do that
[13:24] <evand1> I have a bug in debian on mtools relating to that
[13:24] <lool> evand1: Dont ^C or dont run syslinux at all?
[13:24] <lool> Is it safe to run on sdb1?
[13:24] <evand1> don't ^C
[13:25] <lool> I was wondering if the bug could be that syslinux was run while the vfat was mounted
[13:25] <evand1> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=542635
[13:25] <lool> Running syslinux again didn't bring it any further
[13:26] <evand1> I have another suggestion, just give me a minute to dig it up
[13:27] <ogra> lool, make sure btw that the drive is actually unmounted, i noticed that nautilus doesnt seem to properly unmount stuff if you click the eject icon nowadays
[13:27] <lool> ogra: I unmounted and sync-ed manually
[13:27] <ogra> ah, k
[13:27] <evand1> dd if=/usr/lib/syslinux/mbr.bin of=/dev/whatever bs=446 count=1 conv=sync
[13:27] <evand1> I'm wondering if it's getting confused by whatever is in the boot sector.
[13:28] <lool> Oh that could be
[13:28] <lool> I didn't have ay
[13:28] <lool> any
[13:28] <evand1> (another small bit of code I forgot to carry over)
[13:28] <lool> that's almost certainly the issue
[13:29] <lool> yup
[13:29] <evand1> hooray
[13:29] <lool> evand1: thanks
[13:29] <evand1> (and a big fail to me)
[13:29] <evand1> sure thing, I'll fix that in trunk
[13:29] <lool> thanks for that too; do you want a bug?
[13:29] <evand1> please
[13:30] <lool> Strictly speaking I guess one could argue that I was at fault for using an USB key without a MBR in the first place
[13:31] <lool> (It's odd that I know perfectly about MBR and bootable flags but didn't check these myself; I suck!)
[13:32] <lool> 425680
[13:33] <evand1> thanks!
[13:46] <CIA-33> partman-partitioning: cjwatson * r713 ubuntu/ (90 files in 10 dirs): merge from Debian 71
[14:02] <davmor2> evand1, cjwatson: guys I'm just doing a wubi install off of todays iso.  Also I'll do a install along side to try and sort out that grub2 issue showing vista up
[14:12] <davmor2> evand1: wubi is caught up in a cycle at ubuntu boot time again
[14:12] <evand1> davmor2: can you pastebin the exact error message?
[14:14] <davmor2> evand1: I can pastebin the wubilog you don't get to see an error it just restarts the machine as soon as you hit ubuntu from the windows grub menu
[14:14] <evand1> hrm
[14:15] <davmor2> evand1: I thought you said rev 150 should be pulled in?
[14:15] <davmor2> the wubi log says rev 142
[14:16] <evand1> it should
[14:16]  * evand1 investigates
[14:20] <evand1> weird, the wubi builds weren't producing new executables
[14:21] <davmor2> evand1: I'll leave that one with you then and try again tomorrow :)
[15:13] <davmor2> cjwatson: afternoon.  Right vista on, ubuntu on, vista still not showing up in the grub menu.  However grub still pauses for 4 secs or whatever to allow you to select the os to use, even though it still only displays the ubuntu options
[15:14] <CIA-33> usb-creator: evand * r158 trunk/ (debian/changelog usbcreator/backends/devicekit/backend.py):
[15:14] <CIA-33> usb-creator: * Unmount partitions before writing a disk image.
[15:14] <CIA-33> usb-creator: * Clear the boot sector code area and set the boot flag on the partition
[15:14] <CIA-33> usb-creator:  (LP: #425680).
[15:19] <tormod> cjwatson, thanks for merging those casper branches so fast!
[15:20] <tormod> it so more encouraging to fix things when it get acted upon timely
[15:21] <tormod> now, there is also bug #385305, I am unsure what is the best fix out of several options. if you have an opinion, I can prepare a branch
[15:48] <shtylman> evand1: I worked on the kubuntu-slideshow and have a branch I proposed for merging into trunk... I didn't merge myself cause I wanted one of yall to review it and make sure I did everything right as I moved quite a bit around
[15:48] <evand1> shtylman: wonderful!  I'll take a look at it now
[15:49] <shtylman> evand1: thanks
[15:53] <cjwatson> tormod: I think it would be OK to require .disk/casper-uuid-$blah nowadays
[15:54] <cjwatson> tormod: I'm a bit reluctant to remove it altogether since it's (AFAIK) the only thing that lets image-written-to-unpartitioned-USB-stick work
[15:55] <cjwatson> tormod: to tell you the truth I'm not exactly sure I know all the RAID paths though, so if you have the relevant systems to hand you're probably better-placed than me to make a judgement call ...
[16:07] <evand1> shtylman: You should get some text in the Konqueror page before we upload.
[16:08] <evand1> shtylman: Also, may I ask that you update debian/copyright for the new icons before I merge
[16:08] <shtylman> evand1: indeed :) ... I will poke the kubuntu people to think of something...I am not best suited for that
[16:08] <evand1> sure :)
[16:08] <shtylman> evand1: gotcha...now...the icons...I got some from wikipedia and others from the oxygen icon set...
[16:08] <shtylman> evand1: are there problems of use there?
[16:08] <shtylman> evand1: I unfortunately don't know the intricate details there...
[16:09] <evand1> we're fine so long as they're under and acceptable open source license
[16:09] <evand1> but you'll need to note the license for each in debian/copyright, as we've done for the other icons
[16:10] <evand1> and if it's a license that isn't already included, add it to the copyright file.
[16:11] <shtylman> evand1: gotcha..ok..I will do that and also update the konq page once I get more eyes on it :) thanks for reviewing
[16:11] <evand1> sure thing
[16:11] <evand1> let me know when you're ready for a merge
[16:11] <shtylman> will do
[16:12] <tormod> cjwatson: what is the use-case for image-written-to-unpartitioned-USB-stick? can you boot from something like this in the first place?
[16:12] <tormod> one problem with the "ugly hack" path is that is stops looking elsewhere. maybe we can fix that.
[16:18] <cjwatson> I think you can, yes, and indeed the installation guide used to recommend it in some cases
[16:18] <cjwatson> it saves having to bother with partitioning
[16:25] <tormod> so the CD iso file is written to e.g. /dev/sdc? or only the squashfs file? and what are the "ext[234]" cases for? I don't understand all of the code yet, like the softlinking of this device.
[16:28] <cjwatson> you ask as if I wrote all this ... :-)
[16:28] <cjwatson> you certainly couldn't just write the squashfs on its own and expect it to work, but there'd probably be nothing much stopping you dding the iso9660 filesystem over
[16:29] <tormod> but you wouldn't be able to boot from it...
[16:29] <CIA-33> usb-creator: evand * r159 trunk/usbcreator/ (3 files in 3 dirs): Use proper exceptions. Use a threading.Event object rather than a boolean flag to manage shutting down.
[16:30] <cjwatson> err. I forget then. bzr blame and see if you can find an audit trail? :)
[16:31] <tormod> all this * came from a debian merge so bzr won't reveal the guilty
[16:32] <tormod> if I knew which setups we want to support, I could make sure I understand those, and ditch the rest...
[16:33] <tormod> btw, is the plan to stick to casper for a while? otherwise I wouldn't invest too much in it.
[16:34] <tormod> only make a workaround the mentioned bug is fixed
[16:35] <cjwatson> I see no reason not to stick to casper
[16:36] <cjwatson> moving to live-initramfs would be a huge amount of work at this point and we'd have to make all the current stuff work again ...
[16:36] <CIA-33> usb-creator: evand * r160 usb-creator/usbcreator/backends/devicekit/backend.py: Do not add CD drives to the targets list.
[16:52] <davmor2> cjwatson: Is there anything you would like me to try to get vista showing up on grub2?
[16:53] <davmor2> evand1: did you get to the bottom of the wubi build issue?
[16:53] <cjwatson> I can't look now :-( I'm beating my head against totally reorganising developer permissions in LP
[16:54] <evand1> davmor2: indeed, the latest daily-live should fix the issue
[16:55] <davmor2> cjwatson: Fun :D Not  well I need to redo vista tomorrow to retest wubi :)
[16:55] <cjwatson> sorry, I know I need to find some time when you're free to debug it
[16:56] <davmor2> cjwatson: your the one that needs to be free you gotta fix it :)
[16:56] <davmor2> you're even
[16:57]  * cjwatson tries to figure out how to synthesise a test upload for LP
[19:06] <lool> Did anybody test casper-rw persistence recently?
[19:11] <lool> I think it OOPSes
[19:12] <lool> with aufs that is