[00:00] <cjwatson> that would do it ...
[00:00] <calc> there should be an ID_TYPE for a partition, correct?
[00:01] <cjwatson> yes
[00:01] <cjwatson> ata_id or scsi_id or whatever should set it
[00:01] <calc> ok
[00:01] <cjwatson> we need that in order to filter out CDs, tapes, and other garbage that's uninteresting here
[00:02] <cjwatson> this is going to be vmware-specific
[00:02] <calc> is it, or just the device vmware is emulating?
[00:03] <wgrant> Riddell: That wasn't actually my patch - it's upstreams, and I didn't pull it initially. I just altered it.
[00:03] <cjwatson> well, yes, but it could be that one of the relevant ioctls is failing or something
[00:03] <calc> oh ok
[00:03] <cjwatson> is this vmware's LSI Logic device?
[00:03] <cjwatson> or BusLogic?
[00:04] <calc> it claims to be a PIIX4 IDE and LSI Logic (depending on which it is on)
[00:04] <calc> ah the LSI
[00:04] <calc> i checked the pci id
[00:06] <cjwatson> calc: '/lib/udev/scsi_id --export --whitelisted -d /dev/sda', please?
[00:06] <calc> nothing output
[00:09] <jdstrand> slangasek: would http://cdimage.ubuntu.com/ubuntu-server/daily/20081022.1/ be the new images? they showed up much earlier than 2 hours so I wanted to be sure
[00:10] <cjwatson> calc: try that with UDEV_LOG=debug set in the environment and tail syslog afterwards?
[00:10] <cjwatson> (this really needs Keybuk ...)
[00:10] <cjwatson> Keybuk: batsignal
[00:10] <calc> ok
[00:10] <cjwatson> it's probably actually a kernel bug, but scsi_serial.c is not entirely trivial so you never know
[00:11] <calc> still no output in /var/log/syslog
[00:11] <calc> and no output to screen
[00:12] <slangasek> jdstrand: er, those are them, yes
[00:12]  * jdstrand nods
[00:12] <slangasek> and now, much later than two hours, I'll post them to the tracker :P
[00:12] <slangasek> sorry
[00:12] <jdstrand> heh
[00:12] <cjwatson> calc: well, this depends on how far you're willing to take it; my next step were I in front of the machine would be 'udpkg -i /cdrom/pool/main/s/strace/strace-udeb_*' and then strace the scsi_id invocation above
[00:13] <cjwatson> since it seems like this needs some digging
[00:15] <calc> the ending of the strace shows an ioctl on /dev/sda and then close
[00:15] <cjwatson> can you screenshot that?
[00:15] <calc> yea
[00:16] <calc> done
[00:17] <calc> actually there are several ioctls apparently
[00:18] <calc> that got all of the interesting bit from the strace at least that i saw when scrolling up
[00:19] <calc> the other bits were just loading libraries afaict
[00:42] <james_w> hmm, AdminKit
[00:45] <ArneGoetje> calc: since openoffice.org translations are now installed with the regular language-packs, is it still necessary to install the openoffice.org-l10n-$lang packages, or can I drop the dependencies in the language-support-writing packages?
[00:47] <cjwatson> ArneGoetje: they are?
[00:47] <ArneGoetje> cjwatson: at least they are marked as being exported into the langpacks in Rosetta
[00:47] <cjwatson> I don't see them in the current output
[00:47] <ArneGoetje> cjwatson: hmm...
[00:47] <cjwatson> and wouldn't they have to be exported to gsi?
[00:48] <ArneGoetje> cjwatson: no idea about that
[00:52] <ArneGoetje> cjwatson,calc: forget that question...
[00:58] <calc> ArneGoetje: yea they aren't as far as I know
[00:59] <ArneGoetje> calc: then they shouldn't be exported into the langpacks either, right?
[01:00] <calc> yea they shouldn't and afaik they aren't being export to them
[01:00] <ArneGoetje> calc: how do we currently handle them? Seperate export from rosetta and then building new oo.o-l10n packages?
[01:01] <ArneGoetje> calc: at least some templates are marked as being exported in rosetta... will change that then.
[01:01] <calc> currently not exported but will be doing that with the first jaunty upload, i have to rearrange some bits in the build also since the rosetta stuff was changed
[01:01] <calc> they changed it about a week or two ago
[01:01] <calc> iirc
[01:02] <ArneGoetje> calc: ah...
[01:06] <slangasek> jdstrand, dendrobates: how goes the server testing?
[01:06] <jdstrand> I'm personally working on it-- I know at least two others started
[01:07] <jdstrand> and we were all told to do it :)
[01:07] <kirkland> slangasek: i've downloaded, working on another patch, will be testing server iso thereafter
[01:08] <calc> hmm the server iso got rebuilt today?
[01:08] <slangasek> calc: yes, at server team's request
[01:08] <calc> oh ok
[01:08] <calc> i noticed it resyncing on my machine
[01:08] <Keybuk> cjwatson: am here now
[01:08] <Keybuk> just checking in on my way to bed
[01:09] <Keybuk> there is no ID_TYPE in the udevdb
[01:09] <cjwatson> Keybuk: yeah, I got that far but couldn't see why
[01:09] <cjwatson> bug 287807
[01:09] <Keybuk> because it doesn't come from udev
[01:09] <Keybuk> it's from the kernel uevent
[01:09] <cjwatson> err, doesn't scsi_id write it?
[01:09] <Keybuk> udev doesn't bother caching that stuff in its db, since you can get it by reading /sys/block/sda/sda1/uevent
[01:09] <Keybuk> no
[01:09] <cjwatson> ./extras/scsi_id/scsi_id.c:629:                 printf("ID_TYPE=%s\n", type_str);
[01:10] <Keybuk> unless I'm misfollowing your problem
[01:10] <cjwatson> scsi_id clearly hates that device - calc tried running it by hand at my direction and it wasn't printing anything
[01:10] <cjwatson> and udevadm info prints ID_TYPE for me
[01:10] <cjwatson> so the test is not intrinsically wrong AFAICS; if it were, it would fail everywhere
[01:11] <calc> i'm still here if any debugging is needed
[01:11] <Keybuk> could you recap the problem for me
[01:11] <cjwatson> calc: let me
[01:11] <calc> ok
[01:11] <cjwatson> Keybuk: symptom is that rescue mode fails to detect partitions on calc's vmware emulated disk
[01:11] <Keybuk> ok
[01:11] <Keybuk> do other people's vmware work?
[01:12] <cjwatson> Keybuk: on drilling down, this is because udevadm info -q env -p /block/sda/sda1 doesn't return any output (including ID_TYPE)
[01:12] <cjwatson> haven't heard from others; I don't have a working vmware setup at the moment
[01:12] <Keybuk> calc: no output at all?
[01:12] <calc> i was the first person to test rescue mode afaict
[01:12] <cjwatson> the emulated disk is LSI Logic, which is SCSI
[01:12] <cjwatson> so scsi_id ought to print something useful, AFAICT
[01:12] <cjwatson> calc: rescue mode does work for me - I've confirmed
[01:13] <cjwatson> this is definitely "hardware"-specific
[01:13] <calc> cjwatson: it returns output but not ID_TYPE
[01:13] <cjwatson> oh, sorry, yes
[01:13] <cjwatson> the screenshot is in the bug
[01:13] <calc> http://launchpadlibrarian.net/18807930/bug287807.png
[01:13] <Keybuk> calc: could you pastebin me the output of that udev command?
[01:13] <Keybuk> ah great
[01:13] <calc> Keybuk: its in that screenshot
[01:13] <Keybuk> thanks
[01:13] <cjwatson> ID_PATH and ID_FS_*
[01:13] <cjwatson> list-devices goes "no ID_TYPE, mustn't be a disk then, better skip it"
[01:13] <calc> Keybuk: there is a screenshot of strace of scsi_id also
[01:14] <cjwatson> since it wants to skip other non-disk things like CDs and tapes
[01:14] <Keybuk> cjwatson: that logic will bite you later, but it's not this bug ;)
[01:14] <Keybuk> calc: what's the url of that?
[01:14] <cjwatson> Keybuk: explain that to me later :)
[01:14] <calc> http://launchpadlibrarian.net/18808130/bug287807-2.png
[01:14] <Keybuk> calc: scsi_id doesn't output anything?
[01:14] <calc> Keybuk: nope nothing at all
[01:14] <cjwatson> '/lib/udev/scsi_id --export --whitelisted -d /dev/sda' was the invocation
[01:15] <cjwatson> copied from 60-persistent-storage.rules
[01:15] <calc> yea that ^
[01:16] <Keybuk> ok, so that's the problem here
[01:16] <Keybuk> anything in dmesg?
[01:17] <calc> not that i recall
[01:17] <calc> well not while running those commands anyway
[01:18] <calc> i'll boot back into it and see
[01:18] <Keybuk> calc: could you try it on /dev/sda1 instead?
[01:18] <calc> iirc i ran '/lib/udev/scsi_id --export --whitelisted -d /dev/sda1' also with no output
[01:18] <calc> i'm getting back to the rescue stage now
[01:19] <Keybuk> cjwatson: did you test rescue mode in vmware or something else?
[01:19] <calc> fwiw vmware < 6.5 doesn't seem to work with the intrepid kernel
[01:19] <calc> at least not without some sort of kernel update
[01:20] <calc> er tools software update for the kernel
[01:21] <calc> i see in log this:
[01:21] <calc> rescue-mode: no partitions found!
[01:21] <calc> i can screenshot that if useful, but i think we already well past that point
[01:21] <Keybuk> right, that fits because d-i can't find any partitions
[01:21] <Keybuk> because it's iterating udev info
[01:21] <Keybuk> and udev has no info about it
[01:21] <Keybuk> because scsi_id isn't returning anything
[01:21] <calc> scsi_id sda1 outputs nothing to screen
[01:22] <Riddell> sbeattie: how did that adept hardy test go?
[01:22] <Keybuk> if you strace it
[01:22] <Keybuk> does it have the -EINVAL on the same ioctl?
[01:22] <calc> ran as: /lib/udev/scsi_id --export --whitelisted -d /dev/sda1
[01:22] <calc> lets see
[01:23] <Keybuk> could you try something else for me
[01:23] <Keybuk> /lib/udev/scsi_id --export --whitelisted -d /dev/sda1 -s 3
[01:23] <calc> is the ioctl the 3 or the hex number?
[01:24] <calc> the hex number looks like a memory address to me :)
[01:24] <Keybuk> ah, -s doesn't work directly
[01:24] <Keybuk> /lib/udev/scsi_id --export --whitelisted -d /dev/sda1 --sg-version 3
[01:25] <calc> nothing with --sg-version 3 added
[01:25] <Keybuk> damn
[01:25]  * Keybuk tries to remember how to get into rescue mode <g>
[01:25] <calc> last ioctl was: ioctl(3, SG_IO, 0xbf8002d0)
[01:26] <calc> Keybuk: heh last option on the menu :)
[01:26] <Keybuk> boot from first hard disk?
[01:26] <calc> oh no not that
[01:26] <cjwatson> Keybuk: kvm
[01:26] <calc> hmm i thought i had hit the last option on the menu
[01:26] <cjwatson> Keybuk: "rescue a broken system"
[01:26] <Keybuk> it's the last option on the alternate
[01:26] <Keybuk> it's not on the live
[01:26] <Keybuk> I remember now
[01:27] <cjwatson> yes
[01:27] <Keybuk> calc: vmware 6.5 ?
[01:28] <calc> yes
[01:28] <Keybuk> confirmed here
[01:29] <calc> i have vague memory of the drivers vmware used were slow to convert to udev so this might be a driver issue
[01:29] <Keybuk> it's not a "convert to udev" issue
[01:29] <calc> er i mean sysfs
[01:29] <Keybuk> the driver appears to simply not implement SG
[01:29] <calc> oh?
[01:30] <calc> but it still gets a sg0 device?
[01:31] <calc> actually those might be for the ide
[01:31] <Keybuk> SG is an ioctl set for querying scsi devices
[01:32] <calc> so it can have a scsi generic device without supporting SG?
[01:32] <Keybuk> right
[01:32] <calc> oho k
[01:32] <Keybuk> cjwatson: how do I install strace on this thing?
[01:33] <cjwatson> Keybuk: udpkg -i /cdrom/pool/main/s/strace/strace-udeb_*
[01:33] <Keybuk> yeah getting -EINVAL again
[01:34] <cjwatson> isn't there some old ioctl that predated SG_IO?
[01:34] <Keybuk> honestly, I don't think this thing wants to tell anyone what it is
[01:35] <slangasek> ... VMware+scsi?
[01:35] <Keybuk> I bet I know why this worked before
[01:35] <calc> slangasek: yea
[01:35] <slangasek> isn't that the combination you're not supposed to use, or was that only for CDs?
[01:35] <calc> Keybuk: because we forgot to test it? :)
[01:35] <cjwatson> SCSI is what VMware recommended for hard disks when I last used it
[01:35] <Keybuk> calc: we're good at that ;)
[01:35] <calc> slangasek: thats default combo, scsi disk and ide cd
[01:35] <cjwatson> calc: no, I used to do all my testing in VMware
[01:35] <slangasek> ok, right
[01:36] <cjwatson> calc: and indeed I may have developed rescue mode at least partially in VMware
[01:36] <calc> i did a typical setup for the vm and just installed into it
[01:36] <Keybuk> I do all my testing in vmware
[01:36] <calc> cjwatson: ok
[01:36] <Keybuk> though for obvious reasons, I've been focusing on desktop testing recently ;)
[01:38] <Keybuk> oh arsebiscuits
[01:40] <Keybuk> cjwatson: you remember how I said udev info wasn't really a stable interface?
[01:40] <Keybuk> and that relying on it might one day bite you? :p
[01:40] <cjwatson> as it happens, no
[01:41] <Keybuk> well
[01:41] <cjwatson> are there any stable interfaces for hardware detection? :-P
[01:41] <Keybuk> a while back, the kernel people finally realised that hinting to userspace that something was either a disk or a partition would be jolly helpful
[01:41] <cjwatson> I've just got used to having to keep up
[01:41] <Keybuk> so all block devices include a DEVTYPE=disk and DEVTYPE=partition in their environment
[01:42] <Keybuk> scsi_id used to have a "fallback to sysfs and figure it out" mode
[01:42] <Keybuk> but the only really useful thing that did was set ID_TYPE to disk or partition
[01:42] <Keybuk> since we have DEVTYPE now, and everything in udev uses that instead
[01:42] <Keybuk> that code was dropped out of scsi_id
[01:43] <Keybuk> so on vmware, scsi_id outputs nothing - because the driver doesn't implement that ioctl
[01:44]  * slangasek writes a blog entry, "You think you want your userspace to be able to talk to your kernel, but you're wrong"
[01:44] <Keybuk> slangasek: I've written many blog entries about the kernel's attitude to userspace
[01:44] <slangasek> what you really want is your userspace to talk to gregkh so he can talk to your hardware :-P
[01:45] <Keybuk> cjwatson: so, in summary, list-devices is relying on the existance of an environment variable in the udevdb that isn't there anymore
[01:45] <Keybuk> and isn't there, because it's deprecated in favour of a different one
[01:45] <Keybuk> and just to really make your day complete
[01:46] <Keybuk> that different one won't be in the udevdb either, because it comes from the kernel uevent, and udev doesn't bother caching that stuff
[01:46] <cjwatson> ok, so I just need to grep the uevent?
[01:46] <Keybuk> I have a fairly sick suggestion
[01:46] <Keybuk> actually, let's not call it sick
[01:46] <Keybuk> let's call it "preserving existing behaviour"
[01:46] <cjwatson> Keybuk: unfortunately CDs get DEVTYPE=disk too
[01:46] <Keybuk> sure, they're disks
[01:47] <cjwatson> still, we need to be able to tell them apart
[01:47] <Keybuk> I think ID_CDROM is still there
[01:47] <Keybuk> how about I add this udev rule somewhere
[01:47] <cjwatson> is that likely to keep on working? :-P
[01:47] <cjwatson> I'm happy to add DEVTYPE checking as a fallback if ID_TYPE (which seems more precise when available) isn't there
[01:47] <Keybuk> ENV{ID_TYPE}!="?*", ENV{DEVTYPE}=="?*", ENV{ID_TYPE}="$env{DEVTYPE}"
[01:48] <Keybuk> that would cover other cases we haven't found yet
[01:48] <Keybuk> there's bound to more than d-i's list-devices relying on this
[01:48] <cjwatson> mm, that sounds reasonable
[01:48] <Keybuk> and we can figure out how to update it later
[01:49] <cjwatson> although d-i's list-devices was expecting ID_TYPE=disk for partitions, since that's what was there before
[01:49] <cjwatson> so ideally, emulate that
[01:49] <Keybuk> really?!
[01:49] <cjwatson> yes, it was describing the physical device not the block device I think
[01:49] <Keybuk> hmm
[01:49] <Keybuk> that's a tricky rule
[01:50] <cjwatson> and you can still see that if you're on a device that supports the right ioctls
[01:50] <Keybuk> it would end up saying that any block device is a disk
[01:50] <cjwatson> $ udevadm info -q env -p /block/sda/sda1 | grep ^ID_TYPE=
[01:50] <cjwatson> ID_TYPE=disk
[01:50] <cjwatson> only if there wasn't some other ID_TYPE
[01:50] <Keybuk> meh. it'll do for now ;)
[01:51] <cjwatson> let me know if it's going to be ID_TYPE=partition because I'll need to account for that
[01:51] <cjwatson> as will anything else using the udevdb for this
[01:53] <Keybuk> SUBSYSTEM=="block", ENV{ID_TYPE}!="?*", KERNEL=="hd*[0-9]|sd*[!0-9]|sd*[0-9]|sr*", ENV{ID_TYPE}="disk"
[01:53] <Keybuk> something like that maybe?
[01:54] <Keybuk> after that
[01:54] <Keybuk> # list-devices disk
[01:54] <Keybuk> /dev/sda
[01:54] <Keybuk> /dev/scd0
[01:54] <Keybuk> # list-devices partition
[01:54] <Keybuk> /dev/sda1
[01:54] <Keybuk> /dev/sda2
[01:54] <Keybuk> /dev/sda5
[01:54] <Keybuk> --
[01:54] <Keybuk> is that right?
[01:56] <Keybuk> it lists the cdrom, did it used to do that?
[01:56] <Keybuk> cjwatson: ^
[01:57] <cjwatson> I don't think so
[01:57] <Keybuk> list-devices cd still says /dev/scd0
[01:57] <cjwatson> let me check though
[01:57] <Keybuk> cdrom_id may have had ID_TYPE=cdrom and that's been dropped too
[01:57] <cjwatson> err, somebody who actually has a hardy CD handy would be faster ...
[01:58] <Keybuk> hmm, I don't have a hardy install with a CD-ROM
[01:58] <Keybuk> how strange
[01:58] <StevenK> cjwatson: I have a Hardy Live CD handy-ish
[01:58] <cjwatson> ata_id said ID_TYPE=cd, and that doesn't seem to have changed
[01:58] <cjwatson> scsi_id might have stopped saying so
[01:59] <cjwatson> cdrom_id didn't output ID_TYPE=anything in hardy
[01:59] <Keybuk> right
[01:59] <Keybuk> ata_id doesn't get called
[02:03] <Keybuk> I have 7.10 handy
[02:03] <cjwatson> maybe just KERNEL=="sr*", ENV{ID_TYPE}="cd" for compat
[02:03] <cjwatson> (obviously with the other conditions)
[02:04] <TheMuso> /c/c
[02:04] <Keybuk> hmm
[02:04] <Keybuk> yeah it had ID_TYPE=cd before
[02:08] <Keybuk> ok that seems to work
[02:08] <Keybuk> SUBSYSTEM=="block", ENV{ID_TYPE}!="?*", KERNEL=="hd*[0-9]|sd*[!0-9]|sd*[0-9]", ENV{ID_TYPE}="disk"
[02:08] <Keybuk> SUBSYSTEM=="block", ENV{ID_TYPE}!="?*", KERNEL=="sr[0-9]*", ENV{ID_TYPE}="cd"
[02:08] <Keybuk> as 65-id-type.rules
[02:08] <Keybuk> list-devices shows /dev/scd0 for "cd", /dev/sda for "disk" and /dev/sda[125] for "partition"
[02:11] <cjwatson> Keybuk: that sounds good
[02:12] <Keybuk> http://people.ubuntu.com/~scott/udev_124-7.debdiff
[02:12] <Keybuk> mind a quick review?
[02:12] <cjwatson> (can we get this bug targeted and milestoned and such?)
[02:13] <cjwatson> sd*[!0-9]|sd*[0-9] isn't that equivalent to sd?*
[02:13] <Keybuk> just done that
[02:13] <cjwatson> ?
[02:13] <Keybuk> was typing a comment
[02:14] <Keybuk> cjwatson: I was replicating the exact condition from persistent-storage.rules
[02:14] <cjwatson> how about cciss?
[02:15] <cjwatson> since it's in persistent-storage.rules :)
[02:15] <Keybuk> I don't know that those are :p
[02:15] <Keybuk> are they disks or cd-drives, or something else?
[02:16] <calc> Keybuk: should the bug be attached to the kernel also for that driver to be updated?
[02:16] <Keybuk> calc: I find such bugs somewhat ... pointless
[02:16] <calc> ok
[02:17] <cjwatson> cciss => RAID controller => disks
[02:17] <Keybuk> ok, added
[02:19]  * Keybuk uploads
[02:20] <cjwatson> thanks!
[02:21] <Keybuk> and now, to the bedmobile!
[02:40] <NCommander> hey geser__
[03:00] <slangasek> jdstrand, kirkland: server testing still ongoing?
[03:07] <kirkland> slangasek: yeah
[03:08] <kirkland> slangasek: pam question for you
[03:08] <kirkland> slangasek: specifically unix_chkpwd
[03:09] <kirkland> slangasek: i can get this to work from the command line:
[03:10] <kirkland> slangasek: echo "passwd\0" | /sbin/unix_chkpwd "username" nullok
[03:10] <kirkland> slangasek: that works well, as expected
[03:10] <kirkland> slangasek: as soon as i put that into a script, though, i get rc=7
[03:10] <kirkland> slangasek: is that by design?
[03:10] <kirkland> slangasek: is there a way to work around that?
[03:11] <slangasek> 7 is 'PAM_AUTH_ERR'
[03:11] <slangasek> it is, generally, by design; this script is not meant to be called by anything except pam_unix
[03:11] <slangasek> it's a helper script /for/ pam_unix, not an interface /to/ pam_unix
[03:12] <kirkland> slangasek: hrm
[03:12] <slangasek> as for why it fails, I'd guess that when you put it in a script, it's being run under dash and dash is laughing at you for using \0 ?
[03:12] <kirkland> slangasek: i've tried a handful of escapes
[03:13] <slangasek> maybe you want echo -n "passwd" or printf passwd
[03:13] <kirkland> slangasek: k
[03:15] <sbeattie> Riddell: I commented on the adept bug for hardy-proposed
[03:48] <kirkland> slangasek: server raid installs look good
[03:52] <slangasek> kirkland: good-o - are you going through the test cases on http://iso.qa.ubuntu.com/qatracker/test/2104 or http://iso.qa.ubuntu.com/qatracker/test/2105 ?
[03:56] <kirkland> slangasek: i'm testing more interesting raid setups than that ;-)
[03:56] <slangasek> well, we kinda need to be sure that the standard tests are also covered
[03:56] <kirkland> slangasek: sure, i'll do those too
[03:56] <slangasek> there /shouldn't/ be anything that's changed in the last reroll that would affect them, but still
[03:56] <superm1> slangasek, are there some known issues with the alternates hanging in the middle of package installs in virtualbox?  i can still switch VTs in the VM, but it's just sitting there not doing anything for 25+ minutes on bash-completion
[03:56] <kirkland> slangasek: i'm on amd64
[03:57] <slangasek> superm1: sorry, I haven't heard of anything like that
[03:57] <superm1> slangasek, okay let me see if this hardware supports kvm, and i'll try that instead
[03:57] <ScottK> Wasn't Riddell mentioning some long hangs.
[03:57] <ScottK> I think he uses amd64
[03:58] <superm1> this was i386
[03:58] <ScottK> Ah.
[03:58] <ScottK> Mixed my lines on the scroll
[04:17] <slangasek> the long hangs were with DVDs, not alternates
[04:17] <ScottK> Ah.
[04:19] <jdstrand> slangasek: fyi-- all my assigned iso tests passed just fine
[04:23] <jdstrand> dendrobates: ^
[04:24] <dendrobates> jdstrand: good deal.
[04:31] <superm1> slangasek, what was decided about those long DVD hangs?
[04:35] <kirkland> dendrobates: my iso testing was fine too
[04:35] <dendrobates> kirkland: also good.
[04:38] <kirkland> slangasek: do you have time to sponsor an ecryptfs upload, fixes two bugs?
[04:39] <persia> kirkland, That requires respin of *all* the CDs.  Can it wait until post-RC?
[04:39] <persia> (and DVDs and USB images)
[04:39] <kirkland> persia: post-RC is fine
[04:39] <ScottK> persia: Accepting requires that, not uploading.
[04:39] <kirkland> pre-ga
[04:39] <persia> ScottK, Good point.
[04:39] <kirkland> upload can wait for tomorrow then
[04:40]  * persia was fearful of another repeat, having spent the past 24 hours chasing image rebuilds as much as anything else.
[04:45] <superm1> slangasek, okay alternates look good for mythbuntu.  looks like Virtualbox just hates me, but kvm likes me
[04:52] <calc> hmm some tests still not run on kubuntu/ubuntu (/me gets back to working on them)
[04:57]  * calc hopes we get 2.6.29 with ext4 install support in jaunty
[04:57] <wgrant> calc: We have ext4dev in Intrepid.
[04:58] <calc> wgrant: yea it went out of dev status a few weeks ago and will be in 2.6.28 as regular fs
[04:58] <calc> wgrant: can we install using ext4dev in intrepid already?
[04:58] <wgrant> I don't think so.
[04:59]  * calc read that 2.6.28 will need a lot of already existing stablization patches for ext4 to be ready to be used
[04:59] <calc> so maybe by 2.6.29 it will have shaken out enough to be usable
[05:06]  * TheMuso is not sure he will go near it for a few kernel releases. Let those who are willing to risk their data try it first. :p
[05:06] <Hobbsee> evand: you around?
[05:08] <calc> TheMuso: heh :)
[05:08] <calc> TheMuso: i should have done that for XFS
[05:09] <TheMuso> When I heard that one couldn't use XFS accross  32-bit and 64-bit install, I decided never to touch it.
[05:09] <calc> if i read correctly both opensuse and fedora's next releases will support it, not sure if they will default to it or not
[05:09] <calc> TheMuso: oh ugh
[05:09] <ScottK> calc: Ugh is TheMuso's line.
[05:09] <calc> TheMuso: didn't know about that, when i used it was well before amd64 arch was released
[05:09] <TheMuso> calc: That was a year ago or so, but things may have changed.
[05:10] <TheMuso> ScottK: har har har.
[05:10] <ScottK> Actually not for a long time that I've seen though.
[05:10] <ajmitch> TheMuso: issues like that scare me
[05:11] <TheMuso> ajmitch: me too.
[05:11] <TheMuso> Hense staying away from XFS.
[05:12]  * persia likes to use the oldest filesystem supported by Mr. Tso.  It's always fairly reliable, if perhaps not fast or featureful.
[05:13]  * ScottK recently had to unbork a ReiserFS system that was set up long enough ago that was a reasonable choice.
[05:13] <ScottK> That was 'fun'.
[05:13] <sbeattie> persia: you and me both. I prefer to keep my data in exchange for giving up whatever 5-10% performance gain the others may offer (having seen several ex-coworkers lose data thanks to reiserfs)
[05:14] <persia> sbeattie, Note however that we probably play just as much catchup as anyone else.  I suspect there's a lot of data we'll both want to move off ext2 soon enough.
[05:14] <persia> (and from what I understand, my latest disk doesn't behave like the old ext2 versions anyway)
[05:16] <Hobbsee> evand: added to the bug, enjoy :)
[05:22] <TheMuso> I got burnt by reiserfs early on, have never touched it again.
[05:41]  * NCommander uses ext3 and jfs
[06:18] <dholbach> good morning
[06:19] <dholbach> can somebody accept the ubuntu-docs, example-content, vino and gnome-applets uploads from yesterday? :)
[06:20] <dholbach> errr, vinagre
[06:20] <dholbach> instead of vino
[06:21] <persia> dholbach, CDs haven't been pushed to release yet.
[06:21] <persia> s/release/releases/
[06:23] <slangasek> superm1: the long DVD hangs were really just ubiquity having to calculate a very large list of files for its "do I copy this part of the fs or not" handling, AFAIK; can probably be optimized better, but otherwise not a bug per se
[06:24] <slangasek> kirkland: not until Friday, frankly
[06:24] <slangasek> superm1: glad to hear the alternates check out
[06:24] <slangasek> (also, glad to now have this info on the iso tracker :)
[06:25] <slangasek> dholbach: certainly not, not until RC is released
[06:25] <TheMuso> slangasek: studio all done, at least from my perspective.
[06:26] <slangasek> good, good
[06:26] <slangasek> gah, why is the iso tracker not loading for me
[06:26] <TheMuso> its slowhere too.
[06:26] <TheMuso> here
[06:34] <lool> morning
[07:20] <slangasek> kirkland, jdstrand, dendrobates: I see zero test results for server i386 following that last respin...
[07:26] <Koon> slangasek: I'm on it
[07:26] <slangasek> Koon: excellent, thank you
[07:27] <Koon> slangasek: won't be able to do all tests though, anything special that might have changed since yesterday ?
[07:28] <slangasek> Koon: nothing that should have affected any of the test cases
[07:28] <slangasek> but we need re-testing anyway
[07:28] <Koon> sure
[07:38] <slangasek> saivann: why is bug #285323 "triaged"?  that implies that a developer has all the information needed to fix the bug, but if that refers to yourself, why did you need another person to confirm it before marking it 'triaged'/
[07:41] <pitti> Good morning
[07:41] <StevenK> Morning pitti
[07:42] <geser> Hi pitti, StevenK
[07:43] <pitti> james_w: that's the question I asked myself; I'd really like to see it in the final, so that the live CD works as well, but I'm not sure how many other people tested it
[07:43] <pitti> james_w: however, I really gave it a good beating (stresstest script, VTs, several Xes, etc.) and it works really well
[07:44] <pitti> sbeattie: oh, it affects all setuid programs, not just sudo? I have to look; there are probably not many you'd want guest to run, though
[07:47] <sbeattie> pitti: that's my guess, but I haven't verified.
[07:49] <sbeattie> pitti: I may be mis-guessing as to what it affects; I'm verifying now.
[07:57] <sbeattie> pitti: sorry, you're correct. It must be the post-auth setuid() call that's failing, not the ability to start the program. That seems like a legit rejection then, even if sudo doesn't explain it very well.
[07:57] <pitti> sbeattie: yeah, I guess the output isn't very nice
[07:57] <sbeattie> pitti: I think the ideal solution would be for the default configuration of sudo to not allow the guest user to run sudo.,
[07:58] <pitti> sbeattie: you mean add that to the apparmor profile?
[07:58] <pitti> sbeattie: that's tricky, currently apparmor doesn't allow "set substraction"
[07:58] <sbeattie> pitti: no
[07:58] <pitti> I. e. it can't say /usr/bin/* but not /usr/bin/sudo
[08:00] <sbeattie> pitti: actually, with deny rules, which should be intrepid, you should be able to say exactly that.
[08:00] <sbeattie> should be in intrepid's apparmor, that is.
[08:00] <pitti> sbeattie: hm, it's not in man apparmor.d then
[08:00] <sbeattie> (but I *highly* doubt it's very well tested at all)
[08:01] <sbeattie> pitti: shocking! (or not)
[08:01] <pitti> sbeattie: indeed I wish there was an access mode "none'
[08:01] <pitti> so that I could write
[08:01] <pitti>   /usr/bin/* rmix,
[08:01] <pitti>   /usr/bin/sudo none,
[08:02] <pitti> that worked in grsecurity, but I haven't found a way to model it in apparmor
[08:02] <pitti> in grsecurity, then user would then not even "see" sudo
[08:02] <sbeattie> pitti: http://developer.novell.com/wiki/index.php/Apparmor_2_3#Deny_rules
[08:03] <pitti> sbeattie: nice!
[08:04] <sbeattie> pitti: the initial approach I was thinking of, and is probably a much safer last minute change, would be to deny in sudoers the guest user the ability to do anything in sudo.
[08:04] <sbeattie> or, honestly, this could wait for an SRU.
[08:04] <pitti> sbeattie: it's just a cosmetical thing anyway, I guess
[08:05] <sbeattie> yeah
[08:05] <pitti> sbeattie: however, sudoers is already configured to not allow anything for guest
[08:06] <pitti> sbeattie: at least it says "operation not permitted"
[08:07] <pitti> it could say "stomp yourself at your foot, a measly guest user does not have such powah"
[08:07] <pitti> sbeattie: I'm a bit scared about adding guest to the default sudoers
[08:07] <tkamppeter> pitti, hi
[08:07] <pitti> it wouldn't work for upgrades anyway, and the guest user is only temporary, and folks might already have a real guest user
[08:07] <pitti> hi tkamppeter
[08:08] <tkamppeter> pitti, I did a tiny bug fix on foomatic-filters, see http://pastebin.ubuntu.com/61399/
[08:08] <tkamppeter> Would you take it into Intrepid when I upload it?
[08:08] <pitti> tkamppeter: no, that should become an SRU
[08:09] <tkamppeter> pitti, OK. I only wanted to ask.
[08:09] <pitti> tkamppeter: can you please open an Ubuntu bug about it and subscribe ubuntu-sru? we can already upload it to intrepid-proposed, but it won't be accepted until after the release
[08:09] <pitti> tkamppeter: sorry
[08:11] <tkamppeter> It is also not that much important, I only asked because it was an obvious one-liner. With the PDF workflow this code does perhaps even not get touched.
[08:12] <tkamppeter> pitti, so I will upload Foomatic 4.0 final into Jaunty as soon as I have released it upstream.
[08:13] <sbeattie> pitti: okay, you're correct, even if you allow the guest-session apparmor profile what it needs and set a passwd for guest, sudo claims the guest user isn't in sudoers and so doesn't let it do anything.
[08:14]  * sbeattie shuts up about it now.
[09:01] <torkel> pitti: do you have any plans of updating your v4l-dvb-dkms ppa package? Mostly for a newer v4l-dvb snapshot, but also add it to Intrepid?
[09:01] <pitti> torkel: not right now; from my side it was pretty much just an experiment
[09:02] <pitti> in hardy it's utterly hard to get it truly right, becaue of the separate linux-ubuntu-modules headers
[09:02] <pitti> I tried for an hour or two and gave up
[09:03] <pitti> and intrepid's kernel is fairly recent, so many cards work OOTB now
[09:03] <pitti> torkel: want to adopt it? :-)
[09:03] <torkel> pitti: not af9015 based cards :-(
[09:03] <pitti> so with intrepid supporting my card OOTB I have nothing to test with, and no real incentive either any more, I guess
[09:05] <torkel> pitti: well. I can take a look at it, but I can't promise anything, and I really don't have the time adopt it fulltime :-)
[09:06] <pitti> torkel: for intrepid maintenance should actually be easy; git pull, run script, test, done
[09:06] <pitti> torkel: it would be much more intersting for hardy, if anyone could ever figure out how the heck to build kmods properly against linux and lum
[09:06] <pitti> torkel: erm, s/git/hg/ :)
[09:08] <torkel> everything needed are in your ppa package? Execpt for the v4l-dvb source?
[09:11] <pitti> torkel: I'm not sure whether it includes the make-dkms.sh script
[09:12] <pitti> torkel: if not, I just put it at http://people.ubuntu.com/~pitti/scripts/make-v4l-dkms.sh
[09:12] <pitti> torkel: that builds a dkms.conf from the checked out hg tree
[09:13] <torkel> pitti: thanks a lot. Now I have something to do on my vacation next week :-)
[09:13] <pitti> torkel: hehe
[09:24] <pitti> doko: the remaining rdepends of gcc-4.1 are linux-ports and klibc; I guess that won't change for intrepid, so would you mind if I promote g++-4.1 libmudflap0-dev libstdc++6-4.1-dev? they are pulled in with recommends
[09:27] <doko> pitti: please keep the old c++ out of main, if possible. it's really not needed.
[09:27] <pitti> doko: then we need to upload gcc-4.1 to drop the recommends
[09:27] <doko> have to see why it is pulled in
[09:29] <pitti> doko: gcc-4.1 recommends libmudflap0-dev, libstdc++6-4.1-dbg recommends libstdc++6-4.1-dev
[09:29] <doko> pitti: the latter should be fixed in the seeds
[09:30] <doko> I'll drop the first one to a suggests
[09:30] <pitti> yeah, we can demote libstdc++6-4.1-dbg easily
[09:33] <pitti> doko: ^ done
[09:33] <doko> thanks
[09:33] <pitti> hm, so what pulls in g++-4.1
[09:33] <pitti> ah, libstdc++6-4.1-dev depends on it
[09:34] <pitti> so that should be fixed with the demotion
[09:34] <pitti> doko: is libmudflap0-dev in main really bad enough to warrant a gcc-4.1 upload at this stage?
[09:35] <doko> pitti: I would like to keep it outside.
[09:49] <cjwatson> calc: if it's out of development status, we should certainly be able to support ext4 in jaunty
[09:55] <directhex> cjwatson, is it backward-compatible? and still ass-slow at deletes?
[09:55] <cjwatson> how should I know? :)
[09:57] <directhex> you're smart!
[10:00] <cjwatson> also busy
[10:00] <cjwatson> so I don't tend to do much in the way of random filesystem exploration when it isn't something I need to do
[10:05] <pitti> calc: do you know openoffice.org-emailmerge? It's recommended by -writer, so either we need to drop the recommends, or promote -emailmerge to main and thus install it by defautl
[10:06] <pitti> calc: the latter would avoid another OO.o upload, but is of course subject to feature freeze
[10:06] <pitti> calc: do you know aobut the status/sanity of this package?
[10:19] <davmor2> tseliot: did you and Riddell get to the bottom of the jockey-kde issue?
[10:19] <pitti> davmor2: iz kdesudo weirdness; I uploaded a package which fixes the desktop file (thanks to tseliot), so it should be good after RC
[10:19] <tseliot> davmor2: ^^
[10:20] <davmor2> pitti: okay cool.
[10:21] <pitti> doko: can you please look at the line with "gcc-4.3" on http://people.ubuntu.com/~ubuntu-archive/component-mismatches.txt ?
[10:23] <pitti> Riddell: ./kubuntu.intrepid/desktop: * (gnupg-agent) # for SMIME e-mail support
[10:24] <pitti> Riddell: nothing depends on gnupg2 or gpgsm, and nothing else rdepends on gnupg-agent; is that still actually relevant?
[10:26] <doko> pitti: this is expected. these are powerpc and hppa things. I'll seed gcc-4.3-locales gfortran-4.3-multilib libstdc++6-4.3-pic
[10:26] <pitti> doko: ah, ok; right, c-m has quite a bunch of ia64/linux-ports bits I'm just going to ignore
[10:26] <pitti> but at least some of those look releavant
[10:27] <pitti> doko: you seed them to supported-development in ubuntu.platform?
[10:29] <doko> pitti: ?
[10:30] <doko> new section in development?
[10:30] <pitti> doko: <doko> I'll seed gcc-4.3-locales [...]
[10:30] <pitti> doko: platform.intrepid has a "supported-development" component
[10:30] <pitti> seems like a good fit to me?
[10:31] <pitti> doko: gcc-4.3-locales should probably go to universe, though
[10:31] <pitti> doko: since it's empty (stripped and shipped in langpacks)
[10:34] <pitti> cjwatson: do you happen to know about linux-firmware? it also builds nic-firmware, scsi-firmware, which aren't seeded/depended on by anything
[10:34] <cjwatson> I'll seed those, d-i uses them
[10:35] <pitti> cjwatson: oh, seems they are actually udebs without being named "-udeb"?
[10:35] <Riddell> pitti: ScottK tends to know best about that
[10:35] <pitti> Riddell: okay, thanks
[10:35] <cjwatson> pitti: that isn't a universal naming scheme, by far
[10:35] <cjwatson> most of d-i's core udebs aren't -udeb
[10:36] <pitti> ScottK: nothing depends on gnupg2 or gpgsm, and nothing else rdepends on gnupg-agent; is that still actually relevant?
[10:36] <pitti> ScottK: ./kubuntu.intrepid/desktop: * (gnupg-agent) # for SMIME e-mail support
[10:36] <cjwatson> -udeb is mostly for when we want a .udeb equivalent of something that's already a .deb
[10:36] <pitti> cjwatson: ah, ok; thanks
[10:50] <amitk> should this command work?  apt-get source gtk-vnc=0.3.6-2ubuntu2
[10:50] <pitti> amitk: no, because that version doesn't exist anywhere
[10:51] <pitti> amitk: well, you can dig out old versions from Launchpad, but they aren't indexed in Sources.gz
[10:52] <directhex> pitti, gnupg-agent is evil.
[10:52] <amitk> pitti: 0.3.4-0ubuntu exists, but apt-get source doesn't work for that version either http://www.nic.funet.fi/pub/mirrors/archive.ubuntu.com/pool/main/g/gtk-vnc/python-gtk-vnc_0.3.4-0ubuntu2_amd64.deb
[10:53] <amitk> or am i going about this all wrong? How do I get a source-controlled tree so I can revert to a specific version?
[10:54] <directhex> pitti, ( http://bugs.debian.org/499569 )
[10:54] <pitti> amitk: that's the hardy version; so if you have deb-src for hardy main in your apt sources, it should work
[10:56] <pitti> directhex: oh, seems we should sync that then, perhaps?
[10:56] <directhex> pitti, i would. it would fix f-spot hanging for at least some users. but i didn't get enough confirmations that it did the right thing to push for it
[10:57] <liw> someone's made an icon for system-cleaner, http://launchpadlibrarian.net/18814154/C%3A%5CDocuments%20and%20Settings%5Cmarcorodrigues%5CAmbiente%20de%20trabalho%5Cicon_sc%5Csc_ico_24x24.png -- what license should I ask him to use?
[10:58] <pitti> liw: cute!
[10:58] <pitti> liw: well, any free license is good really, but ideally GPL or at least CC-BY-SA
[10:58] <directhex> liw, WTFPL
[10:59] <directhex> dfsg-free and simple for anyone to understand
[10:59] <cjwatson> liw: the same licence as the application
[11:00] <cjwatson> (would be my preference)
[11:00] <liw> cjwatson, yeah, mine too
[11:00]  * liw points at Kmos :)
[11:02] <persia> liw?
[11:04] <mvo> liw: that is nice
[11:04] <liw> (Kmos made the icon)
[11:12] <persia> Oh, excellent!
[11:19] <pitti> seb128: I'm uploading file-roller with the p7zip recommends dropped to suggests (we have never installed it anyway by default); I think everything else is too late now
[11:20] <seb128> pitti: we didn't? we should ... but right if that's late for intrepid
[11:20] <pitti> seb128: yeah, something to consider for jaunty indeed
[11:20] <pitti> seb128: but it's fairly big, in universe, and not really tested
[11:20] <seb128> ok
[11:24] <juliux> mdz: ogra gaves me a hint that you are working on the brigthness keys on ibm thinkpad, i have a x41 tablet and the keys are not working properly atm, if i press a the key it takes a long long time after there is a reaction, if i should test anythin give me a ping;)
[11:27] <mdz> juliux: I fixed a problem where they didn't work at all.  it's known that they work slowly on some models, but I have not investigated the reason for that
[11:28] <mdz> juliux: if you find the relevant bug report, let me know as I do have a system which exhibits this behaviour
[11:28] <StevenK> They work fine on my X40 if that's a useful data point
[11:30] <mdz> StevenK: hardware or software controlled?
[11:30] <mdz> this seems to affect the software-controlled ones
[11:31] <mdz> there's about a 1-second delay for me
[11:31] <StevenK> mdz: I'm guessing it's hardware, but how do I check?
[11:32] <mdz> StevenK: lshal |grep brightness
[11:33] <mdz> StevenK: and if it works even when acpid/hal/etc. aren't running
[11:34] <StevenK> mdz: They work even if the machine is in the middle of booting
[11:34] <mdz> StevenK: hardware
[11:34] <mdz> (firmware, but who's counting)
[11:36] <cjwatson> asac: could you join #ubuntu-release?
[11:37] <ScottK> pitti: Yes.  To make S/MIME and GPG signing work in Kmail you need gnupg-agent (which was a spec'ed capability starting with Gutsy).  If it's not in the Kmail depends/recommends, it should be.  Please leave it seeded.
[11:37] <pitti> ScottK: okay, sure
[11:37] <pitti> ScottK: so we should probably fix debian bug 499569 then, since it's isntalled by default in Kubuntu?
[11:37] <pitti> ScottK: i. e. sync, or backport the fix
[11:41] <ScottK> pitti: Yes.  I agree we want that fix.
[11:41] <ScottK> Urgh.
[11:41] <directhex> yay
[11:44] <asac> cjwatson: sure
[11:44] <pitti> ScottK: can I leave investigation to you or another delegate? I'm still 120% busy with component-mismatches and an urgent kernel bug
[11:45] <ScottK> pitti: Yes.
[11:45] <pitti> ScottK: cheers
[12:06] <J_P> hi all
[12:07] <J_P> ubuntu 8.10 will be released with OpenOffice3 ?
[12:07] <Hobbsee> J_P: no
[12:08] <J_P> :-(
[12:11] <pitti> doko: do you happen to know about libdv? it currently recommends oss-compat, which seems pretty crackful to me
[12:11] <pitti> doko: I'm currently preparing an upload which drops that recommends, but I'd like to get a second opinion
[12:14] <doko> pitti: no, just touched that for some build problem
[12:14] <pitti> doko: ok, nevermind then
[12:18] <seb128> persia: any news about the glibmm2.4 update?
[12:20] <persia> seb128, No feedback at all.  Sorry.  Please don't let that hold you up : if you could mention "Thanks to Mitsuya Shibata" in the changelog, that'd be great : he's not worried about changelog credits.
[12:20] <persia> (at least based on several other conversations about other packages)
[12:21] <seb128> persia: ok
[12:21] <persia> Err.  s/changelog credits/Changed-By: credits/
[12:25]  * ogra wonders if he's the only one seeing broken focus handling since a while 
[12:25] <ogra> i see no bug about it on any of the lists
[12:26] <pitti> ogra: compiz behaves badly when switchign virtual desktops; it otherwise works quite fine, WDYM?
[12:27] <ogra> pitti, atl tab often leaves the focus in the former window for me
[12:27] <ogra> i.e. o often type IRC text into the firefox url bar recently though having the xchat win in front of me
[12:29] <kwwii> liw: http://sinecera.de/wiper24.png --> how about that? the vacuum cleaner looked like a little blob at 24x24
[12:30] <ogra> whom do you want to crucify on that  ?
[12:31] <pitti> a razor?
[12:31] <cjwatson> last I checked a cross had a bit at the top as well ;)
[12:31]  * persia likes http://launchpadlibrarian.net/18814154/C%3A%5CDocuments%20and%20Settings%5Cmarcorodrigues%5CAmbiente%20de%20trabalho%5Cicon_sc%5Csc_ico_24x24.png : still good at 24x24, and harder to confuse with the letter T
[12:34] <kwwii> it's supposed to be a squeegee :p
[12:35] <ogra> probably put a baloon with "SQEEEEK !" on it ? :)
[12:35] <persia> At 24x24, that's flyspeck 3, which isn't very legible.
[12:37] <ogra> heh
[12:38] <ogra> how about a looking glass ....
[12:38] <ogra> ... shipped with the CDs
[12:38] <ogra> ;)
[12:38] <kwwii> as an interesting side-point you should see the other definition of squeegee (spelled squeegie)...nasty though, be warned
[12:39] <persia> !ohmy
[12:39] <persia> :p
[12:39] <kwwii> I thought about a little housewife in apron, talking on the phone with a duster in one and and a vacuum in another but somehow that didn't work at 24x24 pixels :p
[12:39] <kwwii> perhaps if she was also dancing a jig it would be clearer
[12:42] <StevenK> kwwii: "Why doesn't System Cleaner also cook?"
[12:42] <ogra> that brings up the question about her secret boyfriend on the other end of the phone as well ..
[12:44] <persia> Ummmm ...
[12:44] <kwwii> StevenK: hehe, don't get sexist on me
[13:28] <mathiaz> pitti: server i386 testing completed
[13:28] <mathiaz> pitti: esx is the only one missing and I don't have access to an ESX environment.
[13:29] <mathiaz> pitti: so I think we're good to go with -server
[13:35] <pitti> mathiaz: rock, thanks
[13:42] <ScottK> pitti: On the gnupg-agent bug, it doesn't seem to be reproducable in Intrepid Kubuntu.  If you have a moment to ponder, would we be better off to take the fix 'just in case' or leave it be I wonder?
[13:42] <elmo> how do I get the full range of mixer options back? :(
[13:43] <pitti> ScottK: if it isn't OMGbreakseverything, we should leave it for an SRU
[13:43] <ScottK> pitti: OK.  Thanks.
[13:43] <directhex> ScottK, did you log out/in after installing gnupg-agent? and you're definitely on i386?
[13:43] <ScottK> directhex: I didn't do the test.  I'll double check.
[13:44]  * ScottK has been getting kids out the door to school.
[13:44] <directhex> pfft kids. sounds like effort
[13:44] <ScottK> directhex: Did you try to reproduce it?
[13:44] <ScottK> directhex: Definitely.
[13:47] <directhex> ScottK, not recently. i'll try and find the time this afternoon, but by the time I have a VM installed...
[13:48] <ScottK> directhex: You've seen it in the past though?
[13:48] <calc> pitti: emailmerge package allows for being able to send emails via mail merge so yea its useful to have in main
[13:48] <directhex> ScottK, the sigblk problem? yes. on upgrade installs only though, due to gnupg-agent being left behind from an old release
[13:48] <calc> pitti: iirc it used to be in writer directly
[13:49] <ScottK> directhex: Not a lot we can do about that in Intrepid then.
[13:50] <directhex> ScottK, well, if they upgrade to intrepid and get a non-buggy gnupg-agent, issues go away, no?
[13:50] <directhex> brb, catching a bus
[13:50] <ScottK> Yes.  The real question is is the Intrepid one non-buggy
[13:53] <pitti> calc: could you install it and do some testing whether it works properly? If we promote it now, it'll land on the final CDs, so we should better make sure it works
[13:57] <calc> pitti: afaik it was on hardy cd as well but as part of -writer
[13:57] <calc> pitti: i have it installed i will see if i can send out a merged document with it
[13:57] <pitti> calc: thanks
[14:02] <tseliot> persia: I have fixed this bug and provided upstream with a patch: https://bugs.launchpad.net/abiword/+bug/284857
[14:04] <tseliot> pitti: would a debdiff be ok for this bug? ^^
[14:04] <persia> tseliot, Thanks for that.  I can't upload abiword, so you'll need to find another sponsor.
[14:05] <tseliot> persia: ok, no problem ;)
[14:05] <pitti> tseliot: absolutely, although it sounds like an SRU
[14:05] <persia> tseliot, Looking at your patch, I no longer pretend to understand why it works in Xubuntu and not in Ubuntu.
[14:06] <tseliot> pitti: SRU or FFE?
[14:06] <pitti> tseliot: FF? I thought it's a bug fix?
[14:06] <tseliot> persia: I have no idea
[14:06] <tseliot> a bugfix
[14:07] <tseliot> pitti: a bug fix in Intrepid
[14:07] <tseliot> persia: do you know if the problem affects Hardy too?
[14:07] <pitti> tseliot: so, no FF :) I really meant SRU, unless you can convince slangasek (my feeling is SRU, though)
[14:08] <tseliot> pitti: do you call them SRUs after the RC is released?
[14:09] <pitti> tseliot: lol :)
[14:10] <pitti> tseliot: no, SRU -> after the final
[14:11] <tseliot> pitti: and why did you call it SRU if I can provide a fix now?
[14:11] <pitti> tseliot: just to avoid large uploads/rebuilds after RC
[14:13] <persia> tseliot, No idea.  I only heard about the bug because someone asked for help in #ubuntu-motu.  I pointed them at the Xubuntu devs as the most likely to be interested, and I added the comment to the bug.
[14:13] <tseliot> pitti: do we really want to release Ubuntu with an annoying bug which I fixed with just one line?
[14:13] <tseliot> persia: ok
[14:13] <pitti> tseliot: the patch is probably fine, I'm more scared about misbuilds at this time
[14:14] <pitti> tseliot: see yesterday's libvisual-0.4-plugins debacle
[14:14] <NCommander> persia, what about Xubuntu?
[14:14] <pitti> tseliot: a mere rebuild broke the entire desktop
[14:14] <tseliot> pitti: ouch
[14:15] <NCommander> Thats impressive
[14:15] <persia> NCommander, abiword bug.
[14:15] <tseliot> NCommander: bug 284857
[14:17] <persia> elmo: pavucontrol?
[14:19] <ScottK> pitti: Revised story on gnupg-agent: Bug confirmed on Intrepid by multiple sources.  The bug in the previous upload is also confirmed.  I think we should sync after the RC is out.
[14:19] <pitti> ScottK: previous upload> you mean -2 to -3?
[14:19] <ScottK> Yes
[14:19] <ScottK> It's also a very small fix.
[14:19] <pitti> ok, great
[14:19] <pitti> thanks a lot for testing
[14:20] <ScottK> NCommander: ^^ Thanks for testing.
[14:21] <NCommander> :-)
[14:21] <NCommander> pitti, I think the abiword issue can be fixed via SRU at release
[14:31] <calc> got my passport/visa back today
[14:32] <calc> fedex decided it would be funny to ring the doorbell about 7 times quickly, luckily my son didn't wake up
[14:33] <calc> hmm chinese visa takes a whole page
[14:35] <ArneGoetje> calc: same for any other country's visa. ;)
[14:37] <directhex> nah, cuban visa doesn't
[14:38] <directhex> doesn't get permanently attached to passport either, though
[14:39] <ArneGoetje> directhex: hah... I wonder why... ;)
[14:39] <calc> ArneGoetje: ah ok
[14:39] <calc> directhex: hehe
[14:43] <calc> directhex: if they didn't you probably wind back there in gitmo :\
[14:44] <bryce> calc, where'd you need a visa for?
[14:45] <directhex> calc, yeah, probably. yay for the world police :/
[14:45] <calc> bryce: beijing for ooocon
[14:45] <bryce> ahh
[14:45] <ogra> bryce, his flight to mountainview is probably going via peking :)
[14:48] <ArneGoetje> calc: when you arrive in beijing, only take the red taxis which show the fee on the door. don't listen to the guys at the airport who want to have 400 yuan for a trip to downtown... that's rip off. :)
[14:50] <calc> ArneGoetje: ok
[14:51] <ArneGoetje> calc: 80 ~ 100 yuan is normal for a trip to downtown, depending on where you go.
[14:51] <calc> ok
[14:52] <Keybuk> Riddell: daily -> Install worked for me again
[14:52] <Riddell> Keybuk: from the desktop CD?  ubiquity started?
[14:53] <Keybuk> yup
[14:54] <Riddell> Keybuk: without the desktop starting?  is there any background?
[14:55] <Keybuk> there is no background
[14:55] <Keybuk> if I unmaximise the window, behind is black
[14:55] <Keybuk> but strangely if I maximise and unmaximise again, behind is grey
[14:56] <Riddell> Keybuk: anything in /var/crash ?
[14:56] <Riddell> Keybuk: could you attach /var/log/installer/dm to bug 285626 ?
[14:56] <Keybuk> how do I look in there?
[14:56] <Keybuk> how do I get to a shell?
[14:56] <Riddell> Keybuk: control-alt-F1
[14:57] <Keybuk> oh, duh
[14:57] <Keybuk> sorry, I was trying to find KDE-like Run dialogs :p
[14:59] <Keybuk> Riddell: works if I disable acceleration emulation too
[15:02] <Keybuk> Riddell: attached log to the bug
[15:03] <liw> kwwii, now I have an embarrassment of riches to choose from... I'll ponder, thanks
[15:08] <bryce> kwwii: I really like the new background.
[15:08] <bryce> kwwii: have you gotten much feedback so far?
[15:09] <kwwii> bryce: yes, quite a few people like it :-)
[15:09] <bryce> kwwii: cool
[15:09] <kwwii> liw: well, I think I will keep working on another idea, not so sure I like the squeegee
[15:22] <mib_950n06> join #ubuntu-release
[15:22] <mib_950n06> sorry, ignore that plx
[15:42] <bluefoxicy> o guys
[15:42] <bluefoxicy> I have some little things about Intrepid
[15:42] <bluefoxicy> like, it would have been nice to have OpenOffice.org 3
[15:42] <bluefoxicy> Maybe have the Firefox plug-in in main
[15:43] <bluefoxicy> oh and also
[15:44] <bluefoxicy> damn imageshack
[15:46] <bluefoxicy> http://i33.tinypic.com/33y2i3q.jpg
[15:46] <bluefoxicy> It'd be nice if it didn't spend, oh, 3 minutes saying "Loading hardware drivers" at boot.
[15:47] <bluefoxicy> (3:30 boot time?)
[15:48] <saivann> slangasek : Concerning bug #285323 , this bug has enough information so a developer can take a look at it and start working on a fix (however I can't know if developer has all information needed to fix the bug, but enough to start working on that bug). That's why I marked it as "triaged". The affected hardware, logs and steps to reproduce are clear and confirmed by two person.
[15:48] <jdong> bluefoxicy: the openoffice.org thing is a dead horse at this point...
[15:48] <mib_950n06> that's a long time, have you tried pressing ctrl+alt+f1 to see what it's doing when booting?
[15:48] <ScottK> jdong: Got a moment for a backports policy discussion?
[15:49] <saivann> slangasek : Is "triaged" status a problem here in your opinion?
[15:49] <jdong> ScottK: yeah, I've gotta leave this class in 5min though
[15:49] <ScottK> Should be enough.
[15:49] <jdong> k
[15:49] <ScottK> jdong: Shortly I want to backport clamav 0.94.1 Intrepid -> Hardy.
[15:50] <ScottK> The problem is that avscan upstream has vanished and avscan doesnt' work at all with later than 0.92.
[15:50] <ScottK> jdong: So I'm considering the hack of making the backports clamav conflict with avscan so it doesn't get installed and break it.
[15:50] <ScottK> Or maybe breaks is better (I need to look_
[15:50] <ScottK> )
[15:51] <jdong> ScottK: I was going to sugest that too. either breaks and/or conflicts, whichever makes Update Manager scream less
[15:51] <jdong> ScottK: but I think the idea is reasonable
[15:51] <bluefoxicy> jdong:  Even OpenOffice.org loads faster than Ubuntu now.
[15:51] <ScottK> jdong: If an rdepend can't be fixed up to work with the new version, it seems better than not doing the backport.
[15:51] <jdong> bluefoxicy: yeah you've got some weird bug going on there in your bootup sequences
[15:51] <ScottK> jdong: Thanks.
[15:51] <bluefoxicy> jdong:  what should I file, besides a bootchart screen shot?
[15:52] <jdong> ScottK: sure thing. In this case I agree -- better to give the new clamav and drop support for one of the rdepends
[15:52] <ScottK> OK.  Great.
[15:52] <jdong> ScottK: make a note of this in the backport's changelog though
[15:52] <ScottK> Of course.
[15:52] <jdong> cool :)
[15:54] <tseliot> cody-somerville: it looks like a new debdiff for abiword is already available. Let me know if there's something else I can do
[15:54] <cody-somerville> tseliot, you provided the actual patch
[15:54] <cody-somerville> tseliot, so, w00t w00t, thanks :)
[15:55] <tseliot> cody-somerville: thanks to you for the upload ;)
[16:04] <cjwatson> TheMuso: shouldn't bug 287862 be on ubuntustudio-meta rather than ubuntu-meta? also, if it's critical, it needs to be targeted and milestoned
[16:20] <psusi> TheMuso: ping... any chance of getting in a quick fix to dmraid that fixes a regression by disabling an incorrect dpatch before the release?  see bug #287751
[16:21] <cjwatson> psusi: I've targeted that by virtue of it being a regression
[16:21] <cjwatson> TheMuso: please do try to get that one in
[16:22] <cjwatson> (if it makes sense to you obviously)
[16:22] <psusi> k... just need to disable that dpatch is all... not sure why but the target name used to be wrong in the kernel so BenC patched dmraid, and now the kernel has it right, so the patch needs disabled
[16:22] <cjwatson> psusi: are we confused because the module name is still dm-raid4-5, perhaps?
[16:23] <psusi> hrm... maybe....
[16:23] <cjwatson> dm-raid4-5.c:#define    TARGET  "dm-raid45"
[16:23] <cjwatson> lovely
[16:23] <psusi> I just know that when I looked in the kernel sources, it's raid45
[16:23] <cjwatson> yes, it is
[16:28] <BenC> psusi: I seem to remember this coming up early in the release, and I told someone that the kernel was going to remain stock with upstream and userspace needed to be changed to match it
[16:28] <psusi> BenC: it looks like our kernel used to be 4-5, and the upstream dmraid was just 45, you made a dpatch to dmraid to change it to 4-5 to work with our kernel
[16:29] <psusi> now it looks like our kernel is just 45, so the dpatch makes dmaraid fail
[16:48] <BenC> psusi: I never created a dpatch
[16:48] <BenC> psusi: There are no dpatch's in our kernel
[16:48] <psusi> BenC: no, the dpatch is in dmraid
[16:48] <psusi> you changed dmraid to use the target "raid4-5" instead of "raid45"
[16:48] <BenC> psusi: Ok, right, I changed it to match the kernel module
[16:49] <BenC> psusi: because, IMO, the kernel module sets the naming convention, and userspace needs to follow it
[16:49] <psusi> well at last right now though the kernel module uses "raid45"
[16:49] <cjwatson> BenC: the kernel module and the target name are different, though
[16:49] <RainCT> uhm.. why does rosegarden depend on dolphine?
[16:49] <cjwatson> look at .name in dm-raid4-5.c ...
[16:49] <BenC> Ah, ok, then either someone changed the kernel (bad) or that dpatch is obsolete (good, get rid of it)
[16:49] <psusi> yea, for some reason the module is named raid4-5, but the device mapper target it registers is "raid45"
[16:49] <psusi> exactly
[16:50] <cjwatson> let's do the latter, userspace is a hell of a lot easier to change now
[16:50] <BenC> agreed
[16:50] <psusi> yea, just need to remove the dpatch from 00list
[16:57] <radix> hi all, I've nominated a small, upgrade-breaking bug with patch for intrepid: bug #288116
[16:57] <radix> oof, good timing
[16:58] <radix> as I understand it, I need to get a member of the release team to look at it?
[17:06] <cjwatson> radix: approved the nomination, please get a sponsor to upload that ASAP
[17:07] <radix> cjwatson: thank you very much
[17:07] <radix> will do
[17:07] <mathiaz> radix: I'm on it :)
[17:07] <radix> you guys rock :)
[17:08] <mathiaz> radix: do you have bzr branch somehwere?
[17:08] <radix> mathiaz: oh, no, actually I wanted to ask you about that -- the ubuntu-core-dev branch seems out of date
[17:08] <radix> oh wait er
[17:08] <radix> sorry, let me sort my brain out
[17:08] <radix> scratch what I just said. I don't have a branch for this ticket, I can make one if you want
[17:09]  * radix grabs a canned coffee
[18:24] <pitti> anyone knows who is responsible for ubuntustudio?
[18:25] <slangasek> TheMuso, persia, _MMA_
[18:26] <pitti> TheMuso, persia: do you know about this linux-restricted-modules-rt in source NEW? good to accept?
[18:28] <slangasek> saivann: rereading the official bug status descriptions, I guess that status is fine :)
[18:28] <slangasek> saivann: so, ignore me :)
[18:35] <bryce> slangasek: I just got hit by that gnome-terminal ^D crash again
[18:35] <bryce> slangasek: did you find anything out about it?
[18:36]  * bryce installs gnome-terminal 2.24.1-0ubuntu1
[18:37] <bryce> er 0ubuntu2
[18:39] <slangasek> bryce: I haven't had a chance to file a bug, no; I was going to try to reproduce it in a guest session first, to figure out what circumstances it happens in
[18:44] <bryce> slangasek: I'll try running it in gdb and see if I can get a bt
[18:45] <slangasek> bryce: I don't believe it's crashing
[18:45] <slangasek> bryce: I think the damn thing is closing *on purpose*
[18:45] <bryce> hmm
[18:46] <bryce> well it's quite disruptive to one's workflow
[18:46]  * bryce goes to look at gnome-terminal diffs
[18:46] <slangasek> yes, yes it is
[18:47] <soren> ^D closes gnome-terminal? How is that surprising?
[18:47] <soren> Oh, it closes the window rather than the tab, perhaps?
[18:47] <bryce> soren, it closes the entire application
[18:47]  * soren doesn't use gnome-terminal these days
[18:48] <soren> bryce: Oh, so *all* windows even. Yikes.
[18:48] <james_w> does it close all instances of gnome-terminal?
[18:48] <bryce> right
[18:48] <bryce> james_w: yep
[18:48] <james_w> ouch
[18:48] <james_w> I think I saw that a couple of days ago then while making consolekit segfault while run from the terminal
[18:48] <soren> james_w: Under normal circumstances, you only have one gnome-terminal instance even if you have multiple windows.
[18:48] <james_w> ah, ok
[18:52] <pitti> works fine here
[18:53] <pitti> ^D just closes one window
[18:53] <pitti> bryce: so it's likely that it actually is crashin
[18:53] <pitti> g
[18:54] <bryce> pitti: well I've not been able to reproduce the bug intentionally so far
[18:54] <calc> my wife noticed on "The View" today they inserted a bit of the famous 'vote for president johnson' commerical and didn't reference it at all, was fairly pixelated
[18:56] <bryce> looking through the diff, I wonder if it's some g_assert() getting triggered in some unusual condition
[18:56] <bryce> hrm, but that should print something out...
[18:56] <bryce> AHA
[18:56] <bryce> **
[18:56] <bryce> ERROR:terminal-tabs-menu.c:133:free_tab_id: assertion failed: (id >= 0 && id < \
[18:56] <bryce> tabs_id_array->len * 8)
[18:56] <bryce> .xsession-errors ftw
[18:57] <soren> Any package depended on by a package that is Essential: yes ought to be essential itself, shouldn't it?
[18:57] <NCommander> soren, not always
[18:57] <soren> Seems odd.
[18:57] <NCommander> soren, shared libraries must never be essential yes for instance
[18:57] <soren> i would expect that to be a closed set.
[18:57] <soren> NCommander: Hm... Good point.
[18:58] <NCommander> soren, I have those occasionally ;-)
[18:58] <soren> :)
[18:58]  * soren wanders off for a bit
[18:58] <slangasek> soren: the closure is "all packages marked Essential: yes, plus their transitive pre-dependencies"
[18:59] <soren> slangasek: I see. I was just suprised that libpam-modules wasn't essential since base-files depends on it.
[18:59]  * soren really wanders off
[19:00] <slangasek> heh, actually, base-files is buggy for using Depends instead of Pre-Depends
[19:01] <bryce> slangasek: ok I think I see what's going on
[19:02] <bryce> this change occurred:
[19:02] <bryce> -#define ACTION_VERB_FORMAT_PREFIX_LEN   (6) /* strlen (ACTION_VERB_FORMAT_PREFIX) */
[19:02] <bryce> +#define ACTION_VERB_FORMAT_PREFIX_LEN   strlen (ACTION_VERB_FORMAT_PREFIX)
[19:02] <slangasek> well that's pretty opaque, what did that do? :)
[19:02] <bryce> the assert looks like this:
[19:02] <bryce>         id = g_ascii_strtoull (name + ACTION_VERB_FORMAT_PREFIX_LEN, NULL,
[19:02] <bryce>                                ACTION_VERB_FORMAT_BASE);
[19:02] <bryce>         g_assert (id >= 0 && id < tabs_id_array->len * 8);
[19:03] <slangasek> and how long is ACTION_VERB_FORMAT_PREFIX in practice?
[19:03] <bryce> dunno
[19:04] <bryce> oh I do know
[19:04] <bryce>  #define ACTION_VERB_FORMAT_PREFIX       "JmpTab"
[19:04] <bryce> so...
[19:06] <bryce> hmm, actually the error could be with name
[19:07] <bryce> well, at least I can file a sane bug report at this point
[19:10] <bryce> slangasek: ah, already known as bug 286823
[19:10] <slangasek> bryce: escalate, escalate!
[19:10] <slangasek> importance: planet on fire
[19:10] <bryce> slangasek: allegedly already fixed in the latest gnome-terminal
[19:10] <bryce> slangasek: dpkg -l gnome-terminal ?
[19:11] <slangasek> bryce: er, which one is supposed to be the "latest"?  I don't think I even saw the problem until upgrading to 2.24.1-0ubuntu1
[19:11] <slangasek> and I'm pretty sure I haven't accepted anything newer into the archive yet
[19:12] <bryce> that's the latest
[19:12] <slangasek> then the ^D crash is not fixed
[19:12] <bryce> ok
[19:12] <bryce> according to this bug, it's reproduced by opening >10 tabs then closing one.
[19:12]  * bryce tries
[19:12] <slangasek> right, I have > 10 tabs/windows open
[19:12] <pitti> mvo: I'm a bit confused about bug 281363 -- I don't see postgresql anywhere in the log? do you see anythign in the log files which actually points out a problem?
[19:13] <bryce> hmm, nope
[19:16] <slangasek> bryce: is that how you were seeing it before, opening multiple tabs?
[19:16] <bryce> slangasek, do you launch gnome-terminal from .xprofile by chance?
[19:16] <slangasek> no
[19:16] <bryce> slangasek: yeah
[19:16] <bryce> well, it occurs when closing the tabs
[19:16]  * slangasek nods
[19:16] <bryce> well, I've just put 2.24.1-0ubuntu1 on it, so will wait until I've reproduced it on that before reporting it.
[19:17] <bryce> but I suspect it's related to 286823
[20:03] <alex-weej__> is it out of the question to have virtualbox and kvm work at the same time?
[20:04] <alex-weej__> virtualbox works way better for actual desktop OS virtualisation i find because it uses SDL. i can't get SDL to work with QEmu :(
[20:04] <jcole> alex-weej__: the kvm kernel module somehow "locks" the vmx on the cpu
[20:04] <alex-weej__> arse.
[20:06] <jcole> alex-weej: the vbox kernel module does the same thing... perhaps if kvm and vbox decided to write a "sharable" kernel module
[20:08] <alex-weej> ok
[20:08] <vaughn> Quick question, sorry if it's the wrong place...is the 8.10 Release Candidate still on schedule for release today?
[20:09] <alex-weej> only reason i use vbox is for the SDL and USB support
[20:11] <jcole> alex-weej: you can have both the kvm and virtualbox apps installed but you can only run one at a time.. you will need to modprobe/rmmod the kvm/vboxdrv modules as necessary
[20:12] <alex-weej> jcole: already doing that
[20:12] <alex-weej> but thanks anyway
[20:12] <jcole> alex-weej: ok :)
[20:13] <jcole> perhaps someone can answer my question today :)
[20:13] <jcole> im trying to install an ubuntu terminal server for our team with active directory authentication
[20:13] <jcole> someone told me suse integrates better with ad (using yast) and that i should use it instead... is there a way to set it up on ubuntu/debian?
[20:18] <Riddell> mvo: any idea what's up in bug 288267 ?
[20:20] <slangasek> mathiaz: not that we shouldn't fix bug #288218, but: what in the world are "tomcat6 webapps" doing checking the init script's "status" output in a postinst?  The interface for maintainer script / init script interaction is invoke-rc.d...
[20:25] <NCommander> Well, I just got officially cited for XUbuntu
[20:29] <slangasek> by a traffic cop?
[20:33] <hyperair> hi. i'd like to bring attention to bug #284044
[20:33] <hyperair> i think this is a pretty bad regression
[20:34] <ogra> probably a security feature against insecure passphrases ?
[20:34] <hyperair> what dyou mean insecure passphrases?
[20:34] <hyperair> it doesn't accept input!
[20:34] <hyperair> i'm talking about gpg signing and everything that uses the agent
[20:34] <ogra> so you cant type in an insecure one :)
[20:35]  * ogra is joking
[20:35] <hyperair> =.=
[20:39] <jdstrand> slangasek: fyi-- the ecryptfs-utils upload I just did fixes a security issue and should get in before release. IMO it does not need a respin.
[20:39] <jdstrand> kirkland: ^
[20:39] <jdstrand> slangasek: hi btw! :)
[20:40] <slangasek> jdstrand: noted; is there a bug referenced in the changelog, and have you nominated/targeted that bug for intrepid?
[20:40] <jdstrand> slangasek: bug is in the changelog (bug #287908)
[20:41] <jdstrand> slangasek: kirkland nominated it for Intrepid, and I approved it (hope that's ok)
[20:41] <jdstrand> slangasek: I did not milestone it
[20:41] <slangasek> jdstrand: ok, thanks
[20:42] <slangasek> (if you could milestone it too, that would be good)
[20:42] <jdstrand> slangasek: done. thanks
[20:56] <pitti> calc: so are you happy with oo.o-emailmerge?
[20:56] <pitti> slangasek: WDYT about this -emailmerge thing?
[20:57] <slangasek> pitti: as I said earlier, I think that for such a small use case, even leaving the recommends: unsatisfied in main for release would not be beyond the pale
[20:57] <pitti> slangasek: ah, right, I remember; sorry
[20:57] <slangasek> pitti: so if there's concern that pulling it in would be the Wrong Thing, I would be ok with that, even though it leaves our component-mismatches list non-empty
[20:58] <pitti> slangasek: it will be non-empty anyway
[20:58] <slangasek> also, I *don't* want an OOo upload this week :)
[20:58] <pitti> slangasek: neither do I :)
[20:58] <pitti> slangasek: I don't think it's wrong; to the contrary, it was included in -writer in hardy, so not having it would actually be a regression
[20:58] <pitti> slangasek: my concern is just that the change would happen so late in the game
[20:59] <slangasek> ah, this is functionality that was included in -writer before?
[20:59] <pitti> slangasek: (just parrotting calc here)
[20:59] <slangasek> then I'm certainly comfortable with hauling it back in, as long as it fits
[21:00] <pitti> Size: 6612
[21:00] <pitti> slangasek: believe it or not :)
[21:00] <slangasek> right :)
[21:00] <pitti> python-uno is already on the CDs, I checked
[21:01] <pitti> calc: so if you test it and give your thumbs up, we'll promote it
[21:01] <pitti> otherwise we just ignore the recommends
[21:02] <mvo> pitti: I replied in the bug
[21:02] <mvo> Riddell: I replied in the bug
[21:03] <pitti> mvo: so /var/log/apt/term.log != VarLogDistupgradeApttermlog.gz ?
[21:04] <mvo> pitti: right, apt/term.log is the one that is written when apt-get or aptitude are used
[21:04] <mvo> pitti: the other only gets created when the release upgrader runs
[21:04] <mvo> pitti: might be worthwhile to add it to the package hook
[21:04] <mvo> pitti: I think the reported mentioned that he used aptitude when the install failed?
[21:05] <calc> pitti: yea thumbs up from me, it wasn't split out of writer until after hardy was released
[21:05] <pitti> slangasek: ^ ok, then I'll promote it right after RC release?
[21:05] <calc> it doesn't support gmail but i already filed an upstream bug about that
[21:06] <calc> but for people who used to use it pre-intrepid its good to keep it there
[21:06]  * calc sometimes wishes Novell would fork OOo already ;-)
[21:07] <slangasek> pitti: yes, and then we should do some CD rebuilds to confirm everything fits since we have other post-RC package growth
[21:07] <pitti> slangasek: absolutely; maybe we should just enable dailies again?
[21:07] <slangasek> pitti: after RC is published, yes
[21:07] <calc> i think the main reason it was split out was because it is a OOo extension and it made the packaging a bit cleaner
[21:10] <calc> wow bug 264019 looks ugly
[21:13] <slangasek> it's only ugly if you use Verizon
[21:14] <calc> ah ok
[21:14] <calc> so like half the US ;-)
[21:15]  * calc unfortunately doesn't have Verizon... so no FIOS either
[21:19] <slangasek> "unfortunately", eh
[21:19] <slangasek> Verizon are bastards; when I lived in Verizon territory in Beaverton, I went looking for CLECs instead for my Internet
[21:36] <calc> slangasek: well the best i can get here from ATT is 3/0.5
[21:36] <calc> and afaik there aren't really any useful CLECs here
[21:37] <slangasek> calc: you could probably get a quote from Speakeasy?
[21:40] <sharms> cjwatson - how can I change the gfxboot fg color and selected colors?
[21:52] <mathiaz> slangasek: invoke-rc.d is used in the tomcat6-* postinstall script: http://paste.ubuntu.com/61689/
[21:53] <mathiaz> slangasek: you mean that tomcat6 webapps postinstall scripts should not try to reload tomcat6?
[21:54] <slangasek> mathiaz: I mean that they shouldn't call '/etc/init.d/tomcat6 status', which is what I thought was implied by your comment in that bug
[21:54] <calc> slangasek: from what i recall looking at their site it wasn't any better
[21:55] <slangasek> calc: they're "better" than Verizon in the sense that they're not devilspawn; I'm not talking about speed here :)
[21:55] <calc> i could go to comcast and get higher bandwidth but they have caps i think
[21:55] <calc> oh well att is ok just slow
[21:55] <lool> 'night
[21:55]  * slangasek waves to lool 
[21:57] <mathiaz> slangasek: the root of this issue is outlined in bug 274365
[21:57] <mathiaz> slangasek: hm - no - scratch that. It's not related.
[21:58] <mathiaz> radix: do you have branch for bug 288116?
[22:00] <hyperair> could someone take a look at bug #284044 ?
[22:00] <slangasek> superm1: http://mythbuntu.org/8.10/rc is currently empty?
[22:01] <superm1> slangasek, <shrug> let me stab tgm4883.  one sec :)
[22:01] <slangasek> ok :)
[22:07] <mathiaz> slangasek: does that answer your question about tomcat6?
[22:08] <slangasek> mathiaz: hmm, you said "scratch that" - so... no, I guess it doesn't :)
[22:08] <mathiaz> slangasek: hm. scratch that refered to the bug number I gave.
[22:09] <mathiaz> slangasek: my first answer is still correct -the postinst script use invoke-rc.d
[22:09] <slangasek> mathiaz: ok, so the mention of 'status' in that other bug was a red herring?
[22:11] <mathiaz> slangasek: other bug being bug 288218?
[22:11] <slangasek> yes
[22:11] <slangasek> or rather: the mention of maintainer scripts was a red herring
[22:14] <mathiaz> slangasek: hm - not sure I totally understand what you mean. But the maintainer scripts were failing in the tomcat6-* postinstall script because status was always returning 0
[22:15] <slangasek> why does the maintainer script care about status returning 0?
[22:15] <mathiaz> slangasek: thus the postinstall script would proceed to try to restart tomcat6 even it wasn't running
[22:15] <mathiaz> slangasek: it uses the status action to figure if the process is running or not. If the process is running it will try to force-reload it
[22:16] <slangasek> then these postinstall scripts aren't using the policy-defined interface for maintainer script - init script interaction
[22:16] <dvstin> intrepid is shipping with a screwed up pulseaudio configuration, they need to ship with libao-pulse if they are going to include pulseaudio so that sound capture works.. the libao-alsa doesn't work when pulseaudio is running.. how do I get someone to change this for 8.10?? :S (bug #285621)
[22:16] <hyperair> doesn't anybody here use seahorse?
[22:17] <mathiaz> slangasek: so http://paste.ubuntu.com/61689/ is not policy compliant?
[22:18] <seb128> hyperair: why did you subscribe me to this bug? and yes lot of people use seahorse and nobody is having this issue
[22:18] <hyperair> seb128: well, you were the last one to upload seahorse
[22:18] <hyperair> i thoughty ou might be able to help regarding that bug
[22:18] <seb128> hyperair: do you use scim or something similar?
[22:19] <hyperair> eh yeah
[22:19] <seb128> hyperair: could you try not using it?
[22:19] <hyperair> i could
[22:19] <hyperair> but i'd have to log out
[22:19] <seb128> hyperair: it could be a scim interaction bug
[22:19] <hyperair> yeah
[22:19] <hyperair> could be
[22:19] <dvstin> it's annoying to write up a bug, find the root cause, find the solution, and watch it sit there and do nothing :(
[22:20] <hyperair> dvstin: agreed
[22:20]  * hyperair needs sleep bady
[22:20] <hyperair> badly
[22:21] <slangasek> mathiaz: according to policy, you should be able to call invoke-rc.d tomcat6 force-reload directly
[22:21] <hyperair> seb128: doesn't fix the issue
[22:21] <hyperair> i seti t to xim
[22:22] <hyperair> but i noticed this: ** Message: could not grab keyboard
[22:22] <slangasek> mathiaz: does tomcat6's init script support a force-reload that's separate from a restart?
[22:23] <mathiaz> slangasek: hm - no.
[22:23] <seb128> hyperair: scim is still running though?
[22:24] <hyperair> oh yeah
[22:24] <hyperair> i killall'd it
[22:24] <slangasek> mathiaz: ok.  So this will end up doing a restart, but the whole point of invoke-rc.d is to keep maintainer scripts from starting services that aren't supposed to be started in the current runlevel
[22:24] <hyperair> okay, now this is weird.
[22:24] <slangasek> (or as defined by local policy-rc.d policy)
[22:24] <hyperair> seb128: the second prompt works (after the first one fails)
[22:25] <hyperair> but i have to focus another window and come bak
[22:25] <hyperair> back*
[22:26] <seb128> hyperair: did you try entering your password? there is a bug about the dialog not being colored as if it had the focus but in fact it has it
[22:26] <hyperair> seb128: cursor's there. it stops blinking when i type, but nothing gets entered
[22:26] <seb128> weird indeed
[22:26] <hyperair> yeah
[22:26] <hyperair> it seems that the second passphrase prompt fails to grab the keyboard
[22:27] <hyperair> so the first passphrase prompt successfully grabs the keyboard, and then i can't type in anything
[22:27] <seb128> hyperair: bug #66104
[22:27] <hyperair> then the second passphrase prompt doesn't grab the keyboard, but i can type in stuff after focusing on some other text input, and then back on seahorse
[22:27] <hyperair> hmm XIM huh?
[22:28] <hyperair> what other inputs should i use?
[22:28] <seb128> hyperair: the issue seems to be a scim one rather a seahorse bug anyway
[22:29] <seb128> but I've no real clue about scim, try talking to arne rather
[22:30] <hyperair> hmm
[22:31] <hyperair> i'll try tomorrow then
[22:31] <hyperair> i need to get some sleep
[22:34] <mathiaz> slangasek: ok. So IIRC policy-rc.d is mainly used to manage start/restart permission.
[22:34] <mathiaz> slangasek: in which case using force-reload in the script would lead to problem.
[22:35] <mathiaz> slangasek: considering that restart and force-reload are the same, would replacing force-reload with restart solve the issue?
[22:36] <slangasek> mathiaz: ah, if it's not possible to manage the behavior of force-reload with policy-rc.d, that's something I was unaware of
[22:36] <h4writer> hi, I just wanna thanks everyone from the ubuntu-development for they right choises (integration and development wise). In the previous ubuntu version I removed network-manager, because I thought wicd was better. I now can say I'm happy to switch to network-manager again and FINALLY have WPA working out of the box :-D :-D Happy user here :-)
[22:37] <slangasek> mathiaz: if force-reload is identical to restart anyway for this init script, I would just call "restart" then, yeah
[22:37] <mathiaz> slangasek: oh - I don't pretend that
[22:37] <slangasek> mathiaz: well, I can't say I've tested that directly myself - and the invoke-rc.d code is horrible to behold
[22:38] <mathiaz> slangasek: ok - so if the force-reload is switch to restart would you accept the upload?
[22:39] <slangasek> mathiaz: also dropping the querying of 'status', or just s/force-reload/restart/?  If the other bug is fixed, I'm not sure that either change is necessary at this point in the release
[22:40] <mathiaz> slangasek: hm - that is not sufficient - all of this is related to bug 274365
[22:41] <tedg1> cody-somerville: Does Xubuntu use gnome-screensaver?
[22:41] <cody-somerville> tedg1, yes
[22:41] <mathiaz> slangasek: restart will try to start tomcat which will fail
[22:41] <mathiaz> slangasek: because java is not setup correctly.
[22:42] <mathiaz> slangasek: the workaround we've used is to add an error_handler of true in the tomcat6 postinst script
[22:42] <mathiaz> slangasek: if the status check is removed, the postinst script will try to start tomcat6 anyway and will fail.
[22:42] <mathiaz> slangasek: which is the error seen in bug 288218
[22:44] <tedg1> cody-somerville: 'k
[22:44] <tedg1> cody-somerville: Thanks.
[22:44] <slangasek> mathiaz: ah.  then that answers my original question, "why does it care about status" :)
[22:45] <slangasek> mathiaz: that's something I don't have an answer for within the invoke-rc.d framework, so I guess what you're doing is perfectly correct & necessary
[22:48] <mdke> slangasek: I think ubuntu-docs is still in the queue, don't know if it is a convenient time to let it through?
[22:49] <slangasek> mdke: I'm in the middle of trying to publish the RC, it's definitely not a convenient time to let it through
[22:49] <mdke> slangasek: ok, i wasn't sure of the timetable. No worries
[23:04] <wasabi> it is a bit annoying how parts of my desktop break while running an upgrade.
[23:09] <wasabi> I wonder what a good general purpose solution to 'not breaking running applications during upgrades' is for us. MS solves it by file locking, and not completing the upgrade until reboot (all files are unlocked).
[23:09] <wasabi> Should it be policy that a .deb preinst script should ensure files are not in use? Or what?
[23:09] <wasabi> (given that you accept that it's broken now)
[23:11] <lifeless> wasabi: I wouldn't say MS have solved it
[23:11] <wasabi> Or should software simply be aware that it's files might change on the fly, out of order, and dependent services might stop unexpectidly.
[23:11] <wasabi> in mye xperience, day to day upgrades on windows don't cause running apps to crash, or weird dialogs to pop up on teh desktop.
[23:11] <wasabi> The upgrade pretends to install, and then if files were in use msi makes you reboot.
[23:12] <lifeless> specifically its trivial to break apps on windows because help files and the like are opened on demand; if file locking was the solution upgrades there would look very different
[23:12] <wasabi> Well, I don't see that happening in my usage of Windows. Though on principal I believe you are right.
[23:12] <lifeless> wasabi: you have one part of the puzzle, I recommend you dig deep into orca and the msi service to understand what they do
[23:13] <wasabi> I just did an upgrade of a few packages and a) xchat broke, throwing a message about ORBIT stuff failing b) a dialog box from an unknown application popped up saying it could not do something non-specific c) my fonts in nautilus went unantialiased.
[23:13] <slangasek> What running applications are breaking during upgrade?  Unix /had/ this solved long ago by "software expecting files to change on the fly"
[23:13] <wasabi> Heh.
[23:13] <wasabi> oh, the unknown app was empathy failing because of dbus going up and down I *think*
[23:13] <slangasek> oh, dbus
[23:13] <slangasek> dbus is special :P
[23:14] <wasabi> but I didn't spend enough time watching.
[23:14] <slangasek> dbus is so very un-unix it's not funny
[23:15] <wasabi> Curiously, why isn't 'dbus' just some client library that creates/manages well known pipe names in /tmp/user or something?
[23:15] <slangasek> see previous comment
[23:15] <wasabi> 'just because'?
[23:17] <wasabi> lifeless: I've done a bit of work with MSI... but not taht much. I know about ref counting and the insanity it goes through. I *know* it is *crap*.
[23:18] <wasabi> I'm just wondering what the proper solution is for us.
[23:18] <lifeless> wasabi: I think its a ratchet problem
[23:19] <wasabi> I'm trying to interpret that.
[23:19] <wasabi> Just a matter of lack of time to polish?
[23:19] <lifeless> wasabi: which is to say, its complex and needs many moving parts altered and fixed
[23:19] <lifeless> and there is a high chance of new code being written badly because the current state is 'broken'
[23:19] <lifeless> I don't think we need a bunch of new technical answers
[23:19] <wasabi> Hmm. weird. Intreped just prompted to ask me if I'd like to replace /etc/update-manager/release-upgrades
[23:19] <lifeless> as slangasek says, this is a new problem for us
[23:19] <wasabi> Yeah.
[23:20] <lifeless> by a ratchet problem I mean that we have to draw a line in the sand
[23:20] <wasabi> Haha. Makes me wonder how hard it would be to actually redo the DBUS api as it stands today using plain pipes and stuff.
[23:20] <lifeless> and say 'we won't let this get worse' - upstream changes that make it worse won't be included.
[23:20] <lifeless> and then start at the bottom of the stack - things like dbus - and audit/fix/ and then work up
[23:21] <slangasek> they tend to go unnoticed at the point of inclusion
[23:21] <lifeless> slangasek: true
[23:21] <lifeless> slangasek: 'revert' is not a dirty word though :)
[23:22] <slangasek> no, it's just easier said than done
[23:22] <wasabi> sigh. epiphany broken and won't launch anymore
[23:22] <wasabi> dbus dead
[23:24] <wasabi> So because I'm curious... what have you guys thought about configuration management during upgrade? Another example is dpkg just prompting me to decide what I want to do with smb.conf. What *is* the proper solution to this?
[23:25] <slangasek> lifeless and I differ on that question :)
[23:25] <lifeless> slangasek: I don't think we differ much really
[23:25] <lifeless> slangasek: I know we differ on one aspect of how-to-avoid-prompts
[23:25] <lifeless> slangasek: but I don't believe you think spurious prompts are good :)
[23:26] <slangasek> true... :)
[23:26] <wasabi> I guess the only 'real' way to fix it is to make samba support and upgrade old configuration files.
[23:26] <wasabi> And repeat for every other app.
[23:26] <wasabi> nice. bluetooth.conf
[23:26] <slangasek> wasabi: in the specific case of smb.conf, I would like to know what your old smb.conf and your pre-upgrade /var/lib/ucf/cache/:etc:samba:smb.conf look like
[23:27] <slangasek> because I consider every occurrence of an smb.conf prompt a potential bug
[23:27] <wasabi> i can file a bug then if you'd like
[23:27] <wasabi> basically my file was just joined to AD, had tons of idmap settings added, and I ran it through swat at one point
[23:27] <wasabi> (because it autoconfigures it)
[23:27] <wasabi> (autoformats I mean)
[23:28] <wasabi> and i cannot open my browser to file a bug. nice.
[23:28] <slangasek> oh, swat
[23:29] <slangasek> then that's not a case we can manage, really, so no point in filing a bug
[23:29] <wasabi> I only turn swat on and use it when I get cross eyed by unorganized options.
[23:29] <wasabi> I just have it load/save the file.
[23:29] <wasabi> just to format it. :0
[23:29] <wasabi> Well, you can handle it. The file is still just a list of options.
[23:29] <wasabi> The merge needs context
[23:29] <calc> anyone happen to remember the url that describes how to enable apport?
[23:30] <wasabi> The upgrade process should be able to parse the file, and option by option figure out if it needs to be converted, and then rewrite the file.
[23:30] <wasabi> Not sure there's any alternative.
[23:31] <sbeattie> calc: it's described in https://wiki.ubuntu.com/Testing/EnableProposed
[23:31] <bdmurray> calc: https://wiki.ubuntu.com/Testing/EnableProposed
[23:31] <lifeless> wasabi: 'the current UCF logic cannot handle that'
[23:31] <wasabi> curious why is this the domain of ucf? it is appropiate for samba to be able to handle it's own configuraton file upgrade.
[23:31] <wasabi> no?
[23:32] <wasabi> it certainly possesses the authoritative code for reading the file and understanding the meaning.
[23:32] <calc> sbeattie: ok
[23:32] <lifeless> sure
[23:32] <lifeless> however ubuntu knows that it first installs settings START
[23:32] <lifeless> and then on an upgrade is installed UPGRADED
[23:33] <lifeless> handling that delta is up to Ubuntu and the dpkg upgrade process
[23:33] <lifeless> could that call into samba? sure; currently it uses ucf
[23:33] <wasabi> Maybe samba should provide a utility that will do a three way merge. Load three settings file (original, custom, proposed), and a decision tree about what to write out.
[23:33] <wasabi> I'm just wondering what it SHOULD be like, given infinite time. :0
[23:34] <lifeless> wasabi: I find that that is usually pointless :P
[23:34] <wasabi> I don't think so. I find it impossible to do day to day work without having some vision.
[23:34] <lifeless> vision sure
[23:35] <lifeless> infinite time, well thats a different case :P
[23:39] <wasabi> wow nautilus just gave me an AWESOME error
[23:39] <wasabi> I think it's nautilus.
[23:41] <superm1> TheMuso, were you aware that pulseaudio caused gnome-sound-recorder to behave rather erratically?
[23:43] <Mez> slangasek: it seems your wishes regarding the whole NM process have been granted ;)
[23:43] <slangasek> Mez: I would say... no.
[23:45] <Mez> well, closer to it anyways :P
[23:45] <slangasek> wasabi: the usual cause for smb.conf merge conflicts is with the comments, which are there for a reason; if we're not going to provide the in-line documentation at all, then it'd be a piece of cake for ucf and we don't need samba to do anything anyway
[23:50] <cody-somerville> superm1, Can you upload the patch provided in https://bugs.edge.launchpad.net/ubuntu/+source/abiword/+bug/284857 please?
[23:53] <crimsun> superm1: more precisely, is that with alsa-plugins (intrepid, of course) installed?
[23:54] <superm1> crimsun, with a default install
[23:54] <crimsun> superm1: I have a fix for that and will see about pushing it into ppa for testing
[23:54] <superm1> crimsun, the length of the sound file shoots up to hours within seconds
[23:54] <superm1> crimsun, and then hangs g-s-r
[23:54] <superm1> killing pulseaudio and restarting gsr fixes it
[23:54] <superm1> crimsun, okay
[23:55] <superm1> cody-somerville, it's missing an ack from ubuntu-release
[23:56] <sysadmin> Hmm. What happened to dpkg-reconfigure xserver-xorg -low showing otpions for drivers and stuff?
[23:57] <slangasek> wasabii: xorg.conf is 95% obsolete, therefore the maintainer script handling for managing it is 100% obsolete
[23:57] <wasabii> sure, but X won't detect my video card anymore in intrepid. =(
[23:58] <slangasek> this is a regression vs. hardy?
[23:58] <wasabii> yup
[23:58] <slangasek> if so, please file a bug
[23:58] <slangasek> and nominate it for release
[23:58] <wasabii> *sigh* no browser yet. have to hand edit xorg i guess. =(
[23:58] <slangasek> or boot into "vesa" mode from the recovery menu