[01:51] <tagman> How do I get past the installer being stuck at 15%?
[01:55] <tagman> Anybody there?
[03:07] <CIA-24> ubiquity: evand * r2438 ubiquity/ (6 files in 5 dirs):
[03:07] <CIA-24> ubiquity: * Validate the boot device string that the user provides on the
[03:07] <CIA-24> ubiquity:  advanced page.
[03:07] <CIA-24> ubiquity: * Change the boot device Entry to a ComboBox that displays suitable targets.
[06:30] <evand> ugh, pyqt is quite evil.
[06:33] <superm1> trying to implement the equivalent of that above commit for qt?
[06:36] <evand> yeah, and weird language gotchas like having to str() qstrings
[06:36] <evand> I just want a model with two columns, is that so much to ask for?
[06:37] <superm1> apparently :)
[06:37] <evand> haha
[06:38] <superm1> you see why i opted for the mythbuntu frontend to derive off the gtk one then?  I played with the qt designer for a little bit and decided it would be way to rough to work from
[06:38] <evand> I used to know Qt quite well :/
[06:39] <evand> but yes, my brain can handle GTK much better
[07:56] <CIA-24> base-installer: soren * r322 base-installer/ (debian/changelog kernel/i386.sh): Add support for AMD CPU family 16 on i386.
[09:08] <cjwatson> speaking of GTK, if anyone knows how to implement a multi-column list in GTK where the columns flow newspaper-style rather than meaning different things, that'd be great
[09:08] <cjwatson> that is, it's only multi-column in that when it runs out of vertical space in one column it goes on to the next
[09:29] <soren> cjwatson: I don't think there's a widget for that in GTK, but I guess you could use a regular TreeView and call gtk_tree_view_get_visible_* to determine how many rows are showing and then do it manually.
[10:40] <cjwatson> soren: mm, that's the best I've come up with - it'll be nasty on resize though
[10:44] <cjwatson> I think I'll ask gtk-list if anyone has any sample code
[11:38] <sridhar> how to be a member in ubuntu-installer@lists.ubuntu.com
[11:38] <sridhar> ?
[11:53] <cjwatson> sridhar: https://lists.ubuntu.com/mailman/listinfo/ubuntu-installer
[12:06] <sridhar> cjwatson: thanks
[12:09] <cjwatson> superm1: I'm looking at your preservehome branch at the moment, and comparing it with the adduser source
[12:09] <cjwatson> superm1: it seems to me that if you pass --gid to adduser it expects the group to exist already (although this isn't particularly documented)
[12:09] <cjwatson> superm1: did you test this and confirm it to work?
[12:10] <cjwatson> superm1: I think that you probably need to call addgroup explicitly if GIDOPT is set
[12:23] <tjaalton> does d-i run any scripts _before_ inittab is read?
[12:23] <tjaalton> outside the initrd
[12:23] <cjwatson> d-i runs entirely from its initrd so that question has no meaning ...
[12:24] <tjaalton> heh
[12:24] <cjwatson> rootskel/src/init
[12:24] <cjwatson> that does some stuff and then execs busybox init which reads inittab
[12:24] <cjwatson> :q
[12:24] <cjwatson> (oops)
[12:25] <cjwatson> basically just mounts /proc and creates some devices
[12:25] <cjwatson> oh, and mounts /dev to put said devices in, of course
[12:27] <tjaalton> I'm (again) thinking how it would be possible to disable the "convenience shells" run from inittab. maybe it would be too fugly to read a kernel parameter in rootskel/src/init and echo those tty-lines in a normal situation?
[12:27] <cjwatson> you could read a kernel parameter and have it sed -i /etc/inittab
[12:27] <cjwatson> to eliminate them
[12:27] <cjwatson> remind me why you're disabling them?
[12:28] <tjaalton> unattended installations on a public place
[12:28] <cjwatson> ok, hope you've locked the bootloader
[12:28] <tjaalton> sure
[12:28] <tjaalton> that's easy :)
[12:28] <tjaalton> netboot supports passwords now
[12:28] <cjwatson> I think honouring a 'noshell' parameter or similar would be fine
[12:29] <tjaalton> but the place to do it is in src/init?
[12:29] <cjwatson> yeah
[12:29] <tjaalton> ok cool, I'll make a debdiff
[12:30] <cjwatson> feel free to just commit and upload
[12:30] <tjaalton> heh, ok :)
[12:30] <cjwatson> bzr branch in the usual place
[12:31] <tjaalton> I'm so excited that Matt made all those fancy patches for syslog and sshkey-authentication for network-console :)
[12:31] <tjaalton> d-i will simply rock
[12:31] <tjaalton> oh, it already does btw
[12:31] <tjaalton> but even more
[12:43] <cjwatson> 12:31 <tjaalton> I'm so excited that Matt made all those fancy patches for syslog and sshkey-authentication for network-console :)
[12:43] <cjwatson> was the last thing I saw
[12:43] <cjwatson> tjaalton: yeah, it's pretty cool
[12:43] <tjaalton> 14:31 < tjaalton> d-i will simply rock
[12:43] <tjaalton> 14:31 < tjaalton> oh, it already does btw
[12:43] <tjaalton> 14:31 < tjaalton> but even more
[12:43] <tjaalton> :)
[12:45] <cjwatson> haha
[13:10] <xivulon> cjwatson, I'd like to add hooks similar to lupin/casper into d-i, what would be a good place? initrd, rootskel or udeb?
[13:10] <xivulon> the reason is to support distros that do not ship a live CD and to make it possible to have netinstall capabilities in the future
[13:11] <cjwatson> that depends. hooks for what?
[13:11] <xivulon> 1 hook to set a local ISO skiping the stage where an ISO is looked for (mount it as /cdrom?)
[13:12] <xivulon> 1 hook to do initrd preseeding using a file on local device
[13:12] <xivulon> possibly keeping the same boot arguments
[13:12] <xivulon> as in casper
[13:17] <cjwatson> haven't we done this before? this should use hd-media
[13:17] <cjwatson> I do not want to add this to the CD initrd
[13:18] <xivulon> before I was using the initrd since I needed to do overrides of the ISO
[13:18] <xivulon> of the d-i installer^
[13:18] <cjwatson> d-i has multiple initrd variants
[13:18] <xivulon> but I do not think it is necessary
[13:18] <xivulon> anymore
[13:19] <xivulon> I'd go for either rootskel/src/lib/debian-installer.d or a udeb to be called before initrd preseeding
[13:19] <cjwatson> rootskel is completely and utterly inappropriate
[13:20] <xivulon> can you remind me when initrd preseeding kicks in (web interface is a pain to look code for)
[13:20] <xivulon> that seems to leave udeb route
[13:20] <cjwatson> using a local ISO is already implemented by iso-scan
[13:20] <cjwatson> initrd preseeding using a file on a local device is a contradiction in terms
[13:20] <cjwatson> the purpose of initrd preseeding is to be entirely local to the initrd
[13:21] <xivulon> I think I used to do to seed locale/layoutcode... but can do that via boot parameters anyway
[13:21] <cjwatson> indeed so
[13:22] <cjwatson> file-preseed runs after iso-scan and can already be used in hd-media mode to preseed from a file on a local device
[13:22] <xivulon> it would be good then to specify the path/name of the ISO
[13:22] <xivulon> would be good then to specify the path/name of the ISO/preseed
[13:22] <xivulon> which takes precedence over standard paths
[13:23] <cjwatson> it would be reasonable for iso-scan to support preseeding of iso-scan/filename (which it already uses as an output)
[13:24] <xivulon> it is already possible to set paramaters to look for a specific local path for preseeding correct?
[13:24] <cjwatson> yes
[13:24] <xivulon> so that /path/to/preseed.cfg is looked for in all devices
[13:25] <cjwatson> err, no
[13:25] <cjwatson> only on things that are already mounted
[13:25] <xivulon> and that depends on...
[13:25] <cjwatson> I am very cautious of things that run around mounting everything in d-i
[13:26] <cjwatson> they have been known to cause data loss
[13:26] <cjwatson> (e.g. hibernated partitions)
[13:26] <xivulon> only a temporary mount is required, enough to copy over preseed (and possibly other files) then umounting
[13:27] <xivulon> it's difficult to specify the linux device from windows
[13:27] <cjwatson> I know, but that doesn't really help matters
[13:27] <cjwatson> mounting a hibernated partition that uses a journalled filesystem is enough to corrupt it
[13:28] <xivulon> also a ro mount?
[13:28] <cjwatson> yes
[13:28] <cjwatson> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=417407 suggests a scheme for avoiding this
[13:28] <ubotu> Debian bug 417407 in os-prober "os-prober: protect partitions with "blockdev --setro"" [Important,Open]
[13:28] <xivulon> doesn't the iso-scan mount partitions anyway
[13:28] <cjwatson> but one does have to be pretty careful
[13:28] <xivulon> IIRC
[13:28] <xivulon> that would be not much different
[13:28] <cjwatson> hmm, yeah, I suppose iso-scan does have that problem; yet another reason it is not in the cdrom initrd :)
[13:29] <cjwatson> the boot arguments currently used by casper would not be accepted into upstream d-i
[13:30] <cjwatson> I did warn you about this ages ago ;)
[13:30] <xivulon> on my side the situation is that I have C:\path\to\ISO and C:\path\to\preseed.cfg and need to convey this info over to the installer
[13:30] <cjwatson> all d-i boot arguments used by udebs must correspond to debconf questions and must be properly namespaced
[13:30] <cjwatson> so if you want this in d-i there's going to have to be a transition
[13:30] <xivulon> if you have any good idea on that I'd be more than happy to implement it
[13:31] <cjwatson> things implemented by iso-scan must generally be iso-scan/foo, etc.
[13:31] <xivulon> casper of course has to use the initrd, while that is not required for d-i (as mentioned above), not sure if that helps matters
[13:33] <xivulon> I can do iso-scan mods, that means though that I have to use hdmedia initrd as opposed to the one found in the alternate ISO, correct?
[13:33] <xivulon> or do a netinstall skiiping isoscan (would still need preseed-scan though)
[13:35] <xivulon> on a different topic, I do not know how I missed it for so long, but there is an nsis package in the archives
[13:35] <xivulon> this greatly simplifies the build process
[13:36] <xivulon> only thing is that I'd need v2.34 (now 2.33) since new code uses nsdialog interface which is much saner than previous implementations
[13:39] <cjwatson> at present, iso-scan fundamentally conflicts with the normal cdrom boot process
[13:39] <cjwatson> it might be possible to fix that in some way, but I haven't thought about it much and cannot guarantee that it's straightforward
[13:40] <xivulon> can we have either one or the other accoring to boot arg maybe?
[13:40] <cjwatson> no
[13:40] <cjwatson> well, not right now
[13:41] <cjwatson> that would obviously be roughly the way to fix it but it needs some thought from a d-i developer to get it right
[13:42] <xivulon> hdmedia initrd + iso would still work though (assuming I can push the changes to hdmedia)
[13:42] <xivulon> iirc hdmedia also works for netinstallations
[13:43] <xivulon> I'd be happy with that too
[13:44] <cjwatson> network installations should generally use the netboot initrd
[13:45] <cjwatson> hd-media doesn't include net-retriever
[13:45] <xivulon> haven't looked at it in a while but thought that much functionality of netboot is also in hdmedia
[13:45] <cjwatson> net-retriever is kind of important :)
[13:45] <cjwatson> you can't get udebs from the network without it
[13:46] <xivulon> then I didn't remember correctly...
[13:47] <xivulon> any reason to have different initrds as opposed of having boot switches? wouldn't think that the size would change dramatically
[13:49] <cjwatson> they conflict
[13:49] <cjwatson> and actually the size is quite important and yes it does make a difference
[13:49] <cjwatson> different boot methods require different sets of kernel modules
[13:50] <cjwatson> the netboot initrd doesn't need block device drivers, for instance; it can retrieve those later
[13:50] <cjwatson> similarly the cdrom and hd-media initrds can save quite a bit of space by leaving out network drivers
[13:55] <xivulon> I am fine with it, it only makes it slightly inconvenient for people that want to use wubi in offline mode
[13:55] <xivulon> since on top of the ISO/CD they also need to get an appropriate initrd (but only in some cases)
[13:56] <cjwatson> I'm not saying it's perfect, just that there isn't a quick fix and that it needs some design work, that's all
[13:56] <xivulon> to conclude then I'd gess the best route might be to add an iso-scan/path parameter that will affect hdmedia
[13:57] <cjwatson> iso-scan/filename (since the debconf question already exists)
[13:57] <cjwatson> yes, that seems like a fairly obvious first step
[13:57] <xivulon> as for the preseed fetching I am a bit more cautious, I'd also need something similar to the above
[13:58] <xivulon> does current local-device-preseed-fetching only affects hdmedia?
[13:58] <xivulon> in case I can simply patch that
[13:58] <cjwatson> well, there isn't really such a thing right now
[13:59] <cjwatson> file-preseed knows how to fetch a preseed file from a specified path
[13:59] <cjwatson> (about to be on the phone for two hours, sigh)
[14:00] <xivulon> can we change (in a backward compatible way) the path syntax so that I can specify ANYDEVICE/path/to/preseed.cfg?
[14:01] <cjwatson> I think it would be better to add a second question which says to do a device search, rather than to try to crowbar it into the syntax
[14:08] <xivulon> see also ^ re nsis 2.34, I'll need to nag someone to have that in the archives...
[14:27] <xivulon> cjwatson the above is certainly ok for hdmedia, but not for netinstall (if block device drivers are not there I am not sure how I can preseed it)
[14:28] <xivulon> That is only an issue for dedicated partition installation, you mentioned that if I use a local ISO with hdmedia, repartitioning is an issue, does that still hold true?
[14:57] <cjwatson> yep
[15:04] <xivulon> I assume that using "iso-scan/filename" also in casper is not acceptable since there is no iso-scan package. But would be nice to standardize on that
[15:05] <superm1> cjwatson, I didn't actually get to test it to confirm it works.  I'll see if I can give that a go.
[15:05] <xivulon> same with debian-installer/custom-installation (now in casper)
[15:06] <xivulon> wich includes preseed
[15:14] <tjaalton> rootskel uploaded, hope I got it right the first time
[15:23] <cjwatson> iso-scan/filename in casper would be OK; casper already abuses namespaces somewhat for compatibility
[15:26] <xivulon> ok I'll change that, I like it better than find_iso anyway
[15:27] <xivulon> what about debian-installer/custom-installation within d-i? maybe scan-custom-installation/foldername?
[15:27] <cjwatson> I am on the phone but will get back to you later
[15:27] <xivulon> sure
[16:41] <xivulon> preliminary iso-scan "patch" to support preseeded filename http://paste.ubuntu-nl.org/54997/
[16:51] <cjwatson> please follow local style in terms of indentation
[16:52] <cjwatson> (indent is one tab except for case patterns which are half-indent, i.e. four spaces, to keep the depth reasonable)
[16:53] <cjwatson> I think it would be better to just whack $DEVS and go through the normal code path, to avoid duplicating that code
[16:53] <xivulon> Bug #189630 summarize above discussion
[16:53] <ubotu> Launchpad bug 189630 in lupin "d-i/hdmedia should have hooks similar to the ones in lupin/casper" [Undecided,New] https://launchpad.net/bugs/189630
[16:53] <cjwatson> and I really think this ought to be controlled by a separate preseeded variable which is off by default
[16:54] <xivulon> you mean iso-scan/filename?
[16:54] <cjwatson> I don't mean $DEVS, sorry, I mean the output of the directory-scanning code in the inner loop
[16:54] <cjwatson> no
[16:54] <cjwatson> well, er
[16:55] <xivulon> I just factored out try_dir since the same block would occur 3 times
[16:55] <cjwatson> oh, um, ok, maybe I misunderstood
[16:55] <cjwatson> could you send an actual patch once you can
[16:55] <xivulon> can do that tonight
[16:55] <xivulon> even a debdiff at that :P
[16:56] <cjwatson> I think rather than try_preseeded_filename you should just insert this into the loop that goes 'for iso in $dir/*.iso $dir/*.ISO; do'
[16:56] <cjwatson> and have it check iso-scan/filename first and only if it's not set then do that scan
[16:57] <cjwatson> then it doesn't really need any refactoring AFAICS
[16:57] <xivulon> then it should go in "for dev in devs", since I only need to check once per dev
[16:57] <cjwatson> actually, probably should be around 'for dir in . *; do'
[16:57] <cjwatson> right
[16:58] <cjwatson> sorry, hard to read code while chairing a meeting ;)
[16:58] <xivulon> np
[17:03] <evand> xivulon:
[17:03] <evand> 11:00:25 < TheMuso> evand: I think atm, a series of radio buttons, as thats all that can be done from gfxboot, and I don't  think there is a need for more than one profile needed at the same time.
[17:03] <evand> 11:00:43 < evand> TheMuso: fantastic, thanks
[17:03] <evand> 11:00:48 < cjwatson> I actually implemented checkbox support in gfxboot-theme-ubuntu recently
[17:03] <evand> 11:00:53 < cjwatson> in a hideously crude way but never mind
[17:03] <evand> 11:01:01 < cjwatson> ("x  " FTW)
[17:04] <evand> 11:01:11 < evand> haha
[17:04] <evand> 11:01:12 < TheMuso> cjwatson: I still don't think it makes sense in this context.
[17:09] <soren> I'm having an odd, odd problem trying to build d-i..
[17:09] <soren> The symptom:
[17:09] <soren> During get-packages, I get:
[17:09] <soren> cyberorc: Helt sikkert. Har jævnt travlt, men det er ca. som forventet.The following packages have unmet dependencies: console-tools-udeb: Depends: libconsole (= 1:0.2.3dbs-65ubuntu6) but it is not installable
[17:09] <soren> E: Broken packages
[17:09] <soren> Whoops.
[17:09] <soren> Only this bit: The following packages have unmet dependencies: console-tools-udeb: Depends: libconsole (= 1:0.2.3dbs-65ubuntu6) but it is not installable
[17:09]  * soren curses his mouse wheel
[17:11] <xivulon> evand thanks, I am not convinced that 1 profile is enough but if the TheMuso says so, it's fine with me
[17:13] <soren> I can't imagine what would make libconsole uninstallable.
[17:21] <CIA-24> grub-installer: evand * r724 grub-installer.ubuntu/ (debian/changelog grub-installer):
[17:21] <CIA-24> grub-installer: * Generate a device.map when bootdev_directory is set (loop
[17:21] <CIA-24> grub-installer:  installations) (LP: #188460). Thanks Agostino Russo.
[17:22] <soren> cjwatson: Hm... the sources.list.udeb doesn't list a regular main, only the d-i one.. How is it supposed to get its hands on libconsole? Is it supposed to be a build-dependency of d-i?
[17:23] <CIA-24> grub-installer: evand * r725 ubuntu/debian/changelog: releasing version 1.27ubuntu3
[17:23] <soren> cjwatson: Or is the main archive's absence from sources.list.udeb a bug?
[17:34] <cjwatson> err, you might just need to have it installed on the build system
[17:34] <cjwatson> the main archive should definitely not be in sources.list.udeb
[17:35] <cjwatson> actually, why is console-tools-udeb depending on libconsole rather than libconsole-udeb? that's a bug
[17:35] <cjwatson> I thought I fixed that ages ago
[17:35] <cjwatson> I bet dpkg broke that on me
[17:36] <cjwatson> udeb: libconsole 0 libconsole-udeb (= 1:0.2.3dbs-65ubuntu6)
[17:36] <cjwatson> shlibs *look* right ...
[17:44] <soren> It built correctly on the buildd's as well. How odd.
[17:45] <soren> Ah, new console-tools from the day before yesterday.
[17:47] <cjwatson> urr. any chance you could figure out why console-tools-udeb is getting the wrong dependency, despite the shlibs?
[17:49] <cjwatson> the change in console-tools isn't relevant AFAIK; it's a build system thing
[17:49] <soren> WEll, I guess I'm going to have to.
[17:49] <soren> cjwatson: Sure, I was just wondering why it worked a week ago.
[17:49] <soren> cjwatson: and that explains it.
[17:50] <cjwatson> it hadn't been built since gutsy, so I expect it needs tweaked to cope with dpkg-shlibdeps changes
[17:50] <cjwatson> it was doing some kind of nasty stuff
[17:51] <soren> Will you be around for the next couple of hours or later this evening?
[17:51] <soren> My crystal ball tells me I'll find the issue, but won't be able to tell if it's dpkg or console-tools that's doing the wrong thing.
[17:51] <soren> s/dpkg/dpkg and friends/
[17:59] <soren> cjwatson: Hrm... There's a shlibs.local, that says "libconsole	0	libconsole (= ${Source-Version})
[17:59] <soren> Erk.. That looks mangled here.
[17:59] <soren> cjwatson: Hrm... There's a shlibs.local, that says "libconsole 0 libconsole (= ${Source-Version})".
[18:00] <soren> cjwatson: dpkg-shlibdeps doesn't mention anything about udeb. I have literally no historical context, so I'm not sure where to point my finger.
[18:06] <soren> cjwatson: Adding the udeb: lines to shlibs.local fixes it..
[18:07]  * soren goes to dinner. bbl.
[18:08] <cjwatson> soren: later as in much later
[18:08] <cjwatson> not the next couple of hours
[18:09] <cjwatson> urr
[18:09] <cjwatson> I *think* that shlibs.local should just go away
[18:09] <cjwatson> would be worth seeing what happens if you just rm the thing
[20:54] <soren> cjwatson_: Yeah, everything looks lovely without shlibs.local AFAICS.
[20:54] <soren> cjwatson_: Thanks for your input.
[20:59] <cjwatson_> great, thanks
[20:59] <cjwatson> I like people figuring out d-i build failures for me ;)
[21:02] <soren> :)
[21:02] <soren> I'm curious why it suddenly broke, though.
[21:02] <soren> That shlibs.local has been the for a looong time, apparantly.
[21:43] <soren> cjwatson: d-i's build/config/common still says "SUITE =? gutsy". I doubt that's intentional but somehow I feel I should probably ask to be sure :)
[21:45] <cjwatson> yeah, doesn't actually matter because debian/rules overrides it, but should be fixed; go ahead
[21:45] <cjwatson> suddenly broke> dpkg-shlibdeps was practically rewritten ...
[21:48] <soren> Ah, yes.
[22:16] <soren> cjwatson: Ok, a bit of assistance... I'm working on the iscsi thing again. I've made changes to disk-detect and added a new udeb... How do I most easily test these things? the mini.iso d-i can build for me doesn't have the udeb's so that's not as easy as I had hoped..
[22:16] <soren> My apologies if this is already explained somewhere..
[22:20] <evand> localudebs?
[22:20] <soren> evand: Yeah, but they don't land on the mini.iso, do they?
[22:20] <evand> I thought they did, but it's been a while.
[22:20] <soren> or am I being a muppet?
[22:21] <soren> It's quite conceivable that I am.
[22:21] <evand> heh
[22:22] <soren> Nope.
[22:22] <evand> argh, not sure then
[22:24] <soren> aha!
[22:24] <soren> EXTRAUDEBS ftw, it seems.
[22:28] <cjwatson> for adding a new udeb, localudebs or EXTRAUDEBS is about right
[22:28] <cjwatson> you might need to prod build/pkg-lists/whatever
[22:29] <cjwatson> for simpler changes it's often sane to just edit things on the fly in the running installer
[22:29] <cjwatson> that doesn't work if you add debconf templates though
[22:31] <soren> I do.
[22:32] <soren> But the mini iso should do fine?
[22:32] <soren> Or do I need to dive into debian-cd, too?
[22:36] <cjwatson> mini.iso should do fine provided it's the cdrom one
[22:36] <cjwatson> (mini.iso is a delivery format rather than something that defines what udebs go on the image)
[22:37] <cjwatson> if cdrom doesn't work, monolithic is the standard big hammer
[22:37] <cjwatson> you'll need to edit build/config/i386.cfg or similar to uncomment monolithic, and then run 'make' in build/ to get the right target name
[22:37] <cjwatson> probably rebuild_monolithic
[22:38] <soren> Ah... adding them to EXTRAS and cleaning and rebuilding got them into the initrd. That was what I was looking for, I guess.
[22:38] <cjwatson> monolithic builds all available udebs into the image
[22:38] <soren> Ah, ok.
[22:38] <cjwatson> except that it doesn't need a retriever
[22:38] <cjwatson> because it already has it all in the initrd
[22:38] <cjwatson> obviously fairly giant
[22:39] <soren> I can imagine :)
[22:41] <soren> cjwatson: I remember you said I could define /proc/cmdline aliases... Where was that again?
[22:41] <cjwatson> preseed_aliases
[22:41] <cjwatson> in the preseed source
[22:41] <cjwatson> I think it's /lib/preseed/preseed_aliases in the initrd
[22:42] <cjwatson> right, early(ish) night time, I think
[22:43] <soren> Alright. I think I have plenty to work with now. Thanks for your help.
[22:43] <cjwatson> no problem
[23:04] <soren> cjwatson: Have you gone yet?
[23:26] <xivulon> cjwatson re iso-scan: http://paste.ubuntu-nl.org/55035/
[23:26] <xivulon> haven't tested it though
[23:55] <xivulon> howdy
[23:55] <xivulon> howdy
[23:56] <xivulon> when I use debuild I get "secret key not available"
[23:56] <xivulon> the key is in my keyring, do I need to register it homehow?