[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<EMAIL_ADDRESS>[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?


[12:14] <bronson> Anyone mind looking over http://wiki.u32.net/Dpkg/Versions and telling me if I'm wrong anywhere or missing something?
[12:19] <bronson> Oy, looks like dreamhost is suddenly having issues.
[12:20] <cjwatson> crimsun_: thanks
[12:45] <darwin188> can somebody help me out with ubuntu on a powermac g4
[12:45] <HrdwrBoB> #ubuntu for support
[12:45] <darwin188> x11 wont start
[12:45] <darwin188> nah
[12:45] <darwin188> here is where the good people are
[12:46] <HrdwrBoB> that may be the case
[12:46] <darwin188> it is indeed
[12:46] <HrdwrBoB> but you won't get help here
[12:46] <Burgwork> but #ubuntu is for support, not here
[12:46] <darwin188> come on
[12:46] <Burgwork> darwin188: you will be removed if you continue
[12:47] <Burgwork> this is for development, not support
[12:50] <_ion> burgwork: Btw, i quite liked the link https://wiki.ubuntu.com/UbuntuWeeklyNewsletter being in the beginning of Ubuntu Weekly News emails earlier.
[12:50] <_ion> It would be nice to have it back in the future newsletters.
[12:51] <Burgwork> _ion: hmm
[01:01] <jdong> anyone know who Endersshadow is on the wiki?
[01:03] <mdke> jdong: did you try a search in launchpad?
[01:03] <jdong> no, actually didn't
[01:03] <jdong> was looking on the wiki
[01:03] <mdke> that's the only way
[01:03] <jdong> ah
[01:03] <mdke> you can get an email address that way, although not his name
[01:05] <jdong> found him , https://launchpad.net/people/hewitte
[01:05] <jdong> ok, good
[01:06] <jdong> hmm, bc.edu.... is that Boston College?
[01:06] <jdong> yep
[01:06] <jdong> look at that, I'll be across the street from him in a few weeks :D
[01:14] <jdong> mdke: maybe I'm not seeing it, but is it possible to attach files to the wiki?
[01:15] <xerxas> why is ubuntu not setting PAGER to /usr/bin/less ?
[01:15] <mdke> jdong: sure, More Actions -> attachments
[01:15] <xerxas> is there any good reason ?
[01:15] <jdong> ah cool
[01:15] <fabbione> xeros: what's a good reason to change it?
[01:16] <fabbione> hem
[01:16] <jdong> xerxas: because it seems to use alternatives  instead
[01:16] <fabbione> xerxas: ^^
[01:16] <jdong> /usr/bin/pager
[01:16] <jdong> update-alternatives --config pager
[01:16] <xerxas> fabbione: because less does more than more
[01:16] <xerxas> :)
[01:16] <jdong> huh? more was default?
[01:16] <xerxas> because less isn't annoying when using completion
[01:16] <xerxas> jdong: I think so
[01:16] <jdong> less has always been selected as the pager on my machine...
[01:17] <jdong> is this a Feisty thing?
[01:17] <fabbione> xerxas:
[01:17] <fabbione> fabbione@daltanius:~$ which more
[01:17] <fabbione> /bin/more
[01:17] <fabbione> fabbione@daltanius:~$ which less
[01:17] <fabbione> /usr/bin/less
[01:17] <fabbione> that's why
[01:17] <fabbione> in case of crash/recovery there is no guarantee to have /usr
[01:17] <xerxas> fabbione: good :)
[01:17] <fabbione> so it's user freedom to break what they want
[01:18] <fabbione> the system by default needs to work
[01:18] <xerxas> fabbione:  less won't never be in /bin ?
[01:18] <xerxas> more could be a link to less , or is that a too intrusive change ?
[01:19] <fabbione> xerxas: i don't personally know why less is in /usr/bin if not because there is more in /bin
[01:19] <fabbione> a symlink is like hammering your testicles
[01:19] <jdong> lol
[01:19] <xerxas> a symlink ?
[01:19] <xerxas> to ?
[01:19] <xerxas> in /bin to /usr/bin ?
[01:19] <fabbione> (that's the best description i can think of)
[01:19] <xerxas> surely not !
 more could be a link to less , or is that a too intrusive change ?
[01:19] <fabbione> ^^^
[01:19] <jdong> linking something from /bin to /usr/bin is pretty... iffy at best :D
[01:19] <xerxas> I didn't want to say that :)
[01:19] <xerxas> tired
[01:19] <xerxas> less could be in /bin
[01:20] <xerxas> I wanted to say
[01:20] <mdke> even so, I bet hammering your testicles would be worse
[01:20] <fabbione> xerxas: you said 2 things.. less in /bin AND more a link to less
[01:20] <fabbione> (at the same time)
[01:20] <fabbione> my answer was hammering
[01:20] <xerxas> or less in /bin and more a link to less
[01:20] <fabbione> there are things that depends on more behavious
[01:20] <fabbione> xerxas: we are saying the exact same thing
[01:20] <xerxas> like colors for example probably ?
[01:21] <fabbione> my answer didn't change since
[01:21] <xerxas> fabbione:  yup :)
[01:21] <xerxas> ok
[01:21] <fabbione> you will keep hammering some parts of your body
[01:21] <fabbione> mdke: be aware.. some people do actually LIKE that..
[01:21] <xerxas> $ find /bin -type l  |wc -l
[01:21] <xerxas> 10
[01:21] <xerxas> lol
[01:21] <xerxas> :)
[01:22] <xerxas> jdong: does your completion uses less ? (or you using edgy ? )
[01:23] <jdong> xerxas: man and most of the other commands that use a pager all use less on my boxes from Warty to Edgy :D
[01:23] <jdong> I don't know about anything else though :)
[01:23] <xerxas> jdong:  I think it's ok for man
[01:23] <jdong> ah, ok
[01:24] <xerxas> but my shell completion seems to use more
[01:24] <jdong> then I havent' noticed it yet...
[01:24] <xerxas> I'm reading man bash
[01:24] <jdong> maybe that's true
[01:24] <xerxas> just open a gnome-terminal and hit 2 times [TAB]
[01:24] <mdke> fabbione: this is true. Whether you prefer that or a dodgy symlink depends on the individual, I suppose
[01:25] <cjwatson> $ update-alternatives --display pager
[01:25] <cjwatson> pager - status is auto.
[01:25] <cjwatson>  link currently points to /usr/bin/less
[01:26] <cjwatson> xerxas: that's built into the shell - it's neither less nor more
[01:26] <xerxas> cjwatson:  seems so
[01:27] <xerxas> so it can't be changed ?
[01:27] <cjwatson> it can't be an external problem
[01:27] <cjwatson> er
[01:27] <cjwatson> program
[01:27] <cjwatson> what in particular bothers you?
[01:28] <xerxas> I would like to have a less like completion for commands
[01:28] <xerxas> for command completion I mean
[01:28] <cjwatson> you mean you would like to be able to scroll up and down in the list?
[01:28] <xerxas> yep
[01:31] <cjwatson> xerxas: that's not possible in bash (unless you patch it to add that feature)
[01:31] <cjwatson> it's not a matter of Ubuntu's configuration
[01:31] <xerxas> cjwatson:  ok
[01:31] <fabbione> cjwatson: do you happen to know why we prefer gs-esp to gs-gpl ?
[01:31] <fabbione> cjwatson: gs-esp is the trouble maker
[01:31] <cjwatson> fabbione: I believe it's more up to date for other purposes
[01:31] <cjwatson> fabbione: ask iwj
[01:32] <fabbione> cjwatson: ok
[01:32] <fabbione> thanks
[01:32] <fabbione> iwj: ^^ if you happen to read...
[01:32] <cjwatson> he's on holiday - I'd send mail if I were you
[01:33] <fabbione> yeah i know.. it's not urgent or important
[01:33] <fabbione> if he reads the scrollback good.. otherwise i will send him a patch
[01:33] <fabbione> i have reduced the test case
[01:33] <fabbione> so it shouldn't be impossible to debug once gdb is fixed :)
[01:34] <keescook> fabbione: what's wrong with gdb?
[01:34] <fabbione> keescook: it's broken on sparc... davem is fixing it on the other side of the room
[01:34] <fabbione> it tends to explode easily
[01:34] <keescook> ah, okay.  missed the sparc part.  :)
[01:35] <fabbione> ehhe no problem
[01:35] <zul> hey fabbione
[01:35] <fabbione> hey zul
[01:36] <cjwatson> xerxas: possible workarounds: (a) just keep saying yes to "--More--" until you get to the end of the list, then use Shift-PageUp/Shift-PageDown to page up and down; (b) try zsh and see if you like its completion better
[01:36] <cjwatson> (note that zsh is really quite a different shell, though)
[01:37] <xerxas> cjwatson:  I've already had the idea to switch to zsh but never made the step :)
[01:47] <_ion> /u/s/d/upst/RE<tab><tab>  /usr/share/doc/upstart/README.Debian.gz
[01:47] <mdke> cjwatson: what will be the best took in Feisty for manipulating and mounting partitions? We need to replace the gnome-disks-manager references in the documentation. gparted springs to mind, but something called pyGTK has been mentioned
[01:51] <cjwatson> mdke: uh, pygtk is unlikely to be what whoever it was really meant
[01:51] <cjwatson> mdke: pygtk => python bindings to gtk
[01:51] <cjwatson> mdke: gparted is about the only candidate at present. Nothing is really actually GOOD.
[01:51] <mdke> cjwatson: I beg your pardon. PyGTK Storage Device Manager (pysdm)
[01:51] <cjwatson> oh, I have no idea
[01:51] <cjwatson> sorry, I only do this stuff in the context of the installer which is a specialised use case
[01:51] <mdke> what are you using in the installer, still gparted?
[01:52] <cjwatson> gparted but will be replaced if I manage to do it in time
[01:52] <cjwatson> the replacement will be a home-grown UI based on partman (the d-i partitioner)
[01:52] <mdke> and which won't have an equivalent on an installed system?
[01:52] <cjwatson> no
[01:53] <mdke> cjwatson: shame. Ok, gparted it is, I guess
[01:53] <cjwatson> pysdm looks rather scary and doesn't appear to do things like creating or resizing partitions
[01:53] <cjwatson> partition management and fiddling with fstab are really completely different jobs
[01:54] <cjwatson> creating and resizing partitions is hard to do on an installed system because some partitions on the disk in question are usually mounted which means the kernel won't reread the partition table until you reboot
[01:54] <mdke> ah, does gparted not do the former?
[01:54] <cjwatson> no, it doesn't do the latter
[01:54] <mdke> latter, yeah. it's late
[01:55] <cjwatson> if gnome-disks-manager does fstab fiddling, gparted isn't an appropriate replacement
[01:55] <mdke> you're right, my bad
[01:55] <cjwatson> I guess pysdm could do that, but jeez, presenting a UI for editing udev rules?
[01:55] <cjwatson> scares the hell out of me, dunno about you :)
[01:56] <cjwatson> but, it was a GSoC project for Ubuntu, so ...
[01:56] <mdke> ah
[01:56] <cjwatson> and I'm only going by the screenshot on its sourceforge page
[01:56] <cjwatson> screenshots
[01:56] <mdke> yes. Well, if windows partitions are always mounted by default on installed systems, and always available for non-administrative users, perhaps we can cut the instructions entirely
[01:57] <mdke> problem is one sees lots of questions on support channels about accessing Windows partitions
[01:57] <cjwatson> mm, that's basically an os-prober bug - does need to get fixed
[01:58] <cjwatson> actually, no, I'm thinking of boot stanzas
[01:58] <cjwatson> they should be mounted by default, unless people deselect the mount points
[01:58] <mdke> my windows partitions used to be on the desktop mounted, but when I clicked on em, I got a permission denied from nautilus... dunno if the situation has changed, I killed that partition
[02:01] <cjwatson> mdke: I fixed that in the installer (I believe) but it doesn't affect already-installed systems
[02:01] <cjwatson> that sort of upgrade case is just a nightmare to handle and a security hole when got wrong, so best left alone
[02:01] <mdke> hmm.
[02:01] <mdke> cjwatson: was it fixed already for Dapper?
[02:01] <cjwatson> yes
[02:01] <cjwatson>   * Mount FAT and NTFS with umask=007,gid=46 (static group plugdev), so that
[02:01] <cjwatson>     users can easily be given privileges to read/write mounted Windows
[02:02] <cjwatson>     filesystems, and so that the first user can do so automatically (closes:
[02:02] <mdke> ok, so probably majority of users not affected
[02:02] <cjwatson>     Malone #8048, #25071).
[02:02] <Ubugtu> Malone bug 8048 in partman-basicfilesystems "Mounted vfat partition is not writeable for non-root users" [Medium,Fix released]  http://launchpad.net/bugs/8048
[02:02] <Ubugtu> Malone bug 25071 in partman-basicfilesystems "More reasonable defaults for ntfs mounts during installation" [High,Fix released]  http://launchpad.net/bugs/25071
[02:02] <cjwatson> it was a fairly significant problem before that
[02:02] <mdke> you bet
[02:03] <mdke> cjwatson: thanks as always for your wise counsel.
[02:03] <mdke> where has Kamion gone, I miss him a bit
[02:03] <cjwatson> he got too confused with Keybuk
[02:03] <Keybuk> yeah
[02:03] <Keybuk> so confused that they got the same job
[02:04] <cjwatson> heh
[02:05] <mdke> ha
[02:05] <cjwatson> rodarvus: ping, how're mesa/xorg-server/drivers going? those need to happen today
[02:05] <mdke> is that the genuine reason for changing?
[02:05] <cjwatson> well, the impetus was that I was away from home and my home server was inaccessible for some reason I forget, so I used an alternate nick and liked it better
[02:06] <cjwatson> cjwatson's my username everywhere except Launchpad anyway
[02:06] <Keybuk> you can likely get the LP id changed
[02:06] <cjwatson> but I stuck with it for at least partly the reason above :)
[02:06] <cjwatson> yeah, I just can't be bothered at the moment
[02:06] <Keybuk> though they might tell you to make a cjwatson account and merge the kamion one into it <g>
[02:07] <mdke> ok, bed. thanks again for your help
[02:09] <cjwatson> I wonder what happens if I just change the name in the personal details page
[02:09] <cjwatson> whaddayaknow
[02:09] <cjwatson> https://launchpad.net/people/cjwatson
[02:12] <LaserJock> cjwatson: wow, I wondered if that would work
[02:12] <LaserJock> were all your email addresses (canonical and ubuntu) cjwatson already?
[02:13] <cjwatson> yes; well<EMAIL_ADDRESS>might have managed to work I guess but I never used it for anything
[02:13] <LaserJock> hmm, interesting
[02:14] <cjwatson> Canonical employees' e-mail addresses are "special" and not entirely dependent on LP username
[02:14] <cjwatson> s
[02:14] <LaserJock> I tried jmantha the other day but people complained
[02:14] <LaserJock> cjwatson: ahh, that's good
[02:14] <sistpoty> all my colors :P
[02:14] <LaserJock> yeah, sistpoty was the biggest complainer because of his irssi colors
[02:15] <LaserJock> :-)
[02:15] <sistpoty> kvirc even
[02:15] <LaserJock> ah
[02:16] <LaserJock> darn, they need to put some sort of seperator for LP karma
[02:17] <LaserJock> cjwatson's give me a headache trying to figure out how many digits ;-)
[02:18] <cjwatson> oh, meep, what happens to bazaar.launchpad.net/~kamion/
[02:19] <sistpoty> see, there are so many reasons to keep the old nick, even besides my colors ;)
[02:19] <fabbione> keescook: that gdb bug turned out to be gcc
[02:20] <keescook> fabbione: icky! is it a straight-forward fix for gcc?
[02:20] <fabbione> keescook: more or less... we are working on that.
[02:30] <hads> There appears to be a bug in klibc-utils 1.4.30-3ubuntu1 that was synced from Debain, /usr/lib/klibc/bin/fstype is not functioning and messing with booting.
[02:33] <minghua> hads: please report a bug: https://launchpad.net/distros/ubuntu/+source/klibc/+filebug
[02:33] <minghua> hads: comments on IRC usually got lost
[02:33] <minghua> hads: thanks
[02:34] <hads> minghua: Thanks, I was asking in #ubuntu-bugs about the correct process as I didn't see feisty bugs on Launchpad. I'll do that now.
[02:35] <cjwatson> hmm, the change doesn't look obviously wrong
[02:35] <cjwatson> hads: exactly what is breaking?
[02:35] <minghua> hads: yeah, Launchpad is sometimes confusing.  but generally no, for bugs there is no dapper/edgy/feisty differentiation
[02:36] <cjwatson> indeed, don't report it under /distros/ubuntu/feisty
[02:36] <hads> cjwatson: In scripts/local on my system $FSTYPE isn't being populated, so modprobe errors out and therefore / won't mount.
[02:37] <hads> Sorry, scripts/local in the initramfs that is.
[02:37] <cjwatson> and you're absolutely certain that was caused by just the klibc upload?
[02:37] <cjwatson> as opposed to, for example, initramfs-tools, which also got uploaded today?
[02:39] <hads> initramfs-tools hasn't been updated on my system yet, so it could possibly be a sync issue.
[02:39] <hads> But this is the output of fstype
[02:39] <hads> root@snowman:/usr/share/initramfs-tools# /usr/lib/klibc/bin/fstype < /dev/sda2
[02:39] <hads> stdin: error 0
[02:39] <bddebian> Heya
[02:40] <cjwatson> hmm, reproduced
[02:40] <hads> cjwatson: So, no, I'm not absolutely certain. I've just tried to debug it to the best of my ability.
[02:41] <cjwatson> works under strace
[02:41] <cjwatson> (argh)
[02:42] <cjwatson> well, no, it doesn't really, it says FSTYPE=unknown then
[02:42] <hads> It outputs the same error here under strace.
[02:44] <cjwatson> hmm, assumes that pread will return a full block
[03:04] <hads> I've reported as #76675 - thanks for the pointers.
[03:05] <cjwatson> I'm being stymied by a nightmare build system
[03:05] <Hobbsee> cjwatson: it's not yada, is it?
[03:05] <cjwatson> not that kind of build system
[03:06] <cjwatson> (it's cdbs, but I'm not talking about the build system in debian/)
[03:07] <Hobbsee> ah
[03:10] <cjwatson>         if (argc > 1 && argv[1] [0]  == '-' && argv[1] [1]  == '\0') {
[03:10] <cjwatson>                 fd = open(file = argv[1] , O_RDONLY);
[03:17] <_ion> Uh. :-)
[03:17] <ajmitch> that looks special
[03:22] <cjwatson> hmm, the pread64 syscall shim is busted
[04:07] <bddebian> cjwatson: You around?
[04:09] <cjwatson> not really, just finishing this klibc fix and then I'll be off
[04:09] <bddebian> Oh, not a biggie, I was just curious of the best way to tell why a package is in Debian but not in Ubuntu
[04:10] <cjwatson> ask an archive admin ;) it varies - one common reason is that it's in http://people.ubuntu.com/~cjwatson/sync-blacklist.txt
[04:10] <cjwatson> if it's in contrib, contrib packages are only synced on explicit request
[04:11] <bddebian> Hmm, not there.. It's exaile
[04:11] <bddebian> And it's in main
[04:12] <cjwatson> it's listed by new-source, so I assume it's in the queue
[04:12] <cjwatson> just hasn't been done yet
[04:12] <cjwatson> ask Keybuk
[04:12] <bddebian> Gah, OK, sorry
[04:12] <bddebian> Not a big deal
[04:18] <BenC> cjwatson: FYI, I am working on some brokeness caused by klibc and initramfs-tools
[04:20] <cjwatson> BenC: I just uploaded klibc
[04:20] <cjwatson> I don't know if it's precisely the right fix, but it's certainly the simplest
[04:21] <BenC> cjwatson: What did you fix
[04:21] <BenC> ?
[04:24] <cjwatson> BenC: backed out jbailey's headers patch (plus a couple of other minor things)
[04:24] <cjwatson> BenC: explanation in bug 76675
[04:24] <Ubugtu> Malone bug 76675 in klibc "fstype error causes the root filesystem to not mount" [Critical,Fix released]  http://launchpad.net/bugs/76675
[04:25] <BenC> sweet, that's the bug I was having
[04:25] <hads> Yay, cheers cjwatson.
[04:25] <cjwatson> off_t vs. loff_t confusion totally buggered a few syscall shims
[04:25] <BenC> I can upload this initramfs-tools to fix the missing /bin/sh and then I just need to fix the problem with video handling
[04:26] <cjwatson> hads: np, thanks for bringing it up in a timely fashion
[04:26] <cjwatson> *sometimes* notifications of bug reports by IRC do help ;-)
[04:26] <sfllaw> BenC: Who would know the most about why HAL is not getting ACPI power button presses?
[04:26] <hads> heh
[04:26] <cjwatson> BenC: oh, initramfs-tools was busted as well?
[04:26] <BenC> cjwatson: Yeah, missing /bin/sh symlink
[04:26] <cjwatson> fun
[04:26] <sfllaw> Yikes!
[04:26] <cjwatson> surprised anyone noticed the fstype breakage then :)
[04:26] <BenC> me too :)
[04:27] <BenC> must have been ideal archive timing
[04:27] <cjwatson> oh, klibc was uploaded before initramfs-tools
[04:28] <mjg59> Nf.
[04:28] <mjg59> We're going to need to fix wireless-tools
[04:31] <BenC> mjg59: The power state thing?
[04:32] <mjg59> Oh, that's independent
[04:33] <mjg59> But softmac requires that interfaces be up before you can set the essid, which wireless-tools doesn't currently do
[04:35] <zul> BenC, the fstab thing? yeah i noticed this morning but didnt report it :(
[04:36] <zul> oops
[05:08] <BenC> cjwatson: Cool, your klibc + my initramfs-tools gets things booting
[05:11] <fabbione> hey BenC
[05:11] <fabbione> BenC: do you think we can manage a kernel today?
[05:11] <BenC> fabbione: Going to try, fixing this initramfs-tools bug really set me back
[05:11] <fabbione> yeah i saw
[05:12] <mjg59> BenC: There's a dscape-based ipw3945 driver which removes the need for the binary daemon. I'd be keen on getting that tested.
[05:12] <mjg59> I'll try to sort something out for you next week
[05:13] <BenC> mjg59: Ooh!
[05:13] <BenC> where's it at, I'll test the damn thing right now
[05:15] <mjg59> BenC: http://bughost.org/iwlwifi/ - it's not expected to work terribly well right now, but it'd be handy to find out *how* broken it is
[05:16] <mjg59> There's a few references to the daemon in the docs, but as far as I can tell they're just out of date
[05:20] <BenC> mjg59: 4615? Is that the new intel wireless?
[05:23] <mjg59> BenC: Guess so
[05:24] <mjg59> Maybe this isn't entirely public yet, then :)
[05:24] <mjg59> Probably worth testing it, but not sticking it in the tree just yet
[05:29] <Amaranth> heh, initial commit into git was 36 hours ago
[05:30] <fabbione> BenC:
[05:30] <fabbione> dpkg: error processing /var/cache/apt/archives/initramfs-tools_0.85dubuntu1_all.deb (--unpack):
[05:30] <fabbione>  trying to overwrite `/usr/share/initramfs-tools/scripts/local-top/lvm', which is also in package lvm-common
[05:32] <BenC> fabbione: interesting...that file was added in debian's initramfs-tools
[05:33] <BenC> mjg59: Yeah, I'm not even sure I was supposed to ask that question :)
[05:33] <fabbione> BenC: we need to coordinate that with iwj, but he is on vacation. Can you please just not ship it for now?
[05:33] <fabbione> BenC: because we are switching to udev -> lvm
[05:33] <fabbione> and those scripts will almost disappear
[05:36] <BenC> mjg59: Is this driver from Intel?
[05:36] <BenC> I see nothing but Intel copyrights still
[05:36] <BenC> fabbbione: Sure
[07:37] <dholbach> good morning
[07:40] <dholbach> I trust some people complained already about 2.6.20 not being bootable anymore?
[07:41] <Fujitsu> I've heard about it not booting in some circumstances, yes. It works for me, though.
[07:42] <dholbach> it was after the last dist-upgrade - mkinitramfs complains about busybox: not found - not sure if that's a red herring though
[07:52] <orion2012> Would there be any valid reason to have a file in /etc/default be executable?
[07:53] <orion2012> sysklogd seems to do this with two files it installs there
[07:53] <orion2012> the sysklogd init script only sources them though
[07:58] <Hobbsee> good thing i havent dist-upgraded today tehn
[08:02] <orion2012> err, should I be asking elsewhere?
[08:03] <Hobbsee> probably.  or just that the relevant person isnt here
[08:03] <orion2012> ok, thanks
[08:33] <StevenK> Hrm.
[08:34] <StevenK> If I build cyrus-sasl2 with libdb4.3, it seems to pick 4.4, and makes a few things segfault. If I pick 4.2, it's all fine.
[08:54] <sfllaw> dholbach: I don't know if I talked to you or seb128 about it.
[08:55] <sfllaw> dholbach: But I wonder if we should standardize on 96dpi throughout all of *buntu.
[08:56] <dholbach> sfllaw: right, you did talk to me, but I didn't take the idea to seb128 yet
[08:56] <sfllaw> Hmm, OK.
[09:03] <hunger> Any estimation when firehol, etc. will work again on feisty?
[09:05] <lifeless> sfllaw: standardise ?
[09:05] <lifeless> sfllaw: surely dpi depends on the physical medium, not on anything else
[09:07] <sfllaw> lifeless: Yes, but only above certain resolutions.  About 200 DPI is required for things not to look too crazy.
[09:07] <sfllaw> lifeless: See http://scanline.ca/dpi/
[09:07] <sfllaw> lifeless: Interestingly enough, GNOME locks on to 96dpi once you login.
[09:07] <sfllaw> lifeless: But not before.
[09:07] <sfllaw> lifeless: Thereby causing strange font-size artifacts.
[09:08] <lifeless> sfllaw: even after setting it within gnome ?
[09:08] <sfllaw> lifeless: Yes, GDM relies on the X server telling it what DPI to use.
[09:08] <lifeless> prefs->fonts->details->resolution
[09:08] <sfllaw> lifeless: So if you have a monitor that's very large, you get illegible fonts.
[09:08] <lifeless> sfllaw: as it should, only X knows. But its per screen
[09:09] <lifeless> sfllaw: sorry, I'm confused. If you have a large screen, with low dpi, you should tell X (if it does't autodetect) that its a large screen with low dpi
[09:09] <lifeless> and because gnome is braindead, you need to tell gnome that too, separately.
[09:09] <sfllaw> Right.  But then 10pt (not 10px) fonts will be ridiculously small.
[09:09] <sfllaw> lifeless: For GNOME, you _can_ tell it to trust X.  But it's generally a bad idea.
[09:10] <lifeless> sfllaw: ? small? 10pt font is a fixed size. Do you mean lacking detail ?
[09:10] <sfllaw> lifeless: You don't have enough dpi to make arbitrary a 10pt font look good in all circumstances.
[09:10] <sfllaw> A 10pt font is a fixed size in reality.
[09:10] <lifeless> sfllaw: thats right.
[09:10] <lifeless> sfllaw: and this is why you can choose the fonts to be used throughout your desktop
[09:11] <sfllaw> No, they won't hint properly.
[09:11] <lifeless> and there is a formula we can create to set a sane default based on the actual dpi
[09:11] <lifeless> sfllaw: is there a reference for that? I am really really confused
[09:11] <sfllaw> lifeless: Read http://scanline.ca/dpi/ and http://scanline.ca/dpi/fonts.html for a good argument.
[09:11] <lifeless> sfllaw: you seem to be saying 'when X has teh right dpi, and gnome has the right dpi, and fonts that are reasonable for the dpi are chosen, it will look bad
[09:12] <sfllaw> Once we have screens that can pump out 300 DPI or better, then I'll side with the absolute font heights.
[09:12] <sfllaw> lifeless: Yes, I am.  That's because the font renderers will try to make a 10pt font 10/72 inches tall.
[09:12] <Treenaks> sfllaw: I have a 150dpi laptop
[09:13] <lifeless> sfllaw: as they are -meant- to
[09:13] <sfllaw> lifeless: Right.  But you can still see pixels on current screens.
[09:13] <sfllaw> That's the problem.
[09:13] <Treenaks> absolute sizes are SWEET :)
[09:13] <sfllaw> So if you can see individual pixels, then you will see ugliness.
[09:13] <sfllaw> Treenaks: Indeed.  I agree with absolute sizes on media that are paper-like.
[09:13] <lifeless> sfllaw: I dont get the problem. Are you saying 'we should choose fonts based on the available dpi'?
[09:14] <sfllaw> lifeless: No, I'm saying we should lock the DPI to 96, because that's what looks good consistently.
[09:14] <lifeless> sfllaw: garh NONONONONO
[09:14] <sfllaw> Be it a 3" screen or a 96" screen.
[09:14] <sfllaw> lifeless: YES!
[09:14] <lifeless> it looks like shit
[09:14] <sfllaw> lifeless: Excuse me?
[09:14] <Treenaks> dpi should be set to the screen's real DPI
[09:14] <lifeless> I fixed my setup years ago, when I first got a non-96 dpi screen and couldn't stand the brokenness that result
[09:14] <lifeless> ed from having it set to 96 when the screen wasn't.
[09:15] <sfllaw> What broke?
[09:15] <lifeless> the web
[09:15] <lifeless> pdf viewing
[09:15] <lifeless> document editing
[09:15] <lifeless> terminal fonts
[09:15] <sfllaw> You're going to have to explain more.  The web _unbroke_ for me when I set it to 96 DPI.
[09:16] <sfllaw> As for PDF viewing, evince doesn't care much for DPI.
[09:16] <sfllaw> And terminal fonts definitely benefit from proper hinting because of high contrast.
[09:16] <Treenaks> sfllaw: If I force my 150dpi screen to 96dpi, I can't read anything anymore
[09:16] <Treenaks> sfllaw: everything's so SMALL
[09:16] <lifeless> sfllaw: having the dpi match the screen lets hinting work correctly, surely!
[09:17] <sfllaw> lifeless: No, hinting engines aren't good enough.
[09:17] <sfllaw> If you have a very high resolution screen, you can throw out your hinter.
[09:17] <Mithrandir> sfllaw: non-bitmap terminal fonts look like shit in all cases for me, fwiw.
[09:17] <lifeless> so, I can't be arsed right now, I'm on leave.
[09:17] <sfllaw> lifeless: Fair enough.  :)
[09:18] <lifeless> as long as there is an 'UNFUCK ME NOW' button, to let me control this, I will survive.
[09:18] <Mithrandir> on normal 17" desktop screens and 12" laptop screens as well as 20" desktop screens.
[09:18] <sfllaw> I'm only advocating a change to font DPIs.
[09:18] <lifeless> I'll note that windows looks much nicer when you use the supplied knob within windows to set the right DPI for the screen
[09:18] <sfllaw> I used to do that, but had very ugly widgets.  I don't know if that's still the case or not.
[09:19] <lifeless> and what I see when I read that web page is an argument for fixing the hinter not breaking the dpi
[09:19] <lifeless> its also worth asking whether macosX defaults to 72dpi because all their screens are 72 dpi :)
[09:19] <sfllaw> Yes, I know.
[09:19] <sfllaw> Vertical control makes some things better.
[09:20] <lifeless> now I *do* support changing the fallback default in X to 96dpi
[09:20] <lifeless> because I think that is a saner default than 75
[09:20] <lifeless> but when X has been told by the hardware whats what, it should trust it (modulo a blacklist we can construct)
[09:21] <lifeless> as for the web, its defined very strictly in terms of dpi - even png's have a defined dpi for web rendering.
[09:22] <tepsipakki> btw, stay away from the HP LP3065 30" screen.. it supports _only_ the max resolution (2560x1600), nothing else :/
[09:22] <lifeless> Treenaks: everything is small because font sizes are all defaulted to ~96 dpi environments - and that will fuck the web for you, because stylesheets are defined in terms of pt's, not in terms of pixels.
[09:22] <sfllaw> lifeless: Actually, that's not quite accurate.
[09:23] <Treenaks> pixels are a relative unit, according to the spec :)
[09:23] <lifeless> Treenaks: if the css author defined their fonts as large,larger etc, it will work better once you change your browser defaults
[09:23] <lifeless> Treenaks: yup
[09:23] <lifeless> pixels are not pixels on the web :)
[09:23] <sfllaw> lifeless: The web is completely messed up, because people will intermix points and pixels.
[09:23] <Treenaks> lifeless: I blinked a few times when I read that
[09:23] <lifeless> sfllaw: they are allowed to. pixels are defined as not being pixels
[09:24] <sfllaw> lifeless: You do know that Opera is the only browser that actually honours CSS pixels, right?
[09:25] <lifeless> http://www.w3.org/TR/REC-CSS2/syndata.html#length-units
[09:25] <sfllaw> I know the standard!
[09:25] <lifeless> sfllaw: I wasn't, but it doesn't surprise me, opera is pretty awesome
[09:25] <sfllaw> It is, barring their non-freeness.
[09:25] <lifeless> naturally
[09:26] <lifeless> its why I dont use it
[09:26] <lifeless> anyhow, this also covers the LCD projector argument, because thats clearly a case of wanting to preserve the visual angle
[09:26] <sfllaw> I'm basically looking for relative sanity in rendering text until we get digital paper.
[09:26] <lifeless> anyhow, dinner time, and I've had my anti-rant. Just give me a knob to unfuck whatever evilness is done, and I'm happy.
[09:27] <sfllaw> All right.
[09:27] <sfllaw> Have fun!
[09:27] <lifeless> oh, one last point.
[09:27] <pitti> carlos: any idea why there are no new langpacks on your people page since Dec 15?
[09:27] <lifeless> don't tell *anyone* doing serious artwork/production that we're considering this
[09:28] <pitti> lifeless: Hi Rob
[09:28] <carlos> pitti: no idea, let me check...
[09:28] <sfllaw> lifeless: Oh man.  The GDM startup screen is where I noticed this bug.
[09:28] <sfllaw> lifeless: The screen optimized for someone's laptop looked terrible on a 40" monitor.
[09:28] <carlos> pitti: db changes, I need to update my tree
[09:28] <pitti> lifeless: FYI, I changed the apport code structure to the python package approach we discussed; also, the apport report now has proper methods to add debug info (I got rid of that apport_utils.py entirely)
[09:28] <carlos> pitti: updating it...
[09:29] <pitti> carlos: btw, feel free to clean up all the old tarballs, they need an awful lot of space
[09:29] <carlos> ok
[09:29] <carlos> pitti: thanks for the warning
[09:29] <pitti> carlos: thank you for fixing :)
[09:29] <sfllaw> lifeless: Especially because the theme was done entirely in screen pixels.
[09:33] <lifeless> pitti: sweet
[09:33] <sfllaw> pitti: Huzzah!
[09:34] <lifeless> pitti: so also, we needed to talk about reporting failures from other users.
[09:35] <lifeless> pitti: I think its important we allow this, so that a crash of e.g. a cron job under root, can be inspected and reported by the user
[09:37] <pitti> lifeless: right; TTYL, need to run out for a bit
[09:37] <lifeless> kk
[09:56] <tepsipakki> both amd64 and ia64 failed to build checkinstall, "error: conflicting types for 'readlink'"
[09:57] <tepsipakki> any ideas?
[10:22] <Mithrandir> pitti: is it on purpose pmount isn't part of ubuntu-desktop any more?
[10:34] <Hobbsee> :)
[10:35] <sivang> morning
[10:36] <sivang> interesting, can someone please renew my ubuntumembers membership? (it emaild me about expirey)
[10:37] <sivang> (and @u.c emails sent to)
[10:42] <imbrandon> it shouldent effect planet
[10:42] <imbrandon> but @mail no idea
[10:43] <sivang> already asking in #lp
[11:12] <pitti> Mithrandir: yes, it is
[11:12] <pitti> Mithrandir: the hal mounting backend now doesn't use pmount any more
[11:12] <pitti> Mithrandir: and everything else calls the hal functions now
[11:13] <seb128> hey pitti
[11:13] <pitti> I'm not actually here, mind you :)
[11:13] <seb128> pitti: you should really not join on IRC during holidays ;)
[11:14] <seb128> hi tkamppeter, is cups known to be broken on feisty? like it refuses to add a printer
[11:14] <seb128> gnome-cups-manager prints a "** (gnome-cups-add:6933): WARNING **: IPP request failed with status 1280" and doesn't add the printer
[11:14] <tkamppeter> No, did not hear about such a problem. No one reported a bug about CUPS in Feisty.
[11:14] <seb128> the web UI displays a ""413 Request Entity Too Large" page
[11:15] <seb128> when trying to add an HP deskjet usb printer
[11:15] <hunger> initramfs-tools and lvm-common conflict over /usr/share/initramfs-tools/scripts/local-top/lvm
[11:15] <Mithrandir> pitti: oh, ok.  It seems g-v-m might need an update?  At least, I didn't get the usual "camera plugged in" dialog when I connected my card reader.
[11:16] <pitti> Mithrandir: hm, worked fine for me, but the new libgphoto upstream version might have broken with your cam; can you please file a bug?
[11:16] <pitti> Mithrandir: source package depends on whether gthumb can access the cam if you request a photo import from the menu
[11:16] <Mithrandir> pitti: sure.  It's just a regular sandisk USB mass storage device.
[11:16] <pitti> Mithrandir: ah, mass storage, then it's not libgphoto
[11:17] <pitti> Mithrandir: can you please file a g-v-m bug with the https://wiki.ubuntu.com/DebuggingRemovableDevices info?
[11:17] <tkamppeter> I have set up a printer (USB) with the web interface now and printed a test page, on a completely updated Feisty. CUPS seems to be perfect for me.
[11:17] <pitti> seb128: ^ WFM, too (just added a new printer yesterday)
[11:17] <Mithrandir> pitti: also, I don't see the device on my desktop, but that's probably something fucked in nautilus, somewhere.
[11:17] <seb128> pitti, tkamppeter: let me try again
[11:18] <seb128> Mithrandir: is it listed to computer:?
[11:18] <pitti> Mithrandir: but that's a good hint, might actually be the same reason
[11:18] <pitti> Mithrandir: sounds more like a hal bug now; is the device mounted automatically?
[11:18] <hunger> Mithrandir: I didn't get an icon in KDE for my CDs anymore either, but that is probably unrelated.
[11:19] <tkamppeter> mvo has uploaded my new splix package yesterday and it still did not arrive in the repositories, checked both http://archive.ubuntu.com/ubuntu/pool/universe/s/ and http://archive.ubuntu.com/ubuntu/pool/main/s/
[11:19] <Mithrandir> pitti: yes, it's mounted.
[11:19] <tkamppeter> How long will this take?
[11:19] <pbor> hunger: for what is worth I just reported the lvm conflict in launchpad (76708)
[11:19] <hunger> pbor: Thanks!
[11:20] <Mithrandir> seb128: no, or rather, I see an icon for "generic STORAGE DEVICE" and it mounts the device again when I double click that icon.
[11:20] <hunger> pbor: I try to avoid using LP;-)
[11:21] <seb128> pitti, tkamppeter: works fine today, go wonder, thanks anyway ;)
[11:21] <Hobbsee> tkamppeter: did it build?
[11:22] <seb128> Hobbsee: that's a NEW package
[11:22] <Hobbsee> ah right
[11:22] <seb128> tkamppeter: until somebody accept it from NEW
[11:22] <tkamppeter> Hobbsee, on my 32-bit laptop it builds, and on 64 bit it should build, too (some months ago I added it to Mandriva). I did not get any feedback from mvo or from a Ubuntu bot about any build problems.
[11:23] <tkamppeter> seb128, who has to accept it? Can someone here do so?
[11:23] <Hobbsee> tkamppeter: if it's sitting in NEW, then it tends to take a while
[11:23] <seb128> not sure if Mithrandir does NEW atm
[11:24] <tkamppeter> Where is NEW? Can I see what is currently in NEW?
[11:24] <Mithrandir> seb128: I'm on VAC, but I can NEW for stuff which is blocking development
[11:24] <Hobbsee> yes, it's on LP, but i dont have the direct link, and i'm on a different OS
[11:24] <Mithrandir> seb128: as in, I'll do it by request, but not actively go looking at it.
[11:25] <seb128> Mithrandir: apparently tkamppeter is waiting on splix
[11:25] <tkamppeter> Mithrandir, can you accept splix? Thanks. Many Samsung printer uses will get a nice xmas present by that.
[11:26] <Mithrandir> tkamppeter: I can review it when I get home in a couple of hours, sure.
[11:27] <tkamppeter> Mithrandir: OK.
[11:32] <pitti> Mithrandir: ok, please file a bug against g-v-m with the debug data then; I'll reassign it to hal if approriate
[11:36] <pbor`> running gdb crashes my system... just good old printf today
[11:39] <seb128> pbor`: use 2.6.17, linux-image-2.6.17-10-generic is still available
[11:39] <seb128> I do that
[11:39] <Mithrandir> pitti: I'll do that when I get back from yule shopping.
[11:39] <pitti> Mithrandir: 'yule'?
[11:39] <Mithrandir> christmas
[11:39] <pitti> is that the Norwegian Christmas?
[11:39] <pitti> ah
[11:39] <Mithrandir> 'cept I'm not christian, so it's less christ and more mas.  Or something. :-P
[11:40] <pbor`> seb128: that's for the suggestion
[11:40] <pbor`> s/that's/thanks
[11:40] <seb128> np
[12:41] <cjwatson> rodarvus: ping, X
[12:47] <StevenK> cjwatson: Since he isn't here, might I raise my concern with you?
[12:52] <cjwatson> StevenK: that depends what it is?
[12:53] <cjwatson> I mean, sure, you can try :)
[12:54] <StevenK> cjwatson: Looking at the cyrus-sasl2 merge, Keybuk made a change to have it build against libdb4.3. If I do that, saslpasswd2 segfaults, but if I build it against 4.2, it's fine.
[12:54] <cjwatson> oh, sorry, I have no idea ...
[12:54] <StevenK> Right. When's the deadline?
[12:55] <cjwatson> later today
[12:55] <cjwatson> usually the distro team meeting
[01:10] <sivang> cjwatson: any idea what can I do with my membership auto-expiery ? Can you or someone else from CC renew my membership?
[01:17] <cjwatson> sivang: next CC meeting I guess
[01:18] <cjwatson> we don't have an established procedure yet - it will probably be fairly trivial though
[01:18] <cjwatson> "are you still alive?" "yes" "NEXT"
[01:18] <cjwatson> but I don't want to do it unilaterally
[01:18] <Hobbsee_> heh
[01:19] <Hobbsee_> too bad if someone answers "no"
[01:24] <ogra> cjwatson, could it be that something in pam changed that can cause bug 76632 ? i run the 2.17.4 version here but with a non updated libpam and dont see the bug, whereas nearly everyone else with an up to date system seems to see it
[01:24] <Ubugtu> Malone bug 76632 in gnome-screensaver "screen does not unlock after locking" [Undecided,Confirmed]  http://launchpad.net/bugs/76632
[01:24] <ogra> (the 2.17.4 version of gnome-screensaver i mean)
[01:41] <cjwatson> ogra: I don't think so - the only change in pam_unix was a trivial segfault fix
[01:42] <cjwatson> there don't seem to be any messages in the posted auth.log from gnome-screensaver?
[01:46] <jinty> hi, anyone know where I can find Henrik Nilsen Omma (henrik I guess)?
[01:46] <dholbach> jinty: heno is his nick.
[01:46] <gnomefreak> is mvo on holiday?
[01:46] <dholbach> gnomefreak: yes
[01:46] <gnomefreak> thought so ty
[01:47] <jinty> dholbach: any chance he'll be around today? Or can I find anyone else with access to the support services for schooltool.org?
[01:47] <dholbach> jinty: hang on, I'll have a look if he's on holidays already
[01:48] <dholbach> jinty: I suppose he'll be around during the day.
[01:49] <jinty> dholbach: thanks, i'll wait a while then before trying other things!
[01:52] <cjwatson> henrik is off with technical problems at the moment
[01:52] <cjwatson> he wasn't sure whether he'd be back on today
[01:53] <StevenK> Keybuk: Looking at the cyrus-sasl2 merge, you made a change to have it build against libdb4.3. If I do that, saslpasswd2 segfaults, but if I build it against 4.2, it's fine. Any thoughts?
[01:53] <Keybuk> no idea, I just took that change from the previous merge
[01:54] <StevenK> Right, I'll drop it, and note I've done so.
[02:03] <tepsipakki> fujitsu: <sigh> why do they differ?
[02:03] <tepsipakki> damn
[02:16] <StevenK> Now, who can I bug to look at my cyrus-sasl2 merge?
[02:46] <olemke> ogra: it seems to be g-s's fault really. downgrading pam to the version from edgy doesn't solve the issue but running g-s 2.16.1 with the latest pam works
[02:50] <fabbione> dpkg: error processing /var/cache/apt/archives/initramfs-tools_0.85dubuntu2_all.deb (--unpack):
[02:50] <fabbione>  trying to overwrite `/usr/share/initramfs-tools/scripts/local-top/lvm', which is also in package lvm-common
[02:50] <fabbione> BenC: didn't you fixed this one?
[02:50] <BenC> fabbione: Just uploaded the fixed package
[02:50] <BenC> ubuntu3
[02:50] <fabbione> ah ok
[02:51] <BenC> also fixes the vga16fb loading that was corrupting displays
[02:51] <fabbione> eheh
[02:51] <BenC> new initramfs-tools has some nice stuff in it though
[02:51] <BenC> like video=<fb>:<opts> parsing
[02:52] <BenC> And if I'm not mistaken, the resume machinery now supports suspend2
[03:03] <fabbione> StevenK: did you test it properly?
[03:04] <fabbione> StevenK: if i can take your word for that, i will sponsor
[03:05] <fabbione> but don't ask me to do extra review...
[03:05] <fabbione> ok.. new gcc fixes gdb properly
[03:05] <fabbione> YEPPA
[03:07] <StevenK> fabbione: It installs and saslpasswd2 doesn't segfault like it did.
[03:07] <fabbione> StevenK: slam the debdiff somewhere
[03:08] <StevenK> Against the latest Debian or Ubuntu version?
[03:11] <fabbione> StevenK: if you want me to sponsor an upload/merge, i need it against the latest ubuntu package
[03:13] <StevenK> fabbione: http://wedontsleep.org/~steven/cyrus-sasl2.patch
[03:13] <StevenK> fabbione: Thanks
[03:18] <fabbione>   cyrus-sasl2_2.1.22.dfsg1-8ubuntu1_source.changes: done.
[03:18] <fabbione> Successfully uploaded packages.
[03:18] <fabbione> StevenK: now you get the blame if it breaks
[03:19] <StevenK> I figured. :-)
[03:40] <bddebian> Heya
[04:10] <cbx33> ping mdz
[04:11] <Keybuk> cbx33: unlikely to respond at 7am
[04:11] <cbx33> oh i dunno :p
[04:11] <cjwatson> ... while on holiday
[04:11] <cbx33> cjwatson, Christmas miracle?
[04:12] <cbx33> was wondering if anyone could shed any light on a little problem I have then
[04:12] <cbx33> the ldm glade file won't open in glade....stating it needs a gnomecanvas catalog
[04:12] <cbx33> I've looked around but am unable to find anything like that
[04:12] <cbx33> any clues?
[04:13] <Keybuk> I can safely say that mdz is likely to give a very vacant look if you asked him that :)
[04:14] <cbx33> oh...someone said he was the origial author of ldm
[04:15] <ogra> cbx33, yes, all the backend code is his
[04:15] <cbx33> oh....
[04:15] <bddebian> cbx33: Does gnomecanvas come from diacanvas2?
[04:15] <ogra> and remained unchanged in most parts
[04:15] <cbx33> ogra, who did the font end?
[04:16] <ogra> me
[04:16] <cbx33> ah...
[04:16] <cbx33> then maybe you can shed light
[04:16] <ogra> bddebian, gnomecanvas is the pre-cairo ;)
[04:16] <ogra> its older thqan diacanvas
[04:16] <bddebian> Ahh OK :-)
[04:16] <bhale> man
[04:17] <cjwatson> phew, libx11 merged
[04:17] <bhale> cairo dia would be awesome
[04:17] <bhale> with some hot stock art
[04:17] <Keybuk> cjwatson: enjoy
[04:17] <ogra> i guess thats about to come at some point :)
[04:18] <Keybuk> a GNOME app something of a cross between Visio and Graphviz would be nice
[04:18] <ogra> olemke, well, i dont see it at all here on three machines that arent fully upgraded but use the latest screensaver package
[04:18] <cbx33> so ogra anyway i can thi s working
[04:18] <ogra> thats why i suspect its someting else
[04:18] <bddebian> bhale: Good, help me fix diacanvas2 then ;-P
[04:19] <ogra> cbx33, i think you need python-gnomecanvas installed
[04:19] <ogra> try that
[04:19] <cbx33> ok I'll check that
[04:19] <cbx33> thanks bud
[04:19] <cbx33> was pulling my hair out the other day
[04:21] <bhale> bddebian: meh.
[04:21] <cbx33> ogra, as I suspected
[04:22] <cbx33> python-gnomecanvas is still installed
[04:22] <cbx33> is aready installed
[04:23] <cbx33> any futher ideas?
[04:24] <bddebian> cbx33: Is it looking in the right place? :)
[04:24] <cbx33> bddebian, I'm not sure.....if it isn't then that's a bug surely?
[04:37] <Simira> cjwatson: found your camera yet?
[04:42] <olemke> ogra: i don't know if it helps, but here's the strace log after entering the password http://ubuntu.pastebin.com/842665
[04:45] <ogra> i dont see anything suspicious ...
[05:46] <fabbione> Unpacking replacement initramfs-tools ...
[05:46] <fabbione> dpkg: error processing /var/cache/apt/archives/initramfs-tools_0.85dubuntu3_all.deb (--unpack):
[05:46] <fabbione>  trying to overwrite `/usr/share/initramfs-tools/scripts/local-top/lvm', which is also in package lvm-common
[05:46] <fabbione> BenC: this is ubuntu3
[05:46] <fabbione> still error there
[05:54] <BenC> fabbione: I was sure I removed that
[05:54] <fabbione> dpkg lies :)
[06:58] <desrt> uhm.  hi.
[06:58] <desrt> The following packages will be REMOVED: startup-tasks system-services ubuntu-minimal upstart upstart-compat-sysv upstart-logd
[06:58] <desrt> The following NEW packages will be installed: sysvinit
[06:59] <desrt> ^^ apt-get dist-upgrade on a system that's currently running edgy
[07:00] <_ion> What does apt-cache madison sysvinit say?
[07:01] <desrt> odd.  it's trying to come from breezy.
[07:01] <desrt> i guess having old distributions in your apt.sources isn't legit?
[07:02] <desrt> i'd sort of assume that as long as you didn't have -security or -updates then you'd pretty much be okay because the old distro would only have older versions of everything....
[07:12] <Seveas> desrt, problem is that sysvinit is essential in breezy
[07:12] <Seveas> so it will install it :)
[07:12] <desrt> it was never a problem until just now
[07:12] <desrt> very odd.
[07:14] <dade`> desrt: did you debugged new kernels for sleep on macbooks ?
[07:15] <desrt> dade`; no.  i have not.
[07:15] <desrt> no idea what's wrong this time
[07:15] <desrt> and i have significantly less desire to find out.
[07:15] <dade`> noo
[07:15] <dade`> you were my only hope
[07:15] <desrt> sorry..  last time was painful enough.  i don't feel like going through it again.
[07:16] <desrt> try git disecting :)
[07:19] <dade`> desrt: will someone do that ?
[07:19] <desrt> dade`; you could :)
[07:19] <dade`> desrt: i have a life
[07:19] <desrt> dade`; so do the rest of us
[07:19] <dade`> and i'm not good enough
[08:06] <fabbione> distro meeting is in 2 hours, right?
[08:07] <Ng> is gnome-screensaver supposed to not accept my password in feisty atm? ;)
[08:08] <cge> Ng: I haven't had that happen yet.
[08:08] <somerville32> @schedule
[08:08] <Ubugtu> Schedule for Etc/UTC: 21 Dec 21:00: Ubuntu Development Team | 27 Dec 12:00: Edubuntu | 28 Dec 08:00: Ubuntu Development Team | 02 Jan 20:00: Technical Board | 03 Jan 20:00: Edubuntu | 03 Jan 22:00: Xubuntu
[08:09] <Mithrandir> Ng: I don't think it's _supposed_ to happen, but I see the same thing.
[08:09] <Ng> Mithrandir: I figured it wasnt a new feature ;)
[08:10] <kylem> the ultimate in security.
[08:10] <Mithrandir> kylem: apart from it causing me to C-A-F1 + killall gnome-screensaver, yeah.
[08:12] <ogra> Ng, i'll upload a patched version after the distro meeting
[08:13] <ogra> hopefully that fixes it
[08:14] <Ng> groovy :)
[08:15] <ogra> bug 76632 is the corresponding bug btw
[08:15] <Ubugtu> Malone bug 76632 in gnome-screensaver "screen does not unlock after locking" [Undecided,In progress]  http://launchpad.net/bugs/76632
[08:15] <mdke> nice, that's bitten me too
[08:15] <cbx33> ogra, you fixed it
[08:15] <cbx33> way to go
[08:15] <ogra> seems upstream has a patch, but indeed it doesnt apply without manual work ... so give me some time
[08:15] <cbx33> what's the best text to speech engine we have?
[08:15] <cbx33> festival?
[08:16] <ogra> thats the default one iirc
[08:16] <cbx33> anyone know of any better ones?
[08:16] <ogra> dunno if thats the best though
[08:21] <keescook> has anyone looked the icon situation in firefox?  I'm building up the <IP_ADDRESS> release, but when I tried to fix the icons, it ah... stopped having any icons at all.  ;)
[08:32] <toma> anyone know, how often is the new queue of the archive processed?
[08:35] <fabbione> toma: every hour
[08:35] <fabbione> or hold on
[08:36] <fabbione> the queue is processed every 5 minutes or so
[08:36] <fabbione> but to get a binary in the archive from the upload (assuming the binary takes less than one hour to build) it takes approx 2 hours
[08:36] <toma> fabbione: i mean the list at https://launchpad.net/distros/ubuntu/feisty/+queue
[08:36] <fabbione> so upload -> source into archive is about one hour
[08:37] <fabbione> -> down to the buildd (+build time) -> back to archive (another hour assuming the build time < 60minutes)
[08:38] <fabbione> toma: if you mean NEW packages, that's done manually
[08:38] <fabbione> it depends when people have time
[08:38] <toma> fabbione: okay
[08:39] <toma> fabbione: i'll wait a bit more then
[08:39] <toma> thanks
[08:41] <fabbione> toma: don't sweat it tho.. a lot of people are in holidays right now
[08:42] <toma> fabbione: hmm, too bad. holidays should be forbidden anyhow
[09:16] <ajmitch> you may be waiting a little while
[09:16] <desrt> i wonder what an organ-grinding gesture is
[09:25] <tkamppeter> @schedule paris
[09:25] <Ubugtu> Schedule for Europe/Paris: 21 Dec 22:00: Ubuntu Development Team | 27 Dec 13:00: Edubuntu | 28 Dec 09:00: Ubuntu Development Team | 02 Jan 21:00: Technical Board | 03 Jan 21:00: Edubuntu | 03 Jan 23:00: Xubuntu
[09:32] <sladen> @schedule london
[09:32] <Ubugtu> Schedule for Europe/London: 21 Dec 21:00: Ubuntu Development Team | 27 Dec 12:00: Edubuntu | 28 Dec 08:00: Ubuntu Development Team | 02 Jan 20:00: Technical Board | 03 Jan 20:00: Edubuntu | 03 Jan 22:00: Xubuntu
[09:32] <keescook> desrt: http://en.wikipedia.org/wiki/Organ_grinder
[09:32] <keescook> mostly just a cranking motion next to my machine.  trying to make it run faster.  :)
[09:33] <sladen> the instrustment might have wood-worm, that'd count as a bug
[09:33] <bhale> sladen: oh that rules
[09:35] <geser> is it normal that a package is in "Needs building" state for nearly 8 days?
[09:35] <bhale> geser: could it be NEW?
[09:35] <keescook> geser: which package?
[09:36] <geser> https://launchpad.net/+builds/+build/285683
[09:36] <geser> it changed two minutes ago :)
[09:38] <keescook> E: Couldn't find package libneon26-dev
[09:38] <keescook> libneon26-dev is in universe, but subversion is in main, so it won't build.
[09:41] <tkamppeter> How is the progress on the package Splix which is in NEW?
[09:42] <geser> should it be build against libneon25-dev? or should neon26 move into main and replace neon?
[09:44] <mjg59> tkamppeter: It's quite likely that stuff in NEW won't be processed until after the holidays
[09:59] <keescook> geser: I'm not sure; probably promote libneon26 and demote libneon25.  Someone more familiar with subersion or libneon should probably say.  :)
[10:01] <geser> keescook: have you a suggestion whom should I ask?
[10:01] <keescook> geser: from the changelog, I'd say doko
[10:06] <geser> doko_: are you around?
[10:06] <zyga> hello
[10:26] <doko> cjwatson, Mithrandir: please process sun-java6 in NEW
[10:27] <doko> cjwatson, Mithrandir: please promote neon26 to main (build dependency of OOo, neon25 already is in main)
[10:29] <geser> neon26 is also a build-dependency of subversion
[10:34] <doko> geser: btw, pong
[10:34] <geser> you already solved it with your request to promote neon26
[10:35] <geser> it was about subversion build-depending on libneon26-dev
[10:36] <cjwatson> doko: neon26 promoted
[10:36] <cjwatson> (doesn't need an MIR since neon is already in main)
[10:38] <doko> Mithrandir: if you are around when neon26 shows up in main, pleae requeue openoffice.org and openoffice.org-l10n on i386, amd64, powerpc, sparc
[10:38] <Mithrandir> doko: sure.
[10:38] <Mithrandir> that's just a publisher run away, so about an hour.
[10:38] <doko> cool, thanks
[10:39] <geser> Mithrandir: please requeue also subversion, it waits on libneon26-dev
[10:39] <Mithrandir> geser: that's depwait, it'll be done automatically
[10:39] <Mithrandir> doko: actually, same goes for ooo, it'll be done automatically.
[10:44] <cjwatson> ogra: in case this is what's confusing you, debian-cd doesn't *have* to involve putting the bootability goop onto the CD
[10:45] <cjwatson> ogra: a fair chunk of debian-cd is just logic for getting packages onto the CD, which is all you ened
[10:45] <cjwatson> need
[10:45] <ogra> like apt-ftparchive
[10:45] <cjwatson> sort of, yes
[10:46] <cjwatson> it's all integrated with our CD building and publishing setup already so there's no point in duplicating that
[10:46] <ogra> thats what i thought, i need a seed or something that provides the package list and something like apt-ftparchive that builds the structure, the rest is mkisofs
[10:46] <cjwatson> "something like apt-ftparchive" => debian-cd
[10:46] <ogra> yep i start getting it :)
[10:46] <cjwatson> and of course debian-cd handles mkisofs etc. too
[10:47] <cjwatson> the only fiddly bit is naming the CD output correctly (it's a horrible mess of Makefile, don't ask) and tweaking the cdimage wrapper scripts to germinate it all correctly
[10:48] <ogra> well, with some effort it wont be to hard i think
[10:52] <Burgwork> tkamppeter: there is a nasty regression with samsung printers and cups  1.2.2 in dapper, are you person to talk to about it?
[10:56] <cge> Is there some reason why the default bashrc in feisty sets HISTCONTROL=ignoredups and then immediately replaces it with HISTCONTROL=ignoreboth?
[10:58] <Adri2000> cjwatson: libdjconsole binary packages are in NEW
[10:58] <cjwatson> Adri2000: that's nice :)
[10:59] <Adri2000> hehe, the implicit question was could you approve them? :p
[10:59] <cjwatson> not at 10pm right after a meeting when I really want to get back to the pub, no
[11:00] <tkamppeter> Burgwork: CUPS was always packaged by pitti, and as I entered Ubuntu I was already on Edgy ...
[11:00] <Adri2000> ok, no problem, that will probably be tomorrow :)
[11:00] <cjwatson> either somebody else does them, or it can wait until tomorrow now
[11:00] <Adri2000> okay
[11:00] <sistpoty> cjwatson: and delete a package from new (we have a better version to be uploaded instead the one in new)?
[11:00] <doko> cjwatson: you should get a umts flatrate :-P
[11:00] <tkamppeter> Burgwork: Can you let Ubugtu post a link to this bug here?
[11:00] <Burgwork> yep, just a sec
[11:01] <Mithrandir> sistpoty: just upload a newer version
[11:01] <sistpoty> Mithrandir: that works with the same version number? cool :)
[11:01] <Mithrandir> sistpoty: version numbers are cheap, just bump it.
[11:01] <bddebian> heh
[11:02] <sistpoty> Mithrandir: but the orig.tar.gz has a different md5sum, but no new upstream version... still no probs?
[11:02] <sistpoty> *g*
[11:02] <cjwatson> sistpoty: what's the package name?
[11:02] <Burgwork> https://bugs.launchpad.net/products/cupsys/+bug/55828
[11:02] <Ubugtu> Malone bug 55828 in cupsys "PJL output from 1.2.2 client over IPP" [Unknown,Unconfirmed]
[11:02] <cjwatson> you have 30 seconds :)
[11:02] <sistpoty> cjwatson: klear
[11:02] <sistpoty> *phew*
[11:02] <bddebian> hehe
[11:03] <cjwatson> sistpoty: is the uploader here?
[11:03] <tkamppeter> Thanks, Burgwork.
[11:03] <cjwatson> + -- Marcus Czeslinski<EMAIL_ADDRESS>Sun,  3 Dec 2006 18:38:41 +0100
[11:03] <bddebian> No but the new version is from the same
[11:03] <sistpoty> cjwatson: doesn't look like it... he's czessi_away in -motu
[11:03] <cjwatson> did he request the reject?
[11:04] <bddebian> He built a newer version on REVU
[11:04] <cjwatson> link?
[11:04] <sistpoty> http://revu.tauware.de/details.py?upid=3765
[11:04] <bddebian> http://revu.tauware.de/details.py?upid=3765
[11:04] <bddebian> Gah, you beat me
[11:04] <sistpoty> *g*
[11:04] <cjwatson> I see
[11:04] <cjwatson> sistpoty: please tell him I've rejected it at his request
[11:05] <sistpoty> cjwatson: will do, thanks
[11:05] <cjwatson> (checked #ubuntu-motu logs and found said request)
[11:05] <bddebian> Enjoy
[11:05] <sistpoty> have fun, cjwatson
[11:05] <tkamppeter> Burgwork, this is a simple SRU request issue. In Edgy and Feisty it is fixed and working.
[11:46] <BenC> I hate it when ppl go on tag frenzies in lp
[11:47] <BenC> especially when the tags make no sense
[11:59] <jdong> just wait, one day you will ALL see the merit of me importing all my del.icio.us tags into Launchpad, then you'll be sorry ;-)
[12:04] <BenC> I also hate when random people decide to triage a bug report and then think that they should Assign the bug to themselves
[12:04] <BenC> when it isn't even confirmed yet
[12:05] <Fujitsu> BenC, I love that too! It's really really productive.
[12:05] <BenC> Don't get me wrong, I love the help, but I hate the extra work it sometimes causes :/
[12:06] <BenC> sistpoty: I don't recognize your name, so you aren't on my shitlist as of yet :)
[12:07] <sistpoty> ha, yeeehaa... I guess I only forgot one or two bugs assigned to me so far *g*
[12:07] <BenC> sispoty: But if you've triaged any linux-source-2.6.* bugs and assigned them to yourself for no good reason, please fix ASAP :)
[12:07] <BenC> or even better, fix the bug :)
[12:07] <sistpoty> BenC: no thanks, I'll stay away from linux-source-* for a few miles ;)
[12:07] <sistpoty> I just file bugs on it :P
[12:08] <sfllaw> seb128: Bug 70986 is ready to go into edgy-updates.
[12:08] <Ubugtu> Malone bug 70986 in vino "CoRRE bug prevents connection from Nokia 770 to edgy" [Medium,Fix committed]  http://launchpad.net/bugs/70986
[12:08] <seb128> sfllaw: thank you
[12:10] <sfllaw> seb128: I had to flash my 770.
[12:10] <sfllaw> That took forever to get running.
[12:11] <seb128> and now you can enjoy doing vnc with it ;)