[12:26] <visik7> hi
[12:26] <visik7> why there is no restricted for 2.6.17-1 ?
[02:02] <bddebian> Heya
[04:57] <nickrud> exit
[04:58] <nickrud> erm, try
[08:18] <stub> Launchpad will be going down in 15 minutes time. Estimated downtime is 10 mins. This is for the regular code update.
[08:37] <stub> I've had to abort the update. Another attempt will be made later today.
[08:57] <pitti> meh @ edgy udev
[09:03] <pitti> hi marilize, hey mvo
[09:03] <mvo> hey pitti!
[09:04] <Hobbsee> hi pitti and mvo 
[09:04] <jsgotangco> hey pitti, mvo
[09:05] <jsgotangco> did you see the group photo already from kwwii??
[09:05] <marilize> hey pitti
[09:05] <pitti> jsgotangco: no, I didn't, where is it?
[09:06] <jsgotangco> http://bootsplash.org/14_3.jpg
[09:10] <slomo_> pitti: regarding xchat looking ugly... you mean the entry where you type everything in? ;) it's only this weird now because it's a multi-line entry... try pasting more than one line in there
[09:10] <slomo_> pitti: but it's ugly nonetheless
[09:11] <pitti> slomo_: indeed
[09:11] <pitti> slomo_: the height should adapt to the font size, as usual
[09:11] <pitti> slomo_: right now it wastes too much space for my screen layout
[09:36] <stub> Launchpad will be going down in 15 minutes for its regular code update. Estimated downtime is 10 minutes.
[10:50] <seb128> pitti: alter
[10:51] <seb128> around?
[10:51] <pitti> seb128: duderino!
[10:51] <seb128>  /usr/bin/fakeroot debian/rules clean
[10:51] <seb128> /usr/share/cdbs/1/rules/langpack.mk:23: *** missing separator.  Stop.
[10:51] <seb128> that's how rhythmbox didn't build
[10:51] <seb128> do you know about that?
[10:51] <seb128> http://librarian.launchpad.net/3158171/buildlog_ubuntu-edgy-i386.rhythmbox_0.9.5-1ubuntu1_FAILEDTOBUILD.txt.gz
[10:51] <pitti> what???
[10:52] <pitti> seb128: no, I didn't
[10:52] <seb128> k
[10:52] <pitti> seb128: and line 23 of that file is
[10:52] <seb128> so now you know
[10:52] <pitti> ifndef _cdbs_bootstrap
[10:52] <pitti> _cdbs_scripts_path ?= /usr/lib/cdbs
[10:52] <pitti> which looks sane to me...
[10:52] <seb128> hum
[10:52] <seb128> to me too
[10:53] <pitti> seb128: I try a local build
[10:53] <seb128> local build works fine for me
[10:55] <pitti> seb128: hmm. wtf???
[10:55] <seb128> what?
[10:56] <seb128> my cdbs might have been outdated when I built it
[10:56] <pitti> seb128: did you notice the same in other packages?
[10:56] <seb128> no
[10:56] <pitti> seb128: I'm on current edgy, lemme try a build here
[10:56] <seb128> but i didn't upload anything else yesterday
[10:57] <seb128> I'm on edgy too
[10:57] <pitti> seb128: oh, rb is still the dapper version
[10:57] <seb128> pitti: on my cdbs version l23 is @PATH_RULES@
[10:57] <pitti> huh?
[10:57] <seb128> ifndef _cdbs_bootstrap
[10:57] <seb128> @PATH_RULES@
[10:57] <seb128> endif
[10:57] <pitti> that looks like the .in file
[10:58] <seb128> ii  cdbs                              0.4.41ubuntu3                     common build system for Debian packages
[10:58] <pitti> hm, works fine here
[10:59] <seb128> is l23 @PATH_RULES@ for you?
[10:59] <pitti> no, as I said, it's " _cdbs_scripts_path ?= /usr/lib/cdbs"
[10:59] <pitti> (without the first space)
[10:59] <pitti> seb128: lemme reinstall cdbs
[10:59] <seb128> what version do you have?
[10:59] <seb128> is that a local build?
[10:59] <pitti> seb128: someone else touched cdbs after me, so I doubt it
[11:00] <pitti> anyway, now I have the latest version
[11:00] <pitti> seb128: ah, indeed, fucked langpacks.mk
[11:01] <pitti> seb128: ok, I'll fix that
[11:01] <seb128> pitti: thank you
[11:05] <pitti> Riddell: sorry for larting, that should have gone to siretart 
[11:06] <Riddell> pitti: no problem :)
[11:06] <Riddell> pitti: siretart is keeping cdbs in a bzr archive
[11:07] <pitti> Riddell: oh, thanks for the hint
[11:08] <Riddell> bzr checkout sftp://bazaar.launchpad.net/~ubuntu-core-dev/cdbs/ubuntu
[11:18] <pitti> Riddell: hm, apparently the bzr only has ubuntu1, but the archive has ubuntu3; did you push your changes?
[11:19] <pitti> right now, the checked out tree is a total wreck, missing files, failing test suites, etc.
[11:20] <KaiL> new ati driver - but not worth an upgrade (neigher X1900 support nor fixed libGL for R200)
[11:25] <pitti> Riddell: anyway, I'm going to fix up the bzr now
[11:26] <Riddell> pitti: no, I've not had time to look at the bzr stuff, I didn't know about it until after I uploaded
[11:27] <KaiL> and new nvidia-legacy drivers - yes, nvidia really did it :)
[11:27] <pitti> Riddell: why did you remove the ant.sh test?
[11:28] <pitti> ant-1.sh, rather
[11:28] <Riddell> pitti: don't we have ant disabled in our cdbs?
[11:28] <pitti> Riddell: I changed the test to silently succeed if ant isn't isntalled (since some dependencies are in universe)
[11:28] <dibblego> I have opened a bug because libgtk2.0 is causing a segmentation fault, but since I'm a noob, I'm not sure if I have provided all the required information - can anyone please confirm anything more that need to provide? I'm pretty keen to see it fixed :) https://launchpad.net/distros/ubuntu/+bug/50836
[11:28] <Ubugtu> Malone bug 50836 in Ubuntu "gdk-pixbuf-query-loaders segmentation fault" [Medium,Needs info]  
[11:37] <crimsun> hmm, I wonder if my key is acting up again.
[12:39] <Kamion> jdub: could you put the CC meeting on the fridge calendar? today at 1400 UTC
[01:01] <siretart> pitti: btw, any reason to not remerge cdbs yet? (only changes in python-distutils.mk.in)
[01:46] <pitti> siretart: no, this morning I just fixed the FTBFS of the majority of the archive, that was a bit urgent
[01:46] <pitti> siretart: I also repaired the bzr and brought it up to date
[01:47] <pitti> siretart: feel free to remerge :)
[01:48] <siretart> pitti: allright. I merged cdbs that time because I hope this would make fix many ftbfs in python packages. and it did built in my chroot that time. however the buildds seem to have been disabled at time of uploading, and the archive has changed since my upload
[01:48] <ogra> pitti, i just had someon complaining about missing translations in tuxpaint, where are translations of sdl games supposed to be in ? 
[01:49] <pitti> $ dpkg -L language-pack-de-base |grep tuxpaint
[01:49] <pitti> /usr/share/locale-langpack/de/LC_MESSAGES/tuxpaint.mo
[01:49] <pitti> /usr/share/locale-langpack/de/LC_MESSAGES/tuxpaint-stamps.mo
[01:49] <pitti> ogra: ^
[01:49] <ogra> ah, base :)
[01:49] <ogra> thanks !
[01:50] <pitti> ogra: yes, if the update package does not have it, then there are no new translations since the dapper release
[01:50] <ogra> he said he had installed the language-support-fr package ... 
[01:50] <ogra> i 
[01:50] <pitti> ogra: yes, -support does not have any translations
[01:50] <ogra> i'd expect that to pull -bas in
[01:50] <ogra> *base
[01:50] <pitti> ogra: it recommends -pack, but not depend on it
[01:50] <ogra> or isnt that a metapackage
[01:50] <pitti> since that wouldn't make sense
[01:50] <ogra> aah !
[01:50] <ogra> ok :)
[01:51] <pitti> since usually you only need a subset of supported languages as desktop translations
[02:01] <iwj> Joy.  coreutils is FTBFS
[02:02] <iwj> Oh, no, my libc is hosed.
[02:03] <hunger> iwj: That's the fun you get for living on the edge:-)
[02:03] <Kamion>          | * libmaypole-plugin-authentication-usersessioncookie-perl/1.8-2/i386 Component: main Section: perl Priority: EXTRA
[02:03] <Kamion> contender for longest package name
[02:03] <Kamion> although probably not a winner
[02:05] <Mithrandir> there are some other perl modules which are pretty bad.
[02:05] <Keybuk> ah, conflag caught up with me this morning it appears
[02:08] <Kamion> conflag?
[02:09] <zul> hey
[02:09] <Kamion> Keybuk: I forcibly synced a few of the things in syncs/problems.txt and removed them from that file (bison-doc, make-dfsg, realpath)
[02:10] <Keybuk> ok, cool
[02:10] <pitti> Kamion: at least it's longer than the current champion linux-restricted-modules-2.6.15-23-amd64-generic
[02:10] <Keybuk> that was everything that failed and I didn't want to investigate just yet
[02:10] <Keybuk> Kamion: like jetlag, but for conferences ... when you get home and your body goes "SLEEEEEP!"
[02:10] <Kamion> ah yes
[02:11] <Kamion> er, con-flag
[02:12] <Mithrandir> Keybuk: did you just rm -rf patches.u.c?
[02:12] <Keybuk> Mithrandir: yes :)
[02:13] <Keybuk> well
[02:13] <Keybuk> merge@casey:/srv/patches.ubuntu.com/published$ touch REBUILDING-AGAIN-PLEASE-STAND-BY; rm -rf *
[02:13] <Mithrandir> that's not a very useful ordering. :-P
[02:13] <Kamion> haha
[02:13] <_ion> :-)
[02:13] <Keybuk> Mithrandir: that only occurred to be *after* I pushed enter
[02:13] <Mithrandir> heh
[02:15] <Keybuk> just doing a final flush and rebuild for mom
[02:16] <Keybuk> Kamion: at some point this week I'm going to go through sync-blacklist and make sure it's all still sane
[02:17] <pitti> ogra: still b0rked?
[02:17] <Keybuk> heh, ... "I am working on a project that maintains a list of active hardware on a machine and we want to make it hotplug "aware"."
[02:17] <Keybuk> ... so that would be "HAL" then ?
[02:17] <ogra> Treenaks, well, they'll go away as well during one of the 20 reboots i have to do every day 
[02:17] <ogra> pitti, yes, dmesg shows some irq problems
[02:20] <Keybuk> pitti: bug #51083, talk to me
[02:20] <Ubugtu> Malone bug 51083 in udev "does not create most of the harddisk devices" [Critical,Unconfirmed]  http://launchpad.net/bugs/51083
[02:21] <pitti> Keybuk: so, how can I debug this?
[02:21] <pitti> Keybuk: I can install the new udev again and boot, and collect info
[02:22] <Keybuk> ok, so first we need to identify what is actually going wrong; there shouldn't be any significant difference between the two udevs
[02:22] <Keybuk> so install the new udev again
[02:22] <pitti> Keybuk: ok, let me boot my ibook to have a stable IRC, then I'll screw up my desktop
[02:23] <Keybuk> and make sure the install is sane -- the init script should call udevtrigger and udevsettle -- not udevplug
[02:23] <Keybuk> (I suspect the bug is because we use PHYSDEVBUS in a few places where we shouldn't and I haven't fixed those rules yet)
[02:24] <Keybuk> though that should only break permissions, I thought
[02:24] <pitti> ok, package upgraded, init script is the pristine one from the 093 package
[02:24] <pitti> Keybuk: hm, I just saw something during install
[02:24] <pitti> cpio: ./lib/udev/path_id: No such file or directory
[02:24] <robertj> is there a spec for no-auth security updates? I hear it's goin to be standard in Vista.
[02:24] <Keybuk> that's ok, it's just a minor thing
[02:24] <pitti> ok
[02:25] <Keybuk> actually, can you do gunzip -c /boot/initrd.img$VER | cpio -t | grep ide
[02:25] <_ion> robertj: It already exists, just turn it on.
[02:25] <Keybuk> pitti: the last thing should be lib/udev/ide_media
[02:26] <pitti> Keybuk: it's the first thing for me
[02:26] <Keybuk> ok
[02:27] <Keybuk> as long as it's in there :)
[02:27] <robertj> _ion: Automatic updates option?
[02:27] <pitti_> 'k, should I reboot now?
[02:28] <Keybuk> yup
[02:29] <pitti_> Keybuk: goddamn, of course it boots now
[02:30] <Keybuk> heh
[02:31] <pitti> Keybuk: if your mere aura fixed it, so much the better ;)
[02:32] <Keybuk> I'm not aware of anything that could actually prevent a device being created within udev
[02:32] <Keybuk> usually that means the kernel burped, not udev
[02:32] <Keybuk> though it can mean that udev failed to load the module the kernel needed
[03:11] <zul> is there a cc meeting today?
[03:12] <Kamion> does anyone feel their edgy system is working too well and want to test a new busybox-initramfs?
[03:12] <Kamion> zul: see CommunityCouncilAgenda
[03:12] <Hobbsee> i take it that means no.
[03:13] <Kamion> Hobbsee: see CommunityCouncilAgenda
[03:13] <zul> Hobbsee: according to the wiki there is
[03:13] <mdke> Kamion: I can't make the meeting, hopefully my agenda item is self explanatory enough to be discussed anyway...
[03:13] <Hobbsee> ah, hey, there you go!  i'm sure that wasnt there when i looked last time
[03:14] <Kamion> mdke: probably yes
[03:14] <Kamion> Hobbsee: I imagine not, I only put it there a couple of hours ago
[03:14] <Hobbsee> Kamion: right, okay, cool :)
[03:14] <mdke> Kamion:great, thanks
[03:15] <zul> same here
[03:15] <zul> except for the the staying up part :)
[03:15] <Hobbsee> hehe
[03:15] <TheMuso> Ah. So someone has decided to put that up for discussion.
[03:17] <ogra_> Keybuk, !
[03:17] <Keybuk> ogra: ?
[03:17] <ogra_> my ibook doesnt find its roofs anymore after upgrading to -25
[03:17] <zul> eh?
[03:17] <ogra_> it drops me out of usplash at "mounting root filesystem"
[03:17] <Hobbsee> er...your ibook has roofs?
[03:18] <Keybuk> to what -25 ?
[03:18] <ogra_> linux image 2.6.16-25-powerpc
[03:18] <Keybuk> edgy?
[03:18] <ogra_> nope
[03:18] <Keybuk> kernel bug, then
[03:18] <ogra_> well ...
[03:18] <ogra_> it drops me to a console
[03:19] <ogra_> IP-Config: eth0 hardware address .....
[03:19] <ogra_> i've never seen that 
[03:19] <Keybuk> hmm?
[03:19] <Keybuk> sounds like you've set your initramfs to be in BOOT=nfs mode :p
[03:19] <Keybuk> was ogra playing with ltsp in Paris? :p
[03:19] <ogra_> looks like its attempting to netboot
[03:19] <ogra_> nope
[03:20] <Keybuk> bet you 10 ?
[03:20] <ogra_> i wasnt playing with anything on the powerpc
[03:20] <Keybuk> at the console ... grep BOOT conf/initramfs.conf
[03:20] <ogra_> thats why i had my ltsp server amd64 lappie with me ... powerpc isnt really helpful for ltsp stuff
[03:20] <ogra_> i have no prompt
[03:20] <Keybuk> liesx
[03:20] <ogra_> it just hangs there
[03:20] <Keybuk> boot the older kernel and initramfs
[03:21] <ogra_> i cant, there is no entry for int in yaboot
[03:21] <Keybuk> boot with break=top then
[03:21] <ogra_> oki
[03:22] <ogra_> shudder, its indeed set to nfs ... but i know i never touched it
[03:24] <Keybuk> boot with boot=local then
[03:24] <Keybuk> and fix it
[03:24] <ogra_> actually it looks like a complete ltsp initramfs.conf ... how did that get there
[03:25] <Keybuk> I accept Paypal
[03:26] <ogra_> doesnt work, since no ide modules are loaded in ltsp netboot initramfs :P
[03:26] <ogra_> i suspect i need the livecd
[03:26] <ogra_> thats just mad ... i know for sure i never touched it ... and ltsp doesnt touch the servers initramfs.conf ...
[03:27] <ogra_> Keybuk, i'll pay in beer on the distro sprint
[03:27] <ogra_> thanks for helping :)
[03:27] <Keybuk> never blame udev for that which can be ascribed to pure stupidity
[03:27] <Keybuk> no worries :p
[03:28] <Keybuk> I've made the same mistake before, installed something on my desktop without noticing that it was in a window ssh'd into my laptop
[03:28] <ogra_> well, i guess my tests with the debian ltsp patches have somehow touched it without me noticing ..
[03:44] <ogra_> woah, breezy livecds boot slooooooow
[03:45] <Mithrandir> the eft ones will be faster than the dapper ones again
[03:46] <jsgotangco> wow
[03:46] <ogra_> well i just see the cd (which is a pressed one) seems borked .... got a lot of seek errors 
[03:50] <rodarvus> live cds need to be burned in a very slow speed (so that iso9660 correction algorithms are not called much)
[03:52] <ogra_> rodarvus, tell that to the people shipping our pressed cds :) *i* know it ;)
[03:52] <rodarvus> :)
[03:52] <ogra_> i'm using a pressed breezy cd over here, since i have a box with some 100s lying around :)
[03:53] <ogra_> but indeed i forgot to run ybin after regenerating the initramfs *sigh*
[03:54] <Kamion> ogra_: if it's a pressed CD, then either it's scratched or you need to clean your CD drive's lens
[03:54] <ogra_> looks like i'll have an advererous day
[03:54] <ogra_> *adventureous
[03:54] <ogra_> gah, cant type on that keyboard
[03:54] <Kamion> (or you have a weirder problem such as a kernel driver bug, but you'd probably know about that already)
[03:55] <ogra_> well, the appletouch doesnt work either with breezy ... i guess my HW is just to new for it
[03:57] <TheMuso> Kamion: When you have a minute, could you point me to that bonobo/orbit/whatever patch you came up with at Paris so I can test it? If it works, I dare say it would be a likely candidate for dapper-updates.
[03:58] <Kamion> TheMuso: I thought I'd already replied to you about that - it doesn't work yet, but I'm not out of ideas and will keep trying
[03:58] <TheMuso> Oh ok.
[03:58] <Kamion> my initial attempt caused lots of "/tmp/orbit-root has wrong owner" errors or something along those lines
[03:59] <TheMuso> Oh ok.
[04:01] <Keybuk> INFO:root:eel2: ubuntu is 2.14.1-0ubuntu2
[04:01] <Keybuk> DEBUG:root:Allowing comparison of -1 against -0ubuntuX
[04:01] <Keybuk> ... that's BETTER
[04:02] <G0SUB> pitti: hello :)
[04:02] <pitti> hello G0SUB!
[04:02] <G0SUB> pitti: it's UTC 14:00 now I guess :)
[04:02] <pitti> yep
[04:02] <_ion> 02
[04:22] <Seveas> \sh_away_away, are you really away?
[04:22] <ogra_ibook> no, he is away away
[04:23] <hanspeter> heya! is the libc6 package in edgy already fixed somehow?
[04:24] <_ion> "away from being away"
[04:24] <Kamion> wow, upgrade to edgy worked without dpkg errors. wonder if it boots
[04:24] <hanspeter> Kamion: it has a libc6 issue at the moment.
[04:24] <pitti> Kamion: good luck!
[04:24] <_ion> kamion: Don't be greedy now. ;-)
[04:25] <Keybuk> hanspeter: which issue?
[04:25] <Keybuk> the locales issue appears fixed
[04:25] <Kamion> hanspeter: (a) I can survive with LANG=C, (b) I can probably help fix that if I see the breakage
[04:25] <hanspeter> it's not the locale issue
[04:26] <hanspeter> malloc() throws around with memory-corruption-errors
[04:26] <hanspeter> i cant find a solution for that. even downgrading libc6 seems not to solve it
[04:27] <iwj> Kamion: mine is hosed; I'm fighting with it.
[04:27] <Kamion> hanspeter: what application?
[04:27] <hanspeter> Kamion: well, most applications... kde, firefox, some gnome stuff, xfce...
[04:29] <Kamion> because malloc issues that appear to be in libc are often just application bugs
[04:29] <Kamion> you trash the malloc arena by widdling over memory, malloc will fail later in obscure ways. use valgrind to help track that sort of thing down
[04:30] <hanspeter> well, but it would be strange if they suddenly appear after an upgrade. or am i wrong?
[04:30] <elmo> if they don't go away after a downgrade, I suggest you try memtest
[04:37] <hanspeter> you mean it could be my hardware? well, let's see
[04:39] <hanspeter> ahh, i could imagine that it's the new qt version which came today.
[04:39] <elmo> firefox and gnome don't use qt
[04:40] <hanspeter> yeah, i know. but how about the gtk2-qt-engine?
[04:42] <ogra_ibook> gtk2-qt-engine should just die or get someone who really cares for it ...
[04:42] <Hobbsee> ogra_ibook: it cant die.  you will get outraged kde users if it does not ship.
[04:43] <hanspeter> yeah i think qt's the problem.
[04:43] <ogra_ibook> Hobbsee, then it should be fixed to not break gnome
[04:43] <Hobbsee> ogra_ibook: that is true.
[04:43] <hanspeter> anyone knows the exact version of the qt version before the newest? it's no longer in my archive-cache...
[04:43] <ogra_ibook> the problem is that it breaks nearly all gnome apps and upstrem shows no interest in fixing it at all since two ubuntu releases
[04:43] <Hobbsee> ouch
[04:46] <hanspeter> never gonna install it again :)
[04:46] <hanspeter> i was just too lazy to remove it in the past...
[04:46] <Kamion> ok, does anyone want to test new busybox-initramfs with regard to bootability, or shall I just upload it? it works for me
[04:47] <Kamion> hanspeter: launchpad.net/distros/ubuntu/+source/SOURCEPACKAGENAME should get you to the publication history for the package
[04:47] <ogra_ibook> Kamion, its edgy, no ? ;)
[04:47] <Kamion> I sort of like machines to keep booting even so
[04:47] <ogra_ibook> well, sure, but at least yours boots, so you can fix it if we all fail :)
[04:51] <hanspeter> okay, that fixed it. so libqt is broken for sure...
[04:51] <Hobbsee> ogra_ibook: did you figure out that screensaver thing?
[04:52] <ogra_ibook> Hobbsee, nope, not yet, i was busy with paris and afterwards i had to get ltsp in shape ... its on my list
[04:52] <Hobbsee> ogra_ibook: cool :)  ping me if you want help testing it
[04:52] <Hobbsee> hi bddebian 
[04:52] <Hobbsee> being one of those crazy kde users, and all...
[04:52] <ogra_ibook> did you file a bug about it btw ? 
[04:53] <bddebian> Heya folks
[04:53] <bddebian> Hi Hobbsee
[04:53] <Hobbsee> ogra_ibook: about the rss-glx screensavers?  i believe there was one, yes
[04:54] <_ion> What kind of problem is there with rss-glx?
[04:54] <ogra_ibook> hmm, its not assigned to me ...
[04:54] <Hobbsee> _ion: kde problems - you need kscreensaver-xsavers to be installed if you're running them from kde, but not from anywhere else
[04:54] <Hobbsee> ogra_ibook: i'll try to find it
[04:54] <ogra_ibook> please assign it to me 
[05:01] <Hobbsee> ogra_ibook: lovely, dupes which i hadnt found before :)
[05:01] <ogra_ibook> cool :)
[05:02] <Hobbsee> ogra_ibook: they were hiding under kdeartwork, which i hadnt looked at.  will figure them out
[05:07] <Hobbsee> ogra_ibook: subscribe you as hostmaster@grawert.net?
[05:07] <Hobbsee> looks like there are about 4 things listed there to choose from.
[05:10] <ogra_ibook> under ogra ?
[05:12] <ogra_ibook> well, yes, hostmaster@grawert.net should work
[05:13] <Hobbsee> ogra_ibook: right...
[05:13] <Hobbsee> bug assigned to you - if you're the screensaver man, you should probably just assign yourself to that entire package, and the rss-glx too.
[05:14] <ogra_ibook> well ...
[05:14] <ogra_ibook> i'm subscribed to all screensaver bugs usually ...
[05:14] <ogra_ibook> but if people file against kdeartwork i cant help much :)
[05:15] <Hobbsee> ogra_ibook: kdeartwork is the source package for kscreensaver, and they seem to think that the bugs belong there
[05:15] <Hobbsee> ogra_ibook: looking at those bugs, it seems like there's something really evil going on there that needs time and brains and testers to deal with - to make it sane.
[05:15] <ogra_ibook> urgh, kdeartwork is the source for kscreensaver ? that seems pretty wrong
[05:15] <Hobbsee> ogra_ibook: looks like the deps we discussed earlier would be the hacky way around it
[05:16] <Hobbsee> yeah, it is.
[05:16] <ogra_ibook> yep, it needs some thinking
[05:16] <Hobbsee> in fact, the only kdeartwork bugs there are are for screensavers
[05:26] <izm99> hey all.  Is there some way to search for project/developer by geographic location?
[05:28] <Kamion> to aid in aiming the ICBMs? :)
[06:11] <izm99> no no.  :P  I'm interested in collecting information on projects/developers in Vancouver, canada.
[06:17] <MagnusR> .se
[06:17] <iwj> root@anarres:~ # apt-get upgrade -f
[06:17] <iwj> ....
[06:17] <iwj> E: Internal Error, Could not perform immediate configuration (2) on libc6
[06:17] <troy_s> Wasserschutzpolizei?
[06:18] <ogra> troy_s, what about them ?
[06:18] <troy_s> it was an ongoing source of good chuckles with the german folk at paris.
[06:18] <ogra> heh
[06:19] <iwj> I'm tempted to run dpkg -iGROEB on pool/main but I suspect it would be a bad idea.
[06:21] <KaiL> ...some X-Server-Hackers here?
[06:22] <pitti> KaiL: set({})
[06:22] <ivoks> pitti: hi
[06:22] <pitti> hey ivoks 
[06:22] <pitti> ivoks: I didn't forget about your cups mail, btw, will deal with it soon
[06:22] <KaiL> somebody should really port xorg.conf to something XML based 
[06:23] <pitti> ivoks: however, I don't think we can enable browsing by default -- no open ports
[06:23] <ivoks> pitti: but what open port is that?
[06:23] <KaiL> this md5sum fun is really awefull
[06:23] <pitti> ivoks: UDP 631
[06:23] <ivoks> pitti: but dhclient opens UDP port too
[06:23] <ivoks> pitti: otoh, maybe we could/should skip snmp auto discovery
[06:24] <pitti> ivoks: well, dhcp only if you use dhcp
[06:24] <iwj> KaiL: what md5sum fun ?
[06:24] <pitti> but I agree that this has to be discussed
[06:24] <iwj> Mind you I think I'm winning.
[06:24] <ivoks> pitti: i don't see it as a security issue :/
[06:24] <ogra> KaiL, carefull :) dont mess with iwj 
[06:24] <ivoks> pitti: but i understand if other do :)
[06:25] <iwj> ogra: I'm nice, really :-)
[06:25] <ogra> heh, i didnt mean it that way :)
[06:25] <KaiL> iwj, nvidia-glx-config seams to check the md5sum for xorg.conf - and I had now 5 people today having problems with nvidia-glx - 3 of them got a message, that the md5sum was wrong...
[06:26] <KaiL> as always all of them where shure, hey "never" editied that file...
[06:26] <iwj> That sounds quite insane.  But I'm afraid I don't know any of the answers.
[06:27] <KaiL> well, if xorg.conf would be XML-based, setting the driver *should* be a lot easier and possible without any md5 fun
[06:27] <ogra> xfree used to block dpkg-reconfigure if the md5sum didnt match for xorg.conf
[06:27] <KaiL> (even better would be, if xorg would autoselect it's driver ;)
[06:27] <ogra> i thought daniels worked around that
[06:27] <Kamion> oh for goodness' sake XML is just a transport, saying XML-based makes as much sense as saying ASCII-based or binary-based
[06:28] <Kamion> it is not difficult to parse xorg.conf in other ways
[06:28] <ogra> well, the real improvement would be to have no file at all but have xorg detect everything on startup ...
[06:29] <Kamion> which I'm told is not that far off
[06:29] <ogra> and have it detect changes dynamically as well
[06:29] <KaiL> Kamion, ok, then the other solution is to write a good parser for that file to set the values easiely seperated
[06:29] <ogra> well, i once was told dexconf is the future of x 
[06:29] <KaiL> ogra, ohm, yes - as more or less the whole other system does...
[06:29] <Kamion> upstream's moving towards a dumb server and a configuration client
[06:29] <ogra> yeah
[06:29] <_ion> kail: If xorg were to use libelektra instead of XML, it would be very easy to change the settings programmatically. Oh, xorg already has been elektrified. :-) http://www.libelektra.org/Xorg
[06:30] <ogra> intrestingly i doubt many users know they can have a custom xorg.conf in their homedir for example :)
[06:30] <KaiL> _ion, that's what I was searching for
[06:30] <ogra> our xorg already has somme nifty features ;)
[06:30] <KaiL> ogra, I guess, most of them only imagine this possibility while trying a backup and wondering, why the wrong file is used ;)
[06:31] <ogra> KaiL, yeah 
[06:31] <ogra> thats the usual way to discover that feature *g*
[06:40] <KaiL> but is it really so difficult, to get xorg to do some runtime-autodetection?
[06:41] <ogra> KaiL, nope, in fact merging xorg with xresprobe would be the solution and as Kamion said there is already being stuff in the works
[06:42] <wasabi__> X needs to be more dynamic At Runtime.
[06:42] <wasabi__> I'd like to plug in a new card and have a new screen defined and appear.;)
[06:42] <ogra> what for ? do you replace cards in running systems ? 
[06:42] <wasabi__> Yes.,
[06:42] <wasabi__> USB TV tuners.
[06:43] <wasabi__> USB video out cards.
[06:43] <ogra> and they dont work for you ? 
[06:43] <wasabi__> Not a bit.
[06:43] <ogra> my tv tuner card is running without setup in xine here
[06:43] <wasabi__> You plug them in, sure, but X doesn't know about them until you edit a file and kill the server.
[06:43] <ogra> (usb dvb-t)
[06:44] <ogra> i'm not aware of any usb based graphics cards yet ... 
[06:44] <ogra> and i doubt usb is fast enough
[06:44] <wasabi__> http://www.xbitlabs.com/news/video/display/20040607023341.html
[06:44] <wasabi__> Firewire too.
[06:44] <ogra> heh, funny
[06:45] <wasabi__> Notebooks with projector attachments.
[06:45] <wasabi__> Same thing.
[06:45] <wasabi__> http://reviews.cnet.com/VT_Book_32_MB_Graphics_Card_for_notebooks/4505-8902_7-30893185.html?tag=pdtl-list
[06:45] <wasabi__> http://reviews.cnet.com/Port_Authority_2_graphics_adapter/4505-8902_7-31215806.html?tag=pdtl-list
[06:45] <wasabi__> There's tons. ;)
[06:46] <KaiL> ogra, very good to hear
[06:47] <ogra> but still autodetection on startup would already be a major improvement beyond having a root owned config file
[06:48] <ogra> for input devices and other stuff the kernel and udev take care for it already works quite well
[06:49] <wasabi__> At boot, X should just ask HAL for all the display devices, and attempt to create screens on them.
[06:49] <wasabi__> And basically just watch hal events.
[06:49] <ogra> ++
[06:49] <ogra> thats what i say since months :)
[06:50] <ogra> hal is the thing !
[06:50] <_ion> Well, X should just let the kernel's framebuffer interface handle the screens.
[06:50] <ogra> but having a cool idea and implementing it in such a big thing as X are two different things
[06:50] <iwj> Urr.  /work/Coreutils-md5sum/test-build/coreutils-5.93/build-tree/coreutils-5.93/src/touch: setting times of `d/dd': Function not implemented
[06:52] <iwj> Ah, it means `you forgot to mount /proc'
[06:52] <iwj> This install is still in a bad way.
[06:54] <Riddell> Kamion: could you promote libavahi-compat-libdnssd-dev and libavahi-compat-libdnssd1 to main?
[06:56] <Kamion> Riddell: is something about to build-depend on them?
[06:56] <Riddell> Kamion: kdebase
[06:57] <KaiL> ogra, any ideas, if we can have some visible results on that for edgy?
[06:57] <Kamion> Riddell: done
[06:57] <KaiL> at least the driver should be set automatically imho
[06:57] <ogra> KaiL, ask freedesktop.org ... thats something upstream has to care for
[06:57] <Riddell> thanks Kamion 
[06:58] <ogra> urgh
[06:59] <ogra> isnt libavahi-compat the one that was supposed to go away asap ?
[06:59] <fabbione> KaiL: you clearly don't know that X does already a lot of autodetection and you clearly don't know how difficult is to set the driver right. I suggest you go and look in all bugzilla's and bug reports before asking for so simple "features"
[06:59] <ogra> (at least that was what i was told when i wanted it in main for gobby)
[06:59] <Kamion> ogra: that was compat-howl IIRC
[07:00] <ogra> ah, yes, mixed that up, right
[07:00] <KaiL> fabbione, I know, that it's quite difficult
[07:00] <Keybuk> fabbione: just because it is hard, does not mean that we should not try
[07:01] <KaiL> but having this code in xorg itself (and not in some config-tool makes things a lot easier, as normally nobody knows better, which driver works with which chip, as the driver authors
[07:01] <ogra> fabbione, well, it *is* a simple feature if you rewrite the whole of X to use hal :)
[07:01] <ogra> it just has this small drawback of rewiting X
[07:01] <pitti> ogra: indeed, rewriting the whole X code appears trivially simple :-P
[07:02] <zul> ogra: better start then ;)
[07:02] <ogra> zul, :P
[07:03] <KaiL> the most problems currently are "driver should work with this card (and so is selected by the installer), but doesn't" afaik
[07:06] <ogra> the installer dosnt select graphics drivers
[07:07] <ogra> xorg does that on its own through dexconf and its own postinst script
[07:07] <ogra> thats why dpkg-reconfigure works to change it 
[07:08] <KaiL> at least this fails rather often compared with udev selecting the right kernel module for a network card ;)
[07:09] <fabbione> Keybuk: X already does that without us doing it. Try to remove xorg.conf and start X :)
[07:09] <fabbione> ogra: hal would suffer the exact same issues. like pci id wants driver vesa while this other pci id wants radeon when the both cards are ati
[07:10] <ogra> fabbione, well, it mostly shows the HW pretty reliable ....
[07:10] <ogra> i'd point you to the hwdb to prove my words ... if there were one ...
[07:10] <KaiL> fabbione, kernel modules have a list of all PCI-IDs, they support
[07:10] <KaiL> why shouldn't this be possible for X-drivers too?
[07:11] <fabbione> ogra: so does lspci.. it will tell you that both are ati cards.. it doesn't know about exceptions.. same reason why you need to poke manually
[07:11] <fabbione> ^^ KaiL for you too
[07:11] <Riddell> if infinity_ is still travelling is there anyone around who can give pack a package to the buildds?
[07:11] <ogra> yeah, especially since ati just doesnt provine one driver but many
[07:11] <ogra> *provide
[07:11] <fabbione> ogra: i did chose ati, but can be anything
[07:11] <ogra> yeah
[07:11] <fabbione> that vesa <-> real driver battle applies to everything
[07:12] <Kamion> Riddell: (a) infinity's not still travelling, (b) I believe Keybuk can but I'm not sure
[07:12] <fabbione> like nv claims to support card foo:bar
[07:12] <fabbione> but it's buggy
[07:12] <fabbione> so you default to vesa
[07:12] <KaiL> ATI is good example, as there are some cards with up to 4 drivers (R200-Series!)
[07:12] <ogra> KaiL, but fabbione is right ... and there is nobody in this channel who is as familiar with X as he is
[07:12] <KaiL> ok, fglrx is currenly not really usefull for that ;)
[07:13] <ogra> so trust his words :)
[07:13] <ogra> you need soe kind of AI here :)
[07:13] <Kamion> the difficult bit will probably be going through all changes to dexconf etc. that have ever been made, figuring out *why* they were made, checking whether they're still relevant, and porting those changes to the drivers
[07:13] <ogra> *some
[07:13] <bluefoxicy> doko:  ping
[07:14] <Kamion> I don't think anyone really disagrees that that should be done, but you can say "it should be done" until you're blue in the face and it will have absolutely no effect; somebody who knows X well needs to do the work
[07:14] <fabbione> Kamion: not really.. most of them are still valid for X7.1
[07:14] <KaiL> for the first doing one thing would solve the most problems: some tool, which sets the driver value afaik, based upon the information from dexconf on each boot - with some easy to find config option to force some driver...
[07:14] <Kamion> fabbione: "not really" what? still relevant?
[07:14] <fabbione> Kamion: yeah most of the dexconf stuff is still required
[07:14] <ogra> KaiL, like the liveCD or ltsp do you mean ? 
[07:14] <Kamion> fabbione: right, I know
[07:14] <KaiL> ogra, yes
[07:14] <Kamion> but it needs to be checked anyway
[07:15] <bluefoxicy> gcc is doko's right?
[07:15] <ogra> KaiL, that slows donw booting by several seconds
[07:15] <ogra> but would be possible 
[07:15] <fabbione> Kamion: yes agreed, but for 99.9% of the stuff in there, there is no way to check without hw
[07:15] <KaiL> but additionally with some force-driver-option (to force "nv" even if "nvidia" is installed or to work arround buggy drivers)
[07:15] <Kamion> fabbione: indeed, which doesn't make the task any easier
[07:16] <fabbione> KaiL: nvidia is a buggy as nv..
[07:16] <Kamion> KaiL: it's getting solved by serious X hackers upstream. I don't think inventing random tools will help us in the least ...
[07:16] <KaiL> ogra, maybe it could cache it's information somehow, to shorten the time (means: if the PCI-ID didn#t change, it doesn't change the file..)
[07:16] <ogra> KaiL, they are identical apart from nv having the GL stuff disabled
[07:16] <fabbione> KaiL: if you are so keen to suggest a solution join #xorg-devel here on freenode
[07:17] <KaiL> ogra, and having a different internal card database, afaik?
[07:17] <fabbione> KaiL: all X real 3-ballz 31337 sk1llz h4x0r5 are there
[07:17] <ogra> KaiL, no idea about that, i cant xray the binary blob nvidia or nv are
[07:18] <fabbione> KaiL: whatever.. there is where you discuss X stuff with upstream
[07:18] <KaiL> at least there where times in dapper development, where "nv" failed, but "nvidia" worked (afaik "nv" has also some vesa-fallback or so?)
[07:19] <KaiL> fabbione, the question is, if there shouldn't be some "helper-tool", if this problem won't get fixed in some near future upstream
[07:20] <fabbione> KaiL: why don't you talk to upstream directly? what other helper tools do you want that are not there already?
[07:21] <ogra> KaiL, we dont do hacks here ... if the solution takes several releases but is the right one, we'll take that path
[07:21] <KaiL> currently fighting with xorg.conf is arround 90%, if not more, of the driver related problems in support chats - and if you ask people, why they don't switch from Windows, it's the xorg.conf-fun :/
[07:22] <Kamion> it is being worked on upstream kthxbye
[07:22] <Kamion> seriously, what's hard about this
[07:23] <Kamion> hacking it even more in the distro will make the migration to a sane solution in the medium term even harder
[07:23] <wasabi__> I'd be curious to read some about how upstream is working on it.
[07:24] <KaiL> other topic - something positive: recent c't has compared fedora core 5, suse 10.1 and ubuntu 6.06 LTS
[07:24] <ogra> wasabi__, freedesktop.org is your friend :)
[07:24] <Kamion> I'm told that ajax will be giving a talk at the next x.org developer conference entitled "rm -f /etc/X11/xorg.conf" which is about this
[07:24] <bddebian> w00t
[07:24] <ogra> KaiL, how do we look like ? 
[07:25] <KaiL> very interesting is the hardware detection
[07:25] <KaiL> suspend to Disk worked everywhere (compared to 1/4 on fedora)
[07:26] <KaiL> suspend to RAM 1/4 (fedora 1+1 with manuall changes, suse 2 with manual changes)
[07:27] <KaiL> some ATI RD580 board needs "noapic"
[07:27] <Kamion> the last can be dealt with if reported as a kernel bug with dmidecode output
[07:27] <KaiL> except that, everything eigher worked, or was not expected to work (somebody might explain, what's so difficult in installing linux-686)
[07:28] <Keybuk> Kamion: I don't seem to be able to give packages back, just rescore them
[07:28] <Keybuk> giving back is an LP admin task, allegedly
[07:28] <Kamion> Keybuk: ah
[07:28] <Kamion> KaiL: thanks for passing those one
[07:28] <Kamion> er, on
[07:29] <KaiL> Kamion, you expect a usefull bugreport from somebody, who calles the missing firewall one of the biggest problems with ubuntu? ;)
[07:29] <ogra> KaiL, you do that ? 
[07:29] <KaiL> bzw. fedora and suse both have an SMP kernel as default...
[07:30] <Kamion> KaiL: I expect it if somebody posts a comment explicitly asking them for it, yes
[07:30] <Kamion> I didn't expect them to telepathically know
[07:30] <KaiL> ogra, I an happy, that they found out, that LTS stands for "long term support", not "long time", so don't expect too much from them ;)
[07:31] <KaiL> also interesting: suse seams to autoinstall 915resolution, if needed - maybe edgy should do that too? fabbione? ;)
[07:31] <ogra> KaiL, i live around the corner of the c't tv studio now, feel free to write them a letter, i'll happily do question and answer games with them about missig firewalls :P
[07:32] <KaiL> ogra, *g*
[07:33] <bddebian> Loudmouth?  Some of these package names crack me up..
[07:35] <hunger> ogra: They do have a point though: A packetfilter is one line of defense that ubuntu does not have (whether it is needed is a different question).
[07:36] <ogra> hunger, what for if you dont have opne ports ?
[07:36] <fabbione> KaiL: you are becoming highly offtopic and you are not even attempting to document yourself on what you are saying in here
[07:37] <fabbione> KaiL: most of which are FAQ
[07:38] <KaiL> fabbione, maybe you should find  a way, to get those authors to read the faq :)
[07:39] <Keybuk> Kamion, Riddell: actually, I may be able to
[07:39] <Keybuk> Riddell: what package do you need giving back?
[07:40] <Riddell> Keybuk: kdebase please
[07:41] <Keybuk> Riddell: ok, it would appear to be now "Needs Building"
[07:41] <Riddell> Keybuk: great, thanks
[07:41] <Kamion> it should have automatically dep-waited on the packages I promoted
[07:42] <Kamion> and automatically cleared on promotion ...
[07:42] <Kamion> unless that doesn't work with ogre-model problems
[07:42] <Keybuk> I don't think it notices promotion
[07:43] <KaiL> oh, finally something to laugh: on suse 10.1 you need 2 and a half minute (!) to search for a package (ubuntu took 2seconds ;)
[07:44] <mvo> KaiL: haha :)
[07:50] <Keybuk> Riddell: now "Currently building"
[07:50] <Keybuk> (woohoo, I HAVE THE POWAH!)
[07:50] <Riddell> you rock Keybuk 
[07:51] <bddebian> heh
[08:03] <Riddell> Keybuk: are your super powahs also able to get libtunepimp3 and libtunepimp3-dev through NEW into main?
[08:04] <Keybuk> Riddell: yes, but I'm not processing NEW just now
[08:12] <slomo> Riddell: err, libtunepimp needs mad in main again... didn't we want to leave it in universe?
[08:13] <Riddell> slomo: it looks like it's in main
[08:14] <slomo> right... hrm, i wonder why i thought it was in universe :) ok, then nevermind
[08:15] <ogra> slomo, because we try to get mad to universe since warty, but there is always something holing it up ...
[08:18] <slomo> something beeing k3b, akode and libtunepimp...
[08:20] <crimsun> (which makes me wonder why xmms is still in main)
[08:22] <jjesse> `but isn'txmms what people default to?
[08:22] <jjesse> see the post to sounder
[08:23] <ogra> crimsun, thats really strange since all gtk1 apps should be gone 
[08:24] <ogra> pitti, ?
[08:24] <ogra> wasnt that demoted ? 
[08:24] <slomo> ogra: there's still some stuff depending on it in main
[08:24] <slomo> xmms, libdv, flac, smpeg, libiodbc2
[08:25] <ogra> well, i remember pitti doing a major cleanup
[08:26] <crimsun> Keybuk: do you have a sec to check why my earlier upload, mplayerplug-in (circa 0930 UTC today), was blackholed?
[08:27] <Keybuk> are you still having uploader troubles?
[08:27] <pitti> hm?
[08:27] <ogra> pitti, xmms is still in main ? 
[08:27] <pitti> ogra: yes, we didn't get rid of gtk 1.2 for dapper
[08:27] <crimsun> Keybuk: I haven't tried uploading again since that package
[08:27] <ogra> and lots of other gtk1 
[08:27] <ogra> ah, k
[08:27] <slomo> and gtk1.2
[08:27] <ogra> pfft and i had to drop glife 
[08:27] <ogra> *the* killerapp for edubuntu 
[08:29] <ogra> :)
[08:29] <pitti> ogra: that was for gnome 1
[08:29] <ogra> no
[08:29] <pitti> ogra: and indeed we could throw out all the gdk-pixbuf, gnome1, etc. 
[08:29] <ogra> that was for gtk1 and i dropped it in montreal 
[08:30] <ogra> at least thats what you guys shouted at me from your BOF table while i passed by :)
[08:30] <pitti> ogra: Depends: gdk-imlib1, libgnomesupport0, libgnome32, libgnomeui32, ...
[08:30] <ogra> oh
[08:30] <pitti> imlib1 is particularly painful since dead and vulnerability prone
[08:31] <ogra> yeah
[08:31] <ogra> thanks :)
[08:33] <Keybuk> crimsun: it's in failed again
[08:33] <bddebian> doh
[08:33] <Keybuk> gpg: Signature made Tue Jun 27 10:17:57 2006 BST using DSA key ID C88ABDA3
[08:33] <Keybuk> *sigh*
[08:34] <damned> hi all
[08:35] <bddebian> Hello damned
[08:36] <slomo> Keybuk: do you have some time to approve my gtk2 upload to dapper-updates? mdz approved it already last friday before the upload was done
[08:37] <Keybuk> slomo: please bounce the approval mail to ubuntu-archive
[08:37] <Keybuk> (@lists.ubuntu.com)
[08:38] <mdz> Keybuk: I think I CCed you on my reply, let me check
[08:38] <slomo> Keybuk: done (and noted for the future ;) )
[08:39] <mdz> yep, I did
[08:39] <mdz> forwarded to -archive now
[09:03] <gepatino> maybe this is not the place to ask.. but i need to modify the default initrd.gz in desktop cd and for some reason I cant make it boot after modifying it
[09:04] <crimsun> Keybuk: thanks for your time.
[09:09] <vdepizzol> why ubuntu don't come with banshee as default music player?
[09:11] <_ion> Or ion3 as the default window manager? Or Hurd as the default kernel? Or netcat as the default web browser?
[09:12] <Keybuk> why don't the Ubuntu CD packs come with a slice of cheese?
[09:12] <zul> mmm...cheese
[09:12] <Keybuk> A: Because nobody's proposed it yet or because the proposal was turned down.
[09:14] <pitti> _ion: be my friend for s/firefox/nc/. Far, far fewer vulns :-P
[09:14] <gepatino> i need to know how to properly package a new initrd.gz to make a custom ubuntu live cd
[09:14] <gepatino> but cant find someone who knows the details 
[09:15] <Keybuk> gepatino: what do you want to do to the poor thing?
[09:15] <gepatino> move the default user ot of sudoes
[09:15] <gepatino> sudoers
[09:16] <Keybuk> modify the appropriate part of casper, and update-initramfs
[09:17] <gepatino> the problem is that i had to modify initrd.gz by hand (unpackaging it) but cant package it in a format that the kernel could read at bootup
[09:17] <Keybuk> what format are you trying to produce?
[09:18] <Keybuk> it's just a gzip'd cpio file
[09:18] <gepatino> i know that, but i must be missing some parameter, since it doesnt work
[09:19] <gepatino> im doing: find . | cpio -cov | gzip -9 > initrd.gz
[09:22] <gepatino> Keybuk: do you know where i could find some info about how to package a initrd?
[09:23] <_ion> epx: Thanks a lot for the information. I really appreciate that.
[09:23] <Keybuk> gepatino: search the wiki for initramfs or EarlyUserspace
[09:23] <Keybuk> man mkinitramfs
[09:23] <Keybuk> etc.
[09:23] <gepatino> Keybuk: i'll search the wikis
[09:23] <gepatino> Keybuk: thanks
[09:41] <bluefoxicy> pitti:  ping
 why don't the Ubuntu CD packs come with a slice of cheese?
[09:42] <bddebian> hehe
[09:42] <bluefoxicy> Keybuk:  I'd like a CD pack with Xubuntu/Ubuntu/Kubuntu mixed :)
[09:42] <bluefoxicy> (even though I hate KDE)
[09:46] <Keybuk> bluefoxicy: that may be possible if we ship a DVD
[09:51] <ogra> Keybuk, Kamion and infinity_ had this nice conversation about shipping ubuntu on punchcards in london ... it would be cool to have a release printed out on them and to add one to each cd :)
[09:53] <Keybuk> hmm, getting used to a new mouse is damned hard
[09:58] <Seveas> heh
[09:58] <bluefoxicy> does anybody know if the current Edgy gcc 4.1 is supposed to enable stack smash protection by default?
[09:59] <bluefoxicy> https://wiki.ubuntu.com/GccSsp says it will, but I don't know if it's been set up that way yet (my regression tests say it doesn't, so I just want to make sure)
[10:02] <pitti> bluefoxicy: it hasn't been enabled yet
[10:03] <bluefoxicy> pitti:  nod.  It'll show up in the changelog when it is right?
[10:03] <pitti> bluefoxicy: yes; we need to sort out glibc for sparc before we can enable it
[10:03] <bluefoxicy> ah-- wait what?
[10:03] <bluefoxicy> since when does ubuntu have a sparc distribution
[10:03] <Keybuk> dapper
[10:03] <Keybuk> keep up ;)
[10:10] <jcole> Keybuk: it's possible with a mini.iso netinstall... i've made one :)
[11:00] <sivang> re all
[11:00] <bddebian> Heya sivang
[11:00] <bddebian> Kamion: You around?
[11:01] <sivang> hi bddebian , how you been?
[11:01] <bddebian> OK thanks.  You?
[11:01] <sivang> bddebian: very good :-)
[11:32] <Kamion> slomo_: FYI libtunepimp3 has a separate libtunepimp3-mp3 binary split off for the libmad dependency
[11:32] <Kamion> I've newed it now
[11:32] <Kamion> bddebian: no - being called off to bed
[11:33] <Kamion> let me know what it is and I'll deal with it in the morning
[11:33] <bluefoxicy> bddebian:  hi
[11:33] <slomo_> Kamion: i noticed... but it's still another package build-depending on mad and keeping it in main... and we only have 3 with this one ;)
[11:33] <bddebian> Kamion: Just wondered what you meant here:  Bug #5393
[11:33] <Ubugtu> Malone bug 5393 in hula "hula: merge new debian version" [Medium,Confirmed]  http://launchpad.net/bugs/5393
[11:33] <Kamion> oh, build-dep, sure
[11:33] <bddebian> Heya bluefoxicy
[11:33] <bluefoxicy> bddebian: were you the one asking on snort-inline support and its ramifications?
[11:34] <bddebian> Aye
[11:34] <Kamion> bddebian: any other core-dev member should be able to explain that one
[11:34] <bddebian> OK, sorry to bother you then
[11:34] <bluefoxicy> bddebian:  nods.  In a few when you're not busy we can talk if you want
[11:34] <Kamion> the new package ships a totally different set of binaries to the old one
[11:34] <Kamion> and makes no effort whatsoever to handle upgrades
[11:34] <bddebian> Ah, OK
[11:35] <bddebian> bluefoxicy: Shoot
[11:37] <bluefoxicy> bddebian:  I'd like to see snort with inline support because it lets the signatures be used to actually STOP attacks instead of just detect them.  There's enough work in edgy; but that would be attractive for Edgy+1
[11:37] <bluefoxicy> bddebian:  i don't know the detriments of inline support, besides that 2.3 depends on some library we don't have, that's long since deprecated, to interface with iptables' "QUEUE" target; also it takes a special set of drop rules that tell it what attacks to drop
[11:39] <bluefoxicy> Really I'd like to see snort 2.6 hit Debian Unstable with a fresh package based on cdbs (have you seen the snort package?  omg); as for worrying about what to do with it, well.  Everyone's busy with Edgy, so let it alone for now.
[11:39] <bluefoxicy> That's about... all I know really :)
[11:39] <bddebian> bluefoxicy: I guess what I am getting at is does adding --enable-inline affect binary functionality ?
[11:40] <bluefoxicy> bddebian:  Besides depending on a lib we don't have?  I believe not.  lemme take a look real quick.
[11:40] <bluefoxicy> (yeah, I noticed we CAN'T add --enable-inline because of that)
[11:40] <bluefoxicy> http://www.snort.org/docs/snort_manual/node7.html
[11:40] <bddebian> Does 2.6 have the same issue?
[11:42] <bluefoxicy> I don't know.  We don't even have a 2.6 (or 2.4 for that matter) snort anyway.
[11:42] <bluefoxicy>   --enable-inline          Use the libipq interface for inline snort
[11:43] <bluefoxicy> yeah.. and libipq is still deprecated.. wikipedia says it will be replaced by libnetfilter_queue
[11:44] <bluefoxicy> bddebian:  we should probably just leave that bug open for now.  It's not pressing, it's wishlist.
[11:46] <bddebian> Gah
[11:46] <bddebian> OK, thanks
[11:51] <bddebian> bluefoxicy: Bug #50058  :-)
[11:51] <Ubugtu> Malone bug 50058 in oinkmaster "The Snort rules is no longer FREE! (Oinkmaster can't get the rules)" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/50058
[11:51] <bluefoxicy> bddebian:  what damn!  :(
[11:52] <bluefoxicy> bddebian:  oinkmaster should be able to get the registered rules... "Registered users can access rule updates 5 days after release to subscription users."  http://snort.org/rules/
[11:52] <bluefoxicy> bddebian:  you do need to register to get them ;)
[12:00] <bddebian> Later folks
[12:00] <doko> bluefoxicy: what's your question about gcc?
[12:02] <bluefoxicy> doko:  pitti got it already, I wanted to know if stack smash protection was on by default yet
[12:03] <Keybuk> bluefoxicy: you were told it wasn't already
[12:03] <Keybuk> and you were told why
[12:03] <bluefoxicy> Keybuk:  yes that's what I said, pitti got it already.
[12:03] <Keybuk> ah, sorry, misread your statement as a question :)
[12:03] <Keybuk> my bad
[12:04] <bluefoxicy> Keybuk:  besides, you know I have to be told more than once ;)