[00:01] <infinity> munckfish: Anyhow, like I said, a "debootstrap --variant=buildd" with the build-deps installed after the fact (copy 'em straight from the "apt-get install" in the launchpad build log, if you want to make sure you're getting exactly the same build environment), should reproduce it.
[00:01] <infinity> munckfish: Making sure to "linux32 chroot" not just "chroot", if you're on a 64-bit machine.
[00:01] <cjwatson> -m elf32ppclinux comes from LDFLAGS in ps3-kboot/kboot-11/Makefile
[00:02] <munckfish> cjwatson: dare we just kill that variable I wonder?
[00:03] <cjwatson> just looking for where the other one comes from
[00:03] <cjwatson> but yeah, I have to say that -m elf32ppclinux doesn't sound very sane for a 32-bit kernel; does it make sense for the userspace bits though?
[00:04] <infinity> s/32/64/ I assume you mean?
[00:05] <cjwatson> 32-bit -> 64-bit I meant, yes
[00:17] <munckfish> cjwatson, infinity: as far as I understood it only the kernel needs to be 64 bit, everything else can be 32.
[00:17] <munckfish> I'm trying to work out
[00:17] <munckfish> how LDFLAGS ends up with the two -m
[00:17] <munckfish> I think the
[00:18] <cjwatson> munckfish: I have a feeling I'm almost there ...
[00:18] <munckfish> first -m
[00:18] <munckfish> is constructed in /arch/powerpc/Makefile
[00:18] <munckfish> e.g.
[00:18] <munckfish> line 67
[00:18] <munckfish> override LD	+= -m elf$(CONFIG_WORD_SIZE)ppc
[00:19] <cjwatson> yeah, ahead of you :-)
[00:19] <cjwatson> (though keep going)
[00:19] <slangasek> megabyte405: you asked for a review of the abiword 2.6 package, where is this?
[00:19] <slangasek> megabyte405: is http://launchpadlibrarian.net/13344323/updatetoabi26.debdiff.gz the most current (eew, giant debdiff)?
[00:19] <infinity> If the second one is being used for userspace overrides, it can probably be dropped entirely, since -m32 is the default anyway.
[00:20] <cjwatson> munckfish: the other one comes from kboot-11/Makefile, of course
[00:20] <cjwatson> infinity: right
[00:20] <slangasek> wasabi: did you find out what was wrong with pam on your console?  something that wouldbe an Ubuntu bug?
[00:20] <cjwatson> I'm just waiting for linux.tar.bz2 to unpack, to test this hypothesis
[00:20] <megabyte405> slangasek: the abiword bug is 202174 but since it involves a new upstream package the debdiff is only of academci interest.  You'll want to see my ppa, linked in that bug or https://launchpad.net/~abiryan/+archive/
[00:21] <megabyte405> erm, bug 202174
[00:21] <ubotu> Launchpad bug 202174 in abiword "Please update to version 2.6" [Medium,New] https://launchpad.net/bugs/202174
[00:21] <infinity> cjwatson: Infinitely curious why this doesn't trigger on davis, but even an infinity amount of curiosity is not enough for me to take the time out to find out why...
[00:21] <cjwatson> bingo
[00:21] <megabyte405> there we go :)  I have a fairly complete summary in the bug comments there.
[00:21] <infinity> s/infinity/infinite/
[00:21] <cjwatson> my tests were with debian/rules binary; fakeroot debian/rules binary
[00:21] <cjwatson> er, s/binary/build/ first one there
[00:22] <slangasek> megabyte405: ah, ok, was reading from the bottom and missed the link to your ppa, thanks
[00:22] <infinity> dpkg-buildpackage produces different behavior from debian/rules build, I take it?
[00:22] <cjwatson> but if you use 'dpkg-buildpackage -b' instead, then LDFLAGS is exported by dpkg-buildpackage, and even though it gets reset, the exportedness survives
[00:22] <infinity> Ah-ha.
[00:22] <infinity> Yay for the "new" dpkg.
[00:22] <megabyte405> slangasek: np
[00:22] <cjwatson> LDFLAGS in kboot-11/Makefile was only meant to be local to that Makefile
[00:22] <cjwatson> 'unexport LDFLAGS' right after it should fix this
[00:23] <cjwatson> (that's the most minimal fix; removing LDFLAGS altogether may well also work but is a bigger change)
[00:23]  * slangasek mutters at the unseasonable hail
[00:23] <infinity> cjwatson: Okay, if this is under control, I'm going to wipe out my test env and turn adare back on.
[00:23] <cjwatson> yep, I have it reproduced on davis now
[00:24] <cjwatson> just testing the unexport approach
[00:26] <munckfish> cjwatson: so how do you want to proceed? do you want to add this to my disable cross-compile patch ?
[00:26] <cjwatson> yeah, that does the trick
[00:26] <cjwatson> I think that's probably best
[00:27] <megabyte405> slangasek: I'm out - if you need something email me at abiryan at ryand dot net
[00:27] <slangasek> megabyte405: ok, cheers :)
[00:29] <cjwatson> munckfish: shall I go ahead and do that? I'm happy to now that we see the problem, and I'm pretty confident that it will yield a working image since it's solely working around the build strangeness without which you produced a working image
[00:30] <munckfish> cjwatson: pls go for it
[00:30] <munckfish> It's late here anyway so I wouldn't be able to address this till tomorrow morning at best anyway
[00:31] <cjwatson> ok
[00:31] <munckfish> Sorry I couldn't fix it on my own, I know you didn't want to get distracted too much by this project at the mo
[00:33] <cjwatson> well, this was a pretty tricky one to see
[00:33] <cjwatson> you get to test the result though :)
[00:34] <munckfish> cjwatson: yeah, next job is to dive into the Xorg prob
[00:34] <munckfish> ok I have to go sleep now
[00:34] <munckfish> or I'll be useless to my employer
[00:35] <infinity> munckfish: Don't worry too much about it.  Every time a member of the distro team accuses my buildds of causing a build failure and we later prove it's a packaging bug, I get a free beer so, in essence, you're just contributing to my alcoholism.
[00:35] <infinity> munckfish: Clearly a win.
[00:35] <munckfish> infinity: :)
[00:36] <munckfish> cjwatson, infinity: good night guys, thx for all the help. I look forward to testing the ps3 Xorg problem. cheers!
[00:36] <cjwatson> munckfish: sleep well :)
[01:15] <jdong> kees: does apparmor support subprofiles, like when /bin/foo launches /bin/bar, use this profile, but otherwise leave /bin/bar alone?
[01:17] <kees> jdong: yup -- through the exec, either inherit or switch profiles
[01:18] <kees> jdong: oh, but you mean "only isolate /bin/bar if /bin/foo launched it" ?
[01:18] <jdong> kees: right, parent-aware profiles
[01:18] <kees> jdong: not in a simple fashion, no.  see if anyone is around on #apparmor, though.  they might be able to discuss "changehat" and other odd things
[01:19] <kees> (#apparmor is on oftc, btw, sorry)
[01:19] <jdong> kees: meh I'll go for a simplicity workaround. I'm trying to write a clamscan apparmor profile specific to dealing with my mail
[01:20] <jdong> the amount of security bugs found in clamav's unpackers really concerns me
[01:20] <kees> heh, no kidding.
[01:20] <jdong> btw, whoever in u-m-s is listening, bug 184238 needs sponsorship and is wanted for Hardy release....
[01:20] <ubotu> Launchpad bug 184238 in transmission "Menu entry should be named "Transmission BitTorrent Client" Instead of only the unclear "Transmission"" [Medium,Confirmed] https://launchpad.net/bugs/184238
[01:21] <jdong> kees: how safe are apparmor restrictions? I'd expect as long as a root account isn't compromised I'd be totally safe, and even some forms of root compromise are not problematic?
[01:23] <crimsun> any root compromise would allow /etc/init.d/apparmor stop.
[01:23] <kees> jdong: in theory, AA profiles are as strong as the kernel.  :P  I've done things like run /bin/bash as root listening on an open port, and no one could do anything with it since they didn't have an exec prvis
[01:23] <kees> *privs
[01:25] <cjwatson> I hope you locked it down more than that; bash doesn't need to exec subprocesses in order to (say) overwrite files
[01:25] <jdong> crimsun: well to call apparmor stop I think writing to sysfs is necessary to clear out the profile
[01:26] <jdong> an unrestricted root compromise, sure you're totally screwed :)
[01:28] <kees> cjwatson: right, of course -- I didn't let it do anything.
[01:29] <kees> jdong: I think there is a changehat syntax for profile names... it's been a while since I've looked at that.
[01:30] <kees> crimsun: yeah, without the write perms to the aa security tree in /proc you can't shut it down.
[01:30] <jdong> kees: yeah the syntax for profiles is pretty easy, the question is how much effort it'd take for me to hook that into my scripts
[01:30] <jdong> kees: and whether or not it's easier than just hardlinking a new clamscan ;-)
[01:30] <jdong> (rhetorical, most likely)
[01:30] <kees> jdong: if you run with clamd (and use clamc for the scanning) you could probably just isolate clamd itself.
[01:31] <kees> using clamc is way faster too.  ;)
[01:31] <jdong> that's another good idea :)
[01:39] <jdong> AAAH OH FSCK!!!
[01:39] <kees> ???
[01:40]  * jdong angrily aliases rm to rm --one-file-system
[01:40] <jdong> follow up lesson: ALL mountpoints should go in /media!
[01:40] <bryce> ouch
[01:40] <jdong> alright, damage control time... fortunately XFS ain't too fast deleting files
[01:42] <RAOF> jdong: :(
[01:42] <jdong> RAOF: this kinda thing also makes me worried about gvfs....
[01:42] <jdong> because I simply mounted a sshfs in a temp workdir in my ~/
[01:42] <jdong> but if someone tried to rm -rf a homedir with a gvfs FUSE auto mountpoint....
[01:43] <RAOF> Awkward, yeah.
[01:45] <Fujitsu> More than awkward.
[01:45] <Fujitsu> That'd be a fairly critical bug.
[01:46] <jdong> Fujitsu: well we do it for Hardy by default.... ~/.gvfs often contains fuse mounts of stuff you've browsed in nautilus
[01:46] <jdong> and for things like ssh:// it's identical to a sshfs backend in functionality
[01:47] <Fujitsu> So I note. This is probably a severe problem.
[01:47] <Fujitsu> I don't expect ~/.* to include my server's filesystem.
[01:47] <jdong> right
[01:47] <jdong> but SOMEONE's gonna argue that this is somehow a feature :)
[01:48] <Fujitsu> And a lot more people are going to lose their remote home directories.
[01:49] <jdong> yeah I'm concerned. I wouldn't ever expect a recursion down my home directory to include network shares I've browsed.
[01:49] <jdong> even if removal is not invovled, it's still an annoyance that things like Baobab will recurse down a 7.5TB SFTP server I browsed 10 minutes ago.
[01:50] <Fujitsu> Haha.
[01:51] <Fujitsu> It is very convenient, but also dangerous...
[02:07] <LaserJock> is volumeid meant to be removed?
[02:08] <crimsun> yes, by udev.
[02:08] <LaserJock> ok, cool
[02:55] <LaserJock> anybody around who could help me figure out valgrind output?
[02:55] <LaserJock> I'm trying to find memory leaks in seahorse
[02:55] <jdong> In Soviet Russa, ValGr... oh never mind.
[02:55] <LaserJock> I ran valgrind --tool=memcheck --leak-check=yes seahorse
[02:56] <jdong> this sounds more interesting than an English paper :)
[02:56]  * jdong sits and watches
[02:56] <LaserJock> and I get:
[02:56] <LaserJock> definitely lost: 72,750 bytes in 160 blocks.
[02:56] <LaserJock> indirectly lost: 124,747 bytes in 3,902 blocks.
[02:56] <LaserJock>  possibly lost: 332,563 bytes in 278 blocks.
[02:57] <LaserJock> is that memory leaking?
[02:59] <slangasek> it's memory not freed on exit
[02:59] <slangasek> but I'm not sure how accurate valgrind's leak checking is
[03:00] <LaserJock> slangasek: is there a recommended way to do it?
[03:00]  * StevenK wonders how he can find all the packages that install a particular alternative
[03:00] <slangasek> LaserJock: way to do what?
[03:00] <slangasek> to find memory leaks?
[03:00] <LaserJock> yeah
[03:01] <slangasek> understanding the code :)
[03:01] <LaserJock> yikes
[03:01] <LaserJock> ;-)
[03:01] <slangasek> the variable should be locally scoped, in this case
[03:02] <slangasek> so you should have a finite number of ways to leave that scope
[03:02] <slangasek> and you just need to make sure the memory is freed, or control of the memory is passed somewhere else, before leaving the scope
[03:05] <LaserJock> slangasek: hmm, I guess I would have thought it was in a local scope already :/
[03:06] <slangasek> yes, that's what I mean - so there's a finite number of places the memory can leak
[03:06] <slangasek> i.e., anywhere that you leave that scope without taking care of the memory
[03:26] <LaserJock> slangasek: so would freeing the memory within the for loop instead of outside be better?
[03:28] <LaserJock> I don't see how you would particularly leave the scope without freeing the memmory unless you crash somewhere in there
[03:28] <LaserJock> gosh I need to learn C
[03:30] <lamalex> Hey, does anyone in here know how the subset of packages that get put in add/remove are chosen?
[03:30] <lamalex> what characteristics do those packages have
[03:30] <LaserJock> lamalex: I think in general it's packages that have .desktop files
[03:31] <lamalex> does it have its own cache somewhere? If I wanted to do something with just those packages do you know of a clean way?
[03:32] <LaserJock> lamalex: look in /usr/share/app-install/desktop/
[03:32] <lifeless> slangasek: valgrind is pretty good
[03:32] <lifeless> slangasek: 'definitely lost' is: memory that was allocated, and there are no pointers to it, but free(base) was not called.
[03:33] <lamalex> LaserJock: thanks
[03:33] <lifeless> slangasek: I believe 'indirectly lost' is memory that is pointed too from definitely lost memory
[03:36] <lamalex> hmm, i'd be surprised if this read from desktop files, but it's a place to start, thanks for the help
[03:36] <LaserJock> lamalex: what do you mean?
[03:37] <LaserJock> lamalex: what is it that you're trying to do?
[03:37] <lamalex> well to read all of those files for the package descriptions would be slow
[03:37] <LaserJock> lamalex: it caches them
[03:37] <lamalex> are you familar with gnome do?
[03:37] <LaserJock> sure
[03:37] <lamalex> gnome do apt plugin
[03:37] <lamalex> but indexing 23000 packages is not reasonable
[03:37] <LaserJock> hmm
[03:38] <lamalex> so I was going to choose the subset of packages in add/remove
[03:38] <lamalex> i figured it was running off of an sqlite db or something
[03:39] <LaserJock> see /var/cache/app-install/
[03:41] <lamalex> heh and the problem with binary files is you can't cat them :P
[03:58] <emgent> morning
[03:59] <fabbione> morning
[03:59] <fabbione> emgent: early bird or late night owl?
[04:00] <emgent> fabbione: lol
[04:01] <emgent> i dont like sleep :P
[04:03] <emgent> Hobbsee: have you time for some ACK ?
[04:03] <slomo> slangasek: yes
[04:18]  * Hobbsee waves to fabbione
[04:21] <fabbione> hey Hobbsee
[04:24] <slangasek> LaserJock: well, the point is I haven't had a chance to look at this code myself yet to /know/ whether there are memory leaks...
[04:25] <LaserJock> slangasek: sure, I'm just not sure
[05:56] <LaserJock> slangasek: it looks ok to me, but I'm not confident as you pointed out problems with my first upload
[05:57] <LaserJock> should I leave it for somebody else?
[05:57] <LaserJock> I just don't want it to fall through the cracks
[07:04] <fabbione> morning
[07:04] <fabbione> again
[07:04] <fabbione> nevermind
[07:04] <fabbione> wrong window
[07:04] <Hobbsee> remorning.
[07:05] <Fujitsu> Mourning.
[07:12] <pitti> Good morning
[07:12] <fabbione> hey pitti
[07:13] <Hobbsee> guten morgen, pitti
[07:13] <Hobbsee> hey, is anyone offering to be a projective missile?
[07:15] <fabbione> Hobbsee: eh?
[07:15]  * Hobbsee needs to use something big as a projective missile.
[07:15]  * fabbione doesn't really know what "projective missile" means in this case
[07:15] <Hobbsee> fabbione: heard of a missile?
[07:16] <Hobbsee> fabbione: something large that you throw at someone, or something.  it goes through the air.
[07:16] <fabbione> yeah i heard about that ;)
[07:17] <Hobbsee> yeah.  i need one.
[07:17] <fabbione> what for?
[07:18] <Hobbsee> my boss.
[07:18] <Hobbsee> he fails in crucial ways about "notifying people about important changes in the workplace"
[07:18]  * Hobbsee has no idea if, and when, the power will go out tonight there.
[07:18] <elemjay> Latest Google Tech Talk on the future of Linux: http://www.youtube.com/watch?v=4A6ImflixL8
[07:19]  * Hobbsee is going to be absolutely stuffed, along with my coworkers, if the power *does* go out while we're still there.  Although we certainly won't get hungry.
[07:19] <fabbione> Hobbsee: you really don't need a missile for that
[07:20] <fabbione> it would be a waste of good resources to kill a fly
[07:21] <TheMuso> Hobbsee: And why would the power go out?
[07:21] <Hobbsee> TheMuso: planned maintenance on the local power station.
[07:21] <TheMuso> Oh.
[07:21] <Hobbsee> TheMuso: one says it only happens on monday at 10pm, the other says it happens on both monday and tuesday at 10pm.
[07:21] <TheMuso> Oh right.
[07:22] <Hobbsee> I wouldn't have found out about either notice, if i hadn't been browsing back through the supervisor book, over the last week, nor reading random pieces of paper in teh managers office.
[07:22]  * Hobbsee does *not* call this decent warning.
[07:22] <Hobbsee> especially seeing the rosters still schedule us all to finish after that point.
[07:23]  * Hobbsee looks for her torch
[07:33] <asac> pitti: langpacks ;)
[07:33] <asac> anything left we need to figure?
[07:35] <asac> Riddell: kubuntu offline startpage localization :) ... did you figure why the links are broken?
[07:37] <pitti> asac: I'll have a deeper look after I went through my email
[07:37] <pitti> asac: but it looks fine so far
[07:37] <pitti> asac: what is 'revpath'?
[07:37] <asac> pitti: did you rerun the command i gave you to tsee if it works now properly with your permissions?
[07:38] <asac> pitti: psst.  :)
[07:38] <asac> pitti: i didn't know about it until i found that its missing on rookery
[07:38] <asac> pitti: davidm made use of it ... i had to copy the binary from ronne
[07:39] <pitti> ugh
[08:17] <laga> slangasek: great, thanks for the merge
[08:18] <laga> mjg59: regarding https://bugs.launchpad.net/bugs/157691 - is there any way we can make detection of the graphics driver a bit more robust? autodetection is becoming common these days i guess..
[08:18] <ubotu> Launchpad bug 157691 in hotkey-setup "Hardy/Gutsy crashes when the lid is closed on a HP 6710b, HP 6510b and HP 2510p" [Undecided,Fix released]
[08:43] <laga> hum. are there no daily builds today?
[08:44] <slangasek> no, we're ramping up for candidate images
[08:44] <laga> too bad. oh well, i guess i get to try the candidate image for mythbuntu then :)
[08:50] <pitti> slangasek: seb128 and I just agreed on how to fix camera handling eventually; we can't fix nautilus properly, so we'll enable it in gnome-volume-manager again
[08:50] <pitti> slangasek: I'd like to upload this change now, so that it will work again in RC; ok for you?
[08:50] <pitti> slangasek: (simple gconf default change in the .schema file, no code changes)
[08:52] <slangasek> pitti: corresponding bug #?
[08:52] <dholbach> good morning
[08:52] <pitti> seb128: what's the bug# for that?
[08:52] <seb128> bug #208467
[08:52] <ubotu> Launchpad bug 208467 in nautilus "Camera Device button "Open F-spot Photo Manager" doesn't work" [High,Confirmed] https://launchpad.net/bugs/208467
[08:53] <pitti> thanks; I'll add a g-v-m task and an explanation
[08:53] <seb128> thank you
[08:54] <seb128> slangasek: I've uploaded a new gtk, I synced the new debian revision which fixes the gtk im setting change patch backported some time ago (1 liner) and the dbg packages to work again (not really required since the dbgsym works alright)
[08:55] <seb128> slangasek: the update should not be an issue but it's not a priority either, feel free to accept it or not
[08:58] <slangasek> pitti: yep, go for it
[08:58] <slangasek> seb128: ok, putting it in the "later" pile for now, thanks :)
[08:58] <seb128> slangasek: ok ;-)
[09:40] <emgent> morning
[09:41] <sabdfl> why would f-spot depend on sqlite and sqlite3 at the same time?
[09:42] <tjaalton> slangasek: vdr-plugin-console and -osdserver are waiting on the queue, uploads approved by sistpoty
[09:42] <tjaalton> slangasek: fixes FTBFS
[09:42] <slangasek> sabdfl: database upgrade support :/
[09:43] <slangasek> tjaalton: can you give me a pointer to this approval?
[09:43] <tjaalton> slangasek: a sec
[09:44] <tjaalton> slangasek: http://irclogs.ubuntu.com/2008/04/11/%23ubuntu-motu.html towards the end
[09:47] <slangasek> tjaalton: right, accepted
[09:47] <tjaalton> slangasek: cool, thanks
[09:58] <sabdfl> slangasek: ah, right. read from the old, write to the new. yowser
[10:02] <pitti> mvo: is bug 211978 an issue for hardy?
[10:02] <ubotu> Launchpad bug 211978 in update-manager "do-release-upgrade -d doesn't work immediately after running do-release-upgrade" [High,In progress] https://launchpad.net/bugs/211978
[10:03] <pitti> hey sabdfl, how are you?
[10:04] <StevenK> pitti: Hey, time for a dorky CDBS question?
[10:04] <pitti> StevenK: I'll answer eventually
[10:04] <mvo> pitti: its fixed in hardy
[10:05] <pitti> mvo: ah, can you please close it then? thanks *hug*
[10:05] <s|k> hi
[10:05] <s|k> I know a little python and C and was thinking of maybe contributing
[10:05] <s|k> :/
[10:06] <StevenK> pitti: Heh. CDBS is symlinking the Debian changelog only, and I thought there was a magic button to make it symlink the entire doc dir?
[10:06] <pitti> StevenK: it never symlinks entire directories, since that's evil with dpkg's handling of dirs vs. symlinks
[10:06] <pitti> StevenK: it will symlink individual files in doc/pkg/ if they are identical in any of its direct dependencies
[10:06] <pitti> except copyright
[10:07] <StevenK> pitti: Should I ignore lintian's bleating that the Debian changelog is a symlink?
[10:07] <pitti> StevenK: I do, anyway :)
[10:07] <StevenK> Heh
[10:09] <s|k> :/
[10:13] <soren> pitti: "/usr/share/doc/package may be a symbolic link to another directory in /usr/share/doc only if the two packages both come from the same source and the first package Depends on the second. " Straight from Debian Policy?
[10:15] <pitti> soren: right, but dpkg wreaks havoc if you ever replace the symlink with a proper dir again
[10:15] <pitti> so I don't do it
[10:16] <pitti> s|k: anything in particular you'd like to work on?
[10:16] <pitti> s|k: usually people do not contribute "to C programs", but to a set of packages that interest them :)
[10:16] <soren> pitti: Oh, really? I did not know that.
[10:16] <soren> pitti: Surely that can be fixed?
[10:16] <pitti> soren: that's rather deliberate, I think
[10:17] <soren> pitti: Surely that can be fixed? :)
[10:17] <pitti> soren: e. g. you might have /usr/share point to a different partition if your /usr becomes full, and similar situations
[10:17] <pitti> you want dpkg to honor the symlink
[10:17] <s|k> pitti: by working on the project itself?
[10:18] <megabyte405> FYI - addressed concerns in the abiword 2.6 bug
[10:18] <soren> pitti: Hmm... Sounds reasonable, I suppose.
[10:18] <s|k> as in work on epiphany or something and not ubuntu
[10:18] <pitti> s|k: of course we always welcome people who want to work in a 'horizontal' approach, i. e. fix lots of bugs in lots of different packages
[10:18] <s|k> I see
[10:18] <pitti> s|k: in fact we probably have too few of those :)
[10:18] <s|k> so is it mostly C?
[10:18] <megabyte405> s|k: if you take the horizontal approach please make sure to send patches upstream :)
[10:19] <pitti> s|k: What I'm trying to say is, we usually don't "dump" work on new contributors; you should rather know what you enjoy working on
[10:19] <s|k> I see
[10:19] <pitti> s|k: I'd say the vast majority of packages are C, but there's a good chunk of Python, Perl, and C# nowadays
[10:19] <megabyte405> s|k:  really varies from project to project - find something that interests you, then use your skills: unlike a job where you have your skills and might be told what "interests you"
[10:19] <megabyte405> and c++ too
[10:19] <pitti> right ^
[10:20] <s|k> I see
[10:20] <pitti> s|k: if you want to work on little chunks in various packagages to use and improve your C skills, you might consider looking into fixing confirmed/triaged bugs
[10:20] <s|k> ok, those are listed on launchpad?
[10:21] <s|k> how well do I have to know stuff like gobject and gtk+? Pretty well huh?
[10:21] <pitti> s|k: https://wiki.ubuntu.com/UbuntuDevelopment is a good introduction and link collection about how to get into Ubuntu development, the necessary packaging bits, how to apply patches, etc.
[10:21] <sabdfl> anybody else seeing evince get stuck during the document loading?
[10:22] <s|k> yeah I have that page open in my tab
[10:22] <stgraber> sabdfl: I do
[10:22] <pitti> s|k: people usually learn those while they work on something
[10:22] <stgraber> sabdfl: changing the window's size usually help to unstuck it
[10:22] <pitti> sabdfl: hm, works fine for me; only on some documents, or on all of them? pdf? ps?
[10:23] <sabdfl> seems to be on all the .pdf's i've opened recently
[10:23] <Amaranth> sabdfl: sometimes, it doesn't actually get stuck it just doesn't update the drawing
[10:23] <Amaranth> sabdfl: if you minimize it then restore it it works again
[10:23] <sabdfl> interesting - yes, that works
[10:23] <sabdfl> could it be a compiz interaction?
[10:24] <Amaranth> I am sure that is where the blame will end up
[10:25] <megabyte405> s|k: if you just find something that interests you (an itch to scratch, so to speak) the skills will come with a bit of googling and some experimentation. Remember, nobody needs to know how many builds don't compile on your machine as you learn :)
[10:29] <tkamppeter> pitti, hi
[10:29] <s|k> megabyte405: ok :)
[10:29] <pitti> hey tkamppeter! made it back in one piece?
[10:30] <tkamppeter> yes, pitti, I arrived yesterday, with United.
[10:30] <pitti> sabdfl: could be, I am using metacity on my desktop
[10:31] <tkamppeter> pitti, it is about bug 195782.
[10:31] <ubotu> Launchpad bug 195782 in hplip "Users not automatically added to "scanner" group: No scanning functions of HP multi-function in Hardy" [Undecided,New] https://launchpad.net/bugs/195782
[10:32] <tkamppeter> The HP devices get there "scanner" capability without problem, but there seems to be nothing which sets the permissions then.
[10:33] <tkamppeter> Permissions must be set that both "lp" and the user who is currently logged in on the desktop have read and write access.
[10:33] <pitti> tkamppeter: that needs a hal debug output, I'm afraid (https://wiki.ubuntu.com/DebuggingHal)
[10:33] <pitti> tkamppeter: I thought it worked for you?
[10:34] <tkamppeter> pitti, I checked only the "lshal" output and that was OK.
[10:34] <pitti> you didn't actually try to scan something?
[10:34] <pitti> tkamppeter: well, my scanner (not HP) has the same property, it works fine for it
[10:35] <pitti> so there's something wrong in hal and the auto-ACL magic
[10:40] <tkamppeter> pitti, I have also removed the UDEV rules files of HPLIP, as they should not be needed any more.
[10:45] <pitti> carlos: will Rosetta exports have XPI stuff for dapper to gutsy, too? if so, I need to filter them out in langpack-o-matic (since we don't want them for stables)
[10:46] <carlos> pitti: that's up to asac to decide it
[10:46] <carlos> if we import them, yes, it will
[10:46] <pitti> carlos: ok, so I better filter them out on my side?
[10:47] <carlos> pitti: not really, unless we really import them
[10:47] <carlos> if we import them, I guess is because we need them
[10:47] <pitti> so we won't for dapper to gutsy? asac?
[10:47] <carlos> so if you filter them out... we don't need them and thus, don't neeed to import it in first place :-P
[10:47] <pitti> right
[10:51] <asac> pitti: he? i don't think this is an issue is it? if the translation is in langpacks users will auto get that?
[10:52] <pitti> asac: but we don't want that for dapper to gutsy
[10:52] <pitti> it conflicts with the mozilla-firefox-locale packages
[10:52] <pitti> and we haven't tested it
[10:52] <pitti> maybe later, but not right now
[10:52] <tkamppeter> pitti, I have tried the debug logging of hald, but I did not find anything useful in there. The word "scanner" does not appear.
[10:53] <pitti> tkamppeter: do you see anything matching 'acl'?
[10:53] <asac> i don't understand why suddently _gutsy_ pops up while we are preparing hardy?
[10:53] <pitti> tkamppeter: in particular, the setfacl call?
[10:53] <asac> if you just want to know if we want rosetta exports in gutsy: no!
[10:53] <pitti> asac: right, that was my question; whether i need to special-case hardy in langpack-o-matic or not
[10:54] <asac> pitti: yes ... all this should not happen right now for anything else than hardy
[10:54] <asac> pitti: we don't even have ffox 3 in << hardy
[10:54] <asac> and no templates for gutsy afaict
[10:56] <tkamppeter> pitti, there are calls of the /usr/lib/hal/hal-acl-tool
[10:56] <pitti> tkamppeter: can you put the log somewhere?
[10:59] <tkamppeter> pitti, you can see it as http://www.linux-foundation.org/~till/tmp/hal.log now.
[11:02] <pitti> ci-tracker.c:366: Error doing GetSessionForUnixProcess on ConsoleKit: org.freedesktop.DBus.GLib.UnmappedError.CkManagerError.Code0: Unable to lookup session information for process '5747'
[11:02] <pitti> tkamppeter: ^ do you have a consolekit sessin? ck-list-sessions
[11:03] <tkamppeter> Session1:
[11:03] <tkamppeter> 	uid = '1000'
[11:03] <tkamppeter> 	realname = 'Till Kamppeter,,,'
[11:03] <tkamppeter> 	seat = 'Seat1'
[11:03] <tkamppeter> 	session-type = ''
[11:03] <tkamppeter> 	active = TRUE
[11:03] <tkamppeter> 	x11-display = ':0'
[11:03] <tkamppeter> 	x11-display-device = '/dev/tty7'
[11:03] <tkamppeter> 	display-device = ''
[11:03] <tkamppeter> 	remote-host-name = ''
[11:03] <tkamppeter> 	is-local = TRUE
[11:03] <tkamppeter> 	on-since = '2008-04-14T14:37:30Z'
[11:03] <tkamppeter> 	idle-since-hint = '2008-04-14T16:39:45Z'
[11:03] <pitti> ok, that's fine
[11:03] <tkamppeter> pitti, is that the expected output?
[11:03] <pitti> tkamppeter: do you still have process 5747?
[11:05] <tkamppeter> ps auxwww | grep 5747
[11:05] <tkamppeter> root      5747  0.0  0.1 134944  3100 ?        Ssl  Apr14   0:05 /usr/sbin/NetworkManager --pid-file /var/run/NetworkManager/NetworkManager.pid
[11:05] <tkamppeter> till     14546  0.0  0.0   5164   852 pts/0    R+   12:05   0:00 grep 5747
[11:06] <pitti> tkamppeter: ah, that shuold be unrelated then
[11:06] <pitti> tkamppeter: at which point did you plug in/switch on the scanner?
[11:09] <tkamppeter> pitti, now I have uploaded a file hal2.log to the same place. There is the plugging at or at least near the beginning.
[11:10] <jordi> hey
[11:10] <tkamppeter> pitti, sorry, I will retry
[11:10] <pitti> tkamppeter: but lshal does have the 'scanner' and 'access_control' properties?
[11:10] <pitti> tkamppeter: and info.callouts.add = {'hal-acl-tool --add-device'} ?
[11:11] <pitti> tkamppeter: hal2.log doesn't exist; but maybe post your lshal output first?
[11:13] <jordi> I need some quick advice: my ubuntu derivative is currently using a xubuntu-7.10-alternate CD which adds the necessary packages for my project. our client decided to go with IceWM instead of XFce, and there are some hardware limitations in the project. Now that it's time to migrate to 8.04, should I rebase using a ubuntu or xubuntu CD? iow, are there any significant differences in the alternate CD installers between the two?
[11:14] <Mithrandir> jordi: alternate should be very much the same.  Different package selections, naturally
[11:14] <jordi> I chose xubuntu previously for xfce, but now that I'm not going to use it, I wonder if I should just go with the (better supported?) Ubuntu CD
[11:14] <jordi> Mithrandir: *nod*
[11:14] <jordi> Mithrandir: what about LTS support for xubuntu main packages?
[11:14] <jordi> 5 years as well, for those that  differ from Ubuntu?
[11:14] <pitti> jordi: xubuntu is in universe now
[11:15] <jordi> oh
[11:15] <jordi> see, that's a good reason to go with Ubuntu. :)
[11:15] <jordi> so kubuntu and ubuntu remain in main now?
[11:15] <pitti> yes, and the edubuntu bits
[11:15] <jordi> oh, right
[11:16] <jordi> finally, should I expect changes to the installer from today's daily alternate image to the final thing?
[11:17] <tkamppeter> pitti, I have posted lshal.log now.
[11:17] <Mithrandir> jordi: from experience: yes.  Not big changes, but some changes.
[11:19] <pitti> asac, Riddell: hm, should we install xulrunner and firefox translations into the generic or the ubuntu langpacks? IOW, do we need them in Kubuntu, too?
[11:19] <asac> pitti: interesting point. firefox is not in default kubuntu, not sure about the percentage that actually uses it though
[11:20] <tkamppeter> pitti, hal2.log is uploaded now.
[11:20] <pitti> tkamppeter: ah, that would be it; no access_control capabilities
[11:21] <asac> tkamppeter: you know if HP DJ D1460 works out of the box in ubuntu since feisty?
[11:21] <tkamppeter> pitti, and why does a scanner get this capability and an HP device not?
[11:21] <pitti> tkamppeter: give me a second
[11:21] <tkamppeter> asac, should do, I have other HPs which worked all the time, also inkjets.
[11:22] <tkamppeter> pitti, second is over ...
[11:22] <cjwatson> jordi: there will definitely be some small changes; today's daily build is actually yesterday's, and we made some changes after the build yesterday
[11:22] <jordi> cjwatson: nod
[11:22] <jordi> nothing I can't track during this week I guess
[11:23] <jordi> thanks for the advice
[11:23] <asac> tkamppeter: Works perfectly using hplip 2.7.7 when assigned as a D1300 (from linuxprinting.org) do we have at least that version in feisty?
[11:23] <cjwatson> added warning before deleting contents of partitions, password handling fixes in grub-installer, a couple of other small things
[11:24] <asac> tkamppeter: hmm feisty has 1.7.3?
[11:24] <tkamppeter> asac, do not really know what feisty had. See Launchpad.
[11:25] <asac> tkamppeter: i look at apt-cache show in feisty chroot
[11:25] <asac> yes, launchpad confirms 1.7.3
[11:26] <pitti> tkamppeter: ok, I see the problem, I think; the scanner property is on the usb_device, not on the scanner interface (which is /org/freedesktop/Hal/devices/usb_device_3f0_1c02_CN6B92118304R4_if1)
[11:27] <tkamppeter> pitti, how does hal-acl-tool determine which ACLs to set for which devices? Is there a config file somewhere?
[11:27] <pitti> tkamppeter: it looks for linux.device_file on the parent node, which should be /org/freedesktop/Hal/devices/usb_device_3f0_1c02_CN6B92118304R4
[11:27] <pitti> tkamppeter: yes, it is in /usr/share/hal/fdi/policy/10osvendor/20-acl-management.fdi
[11:28] <pitti> tkamppeter: it almost seems  like hplip attaches the property to info.subsystem = usb_device, not usb?
[11:28] <pitti> tkamppeter: let me grab the hplip package
[11:29] <pitti> tkamppeter: indeed, that's it
[11:29] <pitti> tkamppeter: can you please try to change this in the fdi:
[11:30] <Riddell> pitti: I don't mind about firefox translations, I think I'd prefer not to have them but I can see they'd be useful to others
[11:30] <pitti> tkamppeter: s/usb_device/usb/ in <match key="info.subsystem" and <match key="usb_device.vendor_id" and <match key="usb_device.product_id"
[11:31] <pitti> tkamppeter: try: sudo sed -i sed 's/usb_device/usb/g' /usr/share/hal/fdi/preprobe/10osvendor/20-hplip-devices.fdi
[11:31] <pitti> tkamppeter: erm, drop the second 'sed', of course
[11:34] <jordi> wtf
[11:34] <jordi> Host packages.ubuntu.com not found: 3(NXDOMAIN)
[11:34] <pitti> Riddell: hm; so rather 'no' at this point?
[11:34] <jordi> hm, seems the uni's ns is fubar
[11:34] <Riddell> pitti: that's my preference, but either way is fine
[11:35] <pitti> Riddell: ok, installing them into the ubuntu packages then
[11:35] <pitti> s/ubuntu/gnome/
[11:35] <tkamppeter> pitti, reuploaded lshal.log now, lokks better, but actual permissions did not change.
[11:37] <pitti> tkamppeter: right, lshal looks fine now
[11:37] <pitti> tkamppeter: so xsane still fails now? sane-find-scanner doesn't find anything?
[11:37] <pitti> tkamppeter: can you please do the hal debugging procedure again? (start in debugging mode, switch on scanner, send log)
[11:39] <tkamppeter> pitti, xsane and hp-toolbox work, will try printing now ...
[11:39] <pitti> tkamppeter: didn't you just say the permissions were wrong?
[11:39] <pitti> tkamppeter: it'll still appear as root:lp, but you shouldhave an ACL on it (getfacl /dev/bus/...)
[11:41] <tkamppeter> pitti, I forgot about that the ACLs are separate from the permissions. The ACLs are OK for me and with this non-printing functions work.
[11:41] <pitti> \o/
[11:41] <pitti> tkamppeter: so, want to prepare a new hplip source with s/usb_device/usb/ in the FDI generator?
[11:41] <pitti> tkamppeter: please reopen the bug, and close it again in the changelog
[11:42] <pitti> tkamppeter: would be nice to get this fixed for the release
[11:42] <tkamppeter> pitti, I see now, I have moved away the 55-hpmud.rules UDEV rule file as I have considered it as obsolete. It sets the user "lp" for the /dev file of the printer. seems that I have to put it back in. Is this correct?
[11:43] <pitti> tkamppeter: you need it for getting group lp to the device node, but I don't know whether you need it in the first place
[11:43] <pitti> tkamppeter: you would if the hplip printing backend runs as 'lp' instead of as user
[11:43] <pitti> s/user$/root/
[11:44] <pitti> tkamppeter: if it works with the udev rule, and fails without, then I'd say you need it :)
[11:46] <tkamppeter> pitti, so I will leave the UDEV rule in. If there are sites where it should be desired to scan when sshed in one can also add users to the scanner group then.
[11:46] <asac> bryce: did you upload new xserver already? please comment on bug 186186 about the offscreen pixmap fix so i can finally close the firefox target as well
[11:46] <ubotu> Launchpad bug 186186 in xulrunner-1.9 "web page background render errors" [High,Confirmed] https://launchpad.net/bugs/186186
[11:47] <pitti> tkamppeter: will that actually help?
[11:47] <bryce> asac, it is uploaded
[11:47] <asac> bryce: can you set the bug to fix released for xserver then?
[11:48] <asac> and paste the changelog. thanks
[11:49] <tkamppeter> pitti, with UDEV rule I get lp:root and not lp:scanner, so something else is setting the group to root afterwards.
[11:51] <jordi> cjwatson: btw, do you know who in Debian/Ubuntu would know how to write non-trivial partman-auto-raid recipes? Simon Huggins?
[12:00] <bryce> 'night
[12:02] <cjwatson> jordi: probably; we haven't really touched partman-auto-raid much hereabouts
[12:02] <cjwatson> I might be able to make a stab at it, but I bet Simon would be better
[12:13] <pitti> Riddell: ok, with that little buildd power we don't need to worry about CD builds any time soon
[12:16] <jordi> cjwatson: okay. I'm not looking for something spectacular, I just can't get it working for a raid1 setup on two SATA disks with non-raid swap space and a non-raid ext3 for /srv/backups
[12:16] <jordi> cjwatson: I always get "no root partition defined"
[12:17] <jordi> I'll mail simon, and Cc you to see, debian-boot wasn't too helpful
[12:18] <cjwatson> jordi: please attach the syslog
[12:18] <jordi> cjwatson: ok
[13:02] <james_w> pitti: I'm sorry, but I didn't find a sponsor for bug 153625
[13:02] <ubotu> Launchpad bug 153625 in ca-certificates "update-ca-certificates error. ca-certificates.crt empty (with pt_BR locale)" [High,Fix committed] https://launchpad.net/bugs/153625
[13:08] <Silicium> hi there
[13:08] <Silicium> are there any problems to upgrade from hard beta to stable?
[13:08] <Silicium> i can't wait :D
[13:11] <RussellGee> no, you should be fine
[13:11] <RussellGee> just keep applying updates and you have the final release
[13:11] <Pici> !final
[13:11] <ubotu> If you installed a Alpha/Beta/RC version of Ubuntu 8.04 (Hardy Heron) and have been keeping it up to date, then you are already running the latest version of Hardy. To make sure, type « sudo apt-get update && sudo apt-get dist-upgrade » in a console.
[13:31] <zul> doko: ping nagios-plugins MIR question
[13:34] <doko> zul: ?
[13:34] <zul> doko: couldnt we put nagios-extras-plugins back?
[13:35] <zul> doko: since Im not really sure what to do
[13:36] <doko> zul: sure, but then you would need to build the fping and qstat plugins from this source
[13:37] <zul> doko: gotcha
[13:37] <doko> it's still in hardy/universe
[13:37] <zul> k Ill get that done today
[13:38] <doko> zul: the other possibility would be to build the -extra package from nagios-plugins and keep the binary in universe
[13:39] <zul> doko: ok that would be easier
[13:39] <pitti> hi james_w
[13:40] <pitti> james_w: that's for stables, right? how has testing been gone for the hardy version so far?
[13:42]  * Hobbsee waves
[13:42] <james_w> pitti: There is a proposed update for Hardy there as well.
[13:42] <pitti> james_w: ugh, the hardy task is 'fix released'
[13:42] <pitti> james_w: ah, I see now; darn, nobody was around to upload this last week?
[13:43] <james_w> ah, sorry, I forgot to update the status.
[13:45] <Fujitsu> How do I escape from a situation like the following?
[13:46] <james_w> nobody offered to sponsor, perhaps that's why.
[13:46] <Fujitsu> dpkg: too many errors, stopping
[13:46] <Fujitsu> dpkg: ../../src/packages.c:252: process_queue: Assertion `!queuelen' failed.
[13:46] <Fujitsu> Aborted (core dumped)
[13:49] <pitti> james_w: hardy uploaded
[13:49] <james_w> pitti: thanks.
[14:00] <pitti> mvo: simple-ccsm> there is no bug# in the changelog; is it critical for RC? where has it been ack'ed?
[14:02] <pitti> mvo: (string changes, too)
[14:04] <mvo> pitti: that is universe, I got a FFE from the motu-team
[14:05] <pitti> mvo: ok
[14:06] <pitti> tkamppeter: any luck with an updated hplip?
[14:10] <mvo> pitti: hm, but have a ccsm translation update in the queue too
[14:15] <hubuntu> Where can i see the code to make the Edubntu Add-on CD?
[14:15] <hubuntu> I want to make an Add-On CD but with localized packages, drivers, codecs, etc.. and I do not want to make an ubuntu fork. So using the Edubuntu Add-on CD base should do the trick, right?
[14:16] <hubuntu> and as a side effect we would have an add-on CD framework that do not break or fork ubuntu
[14:18] <Riddell> pitti: is apport going to be on or off in gnome?
[14:18] <pitti> Riddell: we'll switch it off right after RC
[14:19] <pitti> Riddell, seb128: I'm still pondering whether we'll again disable it in adept/update-notifier, or disable apport completely in the default file
[14:19] <pitti> I'll bring that up in Thursday's meeting
[14:19] <seb128> pitti: will disabling apport make it stop hanging the program for several minutes?
[14:19] <cjwatson> hubuntu: http://people.ubuntu.com/~cjwatson/bzr/cdimage/mainline/ and http://people.ubuntu.com/~cjwatson/bzr/debian-cd/ubuntu/
[14:19] <pitti> seb128: yes
[14:19] <cjwatson> hubuntu: checkout with bzr; the best place to start is probably by grepping for CDIMAGE_ADDON
[14:19] <seb128> pitti: ok then disable apport completely
[14:20] <pitti> and we can disable it in one location, which is more obvious to find than a gconf key
[14:20] <seb128> pitti: I've enough to wait for 5 minutes when evolution crashes to be able to start it again and there is likely users annoyed by that too
[14:20] <pitti> yeah; and devs can still re-enable it if they want
[14:20] <pitti> seb128: that was my feeling, too
[14:20] <pitti> Riddell: what's your opinion on that?
[14:21] <Riddell> what seb128 said
[14:21] <seb128> (not that evolution crashes often nowadays but that's an example)
[14:22] <pitti> seems we alredy have a consensus then :)
[14:24] <hubuntu> thanks cjwatson I'll see what i get out of it ;)
[14:26] <mpt> Oh, so *that*'s the reason I never got an explanation when program's crashed in 7.10?
[14:26] <mpt> programs, rather
[14:26] <mpt> because I was using a final release?
[14:27] <\sh> seb128, evolution crashes always, when using evolution as exchange replacement in a company with a crappy mail environment
[14:27] <\sh> tbh, not evolution, but the backend part of it
[14:28] <\sh> seb128, regarding imap and pop3 you are right...
[14:28] <seb128> \sh: the exchange connector might crash, I've no idea about that
[14:30] <\sh> seb128, it's hard to debug....there are problems while sending (e.g. attachments with more then 100k are likely to work in the first try...restarting evolution helps) and sometimes the calendar <-> evolution sync backend is crashing...whysoever...
[14:34] <emgent> heya people
[14:45] <afflux> sorry, dumb question: linux-restricted-modules installs some .mod.o files (fglrx, nvidia, ath_hal...). How are they supposed to get loaded into the kernel? I've for example /lib/modules/2.6.24-15-generic/volatile/nvidia.ko on my system, but it has no package and I wonder where it comes from.
[14:46] <afflux> err, maybe this is rather something for #ubuntu. I'll ask there
[14:47] <Amaranth> afflux: lrm-manager
[14:49] <afflux> Amaranth: ah, that was the trick. Thanks a lot!
[15:00] <dholbach> TheMuso: can you take a look at http://paste.ubuntu.com/7121 and tell the archive admins if you like it? (I'm asking you, because Alberto fixed the apt/sources.list thing in envyng in a different way and some other bugs along with it)
[15:01] <TheMuso> dholbach: ok
[15:03] <Kopfgeldjaeger> are there any plans to include disc encryption in ubiquity for 8.10?
[15:05] <TheMuso> dholbach: Looks fine to me. Is there a bug open about this?
[15:07] <cjwatson> Kopfgeldjaeger: it's on my list, although I am conscious that it's not a straightforward job so could slip despite the best-laid plans
[15:17] <munckfish> Hi guys, xorg question - Am I correct in presuming the 'vesa' driver should not be available for the powerpc build?
[15:17] <munckfish> I'm investigating LP 217647, and I noticed in the x log that it's trying to load the vesa and failing
[15:17] <ubotu> Launchpad bug 217647 in xorg-server "Crash at startup on PS3 (hardy)" [Undecided,New] https://launchpad.net/bugs/217647
[15:18] <cjwatson> vesa is usually a property of the graphics card, not the CPU architecture
[15:18] <cjwatson> (well, ish ...)
[15:20] <carlos> pitti: hi, I have a question for you about latest language pack for Hardy before release
[15:21] <pitti> carlos: sure, shoot
[15:22] <carlos> pitti: When will you do that final upload?
[15:23] <pitti> carlos: I requested a full export, so we should get that Wednesday night, right?
[15:23] <pitti> carlos: I'll build the new packages on Thursday, and have them accepted right after the RC
[15:23] <carlos> right, so the plan is to upload that as the final one
[15:23] <pitti> right
[15:23] <carlos> ok
[15:24] <carlos> pitti: hmm, we should handle LanguagePackTranslationDeadline better for next release...
[15:24] <cjwatson> munckfish: but in any case it's supposed to default to fbdev on powerpc; that may not necessarily prevent it probing vesa, but at the same time that may not be what's actually failing
[15:24] <carlos> pitti: it's supposed to be on Thursday, instead of today
[15:25] <pitti> carlos: hm, I interpret that as "final packages must be ready by then"
[15:25] <munckfish> cjwatson: ok thx for the info
[15:25] <carlos> pitti: as a translator, I interpret it as, the last day to do translations that will be included in the final release
[15:25] <pitti> carlos: I'd like to keep the possibility of yet another upload/rebuild before the release
[15:25] <carlos> maybe we just need some clarification for next release
[15:25] <pitti> in case something gets horribly wrong
[15:25] <cjwatson> munckfish: that backtrace rather looks like memory corruption
[15:26] <carlos> pitti: I'm not asking you to delay it
[15:26] <pitti> carlos: right, we should document that better
[15:26] <carlos> pitti: but to take care of it in Ibex :-D
[15:27] <zul> pitti: hi http://pastebin.ca/986056 (this is for the nagios-plugin reports) I ripped out fping and qstat out of nagios-plugin-standard and put it in nagios-plugin-extra which we can keep in universe
[15:28] <munckfish> cjwatson: oh oh really? I see
[15:29] <cjwatson> munckfish: the sort of thing that happens if you overflow a buffer and trample on malloc's internal structures, say
[15:29] <cjwatson> unfortunately, those failures aren't usually very local
[15:32] <MacSlow> due to https://bugs.launchpad.net/ubuntu/+bug/215833 I'm forced to boot my laptop with 2.6.24-15 in order to try updating to 2.6.24-16.22... but with 2.6.24-15 I cannot get wifi to work anymore
[15:32] <ubotu> Launchpad bug 215833 in linux-ubuntu-modules-2.6.24 "system won't boot after kernel 2.6.24-16-generic update" [Undecided,Fix released]
[15:33] <pitti> zul: ah, I see; did you change the seeds for -plugins -> -plugins-standard?
[15:33] <MacSlow> I tried to compile it (linux-ubuntu-modules-2.6.24-16.22) on another box but there it fails to compile
[15:33] <zul> pitti: no I havent
[15:33] <pitti> zul: the -plugins depends: plugins-extras will require that
[15:34] <pitti> zul: or, drop it to a suggests, as you see fit
[15:34] <munckfish> cjwatson: so I've no experience with these sorts of things yet. Am I likely to nail it with the normal X debugging stuff as doc'd on the wiki? Or is something like valgrind needed?
[15:34] <zul> pitti: ok
[15:34] <pitti> zul: the maintainer scripts are copy&paste from the existing ones?
[15:34] <zul> pitti: yes
[15:34] <MacSlow> is there a way to just grab a .deb from the repository-server?
[15:34] <pitti> zul: diff looks good to me, modulo above issue
[15:35] <zul> pitti: thanks...
[15:35] <pitti> MacSlow: from archive.ubuntu.com? sure, firefox, browse to it, and click on it, gdebi will take care of it
[15:36] <cjwatson> munckfish: valgrind may help if you can get it to work on the X server; I did a visual inspection but didn't see anything obvious
[15:36] <cjwatson> munckfish: talk with bryce once he's up
[15:37] <cjwatson> munckfish: could you attach /etc/X11/xorg.conf too?
[15:39] <munckfish> cjwatson: umm I could but I probably won't be able to get it till tomorrow
[15:40] <munckfish> I should have grabbed that too bother!
[15:40] <TheMuso> mvo: You're not planning any final tweaks to compiz between now and final are you? If so, we may want to conider freedesktop bug  12292
[15:40] <ubotu> Freedesktop bug 12292 in App/compiz "No accessibility events issued by gtk-window-decorator when Alt+Tabbing" [Normal,Resolved: fixed] http://bugzilla.freedesktop.org/show_bug.cgi?id=12292
[15:41] <StevenK> There's an Ubuntu bug about that too
[15:41] <TheMuso> StevenK: I know.
[15:42] <TheMuso> StevenK: I have been contacted about trying to get it in for hardy.
[15:42] <mvo> TheMuso: we discussed this in #compiz-fusion-dev, the fix seems to be not complete, but its a great start, I think I need to commit one or two small tweak for compiz for RC
[15:43] <TheMuso> mvo: Oh ok.
[15:44] <munckfish> cjwatson: what tz is bryce in?
[15:44] <mvo> TheMuso: but my information is already ~4h old, its quite likely that the remaining bits are fixed now too, I will check. the initial patch was small and obvious enough to include it IMO
[15:44] <cjwatson> munckfish: US/Pacific
[15:45] <munckfish> ok i c
[15:45] <munckfish> I may prepare a mail to the ubuntu-x list, I won't be able to work in this tonight
[15:45] <TheMuso> mvo: Ok, thanks a lot.
[15:45] <munckfish> thx for your help again
[15:51] <cjwatson> munckfish: it looks like it ought to be soluble, but this is just an instinct thing
[15:51] <cjwatson> I mean, soluble without anything very difficult - because it's so early in the startup process and the crash is in ordinary library functions
[15:54] <cjwatson> munckfish: it also seems possible that if all else fails it might be soluble with explicit configuration just for ps3, since it's in the autoconfiguration code
[15:54] <munckfish> cjwatson: yes this is one thing I wanted to try tomorrow morning
[15:54] <munckfish> I want to grab the xorg.conf from the gutsy install
[15:54] <munckfish> and bung it over the auto-gen'd one
[15:54] <munckfish> see if that solves it
[15:54] <cjwatson> it would certainly explain the regression from gutsy to hardy; I expect it will, though you may have to tweak a bit
[15:55] <munckfish> cjwatson: if this was the case, how would be get PS3 specific xorg.conf to happen in the install process?
[15:55] <cjwatson> setting DISCOVERED_VIDEO="fbdev" somewhere appropriate in xserver-xorg.postinst if the current machine is a PS3 would be sufficient
[15:55] <munckfish> e.g. what packages would need to be updated to carry that extra knowledge (I don't know the installer system very well at all)
[15:56] <cjwatson> it's all in X; xorg is the source package in question, xserver-xorg is the binary package
[15:56] <cjwatson> we like delegating this sort of thing to packages rather than trying to encode all the knowledge in the installer
[15:56] <munckfish> ok xorg like our glue package isn't it?
[15:57] <cjwatson> right
[15:57] <munckfish> ok, how long are we looking at for this now btw? e.g. RC build is 17th
[15:58] <munckfish> is that our cut-off?
[15:58] <cjwatson> can't really do it before RC now, but if you have a tested fix ready for right after RC then it should be possible
[15:58] <cjwatson> the RC builds have to be ready well before it actually releases, for testing
[16:03] <munckfish> ok
[16:23] <Mirv> mvo: would you now happen to have time to upload the bug #216211, it has ack in the bug report now from the motu release
[16:23] <ubotu> Launchpad bug 216211 in compizconfig-settings-manager "ccsm Finnish translation broken again" [Undecided,New] https://launchpad.net/bugs/216211
[16:24] <seb128> pitti: is bug #215948 something which needs an exception? cheese is a GNOME package and not on the CD, would be nice to have but if it's not updated that's alright too
[16:24] <ubotu> Launchpad bug 215948 in cheese "Update cheese to 2.22.1 (include hildon patch)" [Undecided,In progress] https://launchpad.net/bugs/215948
[16:24] <pitti> seb128: it's part of gnome, so I'd say it's just subject to the general RC freeze
[16:25] <seb128> pitti: which means upload and wait?
[16:25] <pitti> yeah, please go ahead
[16:25] <seb128> pitti: it's not on the CD so should not be too much trouble
[16:25] <seb128> pitti: ok, thanks
[16:27] <mvo> Mirv: thanks, doing that now
[16:29] <Mirv> mvo: thanks.
[16:59] <kees> slangasek: can you let refpolicy 0.0.20071214-0ubuntu3 into universe?  This will let SELinux folks have a more useable RC experience.  :)
[17:00] <emgent> heya kees :)
[17:00] <kees> hi emgent
[17:01] <mvo> Mirv: uploaded
[17:03] <asac> bryce: i am not sure what your patch did, but it definitly didn't turn off offscreen pixmaps
[17:03] <asac> maybe you forgot to port it for 1.4?
[17:04] <asac> bryce: i 1.4 the setting is negated: XaaNoOffscreenPixmaps ... vs XaaOffscreenPixmaps in 1.5 (fedora)
[17:05] <asac> bryce: i have: ii  xserver-xorg-core                       2:1.4.1~git20080131-1ubuntu8
[17:16] <tkamppeter> pitti, I have made a new HPLIP package with the fdi file updated. see bug 195782
[17:16] <ubotu> Launchpad bug 195782 in hplip "Users not automatically added to "scanner" group: No scanning functions of HP multi-function in Hardy" [High,In progress] https://launchpad.net/bugs/195782
[17:20] <pitti> tkamppeter: ah, did you test it with a full package build/install/scanner test?
[17:20] <pitti> tkamppeter: thanks, I'll get to it
[17:21] <pitti> tkamppeter: how did you end up with "hplip-dbg_2.8.2-0ubuntu8_source.changes"? it should be "hplip_..."
[17:22] <tkamppeter> pitti, I simply copied the wrong line to get the name. The file is the correct one, I should better find a way to auto-generate the name, otherwise I produce simply white noise. The content is correct.
[17:24] <asac> bryce: you forgot to enable it in series :)
[17:24] <asac> i am doing a test build and will upload
[17:26] <tkamppeter> pitti, file name is corrected now.
[17:26] <pitti> tkamppeter: "way to auto-generate" -> what do you use, debuild -S and dpkg-buildpackage -S automatically create the source.changes?
[17:27] <ion_> asac/bryce: Confirmed, the bug with firefox and scaled images still exists.
[17:27] <asac> ion_: the patch is not applied :)
[17:27] <asac> currently fixing that
[17:27] <ion_> :-)
[17:28] <pitti> tkamppeter: accepted, thanks
[17:28] <asac> ion_: takes a bit :) ... doing a test build to be sure ;)
[17:29] <tkamppeter> pitti, I do "dpkg-buildpackage -rfakeroot" to generate source and binary packages. Then I install the binaries to see whether they install and work. The only missing file after that is the _source.changes. I use "dpkg-genchanges -S" to generate it, only this command generates it on stdout and not in a file.
[17:30] <pitti> tkamppeter: oh, I see; IMHO "debuild -S" and then "debuild -us -uc -b" is a bit easier, but your's works, too (although it's pretty unusual)
[17:30] <asac> tkamppeter: its handy to first run -S ... and then -b :)
[17:30] <asac> that will give you the chance to trash all and unpack the clean .dsc again
[17:30] <cjwatson> I often do debuild -S, unpack in temporary directory, debuild -b
[17:31] <munckfish> cjwatson: are you on the ubuntu-x list? do you want me to CC you in my mail there?
[17:31] <tkamppeter> pitti, HPLIP now appears as in "waiting for approval" state. Are you a distro manager to approve it? If not, is additional info needed to add to the bug report?
[17:31] <cjwatson> munckfish: I suggest CCing ubuntu-cell
[17:31] <cjwatson> I'm not on ubuntu-x
[17:31] <munckfish> ok cool
[17:32] <Hobbsee> tkamppeter: it's already picked up
[17:32] <Hobbsee> assuming teh queuebot doesn't lie, anyway
[17:32] <tkamppeter> Thanks, pitti and Hobbsee
[17:32] <pitti> tkamppeter: as I said, I just accepted it; it's already building
[17:33] <Hobbsee> y/w
[17:33] <pitti> yay for new soyuz insta-build-record creation \o/
[17:33] <cjwatson> pitti: particularly since the publisher is down :)
[17:33] <pitti> cjwatson: but that would affect build-from-done (instead of published archive), right? or what do you mean?
[17:34] <cjwatson> pitti: I mean that it's particularly good that it's fixed since we don't have to wait for the publisher ...
[17:34] <pitti> cjwatson: right; what I meant is, now we do not even need to wait for this horribly slow buildd queue-builder
[17:35] <tkamppeter> pitti, bug 217787. Seems that /lib/security/pam_smbpass.so got taken from the distro lately.
[17:35] <ubotu> Launchpad bug 217787 in cupsys "cups crashes when using web-gui and refuses to print" [Undecided,New] https://launchpad.net/bugs/217787
[17:35] <cjwatson> pitti: I hope it's not just because the publisher is down ...?
[17:36] <cjwatson> as in, it's not going to slow back down again once I restart it?
[17:36] <tkamppeter> pitti, "Accepted" notification for HPLIP has arrived.
[17:37] <pitti> cjwatson: when I praised the soyuz guys for it, they didn't seem surprised, so I hope it'll stay that way :)
[17:37] <cjwatson> tkamppeter: pam_smbpass.so was only recently added in the default stack, but the error should be cosmetic
[17:37] <pitti> (this was one of my pet nags for soyuz, and I complained very often)
[17:37] <cjwatson> tkamppeter: I doubt it's actually the cause of that bug - it's just some log messages that people noticed at around the same time!
[17:37] <asac> bryce: ok attached all the pieces that will go up to bug 182038
[17:37] <ubotu> Launchpad bug 182038 in xorg-server "Black rectangle instead of image in FF3 [Hardy]" [Medium,Fix committed] https://launchpad.net/bugs/182038
[17:38] <kees> cjwatson, pitti: can one of you release refpolicy (universe)?
[17:38] <pitti> hey kees
[17:38] <kees> heya pitti :)
[17:38] <pitti> I had a look at it earlier, but it looked very intrusive; let me look again
[17:39] <pitti> kees: right, most of the changes don't even have bug refs, so I couldn't check approval status
[17:39] <pitti> and the patch -- description ordering in the changlog is ... confusing
[17:40] <kees> pitti: hrm, true, it's cosmetic though.  only selinux would be affected by that upload, and is currently not installable without it.
[17:41] <pitti> kees: not installable? how come? it's just patches, no dependency changes etc?
[17:41] <kees> pitti: right, I don't mean packaging-uninstallable, but rather one cannot get SELinux up and running.
[17:42] <pitti> kees: you can vouch that the new version doesn't aggravate it?
[17:42] <kees> pitti: upstream vouches, but if you want me to test it as well, I can do that first.
[17:56] <seb128> pitti: can you reject the libgweather upload I just did?
[17:56] <pitti> seb128: not in queue yet
[17:57] <seb128> ok
[17:57] <pitti> seb128: also, you can just reject it yourself if you want
[17:57]  * pitti waits another 3 minutes, when it should appear
[17:57] <seb128> pitti: ok, that was a "don't accept it" rather ;-)
[17:57] <pitti> :)
[17:57] <seb128> pitti: in case you were quicker
[17:59] <max_> I LOVE UBUNTU :)
[18:00] <pitti> max_: :)
[18:00] <pitti> seb128: kicked
[18:00] <seb128> pitti: thanks
[18:00] <seb128> I'll reupload after diner a fixed version
[18:00] <seb128> I've to go now
[18:19] <zeld> hi to all : )
[18:20] <zeld> i've read about genbuntoo...
[18:20] <zeld> : )
[18:21] <zeld> what about the project at the moment?
[18:24] <laga> ask the author?
[18:24] <Pici> zeld: https://wiki.ubuntu.com/GenBunToo - As you can see, its not an Official Ubuntu derivative.
[18:25] <jdong> we have nothign to do with the project
[18:25] <laga> you can also install portage and emerge on ubuntu. i guess. probably nobody has tried it, but it should be possible ;)
[18:26] <jdong> it's not, by any means, a ground breaking concept
[18:26] <jdong> IMO the authors need to read up on apt-build
[18:26] <jdong> which ALREADY does what this set of primitive pseudo broken "shell scripts" does.
[18:26] <zeld> ok thanks guys : )
[18:26] <zeld> but i want only ubuntu with precompiled package : D
[18:27] <zeld> only for information...
[18:27] <zeld> in front of portage i prefere pkgsrc : )
[18:27] <jdong> well what's clear is anyone who uses this methodology is on their own in terms of bug reports.
[18:28] <laga> i dont think "optimization" will benefit many people
[18:28] <jdong> laga: agreed
[18:28] <jdong> maybe 1-2% speed up at most in 99% of scenarios
[18:28] <zeld> jdong:  u think?
[18:28] <jdong> most of the things that benefit from compiler-flag optimization already do so in their build scripts
[18:28] <jdong> zeld: yes.
[18:28] <zeld> but i386 is obsolete...
[18:28] <zeld> : S
[18:29] <jdong> zeld: do you want to list exactly what -march=nocona does over -march=generic?
[18:29] <zeld> jdong: i know the arch and the list : D
[18:29] <jdong> zeld: rough answer is not much. tiny microoptimizations that can either reduce or improve performance
[18:29]  * laga debuilds vim with -O99
[18:29] <zeld> many cpu are based and compatibly with 386
[18:30] <ion_> One kind of optimization that would be beneficial would be somehow measuring the branches programs typically choose and take that into consideration when compiling. But i don't know a generic way to implement that.
[18:30] <zeld> laga: LOL!
[18:30] <jdong> zeld: on x86 based architectures compile-time instruction set optimizing is not helpful.
[18:30] <laga> zeld: then use amd64, most cpus are compatible and these builds are often more optimized
[18:30] <jdong> ion_: kind of done already
[18:30] <jdong> ion_: firefox supports building with PGO
[18:30] <jdong> ion_: which essentially runs that spidermonkey test suite while profiling the browser, and rebuilds according to that data
[18:30] <zeld> : )
[18:31] <zeld> understod jdong laga  : )
[18:31] <jdong> ion_: I've heard that it could increase performance 7-fold on some routines compared to our existing firefox
[18:31] <jdong> zeld: my point is optimization is not just blindly sticking three options to GCC
[18:31] <jdong> zeld: I was a Gentoo user for far longer than I'm an Ubuntu user/developer
[18:31] <jdong> zeld: and even back then I failed to notice much if any difference between various compiler-time flags
[18:32] <ion_> jdong: Yes, that's a way to do it, but it's not a generic way. Every program would then need to have a test suite and have it run with profiling on during the build process.
[18:32] <jdong> ion_: how much more generic could one make it though?
[18:32] <jdong> ion_: a test suite could be as easy as scripting firefox to load some website, mencoder to encode a test video, etc
[18:35] <ion_> jdong: Have a repository section with packages built with profiling on and a cron job that posts the results to an Ubuntu server, have the server average the results and then rebuild packages based on them to the normal sections, tell people to use the profiling sections while informing them of the implications? :-P
[18:35] <\sh> if someone from ubuntu-release is so kind and review bug #211326 and think about upgrading rsync ...:)
[18:35] <ubotu> Launchpad bug 211326 in rsync "[Freeze Exception] Please update rsync to 3.0.x for hardy" [Wishlist,New] https://launchpad.net/bugs/211326
[18:35] <jdong> ion_: haha
[18:35] <jdong> ion_: interesting idea
[18:43] <davmor2> help! please.  I have to keep rebooting to burn test cd's.  It's only happened over the last few days.  If I leave the dvd-rw for any length of time it becomes unusable until I reboot then it works fine until I leave it again.
[18:46] <zeld> bye peopple : )
[18:47] <slangasek> kees: refpolicy> please get approval from motu-release
[18:47] <kees> slangasek: okay
[18:49] <psyke83> hi, I'd like to bring bug #192888 to everyone's attention (the problem where firefox crashes sporadically due to flash). I found a workaround that we could have ready for Hardy's release. See my comments there
[18:49] <ubotu> Launchpad bug 192888 in pulseaudio "firefox crashes on flash contents" [Undecided,Confirmed] https://launchpad.net/bugs/192888
[18:50] <psyke83> basically, I found out that Fedora 9 (i386 version) comes preinstalled with pulse, libflashsupport *and* nspluginwrapper). It seems that having flash isolated in the npviewer.bin process prevents firefox from crashing
[18:50] <psyke83> I manually compiled nspluginwrapper for i386, installed the wrapper plugin and flash, and firefox doesn't crash anymore in Hardy
[18:53] <mario_limonciell> er doko_, it looks like you messed up on the color prompt stuff in bash?  your variable to be uncommented is force_colored_prompt, where as later in the bashrc you check for force_color_prompt
[18:54] <mario_limonciell> i
[18:54] <mario_limonciell> ll file a bug :)
[18:55] <\sh> psyke83, please add your observations to the bug, pls :)
[18:55] <psyke83> \sh, I already did, but I thought that I'd ping everyone in here in case I grab someone's attention that isn't subscribed
[18:56] <psyke83> my findings are in the last two entries (my name there is Conn)
[18:56] <\sh> psyke83, asac is the man for that problem actually...and yes, we saw the crash on i386 without the wrapper but not on amd64 where we need the wrapper
[18:57] <psyke83> \sh, right
[18:57] <ion_> Yeah, getting rid of the flash crashes would be nice indeed. :-)
[18:58] <psyke83> \sh, flash seems to continue crashing at times (the pulseaudio developers realized that the problem is in the flash plugin), but using the wrapper means that the firefox process will never crash - you just get a grey box and an error dialog, and reloading the page fixes the problem
[18:58] <\sh> ion_, getting rid of a closed source, crashing flash would be nice, yes :)
[18:58] <psyke83> this behaviour is the same as in Fedora 9 (with flash sometimes turning grey; I presume it is crashing)
[18:59] <\sh> psyke83, actually the crash come later...on amd64 I'll have the crash after I closed firefox actually...
[19:00] <psyke83> \sh, damn :(
[19:00] <\sh> psyke83, and ubuntus crash dialog tells me, it's pluginwrapper which is crashing
[19:00] <psyke83> I didn't notice firefox crashing yet, but I'll continue testing... nevertheless, it seems better to use the wrapper if it offers some protection against the entire firefox process segfaulting
[19:00] <\sh> not flash actually..but I think it's the trigger for this
[19:00] <psyke83> \sh, this is the real problem: http://www.pulseaudio.org/ticket/267
[19:01] <psyke83> it just so happens that nspluginwrapper lets us recover from flash (and the wrapper) crashing
[19:01] <psyke83> ...and if the bug is in flash, we can't really solve it directly.. damn closed source :P
[19:01] <\sh> psyke83, right :)
[19:01] <\sh> psyke83, no...damn adobe to add some different behaviour to the sec fixed flash player...
[19:02] <\sh> psyke83, which is not even documented, at least not on the adobe web page...
[19:02] <saivann> Some people reported that they had wrong Swap partition UUID in /etc/initramfs-tools/conf.d/resume in bug 205990, can someone take a look at this? Looks that it might be a side effect of replacing volumeid by uuid-runtime that might cause upgrade issues between gutsy and hardy
[19:02] <ubotu> Launchpad bug 205990 in usplash "[hardy] splash screen disappears after a few seconds" [Medium,Triaged] https://launchpad.net/bugs/205990
[19:02] <psyke83> \sh, I downgraded flash and it still seemed to crash, IIRC
[19:03] <psyke83> should I add the flash bug to track nspluginwrapper so the maintainer can consider creating an i386 build, or should I leave it, do you think?
[19:06] <\sh> psyke83, well, actually the .115 never crashed for me on i386
[19:06] <psyke83> \sh, with libflashsupport enabled?
[19:07] <\sh> psyke83, no just leave it to flashplugin-nonfree, I think the decision will be a critical one regarding the time of release
[19:09] <\sh> psyke83, really, I don't want to make this decision...because listening to ogra and his ltsp stuff, it works somehow...regarding i386 user, they are freaked away because of this, and amd64 users are happy
[19:10] <cjwatson> saivann: volumeid wasn't replaced by uuid-runtime
[19:11] <cjwatson> saivann: worth checking whether multiple Linux installations were involved
[19:11] <saivann> cjwatson : when updating initramfs-tools, volumeid is uninstalled and uuid-runtime is installed
[19:12] <psyke83> \sh, I can imagine it's a tough call, since a) there will be many unhappy users due to firefox constantly crashing, b) we can't tell when Adobe will fix this issue (or if they will at all) and c) using nspluginwrapper on i386 will require lots of changes for plugin detection etc, unless you use it exclusively for flash, and handle it in the flashplugin-nonfree package's scripts
[19:12] <cjwatson> saivann: sure, but you've drawn the wrong conclusion :)
[19:12] <saivann> cjwatson : Ha, sorry :)
[19:12] <cjwatson> saivann: volumeid was merged back into udev, and the uuidgen program was split out of e2fsprogs into uuid-runtime
[19:12] <psyke83> I think a decision should be made soon though, for or against
[19:12] <saivann> cjwatson : I just looked at the changelog.. yes
[19:13] <cjwatson> anyway, this doesn't really help you with the bug as such, just wanted to clarify that
[19:13] <saivann> cjwatson : You believe that having multiple linux system on the same computer using the same swap partition might cause the UUID to change?
[19:13] <cjwatson> there have been bugs in that sort of general area
[19:13] <cjwatson> we've never tracked them down for certain
[19:14] <saivann> at least if having wrong values in /etc/initramfs-tools/conf.d/resume can't have a real negative impact..
[19:14] <cjwatson> it would be interesting to know if any non-Ubuntu Linux systems are involved (though may not be)
[19:15] <saivann> cjwatson : I asked the question in the bug report
[19:15] <saivann> thanks
[19:17] <\sh> psyke83, well, it's 9 days before release...I hope that everyone is sane enough to not introduce another serious regression...if the bug is known, and we can document a workaround or push a fixed flashplugin later into hardy...I would say: stay with it..but that's me...I have to work with flash all day long in my company :)
[19:18] <cjwatson> saivann: I don't see how this can possibly be related to the usplash crash Scott diagnosed earlier in that bug report. Are you sure that you aren't helping to make the bug report more confusing by conflating several different issues? People with different issues from the original reporter should be directed to file a new bug.
[19:19] <stgraber> pitti: any idea about bug 217815
[19:19] <ubotu> Launchpad bug 217815 in debian-installer "When selecting LVM Crypt, erase never ends" [Undecided,New] https://launchpad.net/bugs/217815
[19:19] <cjwatson> I just commented on that ...
[19:19] <\sh> psyke83, actually I know now what's not working and I can do something against it: 1. installing amd64 on 64bit dual core machine, or stay with the crash on i386 :)
[19:19] <stgraber> pitti: I don't usually wait for the erase disk step to complete so haven't experienced it myself but it has been reported twice already (two different reporters)
[19:19] <saivann> cjwatson : I'm also suprised but this has been confirmed by three persons + people from the ubuntuforum. Don't forget that it happens when "Reading files needed to boot"
[19:20] <cjwatson> saivann: it is *not related* to the usplash segfault. It is a different problem that may happen to have the same symptoms.
[19:21] <cjwatson> it's entirely possible for different bugs to have the same symptoms - if they all end up piled into the same bug report then the bug report ends up impossible to deal with
[19:21] <psyke83> \sh, heh... and the common opinion held is that Ubuntu x86_64 is less stable than x86... how ironic that it's now more stable because of propitiatory software, heh
[19:21] <pitti> stgraber: so cancelling works?
[19:21] <kees> cjwatson: which bug is the usplash crash?
[19:21] <cjwatson> kees: 205990
[19:21] <pitti> stgraber: hm, last time I tried that, it finished successfully, but that's some weeks ago already
 "usplash segfault in bogl_tcfb_put" and attach the trace
 it looks to me like it's gone out of the bounds of the framebuffer
[19:21] <psyke83> *proprietary
[19:21] <saivann> cjwatson : So I might have complicated things.
[19:21] <stgraber> pitti: cancelling works for me (just finished my alternate i386 lvm-encrypted test)
[19:22] <cjwatson> of course it's hard to tell that *that's* the same issue as the original reporter, too
[19:22] <cjwatson> the original reporter said "
[19:22] <cjwatson> the original reporter said "I have tried without quiet and splash options and I don't see any segfault ...
[19:22] <cjwatson> "
[19:22] <\sh> psyke83, well, that I can't underline, I'm working at home on amd64 only...and I have to say, it's at least stable for me to do my daily tasks...which is compiling, using openoffice and playing nexuiz ;)
[19:22] <cjwatson> but, at any rate, there are at least two different problems in that bug, and many different users
[19:23] <psyke83> \sh, heh. I can't comment, as I've never owned a 64bit system :(
[19:23] <stgraber> pitti: I'm doing another testcase now (LTSP) but will install on encrypted LVM and will wait this time instead of immediatly canceling it
[19:23] <pitti> stgraber: thanks; maybe do it on a small HD in VMWare :) (that's what I usually do)
[19:25] <stgraber> pitti: the HDD in this computer is 10GB large, that shouldn't take very long
[19:26] <saivann> cjwatson : Mmh.. the initial reporter dmesg file does not contain any segfault, only the w00t one. It seems clear that there is two bugs here.. as you just noticed
[19:27] <cjwatson> saivann: ok, if that's the case then the segfault people need to be redirected :)
[19:27] <cjwatson> either way ...
[19:27] <cjwatson> I'm not sure that a usplash segfault would show up in dmesg, mind you
[19:27] <cjwatson> after all it's just an ordinary userspace application - why would it show up in the kernel ring buffer?
[19:28] <jdong> cjwatson: on x86-64 segfaults show up in dmesg
[19:29] <jdong> [243994.160735] tomboy[18006]: segfault at b5d7fb40 eip b5d7fb40 esp bfa2e53c error 4
[19:29] <jdong> not just x86 actually
[19:29] <jdong> it's happening on 32-bit in Hardy too
[19:29] <jdong> that's new, but x86-64 has done it for a while
[19:30] <stgraber> cjwatson, pitti: about bug 217815 couldn't it be that the eraser is lacking of random values to write on the disk and is waiting for input device activity to generate real random values ?
[19:30] <ubotu> Launchpad bug 217815 in debian-installer "When selecting LVM Crypt, erase never ends" [Undecided,New] https://launchpad.net/bugs/217815
[19:30] <saivann> cjwatson : the segfault appears for woot, but not other users that posted their dmesg
[19:30] <pitti> stgraber: it sounds unlikely to me, since /dev/random would be empty *very* fast, and urandom isn't supposed to be blocking
[19:31] <pitti> stgraber: but of course anything is possible, IANAKD
[19:31] <cjwatson> jdong: is that true for all possible kernel paths that could raise SIGSEGV? It seems to be just in the page fault code
[19:32] <stgraber> ok, the "moving the mouse in the guest" part made me remember of GPG and some other encryption tools like that
[19:32] <pitti> stgraber: but that would be a funny situation: urandom being blocked on disk I/O to get entropy, disk I/O being blocked on urandom for delivering more data :)
[19:32] <stgraber> pitti: indeed :)
[19:32] <jdong> cjwatson: that might be true. Killing arbitrary processes with SEGV doesn't do it
[19:32]  * jdong might be confusing the pagefault mechanism with grsec's signal audit framework
[19:33] <cjwatson> stgraber: as far as I can see, partman-crypto doesn't use random data, it uses zeroes
[19:33] <cjwatson> (for the erase)
[19:34] <cjwatson> stgraber: so, no, I don't think that is possible
[19:35] <cjwatson> stgraber: did you reproduce it in kvm, or elsewhere?
[19:35] <stgraber> I'm trying to reproduce on real HW
[19:35] <cjwatson> Apr 15 16:27:37 main-menu[3032]: (process:14634): [:
[19:35] <cjwatson> Apr 15 16:27:37 main-menu[3032]: (process:14634): /: unknown operand
[19:35] <cjwatson> hmm, what's that about
[19:36] <cjwatson> joy, *somewhere* in partman
[19:36] <stgraber> cjwatson: http://iso.qa.ubuntu.com/qatracker/result/1453/195
[19:36] <stgraber> this one is on real HW
[19:36] <cjwatson> very odd
[19:37] <saivann> cjwatson : Well do you still believe that I should ask the people that gets a backtrace to open a new bug report?
[19:37] <saivann> cjwatson : s/backtrace/segfault/
[19:37] <cjwatson> saivann: yes please
[19:38] <saivann> cjwatson : Ok thanks for your guidance
[19:38] <cjwatson> stgraber: oh, I suppose it could be that it's writing zeroes to the encrypted device and access to the encrypted device is blocking due to lack of randomness. or something
[19:40] <cjwatson> we do seem to set up dm-crypt using /dev/urandom though
[19:40] <cjwatson> unless cryptsetup is using /dev/random somewhere else
[19:42] <stgraber> cjwatson: reproduced in KVM
[19:43] <stgraber> cjwatson: I created a VM without network access, 128MB of RAM and with a 1GB HDD. It first got stuck at 8%, then at 33% and finally found enough entropy to complete
[19:44] <stgraber> for both 8% and 33% moving mouse or any other kind of activity seems to make it continue
[19:45] <stgraber> erase disk worked correctly on real HW (never got stuck)
[19:46] <cjwatson> I reassigned the bug to partman-crypto, but I don't think it really belongs there
[19:46] <seb128> pitti, slangasek: I've just uploaded a libgweather update, would be nice to get for hardy, is it late to get it accepted now?
[19:46] <cjwatson> does /dev/urandom exist, out of interest?
[19:46] <stgraber> it does
[19:51] <mo__> i have ha problem, any kernel above 2.6.24-12 freezes while booting at "loading device drivers" . INFO: AMD Phenom/Ubuntu 8.04 Beta
[19:52] <amitk> mo__: upgrade your kernel, it was fixed
[19:52] <kirkland> anyone know of a website that hosts Ubuntu Manpages?  Something similar to manpages.debian.net, or linuxmanpages.com, but Ubuntu-specific manpages?
[19:53] <mo__> amitk, i did upgrade it today, still the same
[19:54] <stgraber> Just tried once again with kvm and a "standard" VM (kvm -hda test.img -cdrom blah.iso), if you don't leave the VM and don't press any key or move your mouse it'll freeze after only a few %
[19:54] <cjwatson> kirkland: I've never heard of one
[19:54] <amitk> mo__: are you running -16?
[19:55] <kirkland> cjwatson: bummer, okay.  I'm building one now.
[19:55] <mo__> amitk, for the moment -12, -16 fails
[19:55] <mo__> amitk, as -14 does
[19:55] <amitk> mo__: try -16 again, there should be a new version of linux-ubuntu-modules for -16
[19:55] <cjwatson> kirkland: excellent
[19:56] <cjwatson> kirkland: I'm happy to help from the groff/man point of view if you run into toolchain problems
[19:56] <cjwatson> (I assume you're going to be using groff to build the HTML output; it would be a good idea ...)
[19:56] <kirkland> cjwatson: i might like your review of the pair of scripts I'm using to generate it
[19:56] <cjwatson> sure, send me mail?
[19:56] <amitk> mo__: does waiting for it to boot (for a long time) continue the boot? Just to be sure that we are talking about the same problem....
[19:56] <mo__> amitk, yes, the modules update came a few days ago, it did not solve the problem (for me)
[19:56] <kirkland> cjwatson: i was actually just building flat text, but HTML might be nice too
[19:57] <mo__> amitk, yes of course, it skips after a minute or smth
[19:57] <cjwatson> kirkland: oh, ok, either way
[19:57] <mo__> amitk, or after pressing ctrl+alt+del
[19:57] <amitk> mo__: strange... let's move to #ubuntu-kernel
[20:22] <asac> anyone knows why bash completion is completely broken here on my laptop (up-to-date), while it still works on my desktop (up-to-date)
[20:22] <davmor2> asac: cause it's you laptop :P
[20:24] <asac> you mean TAB is broken?
[20:24] <megabyte405> try compressed air ;)
[20:46] <kirkland> evand: I hit an error testing Kubuntu i386 Alternate ISO, OEM installation.  I'm filing a bug against oem-config, curious if there are particular logs that might be useful.  Riddell pointed me your way.
[20:46] <tgillespie> hi, is it just me or is the latest boost build broken?
[20:49] <evand> kirkland: depends on the error, but typically running the installer in debug mode (`ubiquity -d` in a terminal) and attaching /var/log/syslog, /var/log/partman, and /var/log/installer/debug is sufficient.
[20:51] <kirkland> evand: install succeeded, boots into Kubuntu, installed an additional application (audacious), clicked oem-config-prepare, rebooted; on reboot X fails to come up, drops to a root shell
[20:51] <kirkland> i'm sitting at that root shell, will grab /var/log/syslog, /var/log/partman, and /var/log/installer/debug, file the bug, and move on with my testing
[20:51] <mario_limonciell> kirkland, if X is failing to come up, you may consider grabbing /var/log/Xorg.0.log too
[20:52] <kirkland> mario_limonciell: yup, i had that one
[21:00] <cjwatson> kirkland: also /var/log/oem-config.log, please
[21:00] <kirkland> cjwatson: okay
[21:04] <kirkland> evand: cjwatson: Riddell: FYI: https://bugs.edge.launchpad.net/ubuntu/+source/oem-config/+bug/217884
[21:04] <ubotu> Launchpad bug 217884 in oem-config "Kubuntu OEM failure on second boot" [Undecided,New]
[21:05] <mdke> asac: just noticed the existence of start.ubuntu.com - is someone working on keeping that synched with changes to ubuntu-docs or is it automatic?
[21:07] <asac> mdke: oh, you are the  creates the content of ubuntu-docs
[21:07] <asac> right?
[21:07] <asac> sorry if i forgot. but i think my brain just wiped everything not of immediate concern :)
[21:08] <mdke> asac: well, the ubuntu-core-doc team has commit access to the bzr branch, but I tend to take care of most changes in the package, with dholbach's help :)#
[21:08] <asac> mdke: so you know how all this works?
[21:08] <asac> good ... please join #ubuntu-mozillateam
[21:08] <asac> ill get someone for you
[21:09] <asac> mdke: ?
[21:09] <mdke> on my way
[21:18] <kees> slangasek: bug 216132 ack'd by motu-release (refpolicy).
[21:19] <slangasek> kees: ok, accepted, thanks
[21:25] <evand> kirkland: thanks, found the problem and uploading a fix momentarily.
[21:26] <kirkland> evand: oh, cool.  i was trying it again in case it was something i had done wrong ;-)
[22:15] <mjg59> laga: No
[23:10] <tjaalton> slangasek: new xorg with the fix for bug 217724 uploaded
[23:10] <ubotu> Launchpad bug 217724 in xorg "xqbiff prevents x11-common from removing /usr/X11R6/bin" [High,Confirmed] https://launchpad.net/bugs/217724