[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'...  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<EMAIL_ADDRESS>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<EMAIL_ADDRESS>Undelivered Mail Returned to Sender; localhost.kvota.net[<IP_ADDRESS>]  said: 554<EMAIL_ADDRESS>    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.  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: <IP_ADDRESS>
[03:10] <pygi> sivang: you must mean bad century, right?
[03:11] <Keybuk> jdong: finger<EMAIL_ADDRESS>[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<EMAIL_ADDRESS>[03:12] <Keybuk> [<IP_ADDRESS>]
[03:12] <Keybuk> collegegeek.org has address <IP_ADDRESS>
[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?   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.  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.    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           | <IP_ADDRESS>svn+r23428-0 | 16 hours
[09:31] <infinity>          | * xfdesktop4/<IP_ADDRESS>svn+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?