=== ubuntu [~ubuntu@wuser200-league.umnet.umich.edu] has joined #ubuntu-devel [12:07] Just tried new live CD - my X problems are fixed (in fact I'm typing from it now) [12:07] downloading install cd now [12:08] thully: .7 ? [12:08] .6, actually [12:08] sladen: ping? [12:08] there is already a new one! [12:09] .6 was an i386-only build to test whether the X fix worked [12:09] it did, so I built .7 for i386/amd64/powerpc/ia64 [12:09] is there any difference? [12:09] no functional difference on i386, no [12:09] Also, is there a chance that .7 will be array 4? [12:09] there is a chance, yes [12:09] if all tests succeed [12:10] I'm downloading install cd build now === sto_ [~sto@224.Red-80-59-203.pooles.rima-tde.net] has joined #ubuntu-devel === srbaker [~srbaker@blk-222-186-25.eastlink.ca] has joined #ubuntu-devel === AndyR [~andrew@rogers666.plus.com] has joined #ubuntu-devel [12:18] lo ppl === thully [~ubuntu@wuser200-league.umnet.umich.edu] has left #ubuntu-devel ["Leaving"] === perdix [~perdix@134.102.101.166] has joined #ubuntu-devel === mpt_montreal [~mpt@HSE-Ottawa-ppp3496346.sympatico.ca] has joined #ubuntu-devel === toresbe_ [tsb@developer.skolelinux.no] has joined #ubuntu-devel === jaco [~jaco@host163-20.pool80117.interbusiness.it] has joined #ubuntu-devel [12:40] i'm off to bed guys... my thighs, my lower legs... everything hurts :-) *wave* === dholbach [~dholbach@td9091be6.pool.terralink.de] has left #ubuntu-devel [] === wasabi_ [~wasabi@c-24-1-67-127.client.comcast.net] has joined #ubuntu-devel === schweeb [~chris@schweeb.org] has joined #ubuntu-devel === wasabi_ [~wasabi@c-24-1-67-127.client.comcast.net] has joined #ubuntu-devel === usual [~colin@cpe-24-194-195-66.nycap.res.rr.com] has joined #ubuntu-devel === bluefoxicy [~bluefox@pcp485126pcs.whtmrs01.md.comcast.net] has joined #ubuntu-devel [01:12] you know [01:12] that could really piss someone off. [01:12] I upgraded to 2.6.10-2-amd64-generic or something [01:12] and upon loading 8139too [01:12] the kernel breaks [01:12] junk is spewed to the terminal [01:13] and the root filesystem (xfs) gets corrupted. [01:13] miiiiiiiiight want to not do that. === wasabi [~wasabi@c-24-1-67-127.client.comcast.net] has joined #ubuntu-devel === marcin_ant [~marcin@www.e-dev.tele2.pl] has joined #ubuntu-devel [01:13] but I've reinstalled now, manually, breaking the install process and now I don't know how to set my default console keymap to dvorak [01:13] also I don't know how to generate the prettified/automated /boot/grub/menu.lst since grub-install (in the installer) never works. [01:14] anyone know how to fix my keymap and timezone up? [01:14] grub is broken on amd64 at the moment, but there is a known workaround [01:14] this is all in bugzilla [01:14] I know how to make grub work manually (grub, root (hd0,0), setup (hd0) [01:15] mdz: how about keymap? that in bugzilla? (I broke that, not you, so I'd imagine not) [01:15] that's fallout from the installer breaking [01:15] yeah [01:15] so if you go back and use the workaround, that'll take care of itself [01:16] Can I get a hint on what ot search bugzilla for? === bluefoxicy checks to see if he's got any hintcoins left [01:17] mdz: there isn't a known workaround that works when booting from CD, unfortunately [01:17] bluefoxicy: grub doesn't work manually like that right now, AFAIK; it's being hit by a kernel bug, it's not an installer bug [01:18] oh dear god, what's mdz done to the seeds [01:18] elmo: oo.o2 [01:18] and thereby kdelibs [01:18] oh goody [01:18] how bad is it? [01:19] Kamion: I just installed grub like that [01:19] Kamion: problem is ubuntu still stops and doesn't installa proper menu.lst [01:19] bluefoxicy: that's surprising, since it doesn't work for me [01:19] I forgot how to trick it into thinking it worked (I killed a certain process and it did it) === bluefoxicy is very mean to the install CD [01:19] it is grub's 'install' command (called by 'setup') that triggers the segfault [01:20] hum. [01:20] perhaps you used a different grub [01:20] mdz: only 7 new source packages; it's just the biggest change in a while, shocked me [01:20] though, that wouldn't help, would it [01:20] although grub-install may use somewhat different arguments, actually [01:20] mdz: hoary amd64 install cd [01:20] mdz: no, that would imply that it was grub's fault, which it isn't [01:20] Kamion: I just use setup (hd0) [01:20] unless you count using nested functions as "fault" [01:20] after using root [01:21] o_o [01:21] nested functions are the children of satan [01:21] grub-install does setup --stage2=/boot/grub/stage2 --prefix=/boot/grub (hd0) [01:21] or similar === bluefoxicy has a list of 29 bugs he's trying to look through for this so-called workaround [01:21] bugzilla is hiding it [01:21] ok. so, no matter how well you swim, everyone where PFD's while you're in a boat. 'k? [01:22] mdz: ia64 cloop runs 40-50 min, iirc [01:22] maybe fabbione WONTFIXed it :-P [01:22] mdz: flushing it is easy - just tell me when you want to pay the pain... Do you want to flush all 4, or just ia64/amd64? [01:22] night everybody [01:22] pitti: night [01:22] lamont: I think RC would be a good time [01:22] bluefoxicy: there is no workaround that works on the install CD, as far as I'm aware. [01:22] Kamion: the noexec=off or whatever doesn't help? [01:23] bluefoxicy: somebody who actually understands this nx bit crap needs to look at it [01:23] Kamion: what about regenerating /boot/grub/menu.lst [01:23] bluefoxicy: update-grub does that [01:23] mdz: that works around the bug in an installed system, but for some reason not when booting from CD [01:23] bluefoxicy: #6082 [01:23] mdz: I have absolutely no idea why [01:23] Kamion: yeah an NX-bit may kill nested functions [01:23] bluefoxicy: it bloody well shouldn't, that's what PT_GNU_STACK is for! [01:23] mdz: thatnks, I was on 5059 or such [01:24] bluefoxicy: emuplt? [01:24] the entire design of all of that was to *prevent* it killing nested functions [01:24] tseng: emutramp? [01:24] bluefoxicy: yes. [01:24] that. [01:24] and /sbin/grub correctly has an executable bit set in its PT_GNU_STACK program header, which is being correctly read by the kernel [01:24] tseng: yeah, better design than PT_GNU_STACK for nested functions, but I didn't want to bring PaX into this [01:25] is this kernel.org NX then? [01:25] Kamion: odd. [01:25] hmm [01:25] as far as I can tell, the memory management layer that's supposed to make the page executable simply isn't working properly in 32-bit mode, or something weird like that [01:25] tseng: vanilla ignores PT_GNU_STACK? [01:25] no [01:25] although I tried with a trivial 32-bit example and it seemed to work [01:25] tseng: yes [01:25] vanilla 2.6.10 does not ignore PT_GNU_STACK [01:26] dumb question, does the app have the markings? [01:26] tseng: 00:24 < Kamion> and /sbin/grub correctly has an executable bit set in its PT_GNU_STACK program header, which is being correctly read by the kernel [01:26] Kamion: ahh, I've noticed with PaX that relocations are still killed in 32 bit on 64 bit kernels, even though PaX is set to allow relocations (as a legacy option until all relocations are removed from 99% of all code at least) [01:26] right.. [01:26] bluefoxicy: that sounds similar [01:26] Kamion: this may be a similar issue due to the design of the kernel, but I don't know. [01:26] pipacs doesn't seem to know wtf is wrong with it either, last i asked [01:26] Kamion: confirmed that noexec=off doesn't fix it when booting from the live CD, how weird [01:26] I reported to linux-kernel and there was no response [01:27] maybe mingo was too busy trolling pagexec [01:27] XD [01:27] mdz: it certainly baffled me [01:27] tseng: vanilla has no execshield though [01:27] *sigh* can we not get into inter-security-group flamewars here please? [01:27] bluefoxicy: bits and pieces [01:28] Kamion: aha [01:28] Kamion: I'm trying so hard not to [01:28] it can't be that hard [01:28] Kamion: noexec32=off ? [01:28] mdz: that option was removed, last I checked [01:28] oh [01:28] mdz: (you could always try it though ...) [01:28] heh [01:30] darn grub [01:30] argh [01:30] clean install still just boots to a blinking cursor [01:34] Kamion: doesn't help [01:34] confirmed that neither noexec nor noexec32 help on the CD boot, but noexec does on the hard disk boot [01:34] maybe something with the command line parsing? [01:35] could be, but that would be ... strange [01:35] mdz: you could try editing syslinux.cfg and putting noexec=off on it earlier on? [01:35] that's the only interesting difference I can think of [01:35] although I think Kurt Roeckx said that didn't help, iirc === thully [~thully@wuser200-league.umnet.umich.edu] has joined #ubuntu-devel [01:37] just finished installing from latest install build... looks good, and at least in my experience is Array 4-ready === tritium [~tritium@12-202-90-180.client.insightBB.com] has joined #ubuntu-devel [01:39] well, network applet crashes when you open it and quit it - that's the one new thing I've seen so far [01:39] netapplet recently got uploaded ... [01:40] Kamion: hmm [01:40] I will try dist-upgrade and see if that fixes it [01:41] Kamion: parse_cmdline_early uses memcmp for comparison, while nonx_setup (now called from it) uses strcmp [01:41] i.e., the string is not null-terminated [01:41] or may not be [01:41] thully: I was more thinking that it might have been introduced by that [01:42] mdz: hmm [01:42] I would naively expect that it would still work if noexec were the last parameter on the command line [01:42] Kamion: wrt ia64 boot magic - I assume that we'll create a separate boot image for livecd eventually, yes? [01:42] but that's exactly where it should be ending up [01:42] It happens when you open it and close it quickly afterwards [01:42] lamont: yeah, that's the plan, or figure out how to push the bootloader config over to debian-cd [01:42] mdz: do you want to flush the images for the RC image, or a few days earlier, so that some of us can sync the bulk of the CD before the RC ships? [01:43] Kamion: cool [01:43] lamont: I want to flush them at such a time that it doesn't interfere with rsyncing down iterations leading up to final, but still minimizes fragmentation [01:45] um [01:45] mdz: right. and that requires a compromise between the two extremes, I think... [01:45] still wondering about that keymap thing === bluefoxicy wants to change the keymap for the console [01:45] please take that to #ubuntu [01:45] mdz: I find it slightly puzzling that __supported_pte_mask is not set to _PAGE_NX by default [01:46] unless I'm missing something [01:46] Kamion: got it [01:46] Kamion: on the CD boot, 'console=tty0' ends up after noexec [01:46] oh, syslinux adds that? [01:46] so I think changing strcmp->(strncmp|memcmp) will at least get noexec working properly [01:46] apparently so [01:47] funky [01:47] just checked with the daily-live amd64 [01:47] I wonder if it's fixed in bk already [01:47] I'll do a test build on concordia and bung it into an image [01:49] that should be sufficient to roll an array 4 [01:50] yep [01:51] I can do a round of tests this evening, and you can bless it in the morning, if you like [01:53] mdz: I'll be up for a bit yet anyway [01:53] mdz: did we want to sync mono 1.0.5 from debian? that'd cure universe of it's tainted state [01:53] lamont: sure [01:53] 1.0.4 should really not be allowed to ship, since it's ftbfs, and all that... [01:54] tseng: what all do we need to sync for 1.0.5? [01:54] lamont: everything was in the mono source last i looked === lamont keeps wanting to spell it 'thomboy' for some reason. :-) [01:54] lamont: im doubting it changed from 1.0.4 to 1.0.5 heh. [01:54] tseng: not what I meant... we need to sync mcs_1.0.5-2, what else? [01:55] binary package names? [01:55] so this bug was the first thing that made me realize that this noexec functionality exists upstream now [01:55] does it actually provide us some security? [01:55] I think it does; stack pages are non-executable by default with any vaguely recently built binary [01:55] apart from a few wacko cases like grub [01:55] vaguely recent, as in -> likely all of main? [01:55] it certainly does provide a better situation than without [01:55] without any NX that is [01:55] mdz: the toolchain patches have been in for ages [01:56] you can look for the PT_GNU_STACK header using readelf -l [01:56] mdz: yes, for modern CPUs [01:56] if the header isn't there, it's an old binary [01:56] lamont: mcs and all that iirc are all from one source package [01:56] mdz: oh yeah, you have to have the nx bit available in hardware, as elmo says [01:56] lamont: i will grab it and play along [01:56] if it makes exploitation slightly harder, and we don't pay for it in terms of having to maintain some awful patch, that's excellent [01:56] mdz: the NX stuff in mainline only works with hardware support [01:56] so it's really new P4s or AMD64 systems [01:57] mdZ: yep [01:57] hm i was unaware that p4s had any NX [01:57] elmo: are our P4s in the DC new enough? [01:57] nocona does not [01:57] $ readelf -l /bin/ls | grep -A1 STACK [01:57] STACK 0x0000000000000000 0x0000000000000000 0x0000000000000000 [01:57] 0x0000000000000000 0x0000000000000000 RW 8 [01:57] ^-- new binary with non-executable stack pages [01:57] $ readelf -l /sbin/grub | grep STACK [01:57] STACK 0x000000 0x00000000 0x00000000 0x00000 0x00000 RWE 0x4 [01:57] ^-- new binary with executable stack pages [01:58] tseng: hm, I thought new P4s did, but I might have been misinformed; I know Intel and Transmeta have adopted the change in some CPUs [01:58] mizar:[/usr/bin] readelf -l tset | grep STACK [01:58] STACK 0x000000 0x00000000 0x00000000 0x00000 0x00000 RW 0x4 [01:58] mdz: the machines will be getting next week maybe; not the existing ones, I don't think [01:59] that's the oldest thing in /usr/bin on my hoary desktop [01:59] s/will/we'll/ [01:59] mdz: you can check by looking in the 'flags' line in /proc/cpuinfo [02:00] tseng: I see mcs, mod-mono, mono, monodevelop, monodoc, monopd.. which of those should we sync is the question... [02:00] or is it really just mcs? [02:01] BOGGLE [02:01] monodevelop i believe will be the same version we have [02:01] http://anandtech.com/cpuchipsets/showdoc.aspx?i=2111 [02:01] if that articles true, that may not be such a win [02:01] debian didnt have it at the time so i bumped it and did CDBS love [02:01] specifically the "you must enable PAE" bit [02:01] you can grab the debian one if youd like, non critical [02:01] mcs and mono are the biggies [02:02] mdz: AMD's NX got marketed as something like "Enhanced Virus Protection" in the Windows world. :-) [02:02] yeah, they got slapped down in several european countries for advertising it like that too [02:02] not surprised [02:03] lamont: want me to do a test run? [02:03] does EM64T implement it in a non-suck way? [02:03] if you're running in amd64 mode, yeah [02:03] lamont: then i can give you better answers, its been a long time [02:04] tseng: sure - I'm going to start with a sync req for mcs and mono, and we'll take it from there... === lamont doesn't use mono, you see... === tseng nods [02:05] mcs and mono are the core [02:05] the other apps you mentioned are ancillary === lamont sends mail so mdz can ack it [02:05] and i havent been tracking all of them in debian, admitedly [02:05] s/sends/has sent/ [02:05] grub or lilo, that is hte question [02:06] i hooked up with meebey and dajobe today, pretty cool guys [02:06] grub is so useful that I am enticed every time, even though it sucks === lamont goes to feed horses -back in a few [02:06] so ill be more up on the debian-mono scene soon hopefully [02:06] Kamion: did I talk with you about publishing the install and live CDs together? [02:07] Kamion: in terms of directory layout? [02:07] mdz: yeah, I thought I'd agreed? [02:07] oh, maybe not [02:07] surely /releases/hoary/array-4/hoary-{install,live}-$ARCH.iso? [02:07] yeah [02:07] with one of those shiny HTML pages? [02:07] I didn't know if that required changes in your publishing infrastructure or not [02:08] definitely shiny [02:08] oh, probably requires minor changes, but practically every release I do does for one reason or another ;-) [02:08] manual automation :-) [02:08] it doesn't really matter, I can always move them into place by hand if need be [02:09] the important thing is to have it not suck for the releases that I have to do in a real hurry (i.e. RC, final) [02:10] do you think it would be at all sensible to build them in a single pass? i.e., merge cron.daily and cron.daily-live, and sync the archive only once so that it's consistent === Josephus [~josephus@huwico.hu] has joined #ubuntu-devel [02:10] s/consistent/guaranteed &/ === thully [~thully@wuser200-league.umnet.umich.edu] has joined #ubuntu-devel [02:11] mdz: I think that's just going to increase build time to the point where it frustrates us both when we're trying to build install and live CDs separately [02:11] although I'm happy to do that as a one-off for array candidates [02:12] hi - I just put my laptop to sleep and woke it up, and the clock moved back 5 hrs - why may this happen? [02:12] well, yeah, we would need to be able to limit it when needed [02:12] thully: I think there's a bug open about that [02:12] we need to reset the clock after resume [02:13] OK - that's what I thought the problem was [02:13] maybe there isn't one; I can't find it [02:13] I have heard of that problem before at any rate, and it needs to be fixed [02:16] mdz: hm, is an ISO from 2005-01-13 rsyncable? [02:16] (live) [02:16] OK - I'll make a bug report now [02:17] Kamion: I think the rsyncability began at ~2005-01-20 [02:21] mdz: oh well [02:21] yeah it was the 20th or so [02:23] I just filed a bug - #6147 [02:26] fabbione: if xorg was failing on sparc, I'd be interested in the logs [02:27] I'll go look into this === stub [~stub@dsl-246.248.240.220.dsl.comindico.com.au] has joined #ubuntu-devel [02:31] Kamion: in a fit of madness today I wrote a little program to sniff around and tell me which version of a package is present in (local mirror, isos, d-i initrds, cloop images) * (i386,amd64,powerpc) on little [02:32] a bit like madison-lite on crack [02:32] maybe this would be useful to you as well? [02:33] might well be; although I kind of concur with the fit of madness bit ;-) [02:33] but, cool === stub [~stub@dsl-246.248.240.220.dsl.comindico.com.au] has joined #ubuntu-devel === thully [~thully@wuser200-league.umnet.umich.edu] has joined #ubuntu-devel [02:37] Hi - i know what the problem is that's causing the clock issues [02:37] it's how hwclock is invoked in the /etc/acpi/resume.sh script [02:38] this whole language pack idea is curious [02:38] im not sure I understand it [02:38] mdz/Kamion: want me to have the build{LiveCD,DI} scripts immediately exit, or do you like having the boring output and the tied up terminal? [02:39] hwclock doesn't autodetect whether the hardware clock is set to UTC or local time - it assumes based on what options it is invoked with. If there is no --localtime or no --utc, it will default to the last option used. If no option was used before, it will default to local time. [02:39] in our case, there is no --localtime or --utc, so it assumed local time [02:40] wasabi: the lang pack motivator is to be able to deliver new translations for packages after the release is out the door. [02:40] thully: so it should source /etc/default/rcS and get it from there, probably [02:40] ahhh. [02:40] So, all of the translations for ALL packages are moved into it? [02:40] wasabi: but you're right. trying to understand it makes brains hurt. [02:40] all of main [02:40] odd. [02:40] that sounds like a lot of useless text. [02:41] Kamion - yes [02:41] for instance, if I had a server, headless, no GUI, but I wanted japanese translations of some console programs... [02:41] wasabi: but only for the languages you want, as opposed to having all the languages you don't want in each of the individual packages. [02:41] I'd need all the translations for all of gnome too? [02:41] I think it's a net loss as it stands. On the other hand I can see that it'd be a net gain once we have enough translations. Dunno ... [02:42] wasabi: what Kamion said [02:42] It sounds confusing as hell to me. [02:42] Like, files for one program are in another heh. [02:42] well, in another package, but yes. === wasabi just not seeing teh point. [02:43] Kamion: once this is fixed in acpi-support, bug #6147 can be closed [02:43] wasabi: I think if you think of it in conjunction with the existence of Rosetta it makes a bit more sense [02:43] thully: please add that information to the bug repoert you filed [02:43] i keep hearing that name [02:44] but haven't bothred to look it up yet [02:44] wasabi: massive translation project [02:44] (that's the 3 word summary) === lamont cooks dinner [02:45] wasabi: you also currently have translations for all languages installed for the packages you have === netjoined: irc.freenode.net -> kornbluth.freenode.net === Nafallo [nafallo@h140n4c2o1027.bredband.skanova.com] has joined #ubuntu-devel [02:45] wasabi: e.g., 500k * N for gcc [02:45] so it has some gains and some losses [02:46] it's a question of which multiplier you remove [02:46] we're betting that the language multiplier is going to grow faster [02:46] I have an initrd-tools bug that only occurs on 2.4. The bugzilla page suggests that bugs like this should be closed as 'notwarty'. Is that tag a generic Not For Us? [02:46] jbailey: yes, there's aa bug open about renaming it to NOTUBUNTU [02:46] but nobody's minding the bugzilla store at the moment [02:47] every day i see ubuntu-update manager improve... what an awesome program === Nafallo_ [nafallo@h140n4c2o1027.bredband.skanova.com] has joined #ubuntu-devel === OddAbe19 [~OddAbe19@pcp02542642pcs.lncstr01.pa.comcast.net] has joined #ubuntu-devel === sivang [~sivang@box79162.elkhouse.de] has joined #ubuntu-devel === boglot [~logbot@gw.workaround.org] has joined #ubuntu-devel [02:49] mdz: oh, install CD build finished ages ago, BTW, if you want to kick off a live CD build [02:49] thully: ^-- [02:49] Kamion: kicked [02:49] I installed from the last one (released a couple hrs ago) and it works pretty good [02:50] also, live cd worked pretty good also [02:50] Kamion: does this have the fixed amd64 kernel? [02:50] only main problem is that with the network applet crashing on close [02:50] and if not, can I download one and patch it in? [02:50] jbailey: NOTWARTY means 'look at it after we release, since it doesn't apply to the version in warty^Wubuntu' [02:50] mdz: what fixed kernel? :) [02:50] Kamion: oh, I thought you said you were making one [02:50] Feb 03 16:48:58 I'll do a test build on concordia and bung it into an image [02:50] yeah, but only for test purposes as yet, I was going to patch it in and see what happened [02:50] but I get: [02:51] modprobe: FATAL: Could not load /lib/modules/2.6.10/modules.dep: No such file or directory [02:51] indefinitely [02:51] wonder what I broke [02:51] you didn't set EXTRAVERSION [02:51] mdz: fwiw, ia64 live is NFG until linux-source-2.6.10_2.6.10-14 - so no array 4 ia64-live [02:51] oh, good point [02:51] you didn't build it using linux-source-2.6.10? [02:51] Kamion: a little symlink love should take care of it, for a test... [02:51] I did, weird [02:52] although I stopped it partway through to use make -j50, maybe that did it [02:52] Do you just hate your io channel? [02:52] yeah, it probably passes it on the command line [02:52] jbailey: concordia loves it [02:52] jbailey: he wants it to feel important [02:53] jbailey: concordia does a kernel in like a minute with that [02:53] Concordia is a box I haven't heard of yet. [02:53] Kamion: way cool === Nafallo_ [nafallo@h140n4c2o1027.bredband.skanova.com] has joined #ubuntu-devel === OddAbe19 [~OddAbe19@pcp02542642pcs.lncstr01.pa.comcast.net] has joined #ubuntu-devel === sivang [~sivang@box79162.elkhouse.de] has joined #ubuntu-devel === boglot [~logbot@gw.workaround.org] has joined #ubuntu-devel [02:54] jbailey: one of the porting boxes [02:54] Ah, cool. [02:54] so, is polypaudio still planned for hoary? I saw it was in universe (or maybe it's main) but not used by default [02:55] yes [02:55] err [02:55] it is? [02:56] hypothetically speaking, GNOME is still planning to move, and we are still planning to follow them [02:56] mdz: EXTRAVERSION> ah, so it does === JanC [JanC@dD5764B90.access.telenet.be] has joined #ubuntu-devel === wasabi_ [~wasabi@c-24-1-67-127.client.comcast.net] has joined #ubuntu-devel === mjg59 [mjg59@cavan.codon.org.uk] has joined #ubuntu-devel === OddAbe19 [~OddAbe19@pcp02542642pcs.lncstr01.pa.comcast.net] has joined #ubuntu-devel [03:03] mdz: kdelibs in main; does that mean that we can revert some of the gross hacks to remove it that break stuff? :) [03:03] (kvim, frex) === sivang [~sivang@box79162.elkhouse.de] has joined #ubuntu-devel [03:03] Kamion: absolutely [03:03] hoorah [03:03] once elmo says it's done [03:03] Kamion: live build is done, btw [03:04] what is frex? [03:04] lazy-man's shorthand for "for example" [03:04] is there going to be any audio cd burn support in Hoary - last I remember there was no forthcoming solution. [03:05] well kvim isn't in kdelibs (I would hope) [03:05] thully: with kdelibs in main, I humbly recommend k3b :) [03:06] Riddell: but kvim was killed so that vim didn't pull kdelibs into main. [03:06] and it was killed really badly; we ended up with a kvim package containing only a diversion of vim [03:06] and nothing to replace it [03:06] Kamion: lol [03:06] we should fix hta [03:06] that [03:07] yes - if kdelibs goes in main, it would be great to find some way to make an exception to allow k3b, as we desperately need a decent CD-burning app - nautlius just doesn't cut it (no audio CD, no multisession CD) [03:07] nautilus [03:07] the plan for hoary was coaster, I believe [03:07] we have no intention of putting kdelibs on the CD [03:08] Kamion: plan for hoary was "if any of them are actually ready"... :) [03:08] well, yeah :) === mxpxpod [~bryan@mxpxpod.user] has joined #ubuntu-devel [03:08] lamont: ah, ok [03:09] tseng: did that work for you? [03:09] mdz: do you object to pulling libqt-perl into main? it's pretty small once you have kdelibs, and would allow me to revert a debconf hack. [03:09] mxpxpod: didnt get to it tbh [03:09] Kamion: sounds fine [03:09] mxpxpod: planning to just play with it here before cleaning it up [03:09] tseng: haha, ok [03:09] mxpxpod: ill do it now [03:09] it sounds like we need to uuencode the images in the diff [03:10] tseng: that sucks [03:10] tseng: can't you just submit the diff upstream? [03:10] and get them to release a new version ;) [03:11] no, the author rejected the icons [03:11] WHAT? [03:11] yeah.. doesnt fit with the goals of tomboy, too industrial [03:11] that's retarded [03:11] whatever that means [03:11] tintin can die [03:11] so he'd rather have a retarded icon? [03:12] apperantly [03:12] then some guy posted some absolutely awful icons of a notebook with stick notes on it [03:12] the icon wasnt worthy of window 3.1 [03:12] thats where the thread ended.. [03:14] haha === wasabi [~wasabi@c-24-1-67-127.client.comcast.net] has joined #ubuntu-devel [03:17]