[12:09] <mdz> tfheen: qt4-x11 is a similar story
[12:09] <keescook> what's the process for archive removal?  open bug with rationale, subscribe ubuntu-archive?
[12:09] <mdz> keescook: yes
[12:13] <bluefoxicy> ....
[12:14] <tfheen> mdz: ok, let's hold those off, then.
[12:15] <mdz> ok, all desktop/live is done except xubuntu, whose livefs is still building
[12:16] <mdz> I'm falling asleep in my chair, will be back in the morning for tests
[12:18] <bluefoxicy> hmm, I backgrounded readahead
[12:22] <Burgwork> bluefoxicy: why did you background it?
[12:22] <bluefoxicy> Burgwork:  to see what would happen, of course.
[12:22] <Burgwork> bluefoxicy: given it was foregrounded to make boot faster...
[12:23] <bluefoxicy> Burgwork: Windows XP has a readahead-like functionality where it does the readahead while loading drivers, for the purpose of letting the cpu-intensive driver initialization routines run while IO is happening on the disk; I'm working backwards from these thoughts
[12:24] <bluefoxicy> Burgwork:  overall, the "perfect world" scenario would be that ALL I/O happens while the CPU is otherwise busy, so by the time anything needs files they're in memory.  I'm trying to see if I can get any closer to that.
[12:24] <bluefoxicy> so far I'm not making any progress.
[12:25] <Keybuk> doesn't that just involve fiddling with the I/O elevator?
[12:25] <bluefoxicy> Keybuk:  I'm fiddling with readahead
[12:26] <Keybuk> oh right?
[12:26] <bluefoxicy> bootcharts that show the boot process waiting for readahead to finish, then huge IO spikes later down the line, do not impress me and I want to investigate why.  :/
[12:26] <Keybuk> the huge I/O spikes down the line seem wrong
[12:26] <Keybuk> what causes them?
[12:26] <Keybuk> got a copy of the chart?
[12:27] <bluefoxicy> no clue.  Other processes run after readahead are showing IO
[12:27] <Keybuk> the chart should show you
[12:27] <Keybuk> the box for the process will be pink
[12:27] <bluefoxicy> http://bluefox.kicks-ass.org/stuff/bluefox/images/edgy-20061005-1.png  This is the first bootchart I took, unadulterated by any modifications to the boot process.
[12:28] <bluefoxicy> a huge IO spike begins about 1.0 seconds after readahead ends
[12:28] <bluefoxicy> (readahead() blocks blahblahblah this shouldn't happen)
[12:28] <Keybuk> ricer fs?
[12:28] <bluefoxicy> plus, yes as you said, many of the processes show pink boxes
[12:28] <bluefoxicy> ext3
[12:29] <bluefoxicy> I don't use murderfs
[12:29] <Keybuk> that extra spike is weird
[12:29] <bluefoxicy> extremely
[12:29] <bluefoxicy> my next attempt is going to be booting with 'profile' to see if the log is just wrong.
[12:29] <bluefoxicy> as it stands, backgrounding readahead has made it neither slower nor faster
[12:30] <Keybuk> readahead should be in the foreground
[12:30] <Keybuk> otherwise you'll be reading from the disk and skipping the head all over the place
[12:30] <bluefoxicy> I got a second back by moving all of the /lib/modules lines to the top of the file
[12:30] <Keybuk> oh
[12:30] <Keybuk> that immediately after readahead spike
[12:30] <Keybuk> I know what that is
[12:31] <Keybuk> there's been an ABI change since I last updated the lists
[12:31] <Keybuk> so that's it just copying the modules into a tmpfs
[12:31] <Keybuk> that'll go away when I redo the list before release
[12:31] <Keybuk> the second bump is PCI I/O -- not unusual during modprobing
[12:32] <bluefoxicy> nods
[12:32] <Keybuk> the third one is evms/lvm
[12:32] <Keybuk> you can uninstall those
[12:32] <Keybuk> they're not deps of ubuntu-desktop anymore
[12:33] <bluefoxicy> Keybuk:  does readahead() trigger a file read, or is it invisible?
[12:33] <Keybuk> the fourth bump set is the log files being written
[12:33] <Keybuk> dmesg, etc.
[12:33] <Keybuk> bluefoxicy: it's a magic ioctl
[12:33] <bluefoxicy> it should be technically feasible to actually profile and readahead() at the same time
[12:33] <Keybuk> and the last bump is just X.org
[12:33] <bluefoxicy> if you can detect which files were open(), close()'d
[12:34] <Keybuk> bluefoxicy: the profiling is done with inotify
[12:34] <Keybuk> so it detects open()/close() not actual read()
[12:34] <bluefoxicy> yes, inotify can detect opens, writes, reads, ...
[12:34] <bluefoxicy> IN_ACCESS          File was accessed (read) (*)
[12:34] <bluefoxicy> IN_OPEN            File was opened (*)
[12:34] <Keybuk> in_access is different
[12:34] <bluefoxicy> there are also closed (no write) and closed (write)
[12:34] <Keybuk> yes
[12:35] <Keybuk> that's what the profiler looks for, checks the way the file is closed
[12:35] <Keybuk> the point is that it can't tell the file is being open()d/close()d by readahead-list
[12:35] <Keybuk> because inotify doesn't tell us the pid of what's doing the open
[12:35] <Keybuk> can you try
[12:35] <Keybuk> 1) remove evms/lvm
[12:35] <Keybuk> 2) boot with profile
[12:36] <Keybuk> and then boot again to get a new chart
[12:36] <bluefoxicy> i don't think there's much interest in files being just open()/close()d without reading/writing
[12:36] <bluefoxicy> (you know you can readahead() directories?)
[12:36] <Keybuk> yeah there is, because the kernel will optimistically read the first block anyway on an open
[12:36] <bluefoxicy> oh, heh.
[12:37] <Keybuk> besides, finding an open()/close() without a read is cause for a patch <g>
[12:39] <tfheen> Keybuk: not if it does mmap instead of read. :-P
[12:39] <Keybuk> tfheen: well, yes
[12:39] <Seveas> (or if it does write() instead of read())
[12:39] <Keybuk> tfheen: I assume it's ok to update readahead, btw?
[12:39] <Keybuk> I was planning to do the profile with the RC
[12:39] <Keybuk> hadn't talked to you about it
[12:39] <tfheen> Keybuk: we should be able to get that in when RC is out, yes.
[12:40] <Keybuk> is just the one file in the source, after all
[12:40] <bluefoxicy> Keybuk:  reordering based on position on disk seems silly.  Also what about actually detecting things like /lib/modules
[12:40] <Keybuk> bluefoxicy: hmm?
[12:40] <Keybuk> why does that seem silly?
[12:40] <Keybuk> and how would one detect them?
[12:40] <bluefoxicy> well, what if I have /lib/modules/2.6.17-10-i386/* in /etc/readahead/boot and I boot -generic?
[12:41] <bluefoxicy> chances are the names of the modules stay the same...
[12:42] <Keybuk> we don't put any /lib/modules stuff in the readahead list usually
[12:42] <Keybuk> it's just the restricted modules stuff
[12:42] <Keybuk> I generate the lists in vmware
[12:42] <Keybuk> so they're almost certainly useless to anyone else in that regard <g>
[12:43] <Keybuk> why move it around?
[12:43] <bluefoxicy> because I put readahead in parallel with the rest of boot and saw it stall around modprobe() running as modprobe started ganking files off disk and wanted to see what happened.
[12:44] <Keybuk> oh, don't do that
[12:44] <Keybuk> it's never faster in parallel
[12:44] <Keybuk> because you're now reading at the same time as other things are reading
[12:44] <Keybuk> and doing I/O
[12:44] <bluefoxicy> 0:48 consistently in series vs 0:47 in parallel
[12:44] <Keybuk> *shrug* that's not consistent with my testing
[12:44] <Keybuk> see ubuntu-devel post of a few weeks ago
[12:44] <Keybuk> if it's slow, it just means your list is off
[12:45] <Keybuk> there's almost no CPU intensive stuff during boot
[12:45] <bluefoxicy> alright, my re-profiled, series timings are 0:45... the chart looks much better too.
[12:45] <Keybuk> can I see the chart?
[12:46] <bluefoxicy> http://bluefox.kicks-ass.org/stuff/bluefox/images/edgy-20061017-8.png
[12:47] <Keybuk> looks much better
[12:48] <bluefoxicy> yes, a whole 3 seconds.
[12:48] <Keybuk> 45 is about right
[12:48] <bluefoxicy> Keybuk:  the reason I want to get lists not reordered by position on disk is because I want to test actually reading the files in the order they're being used-- i.e., attempting to run in parallel and stay slightly ahead of the boot process.
[12:49] <Keybuk> you run -386 on an AMD64?!
[12:49] <bluefoxicy> with DMA, I/O from disk is basically a blocker
[12:49] <bluefoxicy> yes why
[12:49] <Keybuk> why not -generic 386 or amd64?
[12:49] <Keybuk> -386 is for plain old real 386s
[12:49] <bluefoxicy> oh
[12:49] <bluefoxicy> that's edgy on my laptop
[12:49] <Keybuk> -generic is for other processors
[12:49] <Keybuk> -386 has all the shiny optimisations taken OUT
[12:49] <bluefoxicy> any other kernel (literally any, I have 12 installed) doesn't actually boot
[12:49] <bluefoxicy> it just hangs for 10 minutes at a blank screen and then I press power
[12:50] <Keybuk> bluefoxicy: what difference would that have (order being used) to just letting the boot read things as they're used in the order they're used ?
[12:50] <Keybuk> 10 mins or 3 mins?
[12:50] <bluefoxicy> Keybuk:  CPU,IO,CPU,IO series vs {CPU & IO} {CPU & IO} series
[12:50] <lifeless> Keybuk: async lookahead I'm guessing. Certainly you want cylinder at a time though
[12:50] <Keybuk> there's no CPU at boot though
[12:50] <lifeless> bluefoxicy: you *really* want cylinder at a time reads
[12:50] <AlinuxOS> When edgy starts, I've black screen before gdm... maybe it's my card issue: 01:05.0 VGA compatible controller: ATI Technologies Inc Radeon IGP 330M/340M/350M  <-that's my video card.
[12:50] <bluefoxicy> aside from those BIG BLUE AREAS of CPU usage
[12:50] <Keybuk> if we did anything CPU intensive at boot, then yeah
[12:51] <bluefoxicy> Keybuk:  the capslock key won't turn on capslock
[12:51] <Keybuk> bluefoxicy: there's just one
[12:51] <Keybuk> and that's actually a bug in the bootchart code
[12:51] <bluefoxicy> ah, ok
[12:51] <Keybuk> it charts time in kernel as 100% CPU
[12:51] <lifeless> anything other than cylinder at a time will result in massive multiples of head seek latency
[12:51] <AlinuxOS> +(ah, it's a laptop)
[12:51] <Keybuk> so you'll notice the three times are udev, ckbcomp (console setup) and hald
[12:52] <lifeless> you might be able to go faster than block ordering by starting with the first used block, and doing cylinder at a time from there towards the next used block etc
[12:52] <lifeless> Keybuk: ^
[12:52] <bluefoxicy> I did lose a second in parallel
[12:52] <lifeless> but: thats gonna be finicky to get right, as you'll need to know geometry
[12:52] <Keybuk> lifeless: what if the next used block is behind the first used block?
[12:53] <lifeless> Keybuk: then the first cylinder read is optimal - no delay, and the second cylinder read is one for the second block
[12:53] <lifeless> note that I'm happy with the block ordering approach
[12:53] <lifeless> I think its just fine
[12:53] <Keybuk> if you want to tackle a better, go for it
[12:54] <bluefoxicy> heh
[12:54] <bluefoxicy> the only /lib/modules in my /etc/readahead/boot is soundcore.ko
[12:54] <lifeless> I think it would be a PITA to consistently get better
[12:54] <lifeless> and you'd want to be shuffling the required files on disk in fact at that point... into block order
[12:55] <lifeless> so thanks, but I'll leave it as is
[12:55] <Keybuk> I liked the idea of shuffling the entire boot read files into the first area of the disk in order
[12:55] <Keybuk> some ext3 hackery
[12:56] <bluefoxicy> Keybuk:  the other thing I was looking into was actually reading only specific sections of ELF files, particularly the parts used in dynamic linking
[12:57] <Keybuk> any particular reason?
[12:57] <bluefoxicy> with some heuristic where if the space skipped is less than like 16k just read it in anyway (so if .text has 9k that's not shared in 4k blocks not used by other pages...)
[12:57] <bluefoxicy> Keybuk:  because the only thing needed to "start" a program is dynamic linking; and programs aren't likely to use "all" of their code.
[12:57] <bluefoxicy> Keybuk:  gimme a sec.
[12:58] <Keybuk> and the text
[12:58] <bluefoxicy> libgtk is 3.4M, its text is 0x23aba4 bytes
[12:58] <Keybuk> 2.4M ?
[12:59] <bluefoxicy> Keybuk:  yeah, just about that
[12:59] <Keybuk> you need more than .hash though
[12:59] <bluefoxicy> of course.
[12:59] <lifeless> Keybuk: there is a defraggerr
[12:59] <Keybuk> the dynamic loader maps it all
[01:00] <lifeless> Keybuk: probably a small amount of work to teach it to 'defrag only as much as needed to shuffle *these* to *here*
[01:00] <lifeless> Keybuk: glib handwaving, you could do it from initramfs ;)
[01:00] <Keybuk> most of libgtk-x11.so.2, unsurprisingly, is the .rodata and .text
[01:01] <Keybuk> lifeless: boot the entire system from initramfs? :)
[01:01] <bluefoxicy> .hash .dynsym .dynstr .gnu_version .gnu_version_r .rel.plt .rel.dyn .plt .rodata .data.rel.ro .got .got.plt .data are the ones I know are needed; .init .text .fini and .bss are the ones I know the dynamic linker doesn't need.
[01:01] <lifeless> Keybuk: no, shuffle the boot files to the start of / and /usr
[01:02] <Keybuk> .text is very needed
[01:02] <Keybuk> very very very needed :p
[01:02] <bluefoxicy> Keybuk:  not for the dynamic linker :)
[01:02] <Keybuk> there's no such thing as "the dynamic linker"
[01:02] <Keybuk> there's the dynamic link loader
[01:02] <Keybuk> which uses .text to, err, load the .so
[01:02] <bluefoxicy> ld.so then.
[01:02] <Keybuk> that's the dynamic link loader
[01:02] <bluefoxicy> um, not really :)
[01:02] <Keybuk> and it certainly uses .text and .bss
[01:03] <bluefoxicy> ld.so only touches .text if there are .text relocations, which there shouldn't be because they make loading a program slow.
[01:03] <Keybuk> what planet are you on?!
[01:03] <bluefoxicy> Earth, yoU?
[01:03] <Keybuk> ld.so maps .text into memory
[01:03] <Keybuk> because otherwise you can't run the code
[01:03] <bluefoxicy> yes, but the kernel does not bring the data into memory immediately.
[01:03] <Keybuk> it does
[01:04] <bluefoxicy> ok so if I mmap() a 2GB database I need 2GB of ram?
[01:04] <bluefoxicy> (I can do this, and I only have 1GB)
[01:04] <Keybuk> if you mmap a 2GB file, and then scatter read different sections in it
[01:04] <bluefoxicy> you'll wind up getting scatter IO
[01:04] <Keybuk> then you'll need at least 2GB of virtual memory
[01:04] <Keybuk> yes
[01:04] <bluefoxicy> you won't need 2GB of virtual memory
[01:04] <Keybuk> yes you will
[01:04] <Keybuk> but the file itself counts
[01:04] <bluefoxicy> if you WRITE to any pages and it's mapped PRIVATE you will.
[01:04] <bluefoxicy> oh, right sorry :)
[01:05] <bluefoxicy> I read VM as "swap" D:
[01:05] <Keybuk> no
[01:05] <Keybuk> I would have said "swap"
[01:05] <Keybuk> if you open a 2GB file, and scatter reads across it
[01:05] <bluefoxicy> Keybuk:  at any rate my point is that you won't immediately need all of .text
[01:05] <Keybuk> then Linux would prefer to have as many blocks as possible in the page cache
[01:06] <Keybuk> if you take libgtk as your example, the chances are you do want it the text the page cache :)
[01:06] <Keybuk> as lots of things are going to use it
[01:06] <bluefoxicy> you'll need parts of it; you'll probably need .init as well but since it's wedged between .plt  and the REL sections and is small any heuristic you use will probably read it in anyway.
[01:06] <bluefoxicy> Keybuk:  yes but you might need i.e. 1 meg of the 2.4 megs of text in GTK in the first hour you're using it
[01:06] <Keybuk> doubt it
[01:06] <Keybuk> prove it
[01:06] <lifeless> Keybuk: 'defrag -i inode-priority-file'
[01:06] <Keybuk> if you need 1M of the text, chances are you'll only have 1M in the page cache
[01:07] <Keybuk> Linux is good at this
[01:07] <Keybuk> not great, but good
[01:07] <bluefoxicy> you can prove it by instrumenting do_no_page() in the kernel
[01:07] <bluefoxicy> but I don't feel like doing that :)
[01:07] <bluefoxicy> so we'll leave it conjecture.
[01:08] <lifeless> Keybuk: it will need a patch to only optimise the inodes desired, rather than the entire fs
[01:08] <bluefoxicy> Keybuk:  that's my point.  If you readahead() a whole elf file you read all the text into the page cache; but then, you have to wait while readahead() blocks reading a multi-megabyte file.  As opposed to possibly reading 1 meg
[01:09] <bluefoxicy> or on some elf files 24K of their whole 76K size (zlib specifically)
[01:09] <lifeless> Keybuk: and an update to ext3 :(
[01:09] <Keybuk> blockwise readahead would be required for that
[01:09] <bluefoxicy> It may be a worthwhile gamble to read only those portions, then read the .text and .bss in parallel
[01:09] <bluefoxicy> Keybuk:  readahead() does that
[01:09] <bluefoxicy> it reads in 4K chunks :)
[01:09] <bluefoxicy> ssize_t readahead(int fd, off64_t *offset, size_t count);
[01:10] <Keybuk> i mean profiling
[01:10] <Keybuk> we don't currently have any way to tell which blocks are read
[01:10] <bluefoxicy> Keybuk:  the only issue is that 1) the first pass is going to read-short seek-read; 2) the second pass is going to be going over the file system in .. a second pass.
[01:10] <bluefoxicy> Keybuk:  I'm not talking about predicting what parts of .text are used though.
[01:11] <Keybuk> eh?
[01:11] <bluefoxicy> I'm talking about, say, if you spend 0.6 seconds reading in all of libgtk+, when you could spend 0.2 seconds and then (possibly) lose 0.1 more (total 0.3) to not having a part of .text in
[01:11] <bluefoxicy> the idea is to try to take a shortcut, not to superprofile; if you can superprofile go for it
[01:12] <lifeless> bluefoxicy: the problem with unprofiled shortcuts is that they can be long cuts
[01:13] <bluefoxicy> lifeless:  nods, I have not ruled out that possibility.  That chart shows readahead-list taking 13.5 seconds of boot time though, which is a pretty big cut.
[01:13] <bluefoxicy> brb
[01:13] <lifeless> I thought readahead list backgrounded ?
[01:14] <bluefoxicy> no, it doesn't
[01:14] <bluefoxicy> I tried backgrounding it, I lost a second on the last test, some tests I lost nothing.
[01:20] <bluefoxicy> Keybuk:  write_list says the files are sorted by device and inode number
[01:20] <Keybuk> yes
[01:21] <bluefoxicy> that's how you get them in order on disk?  :P
[01:21] <Keybuk> that's what you call "commenting the code before you write it"
[01:21] <Keybuk> no
[01:21] <Keybuk>                 /* Scary ioctl shit */
[01:21] <Keybuk>                 opened[i] .block = 0;
[01:21] <Keybuk>                 ioctl (fd, FIBMAP, &(opened[i] .block));
[01:21] <bluefoxicy> ah, lol
[01:21] <Keybuk> opened_cmp then uses dev, block, ino
[01:22] <bluefoxicy> ok
[01:22] <bluefoxicy> but that line is where they're actually sorted?
[01:23] <bluefoxicy> ("by device and inode")
[01:25] <Keybuk> that line just calls qsort and passes in the sort function defined above
[01:25] <Keybuk> which you'll see also sorts by block
[01:25] <Keybuk> look at the code, not the comments :p
[01:30] <Keybuk> remove "quiet" from the kernel command-line ?
[01:30] <bluefoxicy> ok this is annoying, I think it keeps running fsck after every reboot :(
[01:30] <bluefoxicy> on /, specifically
[01:30] <bluefoxicy> but I've seen /home once
[01:31] <bluefoxicy> did I fall on "too many mounts" and "180 days have passed" at the same time or something, cheriste
[01:31] <bluefoxicy> oh god I have a separate /boot too, what was I smoking when i installed
[01:31] <bluefoxicy> I've LITERALLY had fsck run because "it's time" over 10 times in the past hour
[01:31] <shackan_> is vmware-player broken again ? (no bugs on lp)
[01:32] <Chipzz> shackan_: afaik there's no way to run vmware player on edgy
[01:32] <Chipzz> vmware player uses a different version of libdbus than the rest of gnome
[01:33] <Chipzz> which is of course abi incompatible
[01:33] <Chipzz> errr
[01:33] <Chipzz> api
[01:33] <Keybuk> that got fixed, no?
[01:33] <shackan_> why the hell does vmplayer need dbus ?
[01:33] <bluefoxicy> GOOD LORD
[01:33] <Keybuk> shackan_: everything uses dbus now, didn't you get the memo?
[01:33] <sivang> indeed, why is that?
[01:33] <Keybuk> they're rewriting the kernel as a micro-kernel on top of dbus
[01:33] <bluefoxicy> I have rebooted THREE TIMES trying to get it to not fsck, it always says the FS is clean on multiple file systems, is there a 'nofsck" i can pass on the command line or what
[01:34] <Chipzz> Keybuk: no
[01:34] <Chipzz> chipzz@Reel:~$ apt-cache show vmware-player | grep Conflicts
[01:34] <Chipzz> Conflicts: libdbus-1-2
[01:34] <HrdwrBoB> bluefoxicy: you can set it in /etc/fstab
[01:34] <shackan_> Keybuk, you're scaring me, seriously
[01:34] <Chipzz> which I think should actually be Conflicts: libdbus-1-2, libdbus-1-3
[01:34] <bluefoxicy> HrdwrBoB:  what is that, 0 0?
[01:34] <HrdwrBoB> bluefoxicy: man fstab, I can't remember :)
[01:34] <Chipzz> bluefoxicy: you can use tune2fs
[01:36] <bluefoxicy> Chipzz:  I've had /home, /boot, and / fscked like 12 times now
[01:36] <bluefoxicy> after clean reboots
[01:36] <bluefoxicy> HrdwrBoB:  that did it
[01:36] <Chipzz> bluefoxicy: use -c max-mount-counts
[01:36] <bluefoxicy> wait, no, no it didn't.
[01:36] <Chipzz> first option in man tune2fs
[01:37] <bluefoxicy> Chipzz:  should it fsck one boot, then the immediate following boot, then the immediate following boot, saying something about "mounted 30 times"?
[01:37] <Chipzz> I'm not sure if you need to set it to 0 or -1 or some insanely high value; anyway, it's possible
[01:37] <bluefoxicy> and every time tell me fsck exited with status 1
[01:37] <Chipzz> bluefoxicy: did you ctrl-c the e2fsck?
[01:37] <bluefoxicy> no
[01:37] <bluefoxicy> but I'm about to rm -f the e2fsck
[01:38] <Chipzz> bluefoxicy: just do tune2fs -C 0
[01:38] <Chipzz> that should get rid of it too, except if your fs is not clean
[01:40] <bluefoxicy> Chipzz:  tell usplash to say "Hold on, busy fscking myself" when it does this.
[01:41] <Chipzz> ?
[01:43] <bluefoxicy> that's weird
[01:43] <bluefoxicy> it's only doing it when I "Profile"
[01:44] <Keybuk> you sure it's the fsck?
[01:44] <bluefoxicy> but eevery time I profile it tells me /boot and /home are clean and / is clean and fsck exited with exit status 1
[01:44] <bluefoxicy> Keybuk:  this laptop is the victim of a violent edgy upgrade
[01:44] <bluefoxicy> it's quite likely I busted something.
[01:45] <Kamion> thom: do you care about pygsm any more? see bug 65376
[01:45] <Ubugtu> Malone bug 65376 in pygsm "[UNMETDEPS]  pygsm has unmet dependencies (and FTBFS)" [Undecided,Fix committed]  http://launchpad.net/bugs/65376
[01:45] <malex> Hi. Who should I contact to raise a grievance about an unauthorized import of an upstream project into Rosetta?
[01:45] <Kamion> malex: #launchpad would be a better place to start than here, at any ratee
[01:45] <Kamion> rate
[01:46] <malex> Kamion: thanks, will go there.
[01:46] <Keybuk> "unauthorised?"  are your .pot files non-free?
[01:46] <bluefoxicy> hmm weird.  /etc/readahead/boot isn't sorted yet..
[01:46] <Keybuk> bluefoxicy: sorted?
[01:46] <malex> Keybuk: Unauthorized according to the Ubuntu's own Rosetta import policy ;)
[01:46] <Keybuk> malex: yeah, then #launchpad is your best bet
[01:48] <bluefoxicy> Keybuk:  I commented out the qsort line.  http://bluefox.kicks-ass.org/stuff/bluefox/images/rah/ both those are readahead in parallel, both measure 1 second slower than readahead in series
[01:48] <Keybuk> really?
[01:48] <Keybuk> should be no difference :)
[01:48] <Keybuk> readahead-list sorts them anyway
[01:48] <bluefoxicy> does it?  I commented that out...
[01:48] <bluefoxicy> wait
[01:48] <bluefoxicy> you're sorting in readahead-watch AND in readahead-list?
[01:48] <Keybuk> yeah
[01:49] <Keybuk> why not/
[01:49] <Keybuk> no point not sorting in -watch, it's not time critical
[01:49] <bluefoxicy> because..... you're doing work in readahead-list that you don't have to :P
[01:49] <Keybuk> it doesn't cost much
[01:49] <Keybuk> a sort of that list takes nanoseconds, even on a slow processor
[01:49] <Keybuk> and it's gain is immense for non-profile'd list
[01:52] <bluefoxicy> which only happen when someone like me decides to try and hack it out of the way to see what happens
[01:53] <bluefoxicy> I'm still surprised there's like 119 modules being loaded but you don't readahead those
[01:54] <Keybuk> *shrug*
[01:54] <Keybuk> can't predict the module list
[01:54] <Keybuk> the entire point of modules is that everyone has a different combination
[01:55] <bluefoxicy> yes I'm aware.  profile for me generated like, 1 module (soundcore.ko) in the list.
[01:55] <Keybuk> that's odd
[01:55] <Keybuk> profile should give you them all
[01:55] <Keybuk> it's just the default ones we don't ship modules in
[01:56] <Keybuk> (and even there I've experimented with shipping the common ones like usbcore :p)
[01:56] <bluefoxicy> and you're right again.  I lost 3 seconds not sorting the list.
[01:56] <Keybuk> :)
[01:56] <Keybuk> I did spend a fair amount of time writing this
[01:56] <Keybuk> and testing it
[01:56] <sivang> hmm, why does apt-cache show $pkg now shows two instead of one section of packag info?
[01:57] <jdong> :)
[01:57] <jdong> Keybuk: and I spend a great deal of time abusing it....
[01:57] <bluefoxicy> Keybuk:  yes, I'm aware.  :)
[01:57] <jdong> like preloading OOo, Firefox... KDE.... ;)
[01:57] <Chipzz> sivang: no, but it can show 2 packages
[01:57] <Keybuk> not to mention figuring out the best way to make it work
[01:57] <sivang> Chipzz: it does this for me by default for certain packages, does it show both source and bin now?
[01:58] <Chipzz> sivang: no, it shows installed and in the archive
[01:58] <sivang> Chipzz: I see
[01:58] <Chipzz> sivang: it does that if the version you have installed is not the last
[01:58] <bluefoxicy> Keybuk:  it DOES give me all the linux-restricted-modules
[01:59] <jdong> Keybuk: I was thinking about allowing readahead to slurp while all the module inserting is being done, then having a Sxxreadahead-wait script stall until readahead finishes before continuing
[01:59] <sivang> Chipzz: has it always done so ? ;)
[01:59] <Chipzz> yes
[01:59] <Chipzz> try apt-cache policy
[01:59] <Chipzz> sivang: it also does so if for example you have both dapper and edgy entries in your sources.list
[02:00] <Chipzz> apt-cache policy package
[02:02] <Chipzz> jdong: first reading all modules, then loading udev + reading all the rest makes more sense to me
[02:02] <jdong> Chipzz: why not do readahead while the IO is not really being used, like while modprobing
[02:02] <jdong> or bringing up networking
[02:02] <jdong> because if you readahead while something IO-intensive happens, it's a lose-lose
[02:02] <Chipzz> jdong: probing modules *does* io
[02:03] <jdong> not nearly as much
[02:03] <jdong> as, say, loading dbus
[02:03] <Chipzz> but still conflicting
[02:03] <jdong> Chipzz: it's just one thing I was gonna try....
[02:05] <Keybuk> jdong: I'd rather just get rid of the sleep :)
[02:05] <jdong> ooh! ooh! move gdm to /etc/rc2.d/S01!
[02:05] <jdong> (surprisingly it actually didn't break when I tried that)
[02:06] <Chipzz> jdong: starting udev takes such a long time that I figure you can do most of the readahead (say 70% - 80%) in the background while starting udev
[02:06] <Nafallo> we're not going to have rc*.d for much longer I thought? :-)
[02:06] <Chipzz> that is, if you're not getting conflicting io from loading modules
[02:06] <Chipzz> but then, I'm just guessinhg
[02:06] <Chipzz> I have no actual figures to back this up
[02:09] <bluefoxicy> that's odd.
[02:09] <bluefoxicy> I removed all .so files and the boot time was 46 seconds
[02:10] <bluefoxicy> I put it back in series (instead of parallel) and the boot time went up to 47 seconds...?  o.O
[02:11] <jdong> bluefoxicy: I have 1 second fluxuations between boots anyway....
[02:11] <bluefoxicy> (that's certainly a useless testcase)
[02:11] <bluefoxicy> jdong:  really?  Mine seem to be rather consistent until I start messing with things.
[02:11] <jdong> my bootcharts show 36 and 37
[02:11] <Fujitsu> Kamion, thanks for sending that email to -devel about setting statuses to Rejected... Those antics this morning will have spammed the inboxes of many hundreds of people :S
[02:11] <jdong> 377 when fsck decides it's the lucky day :D
[02:12] <jdong> (hint hint do something about periodic fscks hint hint)
[02:12] <bhale> tune2fs -i 0 /dev/hdX is left as an exercise to the user
[02:14] <Kamion> Fujitsu: I think there's some fundamental miscommunication somewhere about how duplication is supposed to work, but it's too late for deep thoughts about it
[02:14] <Kamion> (too late at night, I mean)
[02:15] <Keybuk> Chipzz: starting udev takes no time at all
[02:15] <bluefoxicy> Keybuk:  give me something to make the little man inside my computer run faster.
[02:15] <Kamion> best rebuild the DVDs, too
[02:15] <Chipzz> Keybuk: hrrrm right, udev backgrounds itself, right?
[02:16] <Keybuk> Chipzz: right, but it's also a very small C program
[02:16] <Keybuk> it just opens a socket, listens and that's it
[02:16] <Keybuk> hardly a time-consuming part of the boot process
[02:16] <Keybuk> the time-consuming bit is the massive sleep() I put in there, because I'm a coward
[02:17] <Chipzz> Keybuk: in the c code, or in the startup script?
[02:18] <Keybuk> it's in the C
[02:18] <Keybuk> udevsettle is just a loop and sleep
[02:18] <Keybuk> we won't need that for feisty
[02:19] <Nafallo> oh? is edgy+1 named?
[02:19] <bluefoxicy> Keybuk:  the joys of artificial improvements
[02:20] <Keybuk> bluefoxicy: "artificial" ?
[02:20] <jdub> foxy!
[02:20] <bluefoxicy> "should we remove bluescreen_test() from loaddriver.c?"  "Yeah sure"  "Alright... *scribble*  WindowsXP... now more stable... with better ... driver... support."
[02:20] <Keybuk> hmm?
[02:20] <Keybuk> udev is a huge improvement on the nothing we had before
[02:21] <bluefoxicy> Yes but you put a big sleep loop into it to let it 'settle'... I assume it has some sort of race condition and needs to settle down after loading?
[02:21] <Keybuk> sure it's slower than compiling the modules you need into the kernel, but that kernel compile is a bitch <g>
[02:21] <Keybuk> nah
[02:21] <Keybuk> the race condition is in the rest of the boot process
[02:22] <Keybuk> assuming things like "I can mount any hard drive I like now"
[02:22] <Keybuk> or "if I ifconfig eth0, it'll be there"
[02:22] <bluefoxicy> ah
[02:22] <Keybuk> half the reason we wrote upstart
[02:22] <Keybuk> means we can get rid of that sleep
[02:22] <bluefoxicy> yeah I was gonna say upstart can wait and get triggered on events can't it
[02:23] <sladen> ah, welcome to late-night flaming action on #ubuntu-devel
[02:23] <pygi> :P
[02:24] <bluefoxicy> sladen:  oh psh, I'm just being a pest
[02:24] <bluefoxicy> if you want I can bring up the microkernel vs monolith argument, but you'll have to coax Linus into the chan
[02:24] <sladen> six of one and half a dozen of the other :)
[02:24] <pygi> bluefoxicy: don't do that!
[02:24] <bluefoxicy> pygi:  lol :)
[02:24] <jdong> bhale: oh, this user is a linux nerd who seems stereotypically allergic to exercise.... ;)
[02:25] <Keybuk> sladen: but bluefoxicy is *so* cute!
[02:25] <bluefoxicy> I am
[02:26] <pygi> sivang: !!!
[02:26] <Nafallo> sivang: the beard :-)
[02:26] <bluefoxicy> I don't have a beard
[02:26] <sladen> depends where the 'beard' is
[02:26] <bluefoxicy> Keybuk:  wait you're not another dirty old man stalking me are you?
[02:26] <pygi> sivang: pm pls?
[02:26] <bluefoxicy> I have 2 or 3 guys over 30 that want to get on a plane already, I don't need more  D:
[02:26] <sladen> ooh, can we all join in?
[02:26] <Keybuk> bluefoxicy: I'm not old, nor stalking you ... but I am dirty, yes
[02:26] <bluefoxicy> restraining orders are expensive you know
[02:27] <jdong> bluefoxicy: how dare you insult hans reiser ;)
[02:27] <sivang> sladen: hehee
[02:27] <sivang> sladen: ROTFLs
[02:27] <Keybuk> bluefoxicy: sugar daddies are so useful though
[02:27] <bluefoxicy> jdong:  He murdered the Unix file system D:
[02:27] <bluefoxicy> with his nonstandard crap
[02:27] <bluefoxicy> (i.e. lack of xattrs)
[02:27] <sladen> perhaps he just tried to fsck it and ended up with a bloody mess
[02:27] <pygi> bluefoxicy: dude, can you write a FS as least half as good as reiser? No? The be shhhh...
[02:27] <bluefoxicy> jdong:  perverse file system lymerics?  :)
[02:27] <bluefoxicy> pygi:  I should
[02:28] <jdong> aww, come in... it's just about efficient storage of small bits....
[02:28] <jdong> ;-)
[02:28] <bluefoxicy> but I don't know enough about the unix file system to get all the features right
[02:28] <bluefoxicy> and I have no concept of extents
[02:28] <sladen> jdong: yeah, just build a tree on top once you've nearly arranged all the little pieces
[02:28] <bluefoxicy> I did independently come up with encoding inodes' physical addresses into their inode numbers, but found out 2 days ago that that's in XFS
[02:28] <jdong> :)
[02:28] <bluefoxicy> trees suck
[02:28] <bluefoxicy> O(1) look-ups
[02:29] <jdong> whatever you say man
[02:29] <jdong> :)
[02:30] <Keybuk> totally
[02:30] <sivang> jdong: I invented jet propoltion, not Larry Wall :)
[02:30] <jdong> well.... I invented broken packages
[02:30] <jdong> oh wait...
[02:31] <bluefoxicy> I still don't know how to account free/used space and quotas properly (run the system without tracking quotas ... and quotas are messed up); or get a O(1) on looking up file names in a directory tree :/
[02:31] <Kamion> mdz: I registered ubiquity-driver-updates before seeing install-with-third-party-drivers. Which should we keep?
[02:31] <_ion> Yay, arguments! KDE is better than Vim!
[02:31] <bluefoxicy> directory tree to me looks like it'd be best implemented as a Patricia Trie
[02:31] <bluefoxicy> where you literally read one string (granted, broken at places) and you're done
[02:31] <Keybuk> wasn't she a drag queen?
[02:31] <pygi> _ion: lol :)
[02:31] <sivang> Keybuk: hehe
[02:32] <jdong> pfft, vim rules, everyone should use reiserfs, ubuntu should adopt portage, why aren't we using -O3 -ftree-vectorize -ffast-math, 686 and k7 kernels should return....
[02:32] <jdong> <insert flamebait here> :)
[02:32] <pygi> jdong: you are wrong, we should adopt conary and pacman 
[02:32] <jdong> AND FORUMS BEAT IRC ANY DAY
[02:32] <jdong> :D
[02:32] <sivang> jdong: only the 686 kernels ;) (oh dear, I killed another kitten)
[02:32] <pygi> jdong: too late =)
[02:32] <Fujitsu> Far too late, jdong.
[02:32] <jdong> :(
[02:32] <_ion> jdong: We should move bug tracking from launchpad to the forums!
[02:32] <jdong> yeah!
[02:33] <jdong> hey, it'd still be easier to use than KDE's BTS
[02:33] <pygi> _ion: I disagree, use irc for bug tracking!
[02:33] <sivang> we should write an LP bot for that
[02:33] <jdong> sivang: hah! that's a wonderful idea
[02:33] <Keybuk> we should just use tfheen for bug tracking
[02:33] <sivang> Keybuk: is he a bot now?
[02:33] <Nafallo> lol
[02:34] <jdong> a LP bot would be great for drive-by bug reports!
[02:34] <jdong> (which I certainly don't partake in)
[02:34] <jdong> ;-)
[02:34] <Keybuk> drive-by bug fixing is far more fun!
[02:34] <jdong> it sure is
[02:34] <jdong> :)
[02:34] <pygi> =P
[02:34] <bluefoxicy> it's tuesday
[02:34] <pygi>  !driveby fix bug #32542
[02:34] <Ubugtu> Malone bug 32542 in nautilus "It's difficult to save a Nautilus search" [Unknown,Unconfirmed]  http://launchpad.net/bugs/32542
[02:34] <bluefoxicy> I never could get the hang of tuesdays
[02:35] <jdong> lol
[02:35] <HrdwrBoB> it's not tuesday here
[02:35] <bluefoxicy> I'm actually good with thursdays though.
[02:35] <Keybuk> _ion: there's a tasteless joke about hans reiser in there somewhere :p
[02:35] <Nafallo> jdong: oowrite!
[02:36] <Keybuk> bluefoxicy: it's wednesday here
[02:36] <Kamion> mdz: do I need to repropose ubiquity-advanced-partitioner for uds-mtv, or can we just carry it over? (I don't think it desperately needs further discussion)
[02:36] <sivang> it's wedensday here
[02:36] <Keybuk> Kamion: mdz is in London, no?
[02:36] <Keybuk> so probably asleep :)
[02:36] <Kamion> Keybuk: if he doesn't read scrollback, I can always ask him again later
[02:36] <Keybuk> the way I understand our earlier discussion though, one shouldn't propose specs that don't need more discussion
[02:36] <Kamion> I wasn't expecting an immediate reply
[02:37] <bluefoxicy> Keybuk:  wednesday is better, special on hotdogs
[02:37] <sivang> heh
[02:37] <jdong> bluefoxicy: as far as I'm concerned, it couldn't get worse for me than today
[02:37] <Kamion> I suppose that means I'll have to actually think of other stuff I want to do for edgy+1 then, otherwise my slate is going to look artificially empty in MTV
[02:37] <sivang> jdong: how so?
[02:37] <bluefoxicy> lol
[02:37] <jdong> apparently the robotics team wanted to see if spinning a CD-R at 50,000 RPM would cause it to fail
[02:38] <sivang> lol
[02:38] <jdong> and I walked into the room as they plugged the motor into the 220V transformer
[02:38] <HrdwrBoB> hahahahaa
[02:38] <Keybuk> bluefoxicy: eww, icky
[02:38] <sivang> jdong: *LOL*
[02:38] <jdong> it hurt... but we all had a laugh
[02:38] <bluefoxicy> Keybuk:  you don't like hotdogs?
[02:38] <sivang> jdong: good thing they didn't want to test that with metal hard drive platters :)
[02:38] <jdong> and oh yeah, don't spin CD's at 50000 RPM :)
[02:38] <Chipzz> bluefoxicy: 02:34 < bluefoxicy> I never could get the hang of tuesdays >> Hitchhikers Guide to the Galaxy quote? :)
[02:38] <jdong> but there's a lesson to be learned in all of this
[02:38] <bluefoxicy> Chipzz:  near quote
[02:39] <bluefoxicy> Chipzz:  Thursdays, really.
[02:39] <Chipzz> well, yeah :)
[02:39] <Keybuk> bluefoxicy: nope
[02:39] <sivang> jdong: the lesson be ?
[02:39] <Chipzz> and I think there's a 'really' too in the real quote
[02:39] <bluefoxicy> Keybuk:  so much for rob's business model
[02:39] <jdong> when chosing between reiserfsck and putting the platters on a 50000 motor, the latter at least puts on a show before imploding your data
[02:39] <Keybuk> bluefoxicy: rob's business model?
[02:39] <jdong> :)
[02:39] <bluefoxicy> Keybuk:  yeah, he runs a small cafe along the pride parade route
[02:40] <bluefoxicy> whenever there's a parade he runs a special on hotdogs as a joke
[02:40] <_ion> jdong: Didn't they know that MythBusters already proved CDrs break down and easily injure people under such RPM rate? :-)
[02:40] <bluefoxicy> (I'll let you figure it out)
[02:40] <Keybuk> aren't whistles more traditional?
[02:40] <jdong> _ion: well, we here take much more of a DIY approach
[02:40] <bluefoxicy> Keybuk: hotdogs are longer
[02:41] <malex> Does anybody know a live email for the Rosetta OR/AND Launchpad contact? I tried rosetta@launchpad.net, but it's dead.
[02:41] <elmo> malex: it's not dead
[02:41] <Keybuk> bluefoxicy: the real thing is less ... mustardy
[02:41] <bluefoxicy> Keybuk: rofl
[02:42] <bluefoxicy> Keybuk:  I hope you know I am holding back dozens of comments right now :)
[02:42] <malex> elmo: To: rosetta@launchpad.net; Undelivered Mail Returned to Sender; localhost.kvota.net[72.36.154.77]  said: 554 <danilo@localhost.kvota.net>;     Relay access denied (in reply to RCPT TO command
[02:43] <Keybuk> bluefoxicy: oh, why?
[02:43] <malex> elmo: It is not a deliverable address.
[02:43] <bluefoxicy> Keybuk:  Ask the man from Nantucket when you see him
[02:43] <bhale> bluefoxicy: thats enough of that
[02:43] <elmo> malex: that's only one of the people on the address
[02:44] <bluefoxicy> bhale: not a fan of Jay Leno?
[02:44] <Keybuk> bluefoxicy: no wonder you stay indoors ;)
[02:44] <bluefoxicy> bhale:  best to be getting back on topic anyway
[02:44] <bhale> right.
[02:44] <malex> elmo: Thanks for the info. There was no way for me to know how many forwards there were.
[02:44] <bluefoxicy> Keybuk:  oh geeze.  I seriously thought that was obscure enough you'd have to look it up.  Then again Leno used it once so
[02:45] <Keybuk> bluefoxicy: did you need a rib removed? or naturally flexible? :p
[02:45] <bluefoxicy> Keybuk:  enough :P
[02:45] <Keybuk> or moral limits, for that matter
[02:45] <Keybuk> I win at this game <g>
[02:45] <bhale> you're lucky my access level is on the other nick
[02:46] <bluefoxicy> Keybuk:  I have no shame or moral limits, I just have a higher probability of getting banned :P
[02:46] <bhale> I havent banned you in ages
[02:46] <bluefoxicy> lol
[02:46] <bhale> starting to have withdraw
[02:47] <bluefoxicy> Yeah I was wondering if you were crawling under the covers with a magazine of old ban logs
[02:47] <bluefoxicy> and a disconnected optical mouse
[02:48] <bluefoxicy> anyway I'm going to search for food before somebody draws me into another indeterminite conversation
[02:49] <Nafallo> food
[02:49] <Nafallo> hmmm
[02:49] <Nafallo> LTNS etc...
[02:49] <Nafallo> brb
[02:50] <Keybuk> LTNS?
[02:50] <bhale> long time no see
[02:50] <Keybuk> ahh
[02:54] <Nafallo> my mom has just signed on a lifetime buying of this cheese for me :-)
[02:54] <pygi> !
[02:54] <bluefoxicy> Keybuk:  will upstart be able to parallelize where proper?  (I microwaved a stale brownie; brownies are never stale)
[02:54] <bluefoxicy> Nafallo: cooper sharp or feta?  I can eat a whole block of feta; it's like a sport, eat more than a small handful without vomiting.
[02:55] <jdong> bluefoxicy: have you ever tried putting a wifi device in a microwave before?
[02:55] <Keybuk> bluefoxicy: it starts all jobs at the same time for a given event
[02:55] <jdong> (not turn it on, of course!)
[02:55] <jdong> it's surprising how much leakage you get out of it
[02:55] <bluefoxicy> Keybuk:  awesome.
[02:55] <sivang> all this C++ can turn a dude blind
[02:55] <Keybuk> so if you have two jobs with "start on tuesday", then they both start at the same time when the tuesday event occurs
[02:55] <Keybuk> start on hotdog
[02:55] <Keybuk> stop on mustard
[02:55] <Keybuk> *ahem*
[02:56] <bluefoxicy> haha
[02:56] <sivang> hehe
[02:56] <jdong> sivang: instinct would tell me not to touch apt's source code, and if I did, to stay clear of anything that hints algorithms :D
[02:56] <bluefoxicy> sivang: if I saw a plusplus I would go blind too.
[02:56] <jdong> bluefoxicy: doubleplus seegood?
[02:56] <sivang> I just so wonderfully astonished at pkgProblemSolver,
[02:56] <pygi> jdong: what's wrong with apt code?
[02:56] <bluefoxicy> jdong:  I try to stick to C
[02:56] <sivang> such that I wanted to have a peak in its guts
[02:56] <Nafallo> bluefoxicy: more something like: http://www.cheese.com/Description.asp?Name=Herrgardsost :-)
[02:57] <sivang> how kinky o me
[02:57] <jdong> pygi: sounds intimidating. that's what
[02:57] <pygi> jdong: not really, trust me
[02:57] <jdong> I'll take your word for it
[02:57] <jdong> but it's still on my personal don't-go-near-it list
[02:57] <pygi> heh :)
[02:57] <Nafallo> bluefoxicy: but this one is ripened for atleast 12 months :-)
[02:57] <bluefoxicy> Nafallo:  sort of like swiss?
[02:57] <pygi> jdong: that way nothing good will ever become
[02:58] <jdong> pygi: nothing good ever would become if *I* touch its source
[02:58] <Nafallo> bluefoxicy: whatever the page says. I mostly eat the swedish cheeses :-)
[02:58] <pygi> problems in the history were solved by touching what seemed untouchable, by trying to solve what seems unsolvable
[02:58] <sivang> pygi: you know anything in algoithms.{h.cc} ?
[02:58] <Nafallo> bluefoxicy: the well-ripened ones ;-)
[02:58] <jdong> pygi: have you ever written a linux defragger :D? As I said, 99% of the things I've done I'm ashamed to admit :)
[02:59] <sivang> pygi: I agree, that was my thought when tryin to read it :)
[02:59] <pygi> jdong: why would you ever be ashamed of writing anything? heh
[02:59] <bluefoxicy> pygi:  if your code looks like mine you would be.
[02:59] <pygi> jdong: so what is it's bad, useless, or something. It's a piece of art, snapshot of your mind in given momemnt. 
[02:59] <jdong> a linux defragger? an auto-backporter? a legacy terribly hackjobbed auto backporter? Portage for Ubuntu hacked?
[02:59] <jdong> hehe
[02:59] <sivang> pygi: but I changed my mind now :p
[03:00] <bluefoxicy> jdong:  make portage emit ubuntu .debs
[03:00] <pygi> o dudes, that's such a negative attitude
[03:00] <jdong> bluefoxicy: that's a great idea
[03:00] <Keybuk> apt-emerge
[03:00] <pygi> jdong: my first songs sucked...as did my first steps on  the guitar
[03:00] <pygi> so should I be ashamed of that?!
[03:00] <sivang> jdong: HEHE
[03:00] <jdong> I roughly hackjobbed the concept of portage asking dpkg/apt for dependencies
[03:00] <jdong> but the rest of it is still portage style
[03:01] <bluefoxicy> jdong:  I think you can build a dependency graph and actually get apt to apt-source and dpkg-buildpkg as well.
[03:01] <jdong> apt/dpkg is still blissfully unaware of portage meddling in /usr
[03:01] <bluefoxicy> jdong:  but I haven't tried, I don't want to try to build a tree of deps and build deps
[03:01] <Keybuk> apt-get build-dep $src && apt-get source -b $$src
[03:01] <zul> *sigh* if you want to use portage use gentoo
[03:01] <jdong> bluefoxicy: I'm personally more interested in the concept of ebuilds in that a "version bump" is a simple rename
[03:01] <jdong> zul: but I want ubuntu :)
[03:01] <bluefoxicy> jdong:  nods, that's much <3's
[03:01] <jdong> zul: I came from Gentoo camp
[03:02] <pygi> jdong: so answer? :P
[03:02] <zul> jdong: yeah so did i, doesnt mean i want portage
[03:02] <jdong> pygi: I'm not all that confident :)
[03:02] <bluefoxicy> jdong:  If you want something realistic, I still want kernels in backports  :D
[03:02] <jdong> zul: I don't miss all of portage... :)
[03:02] <jdong> bluefoxicy: I'm almost afraid to say it, but me too :D
[03:02] <bluefoxicy> (I WANT 2.6.18 with REALTIME preemption, but it won't happen until Edgy+1)
[03:02] <bluefoxicy> jdong:  and a mascot akin to ArOS'
[03:02] <pygi> bluefoxicy: heh
[03:02] <jdong> bluefoxicy: and I suppose you want compressed memory.. oh wait... you do
[03:03] <pygi> bluefoxicy: why don't you help it happen then?
[03:03] <pygi> things don't fall off the sky, you know ... ok, except comets
[03:03] <jdong> pygi: you mean coming to #ubuntu-devel day after day talking about it isn't the way to make it happen?
[03:03] <bluefoxicy> pygi:  I think it's more policy that there isn't a kernel backport process
[03:04] <jdong> bluefoxicy: sure, let's hammer it out. I say make edgy kernel backport happen and it magically does
[03:04] <jdong> minus the build failures, the likely udev incompatibiltiy
[03:04] <jdong> meh
[03:04] <jdong> I can dream
[03:04] <sivang> jdong: hehe
[03:04] <bluefoxicy> jdong:  udev broke one time (after Dapper was released); and predictably, if you backport a kernel and udev breaks, you have to backport udev too
[03:05] <pygi> jdong: so tell me, should one be ashamed of his/her's first hello world application?
[03:05] <jdong> pygi: depends on what it did
[03:05] <bluefoxicy> jdong:  but again, nobody is going to allow something like udev, a kernel, or X to be backported ever
[03:05] <bluefoxicy> there's good reason for this
[03:05] <pygi> jdong: why would it depend?!
[03:05] <jdong> pygi: mine was written in Visual Basic 6 on Windows 98 :)
[03:05] <sivang> I am ashamed of mine ;)
[03:05] <jdong> pygi: and it said "VB6 forever"
[03:05] <bluefoxicy> jdong:  I have vb6 installed under Wine I think
[03:05] <sivang> jdong: HAHAHA
[03:05] <pygi> sivang: o joys, why is that!?
[03:06] <pygi> even if the app DID NEVER START, it was something yours
[03:07] <sivang> pygi: it's a point, but frequently when I look at stuff I did in the past, I think "what the f$# was I thinking"
[03:07] <jdong> pygi: well, technically for(;;)fork(); starts.... it's just that starting is the problem :)
[03:07] <bluefoxicy> jdong:  psh
[03:07] <jdong> that was actually my first unix hello world program
[03:07] <jdong> my "friend" told me to do it
[03:07] <Keybuk> sivang: it's even more worrying when you realise people are still using things you did in the past that you think are shit
[03:07] <jdong> on a shared server
[03:08] <jdong> Keybuk: you mean like the guy who told me the other day that he's recommending pyfragtools to all his linux friends?
[03:08] <bluefoxicy> jdong:  echo '#!`:(){ :&:; }`' > ./it.sh ; . ./it.sh
[03:08] <Keybuk> the number of people on this channel using dircproxy
[03:08] <bluefoxicy> jdong:  no compiler needed ;)
[03:08] <jdong> bluefoxicy: pssh python ;-)
[03:09] <bluefoxicy> jdong:  actually, check this out.
[03:09] <sivang> Keybuk: oh goodness, I am both sorry and happy I still did not reach this point ;) (argh! another kitten)
[03:09] <pygi> heh
[03:10] <jdong> can someone resolve collegegeek.org for me?
[03:10] <pygi> cheer up :)
[03:10] <jdong> my DNS server is down
[03:10] <pygi> sure, sec
[03:10] <sivang> pygi: having a bad year ;)
[03:10] <jdong> Ubugtu should have a !resolve feature :D
[03:10] <Nafallo> jdong: 64.191.182.77
[03:10] <pygi> sivang: you must mean bad century, right?
[03:11] <Keybuk> jdong: finger DNS@158.152.1.222
[03:11] <sivang> pygi: more of, yeah 
[03:11] <Keybuk> hmm, maybe that doesn't work anymore
[03:12] <bluefoxicy> jdong:  http://rafb.net/paste/results/qlL0YE91.html  That should compile but I recommend you don't :)
[03:12] <Keybuk> sorry
[03:12] <Keybuk> .65
[03:12] <Keybuk> syndicate scott% finger collegegeek.org@158.152.1.65
[03:12] <Keybuk> [158.152.1.65] 
[03:12] <Keybuk> collegegeek.org has address 64.191.182.77
[03:12] <bluefoxicy> jdong:  you should also be able to run it as a shell script, but this is not a good idea  >:D
[03:12] <jdong> GOD that's right I can't ping the tracker if DNS is down
[03:12] <sivang> wasn't there a "recent" patch against this type of DoS's ?
[03:13] <sivang> jdong: using dnsmasq on a home made router?
[03:13] <jdong> sivang: yeah
[03:13] <purserj> morning all, can someone tell me if the move to dash for edgy has been accompanied by regression testing of packages (beyond the init scripts)?
[03:13] <jdong> sivang: is that a crime?
[03:13] <jdong> purserj: to some degree, yes
[03:13] <jdong> purserj: but I think most of that has been fixed
[03:13] <jdong> but I don't think anyone in this room will shed tears about that
[03:13] <jdong> :)
[03:14] <sivang> jdong: why not?
[03:14] <jdong> sivang: I've been told that I should grow up and learn to configure bind.....
[03:14] <jdong> but dnsmasq has worked like a charm for me, and for that I'll stick with it
[03:15] <sivang> jdong: indeed, I agree. I have used it for a while, it quite nice
[03:15] <pygi> jdong: I was told that always staying a baby is the best solution
[03:16] <Nafallo> must be the thing the linksys used before I bricked it ;-)
[03:16] <jdong> sivang: I still use dhcpd for DHCP server though
[03:16] <jdong> sivang: the dnsmasq dhcp server is a new feature for me, and I just haven't got the chance to try it yet
[03:16] <Keybuk> purserj: not a deliberate regression test
[03:17] <Keybuk> but we figure that if after a few months nobody's noticed, then it's not a major problem :p
[03:17] <sivang> jdong: works well as well. I've had a dnsmasq + its dhcp server on a p100 machine for 3 years, worked like charm.
[03:17] <Keybuk> also Nokia use dash on the 770, and got most of the patches into Debian a while back
[03:17] <jdong> Keybuk: LOL
[03:17] <sivang> jdong: and the caching seems to be serving quite well
[03:17] <jdong> sivang: yeah, no kidding. it takes me a while to notice when my ISP's DNS goes down!
[03:17] <sivang> Keybuk: does sfllaw know about this workflow? ;)
[03:18] <purserj> Keybuk, are you expecting problems when people start putting it on production systems with custom scripts?
[03:18] <Keybuk> purserj: they may have issues, but it's a simple fix for them -- just change /bin/sh to /bin/bash
[03:18] <sivang> jdong: what eventually killed this debian sarge box was a power failure which burnt the power supply. after 3 power supplies, I got lazy and did not replace it anymore
[03:19] <Keybuk> most hard-core UNIX people are pretty used to /bin/sh not being bash, e.g. from Solaris or FreeBSD
[03:19] <imbrandon> if they use custom scripts and expect /bin/sh not to be POSIX then they need to use /bin/bash ( it is only a two letter change )
[03:20] <jdong> imbrandon: yeah, but try getting ATI to listen :)
[03:20] <imbrandon> jdong, i feel about them the same i feel about nvida binary drivers, e.g. the root exploit, down with binary drivers
[03:20] <sfllaw> sivang: I'm familiar with how much testing our packages get.  ;P
[03:20] <Keybuk> sivang: ?  "configure && make"
[03:21] <Keybuk> sfllaw: testing is for users
[03:21] <Keybuk> I was going to say that if it builds, I upload it ...
[03:21] <Keybuk> ...but then I realised I don't check that half the time

[03:21] <imbrandon> heh
[03:21] <jdong> Keybuk: haha, it it builds upload it
[03:21] <jdong> boy has that reared its ugly head for me several times already
[03:22] <jdong> Keybuk: luckily for you guys, I learned that lesson in the unofficial backports tree
[03:22] <jdong> (or unluckily, if people came crying to you)
[03:22] <sfllaw> Remember folks, this guy wrote your new init system.
[03:22] <Keybuk> sfllaw: and how many bugs have been filed against it? :)
[03:22] <jdong> Keybuk: my fonts still look funny :D
[03:22] <Keybuk> jdong: I'm trying to remember what you broke
[03:23] <jdong> Keybuk: flashplayer?
[03:23] <Keybuk> ah yes
[03:23] <Keybuk> no porntube
[03:23] <jdong> Keybuk: that was an interesting story in its own...
[03:23] <jdong> Keybuk: somehow /var/cache/pbuilder/dapper.tgz had an edgy environment inside
[03:23] <jdong> :)
[03:24] <jdong> that reminds me, I don't think crimsun ever reverted that change
[03:24] <jdong> oh well, no harm done
[03:25] <Nafallo> jdong: reverted the revert? :-)
[03:25] <jdong> Nafallo: something like that :)(
[03:26] <sivang> Keybuk: was never easy when tying to configure with oci8.so , ibm_db2.so , packaging this and reconsturcting the experienc on client's system. both extension have special env vars and LD_LIBRARY_PATHs that need to be in effect to work. I also disliked its software update and the patch install tool.
[03:26] <jdong> apparently, java's plugin segfaults if firefox's version number is too large
[03:26] <jdong> and the backports version trailer put it over the limit once
[03:27] <jdong> oh boy was that a fun one to diagnose!
[03:27] <Keybuk> sivang: of course, our security policy stated that any box running PHP had to be firewalled heavily
[03:28] <bluefoxicy> jdong:  segfaults huh
[03:28] <Keybuk> one of the security guys, when asked how heavily, deadpan replied "every port, especially 80"
[03:28] <bluefoxicy> jdong:  new tell me why that is?  :)
[03:28] <jdong> bluefoxicy: yeah. makes the security part of your brain shudder doesn't it?
[03:28] <Keybuk> Solaris packaging rocks though
[03:28] <sivang> Keybuk: granted
[03:29] <bluefoxicy> jdong:  yes it does.  If you overflow a stack buffer and smash RETP/SFP up with a character array, you may very well jump into non-executable or unmapped memory and segfault.  :)
[03:29] <jdong> bluefoxicy: yeah, I'm going with the "what I don't know can't hurt me" excuse on this one :)
[03:29] <jdong> and pretend it never happened
[03:29] <bluefoxicy> jdong:  however I have no practical use for this exploit; you should only be able to get access in the context of the current user.
[03:29] <bluefoxicy> assuming, of course, such an exploit exists.
[03:30] <jdong> bluefoxicy: expecially since you need to be root to install such an exploit
[03:30] <bluefoxicy> Well, root or convince the user to run a program you gave him
[03:30] <sivang> Keybuk: http://www.zend.com/products/zend_core/zend_core_for_oracle
[03:30] <jdong> bluefoxicy: the latter has issues all of its own ;-)
[03:30] <bluefoxicy> in either case, you already have access to the account running the code.
[03:30] <bluefoxicy> still
[03:30] <bluefoxicy> is that sun's plug-in?
[03:30] <jdong> bluefoxicy: yeah
[03:30] <jdong> bluefoxicy: this was back in Hoary days... I don't know if it still applies
[03:31] <Keybuk> # Make the package, use faspac to compress it if it's set
[03:31] <Keybuk> pkgmk -o -p "`date +%Y%m%d%H%M%S`-`uname -n`" -d ./spool -f prototype
[03:31] <Keybuk> [ -z "$PB_FASPAC" ]  || $PB_FASPAC -m cpio -d ./spool || true
[03:31] <Keybuk> pkgtrans -o -s ./spool $PB_SOURCE_AREA/$PB_FILENAME_GLOB $PB_LOCAL_NAME
[03:31] <bluefoxicy> jdong:  can you change the version string fora given page with javascript
[03:31] <Keybuk> eww
[03:31] <Keybuk> actually, maybe Solaris packaging was a bit icky
[03:31] <jdong> bluefoxicy: I don't know
[03:31] <desrt> Keybuk; good policy :)
[03:31] <jdong> bluefoxicy: just rebuild firefox... dch -i  it with a ridiculously long version string
[03:31] <jdong> bluefoxicy: warty-backports had the full word "~backported" in the trailer :D
[03:32] <bluefoxicy> hah
[03:32] <sivang> Keybuk: and why the hell eveytimeit lost power, it can't boot anymore and spits out those non-human messages that you require a special solaris admin to decipher and fix? :-D
[03:33] <jdong> oh oh oh lookie lookie my ktorrent backport was accepted
[03:33] <bluefoxicy> sivang:  solaris can kiss my ass
[03:33] <bluefoxicy> I installed it once, got it multibooting with linux, booted linux
[03:33] <bluefoxicy> then booted solaris to see what it was about
[03:34] <bluefoxicy> NOTICE:  FOUND ERROR IN MBR <FIXED>  @*^ *FREEZES*
[03:34] <desrt> oh man
[03:34] <bluefoxicy> apparently I no longer had a partition table.
 is not something you want to see here
[03:34] <jdong> lol
[03:34] <jdong> especially in combination with freezing
[03:34] <bluefoxicy> DO NOT fix ANYTHING without consulting me FIRST.  EVER.
[03:34] <desrt> "fix"
[03:34] <sivang> bluefoxicy: right, that how it called me after which I refused to touch it :)
[03:35] <jdong> bluefoxicy: don't you think e2fsck takes that to an extreme though?
[03:35] <sivang> desrt: HEHE
[03:35] <jamesh> Keybuk: I noticed a problem in a package you touched last: it seems that TTF fonts aren't getting registered with the old font system correctly any more
[03:35] <sivang> bluefoxicy: HAHAH
[03:35] <jdong> bitmap for 000001 is incorrect. Fix? Bitmap for 00002 is incorrect. fix?
[03:35] <jamesh> Keybuk: seems to be problems with how mkfontdir gets invoked
[03:35] <bluefoxicy> sivang:  yeah I was like "no screw this" and never touched sun solaris again
[03:35] <Keybuk> jamesh: No. Fucking. Clue.
[03:35] <Keybuk> sorry
[03:35] <Keybuk> what's the package?
[03:35] <jdong> jamesh: are you one of the bzr launchpad supermirror guys?
[03:35] <jamesh> Keybuk: https://launchpad.net/distros/ubuntu/+source/x-ttcidfont-conf/+bug/66360
[03:35] <Ubugtu> Malone bug 66360 in x-ttcidfont-conf "x-ttcidfont-conf.defoma fails to create fonts.dir file on Edgy" [Unknown,Unknown]  
[03:36] <desrt> i hear the sun java plugin will fix your mbr if your firefox version number is too long
[03:36] <jamesh> Keybuk: looks like a simple path problem
[03:36] <sivang> bluefoxicy: man, that enterprise software did to me :)
[03:36] <sivang> s/that/what/
[03:36] <jdong> desrt: yeah, depending on what shellcode you stick in the version trailer :D
[03:36] <Keybuk> jamesh: no clue, I'm afraid
[03:36] <Keybuk> defoma and font stuff is a great big mystery to me
[03:36] <desrt> browsing the web as root -- "just don't do it."
[03:37] <jdong> desrt: yeah, especially with the nvidia exploit going around... oh wait that even works as a regular user to get root
[03:37] <sivang> desrt: you miss a handful of nice stuff you could be getting , do you really want to miss that? :)
[03:37] <jdong> :)
[03:37] <desrt> hah
[03:37] <desrt> closed-source java + closed-source video drivers for the win
[03:37] <Keybuk> jdong: that's just a crasher unless you have bad plugins
[03:37] <sivang> jdong: wouldn't imagine having an ATI would ever turn to be a godo thing, although they ight have even worse bugs nobody knows about :)
[03:38] <Keybuk> there's no known way to get the exploiting glyphs *and* shell code into a web page
[03:38] <jamesh> Keybuk: who would be best to bug about this?  It makes the font rendering of old apps look even worse than usualy :)
[03:38] <jdong> Keybuk: just the crashing is annoying enough though
[03:38] <jamesh> jdong: yeah.
[03:38] <desrt> Keybuk; write your shellcode to run the glyph-exploit
[03:39] <jdong> jamesh: I tried pushing to the supermirror earlier today and got an error
[03:39] <jdong> not sure if it's bzr's fault or the supermirrors
[03:39] <jdong> didn't have a chance to investigate
[03:39] <sivang> anyway fellas, it's been fun, but I'm way past my timezone. night all!
[03:39] <jamesh> jdong: what command did you run, and what error did you get?
[03:39] <jdong> just wondering if you were aware of any known issues
[03:39] <Keybuk> jamesh: at this point, it's probably edgy+1
[03:39] <jdong> jamesh: bzr push sftp://bazaar.launchpad.net/~jdong/pyfragtools/newgranch
[03:39] <Keybuk> jamesh: I can't help but note that the "remaining change" is "X font path"
[03:39] <Keybuk> it's entirely possible the merge is bogus
[03:39] <Keybuk> and the Debian version would work perfectly
[03:39] <Keybuk> can you check that?
[03:40] <jamesh> Keybuk: the fix is to change two simple paths in the script (as mentioned in the bug report)
[03:40] <jamesh> Keybuk: the encodings definitions needed to generate fonts.dir were moved to a different directory in edgy, so the script fails
[03:40] <Keybuk> right
[03:40] <jamesh> Keybuk: it isn't a change to the X font path
[03:40] <Keybuk> so does that make the package identical to Debian
[03:40] <Keybuk> or different?
[03:41] <jdong> jamesh: bzr: ERROR: Transport operation not possible: This is not a LocalTransport, so there is no local representation for a path %
[03:41] <jamesh> Keybuk: from what I can tell the paths used in the upstream debian package would work with Edgy while the paths in the Edgy package don't
[03:41] <jdong> jamesh: in the past I have pushed to supermirror successfully before
[03:41] <Keybuk> right
[03:41] <Keybuk> http://patches.ubuntu.com/x/x-ttcidfont-conf/x-ttcidfont-conf_24ubuntu1.patch
[03:41] <Keybuk> is the diff from Debian
[03:42] <Keybuk> so basically you're saying we should revert that?
[03:42] <jamesh> Keybuk: yeah.  The paths from the Debian package would work.
[03:42] <Keybuk> I guess that our diff is for Xorg 6
[03:42] <Keybuk> and now we're using Debian Xorg 7, the paths moved again
[03:42] <jamesh> /usr/share/X11/fonts/encodings doesn't exist on Edgy while /usr/X11R6/lib/X11/fonts/encodings does (and includes a valid encodings.dir)
[03:43] <jamesh> jdong: what is the full local directory name?
[03:44] <jdong>  /home/jdong/src/bootdefrag
[03:44] <Keybuk> probably the former existed on dapper and not edgy
[03:44] <Keybuk> daniel stone woz 'ere
[03:44] <jamesh> jdong: probably a Bazaar problem -- have you upgraded your Bazaar since?
[03:44] <Keybuk> easiest fix is just to sync from debian and pick up a russian translation in the process
[03:45] <jdong> jamesh: yeah. if it's a bzr problem then I'll investigate on my own
[03:45] <jdong> as long as it ain't supermirror
[03:48] <jamesh> jdong: check the ~/.bzr.log file -- it'll probably have a full traceback
[03:48] <jamesh> jdong: I am not sure why it would be trying to get local representations for remote paths ...
[03:59] <pygi> 4:01 AM
[04:07] <_ion> Wed Oct 18 05:07:00 EEST 2006
[04:20] <stub> Launchpad is going down in 15 minutes to allow some data migration to be done. Estimated downtime is 1 hour.
[04:38] <bluefoxicy> shit
[04:38] <bluefoxicy> launchpad is down
[04:42] <infinity> bluefoxicy: Yes, read the last thing typed before what you said.
[04:48] <bluefoxicy> infinity:  yes I wasn't paying attention, it's 10:48pm and i just realized I need to eat more than a brownie today
[04:48] <Fujitsu> Twice in 24 hours... What fun.
[04:48] <Fujitsu> With minimal warning. Fun fun fun.
[04:48] <infinity> We had lots of warning for this one.
[04:49] <infinity> We scheduled it with stub yesterday.
[04:53] <_ion> if {
[04:53] <_ion> Sorry.
[04:56] <Burgwork> although, why the entire site needs to be taken down...
[05:14] <fabbione> morning
[05:29] <fabbione> infinity: ping?
[05:32] <towsonu2003> hi
[05:32] <towsonu2003> I heard mjg59 wanted to talk to me?
[05:38] <infinity> fabbione: pong.
[05:38] <fabbione> infinity: did you have a chance to restart the rebuild of death at the DC?
[05:38] <fabbione> infinity: i need to stop the buildd here to start install tests
[05:39] <fabbione> otherwise i won't make it for RC
[05:39] <infinity> fabbione: We made a decision to hold off on the DC rebuild until post-RC, though if RC gets held up, I'll rethink that.
[05:39] <fabbione> ok
[05:39] <infinity> fabbione: But if you stop your buildd, that's fine by me.,
[05:40] <fabbione> i know it is ok for you :) i just had to make sure we had plan b around :)
[05:41] <fabbione> for i in $(seq 1 24); do touch buildd$i/EXIT-DAEMON-PLEASE && chmod 777 buildd$i/EXIT-DAEMON-PLEASE; done
[05:42] <fabbione> there.. stopping..
[05:42] <stub> Launchpad downtime looks to be another 40 minutes I'm afraid - I had to restart one of the processes.
[05:43] <sladen> towsonu2003: something about assigning bugs to acpi-support.  I think he's now gone to bed
[05:43] <towsonu2003> sladen: he already emailed me about that, it's ok.
[05:44] <sladen> towsonu2003: groovy!
[05:44] <towsonu2003> sladen: he doesn't want bugs assigned to acpi-support unless the bug specifically mentions acpi scripts
[05:44] <towsonu2003> :)
[05:45] <sladen> magic! :)
[06:19] <towsonu2003> see you
[07:26] <jdub> http://www.flickr.com/photos/geddes/272802153/
[07:26] <jdub> ^ help me baby jesus
[07:28] <ajmitch> jdub: ah, the future has arrived..
[07:29] <Burgundavia> jdub: yay! splash screens make the world go 'round
[07:29] <sladen> oh, dear, goodness
[07:30] <Burgundavia> easyubuntu has a nasty big thing on it too
[07:31] <_ion> Wow.
[07:32] <imbrandon> oh gawd
[07:32] <Burgundavia> my question is: what happened to common-customizations?
[07:32] <Burgundavia> was mdz too busy?
[07:32] <jdub> HELLO, THIS IS THE MOST IMPORTANT SOFTWARE ON YOUR DESKTOP. WE'RE GOING TO SHOW YOU A LITTLE INTRODUCTION, AND THEN ASK A BUNCH OF IRRELEVANT QUESTIONS. IT'S CALLED A WIZARD BECAUSE IT'S STUPID.
[07:33] <imbrandon> Burgundavia, most likely, i'd like to have another bof on it in mtv, i think it was defered
[07:33] <jdub> http://people.ubuntu.com/~jdub/2005/amarok-wizard-1.jpg
[07:33] <Burgundavia> imbrandon: too bad
[07:33] <jdub> ^ best wizard EVER
[07:33] <jdub> pics 1 - 5
[07:33] <Burgundavia> jdub: no, I think the ekiga one is better
[07:33] <Burgundavia> "lets ask you tonnes of questions that will confuse you"!
[07:33] <Burgundavia> we have 3 pages in teh book just because of that bloody thing
[07:34] <ajmitch> that's impressive
[07:34] <sladen> "what's missing from most software, is an interface that doesn't get in your way".... 
[07:34] <imbrandon> jdub, heh thats why in kubuntu we disable the first run wizzard for amarok and just use sane defaults
[07:34] <robitaille> so who is uncle Rodney?  He seems to like Amarok... bug 46526
[07:34] <Ubugtu> Malone bug 46526 in amarok "Amarok description in Add/Remove programs is silly" [Wishlist,Confirmed]  http://launchpad.net/bugs/46526
[07:35] <Burgundavia> imbrandon: gimp has a first run wizard too, apparently
[07:36] <imbrandon> Burgundavia, yea *ALOT* of kde apps do but we disable them and just provide sane defaults
[07:36] <Burgundavia> imbrandon: KDE - because defaults are evil! <dig?
[07:36] <imbrandon> hehe
[07:37] <robitaille> Burgundavia:  I think it is gone from Edgy...but I think gimp in Dapper had it.
[07:37] <Burgundavia> robitaille: no, it has been dead since warty
[07:38] <robitaille> I could swear I saw it in Dapper at work.. maybe it was on one of our Mandriva machine.  In any case, that's good that it is gone.
[07:39] <Burgundavia> changelog only shows it going away in edgy, but I remember a disucssion about it in the early hoary days
[07:40] <Burgundavia> ajmitch: I will kill you, you realize that
[07:40] <ajmitch> but of course
[07:40] <Burgundavia> excellent
[07:41] <Burgundavia> however, I realize fspot lacks the ability to change between view and manage mode
[07:41] <ajmitch> Burgundavia: what's worse is when you can't do anything without going through the wizard
[07:41] <Burgundavia> ajmitch: for which app? amarok?
[07:41] <ajmitch> ie click through these 10 steps to even look at the program
[07:41] <ajmitch> various apps I've run across in the past
[07:41] <ajmitch> & then removed for that reason
[07:48] <Burgundavia> back in a flash
[07:55] <Burgundavia> I need a screenshot of the logout dialog
[07:55] <Burgundavia> anybody got any smart ideas on how to do that?
[07:55] <Burgundavia> xnest doesn't give the shutdown and restart options
[07:58] <bluefoxicy> does gaim beta in edgy have voice and video
[07:58] <_ion> The dialog probably communicates with the instance of gdm that the gnome session was started from. And if it wasn't started from gdm, no dialog.
[07:58] <bluefoxicy> why am I asking this in #-devel
[07:59] <Burgundavia> bluefoxicy: afaik, no
[07:59] <Burgundavia> _ion: yep, hence the issue
[08:00] <_ion> Doesn't 'sleep 5; import -window root, click the quit button' work?
[08:01] <Burgundavia> no tried that
[08:01] <sladen> what the heck is it doing?   xwd -root -out foo.xwd  doesn't work
[08:01] <sladen> and gimp screenshot blocks
[08:02] <Burgundavia> not tried, rather
[08:08] <sladen> Burgundavia: what about vmware/qemu?
[08:08] <sladen> possibly just easier to hack the application/theme and fake it
[08:08] <Burgundavia> sladen: need a cd for that
[08:08] <Burgundavia> yep
[08:08] <Burgundavia> or ship a screenshot that doesn't show shutdown and restart
[08:11] <sladen> maybe "rebuild latest gnome-session deb with logout_no_grab patch" from googling
[08:12] <sladen> https://launchpad.net/distros/ubuntu/+source/gnome-session/+bug/59244
[08:12] <Ubugtu> Malone bug 59244 in gnome-session "gnome-session logout hang with a composite manager" [Low,Fix released]  
[08:14] <sladen> try settings GSM_NO_GRAB_SERVER or LTSP_CLIENT depending on which patch went in
[08:15] <sladen> try running a compositing manager :)
[08:15] <Burgundavia> right, that is way too much work for one screenshot, even if it is in the official book
[08:17] <lifeless> tfheen: bug 54659 has a patch in its duplicate for x64 fwiw
[08:17] <Ubugtu> Malone bug 54659 in cricket "Format.pm does not know about Ubuntu architectures" [Undecided,Unconfirmed]  http://launchpad.net/bugs/54659
[08:17] <mnepton> Burgundavia: you want to Dapper logout?
[08:17] <mnepton> s/to/the/
[08:18] <Burgundavia> mnepton: they are identical
[08:18] <mnepton> Burgundavia: just a sec
[08:19] <sladen> sudo apt-get install compiz && compiz --indirect-rendering --strict-binding --replace gconf
[08:20] <robitaille> Burgundavia:   just search for "dapper logout" in google image :)
[08:22] <Burgundavia> robitaille: need the edgy icons
[08:22] <robitaille> yeah...I just realized they are not exactly like Edgy....sigh.
[08:24] <mnepton> Burgundavia: http://people.ubuntu.com/~mneptok/logout.png
[08:24] <Burgundavia> mnepton: is that dapper or edgy?
[08:24] <mnepton> Dapper
[08:25] <robitaille> the icons are different from Edgy
[08:25] <mnepton> i can edgy, if necessary
[08:25] <jdub> gettin' edgy wit' it
[08:26] <mnepton> arr, jdub
[08:28] <_ion> mnepton: What Gtk theme is that?
[08:28] <_ion> Oh, dapper. Right.
[08:28] <Burgundavia> since I have the attention of everybody. Anybody got a cd handy that could grab me a screenshot of the keyboard chooser in edgy? it has changed
[08:29] <sladen> Burgundavia: the drop-down menu?
[08:29] <sladen> Burgundavia: or the keyboard preferences?
[08:29] <Burgundavia> sladen: in ubiquity, the keyboard chooser
[08:30] <sladen> ah sorry
[08:30] <sladen> Burgundavia: I can boot it in qemu?
[08:30] <Burgundavia> I can get it, just figured somebody else might already have it up
[08:30] <Burgundavia> I will get it tomorrow nigbht
[08:39] <Burgundavia> thanks everybody
[08:39] <Burgundavia> I need to sleep now
[08:40] <ajmitch> night Burgundavia 
[08:40] <^jcole> why does fedora have bluetooth support in gnome via vfs but ubuntu gnome does not? i can't seen to find anything in synaptic either
[08:41] <^jcole> gobexftp is another app missing
[08:42] <^jcole> is it purposely removed from ubuntu gnome?
[08:42] <^jcole> possibly some dfsg thing?
[08:46] <jdub> ^jcole: no, ubuntu just doesn't ship the vfs method
[08:47] <johanbr> ^jcole: From Edd Dumbill's blog: "... removed the crack-laden bluetooth:/// gnome-vfs hack"
[08:48] <jdub> johanbr: there is a new one
[08:48] <^jcole> johanbr: that is the "Send To Bluetooth" from a while back
[08:49] <^jcole> johanbr: i'd like obexftp in gnome on ubuntu the same as one can do on fedora... or kubuntu via konquerer
[08:50] <^jcole> ubuntu dapper --> http://blogs.gnome.org/view/jamesh/2006/10/05/0
[08:51] <jamesh> ^jcole: I compiled that stuff on Edgy
[08:51] <^jcole> jamesh: right :) my bad
[08:54] <jamesh> ^jcole: now that bluez-utils 3.7 is in edgy, it should be possible to modify the VFS method to work directly against hcid too
[08:54] <jamesh> rather than requiring an extra dbus daemon
[08:54] <jamesh> I might see if I can clean it up so other people can use it ...
[08:55] <^jcole> jamesh: that would be awesome
[08:56] <^jcole> jamesh: you might want to also add gobexftp to your list for xubuntu :)
[08:56] <jamesh> what is gobexftp?
[08:56] <dholbach> good morning
[08:56] <mdke__> morning
[08:56] <^jcole> jamesh: gtk obexftp client
[08:57] <dholbach> HAPPY HUG DAY!
[08:57] <^jcole> jamesh: it is also in fedora
[08:57] <bluefoxicy> so uh
[08:57] <^jcole> jamesh: i'm tempted to alien the rpm
[08:57] <jamesh> ^jcole: I'm not actually on the distro team
[08:57] <bluefoxicy> I noticed I can't find bounties on launchpad
[08:57] <dholbach> oh... we need to add that to http://wiki.ubuntu.com/Bluetooth somewhere
[08:57] <bluefoxicy> was there a problem?
[08:57] <bluefoxicy> lack of turn-out?  Deadbeats not paying their bounties?
[08:57] <dholbach> ^jcole: you have the link somewhere?
[08:57] <bluefoxicy> People bountying porno acts?
[08:58] <dholbach> HAPPY HUG DAY!
[08:58] <jamesh> bluefoxicy: the bounty tracker code wasn't being maintained or used, so we hid it in the UI
[08:58] <^jcole> dholbach: here is jamesh's link for gnome-vfs -> http://blogs.gnome.org/view/jamesh/2006/10/05/0
[08:58] <bluefoxicy> jamesh:  it's burried but living?
[08:58] <jamesh> bluefoxicy: yeah
[08:58] <dholbach> ^jcole: I added that to http://wiki.ubuntu.com/Bluetooth/TODO
[08:58] <bluefoxicy> jamesh:  is it dying off or is there a plan to bring it back?
[08:58] <dholbach> ^jcole: what about gobexftp?
[08:59] <bluefoxicy> jamesh:  once in a while I like to browse to see if there's anything dead-simple I can get $10 off :)
[08:59] <bluefoxicy> (I have run out of articles to write for LWN)
[08:59] <jamesh> dholbach: as I said in my blog, the Maemo obex-method needs some love before it'd be ready for desktop users
[09:00] <dholbach> jamesh: Yeah, I read that - but at least it's a good start for investigations :)
[09:00] <^jcole> dholbach: here is a source package -> http://triq.net/obexftp/gobexftp-0.2.tar.gz
[09:01] <dholbach> ok, I'll note the tarball on that page
[09:01] <jamesh> dholbach: I was thinking about cleaning it up in my spare time -- we can get rid of the osso-gwconnect dependency, and it might be best to statically link osso-gwobex into the VFS method if nothing else is going to use it ...
[09:02] <jamesh> the new hcid in the new bluez-utils upload has all the required features
[09:02] <dholbach> jamesh: it probably wouldn't hurt to have it as dependency, no?
[09:02] <dholbach> (and it works with kdebluetooth very well)
[09:02] <jamesh> dholbach: is kbluetooth using the gwobex library?
[09:03] <dholbach> libbluetooth2-dev (>= 3.7-1), libopenobex-1.0-0-dev   afaik
[09:03] <jamesh> dholbach: gwobex is a separate obex implementation (from Maemo)
[09:03] <dholbach> ah ok
[09:04] <dholbach> ^jcole: added to https://wiki.ubuntu.com/Bluetooth/TODO - thanks
[09:04] <tfheen> lifeless: thanks; edgy+1
[09:05] <mnepton> lol
[09:06] <mnepton> Bluetooth/TODO must comprise half the raw data on the 'net :/
[09:07] <BHSPitLappy> gnome just needs a good, non-scattered bluetooth utility set
[09:07] <BHSPitLappy> a nice panel icon with access to anything you'd need, and good backends of course
[09:08] <BHSPitLappy> it's definitely not even comparable to what you get with commercial OS's today
[09:08] <dholbach> BHSPitLappy: get involved in the team and help to fix it
[09:08] <jamesh> BHSPitLappy: what do you want to do with bluetooth?
[09:09] <jdub> BHSPitLappy: there is very active work going on in the gnome mobile and embedded space that is improving the situation -- more desktop hackers need to take advantage of it (as jamesh has done)
[09:09] <jamesh> would it make sense to have a single panel icon for "Ethernet" that'd let you do everything related to that?
[09:09] <jdub> hadess and jamesh are good people to talk to about it in the gnome community
[09:10] <BHSPitLappy> jamesh, uhh, do you think there's a better implementation than what you see in Windows or OSX right now?
[09:10] <jamesh> note that I am a bluetooth newbie -- I only recently got a laptop + phone that supported it
[09:11] <BHSPitLappy> you right click on a tray icon and click, "Pair new device" for example
[09:11] <BHSPitLappy> you can also launch a settings module for the system's bluetooth
[09:12] <jamesh> BHSPitLappy: I haven't played around with bluetooth on Windows or OS X much.  I know it is pretty well hidden on Windows the way Sony sets their laptops up though ...
[09:12] <BHSPitLappy> or launch a window that shows you all the devices in range, or all your pairings
[09:12] <BHSPitLappy> or browse another device's available services
[09:12] <jdub> oh, brainfart -> s/jamesh/mjg59/ 8)
[09:12] <BHSPitLappy> right now we just have a few individual services, working independently, and mostly in obscure, complex setups
[09:12] <^jcole> BHSPitLappy: agreed, i do all my gnome bluetooth from the command line, lol... kde is quite good at bluetooth imho
[09:12] <BHSPitLappy> the only easy-to-do thing is file transfers
[09:13] <BHSPitLappy> here you have a program that does file transfers to other devices, a program that will set up a headset, another that will connect to a bluetooth modem
[09:13] <jamesh> BHSPitLappy: there is a gnome-bluetooth-manager app that gives that kind of view -- it is pretty useless at the moment due to lack of integration with the other tools
[09:14] <BHSPitLappy> I saw on gnome's site, a mockup for a bluetooth panel icon and program 
[09:14] <jamesh> jdub: all I've done is recompile Maemo code and play around with the bluetooth dbus APIs a bit
[09:14] <BHSPitLappy> it might be worthy to take a look
[09:14] <BHSPitLappy> http://live.gnome.org/BluetoothManager
[09:14] <BHSPitLappy> that's a very good setup there
[09:14] <BHSPitLappy> they've got most of what I want mapped out on that page
[09:15] <jdub> jamesh: yeah. i meant matty, but wrote jamesh. i don't know how. no offense. ;)
[09:15] <infinity> tfheen: Ahh, you're up.  Feel like playing RM?
[09:15] <BHSPitLappy> in a hypothetical, of course ;) someone's just got to code it
[09:17] <^jcole> btw, i had to change "class 0x3e0100" to "class 0x000100" in hcid.conf on edgy so it would pair up on my phone
[09:18] <^jcole> worked on dapper
[09:18] <^jcole> was that changed for some reason?
[09:19] <BHSPitLappy> incidentally
[09:19] <BHSPitLappy> I'm getting a new phone tomorrow ^^
[09:19] <BHSPitLappy> according to the fedex online tracker
[09:21] <jamesh> BHSPitLappy: what type?
[09:21] <BHSPitLappy> Cingular 3125
[09:22] <^jcole>   * removed merged/obsolete patches:     - debian/patches/007_hcid_typo.patch
[09:22] <BHSPitLappy> a.k.a., the HTC StarTrek
[09:22] <^jcole> hmm
[09:23] <jamesh> BHSPitLappy: the phone companies rename the phones???
[09:23] <jdub> jamesh: and disable features on the phones!
[09:23] <Treenaks> jdub: how weird
[09:23] <BHSPitLappy> jamesh, HTC tends to make phones, and sell them to wireless providers, etc
[09:24] <BHSPitLappy> who will rebrand them
[09:24] <BHSPitLappy> and put their logo on it, give it a name
[09:24] <BHSPitLappy> this phone exists under a few different names, with different brands
[09:24] <BHSPitLappy> cingular won't rename a RAZR or a nokia phone
[09:24] <BHSPitLappy> this is just what HTC does
[09:25] <jamesh> crazy
[09:25] <jamesh> BHSPitLappy: so it runs Windows? :)
[09:26] <BHSPitLappy> yes :/
[09:26] <BHSPitLappy> it's so sad
[09:26] <^jcole> i cdma/evdo bluetooth through my phone
[09:26] <BHSPitLappy> it's been so long since I've used a Microsoft OS routinely
[09:27] <BHSPitLappy> I chose it because having Windows Mobile is still better than most phones, though, with some crappy shell interface
[09:27] <BHSPitLappy> and, the only Symbian phones I could choose from were crazy expensiv
[09:27] <BHSPitLappy> +e
[09:28] <tfheen> infinity: yes, sure
[09:28] <tfheen> tfheen: that is, after I've had a little bit of breakfast and calmed down the local whirlwind.
[09:28] <tfheen> infinity:: that is, after I've had a little bit of breakfast and calmed down the local whirlwind.
[09:29] <infinity> Breakfast sounds good.  I think I should go find food.
[09:29] <fabbione> tfheen: talking to yourself today? :P
[09:29] <^jcole> BHSPitLappy: via verizon?
[09:29] <tfheen> fabbione: exactly, hence my "after some food"
[09:30] <fabbione> ehe
[09:30] <tfheen> infinity: is there anything particular which I should tend to right away, even before breakfast or are things somewhat under control?
[09:30] <BHSPitLappy> ^jcole,     "<jamesh> BHSPitLappy: what type?  <BHSPitLappy> Cingular 3125"
[09:30] <infinity> tfheen: Just the ueue.
[09:31] <infinity>   110159 | S- | bluez-btsco          | 1:0.42-0ubuntu1      | 1 hour 30 minutes
[09:31] <^jcole> BHSPitLappy: have you done an "sdptool browse {bt id}"
[09:31] <infinity>          | * bluez-btsco/1:0.42-0ubuntu1 Component: universe Section: sound
[09:31] <jamesh> BHSPitLappy: so is there anything tying that handset to the Cingular network in particular?
[09:31] <infinity>   110158 | S- | gossip               | 0.18-0ubuntu1        | 1 hour 40 minutes
[09:31] <infinity>          | * gossip/0.18-0ubuntu1 Component: universe Section: gnome
[09:31] <infinity>   110157 | S- | glom                 | 1.1.7-0ubuntu1       | 1 hour 40 minutes
[09:31] <infinity>          | * glom/1.1.7-0ubuntu1 Component: universe Section: gnome
[09:31] <infinity>   110086 | S- | installation-guide   | 20060726ubuntu5      | 11 hours
[09:31] <infinity>          | * installation-guide/20060726ubuntu5 Component: main Section: doc
[09:31] <infinity>   110081 | S- | kdebindings          | 4:3.5.4-0ubuntu2     | 14 hours
[09:31] <infinity>          | * kdebindings/4:3.5.4-0ubuntu2 Component: main Section: devel
[09:31] <BHSPitLappy> jamesh, I dunno. I wouldn't doubt it.
[09:31] <infinity>   110077 | S- | python-setuptools    | 0.6c3-1ubuntu4       | 15 hours
[09:31] <infinity>          | * python-setuptools/0.6c3-1ubuntu4 Component: main Section: python
[09:31] <BHSPitLappy> infinity, ever heard of pastebin?????
[09:31] <infinity>   110070 | S- | pysvn                | 1.4.2+dfsg-0.1ubuntu | 16 hours
[09:31] <infinity>          | * pysvn/1.4.2+dfsg-0.1ubuntu2 Component: universe Section: python
[09:31] <ajmitch> gossip & glom are dholbach changes, they can be approved
[09:31] <infinity>   110068 | S- | xfdesktop4           | 4.3.99.1svn+r23428-0 | 16 hours
[09:31] <infinity>          | * xfdesktop4/4.3.99.1svn+r23428-0ubuntu2 Component: main Section: x11
[09:31] <infinity>   110050 | S- | human-cursors-theme  | 0.4-0ubuntu1         | 17 hours
[09:31] <infinity>          | * human-cursors-theme/0.4-0ubuntu1 Component: main Section: x11
[09:31] <infinity> BHSPitLappy: Yes.
[09:31] <infinity>   110049 | S- | pycxx                | 5.3.5+5.3.6-0ubuntu1 | 17 hours
[09:31] <infinity>          | * pycxx/5.3.5+5.3.6-0ubuntu1 Component: universe Section: python
[09:32] <infinity> BHSPitLappy: Any other questions?
[09:32] <infinity> ajmitch: Danke.
[09:32] <BHSPitLappy> is it safe to come out now?
[09:33] <infinity> pitti: Fix shadow, kthx. :)
[09:34] <pitti> Good morning
[09:34] <ajmitch> hey pitti 
[09:34] <infinity> pitti: Also, good morning. :)
[09:34] <BHSPitLappy> ditto
[09:35] <pitti> tfheen: are desktop 17.2 and alternate 17.1 good RCCs now?
[09:36] <BHSPitLappy> 7-11 is decent eatin'.
[09:36] <BHSPitLappy> not as good as QT though
[09:36] <^jcole> hot dogs and taquitos
[09:36] <infinity> If anything's really urgent, i can probably manipulate the upload queue via my phone, though I'd not lay bets on it being a good idea. :)
[09:37] <tfheen> pitti: they should be, yes.
[09:38] <dholbach> haha :)
[09:38] <pitti> infinity: fix shadow... harder?
[09:39] <infinity> pitti: Bug reopened, looks like you missed a build-dep or two.
[09:39] <pitti> infinity: argh, I suck; indeed I do
[09:39] <tfheen> infinity: installation-guide is approved. 
[09:39] <tfheen> infinity: the rest is either defer or universe.
[09:40] <dholbach> Riddell: we need to check telepathy-qt to make it buildable/installable again
[09:44] <cbx33> I found a coredump bug in f-spot
[09:44] <cbx33> anyone interested?
[09:45] <dholbach> infinity: I added some notes to bug 66690
[09:45] <BHSPitLappy> dholbach is
[09:45] <Ubugtu> Malone bug 66690 in speedcrunch "FTBFS in edgy, doesn't like qt4 environment?" [High,Unconfirmed]  http://launchpad.net/bugs/66690
[09:45] <dholbach> BHSPitLappy: I doubt that.
[09:45] <BHSPitLappy> I tried.
[09:45] <cbx33> https://launchpad.net/distros/ubuntu/+source/f-spot/+bug/66694
[09:45] <Ubugtu> Malone bug 66694 in f-spot "f-spot crashes when viewing SVG" [Medium,Unconfirmed]  
[09:46] <cbx33> it's a segfault by the looks of things
[09:46] <cbx33> I just imported a directory with a png and an svg in it, my first time using f-spot
[09:46] <cbx33> the svg was blank - I clicked on it, and it segfaulted and died
[09:47] <tfheen> cbx33: not rc.
[09:47] <mdz> morning
[09:47] <cbx33> ok np tfheen 
[09:47] <dholbach> good morning Matt
[09:47] <ajmitch> best I can do for now is forward the f-spot bug upstream
[09:48] <cbx33> thought I'd just make you guys aware
[09:49] <ajmitch> tfheen: would a fix for the f-spot bug be accepted before final release? apparantly there's a fix upstream
[09:50] <^jcole> cat /etc/skel/.bashrc.postinstall_divert | sed "s@#alias@alias@g" > /etc/skel/.bashrc
[09:50] <^jcole> crap
[09:50] <^jcole> sorry
[09:51] <pitti> tfheen, infinity: fixed shadow uploaded, this time pbuilder-tested; sorry
[09:52] <pitti> tfheen: Matt asked me to update our Firefox to RC3 (since Ian is on holiday); is that something you would want me to upload today or on Friday?
[09:54] <cbx33> ajmitch: that'd be good - just seems nasty....seeing as f-spot is nice a nd shiney and new in 6.10
[09:55] <ajmitch> ok, add a sample image as I asked in the bug report if you can
[09:57] <cbx33> sure
[09:59] <tfheen> ajmitch: probably not.
[09:59] <tfheen> pitti: uh, isn't that massively non-trivial?
[10:00] <pitti> tfheen: I'll check the diff, but it probably is absolutely nontrivial, right
[10:00] <pitti> tfheen: my gut feeling is to get RC out with the current firefox, I prepare RC3 today and ask around for testing it until Friday
[10:00] <pitti> tfheen: but it's your call, of course
[10:01] <infinity> OTOH, getting it on the RC CDs would guarantee maximum exposure.
[10:04] <mdz> pitti: after RC, yes
[10:04] <pitti> ah, hi mdz
[10:04] <cbx33> I had aproblem with firefox yesterday....well, still have aproblem infact
[10:04] <pitti> mdz: I still have to get used to you being in an European timezone :)
[10:05] <mdz> pitti: it's surely non-trivial, but upstream has said that the rc2-rc3 diff is relatively small
[10:05] <cbx33> it was looking through the plugins-extensions....this was a fresh install, with a copied home dir
[10:05] <cbx33> when it got to performancing as a plugin...which I don;t even remember installing...it sat there for ages....
[10:05] <cbx33> eventually finished
[10:05] <cbx33> but now it won;t install at all
[10:05] <cbx33> s/install/run
[10:06] <cbx33> I get no gui at all
[10:06] <cbx33> running it in terminal produces no output either
[10:06] <pitti> mdz: let's hope it doesn't break the mozembed ABI, I'll make sure to test the rdepends
[10:08] <ogra> argh, what was added between 20061017 and 20061017.1 ? my CDs grew by 5M !
[10:08] <mdz> pitti: moz_justin on freenode is an upstream contact who can confirm answers to those questions
[10:08] <dholbach> ogra: ubuntu-docs got translations - maybe that's it
[10:08] <ogra> oh, ok ... 
[10:08] <cbx33> ogra: are we oversize?
[10:08] <ogra> i'm at the limit now, please notify me if there are big additions
[10:08] <ogra> cbx33, 699M
[10:08] <cbx33> ogra: is handbook going onto CD?
[10:09] <cbx33> eeek!
[10:09] <cbx33> I guess not, as it's not finished
[10:09] <cbx33> and would probably be large 
[10:09] <ogra> cbx33, did anybody package it ? nobody notified me it would be in a packageable state
[10:09] <cbx33> no, sorry i wasn't thinking
[10:09] <cbx33> it's not finished so it won;t be able to go on
[10:10] <fabbione> hey mdz
[10:10] <ogra> i think we'll have an awesome handbook in edgy+1 (now that sbalneav is writing on it :) ) lets not release half breeded docs
[10:10] <cbx33> heh
[10:10] <cbx33> I gotta touch up the SCP docs
[10:10] <cbx33> but they are essentailly done
[10:20] <mdz> fabbione: morning
[10:20] <seb128> dholbach: do you know about ubuntu-docs translations not being used because there is no .omf shipped for those?
[10:22] <dholbach> seb128: um, I noticed a lot of .omf files in the package I uploaded and the german translation works nicely
[10:23] <seb128> dholbach: 
[10:23] <seb128> $ dpkg -L ubuntu-docs | grep "\.omf" | wc -l
[10:23] <seb128> 6
[10:23] <seb128> ii  ubuntu-docs    6.10.2         The Ubuntu Documentation Project
[10:24] <seb128> dholbach: I would not call that "lot", there are only -C.omf
[10:24] <dholbach> right, I'll double check
[10:24] <dholbach> no, that's not a lot
[10:25] <seb128> and de_DE.UTF-8 doesn't give a frontpage translated for me
[10:25] <seb128> the title of the sidebar are
[10:25] <dholbach> it's all in german for me
[10:25] <seb128> hum, I've no german locale, let me rebuild it, it's not translated in french for sure
[10:26] <seb128> dholbach: I'm curious to know how you get german without a -de.omf
[10:26] <mdz> mvo: why does the .changes for the dist-upgrader say only 'new upstream'?  the diff I saw yesterday seemed to have more detail in the changelog
[10:26] <pitti> mdz: firefox rc2->rc3: a mere 5.8 MB diff
[10:27] <seb128> pitti: going to love firefox :/
[10:27] <mdz> pitti: url?
[10:27] <pitti> (well, there's a lot of CVS crap, it's not that bad actually, I hope)
[10:27] <pitti> mdz: http://people.ubuntu.com/~pitti/tmp/2.0rc3.diff
[10:27] <pitti> mdz: I'll filterdiff it a little to clean up
[10:28] <dholbach> seb128: ok, some are translated, others are not
[10:28] <seb128> dholbach: is the frontpage full german?
[10:29] <mdz> pitti: right, that's what I was going to do
[10:29] <mdz> pitti: it even has CVS metadata in it; don't get discouraged so easily :-)
[10:29] <dholbach> seb128: one abstract is english
[10:29] <pitti> no, that's what I meant with 'lot of crap' :)
[10:30] <mdz> pitti: potpal:[~]  filterdiff -x '*/CVS/*' 2.0rc3.diff|wc -c  
[10:30] <mdz> 896443
[10:30] <seb128> dholbach: are you sure you are running the archive package and not one local build? ;)
[10:30] <dholbach> seb128: archive package
[10:30] <seb128> weird weird
[10:30] <pitti> mdz: much better already :) and a lot of stuff is hopefully s/rc2/rc3/ noise, release notes, etc.
[10:30] <mdz> potpal:[~]  filterdiff -x '*/CVS/*' 2.0rc3.diff |grep -v '^diff.*CVS' |wc -c
[10:30] <mdz> 311985
[10:31] <mdz> pitti: mostly branding changes remain
[10:33] <dholbach> seb128: I asked in #ubuntu-doc
[10:35] <seb128> dholbach: http://people.ubuntu.com/~seb128/yelp-de.png
[10:35] <seb128> dholbach: that's how yelp looks with a german locale on my edgy desktop
[10:35] <mvo> mdz: my bad, the Changelog does not (yet) auto-generate the changes file, I update it by hand
[10:36] <mvo> (the ChangLog file in the DistUpgrade dir)
[10:36] <mdz> mvo: ah, I see.  it would be comforting to be able to match the .changes with the diff more easily
[10:36] <mvo> agreed, I will fix that
[10:36] <dholbach> seb128: ah, i looked at "about ubuntu"
[10:36] <seb128> dholbach: I said "frontpage" :)
[10:37] <ogra> beautiful fonts :/
[10:37] <seb128> ogra: the yelp screenshot?
[10:37] <ogra> yeah
[10:37] <seb128> right
[10:37] <seb128> I blame firefox
[10:37] <ogra> heh
[10:37] <ogra> likely
[10:37] <dholbach> rc3 will make it better :)
[10:37] <siretart> https://launchpad.net/distros/ubuntu/+source/cryptsetup/+bug/62751/comments/27 - any objections with disabling building/installing po files for fixing FTBFS?
[10:37] <Ubugtu> Malone bug 62751 in usplash "Upstart doesn't activate luks volumes in cryptsetup" [Undecided,Unconfirmed]  
[10:37] <seb128> dholbach: maybe ;)
[10:39] <seb128> siretart: that MKINSTALLDIRS issue is probably fixeable, doesn't look like a good reason to drop translations to me
[10:39] <tfheen> mvo: about 66611 ; is our icon a derivative from the apple icon or have they been developed independently.?
[10:39] <seb128> bug #66611
[10:39] <Ubugtu> Malone bug 66611 in update-notifier "icon of application crash in the notification area - copyrighted?" [Medium,Confirmed]  http://launchpad.net/bugs/66611
[10:39] <dholbach> tfheen: glatzor is finding out
[10:40] <mvo> tfheen: I got it from a team-icon in lp, I'm currently trying to get more info. but I thinks its very similar, so it might be good if it would be replaced even if the person claims it was his original work
[10:40] <mdz> mvo: it looking similar to another icon is not an issue for the release
[10:41] <mvo> tfheen: it looks a bit like it is just anti-analised and mirrored 
[10:41] <mdz> mvo: it being derived from an icon we do not have rights to use, that would be an issue for the release
[10:41] <tfheen> mvo: what mdz says, basically.  If this is just an unfortunate choice of icon, it's not RC, if it's copyright infringement, it is.
[10:42] <pitti> ogra: edubuntu DVD is not current; do you want to update it? (I set it to 'out of date' in the testing matrix for now)
[10:42] <mdz> tfheen: do we have current DVD builds?
[10:42] <sivang> morning
[10:42] <mvo> mdz: it maybe, it looks similar enough and I suspect it might be the identical icon just mirrored and flipped
[10:42] <infinity> mvo: If the derivation is in question, I can draw you a new icon.
[10:42] <pitti> mdz: ubuntu and kubuntu are from today
[10:42] <ogra> pitti, surely i'd like it updated
[10:42] <tfheen> mdz: I haven't done, them, so I suspect no.  I'll do them now.
[10:42] <pitti> tfheen: we have 20061018??
[10:42] <mdz> tfheen: someone built them today, apparently
[10:43] <seb128> are DVD images starting by the alternate or desktop image?
[10:43] <fabbione> server is 17.1
[10:43] <pitti> that's what I was just going to put into testing/current
[10:43] <Kamion> morning
[10:43] <pitti> hi Kamion 
[10:43] <fabbione> hey Kamion 
[10:43] <mvo> infinity: that would be good
[10:43] <fabbione> Kamion: something really odd... bug #66685
[10:43] <seb128> (if I want to cat CD images and rsync from that)
[10:43] <Ubugtu> Malone bug 66685 in debootstrap "wrong free space check?" [Undecided,Unconfirmed]  http://launchpad.net/bugs/66685
[10:43] <siretart> seb128: sure. I looked at it for 20mins, but I didn't get it. :(
[10:43] <tfheen> seb128: unsure.
[10:43] <mdz> seb128: cat desktop alternate > dvd
[10:43] <Kamion> jdong: if you think the java plugin version string thing is bad, there was one strange sshd somewhere that fell over due to the addition of the Debian version to the ssh banner
[10:43] <seb128> mdz: thank you
[10:44] <Kamion> fabbione: debootstrap has a free space check? news to me
[10:44] <fabbione> Kamion: i still have console in d-i and i can give you access to look at it
[10:44] <mdz> they're sorted by filename and /casper comes first
[10:44] <mdz> s/filename/pathname/
[10:44] <pitti> testing matrix is clear, test away
[10:44] <fabbione> Kamion: dunno.. that's what syslog claims.. i didn't dig.. had to do other tests, but i did put the machine in stand-by for you
[10:44] <Kamion> that's ENOSPC
[10:44] <Kamion> if tar is saying that, it ain't my fault
[10:44] <fabbione> Kamion: ok... so it's a bug in tar?
[10:44] <Kamion> mdz: I built all the DVDs earlier, yes
[10:45] <Kamion> fabbione: stop jumping to conclusions
[10:45] <tfheen> pitti: edubuntu seems done too:
[10:45] <tfheen> : tfheen@lithium ..image.ubuntu.com/www/full > ls edubuntu/dvd
[10:45] <tfheen> 20061018/  current@
[10:45] <fabbione> pitti: argh dude.. all my tests were from this morning
[10:45] <fabbione> Kamion: right.. can i give you console on it?
[10:45] <pitti> fabbione: sorry, there was no timestamp attached; I'll restore it from the diff
[10:46] <fabbione> pitti: thanks
[10:46] <mvo> pitti: my edubuntu/alternate tests were against 20061017, so if you could restore those too that would be cool
[10:46] <Kamion> fabbione: sure, can do
[10:47] <pitti> mvo: we have 17.1 now
[10:47] <fabbione> Kamion: do you have ssh keys in LP?
[10:47] <Kamion> fabbione: yes
[10:47] <fabbione> ok setting up access for you
[10:48] <Kamion> thanks
[10:49] <pitti> fabbione: done
[10:49] <mvo> pitti: ok, I will update the caption in edubuntu then (it say 20061017)
[10:50] <fabbione> pitti: thanks
[10:50] <pitti> mvo: whoops, sorry; thanks
[10:50] <mvo> mdz: I updated #66611 - I flipped the icon and that shows that its not original art, it needs to be removed
[10:51] <mdz> bug 66611
[10:51] <Ubugtu> Malone bug 66611 in update-notifier "icon of application crash in the notification area - copyrighted?" [Medium,Confirmed]  http://launchpad.net/bugs/66611
[10:51] <mvo> look at the last attachment :/
[10:51] <pitti> mvo: I'm editing the page ATM, will fix the edubuntu timestamp
[10:51] <ogra> pitti, can you ping me when youre done, i want to add a link for the ltsp testing procedure 
[10:52] <mvo> pitti: done already I think 
[10:52] <tfheen> mvo: no, it's not the same.
[10:53] <mvo> tfheen: no?
[10:53] <tfheen> mvo: the apple one has a the firing cord going up a fair bit first, ours doesn't.
[10:53] <infinity> tfheen: I dunno, the differences could be chalked up to really crap anti-aliasing/dithering.
[10:53] <ogra> pitti, thanks :)
[10:54] <mdz> mvo: the shadow also looks a bit different
[10:55] <tfheen> mvo: also, our glare doesn't bend back.
[10:55] <tfheen> they're _quite_ similar, but I don't think it's a derivative.
[10:56] <mdz> it may be inspired but I agree, not likely to be derivative
[10:56] <tfheen> I'll untarget the bug
[10:56] <mvo> ok, I will reject the bug then
[10:57] <mvo> thanks 
[10:58] <tfheen> mvo: untargetted and comment added.
[10:58] <mvo> tfheen: thanks
[10:59] <fabbione> mdz: are we going to reschedule tomorrow's distro meeting?
[10:59] <mdz> fabbione: we haven't announced one, have we?
[10:59] <mdz> fabbione: I'm not planning to have one, no
[11:00] <fabbione> no
[11:00] <tfheen> mdz: there's one on the fridge calendar at tomorrow 2300 UTC.
[11:00] <fabbione> but it is still registered on #u-m
[11:00] <mdz> fabbione: please ask the fridge folks to remove it and mail a reminder to u-d-a
[11:00] <fabbione> mdz: ok will do
[11:03] <fabbione> mdz: should i cancel also the one for the release ='
[11:03] <fabbione> ?
[11:03] <dholbach> ogra: what are those moclecules in the edubuntu artwork?
[11:04] <mdz> fabbione: the what?
[11:04] <mdz> fabbione: oh, next week
[11:04] <mdz> fabbione: yes
[11:04] <fabbione> mdz: yeah
[11:04] <mdz> fabbione: I thought you meant cancel the release from the calendar :-)
[11:05] <fabbione> yeah right.. 
[11:05] <ogra> dholbach, cbx33 or LaserJock would know
[11:05] <fabbione> mdz: i am still waiting the number of your dealer :P
[11:05] <infinity> dholbach: Can you tell your flunkies that if they upload anything else that produces NEW binaries before the release, I might actually go insane? :)
[11:05] <cbx33> ah those molucules dholbach 
[11:06] <ajmitch> infinity: what do we need to buy you in november? :)
[11:06] <infinity> ajmitch: Nothing, it's my job, but you're welcome to give me pity. :)
[11:06] <ajmitch> heh
[11:06] <dholbach> infinity: NEW binaries? which packages were those?
[11:06] <infinity> dholbach: kphotoalbum, mclibs, paw.
[11:07] <dholbach> kphotoalbum replaced kimdaba - that I was aware of.
[11:07] <fabbione> mdz:  i did send the mail but please reject it :)
[11:07] <fabbione> it's off by 2 hours UTC that shifted to wrong dates :)
[11:08] <cbx33> you will have to ask LaserJock for the full meaning - they are from his research
[11:08] <cbx33> I just made the wallpaper
[11:08] <cbx33> :p
[11:09] <Treenaks> where can I see it?
[11:09] <fabbione> ok
[11:09] <cbx33> Treenaks: see what?
[11:09] <cbx33> the wallapper?
[11:09] <Treenaks> cbx33: the edubuntu artwork
[11:10] <Treenaks> cbx33: yes
[11:10] <cbx33> hang on I'll grab wiki page
[11:10] <cbx33> https://wiki.ubuntu.com/EdubuntuArtwork/Finals?highlight=%28artwork%29%7C%28edubuntu%29
[11:10] <cbx33> that's largely it...there were a few changes to artwork
[11:10] <cbx33> to the gdm splash
[11:11] <fabbione> mdz: ok this one is good..
[11:11] <mdz> fabbione: not in the queue yet
[11:12] <fabbione> my brain was off by one day :) the email was good
[11:12] <Treenaks> cbx33: hm, I have no idea about the chemical stuff either :)
[11:12] <cbx33> heheh
[11:12] <cbx33> LaserJock knows...he gave me a name for it....but I culdn't even say it...let alone remember it
[11:13] <Kamion> infinity: those were syncs I did
[11:13] <doko_> mvo: please could you have a look at http://people.ubuntu.com/~doko/edgy/python-central.debdiff
[11:14] <infinity> Kamion: Ahh, right, I'll blame you instead tthen, check .:)
[11:14] <Kamion> heh
[11:14] <mdz> fabbione: approved
[11:14] <fabbione> mdz: thanks
[11:17] <Kamion> dholbach: that's a big bluez-btsco change ...
[11:19] <dholbach> Kamion: nobody ever took care of it - we just had a wonky cvs checkout in the archive before.
[11:19] <pitti> mvo: http://www.ic.unicamp.br/~stolfi/PUB/misc/misc/WoMD-bomb.gif and http://www.pineight.com/tokipona/bomb.png look pretty nice, but I didn't yet find out their copyright status
[11:20] <dholbach> Kamion: the only comments I ever heard about the package we had in the archive was that it was broken - I'm subscribed to its bugs with the bluetooth team - I'm happy to work on the bugs and forward them upstream.
[11:20] <mvo> pitti: maybe we can use the xblast bombs...
[11:20] <mvo> doko_: checking
[11:20] <Kamion> dholbach: ok, your call
[11:21] <dholbach> Kamion: I'll ask people to test it and add a test case to Bluetooth/TestPlan.
[11:23] <Kamion> thanks
[11:23] <dholbach> thank you
[11:25] <pitti> mdz: I updated the diff, 250 kB now (our orig.tar.gz doesn't have other-licenses)
[11:34] <jelmer> infinity: any chance you can have a look at the failures building bzr-svn (https://launchpad.net/+builds/+build/255814) or point me at somebody who can?
[11:35] <Kamion> infinity: did you apply my patch from https://launchpad.net/distros/ubuntu/+source/ubiquity/+bug/52679?
[11:35] <Ubugtu> Malone bug 52679 in linux-source-2.6.15 "link_in_boot not set correctly" [Undecided,Rejected]  
[11:36] <tfheen> jelmer: dpkg: ../../src/packages.c:191: process_queue: Assertion `dependtry <= 4' failed.
[11:36] <tfheen> that's.. special
[11:37] <jelmer> yeah, I haven't been able to figure out what causes it
[11:38] <Kamion> means roughly "there's a dependency cycle that dpkg couldn't figure out how to break", AIUI
[11:38] <jelmer> especially as it builds fine here locally on edgy and ajmitch was able to build it fine as well
[11:38] <Kamion> (but check with iwj)
[11:38] <Kamion> jelmer: to reproduce it locally you'd need to try from a clean chroot
[11:40] <jelmer> Kamion: Hmm, that's odd - I'll try an install using piuparts
[11:41] <mdz> pitti: if you ignore mailnews, BeOS and the updated copyright notices then it's pretty manageable
[11:41] <infinity> Kamion: Argh, slipped off my queue.  I'll roll that out right now.
[11:42] <pitti> mdz: I finished reviewing the diff. It mostly looks like bug fixes; the only non-bugfix thing seems to be the addition of toolkit/themes/pmstripe/global/browser.css
[11:44] <mdz> pitti: I'm not sure that has any effect for us either
[11:44] <pitti> mdz: that file was added to the 'classic' skin jar, but well, it's only a CSS...
[11:45] <mdz> pitti: it's probably a copy of one elsewhere in the tree as well
[11:45] <pitti> however, the changes didn't prevent a linking error *grumpf*
[11:47] <mdz> pitti: oh?
[11:50] <pitti> /usr/bin/ld: nsCOMPtr.o: relocation R_X86_64_PC32 against `nsGetServiceByContractIDWithError::operator()(nsID const&, void**) const' can not be used when making a shared object; recompile with -fPIC
[11:50] <pitti> /usr/bin/ld: final link failed: Bad value
[11:51] <pitti> the funny thing is, everything *is* built with -fPIC already
[11:51] <seb128> Kamion: I usually mark duplicate bugs rejected and copy the stock message for duplication when closing them so submitter knows what is going on
[11:51] <infinity> pitti: Last time I saw that in a mozilla codebase, it had to do with visibility-hidden stuff.
[11:51] <infinity> pitti: s/-/=/
[11:51] <seb128> not sure if that's useful, but marking duplicate without any comment doesn't really make clear what is going on for the submitter imho
[11:52] <infinity> pitti: Our thunderbird (and I thought our firefox) carries a patch for that.
[11:52] <mdz> pitti: does that happen when building the existing source in edgy as well?
[11:53] <pitti> mdz: will try
[11:54] <tfheen> is there a kubuntu version of the dist-upgrader tool now?
[11:54] <mdz> mvo: bug 66708 <- !?
[11:54] <Ubugtu> Malone bug 66708 in debian-installer "Only restricted in sources.list (no main)" [Undecided,Unconfirmed]  http://launchpad.net/bugs/66708
[11:55] <pitti> infinity: it does have a patch in the diff.gz
[11:55] <mvo> mdz: yes, just happend on a edubuntu workstation install - it didn't happen on a ubuntu/amd64/cli install though
[11:55] <mdz> mvo: the log shows packages being installed from main though; very weird
[11:56] <mdz> bug 28033
[11:56] <Ubugtu> Malone bug 28033 in cdrom-checker "cdrom-checker-menu never reboots" [Medium,Confirmed]  http://launchpad.net/bugs/28033
[11:57] <mvo> mdz: might be a issue with the german mirror, I'm checking that theory right now
[11:59] <fabbione> Kamion: i reproduce it in d-i again
[11:59] <fabbione> Kamion: this time no fancy mount options.. just the same FS set
[12:00] <fabbione> Kamion: you can login again if you want.. it's a d-i shell prompt
[12:01] <Kamion> infinity: thanks
[12:01] <doko_> pitti, fabbione: the visibility stuff has problems in 4.1.x, we disabled it in qt and kde
[12:01] <doko_> infinity: ^^^ (not fabbione)
[12:01] <Kamion> seb128: well, I maintain that that's wrong for bug triagers to do; they have a higher probability of being wrong about the duplication, and it's one more thing to fix
[12:01] <Kamion> seb128: and I do think that the big stamp REJECTED discourages submitters of otherwise valid bugs
[12:02] <Kamion> even if there's other pretty text around it
[12:02] <Kamion> seb128: comments are definitely useful, but are totally orthogonal to my point about rejections
[12:02] <Kamion> seb128: and in any case going through a load of bugs that have been marked as duplicates for months and changing the status of all of them to rejected is a waste of time whichever way you slice it
[12:03] <seb128> right, I agree that changing bugs already marked as duplicated is of no use
[12:03] <minghua> seb128: by the way I just noticed that LP now auto-subscribe the subscribers of the bug marked at duplicate to the main bug
[12:03] <pitti> mdz, doko_, infinity: indeed, current firefox package fails the same way
[12:03] <Kamion> mvo: implies that the main Packages/Release files were broken
[12:03] <seb128> I'm not sure I agree on not marking new triaged as rejected though
[12:03] <seb128> minghua: it doing that for some months now I think
[12:03] <Kamion> seb128: are your triagers all perfect? mine aren't :)
[12:04] <mdz> infinity: did the rebuild test succeed?
[12:04] <pitti> doko_: what do you suggest? i. e. how to disable it?
[12:04] <infinity> pitti: That's very new, then (as of the last week)
[12:04] <mvo> Kamion: might have been a transient failure, I'm trying to reproduce it now - do you need anything more (beside the logs) from the install? if not, I will go on with the next testt-install
[12:04] <infinity> mdz: autotest was fine on all arches.
[12:04] <mdz> the upload Sunday built too
[12:04] <seb128> Kamion: no, usually they do no mark bugs as rejected though, I'm the one changing the status and adding a comment to give some feedback to the submitter :p
[12:04] <pitti> maybe it's something strange on my local system
[12:05] <Kamion> seb128: I always add a comment but don't change the status
[12:05] <seb128> you have a point
[12:05] <seb128> I think I just carry the status change habit from bugzilla or something
[12:06] <doko_> pitti: remove the test, which check for this feature? this are one or two autconf tests. but the last package did build?
[12:06] <seb128> I would prefer malone adding a stock comment when marking a bug as duplicate
[12:06] <dholbach> I agree with seb128, I think it makes sense to mark a dup as 'rejected' once you're really sure and want the discussion on that bug to subside - else you could mark as dup and still have it needsinfo to get information
[12:06] <Kamion> mvo: there's no indication of any problem in the log. :-(
[12:07] <pitti> infinity: trying on ronne now
[12:07] <mdz> pitti: is it a clean chroot?
[12:07] <Kamion> Oct 18 10:19:15 main-menu[2918] : (process:17505): Get:3 http://de.archive.ubuntu
[12:07] <Kamion> .com edgy/main Packages [932kB] 
[12:07] <Kamion> ^-- apt-setup looking happy
[12:07] <pitti> mdz: no, it's my normal work system
[12:07] <Kamion> fabbione: thanks, logged in
[12:08] <mvo> Kamion: strange error :/
[12:08] <mdz> I'm relocating to the office; back in ~35m
[12:09] <Kamion> mvo: there is one thing I could do about that, although it's a bit intrusive for edgy maybe
[12:09] <Kamion> mvo: make apt-setup-verify not bother calling apt-get update if the base system is installable from CD and the line starts with 'deb http'
[12:09] <Kamion> or 'deb-src http'
[12:10] <mvo> hm ... let me gather some more data, I will watch out for it on my test-installs
[12:10] <pitti> mdz: fails the same way on ronne
[12:14] <ogra> what is localization-config ? its not found in mvo's log 
[12:15] <Kamion> ogra: a Debian thing not relevant for us
[12:15] <ogra> ok
[12:15] <ogra> there are also many locale errors
[12:15] <Kamion> that will not be relevant
[12:15] <ogra> but thats user-setup
[12:15] <ogra> right
[12:17] <Kamion> http://people.ubuntu.com/~cjwatson/tmp/apt-setup.no-mirror-check.diff <- possible fix/workaround
[12:17] <Kamion> er, with the syntax errors now fixed too
[12:17] <Kamion> that would actually fix a lot of bugs because it would make the mirror validation slowness go away for CD install
[12:18] <Kamion> s
[12:18] <ogra> yeah
[12:18] <Kamion> tfheen: ^-- ? probably too late for RC though ...
[12:18] <ogra> i often install on my laptop with only a broadcom wlan card ... can get quite longish to wait for the mirrir check to time out 
[12:19] <ogra> *mirror
[12:20] <tfheen> Kamion: not RC, imo.
[12:22] <Kamion> tfheen: any opinions on it for edgy? I'll get it tested here ...
[12:22] <pitti> doko_: hm, disabling the visibility=hidden attribute in configure doesn't seem to help
[12:23] <tfheen> Kamion: It's just an annoyance, right?  Nothing actually breaks?
[12:23] <infinity> pitti: Given that the previous package fails for you too, I think that was a red herring on my part.
[12:23] <doko_> pitti: in all subdirs as well? hmm ...
[12:24] <pitti> doko_: subdirs? well, it's changed in confdefs.h
[12:24] <Kamion> tfheen: 10:54 < mdz> mvo: bug 66708 <- !?
[12:24] <Kamion> 10:54 < Ubugtu> Malone bug 66708 in debian-installer "Only restricted in sources.list (no main)" [Undecided,Unconfirmed]  http://launchpad.net/bugs/66708
[12:24] <Ubugtu> Malone bug 66708 in debian-installer "Only restricted in sources.list (no main)" [Undecided,Unconfirmed]  http://launchpad.net/bugs/66708
[12:25] <Kamion> d'oh, pasting Ubugtu output is silly
[12:25] <Kamion> tfheen: it's probably cosmic rays, but we're staying out in the sun without sunscreen at the moment
[12:26] <Kamion> /target/usr # touch foo
[12:26] <Kamion> touch: foo: No space left on device
[12:26] <Kamion> er, that got truncated
[12:26] <Kamion>  /target # touch foo
[12:26] <Kamion>  /target # rm foo
[12:26] <Kamion>  /target # cd usr
[12:26] <Kamion>  /target/usr # touch foo
[12:26] <Kamion>  touch: foo: No space left on device
[12:27] <Kamion> fabbione: kernel bug, IMO
[12:27] <tfheen> Kamion: and this one should fix that problem?
[12:28] <doko_> tfheen: ok to upload python-profiler (multiverse) to add the python2.5 module?
[12:28] <tfheen> doko_: ask dholbach, I don't do *verse*
[12:29] <ajmitch> doko_: might as well upload, dholbach would say the same :)
[12:30] <dholbach> ajmitch: yes :)
[12:31] <Kamion> tfheen: the effect of that patch should be that CD installs add all our default sources.list entries unconditionally
[12:31] <Kamion> without checking the mirror
[12:31] <Kamion> which is actually what I thought we *were* doing, but I missed a case
[12:33] <tfheen> Kamion: ok.. post-RC, then?
[12:33] <tfheen> I'd like not to roll new images now.
[12:33] <Kamion> tfheen: yeah
[12:34] <Kamion> tfheen: I wonder if we should roll new powerpc images for bug 52679
[12:34] <Ubugtu> Malone bug 52679 in linux-source-2.6.15 "link_in_boot not set correctly" [Undecided,Rejected]  http://launchpad.net/bugs/52679
[12:34] <Kamion> rather nasty sleeper bug
[12:34] <fabbione> Kamion: make sense..
[12:34] <Kamion> well, just desktop-powerpc
[12:34] <infinity> Kamion: I can spin a PPC livefs right now, and you can debate whether or not to make an ISO of it.
[12:35] <Kamion> infinity: yes, can you do so for all of ubuntu kubuntu edubuntu xubuntu, please?
[12:35] <infinity> Kamion: Yup.
[12:35] <Kamion> good stuff
[12:35] <infinity> Spinning.
[12:35] <infinity> \ | / - ... I really need to add a spinner to the script output.
[12:36] <pitti> Kamion, infinity: (for the record, I have the ppc/desktop tests assigned to me, and I didn't start testing them yet)
[12:36] <tfheen> Kamion: just ppc images?  I guess we can do that, yes.
[12:36] <pitti> I'll probably start doing them in about two or three hours, when the alternate tests are done
[12:38] <Riddell> infinity: could you give back telepathy-qt
[12:38] <Riddell> dholbach: it just needed the build-dep on glib-dev you added ^^
[12:39] <Riddell> ah, mdz is in England
[12:42] <dholbach> Riddell: it was not installable
[12:43] <pitti> infinity: hm, I still get the firefox link failure in a super-fresh and clean amd64 chroot; was that tested in the recent autobuild test?
[12:43] <infinity> pitti: Yes, it was tested, and it was fine.
[12:43] <pitti> bugger
[12:43] <infinity> pitti: It also built on the "real" buildds two days ago...
[12:43] <Riddell> dholbach: well it isn't built
[12:44] <pitti> infinity: would it be possible to test-build the package on a buildd without uploading/publishing it?
[12:44] <pitti> I'm at loss here...
[12:45] <doko_> dholbach, ajmitch: please approve upload of weather-util to make the build independent of the python version
[12:45] <dholbach> doko_: sure
[12:45] <infinity> pitti: I can re-test it right now, sure.
[12:46] <infinity> pitti: You want the current one retested (it pretty obviously works, though), or yours? :)
[12:46] <pitti> infinity: http://people.ubuntu.com/~pitti/tmp/ has the rc3 package
[12:46] <infinity> pitti: Kay, I'll spin that right now.
[12:46] <pitti> infinity: maybe start with mine, and if that fails, test the one in the archive?
[12:46] <pitti> infinity: *hug*, thanks
[12:46] <pitti> shouldn't take long, fails after ~ 5 minutes for me
[12:46] <infinity> Kay.
[12:47] <infinity> pitti: Same uild-deps at the one in the archive?
[12:47] <infinity> build, too.
[12:47] <pitti> infinity: yes, no changes there
[12:56] <infinity> pitti: Okay, it's building..
[12:57] <infinity> Riddell: telepathy-qt happy now.
[12:57] <mdz> infinity: firefox?
[12:58] <infinity> mdz: Testing pitti's sources on crested right now.
[12:58] <pitti> mdz: I'm at loss; it fails in a fresh clean edgy chroot, in my normal system, and on ronne
[12:58] <mdz> that's not very good news
[12:59] <pitti> let's see what the buildd test does
[12:59] <infinity> pitti: If it works on crested, I'll walk you through reproducing the EXACT same chroot, and we can see if it's the chroot, or an external factor (your environment leaking sketchy kernel, who knows)
[12:59] <infinity> s/leaking sk /leaking, sk/
[12:59] <mdz> I reviewed uploads since the last time it built and nothing caught my eye
[12:59] <pitti> infinity: also, if it works, I'd appreciate if I could get the binaries to test them in parallel
[01:00] <infinity> pitti: Of course.
[01:02] <infinity> SON OF A BITCH.  Argh.
[01:02] <infinity> (No, it didn't fail)
[01:02] <pitti> infinity: *phew*
[01:02] <infinity> But I did lose access to the livefs host I was building on without a screen session.  Go me.
[01:02] <pitti> infinity: I was just about to say, if it works on the buildd, no need to urgently track it down on my box
[01:02] <infinity> (Go sketchy power killing my laptop)
[01:05] <infinity> pitti: ffox still building happily on crested.
[01:05] <pitti> that's good news
[01:05] <infinity> And the livefs build hasn't realised it lost a terminal yet.  Here's hoping it doesn't notice until it's done..
[01:05] <pitti> I guess it's been a while since firefox was actually built on an underlying amd64 edgy, right? iwj builds on i386
[01:06] <elmo> infinity: you know about castilla right?
[01:06] <infinity> elmo: Exploded?
[01:07] <elmo> infinity: yeah - died mid-build, needs recovered blah blah
[01:07] <infinity> elmo: Cute, I didn't even do anything to it this time.  It's getting more fickle...
[01:07] <infinity> Oh, or was therea security build going on?
[01:07] <infinity> Oh, pike.
[01:07] <infinity> We should just purge that from the archive.
[01:08] <infinity> elmo: Thanks.
[01:08] <tfheen> Riddell: could you please proofread and fix the dist-upgrader information on https://wiki.ubuntu.com/EdgyReleaseCandidateAnnouncement ?
[01:09] <tfheen> mdz: https://wiki.ubuntu.com/EdgyReleaseCandidateAnnouncement is now up, a bit late, sorry.  Please proofread.
[01:09] <mdz> tfheen: thanks
[01:10] <infinity> Is there a clever way to detach a process from a terminal (from another tty) so when your old ssh session finally dies, it doesn't take the process with it? :)
[01:11] <fabbione> tfheen: shouldn't we add a link to the ReleaseNotes?
[01:11] <dholbach> hum.... I managed to hose my grub on /dev/sda  -  with "rescue broken system" -> "reinstall grub bootloader" -> /dev/sda or /dev/sda2 I get a return code 20    (/dev/sda{,2}: Not found or not a block device)  - is there anything obvious I might have missed?
[01:11] <mdz> mvo,tfheen: update-manager -c is necessary for dapper users to upgrade to edgy, yes?
[01:11] <tfheen> infinity: cryopid it and restart it in screen?
[01:11] <tfheen> infinity: http://cryopid.berlios.de/
[01:11] <infinity> tfheen: That would require cryopid being installed on the build in question in the next few seconds/minutes before the sshd dies, but okay. :)
[01:12] <mvo_> tfheen: for the upgrade, you need to give it "-c -d" (not only -d)
[01:12] <infinity> (Though it's awfully resillient.. It's been going strong for 10 minutes now..)
[01:12] <tfheen> mvo_: please fix the wiki page. :-)
[01:12] <mvo_> tfheen: I will just fix it in the page
[01:12] <tfheen> fabbione: yes, please add a link in an appropriate spot.
[01:12] <infinity> Oh, speaking of resillience and livefs builds.
[01:13] <infinity> Kamion: You can spin the ubuntu-desktop-powerpc ISO.
[01:13] <mvo> ogra: the usplash image is full of wrong colors for me on edubuntu/amd64 :/
[01:14] <infinity> pitti: I don't think ffox is going to fail (it's still building fine), but I'll let you know either way when I get back from sushi.
[01:14] <mdz> grr, someone clobbered my lock on the announcement
[01:14] <pitti> infinity: ok, who knows; I guess this was lingering for ages already then
[01:14] <pitti> infinity: so I'll download the binaries for testing here
[01:15] <mvo> mdz: that might have been me, but I haven't seen a message that it was locked
[01:15] <mdz> mvo: it's easy to miss
[01:16] <mvo> mdz: my mistake, the history shows it was there :/
[01:16] <mvo> just overwrite my changes
[01:17] <fabbione> mvo: are you next in queue?
[01:17] <fabbione> (editing the wiki?)
[01:17] <fabbione> if so can you add directly the link to https://wiki.ubuntu.com/EdgyReleaseNotes ?
[01:17] <fabbione> pointless that we edit the page a gazillion times
[01:17] <mvo> I can wait, no problem
[01:18] <fabbione> mdz: are you still editing the page?
[01:18] <fabbione> oh yes
[01:18] <fabbione> ok
[01:18] <fabbione> nevermind
[01:20] <mdz> fabbione: yes
[01:22] <Kamion> infinity: running, thanks
[01:22] <pitti> Kamion: oh, nice, contrary to yesterday an expert install asks me whether or not to install ubuntu-desktop
[01:25] <mdz> fabbione: finished for now if you have something to add
[01:25] <fabbione> mdz: ok thanks
[01:26] <mdz> Riddell: when fabbione is finished, the release candidate announcement needs proper Kubuntu upgrade instructions from you
[01:26] <Riddell> mdz: yeah, I was waiting on the wiki page lock 
[01:27] <mdz> fabbione: please also fix the duplicate text in the ubuntu upgrade instructions; that was from an edit conflict
[01:27] <Kamion> pitti: ... not something I knowingly changed
[01:29] <Kamion> mdz: should notes about intra-edgy upgrades go in EdgyUpgrades?
[01:29] <mdz> Kamion: yes, in a separate section
[01:29] <fabbione> mdz: i don't see any duplicate text.. 
[01:29] <mdz> fabbione:     *
[01:29] <mdz>       update manager explicitly. To do this, press Alt-F2 (or open a Terminal using Applications -> Accessories ->Terminal) and type the following command:
[01:29] <mdz>           o
[01:29] <mdz>             gksudo "update-manager -c -d"
[01:29] <mdz>       a Terminal using Applications -> Accessories ->Terminal) and type the command:
[01:29] <mdz>           o
[01:29] <mdz>             gksudo "update-manager -c -d"
[01:29] <mdz>       This step will not be necessary on the final release.
[01:29] <fabbione> oh
[01:30] <mdz> bug 64171
[01:31] <fabbione> it's not there... 
[01:31] <mdz> tfheen must have fixed it
[01:31] <fabbione> ok i did stop editing
[01:31] <mdz> Riddell: all yours
[01:32] <tfheen> mdz: I haven't edited it since my initial version.
[01:32] <fabbione> meh.. i am an idiot.. this is going via email..
[01:32] <fabbione> Riddell: can you please fix the URL to EdgyReleaseNotes to be a full URL and not just a wiki page name?
[01:32] <Riddell> fabbione: sure
[01:33] <fabbione> thanks
[01:34] <mdz> tfheen: there are two entries with your name in the history
[01:34] <tfheen> mdz: weird.
[01:34] <mdz> tfheen: it looks as if it was reverted in fact
[01:35] <Kamion> somebody should put {{{ }}} around that announcement so the wiki doesn't try to render the e-mail formatting
[01:35] <fabbione> mvo: can you add the apt-get dist-upgrade bug note to EdgyReleaseNotes please?
[01:35] <tfheen> maybe my browser did something silly.
[01:35] <mdz> yes, my edits have been lost
[01:35] <fabbione> you probably know better than me how to express that
[01:35] <Kamion> tfheen: can we just remove the oem-config bit from EdgyReleaseNotes?
[01:36] <tfheen> Kamion: yes
[01:36] <mdz> Riddell: let me know when you're finished so I can redo
[01:36] <Kamion> fabbione: are you still editing EdgyUpgrades? your lock has timed out
[01:36] <fabbione> i didn't edit it
[01:36] <fabbione> not even for a sec..
[01:36] <Kamion> fabbione: er, EdgyReleaseNotes I mean
[01:36] <fabbione> just read it
[01:36] <fabbione> same
[01:36] <fabbione> go ahead
[01:37] <Kamion> ok
[01:37] <tfheen> mdz: sorry. :-(
[01:38] <mvo> fabbione: yes, once its not locked anymore
[01:38] <tfheen> Riddell: kubuntu still doesn't have a dist-upgrader?
[01:38] <fabbione> mvo: ok
[01:38] <fabbione> thanks
[01:38] <Kamion> btw, I've tested that apt-setup fix (with strace to see what it was doing) and it works perfectly; IMO we should apply that post-RC
[01:38] <dholbach> I have a weird feeling about this:   Running the livecd, I mount a partition from my harddisk to /mnt, now I have lots of /mnt/sda{,1,2,3,4,5,..} entries (and not in /mnt/dev/sda*)
[01:39] <mdz> Kamion: agreed; that's been nothing but trouble
[01:40] <dholbach> and it hinders me from chrooting and fixing my grub
[01:40] <tfheen> Kamion: post-rc it is.
[01:41] <mdz> dholbach: I don't follow
[01:41] <tfheen> Kamion: I have poked the cdrom-checker bug, but I don't see why it does that.  I can reproduce it just fine, though
[01:41] <Riddell> tfheen: no it's not been possible until very recently, definately in edgy+1
[01:41] <Riddell> mdz: I'm done
[01:41] <mdz> Riddell: thanks
[01:42] <fabbione> Riddell: feh... wiki.Kubuntu ??
[01:42] <fabbione> mdz: the url for the ReleaseNotes is wrong :)
[01:42] <dholbach> mdz: in an attempt to fix grub on my harddisk (it might have been my stupidity during the installation), I boot the livecd, mount the partition on the harddisk to /mnt and now have  /mnt/sda*  entries, instead of having them in /mnt/dev/sda*
[01:43] <Riddell> fabbione: works for me (but mostly it's the shortcut I have set in konqueror)
[01:43] <mvo> am I the only one with no shutdown usplash on the livecd (amd64)?
[01:43] <dholbach> that's why grub-install gives me return code 20    /dev/sda{,2}: Not found or not a block device
[01:43] <tfheen> dholbach: cd /dev ; MAKEDEV generic
[01:44] <fabbione> Riddell: yeah it works.. still :) don't try to steal our users :P
[01:45] <mdz> ok, restored mvo and my edits
[01:45] <mdz> fabbione: fixed
[01:45] <fabbione> mdz: thanks
[01:45] <mdz> but perhaps we should have separate Ubuntu and Kubuntu release notes
[01:45] <mdz> dholbach: how did they get there?
[01:46] <mdz> dholbach: and where did your /dev go?
[01:46] <mdz> dholbach: you should still have an old static /dev on your root filesystem
[01:46] <dholbach> mdz: that's on the chrooted partition on the harddisk
[01:48] <dholbach> what I found interesting is that I have /mnt/sda*
[01:48] <dholbach> mdz: I guess (I'll retry), that on an edubuntu-desktop install to sdb, I was not cautious enough about choosing where to write grub too
[01:48] <dholbach> s/too/to
[01:48] <mdz> dholbach: that doesn't explain device nodes appearing randomly in /
[01:49] <dholbach> no, not really
[01:49] <simira> Kamion: lots of good work today! Thank you.
[01:51] <dholbach> tfheen: thanks for the tip with "MAKEDEV generic", it was good enough to make grub-install happy again
[01:51] <dholbach> and the grub is fixed again -- I'll try another install with a sata and an usb disk now
[01:51] <mdz> infinity: the sed pattern in initramfs-tools.preinst needs to be anchored
[01:52] <mdz> infinity: in order to avoid a conffile prompt on upgrade from dapper
[01:52] <mdz> infinity: -##RESUME=  +#RESUME=
[01:52] <mdz> I'll fix
[01:52] <mdz> not needed for RC
[01:54] <mdz> mvo: did this not turn up during your upgrade tests?
[01:55] <mvo> mdz: it did, see my bugreport about it
[01:55] <mvo> mdz: and my entry on the Tests/Current page :)
[01:55] <mdz> mvo: bug#?
[01:56] <mvo> mdz: bug 66599
[01:56] <mdz> mvo: I didn't see it because it's not targeted; please target to 6.10
[01:57] <mvo> mdz: right, sorry. targeted now
[01:57] <mdz> tfheen: eyeball the one-liner for me?
[01:57] <mdz> -                               sed -i -e "s/RESUME=.*/#RESUME=/" /etc/mkinitramfs/initramfs.conf
[01:57] <mdz> +                               sed -i -e "s/^RESUME=.*/#RESUME=/" /etc/mkinitramfs/initramfs.conf
[01:58] <mvo> mdz: should all the stuff found during the RC tests (e.g. bug #66726) targeted by default?
[01:58] <tfheen> mdz: "only comment out if it's not commented before".  Check.
[01:58] <fabbione> mdz: looks good
[01:59] <mdz> mvo: things which need fixing for final (and unnecessary conffile prompts generally do) should be targeted
[01:59] <ogra> mvo, i'm still waiting for Seveas, he wanted to ping me if the usplash theme stuff is fixed completely
[01:59] <Seveas> ogra, and I'm waiting for fschoep for images and mjg59 to fix usplash :/
[01:59] <mvo> ogra: I targeted #66726 for release
[02:00] <mdz> tfheen: I don't think it's necessary to include that on the CDs, but might be worthwhile to accept into the archive
[02:00] <ogra> bug 66726
[02:00] <Seveas> (bot dead)
[02:05] <fabbione> mvo: are you still editing Testing/Current? your lock did time out
[02:06] <mvo> fabbione: no, feel free to edit/overwrite, don't know why the lock is still there
[02:06] <Hobbsee> Seveas: resurrect bot, kthnksbye!
[02:06] <infinity> mdz: D'oh..  I tested it on a broken conffile, not on a good one.  Stupid me.
[02:06] <tfheen> mdz: so post-RC, then.
[02:07] <fabbione> mvo: thanks done
[02:07] <infinity> pitti: ffox built fine right up until the part where I had an invalid CurrentlyBuilding... Erk.  Re-running to get you binaries.
[02:11] <slomo> Tonio_: regarding your k9copy upload... mencoder is in multiverse and k9copy in universe
[02:12] <Tonio_> slomo: Kamion told me he would demote it to multiverse
[02:13] <Tonio_> slomo: he probably forgot, I'll ping him
[02:13] <StevenK> My local mirror has it in multiverse.
[02:14] <slomo> Tonio_: oh ok... i only saw the -changes mail
[02:14] <Tonio_> slomo: no pb :)
[02:19] <gnomefreak> i also have it in multiverse
[02:23] <infinity> Kamion: kubuntu and edubuntu livefses finished while I was at dinner.  Oh, and xubuntu just finished now.  Cheers.
[02:31] <tfheen> Kamion: so, the cdrom-checker-doesn't-reboot bug is probably a bug in debconf.  It seems to reap the wrong process.
[02:31] <tfheen> Kamion: I can _probably_ work around that by just calling reboot in the menu script.
[02:33] <pitti> infinity: ah, too bad
[02:37] <infinity> pitti: Won't take too long.
[02:39] <Kamion> tfheen: seriously? nifty
[02:39] <tfheen> Kamion: which one of them?  That it blows up or that I can fix it?
[02:39] <Kamion> slomo: I accepted it and then demoted to universe, so the -changes mail is no longer accurate
[02:39] <Kamion> tfheen: both :-)
[02:39] <Kamion> but I meant the former
[02:41] <tfheen> Kamion: of course, this doesn't make any kind of sense since it waitpid's on what I believe is the correct pid.
[02:45] <pitti> mdz: want me to upgrade mozilla-firefox-locale-all to 2.0rc3, too? This will reintroduce relatively important languages like pt-BR, which have been dropped when we went to 2.0beta in edgy
[02:46] <pitti> mdz: (this will not cause any NEW packages, there are empty transitional packages ATM)
[02:46] <tfheen> Kamion: oh, I found the bug.  confmodule_run returns a pid.  debconf(.c) never saves that in the confmodule struct.  What then happens is we wait for any child process in the same process group as ourselves and the catch the wrong one.
[02:47] <tfheen> Kamion: if we just save the fork-ed pid in the default case in confmodule_run it should all work fine.
[02:47] <tfheen> Kamion: I'm not sure I want to change those bits of cdebconf now, though
[02:47] <Kamion> no, absolutely
[02:48] <janimo> heno: i made v2 start orca in mag mode w/o speech with a one line change to the casper script, do you think it should be in the release?
[02:48] <tfheen> Kamion: the minimal-impact fix is just to add an if [ "$RET" -eq 12 ] ; then reboot ; fi to cdrom-checker-menu
[02:48] <tfheen> Kamion: I can do that.
[02:48] <Kamion> oh, yeah, that sighandler in debconf.c is dodgy#
[02:48] <Kamion> are you even allowed to waitpid in a signal handler?
[02:48] <tfheen> probably not.
[02:48] <Kamion> of course it then goes on to SAVE A DATABASE IN A SIGNAL HANDLER
[02:48] <Kamion> which I've already filed a bug on
[02:49] <Kamion> I made it not do that in the SIGCHLD case as a band-aid
[02:49] <tfheen> should we have a "clean out dodgy code from cdebconf spec" for edgy+1?
[02:49] <tfheen> there's this, there's the crack about using stdin/stdout and other things.
[02:50] <seb128> vim-tiny built without multibyte support (bug #361378), would it been considered as something to fix for edgy? A bug triager pointed it on #ubuntu-bugs, it seems to be the cause for some bugs already reported
[02:51] <tfheen> seb128: not edgy.  IMO.
[02:51] <Kamion> tfheen: the signal handling is just a bug, but I'd like to get unixsocket in for edgy+1, yes
[02:51] <pips1> bug 66726
[02:51] <Ubugtu> Malone bug 66726 in usplash "edubuntu artw ork has funny colors on amd64" [Undecided,Unconfirmed]  http://launchpad.net/bugs/66726
[02:51] <seb128> bug #66733 I mean
[02:51] <Ubugtu> Malone bug 66733 in vim "Edgy's vim-tiny doesn't have multibyte support" [Undecided,Unconfirmed]  http://launchpad.net/bugs/66733
[02:51] <seb128> tfheen: ok
[02:52] <seb128> tfheen: I'm asking because that's the default vim, and it doesn't allow to edit utf-8 files correctly apparently
[02:53] <Kamion> hmm, that is rather nasty
[02:53] <heno> janimo: does it work in gnome as well?
[02:53] <tfheen> oh, I thought vim was desktop
[02:53] <janimo> heno: I only tested in gnome :)
[02:53] <tfheen> but it's just -ship.
[02:53] <tfheen> seb128: I think we should fix it, then.  Post-RC.
[02:53] <heno> janimo: it would be nice if that could ship yes
[02:53] <Kamion> vim-tiny is minimal
[02:53] <Kamion> I'm happy to take responsibility for fixing that post-RC
[02:53] <janimo> heno: I'll attach the patch to the same bug in LP
[02:53] <tfheen> Kamion: yeah, I knew that, but I thought vim proper was -desktop.
[02:54] <seb128> Kamion: thank you
[02:54] <heno> ok, thanks
[02:54] <seb128> tfheen: the issue is vim-tiny
[02:54] <Kamion> milestoned and assigned to me
[02:54] <tfheen> seb128: yes, but it would have been less of an issue if vim (proper) was -desktop.
[02:55] <seb128> tfheen: right
[03:02] <tfheen> Kamion: http://err.no/patches/cdrom_checker_workaround_cdebconf_exit_status_propagation.diff works for me.  Post-RC?
[03:02] <infinity> pitti: chinstrap:~adconrad/ffox/
[03:03] <infinity> Kamion: Did you get my above message and re-spin the other desktop/live ISOs?
[03:04] <pitti> infinity: yay
[03:04] <infinity> pitti: Do you want a matching i386+all build to go with that?
[03:04] <infinity> pitti: I didn't build arch-indep in that build...
[03:05] <pitti> infinity: would be nice for a call for testing
[03:05] <infinity> pitti: Oh, true, I'll do i386+all and powerpc then, so you can get broad testing.
[03:05] <mdz> Riddell: what's the story with bug 63325?
[03:05] <Ubugtu> Malone bug 63325 in kde-systemsettings "systemsettings won't load the desktop_kde-systemsettings.mo translation in Edgy" [Undecided,Confirmed]  http://launchpad.net/bugs/63325
[03:07] <Riddell> mdz: I've been working on a fix but not got it totally sorted yet, if it doesn't get fixed it's not the biggest of problems
[03:07] <Kamion> infinity: yes, done
[03:07] <infinity> Kamion: Cool.
[03:07] <infinity> Just checking. :)
[03:07] <Kamion> tfheen: fine by me if it's tested
[03:09] <Kamion> sfllaw: daily-live/20061018 supersedes 20061017.2 (ubuntu, kubuntu, edubuntu) / 20061017.1 (xubuntu) but only needs to be re-tested on powerpc; the other builds have been carried over verbatim
[03:10] <cbx33> is there a known problem with printing?
[03:10] <cbx33> or was there?
[03:11] <seb128> cbx33: printing is wide
[03:12] <cbx33> um....gnome printing 
[03:12] <seb128> some extra details on what sort of issue would probably make easier for you to get a reply
[03:12] <seb128> still wide
[03:12] <seb128> I was thinking to something like
[03:12] <seb128> "printing from gedit generates only blank pages"
[03:12] <seb128> or something like that :)
[03:12] <seb128> (the example is a random example, not a real one)
[03:13] <cbx33> well....I have to confirm but since my update to edgy...printing seems totally broken
[03:13] <seb128> "totally broken" still not good
[03:13] <seb128> how broken?
[03:13] <seb128> do you get any message?
[03:13] <cbx33> I'm getting more info
[03:13] <cbx33> hang on
[03:13] <seb128> pages are not going out of the printer?
[03:13] <seb128> content is not correct?
[03:13] <cbx33> pages seem to go into the queue
[03:14] <Keybuk> tfheen: jamesh reported bug #66360, it's a trivial fix (sync from Debian -- which just brings in a translation update)
[03:14] <Ubugtu> Malone bug 66360 in x-ttcidfont-conf "x-ttcidfont-conf.defoma fails to create fonts.dir file on Edgy" [Unknown,Unknown]  http://launchpad.net/bugs/66360
[03:14] <cbx33> lemme just check the machine it's connecting to
[03:14] <Keybuk> tfheen: basically a package missed that still uses daniels X paths, rather than real ones
[03:14] <cbx33> seb128 ignore that 
[03:14] <seb128> cbx33: ?
[03:14] <cbx33> it's working now...must have just been having a slow day
[03:14] <seb128> k
[03:24] <tfheen> Keybuk: I wonder why I have /usr/share/X11/fonts still.
[03:25] <Keybuk> tfheen: upgrade?
[03:25] <tfheen> Keybuk: it should have been nuked then
[03:25] <Keybuk> mine is empty and just contains fontconfig crap
[03:26] <tfheen> yes, it's just fonts.* and encodings.dir here too.
[03:26] <mdz> Riddell: medium or low?
[03:27] <pitti> mdz: ah, the m-firefox-locale-all question more or less resolved itself -- we need to ship the matching xpis unless we want to ship with a broken hel0p
[03:27] <pitti> s/0//
[03:27] <mdz> pitti: oh, I missed that question
[03:27] <mdz> pitti: does that involve a round trip to rosetta?
[03:27] <pitti> mdz: no
[03:27] <mdz> ok
[03:27] <pitti> mdz: we don't have langpack support for Firefox yet
[03:27] <mdz> right
[03:27] <mdz> and we don't export XPIs either
[03:27] <pitti> mdz: of course I'll test all languages that we ship
[03:28] <mdz> pitti: how many of those do you speak? ;-)
[03:28] <pitti> s/ship/support/
[03:28] <pitti> mdz: well, I can't check the translations obviously, but I can check for XML failures and if the help works :)
[03:29] <pitti> I can check German, en-GB, and Russian, and I can recognize some Spanish, Czech, Polish, and French words
[03:29] <pitti> the rest is 'ah, looks nice and looks like Chinese' :)
[03:29] <mdz> pitti,sfllaw: I think the manual partitioning and auto resize test cases should be reversed in order, since it seems that usually manual partitioning is necessary to get a layout which can be auto-resized
[03:30] <mdz> the page should probably have a note about how to get there as well
[03:30] <pitti> mdz: yesterday I thought I had figured out how to get there, but I still cannot reproduce it consistently
[03:30] <mdz> erase disk -> auto-resize used to work
[03:30] <mdz> but no longer
[03:30] <mdz> (used to work in dapperish times)
[03:30] <pitti> mdz: apparently it does for Kamion
[03:31] <pitti> but not for me
[03:31] <mdz> nor me
[03:31] <mdz> (in vmware)
[03:31] <pitti> I usually do a manual install with a single large partition
[03:31] <mdz> and no swap?
[03:31] <pitti> putting swap as a first partition works, too
[03:39] <leonel> hello  where can I find or ask about  SUN JDK  in ubuntu ?
[03:39] <leonel> hello  where can I find information about updates for the    SUN JDK  in ubuntu ?
[03:40] <Mirv> leonel: ask in channel #ubuntu
[03:41] <bddebian> Howdy folks
[03:42] <leonel> ok  Mirv thanks
[03:42] <Riddell> mdz: low I guess, it just means some translations will be unused
[03:43] <doko_> tfheen: please consider http://people.ubuntu.com/~doko/edgy/python-central.debdiff for the RC, reviewed by mvo; it makes the upgrade more robust and allows people with broken installations to recover.
[03:53] <pitti> hi sbalneav 
[03:53] <sbalneav> Hey pitti!
[03:54] <sbalneav> I'll be buying you those beers I owe you soon!
[03:54] <sbalneav> :)
[03:54] <pitti> sbalneav: you'll come to UMV?
[03:54] <sbalneav> I will!
[03:54] <sbalneav> Like a bad penny, I keep turning up :)
[03:55] <pitti> sbalneav: great! I'm looking forward to seeing you again
[03:55] <sbalneav> Likewise!
[03:55] <tfheen> doko_: no, for RC it's not appropriate.
[03:57] <sladen> hope so
[03:58] <mdz> Riddell: jane pointed out that the kubuntu upgrade instructions need a bit more detail; please see the FIXME
[04:07] <mvo> fabbione: I drafted some notes about the upgrade
[04:10] <pitti> mvo, infinity: on dapper->edgy upgrade I get a conffile question about /etc/initramfs-tools/initramfs.conf (##RESUME= -> #RESUME=); is that known?
[04:11] <thom> pitti: mdz was fixing that earlier
[04:12] <mdz> pitti: fix is uploaded and queued for post-RC
[04:12] <pitti> ah
[04:12] <Riddell> mdz: done
[04:13] <mdz> Riddell: thanks
[04:14] <mdz> sfllaw: ping
[04:14] <mvo> pitti: yes, see the Testing/Current page
[04:14] <pitti> mvo: ok, thanks
[04:15] <mvo> np
[04:37] <infinity> pitti: Okay, concrete proof I need sleep sometime; I just made the same CurrenlyBuilding mistake on the other two builds.  Re-building for you. :/
[04:37] <pitti> infinity: you rock
[04:38] <infinity> pitti: Not today, I don't. :)
[04:38] <pitti> maybe today a little less than usual :)
[04:39] <mdz> pitti: so it appears that it works OK on the buildds but not in the chroots you tried?
[04:39] <pitti> mdz: right
[04:40] <infinity> mdz: Yeah, I'll have to work with pitti a bit later to see why it's not working on his box.  Could be a sleeper bug somewhere.
[04:40] <pitti> mdz: I can live with that for the moment, although it doesn't feel right
[04:40] <pitti> aah, I finally found the culprit that's breaking half of firefox translations
[04:41] <mdz> infinity: not his box or the porting box
[04:41] <mdz> pitti: oh?
[04:41] <infinity> mdz: Yeah, that's even worse.
[04:41] <pitti> mdz: yeah, installing one faulty XPI ruins a random subset of other translations :)
[04:42] <mdz> pitti: this was only on amd64 in both cases, right?  did it build for you on i386?
[04:43] <pitti> mdz: right, I didn't try i386, since I don't have an i386 edgy here ATM
[04:44] <keescook> (joining in the middle of the conversation) what wasn't building?  Can I help test?  (i've got both amd64 and i386 edgy chroots)
[04:44] <pitti> keescook: firefox isn't building for me on amd64/edgy
[04:44] <mdz> keescook: a very strange firefox build failure which happened for pitti locally, and on another manual build as well, but doesn't happen on the autobuilders
[04:44] <infinity> keescook: firefox doesn't build on ronne or on pitti's machine, but works fine on my buildds and my laptop.
[04:44] <mdz> infinity: i386 laptop?
[04:44] <pitti> mdz: ... and does happen on ronne, too
[04:45] <infinity> mdz: Yeah.
[04:45] <mdz> pitti: do you have a full build log?
[04:45] <pitti> mdz: ronne should be quite similar to the buildds, with running dapper kernel and all that
[04:45] <infinity> pitti: Will you be around tomorrow for me to walk you through recreating a buildd-alike on your machine to narrow down some variables?
[04:45] <infinity> The buildds don't run dapper kernels, they run a home-brew 2.6.15.7.
[04:45] <pitti> mdz: http://people.ubuntu.com/~pitti/tmp/firefox_1.99+2.0rc3+dfsg-0ubuntu1_amd64.build
[04:46] <pitti> infinity: can do
[04:46] <elmo> infinity: it's dapper kernel source, just custom config
[04:46] <infinity> elmo: Ahh, kay.
[04:46] <elmo> and ronne == buildds, for kernels.  for most arches.  the less well supported arches (powerpc, sparc, hppa) all run dapper kernels
[04:46] <infinity> I expect ronne's is more or less the same anyway.
[04:47] <keescook> hmm. where's the .dsc?  I can stuff it through my sbuild/schroot setup and see what happens.
[04:47] <infinity> pitti: How's your bandwidth?
[04:47] <pitti> infinity: poor
[04:47] <infinity> keescook: The .dsc is there.
[04:48] <pitti> infinity: well, 300 kB/s, but only 300 MB quota left for the next couple of days
[04:48] <keescook> infinity: ah, gotcha
[04:48] <infinity> pitti: Ow... Kay.
[04:48] <dholbach> did we get oopses like that already (installation on usb disk):  http://daniel.holba.ch/temp/oops ?
[04:48] <pitti> infinity: well, should be a little more actually
[04:48] <pitti> infinity: I have 3 GB in any seven days
[04:48] <pitti> and I'm at 80%
[04:48] <elmo> let me dist-upgrade edgy on ronne
[04:48] <elmo> it's bound to be out-of-date
[04:49] <infinity> pitti: Alright, well, the chroot tarballs are small anyway, so if you have a hot apt cache you can steal the build-deps from, it won't be too bad. :)
[04:49] <mdz> pitti: your local chroot is up-to-date, right?
[04:49] <pitti> infinity: I do have all build deps for firefox here
[04:49] <mdz> infinity: do we still wrap gcc on the buildds?
[04:49] <pitti> mdz: right, I just freshly created it and installed build-deps from CD
[04:50] <pitti> s/CD/archive/
[04:50] <infinity> pitti: Kay, tomorrow we'll play with "making it just like crested", then.
[04:50] <pitti> my main system is up to date, too
[04:50] <pitti> infinity: heh, let's :)
[04:50] <infinity> mdz: No more gcc-opt or ccache.  It's just bare g++
[04:50] <Kamion> dholbach: that's usually squashfs reacting REALLY BADLY to a badly burned CD or a dirty CD drive lens
[04:50] <mdz> pitti: can we compare the nsCOMPtr.o from a good build and a failed build?
[04:51] <dholbach> Kamion: oh good to know, I'll give it another try then - thanks.
[04:51] <infinity> mdz: We could if I hadn't blown away the chroot I used to build.  I can always re-do the amd64 build, though.
[04:51] <elmo> (no ccache?!)
[04:51] <pitti> mdz: should be fine to compare against ronne:~pitti/firefox/firefox-1.99+2.0rc3+dfsg (against infinity's build tree)
[04:52] <infinity> elmo: It was on my todo to get ccache back in one way or another after removing gcc-opt from the equation, but it wasn't a high priority, as the package that always seemed to benefit the most (12 xorg uploads in a day, yay!) was a non-issue now.
[04:53] <infinity> elmo: And taking it out of the equation does prevent some quirkier FTBFS issues with some sketchy build systems *cough*scons*cough*
[04:53] <elmo> fair enough
[04:53] <pitti> okay, powerpc/alternate and dist-upgrade is happy
[04:53] <mdz> http://www.google.co.uk/search?q=nsCOMPtr.o%3A+relocation+R_X86_64_PC32&ie=utf-8&oe=utf-8&rls=org.mozilla:en-US:unofficial&client=firefox-a
[04:54] <pitti> tfheen: so you rolled 17.2 for all architectures again? I thought only for ppc?
[04:54] <infinity> pitti: Re-rolling powerpc will re-publish everythin else under the same name/directory.
[04:54] <mdz> also bug 63814
[04:54] <Ubugtu> Malone bug 63814 in firefox "please include patch for a highly visible crash in epiphany" [Unknown,Confirmed]  http://launchpad.net/bugs/63814
[04:54] <mdz> apparently dholbach saw this before as well
[04:55] <mdz> bug 61104 seems relevant
[04:55] <Ubugtu> Malone bug 61104 in gcc-4.1 "Build process of firefox trunk is broken with both gcc 4.1.1 and gcc 4.0 !" [Undecided,Unconfirmed]  http://launchpad.net/bugs/61104
[04:55] <mdz> doko_: ^^
[04:55] <pitti> infinity: ah, so for i386 and amd64, 17.1 and .2 are identical?
[04:55] <infinity> pitti: Should be, yes.
[04:55] <infinity> pitti: Timestamps should give that way.
[04:55] <pitti> well, given that the desktop testing matrix is empty anyway, I can as well bump the version
[04:56] <pitti> infinity: s/17.2/18; s/17.1/17.2/ of course
[04:57] <infinity> pitti: Yeah, note the timestamps at http://cdimage.ubuntu.com/daily-live/20061018/ and how only the powerpc ISO is "new", the rest are a bit stale.
[04:57] <infinity> (But the torrents get re-done on each re-publish)
[04:57] <pitti> ah, sweet
[04:57] <Kamion> pitti: correct, as I said a while back
[04:57] <Kamion> 14:09 < Kamion> sfllaw: daily-live/20061018 supersedes 20061017.2 (ubuntu, kubuntu, edubuntu) / 20061017.1 (xubuntu) but only needs to be re-tested on powerpc; the other builds have been carried over verbatim
[04:58] <pitti> ah, didn't catch that
[04:59] <elmo> checking For gcc visibility bug with class-level attributes (GCC bug 26905)... test: 1: ==: unexpected operator
[04:59] <Ubugtu> Malone bug 26905 in partman-partitioning "partioning and windows" [Medium,Unconfirmed]  http://launchpad.net/bugs/26905
[04:59] <mdz> there are quite a lot of reports of this same build failure with firefox/thunderbird on the web
[04:59] <elmo> no
[04:59] <elmo> are those relevant?
[04:59] <elmo> checking For x86_64 gcc visibility bug with builtins (GCC bug 20297)... test: 1: ==: unexpected operator
[04:59] <Ubugtu> Malone bug 20297 in usplash "Hibernate does not work with usplash" [Critical,Fix released]  http://launchpad.net/bugs/20297
[04:59] <elmo> no
[04:59] <elmo> I saw that flash past in a build log
[04:59] <sfllaw> Kamion: Thanks.
[04:59] <mdz> elmo: oooh
[05:00] <elmo> god, I would kill for buildd.d.o/pkgname type shortcuts in launchpad
[05:00] <pitti> mdz: for testing I entirely disabled the visibility=hidden check in configure, didn't help
[05:00] <mdz> pitti: what does it do if the test succeeds?
[05:01] <pitti> mdz: I'll fix the == and check if it works with the bug test
[05:01] <infinity> elmo: I'm to the point of doing javascript bookmark popups in firefox to bounce me places.
[05:01] <mdz> checking For gcc visibility bug with class-level attributes (GCC bug 26905)... yes
[05:01] <mdz> checking For x86_64 gcc visibility bug with builtins (GCC bug 20297)... no
[05:01] <Ubugtu> Malone bug 26905 in partman-partitioning "partioning and windows" [Medium,Unconfirmed]  http://launchpad.net/bugs/26905
[05:01] <Ubugtu> Malone bug 20297 in usplash "Hibernate does not work with usplash" [Critical,Fix released]  http://launchpad.net/bugs/20297
[05:01] <mdz> pitti: that test passes on the buildds
[05:01] <elmo> mdz: the amd64 buildd doesn't have that unexpected operator gumph
[05:01] <mdz> infinity: what's /bin/sh on the buildds
[05:01] <infinity> Ah-ha.
[05:02] <pitti> right, == is a bashism
[05:02] <infinity> mdz: /bin/sh on the buildds is bash, because I didn't want to break the world 3 weeks ago when I noticed it hadn't been switched.
[05:02] <infinity> So, we have a winner here.
[05:02] <mdz> ok
[05:02] <mdz> so it's a gcc bug
[05:02] <mdz> but firefox works around it
[05:02] <infinity> mdz: (It's going to dash first thing in feisty)
[05:02] <mdz> but the workaround has a bashism
[05:02] <pitti> mdz: ok, I'll fix the firefox source accordingly
[05:02] <mdz> wheels within wheels
[05:02] <infinity> pitti: If you fix the bashisms, does the world work for you?
[05:02] <elmo> within wheels within wheels
[05:03] <mdz> infinity: I bet a dollar
[05:03] <infinity> I'm not taking that bet.
[05:03] <elmo> I'm test building on ronne now, will let you know
[05:03] <pitti> elmo: heh, me too; /me cancels
[05:03] <mdz> doko: is gcc 20297 the same as bug 63814?
[05:03] <Ubugtu> Malone bug 63814 in firefox "please include patch for a highly visible crash in epiphany" [Unknown,Confirmed]  http://launchpad.net/bugs/63814
[05:03] <elmo> = is the non-bash version, right?
[05:03] <infinity> elmo: yes.
[05:04] <Kamion> @bugtracker add gcc bugzilla http://gcc.gnu.org/bugzilla/
[05:04] <Kamion> wonder if I have leet Ubugtu privileges somehow
[05:04] <Kamion> gcc bug 26905
[05:04] <Ubugtu> gcc bug 26905 in c++ "default-visibility class symbol improperly resolved as hidden-visibility" [Normal,Resolved: fixed]  http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26905
[05:04] <infinity> Apparently.
[05:04] <Kamion> bingo
[05:04] <Kamion> GCC bug 20297
[05:04] <Ubugtu> gcc bug 20297 in middle-end "#pragma GCC visibility isn't properly handled for builtin functions" [Normal,Resolved: fixed]  http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20297
[05:05] <mdz> doko: I meant 61104
[05:05] <sladen> elmo: = is posix  == is bash
[05:05] <infinity> I've never understood why that Cism crept into bash anyway, but whatever.
[05:05] <infinity> Yay for confusion.
[05:05] <mdz> pitti: is that an upstream bug?
[05:06] <pitti> mdz: the bashism? no, that's a Debian specific patch to work around the gcc problem
[05:06] <mdz> yes, the bashism. ah
[05:06] <infinity> Oo, go us.
[05:06] <mdz> pitti: what does it do to work around the bug?
[05:07] <sladen> infinity: mentally I prefer '==' since '=' is something else, namely assignment.  Languages like basic are confusing to beginners because two different operators share one representation
[05:07] <elmo> the build seems to be going further, I suspect that fixes it
[05:07] <infinity> sladen: Yeah, but you can't assing in shell with $var = foo, so...
[05:07] <mdz> sladen: = is equality, == is very very equality
[05:08] <infinity> sladen: I understand why C (and perl and PHP, and many languages) need to make the distinction, but shell just plain doesn't let you do that anyway, so adding a == operator to make others more comfy with bash just ends up confusing (and making us write bad patches, apparently)
[05:09] <Ng> hey folks, apologies for being slightly offtopic, but if any of you have a SIP client, could you call 5501@canonical.com now to give us a hand with some testing please?
[05:09] <sivang> Ng: don't forget those hubackup bugs :)
[05:09] <sivang> re all
[05:09] <Ng> sivang: yeah I have them in tomboy. I noticed most of them are reported already
[05:11] <sivang> Ng: cool
[05:12] <sladen> Ng: so, who's in there?
[05:16] <pitti> mdz: it does this: VISIBILITY_FLAGS='-I$(DIST)/include/system_wrappers -include $(topsrcdir)/config/gcc_hidden.h'
[05:16] <pitti> mdz: and the latter does '#pragma GCC visibility push(hidden)'
[05:19] <elmo> ok, this isn't actually offtopic, it's for UDS
[05:19] <elmo> if you have a machine with any kind of soundcard, regardless of whether or not you have headphones or a mic, please help us stress test the conf call facility by dialing 5501@canonical.com
[05:20] <Spads> also, it helps if you try the echo test out first at 6701@canonical.com
[05:20] <pitti> does that work with ekiga?
[05:20] <elmo> pitti: yes
[05:20] <Spads> pitti: most of us are using ekiga
[05:20] <elmo> it works with any SIP capable phone
[05:20] <elmo> or client
[05:27] <Nafallo> hmm
[05:27] <Nafallo> low volume :-/
[05:27] <Ng> turning off echo cancellation is a good plan
[05:27] <pitti> Spads: if I dial 6701, I get two 'free' tones, and then a 'busy' tone; is that correct?
[05:28] <Spads> pitti: hmmm, it should stay connected, and repeat everything you say back to you
[05:28] <pitti> argh, I see, login has failed
[05:28] <pitti> I do remember seeing 'logged in' (freely translated), now it's failed'
[05:28] <Nafallo> Ng: I finally found the option, thanks :-)
[05:29] <elmo> pitti: you shouldn't need to login
[05:29] <elmo> not to get to the conf call at least
[05:29] <pitti> hmm
[05:29] <elmo> I doubt the echo test either
[05:29] <pitti> elmo: I get the same 2x free, 1x busy, hangup for 5501
[05:29] <elmo> pitti: hmm, maybe it's your firewall of death
[05:30] <pitti> sure, I disabled STUN as advised in the wiki
[05:30] <pitti> but that's only for incoming calls anyway, isn't it?
[05:30] <Nafallo> oh? supposed to disable that?
[05:31] <keescook> it seemed to me that if you're behind a NAT, and you can get registered, you don't need STUN.
[05:31] <keescook> but I've only tried sip once before.
[05:31] <pitti> hm, it says 'security check failed' in the status bar, does that mean anything?
[05:32] <keescook> not sure.  :(  wrong password?
[05:33] <pitti> it's the one I was given by mail
[05:33] <mdz> tfheen: is the current candidate still without showstoppers?
[05:33] <mdz> tfheen: and have you heard from sfllaw at all?
[05:34] <tfheen> mdz: I haven't heard of any showstoppers with them, at least.
[05:34] <tfheen> mdz: no, I haven't heard from Simon.
[05:35] <mdz> he mentioned something the other day about not feeling well I think
[05:35] <pitti> no, still 'login failed: not allowed'
[05:35] <sfllaw> Uhm, I am here.
[05:38] <pitti> mdz: ffox build is now going well for me, too
[05:38] <pitti> \o/
[05:38] <dholbach> congratulations pitti!
[05:39] <pitti> dholbach: well, the credit is due to elmo, he spotted the bashism
[05:39] <dholbach> ahhh great!
[05:39] <mdz> sfllaw: I take it you didn't see either of my messages in channel earlier?
[05:40] <doko_> mdz: 61104, tried a backport from the redhat/gcc-4_1-branch, which works for ff, but breaks the OOo build ... it's definitely fixed in 4.2
[05:40] <mdz> doko_: and we're going with 4.2 after edgy?
[05:43] <sfllaw> mdz: I saw the one about new PPC images.
[05:43] <mdz> sfllaw: I didn't say anything about new PPC images
[05:44] <doko_> mdz: not before it's released. it will branch this week
[05:44] <sfllaw> mdz: Ah, sorry.  That was Kamion.
[05:45] <sfllaw> I suppose swapping those auto-resize and manual does make sense.
[05:46] <mdz> fabbione: why are all of the sparc CD test cases marked N/A?
[05:47] <mdz> oh, the server ones aren't
[05:48] <mdz> sfllaw: there are no known showstoppers in the current candidate, but very few test cases are filled in
[05:48] <mdz> sfllaw: all of the most important ones are assigned to cr3, but he isn't in here
[05:49] <sfllaw> I'll invite him.
[05:49] <lool> seb128: around?
[05:51] <lool> seb128: I'd like to discuss the spec on easy codecs installation
[05:52] <lool> seb128: I wonder if it would make sense to extend its scope slightly to cover more problems; instead of focusing in mime type => gstreamer element mappings, we might want to provide some general feature => package mapping with a common UI to search and install packages or popup web pages
[05:53] <lool> seb128: this would at least cover the KDE use case
[05:54] <lool> seb128: concerning the storage of the mappings, I thing Xb- headers would permit some sort of simple implementation which we could automatically provision with gst-inspect at build-time, but it has some limitations because of the packages that would be in repositories not visible to apt; of course, it doesn't cover codecs which are not in packages
[05:55] <lool> seb128: finally, the specs shortly mentions that non-admin users can't install codecs, but on the other hand gstreamer perfectly permits installing plugins in ~/, so perhaps it makes sense to support this?
[05:55] <lool> (I've added most of the above on the wiki page of course, but thought it would be interesting to discuss implementation live a little)
[05:56] <mdz> Kamion: selecting 'use largest continuous free space' with only ~200M of free space seems to allow me to continue although it is doomed to fail
[05:57] <mdz> and I can't seem to convince it to offer me the resize option
[05:57] <mdz> cr3: how goes it?
[05:58] <cr3> mdz: it's going more or less, that installation bug I logged is worrying me
[05:59] <tfheen> cr3: which bug is that?
[06:00] <cr3> tfheen: 66632
[06:00] <tfheen> bug 66632
[06:00] <Ubugtu> Malone bug 66632 in linux-source-2.6.17 "Ubuntu 6.10 Desktop for i386 installation crashes" [Undecided,Needs info]  http://launchpad.net/bugs/66632
[06:02] <cr3> sorry for the crappy bug subject, I have no clue what's going on so I preferred to log the bug early instead of waiting a day while trying to gather more information
[06:03] <tfheen> yes, I'm reading the bug now, judging how critical it is.
[06:04] <wasabi> ajmitch: ping
[06:05] <tfheen> cr3: had any chance to test the media, etc on the machine?
[06:06] <cr3> tfheen: I had tested the media before, as stated in my bug report. I have been running memtest86 all morning, still not finished
[06:07] <cr3> tfheen: I will update the bug report as soon as I have new information
[06:07] <tfheen> cr3: I'm worried about your "On the other hand, I am also getting installation failures on other systems."
[06:07] <cr3> tfheen: I'm trying to get some relevant information from that system as well, and I will probably log another bug report as soon as I have some sort of substance.
[06:07] <tfheen> cr3: thanks.
[06:08] <cr3> fuck, crashed again, this time at 22% and last time at 46% :(
[06:08] <pitti> infinity: are the i386/ppc firefox builds finished?
[06:09] <mdz> cr3: have you been able to successfully install on any machines?
[06:14] <cr3> mdz: yes: t1000, t2000, Precision 380, Dimension 9150 and a couple netinstalls on gigabyte boards
[06:15] <mdz> cr3: great news; could you update Testing/Current with those results?
[06:16] <cr3> mdz: sure, but I have a few reports to generate beforehand
[06:18] <mdz> cr3: reports?
[06:21] <elmo> Kamion: ping?
[06:21] <Kamion> elmo: Rather than just pinging me, please tell me what you want and I'll reply when I'm around.
[06:21] <elmo> har har
[06:21] <cr3> mdz: certification reports, that is ultimately my responsibility so I need to generate them quickly. it shouldn't take long though, probably an hour or so
[06:23] <pitti> does anyone else apart from infinity have access to the buildds? infinity did i386 and ppc builds of firefox 2.0rc3, and I'd like to put the binaries on rookery for testing
[06:25] <tfheen> pitti: the sysadmin team has
[06:26] <pitti> elmo: ^ if you have a minute, can you please copy these binaries to chinstrap or rookery?
[06:26] <elmo> what?  soyuz builds?
[06:26] <elmo> they're not stored on the buildd
[06:28] <cr3> mdz: I have another installation crash on a Dimension 5150, any files you'd like other than /var/log/dmesg?
[06:29] <cr3> kern.log seems to contain interesting information as well
[06:30] <pitti> elmo: I guess so, infinity wanted to manually build them; he did amd64 on a buildd (crested), so I guess he used a buildd for the other arches
[06:30] <pitti> elmo: right, he spoke about an invalid CurrentlyBuilding, so this must have been a buildd
[06:32] <mdz> cr3: wiki.ubuntu.com/DebuggingSystemCrash
[06:33] <mdz> cr3: since it's reproducible, just switch to a text console while the installer goes, and you should either see the panic or at least be able to do sysrq commands to get more info
[06:33] <elmo> pitti: yeah, sorry, I don't think I can help - you really want a team soyuz person or similar
[06:33] <elmo> if he built it on crested, that's a soyuz buildd and the binaries are sent back to drescher over XMLRPC and I can't retrieve them from the buildd
[06:34] <elmo> they really should be available from the librarian, if you can find them in the web UI
[06:42] <Kamion> mdz: continuous> yes, I don't think we ever filled in that particular bit of intelligence in partman. Bug report on partman-auto please?
[06:42] <pitti> elmo: ah, thank you anyway
[06:42] <Kamion> mdz: resize> as usual, I can debug given /var/log/partman (and time to stare at it)
[06:42] <Kamion> elmo: yes?
[06:45] <Kamion> right, now that two sets of parents have left I can get some work done ;-)
[06:46] <Kamion> (though they have been very helpful otherwise ...)
[07:00] <cbx33> hi guys, inlight of future ubuntu development
[07:00] <cbx33> what language is most needed by ubuntu?
[07:00] <cbx33> c/C++/python/mono/Java...?
[07:02] <pradeep_> cbx33, i think c and python
[07:03] <thom> c/python/shell
[07:03] <thom> and you'll be pretty much laughing to start with
[07:05] <Keybuk> lua!
[07:05] <pitti> elmo: cprov does not have an accound on adare/vernadsky any more, so he cannot fetch the debs for me; those were manual builds, thus they weren't uploaded anywhere
[07:06] <mdz> Kamion: ok, it's trivially reproducible for me, so I'll do so now
[07:14] <Kamion> any chance we could get bug 60071 fixed for final?
[07:14] <Ubugtu> Malone bug 60071 in launchpad-integration "Gets confused when using --translate --pid $pid on the live cd" [Undecided,Unconfirmed]  http://launchpad.net/bugs/60071
[07:14] <tfheen> Kamion: I thought I fixed that?
[07:14] <tfheen> or rather, worked around it.
[07:15] <Kamion> tfheen: it now fails on /filesystem.squashfs/usr/bin/yelp, but same difference ...
[07:15] <Kamion> (rather than /casper/filesystem.squashfs/...)
[07:15] <tfheen> Kamion: is the cdrom mounted?
[07:16] <Kamion> tfheen: er, it's on a live CD ...
[07:17] <Kamion> (so yes)
[07:19] <mdz> Kamion: sounds awfully like a kernel issue
[07:19] <mdz> presumably /proc/pid/exe has that path
[07:20] <tfheen> mdz: yes, that's the problem.
[07:20] <mdz> we could hack around it in l-i for final
[07:21] <Kamion> tfheen: /proc/pid/cmdline doesn't always have the full path, so that doesn't work
[07:21] <mdz> but probably not fix the underlying issue
[07:21] <Kamion> $ cat /proc/7344/cmdline; echo
[07:21] <Kamion> gnome-terminal
[07:21] <elmo> Kamion: getting debconf prompts on avril's laptop in the office - 100% sure that's only ever been Ubuntu
[07:21] <Kamion> elmo: echo GET debian-installer/keymap | sudo debconf-communicate
[07:21] <tfheen> Kamion: sorry, are the squashfs-es bind-mounted inside the root?
[07:22] <Kamion> tfheen: not AFAICS
[07:22] <Kamion> certainly no /filesystem.squashfs directory
[07:22] <Kamion> no /casper either
[07:22] <Kamion>   * Don't move-mount all the squashfs-es into / since that confuses mono
[07:22] <Kamion>     (and some other apps too).  Malone: #62756
[07:22] <tfheen> Kamion: gnnr. :-/
[07:23] <tfheen> yes, that's what I hoped fixed it, but apparently not well enough
[07:23] <Kamion> I think we should be very careful about messing about with the bind/move-mounts at this point
[07:23] <mdz> Kamion: I am dead serious about hacking around it in l-i
[07:23] <Kamion> mdz: I entirely agree with you
[07:23] <tfheen> that sounds like a safer approach, yes.
[07:23] <Kamion> not much else appears to care
[07:23] <elmo> Kamion: locked 'cos the config question is still up - is it safe from a diagnosis to just go forward in the upgrade?
[07:24] <tfheen> I wonder why l-i breaks it, while mono is now happy.
[07:24] <mdz> why does mono care?
[07:24] <Kamion> elmo: less /var/cache/debconf/config.dat and see
[07:24] <Kamion> elmo: also, what default answer did it present? U.S. English?
[07:25] <tfheen> mdz: ask ajmitch or one of the other Mono guys.
[07:25] <Kamion> elmo: please don't go forward *quite* yet - shouldn't take long
[07:25] <elmo> Kamion: noting in config.dat about debian-installer
[07:25] <bhale> f-spot was looking for a config file in the squashfs
[07:25] <elmo> /var/log/installer/syslog makes it look like a ubiquity install of some sort
[07:25] <bhale> not the unionfs
[07:25] <infinity> pitti: I passed out, sorry, do you still need those builds? (they're done)
[07:26] <pitti> infinity: would be great
[07:26] <Kamion> elmo: is there a /var/log/installer/version, or a version number at the top of /var/log/installer/syslog?
[07:26] <pitti> infinity: as soon as I have them, I call for testing
[07:27] <mdz> bhale: but why?
[07:27] <mdz> was it trying to look up the location based on the path to an executable for the running process via /proc?
[07:27] <avril> Kamion: "Configuring console-setup" is the title, "The origin of the keyboard:" is the question, default answer is "United Kingdom"
[07:27] <pitti> infinity: (and, no reason to apologize for sleeping in the middle of the night) :)
[07:27] <bhale> mdz: no idea, tfheen said "hey that looks like l-i, I have a lead on a fix"
[07:27] <mdz> I don't know where else that's exposed
[07:27] <bhale> mdz: not sure on what that fix was
[07:27] <Kamion> interesting that that's the default
[07:27] <infinity> pitti: Well yeah, it's 3:30am now, but still, I wasn't planning on passing out. :)
[07:27] <avril> Kamion: no version either in separate file or at top
[07:27] <bhale> mdz: and yes at /proc
[07:28] <Kamion> avril: I'm betting it was a pre-release of espresso/ubiquity then
[07:28] <Kamion> dapper's version copied debian-installer/keymap into the installed system
[07:28] <Kamion> ubiquity (1.0.10) dapper; urgency=low
[07:28] <Kamion>   * Copy debian-installer/keymap to the installed system (closes: Malone
[07:28] <Kamion>     #40627).
[07:28] <Kamion>  -- Colin Watson <cjwatson@ubuntu.com>  Sun, 28 May 2006 15:46:48 +0100
[07:28] <avril> hmm, ok
[07:28] <avril> that's possible, I think I reinstalled this laptop from scratch when it passed from Pregnant Claire to Avril
[07:29] <Kamion> avril: go ahead with the upgrade - think we just have to suck this up as an annoyance
[07:29] <avril> Kamion: ok, cool, thanks sorry for the false positive
[07:29] <bluefoxicy> Nautilus is suddenly misbehaving, it hangs when I access a usb drive
[07:29] <infinity> pitti: chinstrap:~adconrad/ffox/
[07:29] <Kamion> it's not necessarily a false positive - ideally we'd upgrade from dapper beta without questions
[07:29] <bluefoxicy> ls sees the drive fine and I've umounted/mounted/removed/inserted it a bunch of times
[07:29] <pitti> infinity: thanks! and continue to sleep well
[07:29] <Kamion> the keymap's just damned hard to parse without the value being recorded
[07:30] <Kamion> we tried grokking it out of xorg.conf, but console-setup upstream mailed me with some convincing reasons why that was a thorny approach, and I was seeing bugs in it anyway
[07:31] <Kamion> (convincing reasons> lots of users fix broken autodetected X keymaps using GNOME - the console keymap was probably right because they managed to use it to install, but the X keymap might well not have been)
[07:31] <avril> Kamion, what about parsing /var/log/installer/syslog? ;-)
[07:31] <Kamion> avril: ewwwww. is it actually in there?
[07:31] <avril> Kamion, yep
[07:31] <avril> ubiquity: apply_keyboard: uk
[07:31] <avril> ubiquity: apply_keyboard: layout gb
[07:31] <avril> I was kidding tho
[07:31] <Kamion> avril: I know how you love parsing non-machine-readable files
[07:32] <tfheen> avril: don't give Colin ideas, please. :-P
[07:32] <avril> haha
[07:32] <Kamion> # What kind of genius logs 3.5 years of removal data in
[07:32] <Kamion> # semi-human-parseable text and nothing else?  Hmm.  That would be me. :(
[07:32] <Kamion> # MAAAAAAAAAAAAAADNESSSSSSSSSSSSSSSSS
[07:32] <avril> thank you for sharing my shame
[07:32] <Kamion> :-)
[07:32] <zul> uh..ok
[07:33] <mdz> Kamion: do we save that stuff somewhere machine-readable on current installs?
[07:33] <Kamion> mdz: yes, and in dapper too
[07:33] <Kamion>     for q in ('^console-setup/',):
[07:33] <Kamion>         misc.ex('debconf-copydb', 'configdb', 'targetdb', '-p', q,
[07:33] <Kamion>                 '--config=Name:targetdb', '--config=Driver:File',
[07:33] <Kamion>                 '--config=Filename:%s' % targetdb)
[07:33] <tfheen> removals.txt is fairly parseable, though.  I wrote something generating RSS out of it some time ago.
[07:34] <Kamion> aside from debconf-copydb having possibly the craziest command-line syntax evah
[07:34] <dholbach> hm, it seems that usbdisks get mounted during a desktop install (during/before) the partitioning step
[07:35] <jonh_wendell> Kamion: are you the person who take care of keyboard setup in edgy install?
[07:35] <Kamion> jonh_wendell: yes
[07:35] <jonh_wendell> Kamion: can you take a look at bug 66774?
[07:35] <Ubugtu> Malone bug 66774 in ubiquity "Wrong configuration for Brazilian keyboard" [Undecided,Confirmed]  http://launchpad.net/bugs/66774
[07:36] <mdz> Kamion: alternate install in vmware prompts for the X mode?!
[07:36] <mdz> is that normal?
[07:37] <Kamion> mdz: yes - vmware doesn't expose that information
[07:37] <tfheen> Kamion: didn't your xorg upload fix https://launchpad.net/distros/ubuntu/+source/xutils-dev/+bug/65264 ?
[07:37] <Ubugtu> Malone bug 65264 in xutils-dev "Dapper-Edgy upgrade: three packages are still from dapper" [Undecided,Confirmed]  
[07:37] <Kamion> AFAIcouldT last I looked
[07:37] <infinity> mdz: It did in dapper as well.
[07:37] <Kamion> jonh_wendell: ok, shame I found out about this so late
[07:38] <infinity> mdz: (I know, since I just did a few dapper test installs in vmware for upgrade testing)
[07:38] <Kamion> jonh_wendell: may be fixable for edgy, possibly. thanks
[07:38] <mdz> I don't remember dapper doing that for me, weird
[07:39] <Kamion> tfheen: yes, I'll close it, thanks
[07:39] <jonh_wendell> Kamion: thank you
[07:47] <bluefoxicy> Keybuk:  hey check this bootchart out.
[07:47] <Keybuk> ...?
[07:48] <bluefoxicy> http://bluefox.kicks-ass.org/stuff/bluefox/images/edgy-20061018-1_desktop.png
[07:49] <Keybuk> does that thing have an ATI/ALi sound card chip, by any chance?
[07:49] <bluefoxicy> 00:09.0 Multimedia audio controller: Creative Labs SB Audigy (rev 03)
[07:49] <bluefoxicy> nope
[07:49] <Keybuk> what about the onboard?
[07:49] <bluefoxicy> it's disabled in bios.
[07:50] <Keybuk> just wondering what that long modprobe is
[07:50] <bluefoxicy> no clue.
[07:50] <Keybuk> got a copy of /var/log/udev available?
[07:51] <bluefoxicy> http://bluefox.kicks-ass.org/stuff/bluefox/udev
[07:52] <bluefoxicy> Keybuk: can you get udev up earlier, by any chance?
[07:52] <bluefoxicy> or well, it starts pretty early heh.
[07:53] <Keybuk> bluefoxicy: nothing much happens before udev
[07:53] <bluefoxicy> Better question:  What's about the best you can do to get modules loaded as early as technically possible
[07:53] <Keybuk>       8.710907  add@/devices/pci0000:00/0000:00:09.0/0-0:TR28602
[07:53] <Keybuk> what's that one?
[07:54] <bluefoxicy> Keybuk:  Windows XP does its 'preload' (readahead) at boot "while loading drivers" because "drivers take time to initialize and we can capitalize on that time spent doing nothing" or something.  That's what sparked my whole readahead thing. :)
[07:54] <Keybuk> oh, your sound card
[07:54] <bluefoxicy> yeah, it is.  Hm.
[07:54] <Keybuk> bluefoxicy: that's what we tried to do ... except that we don't just load drivers, we do lots of other bits, that also need readahead
[07:54] <Keybuk> the other one is your usb hub
[07:54] <bluefoxicy> hmm
[07:54] <Kamion> and also some of the drivers that take longest to initialise are things like SCSI disk drivers and RAID controllers
[07:55] <bluefoxicy> Kamion:  nods.
[07:55] <bluefoxicy> Kamion:  for everything else, there's Vesa?
[07:56] <bluefoxicy> Keybuk:  will that go away when udevsettle is killed off?
[07:57] <mdz> pitti: great, thank you
[07:57] <bluefoxicy> boot time is a bunch of little CPU and IO spikes :/  I'm actually pretty amazed at how difficult it is to turn it into one giant massive spike of IO and CPU
[07:57] <mdz> sfllaw: how is i386?
[07:57] <pitti> mdz: I can't get ubiquity to offer resizing to me, but it worked fine in d-i
[07:58] <mdz> pitti: I got it to work
[07:58] <mdz> my virtual disk needed to be bigger
[07:58] <Keybuk> bluefoxicy: the fact that the rest of the boot waits for your sound card to faff will go away, yes
[07:58] <infinity> sfllaw: I noticed you put me on the testing matrix for powerpc.  My powerpc machine can't boot from CDs. :)
[07:59] <pitti> mdz: hm, I tried with bootstrap/256MB swap/35GB root, bootstrap/35GB root/256 MB swap, and boostrap/36GB root; no dice :(
[07:59] <mdz> pitti: dunno about powerpc
[07:59] <Nafallo> lol
[08:00] <pitti> Kamion: yay
[08:01] <pitti> mdz: for the record, firefox 2.0rc3 is prepared and ready for testing on people, locales updated, fixed, and tested, reverse dependencies tested; looks pretty good
[08:01] <tfheen> "ready for testing on people" sounds like a new drug or biochem weapon or something.
[08:02] <Nafallo> tfheen: maybe it is :-)
[08:02] <thom> most mozilla products could be reclassified as pyschological warfare
[08:03] <mdz> pitti: is there a mail about it?  I'll give it some testing here
[08:03] <mdz> ah, there it is, on -devel
[08:07] <Kamion> pitti: first time since breezy that powerpc has gone vaguely smoothly
[08:07] <Kamion> this is good news
[08:10] <Kamion> mdz: I always just use vmware's default "8GB, split into 2GB chunks"
[08:10] <Kamion> which is more than adequate
[08:10] <mdz> I usually keep them small because I preallocate them
[08:11] <mdz> usually 4G
[08:11] <mdz> 6G is enough to get the resize option so I'm using that now
[08:11] <Kamion> seb128: I've just done two consecutive amd64 desktop CD boots both of which failed to start gnome-settings-daemon
[08:11] <mdz> I learned this lesson during the dapper release but forgot it
[08:11] <Kamion> seb128: what do you need me to do?
[08:11] <mdz> I thought that was fixed
[08:12] <Kamion> except this time at least it managed to start a usable desktop; last time it seemed to just hang
[08:13] <Kamion> starting it by hand appears to work fine
[08:13] <Kamion> classic, strace it and it goes away :(
[08:14] <pitti> mdz: yup, I mailed u-devel
[08:14] <pitti> Kamion: indeed, after the recent ubiquity fixes it went surprisingly smooth today
[08:14] <tfheen> Kamion: it fails during boot because too much other stuff is going on.  It's a timeout.
[08:14] <tfheen> Kamion: the fix is to increase the dbus activation timeout.
[08:15] <pitti> Kamion: we increased the timeout from 25 to 40 seconds lately
[08:15] <pitti> Kamion: if that's still not enough, we have to increase it further, maybe 60 seconds
[08:15] <pitti> slomo: ^ FYI
[08:15] <Kamion> where does it need to be fixed? g-s-d or dbus?
[08:16] <slomo> dbus
[08:16] <tfheen> at least that has been the problem in the past.
[08:16] <Kamion> it gives a pretty poor impression of the desktop CD, and this is not that slow a machine - increasing that for final sounds relatively safe to me
[08:16] <infinity> Is this timeout a compiled-in thing?
[08:16] <tfheen> infinity: yes.
[08:16] <infinity> Cause it seems one would want a ridiculously long one for the live session, but a shorter one for an installed system.
[08:17] <infinity> Shame.  So casper can't fiddle with it. :/
[08:17] <tfheen> we could binpatch it..
[08:17] <tfheen> we should just not use dbus activation for this, IMO.
[08:17] <slomo> infinity, tfheen: nope, it's set in the session bus configuration in /etc
[08:17] <infinity> slomo: Ahh, so there's hope.
[08:18] <Kamion> there's /etc/dbus-1/session-local.conf which casper could write
[08:18] <shawarma> Where can I find a list of the packages installed on the Ubuntu Live CD and the Kubuntu Live CD? (I'm here assuming that it's not just equivalent to [k] ubuntu-desktop and all their dependencies)
[08:18] <slomo> Kamion: "<limit name="service_start_timeout">40000</limit>" in /etc/dbus-1/session.conf
[08:19] <Kamion> shawarma: *.manifest files alongside each of them on cdimage
[08:19] <Kamion> slomo: not here
[08:19] <shawarma> Kamion: Of course. thanks.
[08:19] <slomo> Kamion: oh damn, the patch for it is wrongly applied in the package... i'll add this correctly after RC or now if you want
[08:19] <mdz> tfheen,Kamion: I've created a 'later' milestone for the 'ooh, really should fix that after the release' bugs
[08:19] <tfheen> mdz: thanks,
[08:19] <Kamion> slomo: after RC, please
[08:20] <mdz> it's a milestone on edgy and might look a little weird but it's something
[08:20] <slomo> pitti: i wonder what fixed it for you then... :/
[08:20] <infinity> slomo: But please prepare it now, so it can be reviewed and we can get it in immediately post-RC, if it's sane.
[08:20] <Kamion> yeah, I've just been uploading my post-RC fixes so that they can sit in the queue
[08:20] <slomo> infinity: it's just a one-line addition to another file, i forgot that we don't use upstream's session.conf but have our own in debian/
[08:20] <mc44> pitti: not that this is a regression from rc2, but firefox rc3 still breaks on rss feeds re: bug 61182 - this is not broken in vanilla upstream firefox. I don't know if any who cares for firefox has actually looked at this bug...
[08:20] <Ubugtu> Malone bug 61182 in firefox "Mozilla Firefox Bon Echo Beta 2 Doesn't show RSS Feed preview" [Unknown,Rejected]  http://launchpad.net/bugs/61182
[08:21] <mdz> Kamion: this was more for immediately after final
[08:21] <shawarma> Kamion: Is the manifest by any chance generated from the ubuntu-desktop with some additions? I suppose what I'm actually looking for is what packages are installed on the Live CD, but are not part of ubuntu-desktop (and the same for Kubuntu).
[08:21] <mdz> ubuntu-6.10 is appropriate for post-RC
[08:22] <Kamion> mdz: yeah, my comment was unrelated to your comment about milestones; I was replying to 19:20 < infinity> slomo: But please prepare it now, so it can be reviewed and we can get it in immediately post-RC, if it's sane.
[08:22] <Kamion> shawarma: ubuntu-minimal + ubuntu-standard + ubuntu-desktop + ubuntu-live [+ make sure the right kernel is there] 
[08:22] <infinity> shawarma: There's an "ubuntu-live" task. (apt-get install ubuntu-live^)
[08:22] <shawarma> infinity, Kamion: aha! Excellent. Thanks!
[08:22] <infinity> shawarma: And the one Kamion missed was casper, which isn't in any task. :)
[08:22] <mdz> Kamion: gotcha
[08:23] <Kamion> shawarma: easier to see in the seeds (http://people.ubuntu.com/~cjwatson/seeds/edgy/ for a read-only mirror of the Ubuntu edgy seeds)
[08:24] <Kamion> casper isn't in live because we also build a "livecd-base" that doesn't include the desktop or live seedss
[08:24] <Kamion> seeds
[08:24] <Kamion> but maybe casper should be in live anyway, for clarity
[08:24] <slomo> Kamion: ok, finished... http://slomosnail.de/~slomo/temp/dbus_0.93-0ubuntu3.debdiff if you already want to look at it now...
[08:24] <infinity> mdz: Do we have any intention of even pretending to care about the nvidia-glx root hole, or is "upgrade to a random beta driver to fix it" just not a good enough answer for us?
[08:25] <mjg59> infinity: Wouldn't help the legacy ones anyway
[08:25] <mdz> infinity: we'll wait until there's a proper update
[08:25] <shawarma> Kamion: Are those seeds the input for germinate?
[08:25] <Kamion> shawarma: yes
[08:25] <infinity> Kamion: I vaguely recall we had some reason or other (other than livefs-base) for not having it in the live seeds, but danged if I can remember what that reason was.
[08:25] <shawarma> Kamion: I see.
[08:25] <Kamion> c.f. SeedManagement
[08:26] <mdz> infinity: and -legacy will need to go to universe
[08:26] <mdz> we can't pretend to support it
[08:26] <Kamion> multiverse
[08:26] <mdz> right
[08:26] <Kamion> mdz: if so, we should make that overrides change nowish
[08:26] <infinity> mdz: Yeah, like we pretend to support any of it anyway. :/
[08:26] <Kamion> I don't want to be changing overrides post-release
[08:27] <mdz> Kamion: still debating whether to change it for edgy
[08:27] <infinity> It probably should have been in multiverse from its introduction anyway.
[08:27] <mdz> yes
[08:27] <mc44> mdz: how about an option for nvidia-beta a la nvidia-legacy, obivoulsy in multiverse as well
[08:27] <mjg59> mc44: Adds another lump to linux-restricted-modules
[08:27] <mdz> mc44: far too frozen for that sort of thing
[08:27] <infinity> A large lump.
[08:27] <infinity> The nvidia kernel module is huge.
[08:27] <mjg59> Is it going to be releases-noted?
[08:28] <mdz> Kamion: ok, let's do it before final
[08:28] <mdz> mjg59: which? legacy or the bug?
[08:28] <mjg59> "If you install this, arbitrary websites may 0wn you"
[08:28] <mc44> fair enough. Just dont like thee idea of random strings on webpages crashing my computer :-/
[08:28] <pygi> hello all
[08:28] <mjg59> mdz: The bug
[08:28] <Kamion> still trying to figure out why nvidia-glx-dev isn't on the demotion list in the first place
[08:28] <mdz> mjg59: probably a good idea
[08:29] <mdz> mjg59: though we don't do that for, say, the kernel
[08:29] <Kamion> s/nvidia-glx-dev/nvidia-glx/
[08:29] <mdz> I don't think it's necessary
[08:29] <mdz> Kamion: I think restricted is...weird
[08:29] <Kamion> mdz: anastacia is supposed to look at both main and restricted
[08:29] <mjg59> mdz: We don't generally release kernels with known security issues
[08:29] <Kamion> migration between main<->restricted is entirely manual, yes, but it should notice stuff in restricted that's not seeded
[08:30] <mdz> mjg59: sure we do; if they become known too close to release there's little point in delaying
[08:30] <mdz> the difference between releasing with very-recently-known vulnerabilities and unknown vulnerabilities is minimal
[08:30] <infinity> Kamion: nvidia-glx is in ship.
[08:30] <Kamion> OH, sigh
[08:30] <mc44> mdz: but then you expect to update the kernel in a reaobale timeframe
[08:30] <mc44> *reasonable
[08:30] <Kamion> infinity: I meant nvidia-glx-legacy, I just can't think/type/whatever
[08:30] <Kamion> but I worked it out - it's because of Extra-Include: *-dev
[08:30] <mdz> mc44: and we do. what is your point exactly?
[08:30] <infinity> Kamion: Fair enough, I can;t do any of those three either. :)
[08:31] <Kamion> which pulls in nvidia-glx-legacy-dev which pulls in nvidia-glx-legacy
[08:31] <Kamion> infinity: you can't whatever?
[08:31] <infinity> Kamion: Indeed.  I'm terrible at it.
[08:31] <Kamion> mdz: so, Extra-Exclude: nvidia-glx-legacy-dev and demote that pair?
[08:31] <mc44> mdz: that an update to the kernel would be quick after release so risk is smaller not warrenting a realse note, however it may be a long time before nvvidia fix it in a stable driver, and that may be too dangerous to -update
[08:31] <mdz> Kamion: yes
[08:31] <Kamion> mdz: before or after RC?
[08:32] <mdz> Kamion: after
[08:32] <shawarma> Kamion: Do you happen to know the Kubuntu equivalents of -minimal and -standard?  Do "they" have such equivalents at all?
[08:32] <infinity> Makes little difference, since it doesn't ship anyway.
[08:32] <Kamion> right, I'll do the seed change locally
[08:32] <mdz> Kamion: unless it's seriously negligible in the risk department
[08:32] <Kamion> shawarma: all derivatives use the same minimal and standard tasks
[08:32] <infinity> shawarma: The "minimal" and "standard" tasks are the same for all derivatives.
[08:32] <Kamion> shawarma: same minimal is a technical requirement (debootstrap); same standard is merely policy
[08:32] <infinity> shawarma: Again, "apt-get install taskname^"
[08:33] <shawarma> Kamion, infinity: ah. makes sense.
[08:33] <shawarma> infinity: apt-get install ubuntu-live^  does not install everything 'apt-get ubuntu-desktop ubuntu-minimal ubuntu-standard' does.
[08:33] <Kamion> shawarma: it's not meant to.
[08:34] <infinity> shawarma: No, you need to do all the above-mentioned tasks to get a livefs.
[08:34] <Kamion> we tried making those inherit at one point and it had complicated undesirable consequences whose specifics I forget exactly (sorry)
[08:34] <infinity> shawarma: minimal, standard, ubuntu-desktop, ubuntu-live, casper, kernelstuff.
[08:34] <infinity> Kamion: If nothing else, it makes debugging uninstallable tasks pure hell.
[08:34] <mdz> Kamion: I believe it was that removing something low on the stack removed all metapackages going upward
[08:34] <infinity> And that too.
[08:34] <Kamion> yeah, either of those could've been it
[08:35] <shawarma> infinity: So 'apt-get install ubuntu-live^ ubuntu-desktop ubuntu-standard ubuntu-minimal linux-generic casper' for ubuntu and 'apt-get install kubuntu-live^ kubuntu-desktop ubuntu-minimal ubuntu-standard casper linux-generic' for Kubuntu?
[08:35] <Kamion> shawarma: you don't install ubuntu-minimal from scratch - you debootstrap to get that
[08:35] <shawarma> Kamion: Yes, I was wondering why they didn't just depend downwards.
[08:35] <infinity> shawarma: More or less, yes, but you start with a debootstrap.
[08:36] <shawarma> Kamion: Of course, but that's not exactly what I'm trying to do. :-)
[08:36] <Kamion> and the linux-* are different for different architectures
[08:36] <shawarma> infinity: Yes, I *would* if I was doing an actual install :-)
[08:36] <infinity> Kamion: I still install minimal^ anyway, for sheer paranoia's sake.  Not sure why. :)
[08:36] <shawarma> Kamion: Of course.
[08:36] <shawarma> infinity: Ah, minimal is a taskk, too?
[08:36] <Nafallo> pitti: nice changelog on the firefox-build :-)
[08:37] <Kamion> minimal's only really a task because I'm a completist
[08:37] <infinity> Kamion: Was there a point when minimal wasn't part of debootstrap?  That could be why it's in livecd.sh
[08:37] <infinity> (It clearly doesn't need to be anymore)
[08:37] <shawarma> Kamion: -desktop and -standard are not tasks, right?
[08:38] <Kamion> infinity: no
[08:38] <infinity> shawarma: They are.
[08:38] <Kamion> infinity: before minimal existed, there was base, but that was part of debootstrap then
[08:38] <shawarma> infinity: Ok.
[08:38] <Kamion> one of the main reasons for splitting base into minimal and standard was to speed up debootstrap :)
[08:38] <infinity> Kamion: Right, then, I guess it's just lamont paranoia that I never stripped.
[08:39] <shawarma> infinity: minimal and standard are not. At least that's why my apt-get tells me.
[08:39] <infinity> shawarma: minimal^ and standard^
[08:39] <infinity> shawarma: No derivative stem.
[08:39] <shawarma> infinity: Garh... I'm so stupid.
[08:39] <shawarma> infinity: feel free to quote me on that.
[08:40] <infinity> Only when drunk, and you're paying.
[08:40] <shawarma> infinity: indeed.
[08:41] <Nafallo> pitti: firefox looks good in Swedish anyway, nothing jumps at me.
[08:42] <infinity> pitti: Can we s/BonEcho/Firefox/ on the user agent string?  There are some painfully retarded websites that refuse to work with "unknown" user agents.
[08:47] <seb128> Kamion: do you have anything to ~/.xsession-errors or any clear message about the issue on boot?
[08:48] <seb128> that's weird we didn't get some bug reports about that, the package didn't change for weeks now
[08:48] <seb128> there was an issue some time ago, I fixed it and people who replied on the bug confirmed it's fixed
[08:48] <seb128> Kamion: does it happen every time?
[08:56] <slomo> pitti: ping?
[08:58] <Kamion> seb128: no, not every time - and as I say it's on the live CD so it could well be the dbus activation timeout thing that people were talking about above
[08:58] <pitti> Nafallo: cheers
[08:58] <pitti> slomo: pong
[08:59] <Kamion> seb128: http://people.ubuntu.com/~cjwatson/tmp/xsession-errors - nothing obvious
[08:59] <pitti> Nafallo: changelog> well, I got sick of tracking all these CVEs in the manual db :)
[08:59] <pitti> infinity: I'll look into it
[08:59] <Kamion> (I've already started g-s-d by hand and started ubiquity)
[08:59] <Nafallo> pitti: hehe, yea. thought so :-)
[08:59] <slomo> pitti: saw that i managed to not change the dbus timeout? ;) any idea what else has fixed it for you? (and does the bcm43xx driver work for you with latest kernel? i always loose the connection to APs after some time...)
[09:00] <Lure> mjg59: I cannot reproduce bug 60442, but I have prepared a test package - so if you can test it would be great
[09:00] <Ubugtu> Malone bug 60442 in gnome-power "Dual / Two Batteries, shutdown on empty expansion battery. (GPM does not recognises second battery on hotplug)" [Unknown,Unknown]  http://launchpad.net/bugs/60442
[09:00] <pitti> slomo: dbus timeout> no idea, it just works now
[09:00] <Kamion> seb128: also bug 66124 was filed just four days ago about this and you replied to it ...
[09:00] <Ubugtu> Malone bug 66124 in control-center "gnome-settings-daemon crashes" [Undecided,Needs info]  http://launchpad.net/bugs/66124
[09:00] <Kamion> so it's obviously not fixed for everyone
[09:00] <pitti> slomo: bcm43xx> works fine for me, but I didn't test it for longer than an hour or so
[09:00] <pitti> slomo: but it's completely broken with network-manager
[09:00] <elmo> my fonts consistently get mangled on upgrade
[09:00] <seb128> Kamion: that one is clearly a different issue
[09:00] <pygi> sivang: ping?
[09:00] <Kamion> seb128: oh?
[09:00] <elmo> from subpixel -> best shape
[09:00] <elmo> who would that be a bug on?
[09:00] <Kamion> seb128: oh, sorry, you're quite right
[09:00] <seb128> Kamion: the previous crasher people have had "gstreamer init failed" message
[09:00] <pitti> slomo: From what I have heard, wpasupplicant wrecks up the settings, and I don't even get an IP
[09:01] <pitti> slomo: so I'm back at good ol' sudo ifup eth1
[09:01] <seb128> s/have/had
[09:01] <slomo> pitti: i loose the connection after < 5 minutes already but don't use NM at all
[09:01] <pitti> slomo: anything helpful in dmesg?
[09:01] <slomo> pitti: no... jsut the usual spamming by the bcm43xx module
[09:01] <seb128> Kamion: would be nice to try with the extra delay for dbus first
[09:01] <Kamion> mm, I'll see if I can try that out hand-hacked later
[09:01] <seb128> Kamion: and debug it if the isssue is still there
[09:01] <pitti> slomo: how come that the timeout isn't changed? I still remember the changelog
[09:02] <pitti> Kamion: it's nontrivial to hack
[09:02] <Nafallo> pitti: network-manager bailed out on my rt2500, wifi-radar works though :-). if you want something GUIsch that is :-).
[09:02] <slomo> pitti: i patched upstream's session.conf but we have our own in debian/ and forgot about it
[09:02] <pitti> Kamion: in my experiments I never managed to get the effect after logging out and back in - that was just too fast
[09:02] <Kamion> pitti: I can hack it at boot
[09:02] <Kamion> break=casper-bottom, mess around with ed
[09:02] <pitti> ah, nice trick
[09:03] <Kamion> you have to provide a script that edits the file, but shrug
[09:04] <seb128> is apport running on the desktop CD?
[09:04] <seb128> like a g-s-d crash would generate a crash log?
[09:11] <Kamion> doesn't seem to
[09:16] <Riddell> mjg59: has usplash changed on amd64?
[09:16] <tfheen> Riddell: yes.
[09:16] <tfheen> Riddell: it now works, unlike what it used to.
[09:16] <Riddell> well that would be handy to know
[09:16] <Riddell> what do I have to do to make it work in kubuntu?
[09:17] <tfheen> provide proper (640x400 and 640x480) artwork.
[09:17] <tfheen> 16 colours
[09:26] <pitti> sfllaw: do you need help with amd64 testing? I can do some testing tomorrow morning
[09:27] <Kamion> I'm slowly cranking my way through the amd64 DVD still
[09:36] <ogra> hmm, gaim is funny as IRC client
[09:37] <sivang> ogra: I couldn't never get used to it as an IRC client
[09:43] <Riddell> Gloubiboulga: someone will have to add a 640 xubuntu usplash too, else it won't work on amd64
[09:44] <seb128> lool: hi, yeah, you have some nice ideas. I think we will discuss that again at next summit. I'm busy with edgy at the moment but I would be happy to discuss that after edgy if you are interested. I think mvo is interested to the topic too
[09:58] <mvo> seb128: what topic was that?
[09:58] <seb128> mvo: easy-codec-install
[09:59] <mdz> sfllaw: how goes the testing?
[09:59] <lamont> infinity: what did I do now??
[10:00] <mvo> seb128: yeah, that is a nice one
[10:08] <pitti> mdz: btw, I did the whole range of amd64/alternate tests with yesterday's images; the big bugs I noticed have been fixed
[10:08] <mdz> pitti: thank you
[10:08] <pitti> my machine is still busy with firefox, but I'll do some more amd64 tests tomorrow
[10:13] <mvo> how can I get the installer to present me the auto-resize option :/
[10:14] <mvo> do we need more ubuntu testing? it would be a welcome break from edubuntu testing :)
[10:14] <tfheen> mvo: the disk needs to be bigger than 6G
[10:14] <tfheen> mvo: ubuntu i386 testing == good
[10:14] <pygi> get mvo 
[10:15] <pygi> hey*
[10:15] <pygi> o joy, what a typo
[10:15] <gnomefreak> seb128: you mean like amaroks easy install codecs?
[10:15] <seb128> gnomefreak: what?
[10:15] <gnomefreak> amarok installs codecs for you now :)
[10:15] <seb128> gnomefreak: and?
[10:15] <mvo> tfheen: my disk is 160G and I don't see it in ubiquity 
[10:15] <seb128> gnomefreak: I don't use amarok and don't care about what it does
[10:15] <mvo> hey pygi!
[10:15] <gnomefreak> seb128: is that the same as what you mean?
[10:16] <seb128> gnomefreak: no
[10:16] <gnomefreak> oh ok
[10:16] <seb128> gnomefreak: I mean you try to play a mp3 with totem and it open a dialog "you need to install gstreamer0.10-plugins-ugly"
[10:16] <seb128> gnomefreak: with an "install" button
[10:16] <gnomefreak> seb128: yeah thats what amarok does atm
[10:17] <gnomefreak> it would be nice if it can be done with totem
[10:17] <seb128> gnomefreak: how do they do the mapping package to install codec?
[10:17] <seb128> gnomefreak: and is amarok running as admin or is there a daemon to install the package?
[10:17] <gnomefreak> seb128: that i dont know thats a riddell question
[10:17] <gnomefreak> seb128: daemon
[10:18] <seb128> gnomefreak: that's stupid to have an app specific daemon
[10:18] <seb128> gnomefreak: we should have something you can speak to over dbus or something like that
[10:18] <gnomefreak> agreed
[10:19] <seb128> gnomefreak: does amarok install the codec for the user or the package required or the codec out of the package systm?
[10:20] <gnomefreak> out of package system iirc. the last time i played with it it kept running in a loop
[10:20] <seb128> gnomefreak: ah, k, that's not what the spec is about, the spec is about determining what package is required and install it
[10:20] <gnomefreak> ah
[10:21] <seb128> we are not really interested to install codecs out of the packaging system :)
[10:21] <gnomefreak> ah
[10:25] <sfllaw> Kamion: You're looking at bug 59983.  EtienneG was wondering if this will make it for edgy.
[10:25] <Ubugtu> Malone bug 59983 in ndiswrapper "ndiswrapper in edgy broken" [Medium,Confirmed]  http://launchpad.net/bugs/59983
[10:25] <sfllaw> According to the report, it looks like the kernel interface changed.
[10:25] <sfllaw> And he's already had a call about it.
[10:26] <mdz> Kamion: I think we had the same idea: https://features.launchpad.net/distros/ubuntu/+spec/install-with-third-party-drivers and https://features.launchpad.net/distros/ubuntu/+spec/ubiquity-driver-updates
[10:26] <Riddell> gnomefreak: hmm?
[10:26] <gnomefreak> Riddell: we were talking about how amarok installs the codecs
[10:27] <Riddell> gnomefreak, seb128: it runs /usr/lib/amarok/install-mp3
[10:27] <Riddell> which installs libmad
[10:27] <Riddell> there's no daemon
[10:28] <seb128> Riddell: is that mp3 specific or does it do that with any codec?
[10:28] <Riddell> seb128: it's mp3 only, amarok just reads this .desktop file for the script to run which is supplied by the packager /usr/share/services/amarok_xine-mp3_install.desktop
[10:29] <seb128> Riddell: and does it install the package or a codec it downloads from somewhere?
[10:29] <dieman> suck, wont be working with ubuntu a ton in my new job it sounds -- the emc software for the SAN requires SLES or RHEL. 
[10:29] <Riddell> seb128: our install-mp3 runs kdesu adept to enable muliverse if needed and do apt-get install libmad0
[10:30] <seb128> Riddell: ok, I see. gnomefreak said that amarok was already doing what the easy-codec-install specs wants to do, looks like it's a "light version" :) We want a mapping for any codec
[10:30] <pygi> dieman: why is that?!
[10:30] <dieman> pygi: its not 'certified' for ubuntu, etc.
[10:30] <lool> seb128: fine
[10:30] <seb128> Riddell: thank you for the details about it :)
[10:30] <dieman> the SAN people here dislike not using certified platforms, etc.
[10:31] <pygi> dieman: ok, help us get in contact with the providers of software, we'll certify
[10:31] <dieman> i can't blame them, because its a support issue for them.
[10:31] <tfheen> dieman: where you moving to?
[10:31] <dieman> sticking here at umn in minneapolis
[10:31] <dieman> moving to oit security and assurance
[10:31] <dieman> doing network security work
[10:31] <tfheen> oh, nice.
[10:31] <dieman> yah
[10:34] <Kamion> 01:31 < Kamion> mdz: I registered ubiquity-driver-updates before seeing install-with-third-party-drivers. Which should we keep?
[10:34] <Kamion> 01:36 < Kamion> mdz: do I need to repropose ubiquity-advanced-partitioner for uds-mtv, or can we just carry it over? (I don't think it desperately needs further discussion)
[10:34] <Kamion> 01:37 < Kamion> I suppose that means I'll have to actually think of other stuff I want to do for edgy+1 then, otherwise my slate is going to look artificially empty in MTV
[10:35] <Kamion> mdz: yep, I'd noticed that too, shortly after registering u-d-u
[10:35] <infinity> Kamion: If you already have a large amount of work (and thus no need to spec more for yourself), register a mess of LP specs, and sit in with the soyuz guys and I for distro/soyuz requirements.
[10:36] <infinity> Kamion: Or register other random specs for cool stuff you hope you can pawn off on other assignees. :)
[10:36] <Kamion> sfllaw: some total random assigned that bug to me without my consent; I know nothing about it
[10:36] <sfllaw> Kamion: Ah.
[10:37] <ajmitch> morning
[10:37] <sfllaw> When people do that, can you toss it back to Nobody?
[10:37] <ajmitch> wasabi_: pong (what was it about?)
[10:37] <Kamion> sfllaw: yeah, I just did
[10:37] <Kamion> it was only yesterday
[10:38] <sfllaw> mdz: Bug 59983 looks like it could cause pain for our users.  The regression seems to be a bad one, but the fix involves a UVF exception.
[10:38] <Ubugtu> Malone bug 59983 in ndiswrapper "ndiswrapper in edgy broken" [Medium,Confirmed]  http://launchpad.net/bugs/59983
[10:38] <sfllaw> mdz: EtienneG just pointed out that he had a call about it.
[10:39] <mdz> sfllaw: I have read that entire bug and I don't understand what the problem is
[10:40] <tfheen> ajmitch: http://err.no/src/contentless_ping.pl
[10:40] <Riddell> mdz, tfheen: I'm uploading a new kubuntu-default-settings to allow booting on amd64
[10:40] <mdz> Riddell: bug#?
[10:40] <pitti> there, firefox User-Agent string fixed
[10:41] <Riddell> mdz: been to busy making the changes to report a bug yet :) hang on
[10:41] <mdz> Riddell: so kubuntu/amd64 is completely broken?
[10:41] <Riddell> mdz: you need to turn off usplash
[10:42] <pitti> mdz: I fixed firefox' UserAgent: to be 'Firefox' instead of 'BonEcho' (to restore compatibility with some websites which check the string); I hope that's conformant with the branding agreement?
[10:42] <mdz> pitti: please make it compatible with whatever dapper did
[10:42] <Ubugtu> Malone bug 66815 in kubuntu-default-settings "amd64 usplash boot broken" [Undecided,Unconfirmed]  
[10:42] <pitti> mdz: alright
[10:43] <ogra> Riddell: woah, thats evil ...
[10:43] <mdz> Riddell: was this a regression caused by the most recent usplash changes?
[10:43] <sfllaw> mdz: The bug is that you can't use ndiswrapper-utils to confiugre a proprietary network card.
[10:43] <sfllaw> That makes it rough for users who don't have free cards in their computers.
[10:43] <ogra> in edubuntu the splash is completely broken on amd64, but still boots fine
[10:43] <mdz> sfllaw: that's the symptom. what's the problem?
[10:43] <sfllaw> mdz: ndiswrapper.ko changed its interface.
[10:43] <Riddell> mdz: yes, since nobody told me about the usplash changes I never knew to update it
[10:44] <ogra> Riddell: it was mentioned loosely on teh last dev meeting
[10:44] <sfllaw> Our ndiswrapper (1.1) doesn't know how to use the new module.
[10:44] <sfllaw> Upstream's 1.8 reportedly does.
[10:44] <sfllaw> EtienneG says he's going to verify that.
[10:44] <tfheen> sfllaw: so we can just change the seeds to point to 1.8 for release, then.
[10:44] <mdz> Riddell: why does that cause it to fail to boot?
[10:45] <tfheen> fwiw, not having proper artwork doesn't make it blow up for me.  It just gives a garbled image.
[10:45] <Riddell> mdz: it seems to freeze the computer shortly after X starts (presumably when usplash stops)
[10:45] <Kamion> ugh, cdebconf-keystep doesn't line-wrap one of its questions - that's incredibly ugly
[10:45] <ajmitch> tfheen: ta for the script
[10:45] <EtienneG> sfllaw, I will confirm and post a comment in #12016 somewhen before midnight EST
[10:46] <sfllaw> EtienneG: 12016?
[10:47] <EtienneG> sfllaw, Sorry !  I am mixing bug/ticket number here ... :)
[10:47] <sfllaw> tfheen: I'm confused but I presume you're not.  Are you saying you'll point the seeds to 1.8, which is living in?
[10:47] <sfllaw> EtienneG: Please comment in Malone.
[10:47] <EtienneG> that's really #59983
[10:47] <EtienneG> sfllaw, yep, I guess that's better ! :)
[10:48] <EtienneG> tfheen, my understanding is that ndiswrapper-utils bring in ndiswrapper-utils-1.1
[10:48] <EtienneG> so just changing ndiswrapper-utils to bring in -1.8 should worked, if confirmed
[10:48] <doko_> sfllaw: can we swap Ubuntu/Kubuntu testing for amd64 (already have the CD here)?
[10:49] <sfllaw> doko_: Yes.
[10:49] <doko_> sfllaw: ok, changing the wiki
[10:49] <sfllaw> doko_: Thanks.
[10:50] <mdz> Kamion: I replaced my spec with yours
[10:51] <doko_> sfllaw: hrm, no, Kamion is testing amd64 Ubuntu, not me, so please keep it ;-) starting with the kubuntu CD's :)
[10:51] <sfllaw> OK.
[10:51] <tfheen> EtienneG: no, not changing the package.  Changing the seeds.
[10:51] <Kamion> doko_: only DVDs
[10:51] <sfllaw> kozz: Right.
[10:51] <sfllaw> Desktop CD and Alternates.
[10:52] <doko_> Kamion: seen
[10:53] <mdz> sfllaw: I have version 1.8-0ubuntu2 installed
[10:53] <mdz> but the source package in the archive is 1.1-5
[10:54] <mdz> oh, it's gone weird
[10:54] <mdz> the package names changed around
[10:54] <Kamion> oh, I see - we need to build cdebconf-keystep with libtextwrap
[10:55] <mdz> there's an ndiswrapper-utils in the archive, built from ndiswrapper-1.1
[10:55] <mdz> then a bunch of newer stuff built from 'ndiswrapper'
[10:55] <tfheen> mdz: that's an empty transitional package depending on ndiswrapper-utils-1.1
[10:56] <mdz> tfheen: 'ndiswrapper' also builds an ndiswrapper-utils though
[10:56] <mdz> which is not empty
[10:56] <tfheen> mdz: yes, ndiswrapper-utils is the package I talked about.  It should be empty or just containing symlinks, I'd imagine.
[10:56] <Riddell> doko_: if you're testing amd64 kubuntu keep in mind the usplash needs disabled
[10:56] <ogra> Riddell: how does kdm stop usplash ? i dont see the initscript running DO_NOT_SWITCH_VT=yes /etc/init.d/usplash start
[10:56] <tfheen> the reason for this is to prevent upgrades to break people's networking because the ndiswrapper ABI changed and they didn't get a new kernel at the same time
[10:57] <tfheen> (and now they can't because they have an old kernel and new ndiswrapper or the other way around)
[10:57] <Riddell> ogra: there's nothing in kdm to stop usplash as far as I remember
[10:57] <mdz> tfheen: what I don't understand is that I have two 'ndiswrapper-utils' packages in my apt cache
[10:57] <ogra> Riddell: aha ... that might be your prob then
[10:57] <mdz> tfheen: which contains only edgy
[10:58] <tfheen> mdz: and you don't have it locally installed?
[10:58] <sfllaw> There's a 1.8 in dapper.
[10:58] <mdz> tfheen: I have it installed, but I wouldn't have manually installed it
[10:58] <Riddell> ogra: so that'll be yet another usplash change I've not been told about, grump
[10:58] <ogra> Riddell: look at gdm in debian/patches/15_usplash.patch
[10:58] <mdz> it's as if the version number got smaller between dapper and edgy
[10:58] <sfllaw> It did.
[10:58] <doko_> Riddell: will do
[10:58] <mdz> that's not supposed to happen
[10:58] <sfllaw> http://packages.ubuntu.com/cgi-bin/search_packages.pl?searchon=names&version=all&exact=1&keywords=ndiswrapper-utils
[10:58] <mdz> ndiswrapper-utils |     0.10-1 |         warty | i386
[10:58] <mdz> ndiswrapper-utils | 0.12+1.0rc2-1 |         hoary | i386
[10:58] <mdz> ndiswrapper-utils | 1.1-4ubuntu2 |        breezy | amd64, i386
[10:58] <mdz> ndiswrapper-utils |      1.1-5 |          edgy | all
[10:58] <mdz> ndiswrapper-utils | 1.8-0ubuntu2 |        dapper | amd64, i386
[10:59] <mdz> cprov,malcc: ^^^
[10:59] <tfheen> that's.. special.
[10:59] <mdz> so we just need to fix ndiswrapper-utils to depend on -1.8 rather than -1.1 it sounds like
[10:59] <Nafallo> where are the manpages? :-P
[11:00] <sfllaw> And up the version number.
[11:00] <mdz> for good measure
[11:00] <cprov> mdz: I'm checking
[11:00] <sfllaw> I'll update the description for 59983.
[11:01] <sfllaw> Done.
[11:04] <infinity> cprov: Could it be that version constraints are only checked on source uploads, but not on binary uploads?
[11:05] <infinity> cprov: Oh, or something more sinister at work...
[11:05] <malcc> We seem to have two source packages (ndiswrapper vs ndiswrapper-1.1) both publishing ndiswrapper-utils binaries...?
[11:05] <infinity> mdz: At a glance, I'd say that 'ndiswrapper-utils' was removed from edgy as NBS, then ndiswrapper-1.1 started building it with a lower version.
[11:06] <malcc> Hmm, the version of ndiswrapper in edgy builds ndiswrapper-utils-1.8
[11:06] <sfllaw> doko_: What did you decide to do?
[11:06] <cprov> infinity: have you ran archive-cruft-check recently ?
[11:07] <infinity> (Which still is no excuse for it not failing version constraints when it was cleared from the new queue)
[11:07] <mdz> malcc: yes, we had some discussion about it before you /joined
[11:07] <mdz> malcc: cprov should have a copy
[11:07] <doko_> sfllaw: just testing the Kubuntu CDs/DVD
[11:07] <sfllaw> OK.
[11:07] <sfllaw> Thanks.
[11:07] <sfllaw> I'll continue with AMD64 on Ubuntu.
[11:08] <mdz> sfllaw: someone needs to confirm Riddell's bug
[11:08] <mdz> if it breaks the boot everywhere, it's a problem for RC
[11:09] <Kamion> cprov: I run a-c-c frequently, and its output was empty yesterday
[11:09] <Kamion> in fact this morning too, I think
[11:09] <Kamion> mdz: I checked for versions in edgy << dapper-updates, but looks like I need to check dapper too ...
[11:10] <cprov> Kamion: good, was just curious about it, thanks
[11:10] <mdz> Kamion: where do you check that?
[11:10] <Kamion> cjwatson@drescher:~$ for component in main restricted universe multiverse; do for arch in amd64 i386 ia64 powerpc sparc; do echo "$component/$arch:"; ./suite-diff.py /srv/launchpad.net/ubuntu-archive/ubuntu/dists/dapper/$component/binary-$arch/Packages.gz /srv/launchpad.net/ubuntu-archive/ubuntu/dists/edgy/$component/binary-$arch/Packages.gz gt; echo; done; done | less
[11:10] <Kamion> ndiswrapper-utils is the only offender for edgy << dapper
[11:11] <Kamion> suite-diff.py is something I wrote way back shortly after I started working for Canonical; I no longer remember why ...
[11:11] <Kamion> oh, I think it was to check for newer versions of packages in unstable than warty after UVF
[11:12] <Kamion> there's also one instance of edgy << dapper-security at present
[11:12] <mdz> sfllaw: ubuntu/i386 is still lacking confirmed tests as well
[11:12] <Kamion> mvo: could you (get somebody to) update vmware-player-kernel-2.6.15 for our current kernel, please?
[11:12] <sfllaw> I'm going to import some of cr3's results from Salesforce.
[11:12] <Kamion> assuming we're allowed to
[11:12] <sfllaw> mdz: Is there a DevelTeamMeeting this week?
[11:12] <mdz> sfllaw: no, as posted to ubuntu-devel-announce
[11:12] <tfheen> Kamion: should we even have vmware-player-kernel-2.6.15 in edgy?
[11:12] <Kamion> vmware-player-kernel-modules: 2.6.15.10-10 > 2.6.15.10-6
[11:12] <Kamion> vmware-player-kernel-source: 2.6.15.10-10 > 2.6.15.10-6
[11:12] <sfllaw> OK.
[11:13] <Kamion> tfheen: no, should be 2.6.17
[11:13] <Kamion> but regardless, the versions of those binaries need to be higher
[11:13] <sfllaw> Ah.  I see, it's cancelled on fridge, not disappeared like normal.
[11:13] <tfheen> oh, the binaries doesn't have versioned package names.
[11:14] <Kamion> which is correct for -source; less sure about -modules
[11:16] <mdz> sfllaw: I see cr3 is also assigned all i386 DVD cases, but there supposedly isn't enough bandwidth to montreal for CDs, much less DVDs
[11:16] <tfheen> I can do DVD ubuntu tests in the morning
[11:35] <Kamion> tfheen: vmware-player-kernel-modules: 2.6.15.10-10 > 2.6.15.10-6
[11:35] <Kamion> vmware-player-kernel-source: 2.6.15.10-10 > 2.6.15.10-6
[11:35] <Kamion> oops
[11:35] <Kamion> tfheen: http://people.ubuntu.com/~cjwatson/tmp/cdebconf-keystep.libtextwrap.diff
[11:35] <Kamion> how does that look to you?
[11:35] <Kamion> need to figure out how to test it
[11:37] <tfheen> Kamion: it doesn't need to do anything to use libtextwrap?  Just make sure it's present?
[11:38] <Kamion> it already has that code, AFAICT
[11:39] <Kamion> which is why I didn't notice the problem earlier - it's all inside #define HAVE_LIBTEXTWRAP
[11:39] <tfheen> oh, ok.
[11:39] <Kamion> which is always defined in cdebconf so I assumed it would be in cdebconf-keystep too
[11:39] <tfheen> I probably got that when I C&P-ed the code out of cdebconf.
[11:39] <tfheen> yeah, looks good to me otherwise.
[11:39] <Kamion> it's only 9 lines of #defined-out code in total
[11:40] <tfheen> yeah, I'm not worried about that bit.
[11:46] <malcc> Looks like ndiswrapper-utils-1.8 is left behind in universe where ndiswrapper-utils and ndiswrapper-utils-1.1 are in main
[11:46] <sfllaw> tfheen: Thanks.
[11:52] <Kamion> malcc: due to not being seeded
[11:54] <malcc> So, I can't find anything wrong in Soyuz here, unless its whole approach to packages with chunks of version numbers in their names is on crack
[11:55] <Kamion> malcc: we're talking solely about the ndiswrapper-utils binary package here, not the others
[11:55] <cr3> mdz: do answer your concer about testing DVDs in the Montreal office, sfllaw has sneakered much of the DVD downloads into the office from home, so we should be able to rsync minor changes in the office
[11:55] <sabdfl> malcc: evenin'
[11:55] <malcc> sabdfl: Hi
[11:55] <Kamion> malcc: the bug is that the ndiswrapper-utils binary package should not have been accepted into edgy when its version was << that in dapper
[11:56] <tfheen> malcc: you need to never forget about a binary package that has existed in some distro you derive from and also disallow version number downgrades.
[11:57] <Kamion> well, yes, there are weak and strong versions of this constraint
[11:57] <tfheen> Kamion: I suspect dak is vulnerable to a similar problem as soyuz is, but I haven't verified it.
[11:57] <Kamion> the weak version is to check just versions of binaries in other existing distroreleases, with an awareness of the order of distroreleases
[11:57] <tfheen> I've just pondered with it as an (evil!) way to get rid of epochs.
[11:57] <Kamion> the strong version is to remember all versions and never allow going backwards, as tfheen says
[11:58] <Kamion> tfheen: what about epochs?
[11:58] <tfheen> Kamion: if you're allowed to downgrade, you can get rid of epochs.
[11:59] <Kamion> you have to arrange for an ftpmaster to remove the binary temporarily
[11:59] <Kamion> I think eventually ftpmaster would notice :)
[11:59] <tfheen> so if edgy-2 had a package, you got rid of it in edgy-1, you can reintroduce it in edgy without the epoch and close any bugs as "this was a package that wasn't in edgy-1".
[11:59] <tfheen> yes, evil, wrong and all.
[12:01] <Kamion> from the sounds of things, I think I need to get a version of my suite-diff hack into Soyuz sooner rather than later. :)
[12:01] <Kamion> in case anyone gets any ideas
[12:01] <Chipzz> I don't see how this can work
[12:02] <Chipzz> if I have a package installed with an epoch
[12:02] <Chipzz> I do not update
[12:02] <Chipzz> you guys remove it
[12:02] <Kamion> Chipzz: it wouldn't. that's the point
[12:02] <Chipzz> you guys add it again
[12:02] <Kamion> Chipzz: that's why it's evil
[12:02] <Chipzz> I update
[12:02] <Chipzz> it still wouldn't work
[12:02] <tfheen> Chipzz: it wouldn't, but I could blame it as user error since you should have removed it when it wasn't supported.
[12:02] <tfheen> well, 'night.
[12:02] <Kamion> Chipzz: tfheen's pointing out a failing in the archive's current integrity checks. of course it has negative consequences on users ...
[12:02] <Chipzz> tfheen: no, I just didn't update while it wasn't supported
[12:03] <Chipzz> I never noticed that there was a period when it wasn't supporte
[12:03] <Chipzz> d
[12:03] <tfheen> Chipzz: you should have.
[12:03] <Kamion> don't analyse it too hard
[12:03] <tfheen> what Colin says.
[12:03] <tfheen> anyway, I need sleep; there's an RC tomorrow.
[12:03] <Chipzz> uhu :)
[12:03] <malcc> Ok, I'm feeling a bit better that I didn't understand this now :)
[12:03] <Chipzz> good night :)
[12:03] <tfheen> need to be dapper, no, edgy tomorrow.
[12:03] <Kamion> CAFFEINE
[12:04] <Kamion> Chipzz: the above is why, by policy, version numbers never, ever go backwards
[12:05] <Kamion> Chipzz: mostly, this is enforced technically; occasionally it still needs to be enforced socially; sometimes things slip through
[12:05] <Kamion> malcc: it's actually much more important in some ways that version numbers never go backwards for binary packages than for source packages, because the reason why they mustn't go backwards is that if they do they won't get upgraded on users' systems, as Chipzz describes
[12:06] <Chipzz> Kamion: uhu
[12:06] <elmo> tfheen: dak is so not vulnerable to that - it does cross-suite version checking
[12:06] <Kamion> for source packages we could theoretically get away with only uniqueness (although decreasing version numbers might break things like apt-src; I'm not sure about that) - but in practice it's much less confusing just to have the same constraint, especially considering that you have to go to some lengths to get source and binary versions to differ
[12:07] <Kamion> elmo: it's vulnerable to it across removals within the same suite, surely?
[12:07] <elmo> the only thing it's vulnerable to is the temporary removal trick, but if I ever saw anyone do that deliberately I would kick them out of the keyring faster than they could say banana hammock
[12:08] <elmo> Kamion: not sure how you mean?  dak would have rejected an edgy upload of a package, even if it was new to edgy, if the version was << dapper