[00:04] <Keybuk> ion: former sounds good
[00:04] <slacker_nl> ion: if you need a tester gimme a ppa to add and I'll test it for you
[00:11] <ion> My VirtualBox seems to have serious issues. Still trying to get the VM booted in order to test the patch in action. :-P
[00:15]  * slacker_nl goes to bed
[00:29] <ion> keybuk: Yeah, verified https://code.edge.launchpad.net/~ion/usplash/karmic to fix the issue.
[00:39] <natewiebe13> ion.. what issue does that usplash ppa fix?
[00:40] <ion> natewiebe13: Bug #215666
[00:41] <natewiebe13> ion: awesome.. been waiting for that one
[01:15] <arand> cjwatson: I'm a bit worried about Bug #445067 , would I be right to be?
[01:24] <Keybuk> ion: could you mail that one to me
[01:28] <ion> keybuk: Done
[02:18] <Keybuk> ion: you have one of those slow hard-drives, right?
[02:20] <ion> keybuk: A typical laptop HDD, yeah
[02:20] <Keybuk> ion: sweet
[02:20] <Keybuk> mind running a little test for me
[02:20] <Keybuk> some manual work required
[02:21] <ion> keybuk: Sure.
[02:21] <ion> keybuk: Btw, the mountall 0.2.6 change breaks stuff. Even if there are mountpoints we’re waiting for, if try_mounts is called with newly_mounted == FALSE, mountall exits immediately.
[02:22] <Keybuk> ion: argh
[02:22] <Keybuk> hate hate hate
[02:22] <Keybuk> anyway
[02:23] <ion> How about just iterating through mounts every single time try_mounts is called? :-P
[02:23] <Keybuk> http://zelda.netsplit.com/~scott/ureadahead.tar.gz
[02:23] <Keybuk> download, unpack, configure, make
[02:23] <ion> Will do
[02:23] <Keybuk> that'll give you a src/trace binary
[02:23] <Keybuk> write an /etc/init/trace.conf that execs it, piping the output somewhere
[02:23] <Keybuk> e.g. exec /path/to/src/trace > /dev/trace.log
[02:24] <Keybuk> +2>&1 I guess
[02:24] <ion> I have sreadahead disabled at the moment. Should i do anything about that?
[02:24] <Keybuk> no, that's fine
[02:24] <Keybuk> was goign to say, disable sreadahead
[02:24] <ion> :-)
[02:24] <Keybuk> (but make sure it's installed so /var/lib/sreadahead/debugfs exists :p)
[02:24] <ion> Yeah
[02:24] <Keybuk> make the trace.conf start on startup
[02:24] <Keybuk> or actually
[02:24] <Keybuk> start on starting mountall
[02:24] <slangasek> ccheney: hi
[02:24] <Keybuk> hmm, no
[02:24] <Keybuk> start on startup ;)
[02:25] <Keybuk> the other won't work just yet
[02:25] <Keybuk> then reboot
[02:25] <Keybuk> and once back to your desktop send it SIGTERM
[02:25] <Keybuk> it'll spit out a random dump of information
[02:25] <Keybuk> I'd like that ;)
[02:25] <Keybuk> in the output, I expect you'll see that for any given file, the number of "chunks" exceeds the number of "fragments"
[02:27] <Keybuk> ion: I think the newly_mounted is a hold-over for when try_mounts wasn't a main loop function, so you could well be right - just get rid of that entirely and always try mounts
[02:31] <ion> keybuk: trace: Cannot enable tracing: No such file or directory
[02:31] <Keybuk> ion: odd, does it do that now if you run it?
[02:32] <ion> It works correctly when started from a running system.
[02:32] <Keybuk> odd
[02:32] <Keybuk> maybe a race, /sys was mounted so /sys/kernel/debug existed but not /sys/kernel/debug/tracing
[02:32] <Keybuk> I can fix that
[02:32] <Keybuk> (sreadahead must be vulnerable to the same race though)
[02:32] <ion> I could start with init=/sbin/sulogin and strace the binary to see what’s going on.
[02:32] <Keybuk> ion: tweak the code
[02:33] <Keybuk> actually, right
[02:33] <Keybuk> so that ;)
[02:33] <Keybuk> boot with sulogin
[02:33] <Keybuk> mount -t debugfs none /sys/kernel/debug
[02:33] <Keybuk> then exec init as normal
[02:33] <Keybuk> that'll fix it
[02:33] <ion> Ok
[02:42] <Keybuk> ion: any luck with that?
[02:46] <ion> keybuk: Hmm, the output seems to be missing everything that happened during the bootup, there’s only some desktop stuff in there, beginning with /usr/share/icons/gnome/icon-theme.cache
[02:47] <ion> Nothing about e.g. xsplash, gdm, mountall, hal
[02:48] <ccheney> slangasek: was going to ask you about rebasing on 3.1.1-5 when i do the upload, most of the changes i already have or are apparently from something you told rene to fix yourself?
[02:49] <slangasek> ccheney: the debconf pre-depends?  I'll want to review the exact changes implemented, because even though it's a bugfix there's substantial risk of regression; the sooner you can upload that to the queue, the better
[02:49] <ccheney> ok, so i can go ahead and upload early tomorrow morning and it won't disrupt anything?
[02:50] <slangasek> ccheney: "early tomorrow morning" is later than I would prefer
[02:50] <ccheney> i can try to do it tonight but its already 9pm here and takes a while to get a build done
[02:50]  * slangasek nods
[02:50] <ccheney> my new machine is installing atm but i can do the build on my laptop
[02:51]  * ccheney will see what he can do
[02:51] <slangasek> ccheney: if it's not there until tomorrow morning, it's likely that I won't get back to you with any feedback until Friday; but it's your call
[02:51] <ccheney> ok will try to get it done tonight
[02:51] <Keybuk> ion: odd, but that'll do for now
[02:51] <Keybuk> just want to get an idea of the fragmentation pattern of your disk
[02:52] <ion> keybuk: http://heh.fi/tmp/trace.log
[02:53]  * ccheney is glad he has much faster internet access now :)
[02:56] <Keybuk> ion: not hugely so, then
[02:57] <Keybuk> ion: what filesystem are you using?
[02:58] <ion> keybuk: ext4. I have a box with an older desktop HDD and ext3 nearby; it probably has lower throughput but faster seeking. And it’s been in use much, much longer than this laptop.
[02:59] <ion> Should i get a trace from that box as well?
[02:59] <Keybuk> if you can
[03:13] <ion> keybuk: http://heh.fi/tmp/trace.log
[03:15] <Keybuk> that looks good
[03:15] <Keybuk> having more sreadahead problems with that one?
[03:16] <Keybuk> /usr/lib/locale/fi_FI.utf8/LC_CTYPE (250 kB, 63 pages)
[03:16] <Keybuk> @########################################################......
[03:16] <Keybuk> @@@@@@@@@@##@@@@@@########@@#@@@@######@@######@@###@####......
[03:16] <Keybuk> 1 fragments (228 kB), 27 chunks
[03:17] <ion> I haven’t measured the startup time difference between sreadahead enabled and disabled on the latter box.
[03:20] <Keybuk> bet it hates it
[03:20] <Keybuk> the pretty above means that for that file, 228/250 kB of it was in memory
[03:20] <Keybuk> and in one long contiguous bit of the file
[03:20] <Keybuk> but, on disk, that turns out to be scattered in 27 different places
[03:21] <Keybuk> sreadahead would have tried to optimise that to one readahead() call
[03:21] <Keybuk> it needs to be 27
[03:21] <ion> Ok
[03:21] <Keybuk> possibly with bits of other files in between
[03:21] <Keybuk> in conclusion, sreadahead sucks
[03:23] <ion> So, it readaheads in the wrong order in four simultaneous threads? :-)
[03:24] <Keybuk> basically
[03:24] <Keybuk> and fails to take into account it might need to read a chunk from file A, then a chunk from file B, then the second chunk from file A
[03:24] <Keybuk> etc.
[03:24] <ion> Yeah
[03:26]  * Keybuk battles with FIEMAP
[03:26] <ion> Would be nicer to store the trace data somewhere and have an idle priority program reorder the disk blocks based on it, attempting to get things physically into the order the system tends to read them in. No need for sreadahead anymore.
[03:27] <ion> Next up: getting all filesystems to provide an interface for that. :-P
[03:27] <Keybuk> you'd still want to read ahead
[03:27] <Keybuk> but yes, it'd be nice to be able to feed the trace into defrag too
[03:29] <ion> https://code.edge.launchpad.net/~ion/ubuntu/karmic/mountall/karmic (didn’t test yet, about to)
[03:30] <Keybuk> ion: can you mail me that to remind me
[03:35] <ion> keybuk: Ah, that’s not good either. It ends up trying to mount stuff many times a second, even though nothing’s changed.
[03:36] <ion> keybuk: I’ll send the email when i get it to work.
[03:52] <ion> keybuk: Is the change in 0.2.6 really needed? If the mountinfo watcher notices something has been newly mounted, it calls mounted (mnt), which should cause try_mounts to be called with newly_mounted == TRUE.
[03:53] <ion> I guess it is. /me looks at the log attached to bug #456806.
[03:53] <LaserJock> slangasek: we've found that moving the database (mysql-server or postgresql) from Recommends to Pre-depends for moodle allows it to install. Can I upload that or is it too late?
[03:54] <slangasek> LaserJock: bug #?
[03:54] <slangasek> LaserJock: it's not too late to upload for release, but it's too late for RC
[03:56] <LaserJock> slangasek: bug #440098
[03:56] <slangasek> LaserJock: if this is bug #319868, then Pre-Depends is wrong
[03:56]  * slangasek looks
[04:02] <slangasek> LaserJock: in fact, that's a good general rule for everything: Pre-Depends are wrong
[04:02] <slangasek> LaserJock: the /existing/ Pre-Depends in moodle are /also/ wrong
[04:03] <LaserJock> slangasek: I know, that's why I hated to even mention it
[04:03] <LaserJock> slangasek: but it fixes the immediate issue is all
[04:03] <slangasek> LaserJock: it fixes it *wrong*
[04:03] <slangasek> *do not add Pre-Depends*
[04:03] <LaserJock> k
[04:03] <slangasek> Depends is the correct relationship
[04:04] <LaserJock> will that make the DB server be configured before moodle?
[04:05] <LaserJock> I wouldn't think there would be a difference between Recommends and Depends in that regard
[04:05] <slangasek> then you haven't read the definitions of these package relationships
[04:05] <slangasek> the *definition* of Depends is "packages that must be configured before the current package is configured"
[04:06] <LaserJock> hmm
[04:07] <mathiaz> LaserJock: not sure about the exact context - but neither mysql nor postgresql will be running in the installer
[04:07] <mathiaz> LaserJock: even the package is configured correctly, the daemons are *not* started when d-i is running
[04:08] <LaserJock> mathiaz: apparently it's not that their running that matters but that they're configured
[04:08] <LaserJock> but I don't know why they're Recommends now
[04:08] <mathiaz> LaserJock: if the moodle post install script tries to create databases which SQL statement, the databases need to be running
[04:09] <LaserJock> I don't *think* it does but I'm not sure
[04:09] <mathiaz> LaserJock: http://paste.ubuntu.com/298761/
[04:10] <mathiaz> LaserJock: the postgresql server is *not* running
[04:10] <mathiaz> LaserJock: which is expected in the installer
[04:13] <LaserJock> mathiaz: has that changed within the last release or two (that the db server wouldn't be running)
[04:14] <mathiaz> LaserJock: hm - no - it has been the case for a long long time
[04:14] <LaserJock> I don't understand how this stuff seems to work in Debian and used to work in Ubuntu
[04:14] <mathiaz> LaserJock: may be the moodle packaging has changed?
[04:14] <mathiaz> LaserJock: and now it fails if it cannot connect to the server?
[04:15] <LaserJock> no, the packaging was changed so that it *did* work
[04:15] <LaserJock> it's a real mess though
[04:15] <LaserJock> seems like people have tried for years to get a decent moodle package
[04:15] <LaserJock> ok, just got a report  that sid has the same problem
[04:15] <jbicha> slangasek: even if it's wrong, pre-depends allows the moodle install to work, as it is, some teacher may not understand why his software won't install and how doing a dpkg-reconfigure afterwards makes his software "more right"...to do the "more right" thing would take a full FFE pretty late, right?
[04:16] <LaserJock> jbicha: if Depends works it's infinitly better than pre-depends
[04:18] <mathiaz> jbicha: I don't see how Pre-Depends would work here
[04:19] <mathiaz> the problem is that the database daemon is not running - whether it's a Depends or a Pre-Depends doesn't change IIUC
[04:19] <LaserJock> I tested it with pre-depends and it worked quite well
[04:19] <LaserJock> the app installed and I was able to set up moodle no problem
[04:19] <mathiaz> LaserJock: from an iso install?
[04:20] <LaserJock> no, on a desktop with no db server installed
[04:20] <mathiaz> LaserJock: right - that will work correclty
[04:20] <mathiaz> LaserJock: because the DB daemon will be running
[04:21] <mathiaz> LaserJock: bug 440098 is about Edubuntu d-i
[04:21] <mathiaz> LaserJock: ie an iso installation
[04:21] <LaserJock> right
[04:21] <LaserJock> how is the iso installation different?
[04:21] <mathiaz> LaserJock: daemons are not started during an iso installation - as it doesn't make sense and would probably fail
[04:22] <LaserJock> I see
[04:22] <LaserJock> that would cause a bit of a problem, yes
[04:22] <mathiaz> LaserJock: the daemon are installed in the chroot - but the system is not running from the chroot
[04:22] <LaserJock> right right
[04:23] <LaserJock> ok, so well, that isn't a big issue right now
[04:23] <LaserJock> I already dropped it from the DVD
[04:23] <LaserJock> but that's a very good point
[04:23] <LaserJock> ok
[04:24] <LaserJock> so if we upload the apache config fix (for IPV6) and move the server from Recommends to Depends
[04:24] <LaserJock> then moodle should work for existing desktops
[04:24] <mathiaz> LaserJock: hm - which server?
[04:24] <LaserJock> mathiaz: the db server
[04:25] <mathiaz> LaserJock: you wanna make moodle depend on postgres or mysql?
[04:25] <LaserJock> it Recommends postgresql|mysql-server right now and needs a dpkg-reconfigure to work right
[04:25] <mathiaz> LaserJock: IIRC the default in the config script is to use postgresql
[04:26] <mathiaz> LaserJock: so recommending postgresql seems the best option
[04:26] <LaserJock> well it's postgresql | mysql-server
[04:26] <LaserJock> you should be able to use either
[04:27] <LaserJock> but as slangasek pointed out you need Depends to have it configured before moodle
[04:27] <LaserJock> which seems to fix the problem we've been seeing on the desktop installs
[04:27] <mathiaz> LaserJock: well yes - unless the admin choose mysql as the backend
[04:27] <mathiaz> LaserJock: in which case things won't work
[04:28] <mathiaz> LaserJock: so you'd move postgres|mysql-server to a Depends?
[04:28] <LaserJock> yeah
[04:28] <jbicha> mysql works also
[04:28] <mathiaz> LaserJock: right - seems like a good option
[04:28] <jbicha> I'm going to try again as just a depends, thanks all for the time and the help
[04:28] <LaserJock> I mean, it stinks because it's not all that easy to get a mysql backend because you have to get all the bits right
[04:29] <LaserJock> but it should at least work if you're choose to install the mysql packages
[04:29] <mathiaz> LaserJock: that means if you do an "apt-get install moodle" you'll get a postgresql backend
[04:29] <mathiaz> LaserJock: if you do an "apt-get install moodle mysql-server" you'd have to choose the mysql backend
[04:30] <LaserJock> actually apt-get install moodle mysql-server php5-mysql mysqlclient
[04:30] <mathiaz> LaserJock: right - a Depends should be enough
[04:31] <mathiaz> LaserJock: but it won't fix the installer failure
[04:31] <LaserJock> no
[04:31] <LaserJock> but that's ok for Karmic
[04:31] <LaserJock> well, at least it's not on the Edubuntu DVD, it could be still on the Ubuntu DVD but I doubt many people will be installing it from there
[04:32] <LaserJock> ok, I really got to get to bed
[04:32] <LaserJock> mathiaz: thanks for the info
[04:32] <LaserJock> slangasek too
[04:37] <ccheney> was 'text editor' renamed to 'gedit text editor' on purpose?
[04:42] <julien_c> ccheney: https://bugs.launchpad.net/ubuntu/+source/ubuntu-docs/+bug/442417
[04:51] <ccheney> julien_c: ok
[04:51]  * ccheney likes the new karmic artwork :)
[04:54] <ccheney> julien_c: hmm so it sounds like someone just dropped a patch by accident and then isn't going to fix it?
[04:55] <ccheney> slangasek: uploading new OOo now
[04:56] <slangasek> jbicha: I've told you how to fix it right.
[04:56] <slangasek> jbicha: I will not accept the wrong fix for this
[04:56] <ccheney> wow my new system loads OOo so fast I can barely see the splash screen
[04:57] <slangasek> mathiaz: why does the db server not start in the target under the installer?  I wasn't aware that we redirect invoke-rc.d there?
[04:57] <ccheney> ~ 0.5s or so, can't even time it really
[04:57] <mathiaz> slangasek: hm - I thought invoke-rc.d was redirected in the installer
[04:57] <jbicha> slangasek: I thought you said I just needed to make the db server & debconf depends not pre-depends
[04:57] <slangasek> mathiaz: I honestly don't know
[04:58] <slangasek> jbicha: yes - which modulo mathiaz's concerns about the server not starting when running under the installer, is the right way to fix it.
[05:00] <jbicha> slangasek: so my new patch is not necessarily a wrong fix now?
[05:01] <slangasek> jbicha: I haven't seen the new patch, let me look
[05:01] <slangasek> I was responding to your comment here on IRC
[05:01] <shtylman> ccheney: specs?
[05:02] <slangasek> jbicha: yes, that new patch looks fine, thanks
[05:03] <ccheney> shtylman: core i7 860 @ 3.6ghz
[05:03] <jbicha> slangasek: thanks again, I have to go to my real job now
[05:03] <shtylman> nice!
[05:04] <shtylman> ssd drives?
[05:04] <ccheney> shtylman: 8gb ddr3 1690mhz :)
[05:04] <ccheney> shtylman: no just a regular 1tb seagate drive
[05:04] <shtylman> thats some nice stuff
[05:04] <shtylman> you gotta put two ssd in raid 0
[05:04] <shtylman> that will seal the deal
[05:04] <ccheney> shtylman: yea i was tired of using my 3 year old system so upgraded, heh
[05:04] <shtylman> nice
[05:04] <shtylman> yea... doesn't compiling OO feel so much better
[05:04] <ccheney> two ssd would cost about as much as my whole system, heh
[05:05] <shtylman> don't have to be top of the line
[05:05] <ccheney> yep ~ 54m or so
[05:05] <shtylman> I found that standard ssd in raid 0 perform very well
[05:05] <ccheney> ah
[05:06] <ccheney> does linux do trim yet?
[05:06] <shtylman> no idea...I think I hear it does
[05:06] <ccheney> ok
[05:06] <shtylman> but I ould be wrong on that
[05:06] <shtylman> *could
[05:07] <ccheney> iirc ext4 was going to get it soon back around UDS time but i haven't tracked its status
[05:07]  * ccheney may be thinking of UDS jaunty though
[05:08] <shtylman> hmm
[05:08] <shtylman> maybe... ive been running ext4 on my ssds
[05:09] <shtylman> but then again I havn't tuned anything
[05:09] <shtylman> I just run stock options for now
[05:09] <ccheney> ok
[05:16] <cjwatson> slangasek,mathiaz: we do indeed stop services being started in /target during installation
[05:17]  * cjwatson runs to catch a flight
[05:18] <ion> cjwatson: Only 5½ hours of sleep? :-)
[05:18]  * slangasek waves
[05:18] <cjwatson> ion: more like 3.5
[05:18] <ion> Ouch :-)
[06:24] <liw> screen is supposed to be locked when suspending, right? mine isn't, what should I look at?
[06:24] <StevenK> slangasek: Bug 456896 is asking for the removal of kaffe, but there's a bunch of rdepends. Debian removed kaffe about a week ago, so they've done the work for this, it looks like kaffe -> default-jdk, are you comfortable handling this before release?
[06:25] <StevenK> ScottK: In other news, the rest of your removal requests are done.
[06:26] <ScottK> StevenK: Thanks.
[06:27] <slangasek> StevenK: of handling what, updating the rdepends for the transition?
[06:28] <liw> also, I keep hitting but #446031 still (just did), and it's starting to worry me
[06:28] <slangasek> I think that's motu-release's call
[06:29] <StevenK> slangasek: Yes.
[06:29] <StevenK> ScottK: ^ ? :-)
[06:29] <slangasek> liw: gnome-screensaver has been failing to lock-on-idle for me today; would suggest filing the bug there
[06:29] <ScottK> StevenK: Looking
[06:30] <ScottK> StevenK: Let's hold off on that one for now.  I'll look at it when it's not 1:30AM and I'm tired.
[06:35] <liw> slangasek, #446191 has same symptoms as I do
[06:38] <liw> hm, if I enable screensaver's locking, suspend locks, too; I guess I can live with that, though it's going to annoy me often
[06:47] <slangasek> liw: different bug than mine then, I guess; I already have gnome-screensaver set to lock
[06:48] <liw> let me see if I can trigger the screensaver and see if it locks...
[06:49] <al-maisan> Good morning
[06:51] <ccheney> memory bandwidth (tested via hdparm) on this new machine is immensely faster than my old box, 1.4GB/s vs 11.5GB/s
[06:55] <liw> I must be doing something wrong, I can't get screensaver to trigger
[07:00] <mneptok> liw: my screen doesn't lock when suspending, either. i can always open the laptop lid easily.
[07:01] <liw> mneptok, heh
[07:06] <slangasek> liw: well, my problem appears to be resolved after the latest reboot, leaving only the policy question, I guess
[07:06] <slangasek> (and I'm of the opinion that one toggle for screen lock is sufficient)
[07:08] <liw> slangasek, for the suspend? I won't oppose. I'm now more worried that my screesaver doesn't trigger at all
[07:10] <liw> though less worried that my desktop's network doesn't come up at all
[07:10]  * liw is generally worried this morning
[07:31] <liw> http://paste.ubuntu.com/298845/ -- which setting there is wrong and prevents screensaver from working?
[07:39] <liw> slangasek, is bug #411350 the on you get?
[07:39] <slangasek> liw: dunno, the problem's not reproducible for me now
[07:40] <slangasek> superm1: bug #457896 - in a chroot, or not?
[07:40] <slangasek> superm1: ignore that question, it's clearly not
[07:41] <slangasek> superm1: please give me the output of 'sudo status idmapd; sudo dpkg --configure --pending; sudo status idmapd'
[07:42] <superm1> slangasek, well i already resolved it by "sudo service idmapd stop && sudo apt-get upgrade"
[07:42] <slangasek> superm1: sigh
[07:42] <slangasek> superm1: I can't reproduce this problem, so that leaves me with no way to fix it :(
[07:43] <slangasek> superm1: how about 'sudo status idmapd; sudo dpkg-reconfigure nfs-common; sudo status idmapd'?
[07:43] <pitti> Good morning
[07:43]  * slangasek waves to pitti 
[07:44] <superm1> slangasek, http://paste.ubuntu.com/298853/
[07:46] <slangasek> superm1: I think you put an extra 'service' in there, but close enough ;)
[07:46] <slangasek> superm1: actually, what commands *did* you run?
[07:46] <superm1> slangasek, $ sudo status idmapd; sudo dpkg-reconfigure nfs-common; sudo status idmapd
[07:47] <slangasek> er, odd
[07:48] <superm1> it looks like it tries to restart statd, gssd, and idmapd
[07:48] <slangasek> which it's supposed to do - I don't know why the extra output is there, though
[07:48] <slangasek> but that's reproducible for me when using dpkg-reconfigure
[07:51] <superm1> would you like me to attach misc things that appear to be sourced like /etc/default/nfs-common /etc/exports /etc/fstab ?
[07:51] <slangasek> superm1: feh, dpkg-reconfigure bypasses setting the DPKG envvar we look for; well, that explains the noise
[07:51] <slangasek> superm1: you haven't modified /etc/init/idmapd.conf, have you?  (debsums -e -s nfs-common)
[07:52] <superm1> return code was zero for that
[07:52] <superm1> i dont recall ever touching it
[07:52] <slangasek> ok
[07:54] <slangasek> superm1: well, "idmapd start/running" is the wrong output, because there should be a PID.  Can you do a sudo stop idmapd && sudo initctl log-priority debug && sudo start idmapd, and send me whatever log spew upstart generates? (/var/log/syslog)
[07:55] <superm1> slangasek, http://paste.ubuntu.com/298858/
[07:57] <slangasek> superm1: ok, please run 'sudo rpc.idmapd -v -f' and show me the output
[07:58] <superm1> slangasek, ooh this looks fun: http://paste.ubuntu.com/298859/
[07:58] <slangasek> (the log shows that upstart got all the way to trying to run rpc.idmapd, and the process died immediately after invocation)
[07:58] <slangasek> superm1: urk
[07:58] <superm1> the only reason i could suspect that would have happened is if ubiquity decided to not copy that file during installation
[07:59] <slangasek> superm1: ok, cool, Not My Bug ;)
[07:59] <superm1> slangasek, yeah.... let me fire up a VM with a fresh install and see if that's still happening on current dailies too then
[08:00] <slangasek> superm1: ok - I've sent the latest info to the bug but left it open, I'll leave it to you to further triage as you see fit
[08:00] <superm1> slangasek, okay thanks.
[08:04] <slangasek> ironically, we had two undesirable behaviors of upstart cancelling each other out (job is considered started even if respawning indefinitely; running 'start' on a started job fails), and the init script did the right thing, it just didn't give any useful feedback
[09:04] <slangasek> davidbarth: can you tell me what the status of bug #419839 is? these tasks have been marked "fix committed", but I don't know if that's accurate at all and I don't know how to verify myself whether this is resolved
[09:21] <pitti> kees, mdeslaur, jdstrand: I just got a call from a friend that yesterday's kernel update rendered his machine unusable; some init scripts fail, and you can't even log into a VT ("/bin/bash: permission denied"); haven't tracked it down yet, since booting the previous kernel now gives the same result; did you happen to hear any other problem reports from anywhere?
[09:22] <pitti> (jaunty)
[09:29] <chrisccoulson> hey pitti - do you think we should revert back to the jaunty behaviour for screen locking on suspend, and fix bug 446191 before release?
[09:29]  * chrisccoulson prods launchpad again
[09:33] <pitti> chrisccoulson: read LP and upstream bug now
[09:33] <pitti> chrisccoulson: if we keep this gconf key disabled by default, we should revert, yes
[09:33] <pitti> chrisccoulson: I'm just not sure whether we shouldn't enable screensaver lock as well by default
[09:34] <pitti> chrisccoulson: my feeling is that it makes sense (as much as locking screen on suspend)
[09:34] <pitti> chrisccoulson: but at this point of the release cycle it's bad to change behaviour like that, so I agree to just reverting to jaunty g-p-m behaviour
[09:34] <chrisccoulson> yeah, i'm not sure about the default. i've always found it a bit strange that we turn the default to off
[09:34] <pitti> chrisccoulson: what would that mean technically? change gnome-session to not look at the screensaver gconf key when suspending?
[09:34] <pitti> seb128: ^ any opinion?
[09:35] <chrisccoulson> i'll work on a patch later to revert back to the jaunty behaviour then. it will involve the same logic to what is already in g-p-m
[09:35] <chrisccoulson> (i'll probably just copy and paste;))
[09:35] <chrisccoulson> that will mean that the behaviour follows g-p-m policy, which is how it used to work
[09:35] <seb128> chrisccoulson, is there a summary of jaunty and karmic behaviours?
[09:36] <seb128> I'm not sure what it used to do and what it does now
[09:36] <pitti> chrisccoulson: yes, that makes sense; so it will read g-p-m's gconf key instead of g-screensaver's?
[09:36] <chrisccoulson> seb128 - in jaunty, suspend used to be proxied through g-p-m, and the decision to lock the screen was based on g-p-m settings, which are independent of the screensaver settings in Preferences -> Screensaver
[09:36] <pitti> chrisccoulson: that's at least consistent with indicator-applet etc., so let's do that
[09:37] <chrisccoulson> cool, i'll work on that. thanks!
[09:37] <seb128> agreed with pitti
[09:37] <pitti> chrisccoulson: many thanks
[09:37] <chrisccoulson> excellent, thanks:)
[09:40] <davidbarth> slangasek: hi; they are fix commited for gnome apps, in that we have checked that icons were used properly
[09:41] <slangasek> davidbarth: ok, then that should be 'fix released'
[09:41] <davidbarth> slangasek: we should mark that invalid for kubuntu apps however, as the priority here is with following platform UI guidelines more than Ayatana ones directly (KDE loves icons ;)
[09:41] <davidbarth> slangasek: correct, let me update that
[09:41] <slangasek> davidbarth: great, thanks
[09:42] <seb128> I don't think it's obvious for users that it use the screensaver option
[09:42] <seb128> using the gpm one is better
[09:42] <seb128> davidbarth, fix commited = still open
[09:42] <seb128> davidbarth, I've been confused by where the empathy fix has been commited too cf my comments
[09:42] <seb128> davidbarth, ie is there any fix to cherrypick and upload?
[09:44] <davidbarth> seb128: the tasks was a reminder to inspect the code, as the design team had introduced this additional visual requirement
[09:45] <seb128> davidbarth, hum ok, still seems something you could track you of ubuntu package tasks if there is no ubuntu change required ;-)
[09:48] <slangasek> seb128: AFAIK there isn't a gpm option for whether to lock the screen, only whether to blank it?
[09:50] <seb128> slangasek, /apps/gnome-power-manager/lock/suspend
[09:51] <slangasek> seb128: right, but not exposed in the UI
[09:51] <slangasek> (and I don't think it should be...)
[09:51] <seb128> right
[09:51] <seb128> but I think it just makes sense to follow this setting
[09:52] <slangasek> well, you can force it to if you also turn off "use_screensaver_settings" while you're in there
[09:53] <slangasek> but I don't see why anyone would want a different policy when closing the lid than for other uses of the screensaver
[09:53] <slangasek> OTOH, I think anyone whose screensaver isn't set to lock is crazy :)
[09:53] <slangasek> (what else is a screensaver for? :)
[09:54] <seb128> chrisccoulson, pitti: ^
[09:55] <pitti> I said the same in the bug
[09:55] <liw> I prefer to have my screensaver not lock (just turn off the screen to save power) when I'm at home, since the laptop is only turned on when I'm here (if I take the laptop with me, I'd like it to be locked on screensave)
[09:55] <liw> but steve's considered me crazy for years, so that's ok :)
[09:55] <slangasek> :-)
[09:58] <slangasek> liw: I suspect that's really an approximation of the policy you /really/ want, though, which is "when the screen blanks at home, don't lock; when the screen blanks on the road, do lock" ?
[10:00] <seb128> slangasek, you forget "and make coffee"
[10:00] <pitti> presumably you then also don't want it to lock on suspend?
[10:02] <slangasek> seb128: that's why it's KEY_COFFEE
[10:02] <liw> hnghgh. I re-set my screensaver to blank the screen after 20 mins, not 1, and now it started working again -- after 1 min, not 20; it's as if it remembered the _previous_ setting
[10:03] <slangasek> forget gnome-settings-daemon, I have Fn+F2 mapped to my espresso machine
[10:03] <liw> slangasek, hm, yes. on suspend: always lock; on screensaver: when not at home or when there are people there that I don't know
[10:03] <liw> or rather, that don't live there
[10:03]  * slangasek nods
[10:03] <ion> How interesting, i have Fn+F2 mapped to your espresso machine, too.
[10:04] <pitti> is there a way in grub to say "stop in initramfs before booting the root fs?
[10:04] <chrisccoulson> so, we're ok with restoring the jaunty behaviour for screen locking? (i couldn't work out what everyone agrees with)
[10:05] <ion> pitti: break=mount
[10:05] <chrisccoulson> pitti "break=<something>" appended to the kernel command line? (i can't remember what "something" is though)
[10:05] <chrisccoulson> yeah, thats it:)
[10:06]  * ion looked it up from /usr/share/initramfs-tools/init
[10:06] <pitti> thanks
[10:08] <mvo> I get messages on my (upgraded) test system that swap ID <long> remians to be mounted in usplash at bootup ~3-5 times with a delay of ~1sec between them  (then everything continues) - is that a known issue?
[10:08] <Keybuk> mvo: yeah
[10:08] <Keybuk> it's not an issue though?
[10:08] <Keybuk> it's telling you why your boot is taking longer than 3s <g>
[10:09] <slangasek> "I could be using the processor to mount your swap, but I wrote you this message instead" ;)
[10:09] <mvo> heh :) I need a faster system obviously
[10:09] <Keybuk> the fact they appear as separate messages, ion had a fix for
[10:09] <Keybuk> (mountall is sending CLEAR, but usplash is ignoring it)
[10:10] <Keybuk> it should just look like a static message, updated once a second
[10:10] <Keybuk> slangasek: this is why splash screens are fundamentally silly <g>
[10:10] <mvo> ok, cool
[10:10] <liw> slangasek, hah, that reminds me of an optimization story: added some logging to a program to measure how long various parts of it took, and they were really slow; much hair pulling; took out log messages, system was faster than required
[10:11] <liw> turned out writing lots of text to a graphical terminal emulator was really, really slow
[10:11] <Keybuk> liw: see also: bootchart
[10:11] <ion> usplash should have doublebuffering, so mountall could say “CLEAR, TEXT foo, TEXT bar, TEXT baz, FLIP” and there wouldn’t be visible flickering and scrolling on updates. :-P
[10:11] <liw> Keybuk, sure, bootchart is a nice thing to have, this millennium
[10:11] <Keybuk> liw: I mean that bootchart makes a big effect on boot speed
[10:12] <liw> Keybuk, ah, I guess I'm not surprised there
[10:12] <Keybuk> liw: it can up to double the boot time ;)
[10:12] <Keybuk> ion: does Plymouth have double-buffering? :p
[10:13] <Keybuk> ion: btw http://zelda.netsplit.com/~scott/ureadahead.tar.gz -- I'd appreciate another test ;-)
[10:13] <ion> keybuk: Dunno. It should, it it’s supposed to be boot splash done right. :-P
[10:15] <slangasek> Keybuk: btw, upstart readding 'sync on reboot' seems to have caused a regression for me, which I still need to get to the bottom of; the sync never returns, so my system hangs until I power it off :P
[10:15] <slangasek> (may or may not be related to network filesystems being present)
[10:15] <Keybuk> slangasek: that's odd ;)
[10:15] <Keybuk> reboot always had a sync() in it
[10:15] <Keybuk> except for a brief time
[10:16] <slangasek> Keybuk: when was it first removed?
[10:16] <Keybuk> slangasek: mid-karmic
[10:16] <davidbarth> slangasek: i can't update the bug to mark it fix-released; access level issue as it's tracked by the release team i suppose (#419839)
[10:16] <slangasek> Keybuk: so... before the conversion of everything to upstart jobs that would have caused reordering of the shutdown sequence
[10:17] <Keybuk> slangasek: yes
[10:17] <Keybuk> though unmounting things is still handled by the sysvinit scripts
[10:17] <slangasek> davidbarth: release team tracking has no bearing on it, dunno what blocks you - I'll grab it now to fix though
[10:17] <slangasek> Keybuk: yep - but shutting down NM isn't
[10:18] <Keybuk> slangasek: NM was never sendsigs/omit.d either
[10:18] <Keybuk> so it was always dead by that point
[10:18] <slangasek> Keybuk: no
[10:19] <slangasek> Keybuk: by no I mean yes, obviously
[10:19] <slangasek> Keybuk: then the other possible complication is my own migration to NFSv4 during the period ;)
[10:19] <Keybuk> from german import doch
[10:20] <slangasek> that wasn't my problem, I was just asserting untrue things :)
[10:21] <slangasek> well, I guess this would be fixed if I ever got around to implementing the "if all the networks are gone, lazy unmount" I've been meaning to
[10:22] <Keybuk> I could remote the sync() :p
[10:22] <slangasek> I'll try unmounting NFS before reboot, to confirm that's the source of the problem
[10:22] <slangasek> "remote" it?
[10:22] <Keybuk> remove it
[10:22] <Keybuk> evan has rudely not supplied coffee :p
[10:22] <slangasek> heh
[10:22] <Keybuk> but removing the sync() could be bad
[10:23] <slangasek> but your rationale for readding the sync seems... sound, yes
[10:23] <Keybuk> it turns out that remounting ext4 read-only doesn't imply a sync
[10:23] <Keybuk> as of somewhere mid-.31
[10:23] <davidbarth> slangasek: works now, using a different way in LP
[10:26] <slangasek> oh for the love of trapdoors
[10:26] <slangasek> why does clicking once on a background in appearance preferences change my desktop background with no warning and no way to let me restore the custom image I was using before? :P
[10:26] <ion> keybuk: http://heh.fi/tmp/trace-desktop.log (worse throughput, better seek time, ext3, old installation) http://heh.fi/tmp/trace-laptop.log (better throughput, worse seek time, ext4, recent installation)
[10:29] <Keybuk> ion: both fairly fraggy then
[10:30] <Keybuk> /usr/lib/locale/locale-archive (838 kB), 1 chunks (128 kB), 9 extents
[10:30] <Keybuk>   [@@#%%%%%%%%@@#%@##@##@@###@#####..........................................]
[10:30] <Keybuk>   [..........................................................................]
[10:30] <Keybuk>   [..............................................................            ]
[10:30] <Keybuk> that's kinda odd
[10:30] <Keybuk> the %s are bits of the file that were in core memory, but had no extents on disk
[10:30] <Keybuk> ext3 indirect blocks maybe?
[10:33] <soren> Keybuk: What did you use to generate that map?
[10:33] <ion> keybuk: Both fraggy? In the laptop trace, there aren’t many entries with >1 extents. Or am i reading it wrong?
[10:34] <Keybuk> soren: ureadahead
[10:34] <ion> keybuk: http://pastebin.com/f9f77331 btw :-P
[10:34] <ion> keybuk: Pretty pre-start
[10:34] <Keybuk> heh
[10:35] <Keybuk> oh, sorry, I opened the desktop log twice
[10:35] <Keybuk> you're obviously right that your laptop is a lot less fraggy ;)
[10:35] <Keybuk> this also explains why it's the "I upgraded from warty" crowd who also have the most problems with sreadahead
[10:39] <Keybuk> soren: if you were after the technical explanation
[10:39] <Keybuk> for each file, open() and mmap()
[10:40] <Keybuk> then use mincore() to identify what bits of the file are in the page cache
[10:40] <Keybuk> iterate over that to generate a series of in-memory chunks
[10:40] <Keybuk> and use the FIEMAP ioctl() to convert that to a list of on-disk extents
[10:41] <Keybuk> ie. that file has one contiguous chunk in memory, but is actually split across 9 disk locations including a gap
[10:43] <ion> keybuk: So, after having made the determination that there’s nothing wrong with the short try_mounts function, i spent 1½ hours crawling through the logic of mountall, trying to keep track of state from the log attached to the bug report, until i finally took another look at try_mounts and realized all = TRUE was set on the wrong side of the start of the while loop. ;-)
[10:43] <Keybuk> ion: oh?
[10:43] <Keybuk> how would that help
[10:44] <Keybuk> elmo's problem was that by the time he got to try_mounts(), newly_mounted was FALSE, so it never determined that everything was mounted so never exited
[10:45] <ion> I’ll pastebin what i think happened on his system, a moment...
[11:00] <ion> keybuk: http://pastebin.com/m26780454
[11:01] <Keybuk> ion: oh, that makes sense
[11:01] <Keybuk> all needs to be set to TRUE at the top of the loop?
[11:02] <ion> keybuk: http://bazaar.launchpad.net/~ion/ubuntu/karmic/mountall/karmic/revision/141
[11:02] <Keybuk> ion: can you mail that to me? :p
[11:03] <ion> keybuk: I already did. :-P
[11:03] <soren> Keybuk: Does ureadahead exist anywhere except your laptop? :)
[11:04] <Keybuk> soren: I gave ion the URL :)
[11:04] <Keybuk> it's just the tracer code at the moment
[11:04] <ion> http://zelda.netsplit.com/~scott/ureadahead.tar.gz
[11:04]  * ion realized he just typed the command ‘/last urea’
[11:05] <soren> Keybuk: Ah, there it is. Neat.
[11:08] <Keybuk> ion: urea is an interesting name ;)
[11:16] <ion> keybuk: Also, i’m quite certain it’s okay to have the delayed_exit call within the while (newly_mounted) loop. mounted() is called (and sets newly_mounted = TRUE) whenever mountall itself manages to mount something or it notices from mountinfo that something else mounted what it was waiting for. (As i mentioned, moving the delayed_exit call outside the loop caused the call to happen on every such main loop iteration that had newly_mounted == FALSE, which ...
[11:16] <ion> ... was bad).
[11:19] <Keybuk> yeah I think you're right
[11:20] <Keybuk> I'll get elmo to test after RC
[11:21] <ion> In fact, i’m totally certain it’s okay, but now that i said it, i’m sure someone bumps into some obscure code path that makes it not okay. :-P
[11:22] <Keybuk> I'm truly horrified by how many corner cases there are in mounting filesystems ;)
[11:29] <davmor2> Keybuk: will you hate me if I assign bug 457496 in your general direction.  /me runs for cover
[11:29] <Keybuk> davmor2: ion already has a fix for that
[11:29] <davmor2> Yay :)
[11:29] <davmor2> can I assign it to you then ion
[11:30] <ion> Well, i’ve done all i can, someone with teh access just needs to upload it. :-P
[11:30] <Keybuk> assign it to me, since I'll be the one to sponsor it in
[11:30] <davmor2> Keybuk: sweet
[11:31] <ion> Looks like a duplicate of bug #215666, though.
[11:38] <pitti> kees, mdeslaur, jdstrand: unping, we solved it; local problem
[11:43] <ion> pitti: Out of curiosity, what was the cause?
[11:46] <pitti> ion: a backup cron script messed up permissions of /bin, /lib, etc.
[11:46] <pitti> but I didn't have that idea on the phone, I actually had to travel here :)
[11:46] <ion> Ah, you don’t have teleport transportation in Germany yet.
[12:26] <mantiena> hello all
[12:28] <mantiena> evand: hi, today is translation freeze do you have any plans about updating Karmic ubiquity translations from launchpad ?
[12:28] <evand> mantiena: ah, thanks for the reminder.  On it now.
[12:28] <mantiena> I've found several problems in Lithuanian translation and I'm fixing these right now
[12:28] <evand> okay
[12:28] <evand> mantiena: do let me know when you're done
[12:29] <slangasek> for ubiquity, or for ubiquity-slideshow?
[12:30] <evand> ah right, the exception is only for the slideshow, if memory serves
[12:30] <mantiena> evand: could you wait for ~2 hours, I wanna export debian-installer and ubiquity-debconf translations and test it in real installation (I wanna be sure to have final version without problems)
[12:30] <slangasek> because the nonlangpack translation deadline was /last/ week
[12:31] <dpm> slangasek, ubiquity-slideshow -> bug 452889
[12:31] <slangasek> dpm: yes, I'm just trying to clarify if that's what mantiena is asking after
[12:31] <dpm> ah, ok
[12:31] <mantiena> evand, slangasek: you will update only ubiquity-slideshow translations, not d-i and ubiquity-debconf?
[12:32] <slangasek> mantiena: correct, no further updates are planned for those other packages unless critical bugs are found
[12:34] <mantiena> evand: so, now I can fix only slideshow translations? you will not update ubiquity-debconf and d-i translations from launchpad.net ?
[12:34] <evand> correct
[12:34] <evand> sorry
[12:35] <mantiena> evand: ok, I will work now only on slideshow translations, I will inform you when I finish
[12:35] <evand> mantiena: thanks!
[12:49] <ion> kees: Is your latest commit to mountall really the way to go? It leaves ‘cannot yet be mounted’ messages to the screen even after successful mounts. (Cc: Keybuk)
[12:51] <ion> kees: IMHO, that part of mountall code should be left as it was; the CLEAR commands that were originally there will work as soon as my usplash change is published.
[12:52] <Keybuk> I think kees's complaint is that it clears at all
[12:52] <Keybuk> he likes verbose boot logging
[12:53] <slangasek> having mountall clearing interleaved with boot messages from other services certainly seems problematic to me, for the !quiet case
[12:53] <Keybuk> though I don't think his patch is right either
[12:53] <Keybuk> because that means it'll always look like the "mountall singing about gold" case is scrolling text
[13:02] <ion> To implement the thing *properly*, usplash or equivalent should have a socket that would listen to distinct connections, and it could provide each connection a variable-sized area for text output, keypress input, progress etc. and kill each area on the corresponding client disconnection. The user could switch between cryptsetup’s password request and mountall waiting for Esc with the tabulator. :-)
[13:02] <ion> I guess that won’t happen for karmic. :-P
[13:04] <ion> In fact, mountall probably should create a connection for each action currently in progress. Every one of them could have its own progress widget and listen to Esc separately.
[13:05] <ion> (Of course, things could be multiplexed to a single connection, but that might be unnecessary optimization.)
[13:15] <ion> keybuk: ↑ :-)
[13:21] <ion> The splash program could render the equivalent thing to text console as well, so clients wouldn’t need to handle the console fallback themselves.
[13:24] <slangasek> ion: they already have to handle the case where usplash isn't running, though?
[13:26] <ion> So make this hypothetical splash thing a dependency. :-P If it doesn’t manage to display a graphical splash, it’ll at least open a pretty text UI on a VT.
[14:10] <mvo> Riddell: hm, I'm still seening issues with my kubuntu hardy->karmic upgrade, now http://paste.ubuntu.com/299039/
[14:10] <mvo> Riddell: it did work flawless for you?
[14:11] <Riddell> mvo: it works flawless for me from a stock hardy Kubuntu install, that's not the same as working with a load of extra things installed as most users will
[14:12]  * mvo nods
[14:17] <mvo> Keybuk: could you please have a look at http://paste.ubuntu.com/299039/ (happens during hardy->karmic) - is the "invoke-rc.d udev reload" problematic ?
[14:47] <cr3> primes2h: thanks for the email report about the anti-slashes in checkbox, those are unfortunately needed to indicate the following newline should be ignored. so, they're not meant to be like \n, they're meant to enable the template files to be more readable by having long lines wrapped
[14:49] <asac> can we upload to karmic-proposed already?
[14:50] <primes2h> cr3: Do you mean we have to report them also in the translated strings?
[14:55] <cr3> primes2h: if you simply translate pagraphs as a single line, then you don't need any anti-slashes at all
[14:56] <dpm> cr3, primes2h, thanks a lot for the work on getting those strings translatable and announcing it to translators! One question folks have been asking is how to translate strings such as https://translations.edge.launchpad.net/ubuntu/karmic/+source/checkbox/+pots/checkbox/ca/25/+translate How should the translations be done in the case of backslashes? Just translate them as they are? Could they be perhaps substituted by newlines instead at some futute ve
[14:56] <dpm> rsion?
[14:57] <dpm> future, I meant
[14:57] <cr3> dpm: \ != \n, it's actually the opposite, the anti-slashes are meant to express "no newline" :)
[14:57] <dpm> oh
[14:57] <primes2h> cr3: in the po the \ are reported as \\
[14:58] <cr3> dpm: I didn't foresee this kind of problem and it's unfortunate that even newlines are being wrapped into a single line in the translation interface
[14:58] <primes2h> cr3: and launchpad report it as \
[14:58] <primes2h> in the translation UI
[14:58] <cr3> primes2h: and how are the newlines reported?
[14:58] <primes2h> cr3: in po is \n
[14:58] <cr3> dpm: to answer your other question though: yes, this will definately be addressed early in the lucid cycle
[14:59] <primes2h> and launchpad report it as a graphic symbol
[15:00] <cr3> oh crap, there seems to be a bug in [type: gettext/rfc822deb] which is stripping out text!
[15:03] <primes2h> cr3: example https://translations.edge.launchpad.net/ubuntu/jaunty/+source/xubuntu-docs/+pots/printing/it/64/+translate
[15:03] <cr3> primes2h: I think I can workaround this problem for now, let me try something out...
[15:05] <dpm> primes2h, I don't quite understand the problem there. Launchpad uses the graphical symbols to better highlight spaces, it's always been like that
[15:05] <dpm> on the string you were pointing to ^
[15:05] <primes2h> dpm: I was just explaining cr3 how launchpad show the \n
[15:06] <dpm> primes2h, ok, gotcha
[15:12] <pitti> jono: PAE kernel> 4 GB? I wish ..
[15:12] <jdstrand> kirkland: are you planning a libvirt upload?
[15:12] <jdstrand> kirkland: hi btw!
[15:13] <kirkland> jdstrand: howdy
[15:13] <kirkland> jdstrand: i don't have anything
[15:13] <kirkland> jdstrand: why?
[15:13] <jono> pitti, lol
[15:13] <jdstrand> kirkland: cause I have something that could be incorporated into it
[15:13] <jono> yeah this is the problem we are finding, few people have that hardware
[15:13] <jdstrand> kirkland: but, if you don't, I guess I'll just SRU it
[15:13] <kirkland> jdstrand: i wish i had a fix for the audio hangs, etc.
[15:13] <kirkland> jdstrand: but i don't yet, sadly
[15:14] <jdstrand> kirkland: did you see dtchen's comment?
[15:14] <kirkland> jdstrand: nothing pending on libvirt on my side
[15:14] <kirkland> jdstrand: yeah, i did
[15:14] <kirkland> jdstrand: i'm still trying to tackle it from the qemu-kvm side
[15:14] <jdstrand> kirkland: that would seem to be the best route, yes
[15:14] <kirkland> jdstrand: i have a build of qemu-kvm in my ppa that completely disables support for the pa backend in qemu-kvm
[15:15] <jdstrand> kirkland: though it working without the monitor is intriguing
[15:25] <Martin_vW> Hello. I just uploaded my first package to a PPA; it's a patched version of libwnck. Of course, as soon Ubuntu releases a new version of libwnck, my version will get overwritten with the most recent one and I have to patch the new version too. Is there a way that e.g. Launchpad will inform me when this happens, so that I don't have to monitor libwnck myself?
[15:26] <slangasek> jono: why does testing the PAE kernel require a 32-bit processor?
[15:26] <slangasek> jono: the PAE kernel should also get used if installing i386 on a 64-bit processor
[15:26] <jono> slangasek, thats what I was told by david who asked Colin
[15:27] <slangasek> hmm
[15:27] <pitti> hm, are there really people with a real 386 processor and 4 GB RAM?
[15:27] <LaserJock> it was fairly common for LTSP servers not that long ago
[15:27] <pitti> I meant "not 64 bit compatible"
[15:27] <jono> slangasek, I can modify the testcases page if 64bit processors can be used in the test too
[15:28] <slangasek> jono: insufficient info to tell if this is a game of telephone, or if there's some code path cjwatson is trying to debug that's specific to 32-bit procs
[15:28] <slangasek> jono: however, 64-bit procs with 4GB of RAM are certainly much more plentiful, and installing Ubuntu from DVD on such a system should *also* install the PAE kernel, so at least someone could verify that
[15:29] <jdong> pitti: unfortunately I've been brainless enough to secure 4GB RAM for a core duo laptop.
[15:29] <jdong> needless to say, though, it doesn't support relocating that PCI memory window so even PAE is not useful on it :)
[15:30] <pitti> jono: ^ hah, there walks your test victim :)
[15:30] <jdong> don't we like PAE on i386 for its NX-emulating ability or something like that?
[15:30] <jono> davidm, ^^ was Colin explicit in specifying 32bit?
[15:30] <jono> pitti, aha!
[15:30] <jono> jdong, can you test this?
[15:30] <jdong> ahhhh!
[15:30] <slangasek> we made PAE /better/ on i386 with NX emulation; we /like/ PAE for being able to address our memory ;)
[15:30] <jdong> jono: unfortunately the machine is a server and can't be used to run random stuff right now
[15:31] <jono> jdong, you won't completely blow it away on a whim? bah
[15:31] <jono> :)
[15:31] <jdong> hahaha! A couple people might get upset at me ;-)
[15:31] <jdong> but I always enjoy taking critical machines down for fun experiments!
[15:31] <jono> jdong, lol, I imagine
[15:31] <jono> :)
[15:31] <jono> no worries
[15:31] <davidm> jono no, but that seemed to be the test point 64 bit machines can just access memory
[15:31] <jono> right
[15:31] <jdong> davidm: 64-bit machines with a 32-bit kernel can't :)
[15:32] <jdong> I've got one of those at home too with 8GB RAM running XP.
[15:32] <jdong> that's a good waste of 60% of the RAM.
[15:32] <jcastro> I have hw for this guys, and the 32bit DVD image, should I go ahead and do it or have the images been updated since yesterday?
[15:32] <pitti> jcastro: 20091020 is still current
[15:34] <slangasek> jdstrand: any idea why RAID1/amd64 failed for you but worked for mathiaz?
[15:35] <jdstrand> slangasek: no clue. I tried to provide as much detail as possible. If I were to hazard a guess, I'd look at partman first, cause I think I started to partition one way, then went back and did it for raid
[15:36] <ion> I’d like to switch most of my laptop to amd64, as soon as someone implements the multiarch spec. ;-) Dunno whether it makes any difference with desktop use, but the doubled number of registers should be a theoretical benefit at least.
[15:36] <jdstrand> slangasek: I provided all the logs in the bug
[15:36] <jdong> ion: about a 5% speedup on general stuff, as much as 20% on specially tuned routines.... and about 15% more RAM usage.
[15:37] <slangasek> jdstrand: yeah, the logs don't give me much insight; it looks like grub is saying it can't find device 251,1 - is that supposed to correspond to /dev/md0?
[15:37] <davidm> jdong, good point
[15:37] <ion> RAM usage is not a problem, i always seem to have 1–2 GiB of free RAM.
[15:37] <slangasek> seems a very strange error to affect only some testers
[15:37] <pitti> ion: day to day use feels the same, but compilation is up to 30% faster for me (due to registers, I suppose)
[15:37] <jdong> yeah compilers are A LOT faster
[15:37] <jdong> forgot to mention that :)
[15:37] <jdstrand> slangasek: it didn't. I checked that. I accidentally blew the machine away, but it was not 251, 1. I believe it was 9, 1
[15:38] <jdong> ion: Well RAM usage contends with disk cache availability which sometimes is a cripple to performance at hand :)
[15:38] <davidm> jcastro, test the memory detector code and see if you get back the correct amount of memory that is the critical question
[15:38] <slangasek> jdstrand: hmm; what about vda1?
[15:38] <pitti> ion: it's really just adobe flash that's missing; swfdec works well enough for me, though, so I don't care and don't need ia32-libs
[15:38] <davidm> If you do, we have a logic bug, if you don't then the memory detection code needs to be fixed.
[15:38] <pitti> brw-rw---- 1 root disk 9, 125 2009-10-22 16:03 /dev/md125
[15:38] <jdong> ugh flash on 64-bit is in a nightmare-ish state on Karmic right now :)
[15:38] <jdong> hopefully that clicking bug magically disappears by release
[15:38] <pitti> slangasek: /dev/md is major 9, yes
[15:38] <slangasek> pitti: what's major 251?
[15:39] <maco> jdong: whats yours doing? on mine flash stops working if firefox's uptime is too high
[15:39] <pitti> slangasek: firing up KVM to verify
[15:39] <hyperair> md125? you seriously have 125 raid devices? O_o
[15:39] <pitti> hyperair: no, that's the one that my devkit-disks test suite creates and uses
[15:39] <jdong> maco: not accepting any mouseclicks unless both buttons are held or ctrl/shift are held
[15:39] <jdong> maco: the bug is highly correlated with compiz being active.
[15:39] <maco> hyperair: i think you read that wrong
[15:39] <pitti> hyperair: I create an md from /dev/ram0, so that I can test dk-disks without actually destroying anything
[15:39] <jcastro> davidm: ok, that shouldn't be a problem. Does it absolutely need to be on the real hw or is a VM sufficient? (struggling with my physical DVD burner at the moment)
[15:40] <hyperair> ah cool
[15:40] <hyperair> i see
[15:40] <jdong> maco: that's bug 410407
[15:40] <maco> jdong: lovely. and just soooo discoverable!
[15:40] <keybuk> jdong: really?
[15:40] <keybuk> 64-bit flash is delightful for me
[15:40] <keybuk> for the first time in years, youtube works every time ;)
[15:40] <davidm> jcastro, Real HW it seems to work in a VM
[15:40] <hyperair> keybuk: agreed.
[15:40] <jdong> keybuk: well I'm using flashplugin-nonfree from the repositories
[15:40] <keybuk> jdong: oh, don't use that
[15:40] <davidm> jcastro, but you don't need to do an install, just run the memory test first
[15:41] <keybuk> go download the real genuine 64-bit deb from adobe.com
[15:41] <jdstrand> slangasek: I don't have a virtual machine with virtio atm. I think pitti will be faster than I atm
[15:41] <hyperair> there's a 64-bit deb?
[15:41] <jdong> keybuk: :) native 64-bit flash used to crash on me quite an amusing amount...
[15:41] <hyperair> i downloaded the tar.gz
[15:41] <jdong> I guess I'll try that again.
[15:41] <pitti> slangasek, jdstrand: confirmed; /dev/vda* is major 251 (that's kvm virtio)
[15:41] <jdong> people on the bug report claim even gmail causes the crash
[15:41] <davidm> jcastro, Then if the memory test is good, and you have time the install is worth while
[15:41] <keybuk> flash, on nvidia, on amd64, with compiz
[15:42] <davidm> And the more I think of it testing both on 32 but and 64 bit becomes more important
[15:42] <jdong> keybuk: but do we plan on milestoning any fix for the bug? Kinda sucks that the magical default recommended way of using Flash on amd64 doesn't work.
[15:42] <keybuk> now there's a combination forbidden to appear on question time
[15:42] <jdstrand> slangasek: I can tell you I did tell it to boot in degraded mode
[15:42] <slangasek> pitti, jdstrand: aha - thanks, if it's kvm-specific I'll leave it there for now
[15:42] <slangasek> jdstrand: would be good to have this info added to the bug report
[15:43] <pitti> slangasek: we already had weird kernel bugs with virtio+some particular image types (non-raw) in jaunty, didn't we?
[15:43] <maco> question time? what is question time?
[15:43] <pitti> I just use raw images, though, I never noticed problems
[15:43] <jdstrand> I use qcow2
[15:43] <slangasek> pitti: I don't know, I have no hardware with vmx
[15:44] <pitti> jdstrand: right, that was the one which caused (guest) kernel oopes in conjunction with virtio earlier
[15:44] <jdstrand> pitti: there were definitely problems in the past, but kirkland tells me they are fixed now
[15:44] <pitti> slangasek: no, was just FYI; some of these bugs could still be there and manifest as bugs like that one
[15:44] <pitti> but it's just pure hypothesis
[15:45] <jdstrand> pitti: I can say the kernel didn't oops. it was a grub failure
[15:45] <jdstrand> slangasek: I'll add it to the bug
[15:46] <jdstrand> slangasek: I'm not totally sure we can chalk it up to kvm weirdness though. I know mathiaz uses kvm and bet he used virto too and didn't have the problem
[15:47] <jdstrand> I can try to reproduce
[15:49] <kirkland> jdstrand: pitti: yeah, i'm using virtio almost exclusively, without problem
[15:49] <jdstrand> kirkland: do you use qcow2 or raw?
[15:49] <kirkland> jdstrand: qcow2
[15:50] <jdstrand> kirkland: would you mind peaking at bug #457687? I'm not up on how raid is setup in the installer
[15:50] <jdstrand> peeking
[15:51] <jdstrand> kirkland: keep in mind, /dev/md* is major 9 and /dev/vd* major 251
[15:52] <ccheney> i installed karmic last night and noticed that the english localizations weren't completely installed, when i went to language support it asked me to install the rest, is that a known issue?
[15:52] <kirkland> jdstrand: my focus is elsewhere at the moment; cjwatson re-did the raid grub install stuff for karmic and grub2
[15:53] <dpm> ccheney, if I'm not mistaken, that might be bug 434173
[15:55] <slangasek> ccheney: known,milestoned,triaged...
[16:01] <jdstrand> slangasek: you know, I *did* sete the bootable flag for each of the /dev/vd* partitions that made /dev/md0
[16:02] <slangasek> jdstrand: surely that shouldn't prevent grub from being able to find the device?
[16:03] <wasabi__> jcastro, you're coming to my city!
[16:03] <jdstrand> slangasek: I really have no idea. I am just providing info (I'm no grub/raid expert)
[16:09] <cr3> primes2h and dpm: I won't be able to do anything regarding the anti-slashes for this release, just ignore them for now
[16:10] <primes2h> cr3: ok, but the question is...
[16:11] <dpm> cr3, thanks for your work anyway. What's your recommendation for translators regarding the anti-slashes? Skip them or use them in the translations they do?
[16:11] <primes2h> cr3: translated strings with \ will appear correctly?
[16:12] <mantiena> evand: it seems translation process was slower than I planned... How much time I have for finishing ubiquity-slideshow translations?
[16:12] <cr3> dpm: skip them
[16:12] <evand> I *think* until the end of the day.  slangasek?
[16:14] <cr3> primes2h: the problem is that if you use a slash, it will appear as is unless it is followed by a newline
[16:14] <slangasek> evand: you're doing the upload, right?  whenever you need the cutoff to be in order to get the upload done today
[16:14] <evand> I'll be here late working on the PAE bug, so evening BST.
[16:15] <evand> err late evening, say 10pm
[16:15] <primes2h> cr3:  if we put a \ on launchpad it's reported as a \\ in the po.
[16:16]  * ion hopes lucid will have a non-crippled pulseaudio. :-)
[16:16] <davmor2> ion: It's a lot better this time as far as I've seen, certainly more stable.
[16:17] <ion> In karmic, flat-volumes and rtkit have been disabled. :-\
[16:17] <ion> But it’s understandable, they came in too late to the release cycle.
[16:18] <primes2h> cr3: On the other hand, does checkbox manage CR correctly on the UI if we don't put the \?
[16:18] <cr3> primes2h: yes, lines are wrapped correctly
[16:18] <mantiena> evand: can you tell how many hours I have for translation - I don't know your localtime, so, it would be simpler to know how many hours ;)
[16:18] <cr3> primes2h: both in the command line and the graphical interfaces
[16:19] <evand> mantiena: 5 and a half.
[16:19] <primes2h> cr3: ok, so we'll put strings as one line only.
[16:19] <cr3> primes2h: actually, fyi, the lines are merged by the parser when \ is followed by a newline, so it will be the same if you just don't use \ nor newline
[16:19] <mantiena> evand: thanks
[16:19] <cr3> primes2h: thanks!
[16:20] <evand> sure thing
[16:24] <primes2h> cr3: Thank you very much indeed! Could you please explain it in a email and send it to me so I can forward it to the ubuntu-translator ML? We would be really appreciate it.
[16:26] <primes2h> cr3: I don't want to make a mess :)
[16:33] <cr3> primes2h: will do, but give me a moment, I'm in the middle of too many things right now :)
[16:37] <jdstrand> slangasek: ok, I reproduced it
[16:38] <jdstrand> slangasek: I kept track of my actions and will update the bug with everything
[16:38] <slangasek> jdstrand: ok, cheers
[16:39] <ccheney> slangasek: hmm that bug looks like it was supposedly fixed over a week ago, but i still saw it on the oct 20 disk
[16:40] <slangasek> ccheney: I don't know what bug you're looking at, but I'm talking about bug #452516
[16:41] <ccheney> slangasek: oh oops i looked at the wrong one, bug 434173, apparently
[16:42] <ccheney> ah 452516 does look correct :)
[16:43] <cytotoxic> !ops
[16:43] <maco> cytotoxic: whats that for?
[16:44] <maco> oh gosh another one
[16:44] <cytotoxic> ban me
[16:44] <iulian> Yikes.
[16:44] <maco> or you could just go away...
[16:44] <slangasek> cytotoxic: why?
[16:45] <ruku> Eee O: So excited about 9.10.
[16:51] <ruku> Isn't the Release Candidate supposed to be out today?
[16:53] <julien_c> ruku: yes according to the release schedule, but I think it will come out more towards the end of the day
[16:53] <ruku> Hee. My friend invited me to his Windows 7 install party today. I'm hoping I get to bring a CD along. 83
[16:56] <virtuald> ruku: just get a daily
[16:56] <ScottK> ruku: The current candidate ISOs for RC status will almost certainly be it, so you can download that now.  Most of what's going on now is testing and documentation.
[16:58] <slangasek> cody-somerville: will there be https://wiki.ubuntu.com/Xubuntu/KarmicKoala/RC for the RC?
[16:58] <cody-somerville> Yes
[16:59] <primes2h> cr3: Don't worry, I already did it due to the being in a hurry. Thanks anyway. :)
[16:59] <slangasek> cody-somerville: now's a good time to post it, then :)
[17:00] <slangasek> superm1: http://mythbuntu.org/9.10/rc - access denied?  can that be unblocked?
[17:00] <cr3> primes2h: thanks muchly!
[17:01] <superm1> slangasek, need to make sure that the mirrors are synched first.  few moments
[17:02] <ruku> superm1, yeah. I heard not to download until the official announce was out
[17:03] <slangasek> superm1: website mirrors?
[17:03] <seb128> I'm surprised we didn't get extra bugs about bug #458250
[17:03] <superm1> slangasek, download mirrors.  we have our download URL in there too
[17:04] <superm1> we don't let cdimages.ubuntu.com take "all" the pain :)
[17:04] <kees> jdong: PAE on i386 gets you _real_ NX.  Without PAE, i386 does the partial nx-emulation.  PAE gets you >3G memory ability, though.
[17:05] <jdong> kees: *nods* gotcha
[17:07] <slangasek> superm1: well, the mirrors can't possibly be current yet, because I haven't pressed the button?
[17:07] <LaserJock> slangasek: do I need to write anything up for Edubuntu?
[17:08] <slangasek> LaserJock: there's content is https://wiki.ubuntu.com/KarmicKoala/RCAnnouncement, which is fine; there's no need for you to write anything, I'm just making sure that any links I'm expecting from others based on past practice aren't going to be dead links
[17:08] <slangasek> s/is/in/
[17:08] <superm1> slangasek, yeah it looks like they aren't in order yet indeed.  so  iguess for now we can just link to cdimages, and then update it to the mirrors once they are ready
[17:27] <superm1> slangasek, okay it's ready
[17:28] <slangasek> superm1: ok - mirrors should be able to sync now, also
[17:28] <superm1> thanks
[17:35] <dpm> primes2h, thanks for your e-mail to ubuntu-translators
[17:36] <primes2h> dpm: You're welcome :)
[17:38] <primes2h> dpm: we are in a hurry, so I have tried to do all I could to help.
[17:39] <dpm> primes2h, that was great, thanks
[17:41] <Armageddon> hello guys, I have a question to ask... I think only you can help me out cause you know more about this
[17:42] <Armageddon> I have a bluetooth on my laptop, used to work fine on 8.10, stopped on Jaunty, during the updates process it worked for a while and then another update made it stop again, I don't know which did any, and on Karmic is does not work either, any idea ?
[17:44] <Q-FUNK> howdy! what's missing to get #456598 into Karmic?
[17:47] <highvoltage> Q-FUNK: according to the bug report asac did fix it but the upload didn't make it to the archive
[17:48] <Q-FUNK> highvoltage: that, I've already noticed.  I'm wondeirng what's missing to get it to make it to the archive.
[17:48] <dupondje> can somebody check
[17:48] <dupondje> https://bugs.launchpad.net/ubuntu/+source/aptitude/+bug/391035
[17:50] <highvoltage> Q-FUNK: sorry for have stating the obvious :)
[17:51] <Q-FUNK> highvoltage: I wondered if it might be stalled by the general freeze or something similar.
[17:51] <LaserJock> Q-FUNK: seems like a likely guess
[17:53] <Q-FUNK> LaserJock: indeed so, but I need a binding answer.  right now, introducing this new FF just 2 days before the final freeze has proken this plug-in, which, in turn, breaks one language pack.
[17:55] <Armageddon> Guys, I have bluetooth on my laptop, Toshiba Satellite A300-17G, AMD64 CPU with x86-64 Kernel, bluetooth used to work fine on 8.10, stopped working on 9.04 till one update made it work and I don't know which update did that, and then another update made it stop working again, now on Karmic it doesn't work either, any idea ?
[18:29] <Martin_vW> I've uploaded a package to my PPA, but update-manager always displays a warning that the package is unauthenticated, although I've imported the key. I looked into the repository and noticed that there is no Release.gpg file... could this be the problem's source? http://ppa.launchpad.net/martin.von.wittich/libwnck-nodimming/ubuntu/dists/karmic/
[18:36] <ccheney> Grr what is wrong with launchpad I can't upstream a bug because the page is fubar
[18:36] <ccheney> bug 456434
[18:37] <ccheney> click also affects project and some weird page displays that doesn't seem to have anything to do with OOo
[18:38] <ccheney> argh someone fscked the upstream link for OOo
[18:38] <ccheney> we really need ability to lock things like that to only bugsquad or some smaller group of people
[18:39] <ccheney> someone decided to change the OOo upstream to ubslax
[18:39] <ccheney> whatever that is
[18:42]  * ccheney thinks he managed to fix it, but would be good to be able to find out who the joker is changing things to the wrong settings
[18:46] <Riddell> mdeslaur: do you have anything I can test for the fix for bug 457985 ?
[18:46] <mdeslaur> Riddell: I've added Okular to our test suite so it doesn't happen again
[18:46] <mdeslaur> Riddell: the new updates are built, I'll push them out in about an hour
[18:47] <mdeslaur> Riddell: I can put new binaries somewhere if you want to test. What release/arch do you want?
[18:47] <Riddell> mdeslaur: jaunty i386 would be lovely
[18:47] <mdeslaur> Riddell: sure, hold on a sec
[18:48] <ccheney> whatever is going on it appears 'ubslax' people are linking a lot of packages upstream to themselves for whatever misguided reason
[18:48] <ccheney> jcastro: any idea about the above?
[18:49] <slangasek> ccheney: where exactly does that link to?
[18:49] <slangasek> (is it even good faith, or is it spam?)
[18:50] <ccheney> slangasek: https://launchpad.net/ubslax
[18:50] <jcastro> ccheney: I just fixed one yesterday but I didn't know they did it for other things
[18:50] <ccheney> slangasek: not sure what it is, but breaks upstream linkage
[18:50] <jcastro> yeah, you need to delete their link
[18:50] <ccheney> pidgin apparently is set that way, as was OOo until i fixed it
[18:51] <ccheney> i imagine probably everything shown in their distribution list
[18:51] <ccheney> eg openjdk-6 also shows it
[18:51] <jcastro> ok the project seems to be a one person operation, I'll send the person a mail now
[18:52] <ccheney> looks like there are only 10 packages in the list so its not too bad
[18:52] <jcastro> ccheney: thanks for the tip
[18:52] <ccheney> jcastro: thanks for the following up on it :)
[18:53] <mdeslaur> Riddell: my apologies for the Orkut regression
[18:55] <Riddell> mdeslaur: yay, package updates work
[18:55] <mdeslaur> Riddell: cool
[18:56] <mvo> Martin_vW: yeah, if the ppa has no release.gpg, that is the problem. I think that needs discussion with #launchpad or a bug against soyuz
[19:32] <pitti> jdstrand: just posted a question to bug 456893; would be great if you could answer soon
[19:41] <slangasek> zul: please don't close MIR bugs.
[19:42] <zul> slangasek: sorry
[19:44] <pitti> slangasek: ooh, congratulations!
[19:45] <slangasek> pitti: yes, please
[19:45] <slangasek> heh, ECHN
[19:45] <slangasek> AN
[19:45] <slangasek> pitti: "thanks" :)
[19:51] <jdstrand> pitti: done
[20:03] <cumulus007> Hi, I'm a translator for the Dutch translation team on Launchpad and I noticed that lots of the Ubuntu documentation isn't localized to Dutch, while the translations are fully completed on Launchpad
[20:04] <cumulus007> I think this is not really motivating and I'm wondering why this happens
[20:05] <dpm> cumulus007, would you mind coming to the #ubuntu-translators channel to see if we can sort out what's happening?
[20:05] <dpm> mdke, you might also be interested in that, if you are around ^
[20:27] <dupondje> https://bugs.launchpad.net/ubuntu/+source/aptitude/+bug/391035 -> can somebody check to fix this crap bug ?
[20:29] <sebner> jdstrand: do you plan to do some sync processing (universe) tomorrow?
[20:29] <pitti> lamont: any idea why crested is disabled?
[20:30] <pitti> we're a bit low on buildd power right now (and have a full queue)
[20:31] <pitti> Keybuk, doko__: does it actually make sense to accept this sreadahead upload? sparc is still busted due to the sigbus (but a patch was posted), and slangasek said that the -pthread issue is just for mipsen, which we don't care about?
[20:35] <pitti> Keybuk: util-linux removes libs/blkid/Makefile.in and more Makefile.ins, but it doesn't b-dep on automake; was that intended?
[20:41] <pitti> lamont, elmo: would you mind killing the build on rothera? the other buildd builds a newer gcc, and we need the horsepower now
[20:43] <mdeslaur> Riddell: New poppler packages were published. Regression should be fixed now.
[20:44] <elmo> pitti: done
[20:45] <pitti> elmo: many thanks!
[20:56] <lifeless> slangasek: are you aware of https://bugs.edge.launchpad.net/ubuntu/+source/boost1.38/+bug/457688 ?
[20:57] <ScottK> lifeless: I think it's SRU material unless ajmitch found a patch.
[20:57] <lifeless> so
[20:57] <lifeless> upstream python say 'not a bug, grab the new boost'
[20:57] <doko__> pitti: I don't mind
[20:57] <lifeless> but the new boost isn't released yet
[20:58] <ScottK> Yeah.  ajmitch was trying to find the fix in their VCS yesterday.
[20:58] <lifeless> oh cool
[20:58] <ScottK> I don't think he succeeded though.
[20:58] <Keybuk> pitti: those might be empty directories
[20:58] <Keybuk> I run autogen before making the util-linux package
[20:58] <Keybuk> did it FTBFS?
[20:59] <pitti> Keybuk: I just reviewed the diff
[20:59] <pitti> I accepted it anyway (more or less by accident)
[21:01] <Keybuk> pitti: ok
[21:01] <Keybuk> sreadahead > no harm in accepting it if the patch is right ;)
[21:02] <ajmitch> ScottK: you're right, I didn't find anything yet
[21:10] <pitti> Keybuk: I don't know whether the patch is right, I don't understand the -pthread change; I don't mind the sparc change, since it'll be broken either way
[21:45] <mantiena> Hi evand, still not in bed ? ;)
[21:45] <evand> mantiena: correct :)
[21:47] <evand> mantiena: all set?
[21:48] <mantiena> evand: still fighting with latest slide: ubiquity-slideshow-ubuntu-rhythmbox-totem
[21:48] <evand> okay, I can wait a bit longer
[22:02] <mantiena> evand: is seems I finished the Lithuanian translation of all ubiquity-slideshow-ubuntu templates :)
[22:03] <evand> mantiena: great!  I'll import them now.
[22:08] <trunet> hello guys
[22:08] <trunet> look, I upgraded to karmic today
[22:09] <trunet> and now I can't set a ipv6 address to a bridge I have
[22:09] <trunet> # /sbin/ip ^Cdr add 2001:470:x:x::1/64 dev virbr0
[22:09] <trunet> RTNETLINK answers: Permission denied
[22:09] <trunet> the ip is masqued
[22:10] <trunet> (there's an error in commandline, Ill post again)
[22:10] <trunet> # /sbin/ip addr add 2001:470:x:x::1/64 dev virbr0
[22:10] <trunet> RTNETLINK answers: Permission denied
[22:10] <trunet> it works with ipv4 and setting this same ipv6 to a physical interface works too
[22:15] <mantiena> evand: thanks for improving ubiquity - I was waiting for slideshow feature since 2005, I worked together with spanish guys, who created ubuntu-express installer, which was ubiquity predecessor and Baltix GNU/Linux 2005 (based on Ubuntu 5.10) installer, was with slideshow feature ;)
[22:24] <evand> :)
[22:32] <mantiena> evand: btw, ~12 hours ago I've fixed 2 important Lithuanian translation problems in gfxboot-theme-ubuntu package - previous translation used 2 words for translating "F5 Accessibility" and because of this "F6  Options" doesn't fit in ISOLINUX boot menu :(, are there any chances to see updated translations in final 9.10 CD's?
[22:33] <evand> I don't believe so, but it's the release team's call to make (#ubuntu-release)
[22:35] <maxwellian> Hi, can anyone point me in the direction of a document that clearly describes how to patch a package and then be able to install it to test it, and possibly revert back when I'm done?
[22:38] <mantiena> evand: ok, I asked about this in #ubuntu-release. If you will need to make one more ubiquity build before release - please update d-i and ubiquity-debconf translations from launchpad, there I also have improved some translations today ;)
[23:00] <rickspencer3> robert_ancell, hi
[23:00] <robert_ancell> rickspencer3, hi