[02:06] <NCommander> does anyone know a good hexeditor?
[02:06] <directhex> bless?
[02:06] <directhex> (no i don't know if it's any good, but it's installed on here)
[02:06] <NCommander> is it graphical?
[02:07] <directhex> yes. is that good or bad?
[02:07] <NCommander> that's good
[02:07]  * NCommander needs to write some MAGIC
[02:08] <directhex> FANTASTIC MAGIC?
[02:08] <directhex> christ on a bike, i should be in bed
[02:08] <NCommander> PHOENIX magic ;-)
[02:08] <directhex> i was busy watching the merriment in #u-motu
[02:08]  * NCommander notes that trying to cook phoenix meat however is an attempt at futatility
[02:09] <Hobbsee> directhex: yes, i'm sharpening my stick, just in case ;0
[02:09] <StevenK> NCommander: If we follow Harry Potter mentality, there is no meat to cook
[02:10] <NCommander> Hobbsee, do you have a specialized stick sharper, or just use a knife?
[02:10] <directhex> if we follow the x-men mentality, it's canibalism!
[02:10] <Hobbsee> NCommander: neither.  I use fire and diamond.
[02:10]  * NCommander is reminded of some sorta crappy rap song ...
[02:11]  * directhex gives up; sleeps
[02:13] <Hobbsee> night directhex
[02:42] <joe-mac> hi all, i've been desperately trying to get the partman-auto-raid functionality to work in preseeding. i discovered the partman-auto-raid udeb is not in the install tree. i basically just need to know at this point, how do you tell the debian installer to recognize a new udeb, without going through the process of building a whole new install tree?
[02:43] <StevenK> anna-install or something similar
[02:45] <TheMuso> Thats if the package metadata knows about the udeb in the first place.
[02:45] <TheMuso> s/knows/has/
[02:47] <joe-mac> Thanks for teh response guys, so TheMuso by package metadata you mean the Packages file for that tree under the pool?
[02:47] <TheMuso> joe-mac: Yes, the file that stores all info about a package, its name, version, MD5sums etc.
[02:48] <joe-mac> alright, i'll look into this anna-install, and add the package to the Packages file. i really hope that works... won't be able to tell til tomorrow morning, but thanks first glimmer of hope i've had all day
[05:10] <calc> anyone happen to know the name of the wiki blueprint/spec template?
[05:11] <persia> calc, https://wiki.ubuntu.com/SpecTemplate ?
[05:11] <calc> ah yes that's it :)
[05:13] <persia> For namespace conservation reasons, I'd advocate putting your result at https://wiki.ubuntu.com/Specs/${ camelcase(blueprint_name)}
[06:30] <dholbach> good morning
[06:44] <ion_> Howdy
[07:11] <lukehasnoname> Morning
[07:13] <roccity_> does any think that there may be a need for a user name generator in ubuntu
[07:13] <roccity_> for corps and such?
[07:13] <lukehasnoname> I don't know who would be responsible for this... by default, in .bashrc, the block that loads .bash_aliases if it exists is commented out. 1) Why is that? It seems pointless to have the code in there by default, the way it is designed, if you're going to comment it out. 2) Who could change this?
[07:14] <roccity_> or is it best to leave that to the techs of the company
[07:18] <pitti> Good morning
[07:18] <StevenK> Morning pitti!
[07:19] <persia> roccity_, Probably best to leave that to organisations: there's far too many different schemes in use.
[07:23] <lukehasnoname> hm
[09:05] <thekorn> pitti, hello, I created lp:~thekorn/apport/api.launchpadlib this morning, don't know if this makes sense at this stage, but it's working
[09:06] <pitti> thekorn: cool!
[09:06] <pitti> thekorn: unfortunately, as I said, I can't use launchpadlib from ronne (where the retracer lives) until its networking gets fixed
[09:07]  * pitti hugs thekorn
[09:07] <thekorn> pitti, yes, so get this networking fixed ;)
[09:07]  * thekorn hugs pitti back
[10:24] <fabbione> morning guys
[10:24] <soren> o/
[10:24] <fabbione> any archive admin around that could please process NEW for redhat-cluster in jaunty?
[10:25] <fabbione> hi soren
[10:28] <fabbione> soren: the last updates to libvirtd in hardy are crap. They overwrote my configurations
[10:28] <fabbione> soren: got default network back again and all the machines that were supposed to autostart didn't because the autostart symlinks were purged
[11:02] <doko__> lool: mbr tests fail on 32bit
[11:05] <lool> doko__: I know; but only on the official buildds; not on my host nor on ppa buildds
[11:05] <doko__> infinity: ^^^
[11:06] <lool> doko__: You're welcome if you like to look into it; IIRC it fails in mmap() or something
[11:07] <cjwatson> fabbione: done
[11:09] <fabbione> cjwatson: thanks a lot
[11:09] <lool> So I have an issue with autoreconf -fi in rpm; it ends up replacing po/Makefile.in.in with gettext's, but gettext's doesn't define top_builddir yet uses it
[11:10] <lool> The build ends up failing not finding "/config.status" because of this target:
[11:10] <lool> Makefile: Makefile.in.in Makevars $(top_builddir)/config.status @POMAKEFILEDEPS@
[11:10] <lool> My understanding is that gettext's Makefile.in.in should have a top_builddir = @top_builddir@ snippet at the top
[11:12] <lool> (e.g. intltool's does it)
[11:16] <cjwatson> lool: top_builddir is set in Makevars
[11:16] <cjwatson> or should be - it's in the template
[11:16] <lool> Aha, after the autoreconf, there isn't the -# Makevars gets inserted here. (Don't remove this line!)
[11:16] <lool> Ah there is, just saw the removal in the diff
[11:17] <cjwatson> this can happen when you do gettextize and intltoolize in the wrong order
[11:17] <cjwatson> (or similar)
[11:17] <lool> cjwatson: I'm just running autoreconf -fi
[11:17] <cjwatson> I bet that your po/Makefile.in.in is not really the one from gettext, but is rather the one from intltool
[11:17]  * lool rekicks the build
[11:18] <cjwatson> or is some other broken thing
[11:18] <lool> cjwatson: Well the one from intltool sets top_builddir and this one doesn't
[11:18] <cjwatson> intltool does because it doesn't have Makevars to do it
[11:24] <lool> cjwatson: I see the Makevars line, but it doesn't get replaced with a top_builddir
[11:25] <lool> cjwatson: Actually the line stays in Makefile
[11:26] <lool> configure.ac has AM_GNU_GETTEXT_VERSION([0.11.2])
[11:26] <lool> AM_GNU_GETTEXT([external])
[11:26] <cjwatson> if the "inserted here" line is getting removed from Makefile.in.in, that would seem to be the problem ...
[11:26] <lool> cjwatson: No it's not
[11:27] <lool> cjwatson: It's still in the po/Makefile during the build
[11:27] <cjwatson> but Makevars isn't?
[11:27] <lool> cjwatson: I see vars, not sure whether these are the Makevars, but no top_builddir
[11:28] <cjwatson> this source looks broken
[11:28] <cjwatson> I think, actually, it's from a really old version of gettext
[11:28] <lool> I see the sed in config.status
[11:28] <cjwatson> and that attempting to autoreconf it with current tools is liable to blow up
[11:28] <cjwatson> it needs a decent upstream
[11:29] <lool> cjwatson: Ok; I wished to fix the FTBFS without going with a new upstream release
[11:29] <lool> But it seems that's not easy
[11:29] <cjwatson> have you tried using its autogen.sh (possibly fixing it to use --install where appropriate)?
[11:29] <cjwatson> that doesn't run autopoint
[11:29] <lool> Ok; will try that
[11:31] <Keybuk> cjwatson: so I'm trying to decide whether I need to add Depends: udev to cope with the /etc->/lib transition
[11:31] <Keybuk> what do you think?
[11:31] <pitti> seb128: F9 to F11 started controlling volume/mute for me yesterday; do you get that as well?
[11:31] <cjwatson> Keybuk: to what package?
[11:31] <Keybuk> all of them
[11:31] <lool> Keybuk: Did you see #314879 BTW
[11:32] <Keybuk> none of the packages currently shipping udev rules have any form of dep on udev
[11:32] <lool> I guess so, but when in doubt
[11:32] <cjwatson> Keybuk: it seems more like udev Breaks: (everything else)
[11:32] <Keybuk> which, given the rule files tendancy to change
[11:32] <seb128> pitti: no but I didn't dist-upgrade yet
[11:32] <cjwatson> Keybuk: pcmciautils Depends: udev
[11:32] <seb128> pitti: that's not likely due to a GNOME change though, could be acpi or something?
[11:32] <Keybuk> lool: no, but I suspect that has more to do with soren
[11:32] <pitti> Keybuk: but for some packages it might even be justified to not depend on udev
[11:33] <Keybuk> cjwatson: that's the one package I didn't touch :-)
[11:33] <pitti> seb128: haven't looked into it at all yet
[11:33] <lool> Keybuk: downgrading udev fixes it?!
[11:33] <Keybuk> pitti: you can't not have udev in Ubuntu
[11:33] <cjwatson> actually the new package definitely Breaks: udev (<< 136-1) surely?
[11:33] <soren> Keybuk: What did I do now?
[11:33] <Keybuk> soren: I mean that's what you're looking into, no?
[11:33] <Keybuk> cjwatson: isn't Breaks the wrong way round?
[11:33] <cjwatson> which seems like a more appropriate relation
[11:33] <Keybuk> that deconfigures udev, rather than the package
[11:34] <soren> Oh, right. I just saw my name mentioned and wasn't caught up on scollback :)
[11:34] <cjwatson> Keybuk: in practice it forces udev to be upgraded :)
[11:34] <Keybuk> that sounds sane then
[11:35] <cjwatson> the alternative is putting Breaks in udev but I can see why you might find that painful to maintain
[11:35] <Keybuk> hmm
[11:35] <Keybuk> if I apt-get install one of these packages from jaunty onto intrepid
[11:35] <Keybuk> will it upgrade udev?
[11:35] <Keybuk> and if I dpkg -i one, will it complain about udev being too old?
[11:36] <cjwatson> 1) yes provided apt has a source for the new udev 2) er not sure, worth a test
[11:39] <Keybuk> hmm
[11:39] <Keybuk>  installing libmtp8 would break udev, and
[11:39] <Keybuk>  deconfiguration is not permitted
[11:40] <Keybuk> if you follow its instruction, it "deconfigures" udev
[11:40] <lool> soren: Oh you're chasing that boot on lvm udev issue?
[11:40] <Keybuk> forcing that does complain that you need to upgrade udev
[11:40] <lool> Keybuk: Did you notice a couple of conffiles show up as obsolete now?  You might want to rm_conffile them
[11:40] <Keybuk> so other than the language, that looks ok
[11:40] <Keybuk> lool: example?
[11:40] <lool> Keybuk: In the bug report
[11:40] <Keybuk> soren: we should use Breaks then
[11:41] <Keybuk> lool: which report?
[11:41] <lool> #314879
[11:41] <StevenK> cjwatson: So, according to the ubuntu-mid build log, germinate is breaking due to libavcodec being pulled in -- from what I can see, nothing in the seeds should pull it in, could I bug you have a quick look when you can?
[11:41] <lool> % dpkg-query -W -f='${Conffiles}' udev | grep obsolete /etc/udev/rules.d/05-udev-early.rules 01cc7968762a9a6590801ac94f585d44 obsolete /etc/udev/rules.d/66-persistent-storage-edd.rules 5dc9376604e2266886c6be1c7a467222 obsolete
[11:42] <Keybuk> those are both very old rules
[11:43] <Keybuk> 05-udev-early was rm'd in upgrade from feisty to gutsy
[11:43] <soren> StevenK: Isn't that even blacklisted?
[11:43] <Keybuk> I didn't think we ever shipped a 66-persistent-storage-edd.rules file
[11:43] <StevenK> soren: It is blacklisted, which is why germinate is having a hissy fit
[11:43] <Keybuk> that could have been from a PPA or something?
[11:44] <cjwatson> the blacklist syntax is pretty crude which is why I discourage it for most purposes (libavcodec is one of the few sensible uses)
[11:44] <cjwatson> StevenK: will do
[11:44] <Keybuk> cjwatson: yup, this works
[11:44] <Keybuk> where we don't have a Depend on udev, we should have a Breaks
[11:44] <soren> Keybuk: I think I understand the reasoning, but it still looks a bit wierd that all those packages break udev, since it certainly feel sht other way around :)
[11:45] <cjwatson> ? Package libavcodec51 blacklisted in ship-live but seeded in extra (mpeg4ip-server)
[11:45] <cjwatson> is what the log says
[11:45] <Keybuk> soren: all those packages Depend on udev, so it looks weird to me that they don't ;)
[11:45] <cjwatson> soren: I agree that it's slightly twisty
[11:45] <soren> Keybuk: Heh :)
[11:45] <StevenK> cjwatson: Which doesn't exist in mobile.jaunty ...
[11:45] <cjwatson> in general I do not particularly object to adding udev dependencies in Ubuntu, although respect the case where package maintainers don't want to
[11:45] <cjwatson> StevenK: extra, by definition, is synthesised by germinate
[11:45]  * Keybuk still doesn't buy this whole "but I might want to uninstall udev" nonsense
[11:46] <Keybuk> it obviously makes sense in Debian
[11:46] <cjwatson> exactly why it's showing up here I haven't figured out yet
[11:46] <Keybuk> because there's a very good reason to want to uninstall udev in Debian
[11:46] <Keybuk> but since Marco isn't an Ubuntu maintainer ...
[11:46] <Keybuk> ;-)
[11:46] <soren> Keybuk: What might that reason be? Do they still have devfs kernels or some such? Or are you thinking for embedded systems or something?
[11:47] <cjwatson> I think this is argumentum ad hominem, actually ;-)
[11:48] <directhex> against whom? d'itri?
[11:48] <soren> cjwatson: Ah :)
[11:49] <Mithrandir> udev in Debian generally works fine those days.
[11:50] <soren> Ok, so the verdict is to add "breaks: udev (<< 136-1)", fix up the paths in the initramfs hook scripts, and nothing else? No dependency on udev?
[11:50] <Keybuk> soren: if you have a dep on udev, increase it
[11:50] <Keybuk> lvm needs it put back, I removed it by mistale
[11:50] <soren> Right.
[11:51] <Keybuk> I think mdadm should have a Dep too
[11:51] <Keybuk> since it relies on udev these days
[11:51] <Keybuk> devmapper needs a Breaks
[11:52] <soren> Keybuk: lvm still needs the watershed dependency, right? It's gone from udev, AFAIUI?
[11:52] <Keybuk> right
[11:52] <Keybuk> after talking with Kay, we opted not to include watershed upstream because the only program that needs it is lvm and our opinion is that lvm is broken
[11:52] <Keybuk> (lvm needs to grow incremental assembly support)
[11:52]  * soren nodes
[11:52] <soren> nods, even.
[11:53] <lool> Keybuk: these conffiles show up on both of my jaunty systems; installed around gutsy I believe
[11:53] <Keybuk> lool: *shrug* you upgrade through development releases and probably install test packages I make from time to time
[11:53] <Keybuk> just rm them and delete the lines from status? :)
[11:53] <lool> Are you confident they wont be there for regular users?
[11:54] <Keybuk> yeah
[11:54] <Keybuk> I've upgraded this machine only on major releases since warty, and they're not there
[11:55] <lool> Ok, thanks
[11:55] <cjwatson> StevenK: this is a very interesting little problem. :)
[11:55] <StevenK> cjwatson: Heh
[11:56] <cjwatson> I *think* it's a germinate bug
[11:57] <soren> Keybuk: What if someone (for whatever reason) just installs the new udev (without updating all the other stuff)? That will obviously break, but do we care?
[11:57] <Keybuk> it won't break
[11:58] <Keybuk> well, not entirely true; it'll probably ignore some of the rules
[11:58] <soren> It clearly breaks.
[11:59] <soren> That's what that bug is about.
[11:59] <soren> ..and that's why my laptop fails to boot.
[11:59] <Keybuk> oh, that'll break, true
[11:59] <Keybuk> upgrade lvm then ;)
[11:59] <soren> A.k.a.: we don't care :)
[11:59] <Keybuk> there's no way to express this kind of thing
[11:59] <soren> Other than inverting the Breaks.
[12:00] <Keybuk> you can't provide ABIs with dpkg, like you can in RPM
[12:00] <Keybuk> I'm not having a Breaks in udev listing every single package that ships a udev rule
[12:00] <Keybuk> that's insane
[12:00] <soren> I agree.
[12:00] <soren> But it's possible.
[12:00] <soren> Just because it's possible doesn't mean we want to do it :)
[12:00] <Keybuk> just thought
[12:00] <Keybuk> dmsetup needs a Depend on udev
[12:01] <cjwatson> you certainly can provide ABIs with dpkg; you can implement this kind of thing with Provides and a bit of creativity
[12:01] <Keybuk> because it ships an initramfs-hook that assumes udev is installed
[12:01] <Keybuk> cjwatson: not in a way that would help soren's problem
[12:01] <Keybuk> well
[12:01] <Keybuk> Provides: udev-abi-4
[12:01] <soren> Not now, anyway.
[12:01] <Keybuk> Conflicts: udev-abi-1, udev-abi-2, udev-abi-3
[12:01] <soren> If we had done that from the start, sure.
[12:02] <Keybuk> or maybe Breaks
[12:02] <lool> I don't think it's insane to add Breaks in udev; we did add Conflicts in libgtk for all gtk 2.4.0 modules
[12:02] <lool> And we added an ABI provides
[12:02] <lool> Provides: gtk2.0-binver-2.10.0
[12:02] <Keybuk> udev doesn't even have a stable ABI
[12:02] <Keybuk> every package that ships a udev rule should depend on an exact version of udev
[12:02] <Keybuk> but they don't
[12:03]  * soren needs lunch
[12:11] <Keybuk> after some playing around, it doesn't matter which way you put the Breaks
[12:11] <Keybuk> the net effect is always the same
[12:11] <Keybuk> if you put the Breaks on udev for lvm, you can't upgrade udev without breaking lvm
[12:12] <Keybuk> but you can still upgrade lvm without upgrading udev (and hit the same bug from the opposite direction)
[12:12] <Keybuk> it makes sense to me that the Breaks should be on the "lesser" package
[12:12] <Keybuk> because people are more likely to backport backinstall those
[12:13] <Keybuk> so if someone grabs the lvm from jaunty, they'll be forced to upgrade udev
[12:13] <Keybuk> (which matches the and upgrade libc, etc.) pattern
[12:13] <Keybuk> whereas people rarely backport udev ;)
[12:20] <Keybuk> pitti: \o/
[12:21] <Keybuk> devicekit (002-0ubuntu1) jaunty; urgency=low
[12:21] <pitti> huzzah :)
[12:21] <pitti> Keybuk: DK-power is now current as well
[12:21] <ion_> Yay
[12:21] <Keybuk> I saw
[12:21] <ion_> Why 002 instead of, say, 2?
[12:21] <pitti> I think I properly udevified it, please yell at me if not
[12:21] <Keybuk> ion_: upstream version number scheme
[12:21] <pitti> ion_: *shrug* I just took what upstream used
[12:22] <Keybuk> pitti: question about sane-backends
[12:22] <Keybuk> why did you remove the code to create the scanner group?
[12:23] <pitti> Keybuk: because we don't install the udev rule any more, and thus we don't need it in sane-utils
[12:23] <Keybuk> but the very next line of the postinst assumes the scanner group exists
[12:23] <Keybuk> and tries to add the user to it
[12:23] <pitti> !
[12:23] <pitti> which user?
[12:23] <Keybuk>     # Create saned user/group if they do not exist
[12:23] <Keybuk>     if ! getent passwd | grep -q "^saned:"; then
[12:23] <Keybuk>         echo "Adding saned group and user..."
[12:23] <Keybuk>         adduser --quiet --system --no-create-home --group saned || true
[12:23] <Keybuk>     fi
[12:23] <pitti> argh
[12:23] <pitti> saned
[12:23] <Keybuk>     if [ "$SANED_IN_SCANNER" = "true" ]; then
[12:23] <Keybuk>         adduser --quiet saned scanner
[12:23] <Keybuk>     else
[12:23] <Keybuk>         if id saned | grep -q "groups=.*\(scanner\)"; then
[12:23] <Keybuk>             deluser --quiet saned scanner
[12:23] <Keybuk>         fi
[12:24] <Keybuk>     fi
[12:24] <Keybuk> SANED_IN_SCANNER would appear to be true
[12:24] <pitti> Keybuk: merge error then, thanks for spotting
[12:24] <liw> hm, piuparts should catch that kind of error
[12:24] <Keybuk> we don't put anything in scanner anymore, so it's utterly pointless
[12:24] <Keybuk> so maybe just remove that bit? :)
[12:24] <pitti> Keybuk: hm, then saned would not work at all
[12:25] <Keybuk> why wouldn't it?
[12:25] <pitti> because it can't access the device?
[12:25] <pitti> (it's a daemon)
[12:25] <Keybuk> hmm
[12:25] <Keybuk> but there's no scanner group anymore ;)
[12:25] <pitti> right, and it's broken either way
[12:25] <pitti> just pondering whether we want to do anythign to unbreak it
[12:26] <Keybuk> well, unbreaking the postinst would be nice ;P
[12:26] <pitti> Keybuk: do you happen to have some time to do that? I'm in quite a time crunch ATM
[12:26] <Keybuk> I can add it to my todo
[12:26] <pitti> trying to get some stuff sorted before I leave tomorrow 6 am for a week..
[12:26] <Keybuk> np
[12:26] <pitti> Keybuk: appreciated, thanks
[12:32] <phix> hey
[12:43] <dholbach> can somebody massage the ubuntu-devel-announce@ queue? :)
[12:44] <cjwatson> dholbach: done
[12:44] <dholbach> cjwatson: gracias!
[13:04] <Laibsch> Hi
[13:04] <Laibsch> Can somebody please upload my patch from bug 254228 to intrepid-proposed?  It fixes a quite serious error in sqlite3
[13:19] <stefanlsd> lool: still getting that magick/api.h: No such file or directory for imview with new imagemagick
[13:20] <ogra> tjaalton, any hint for me how to handle evtouch to get it building again ? is there any replacement for xf86Version.h ?
[13:21] <StevenK> cjwatson: Any news about my germinate issue before I scamper off to bed?
[13:28] <Laney> slangasek: <slomo> gnome-sharp2 first needs gnome-desktop-sharp2 to be packaged
[13:29] <tjaalton> ogra: nope, dropping that include doesn't help (it's not needed anymore)
[13:30] <ogra> well, its one of the issues
[13:30] <ogra> i understood that there was a evtouch version in experimental, but i seem unable to find it
[13:30] <ogra> i was hoping that builds
[13:31] <tjaalton> there isn't
[13:31] <ogra> weird ... soeone said the new upstrem version was there
[13:31] <cjwatson> StevenK: oh, sorry, I was working on it and got distracted by ext4 stuff. One minute
[13:32] <tjaalton> ogra: I doubt 0.8.8 works any better
[13:32] <cjwatson> StevenK: ok, the last seed in STRUCTURE is special, as documented in germinate(1)
[13:32] <ogra> yeah, it just includes my changes actually
[13:32] <cjwatson> StevenK: so ship-live was getting all the build-dependencies added to it which was kind of bad
[13:33] <ogra> but i would like to get it building
[13:33] <cjwatson> StevenK: I'll fix the seeds
[13:34] <cjwatson> coo, ext4 resizing in the installer even works
[13:35] <StevenK> cjwatson: Okay, cool. Thanks. :-)
[13:35] <cjwatson> StevenK: (done)
[13:36] <ogra> cjwatson, btw i think ted mentioned in his ext4 talk that you shouldnt expect the performance gains with a converted ext3->4 fs
[13:36] <ogra> (you didnt mention that in your mail)
[13:36] <cjwatson> no, feel free
[13:37] <cjwatson> I didn't have the reference so didn't want to shoot my mouth off based on hearsay
[13:37] <ogra> yeah, i only remember it vaguely either from the talk
[13:37] <ogra> no details in my head
[13:38] <cjwatson> I would have expected that to be because existing files aren't converted to extents
[13:39] <ogra> yeah
[13:44] <Keybuk> soren: ugh, you unequivocally just remove the old udev rules?
[13:44] <Keybuk> you should almost certainly check whether or not the user has modified them first
[13:46] <Keybuk> soren: devmapper needs the b-d of debhelper increasing to pick up the new udev behaviour
[13:57] <soren> Keybuk: I remove the old udev rules?
[13:57] <soren> Keybuk: Oh, because of debhelper putting them in a different place?
[13:57] <Keybuk> soren: it looks like it, in the preinst?
[13:57] <Keybuk> in lvm2/mdadm?
[13:57] <soren> I haven't touched maintainer scripts at all.
[13:58] <Keybuk> uploaded devmapper with fixed b-d
[13:59] <soren> I don't see why it's needed, to be honest.
[13:59] <Keybuk> well
[13:59] <Keybuk> if I download this source and build it
[13:59] <Keybuk> but don't update devmapper
[13:59] <Keybuk> it'll be a *different* package to the one on the buildds
[13:59] <soren> "this source"?
[13:59] <Keybuk> devmapper 2:1.0.27-4ubuntu2
[13:59] <soren> If you download devmapper and build it, but don't update it?
[14:00] <Keybuk> if I build this as-is, but don't update *debhelper* (I keep doing that! :p)
[14:00] <soren> Go on, it might sink it at some point :)
[14:00] <soren> Ah.
[14:00] <Keybuk> then I'll have a different package
[14:00] <Keybuk> it will have different contents
[14:00] <Keybuk> you could claim that's desired
[14:00] <soren> Yes.
[14:00] <Keybuk> *except* the contents won't match the initramfs hook in the package
[14:00] <soren> Ah.
[14:00] <Keybuk> so update-initramfs will fail because /lib/udev/rules.d/blahblahblah won't exist
[14:00] <soren> That's a good point.
[14:01] <Keybuk> the only justification I can think of for not always bumping build-dependencies is to make backporting less painful
[14:01] <Keybuk> but I honestly think that the pain is a feature here
[14:02] <soren> *nod*, but only due to the initramfs hooks.
[14:02] <soren> Oh, wait.
[14:02] <Keybuk> I think package contents and maintainer scripts being different if you build it two different ways is a bug
[14:02] <soren> if the user has put rules in /etc/udev/rules.d to override something... Shouldn't we be putting those in initramfs, too?
[14:02] <Keybuk> I could switch to a chroot, do dpkg-buildpackage *and never realise* that I had to update debhelper
[14:03] <Keybuk> soren: honestly?
[14:03] <Keybuk> no :)
[14:03] <Keybuk> there's so many things we don't copy into initramfs right now
[14:03] <soren> That's true, but this could be a regression for some people.
[14:04] <soren> If they have local changes in the lvm rules, they will be used to having them in initramfs, but that will no longer be the case.
[14:04] <soren> I can't imagine what they'd be doing in there, but still.
[14:04] <Keybuk> the whole point of the move to /lib is to *stop* people making local changes to these things
[14:04] <Keybuk> if you can find someone legitimately doing it, then we'll work out how to make it so they don't need to :p
[14:05] <lool> stefanlsd: I didn't get that in my ppa, but it's probably because it sees main/universe stuff
[14:05] <lool> stefanlsd: is this with the current jaunty version or a new one?
[14:05] <soren> Keybuk: I see your point.
[14:06] <soren> Keybuk: To get back to the chroot case for a minute..
[14:06] <stefanlsd> lool: one coming in from debian. 1.1.9c
[14:06] <soren> Keybuk: I'm still not completely convinced. The versioned dependency (be it explicit or not) is really between debhelper and udev.
[14:07] <lool> stefanlsd: Ok, then your issue is a different one I would guess; did you diff the configure.in changes?  Can you hand me a .dsc to look at?
[14:07] <lool> http://ftp.debian.org/debian/pool/main/i/imview/imview_1.1.9c-3.dsc?
[14:07] <Keybuk> soren: no it's not
[14:07] <Keybuk> debhelper is a package build tool
[14:07] <soren> Keybuk: debhelper is the one changing incompatibly
[14:07] <soren> Keybuk: I realise.
[14:08] <Keybuk> debhelper is a short-cut for not doing stuff in debian/rules itself
[14:08] <soren> That's why I said earlier that there really is no sane way to express this relationship.
[14:08] <lool> stefanlsd: Right, as I suspected there are changes in the configure.in
[14:08] <stefanlsd> lool: yeah. thats it. I just did get it to compile by uncommenting line 769 of configure.in
[14:08] <lool> -                       CPPFLAGS="$CPPFLAGS "`pkg-config ImageMagick --cflags`
[14:08] <lool> +                        MAGICKNAME=$(pkg-config ImageMagick --libs-only-l | sed 's/-l//')
[14:08] <lool> This is really scary
[14:09] <Keybuk> right, we don't _really_ have this kind of flexibility
[14:09] <soren> Keybuk: short of having dh_installdev add a versioned udev dependency to ${misc:Depends} or something.
[14:09] <Keybuk> but as long as you're always moving forwards, things tend to work out :)
[14:09] <stefanlsd> so essentially CPPFLAGS="$CPPFLAGS "`Magick-config --cppflags`
[14:09] <lool> stefanlsd: The configure changes are crackful; they shouldn't be using AC_CHECK_LIB manually with pkg-config calls at the other end of the configure.in
[14:10] <soren> s/dh_installdev/dh_installudev/ obviously.
[14:10] <lool> stefanlsd: The configure.in might use AC_CHECK_LIB for compat with very old imagemagick, but I'd recommend simply using PKG_CHECK_MODULES unconditionally
[14:11] <soren> Keybuk: I feel this discussion is really about choosing the lesser of a number of evils. I see the argument for a versioned b-d on debhelper, certainly. I just wasn't completely convinced by it.
[14:11] <Keybuk> soren: when I was considering dpkg2, one of my ideas was to take versioned dependencies away again
[14:11] <soren> OTOH, I'm not insistant against it.
[14:11] <Keybuk> because they don't actually work in practice
[14:12] <lool> stefanlsd: Search for Imagemagick in xine-lib's configure.ac for an example; it's not perfect style but it's good enough
[14:12] <Keybuk> in reality, you want something more like .so versions
[14:12] <cjwatson> versioned deps are good for some things but not others
[14:12] <cjwatson> in many cases feature dependencies would be more appropriate, but I'm not sure "many" = "all"
[14:12] <Keybuk> cjwatson: possibly
[14:12]  * soren concurs with cjwatson
[14:12] <Keybuk> there may be situations where they are equally appropriate
[14:13] <lool> stefanlsd: Is that good enough to get you going?
[14:13] <Keybuk> it'd be an interesting exercise to think of situations where they are less appropriate
[14:13] <cjwatson> I've worked with a system where we only had feature dependencies; it wasn't that they were *inappropriate*, but they were kind of cumbersome sometimes
[14:13] <cjwatson> if it was just for one-off things it was cumbersome; for anything complicated it was great
[14:14] <Keybuk> the problem with versioned dependencies is you tend to do:
[14:14] <Keybuk>   Depend: foo (>= whatever-version-I-need)
[14:14] <cjwatson> a system that supported both would be the best of both worlds, in my mind
[14:14] <Keybuk> which will always shoot you in the foot if a later version of foo isn't compatible
[14:14] <Keybuk> and you can't go back in time and undo it
[14:15] <Keybuk> but then in practice, the dpkg/apt world is always moving forwards
[14:15] <Keybuk> you move from 8.04 to 8.10 to 9.04
[14:15] <cjwatson> for udev, that's a very valid concern, but there are plenty of other situations where it's not a problem
[14:15] <Keybuk> so as long as you stay in that direction, things work out
[14:15] <cjwatson> and yes, indeed
[14:15] <Keybuk> cjwatson: all library packages too ;)
[14:15] <Keybuk> debhelper, cdbs, other build-tools as well
[14:16] <soren> There's really very little about the package relationships that is in any way guaranteed to be true forever.
[14:16] <cjwatson> if the reason for your dependency is that you need a feature, you want to depend on the presence of a feature
[14:16] <cjwatson> if the reason for your dependency is that previous versions were screwed, then it's often a bit too cumbersome to define a feature "not-screwed-any-more"
[14:16] <cjwatson> bugs will always screw you over ...
[14:16] <Keybuk> hmm, true
[14:17] <Keybuk> depending on a version with a known bugfix is compelling
[14:17] <lool> And then you can also conditionalize which features you want to build in this package and which features in other packages this requires and we have combinatory explosion and useless packages  \o/
[14:17] <stefanlsd> lool: not a configure expert, but i'll give it a try. thanks!
[14:17] <Keybuk> lool: we have that now ;)
[14:17] <cjwatson> lool: oh, I'm not arguing for USE flags!
[14:17] <Keybuk> "oh, no, that's _only_ a Recommends" *argh*
[14:17] <lool> erf
[14:18] <lool> cjwatson: It was too tempting to bend the discussion   :-P
[14:18] <Keybuk> conary has a kinda cute feature
[14:18] <Keybuk> for lack of a better term, packages can have flavours
[14:18] <Keybuk> so you can have foo-with-gnome or foo-with-kde or just foo-with-gtk
[14:18] <lool> stefanlsd: if you don't manage, I'm happy to try to hepl
[14:20] <stefanlsd> lool: thanks a lot.
[14:21] <Mithrandir> lool: sorry about sucking utterly; I have merged your pkg-config stuff, but haven't gotten around to writing up a changelog for it yet.
[14:35] <doko> pitti, calc: please could you get OOo building today, so that we can include it in the next alpha?
[14:38] <lool> Mithrandir: Cool, thanks
[14:39] <pitti> calc: depwaiting on libstlport4.6-dev; can we please build it against libstlport5.1-dev and MIR that?
[14:40] <lool> Mithrandir: The two things I'd care about after that would be 1) an opinion on using new flags instead of changing the semantics of requires.private and 2) pushing whatever the resulting pkg-config is to Debian/Ubuntu  ;-)
[14:44] <Keybuk>     Definition Status: Discussion => Drafting
[14:44] <Keybuk> erp
[14:45] <Keybuk> lool: I didn't attend that because I thought we'd agreed it was a Bad Idea(tm)
[14:45] <Keybuk> is that back on the cards
[14:47] <lool> Keybuk: Assuming you mean squashfs-initrd?  It basically was an idea thrown on IRC which ended up with "Let's discuss it at UDS" for some reason, but with absolutely nobody clueful enough to comment on the feasibility and benefit; the idea was that if you mount a filesystem instead of decompressing a full initramfs you can immediately start running its contents without reading it in full; also it made the thing a tiny bit smaller, but that's uninte
[14:48] <cjwatson> cut off at "uninte", in case there was more after that than just "resting"
[14:48] <cjwatson> splitlong.pl++
[14:48] <Mithrandir> lool: /script load splitlong.pl :-)
[14:48] <lool> No, just "uninteresting"; thanks for the notice
[14:48] <lool> Mithrandir: thanks :)
[14:48] <pitti> seb128: gdm-upgrade spec reviewed, needs some clarification
[14:49] <seb128> pitti: ok, I noticed that tedg was set a drafter btw, should that be changed?
[14:49] <Keybuk> I now have images of lool in a corset
[14:49] <pitti> seb128: if you are happy with drafting it further, sure
[14:49] <lool> Mithrandir: The plugin doesn't seem to set splitlong_max_length; which value did you set it to?
[14:50] <seb128> pitti: well I didn't notice that tedg was set as drafter before updating the wiki and changing the blueprint then
[14:50] <Mithrandir> lool: it's 512 by default, I think.
[14:50] <lool> Thanks
[14:50] <Mithrandir> lool: I've never explicitly configured it, but it seems to work for me anyway.
[14:50] <seb128> pitti: I'm fine editing the spec, I'm not sure about the autologin thing though, that's not something available in ubuntu right now, do you know what team is working on that?
[14:50] <lool> Oh right there's a default at another place in the script
[14:50] <lool> $maxlength = 497 - length($server->{nick} . $server->{userhost} . $target);
[14:52] <lool> Keybuk: Assuming you mean squashfs-initrd?  It basically was an idea thrown on IRC which ended up with "Let's discuss it at UDS" for some reason, but with absolutely nobody clueful enough to comment on the feasibility and benefit; the idea was that if you mount a filesystem instead of decompressing a full initramfs you can immediately start running its contents without reading it in full; also it made the thing a tiny bit smaller, but that's ...
[14:52] <lool> ... uninteresting
[14:52] <lool> Works a charm
[14:53] <lool> Keybuk: I understand from your vision of me in a corset that you don't think that makes any difference?
[14:53] <liw> mvo, I've edited https://wiki.ubuntu.com/FoundationsTeam/Specs/JauntyCruftRemover -- when you have time, I'd like feedback
[14:53] <Keybuk> Rocky Horror, innit
[14:53] <Keybuk> Shiver with anticip
[14:54] <Keybuk> ation
[14:55] <lool> Keybuk: ?
[14:55] <Keybuk> lool: NM :)
[14:56] <Keybuk> in summary:
[14:56] <Keybuk> - you can compress an initrd with whatever you like, provided the kernel has built-in support for mounting it
[14:56] <Keybuk> - initrd is a filesystem
[14:56] <Keybuk> - initramfs is a compressed cpio file, tagged onto the end of the kernel
[14:56] <Keybuk> - initrd and initramfs are used at *different points* of the kernel boot process
[14:57] <Keybuk> (effectively an initrd is used instead of the real root, whereas an initramfs is used instead of much of the kernel's init procedure)
[14:57] <lool> So far I understood all of that
[14:58] <Keybuk> the initrd has to be loaded into a ramdisk,
[14:58] <Keybuk> the metadata examined,
[14:58] <Keybuk> and it has to be mounted
[14:58] <Keybuk> that takes X seconds
[14:58] <Keybuk> the initramfs only has to be uncompressed into a tmpfs
[14:58] <Keybuk> that takes Y seconds
[14:59] <Keybuk> I'm not sure anyone's done practical timings of the difference between X and Y
[14:59] <Keybuk> especially since with the initramfs, Z seconds of kernel code is omitted
[14:59] <lool> I guess since the bootloader will always load them in full, it probably doesn't make a big one
[14:59] <Keybuk> it wouldn't surprise me if the speed benefit of not decompressing it first
[14:59] <Keybuk> is outweight by the fact you have to decompress it all anyway
[15:00] <Keybuk> and I can't imagine you're talking more than ms difference
[15:01] <lool> Ok; also I understand we try to get rid of the initramfs completely in jaunty
[15:01] <lool> How will that work for lvm?
[15:01] <calc> pitti: already got another build going just have to test the resulting debs this morning before upload
[15:01] <calc> pitti: and i disabled stlport entirely in it
[15:02] <pitti> ah, good
[15:02] <pitti> calc: so the two java libs are the only remaining blockers now?
[15:03] <calc> pitti: yes afaik
[15:04] <pitti> calc: ok, I'll promote them to main now and make the bug jaunty blockers, so that the libs get fixed in time
[15:05] <calc> pitti: ok
[15:06] <calc> pitti: i'll get the new OOo build uploaded in a few hours, i have to test then it takes around 1.5-2 hr to upload due to my 512kbps upload rate
[15:06] <Keybuk> lool: if you use LVM, you need to use the initramfs
[15:06] <pitti> calc: hm, xom is FTBFS
[15:07] <calc> pitti: yea very strange issue with that one, it worked on my machine then FTBFS when uploaded
[15:07] <doko> pitti, calc: can we get the OOo related MIR's resolved today? and OOo 3.0 included for alpha-3?
[15:07] <pitti> calc: I gave it back, just for fun, and promote the old binaries for now (ugh)
[15:07] <calc> pitti: ok
[15:07] <pitti> doko: probably not resolved, but tentatively promoted already (just doing)
[15:07] <calc> doko: well trying the xom FTBFS is very odd at least to me, heh
[15:08] <calc> doko: but since pitti is just promoting it regardless it should work
[15:09] <mvo> liw: I have a look
[15:10]  * calc installing the packages now to see if they blow up still
[15:11] <doko> mvo: for alpha-3: Notify Michael Vogt to perform a GnomeAppInstallDesktopDatabaseUpdate
[15:11] <doko> pitti: for alpha-3: Discuss with Desktop team and MartinPitt whether or not to re-enable apport by default.
[15:12] <pitti> doko: currently enabled now; retracers for jaunty don't work, though
[15:12] <pitti> doko: I'd say we leave it enabled, and if seb128 drowns in the unprocessed flood, we'll disable it again
[15:13] <pitti> calc: failed again, hm
[15:14] <seb128> pitti: if we have no retracers I would disable it, we will just collect bugs which will not be retracable when we restart those anyway, jaunty change quickly so versions will be outdated
[15:15] <pitti> seb128: okay, I'll disable it; I'm still unable to work around the lp timeout
[15:16] <pitti> seb128: I'll play with them a bit more, and if I fail, I'll upload a new apport this evening
[15:16] <seb128> pitti: lpi is broken too, the IRC bot tends to timeout when being asked for bugs, I think that's a launchpad isue
[15:17] <pitti> seb128: I just wonder why it doesn't affect intrepid crash reports
[15:17] <seb128> that's weird indeed
[15:20] <soc> hi
[15:21] <soc> has that recent openssl/libssl update changed how key unlocking works?
[15:21] <soc> because since that update, i can't unlock my ssh keys anymore
[15:26] <seb128> soc: gnome-keyring got updated
[15:29] <soc> ah nice to know
[15:29] <soc> and because of that my keys stop working?
[15:30] <soc> i don't really want to sound angry :-)
[15:30] <doko> calc: xom doesn't build with gcj either
[15:30] <sconklin> can anyone point me to a description of the operating environment for init scripts (intrepid)? I'm having a problem that appears to be related to forking and the available file descriptors.
[15:31] <Keybuk> there is no guaranteed operating environment
[15:31] <mvo> doko: thanks
[15:31] <calc> doko: for some reason it built on my machine both times before i uploaded but then failed on the buildd, not sure why it worked on mine and failed on the buildd though
[15:31] <sconklin> not even for file descriptors 0-2?
[15:31] <Keybuk> not even for them
[15:32] <sconklin> sigh. Thanks
[15:32] <Keybuk> this is one of the bugs that Upstart is intended to address
[15:32] <Keybuk> (it goes out of its way to ensure every job gets a guaranteed environment)
[15:32] <sconklin> Then I vote for that.
[15:33] <kees> Keybuk, soren: so, the new udev rules path... does mdadm need to be fixed too?
[15:33] <Keybuk> kees: mdadm should be fixed?
[15:34] <kees> Keybuk: that's what I'm asking.  :)
[15:34] <Keybuk> no, I mean it should _already_ be fixed, are you disagreeing?
[15:34] <kees> oh! okay, cool, nm then.  :)
[15:35] <kees> also, where should the *persistent* .rules files live?
[15:35] <Keybuk> /etc
[15:35] <kees> in /etc/udev/rules.d ?
[15:35] <Keybuk> yes
[15:35] <kees> okay
[15:37] <kwwii> seb128: do you know which package the default cursor theme is in?
[15:37] <kwwii> seb128: I looked in xcursor-themes but it is not in there
[15:37] <ogra> isnt that dmz-cursor-theme ?
[15:39] <kwwii> ogra: yes, it is and unfortunately they are all in cursor forrmat
[15:39] <ogra> even in the source package ?
[15:39] <ogra> thats bad
[15:40] <kwwii> ogra: in that package there are only x11 cursor files, and I can#t find another package with any source for it
[15:43] <ogra> evil
[15:43] <ogra> though arent there tools to convert cursor files to png ?
[15:43] <ogra> and back
[15:46] <kwwii> no, not that I can find...I did find the sources though
[15:46] <kwwii> on jimmacs website
[15:46] <seb128> no idea about those
[15:47] <seb128> soc: could be bug #315398
[15:47] <seb128> soc: though you mentionned ssl but not ssh before?
[15:47] <james_w> what's the replacement for "update-modules"?
[15:51] <calc> ok upload now in process
[15:53] <kees> Keybuk: out of curiosity, why the dh bump in lvm2?
[15:53] <soc> seb: yes, i can't unlock my ssh key anymore
[15:53] <Keybuk> kees: because it uses dh_installudev
[15:53] <Keybuk> so needs the bump to install the rules in the right place
[15:54] <Keybuk> otherwise you could build it with a version of dh_installudev that still puts the rules in /etc
[15:54] <kees> hah, okay
[15:56] <seb128> kees: hi
[15:56] <kees> heya seb128
[15:56] <seb128> kees: did you send your libtop patch upstream after uploading it to jaunty?
[15:57] <kees> seb128: do you have the bug# handy?  (I don't presently remember)
[15:57] <seb128> kees: you uploaded a change some weeks ago to fix a leak which were create issue in the system monitor applet
[15:57] <seb128> let me get the bug number
[15:58] <seb128> kees: bug #307472
[15:58] <seb128> kees: https://edge.launchpad.net/ubuntu/+source/libgtop2/2.24.0-0ubuntu3
[15:59] <kees> seb128: no, I did it as part of my sponsorship workflow, so I didn't file an upstream bug
[15:59] <seb128> kees: not sure if you know but we try to follow https://wiki.ubuntu.com/UbuntuDevelopment/PatchTaggingGuidelines too and make sure we send fixes upstream for desktop changes ;-)
[15:59]  * kees nods
[15:59] <seb128> kees: anyway would be nice if you could bugzilla it, thanks!
[15:59] <kees> I haven't gotten into the habit of requiring that from sponsorees yet
[15:59] <seb128> since you did the upload I think it's fair you do the forwarding too ;-)
[16:00] <seb128> well, either we request and we forward the patch for them
[16:00] <kees> sure, it might result in a gnome patch that isn't ignored
[16:00] <seb128> hehe
[16:00] <kees> seb128: btw, do you think that qualifies as SRU material?
[16:01] <seb128> could be
[16:01] <seb128> but we didn't get many complain about it and intrepid is not a lts so I'm not sure I would bother
[16:02] <seb128> I don't think many people do disk monitoring but maybe that's a wrong impression
[16:02]  * kees nods
[16:02] <seb128> I usually have network and cpu monitors on my config
[16:02] <seb128> anyway if you want to do the sru feel free
[16:03] <kees> seb128: looks like it's already upstream http://bugzilla.gnome.org/show_bug.cgi?id=566611
[16:04] <seb128> kees: ah good, it was not when you uploaded, I just had this on my list since before the holidays and I didn't check again ;-)
[16:04] <kees> seb128: cool, yeah
[16:12] <soren> Keybuk: Your watershed 2 package is vapourware so far.. :/
[16:13] <Keybuk> heh]
[16:13] <Keybuk> but I committed it!
[16:13] <Keybuk> and I tagged it!
[16:13] <soren> Good for you :)
[16:13] <Keybuk> uploaded
[16:13] <soren> For me (and my builds), less so :)
[16:13]  * Keybuk so wants build-from-tag
[16:13] <soren> Ta.
[16:13]  * soren takes a break
[16:13] <Keybuk> bzr tag --for ubuntu 136-2
[16:14]  * Keybuk hands ubottu a cup of FAIL
[16:22] <kees> hm, can an archive admin accept zsnes into -proposed?
[16:29]  * directhex puts snes9x there instead, hopes nobody notices
[16:44] <pitti> kees: done
[16:48] <Keybuk> cjwatson: you've not uploaded pcmciautils yet, right?
[16:52] <kees> pitti: thanks!
[16:53] <kees> pitti: actually, I've got one more: dosemu, which will show up in about 2 minutes
[16:56]  * pitti boggles
[16:56] <pitti> seb128: I don't believe it, but using the change-a-thing-and-document it, I found the difference for the lp timeouts
[16:57] <pitti> seb128: downgrading python-apt to intrepid in the jaunty chroot makes the LP timeouts go away; likewise, upgrading p-apt in the intrepid chroot makes them appear
[16:57] <pitti> W. T. F. ?
[16:58] <pitti> thekorn_: ^ FYI
[16:59] <seb128> pitti: weird
[16:59] <seb128> pitti: several users commented about getting timeout using apport too in jaunty btw
[17:00] <pitti> seb128: which kind of timeout?
[17:02] <pitti> seb128: when uploading reports, timeout displayed in LP in the browser?
[17:03]  * pitti pins python-apt to intrepid for now and tests the real thing
[17:04] <seb128> pitti: wait, I'm looking if I find the bug
[17:06] <seb128> pitti: I don't find it right now
[17:07] <seb128> pitti: but we asked on some crash to use apport to send the crash and the user replied that was not working but timeouting
[17:11] <bluefoxicy> okay, hold it.
[17:11] <seb128> pitti: that's bug #311690 rather
[17:11] <bluefoxicy> Mem:   3797552k total,  3746448k used,    51104k free,   101104k buffers
[17:11] <bluefoxicy> Swap:   787072k total,   786396k used,      676k free,   346060k cached
[17:11] <pitti> seb128: right, but that's even something else
[17:11] <pitti> seb128: I saw that
[17:11] <seb128> right
[17:12] <pitti> seb128: loading the page again after some seconds works
[17:12] <bluefoxicy> 3.5G + .75G used?
[17:12] <bluefoxicy> 11271 bluefox   20   0 1638m 945m  11m S    0 25.5  36:17.50 nautilus
[17:12] <bluefoxicy> 11594 bluefox   20   0 1175m 674m  19m S   12 18.2   7177:05 firefox
[17:13] <bluefoxicy> When you guys get done discussing real business, somebody /msg me how to figure this one out, because I  don't even know where to begin filing a bug for this that isn't too vague to matter
[17:13] <bluefoxicy> (WTF nautilus!?)
[17:15] <seb128> bluefoxicy: try to find how to trigger it and run those under valgrind
[17:15] <seb128> bluefoxicy: could be some image you loaded which created the issue for example
[17:15] <bluefoxicy> seb128: firefox is like this all the time
[17:15]  * pitti hugs seb128, thekorn, and everyone
[17:16]  * seb128 hugs pitti
[17:16] <pitti> IT'S WORKING!!!!!!
[17:16]  * pitti jumps for joy
[17:16] <bluefoxicy> nautilus may be a bit iffy after browsing my porn directory; I can only hypothesize the most likely cause involves generating thumbnails for videos
[17:16] <bluefoxicy> however
[17:16] <bluefoxicy> clearing it requires killing nautilus
[17:18] <bluefoxicy> 7ffffc89e000-7ffffc8ba000 rwxp 7ffffffe3000 00:00 0                      [stack] <--- LOVELY
[17:18] <bluefoxicy> rwx?
[17:18] <pitti> mvo: so, any idea why jaunty's python-apt causes Launchpad bugs to timeout through python-launchpad-bugs? :-)
[17:18] <pitti> mvo: (that's veeery high on my list of "weirdest bugs ever")
[17:19] <mvo> pitti: uh, first time I hear about that
[17:19] <mvo> pitti: d yo uhave more details?
[17:19] <mvo> pitti: is there any sort of proxy involved?
[17:19] <pitti> mvo: not yet, it just took me 2.5 days to find that in the first place...
[17:19] <mvo> pitti: or a way for me to reproduce it?
[17:19] <pitti> but I have no idea what p-apt and p-lp-bugs have in common
[17:20] <pitti> mvo: I have a reproducer in the retracer chroots, I'll try to come up with a very small one which works "at home"
[17:20] <pitti> mvo: anyway, it was really just a teaser, not "plzfixitnow" :)
[17:20]  * pitti hugs mvo
[17:20] <mvo> pitti: hrm, damm. that means I need to back to finish spec reviewing? :P
[17:22] <mvo> pitti: it sounds definitely quite mysterious (especially now that I understand that its LP itself that times out)
[17:23] <bluefoxicy> can anyone tell me what /usr/lib/libgmp.so.3.4.2 does?
[17:23] <bluefoxicy> and why it needs an executable stack?
[17:25] <cjwatson> Keybuk: oh, sorry, no, needed to upgrade to new udev so I could test it
[17:28] <pitti> mvo: ok, the reproducer works locally, too; do you want that in a bug report?
[17:28] <pitti> mvo: (or at all?)
[17:30] <maxb> bluefoxicy: "dpkg -S /usr/lib/libgmp.so.3.4.2" --> tells you it comes from the libgmp3c2 package. "dpkg -p libgmp3c2" --> tells you about the package
[17:31] <ogra> and http://gmplib.org/ tells you what it is
[17:31] <bluefoxicy> maxb:  thanks, that's more useful than google :)
[17:34] <mvo> pitti: please, I would love to have a look at this
[17:40] <pitti> mvo: bug 315571 now contains everything I know about this bug
[17:40] <pitti> mvo: can you quickly try the reproducer? it's just an one-line copy&paste shell command
[18:14] <Keybuk> packages that build-conflict their own binaries are UNHELPFUL
[18:20] <directhex> Keybuk, but sometimes inevitable
[18:20] <directhex> i think mythtv does this
[18:22] <Keybuk> glibc should do it
[18:22] <Keybuk> just to explain to everyone why it's wrong
[18:33] <LaserJock> cjwatson: can I have mixed Universe and Main seeds in a "seed pod"? I'm wondering if that creates component mismatches
[18:33] <cjwatson> err. worldview clash
[18:34] <cjwatson> you're asking a question whose terms will be undefined in the new world order
[18:34] <cjwatson> or are you not talking about archive-reorganisation?
[18:34] <LaserJock> I'm not, no
[18:34] <cjwatson> oh
[18:34] <LaserJock> I'm talking for today
[18:34] <cjwatson> which seed collection are you talking about?
[18:34] <LaserJock> Edubuntu
[18:34] <LaserJock> we'd like to make some metapackages for Universe
[18:35] <LaserJock> and I'm wondering if we should split that out into a different bzr branch
[18:35] <cjwatson> if you put packages into the Edubuntu seed collection, they will be flagged for promotion to main
[18:35] <cjwatson> you can create another branch that inherits from edubuntu.jaunty
[18:35] <cjwatson> that's probably the correct approach
[18:36] <LaserJock> cjwatson: is there a reasonable ETA on archive-reorganisation? i.e. "it's gonna happen for Jaunty"?
[18:36] <cjwatson> blocked on LP feature, call due next week to try to figure out what to do
[18:36] <cjwatson> in short, no
[18:37] <LaserJock> when we have that reorganization is there going to be a way to distinguish between Universe and Main-type packages within a project?
[18:38] <LaserJock> would we have to like create two different seed pods (can't remember what the adopted term was)
[18:38] <cjwatson> I think that will become easier
[18:38] <cjwatson> although I do not have the precise layout yet
[18:38]  * ScottK thinks about it and gets a headache.
[18:39] <jpds> LaserJock: lobe I think.
[18:39] <LaserJock> what we're shooting for it to be able to define a "fully supported" core set of app but also have a "best effort support" app selection
[18:41] <cjwatson> LaserJock: remember that in the new world order there is no universe
[18:41] <LaserJock> I know
[18:41] <LaserJock> but we want to make our own, essentially
[18:42] <cjwatson> LaserJock: so it's a lot easier to just say "we're supporting these bits"
[18:42] <LaserJock> "Education" is such a broad category with such a wide range in software/package quality that we would like to define a core set
[18:42] <cjwatson> I think it will probably involve two different seed collections since you might well want to have different access control associated with them, but that that will not be a big deal
[18:42] <LaserJock> ok, cool
[18:43] <cjwatson> also, if you want to make it be just one seed collection and have only one ACL, I don't think that should be a problem either
[18:43] <cjwatson> but I still need to work my way through the UDS session video and update the spec properly
[18:44] <LaserJock> well, I think we may want to have different ACLs
[18:44] <cjwatson> I think there is a bijection between seed collections and ACLs
[18:44] <cjwatson> one seed collection defines one package set which is given an ACL in LP
[18:45] <cjwatson> or thereabouts
[18:45] <LaserJock> right
[18:45] <cjwatson> actually that isn't quite true given overlaps but you get the general idea
[18:45] <LaserJock> how is Canonical then going to define what it supports? will that be independent of seeds?
[18:46] <cjwatson> I don't see any reason why we would put all this effort into a more expressive infrastructure only to not use it to define what we support :-)
[18:46] <RainCT> (if someone answered my question, please repeat the answer.. irssi reconnected)
[18:46] <cjwatson> there has been some talk of something like supported-by: canonical in Packages, and I think we'll probably end up with something along those lines though probably not quite
[18:47] <ScottK-desktop> RainCT: I don't think we got a question from you.
[18:47] <cjwatson> I would like to get to the point where synaptic/gnome-app-install can display icons indicating a package's support status, analogous to the current main/universe display
[18:47] <cjwatson> but for that to not require physically separate Packages files
[18:47] <cjwatson> we may need pdiffs for this to be sane
[18:47] <RainCT> evil network-manager..
[18:47] <LaserJock> right
[18:48] <RainCT> Btw, what will happen with MOTU? Will it still have the same powers as now, or will applying to additional teams (or requesting sponsorship from them) be necessary in order to upload packages maintained by certain teams?
[18:48] <cjwatson> err the detailed answer to that question changes every time I look
[18:48] <RainCT> lol
[18:48] <LaserJock> I really wish g-a-i wouldn't used "Canonical-maintained applications" for Main, kinda makes me sad :(
[18:48] <cjwatson> there is no intention to disband MOTU or anything
[18:49] <cjwatson> (I suspect if there were there'd be a riot!)
[18:49] <LaserJock> I would suspect the MOTUs "universe" just starts getting smaller
[18:50] <cjwatson> or bigger - there are things that are in main that don't necessarily need to be core-only
[18:50] <LaserJock> true
[21:03] <arthur-> doko: I have a fix for fastjar's make_manifest instead of building it with -O0 on ia64, it's not miscompilation
[21:07] <arthur-> doko: see in query
[21:17] <maxb> The nvidia-180-libvdpau stuff... doesn't that need to either be using version-agnostic names, or declare Provides+Conflicts+Replaces of version-agnostic names?
[21:43] <tvakah> quick question before I jump, is jaunty in a place where someone used to running debian unstable+experimental could get by?
[21:45] <cody-somerville> tvakah, can you deal with breakage?
[21:46] <tvakah> cody-somerville: I know how to downgrade and pin packages if that's what you mean
[21:46] <cody-somerville> tvakah, jaunty should be okay for you
[21:46] <tvakah> cody-somerville: righto, thanks :)
[21:47] <cody-somerville> np
[21:48] <ScottK-desktop> mvo: WRT jaunty backup solution, did you see SuSE just announced http://www.csync.org/
[21:49] <mvo> ScottK-desktop: thanks, I have not seen this one yet
[21:49] <ScottK-desktop> mvo: They just announced it yesterday.
[21:50] <mvo> ScottK-desktop: I'm not sure how useful it is if the primary purpose is sync, but I will try to find out more
[21:51] <ScottK-desktop> My thought is that backup is potentially a subset of sync and if you can do two things with one tool that another distro is already developing ....
[21:52] <mvo> ScottK-desktop: yeah, its definitely a good hint and something that we should know about
[21:52] <pwnguin> how's csync different than a gui frontend to zsync?
[21:52] <ScottK-desktop> No gui to start with.
[21:52] <pwnguin> oh
[21:52] <ScottK-desktop> The description reminds me a lot of unison.
[21:52] <pwnguin> silly me; i thought "normal user" meant something entirely different than they did
[21:53] <mvo> ""The implementation of the library will be introduced as a File Synchronizer for a Microsoft Active Directory environment (Roaming Home Directories for Linux Clients). " <- looks like that is the fist target use for the lib
[22:01] <maxb> Hmm... unison written in a mainstream language? :-)
[22:01] <pwnguin> hey
[22:01] <pwnguin> ocaml is neat
[22:02] <pwnguin> it just lacks a threaded garbage collector is all ;)
[22:02] <maxb> Maybe I should have another try at learning ML, just for fun :-)
[22:03] <pwnguin> ive been doing the project euler stuff in ocaml
[22:04] <pwnguin> but then, I used to grade undergraduate programs in ocaml
[22:04] <pwnguin> ymmv
[22:07] <bryce> nenolod: I posted some patches for the crash on bug #188659
[22:09] <nenolod> bryce: thanks
[22:16] <nenolod> bryce: http://launchpadlibrarian.net/21065596/null_ptr_fix.patch is wrong, truncation_point is not a pointer
[22:16] <nenolod> bryce: but i will push an upload to debian with those patches
[22:31] <tvakah> nvidia binary driver in jaunty: do I hold back all of x11 or is there a version of 180 on ppa or some such?
[22:32] <tjaalton> you can use it by specifying IgnoreABI or such on the xorg.conf
[22:33] <tjaalton> so no ppa could fix the driver, only nvidia can
[22:34] <tvakah> yeah but it's blocking the upgrade currently since nvidia-glx-180 provides xserver-xorg-video-4, which conflicts with xserver-xorg-core
[22:34] <tjaalton> for good reason
[22:35] <tjaalton> it can be forced though, but you get to keep both pieces
[22:36] <tvakah> tjaalton: is this a matter of nvidia upstream, or rebuilding it for the new xserver in jaunty?
[22:37] <tjaalton> tvakah: we don't have the source, so it's nvidias fault
[22:38] <tjaalton> also mentioned on the alpha2 release notes IIRC
[22:41] <bryce> nenolod: right, needs a *
[22:45] <tvakah> hmmm this may be the final straw that makes me seek an ati graphics module for my notebook
[22:46] <tjaalton> for a new one you mean?
[22:47] <maxb> Presumably fglrx is in the same mess
[22:48] <tvakah> no I have a notebook with discrete graphics that can be replaced fortunately
[22:48] <tjaalton> strange notebook
[22:49] <tvakah> asus c90s
[22:51] <tjaalton> oh, more like a mobile pc :)
[22:51] <tvakah> pretty much, that's exactly what I wanted :)
[22:52] <tvakah> so, if trying to force xorg 1.6 + nvidia breaks things into pieces, are the pieces fewer if I hold xorg back on 1.5?
[22:52] <bryce> tvakah: make sure to get r500 or older
[22:52] <bryce> tvakah: in which case the open -ati driver supports it quite nicely
[22:52] <bryce> r600 and newer support is in the works and probably will be there for jaunty+1
[22:53] <bryce> (_maybe_ sooner, we'll see)
[22:53] <tvakah> gotcha, I'll see what I can find
[22:54] <tvakah> hmm yeah, according to the forums the 180.22 driver released yesterday works with some semblance of stability with IgnoreABI on
[22:57] <tjaalton> 180 always has
[22:57] <tjaalton> the thing is that they've compiled it against the older stack
[22:57] <tjaalton> so you need to use the option
[22:58] <tjaalton> 177 segfaulted when I tried it a ~month ago
[23:35] <cjwatson> Keybuk: pcmciautils done now, sorry for lateness
[23:53] <sconklin> Is there a place that userspace packages are usually kept if they're not on launchpad? I'm looking for pm-utils and all I can find on launchpad is "it's not here".
[23:55] <cjwatson> sconklin: many packages have no revision control as yet and the only place you'll find them is 'apt-get source pm-utils'
[23:56] <cjwatson> (pm-utils may or may not have somewhere you haven't found, I haven't checked)
[23:56] <cjwatson> Homepage: http://pm-utils.freedesktop.org/
[23:56] <cjwatson> Vcs-Browser: http://svn.debian.org/wsvn/collab-maint/ext-maint/pm-utils/trunk
[23:56] <cjwatson> Vcs-Svn: svn://svn.debian.org/svn/collab-maint/ext-maint/pm-utils/trunk
[23:56] <cjwatson> that's the Debian revision control rather than ours but might be useful
[23:57] <cjwatson> information from 'apt-cache showsrc pm-utils' on jaunty
[23:58]  * cjwatson sticks out his tongue at ubottu and waggles it around
[23:59]  * StevenK waves http://paste.ubuntu.com/102967/ at cjwatson (livecd-rootfs)