[12:04] <Kamion> mdz: I'll do that udevstart change tomorrow
[12:06] <mdz> thanks and thanks
[12:06] <Kamion> ta for the idea
[12:06] <mdz> untranslated messages sound OK for unattended installs
[12:06] <mdz> I guess it only sucks if some detection step fails
[12:06] <Kamion> I tend to agree. The only issue is if it has to stop and wait for keyboard input
[12:07] <Kamion> but most people can probably cope in an emergency
[12:07] <HrdwrBoB> unless they have a usb keyboard
[12:07] <Kamion> anyway, time for !work
[12:07] <HrdwrBoB> with no legacy emulation
[12:07] <HrdwrBoB> eg:mac
[12:07] <Kamion> HrdwrBoB: that's already set up before the keyboard chooser runs, or you would not be able to select your language.
[12:07] <HrdwrBoB> true
[12:08] <Kamion> we're not talking about not doing keyboard hardware probing
[12:08] <mjg59> What's the situation with respect to the kernel at the moment?
[12:08] <HrdwrBoB> apparently thought he low memory detector runs before hotplug
[12:08] <Kamion> this is purely layout
[12:08] <mdz> Kamion: did smurfix talk with you about integrating the keyboard layout selector?
[12:08] <Kamion> mdz: yes, I gave him some hints
[12:08] <mdz> ok, good
[12:08] <Kamion> HrdwrBoB: it runs before hw-detect, but hotplug does stuff well before that in practice.
[12:08] <Kamion> HrdwrBoB: there's also usb-discover, which runs in debian-installer-startup.d
[12:09] <mjg59> There's a couple of patches I could do with getting in
[12:09] <Kamion> really gone
[12:20] <YokoZar> Hey, can someone help me out with a package?
[12:21] <YokoZar> It's sort of half compiling (gets to the .deb file, but errors before asking for my key)  The deb file works though
[12:22] <YokoZar> deb-src http://tuzakey.com/~scott/apt source/
[12:22] <dholbach> YokoZar: what does it say? what error messages?
[12:22] <YokoZar> The package is winetools
[12:22] <YokoZar> It's a make: clean error - "no package"
[12:22] <dholbach> YokoZar: and before that?
[12:23] <YokoZar> Before that it finishes the build package step I think
[12:25] <dholbach> YokoZar: the build-depends are surely wrong
[12:25] <dholbach> YokoZar: i mean debian/control
[12:27] <dholbach> brb
[12:42] <srbaker> doesn't ssmtp do what sjr wants?
[12:45] <tseng> srbaker: having only read the summary in ubuntu traffic, i believe ssmtp does
[12:45] <srbaker> good
[12:45] <tseng> its the default mta in gentoo to fill the same niche as described
[12:45] <tseng> /usr/bin/sendmail w/o listening daemon
[12:46] <srbaker> excellent
[12:46] <srbaker> the unfortunate thing about gentoo is that there are a few smart people wasting their time on it :(
[12:46] <srbaker> those people would have their efforts better spent on Debian, Ubuntu, Fedora, or FreeBSD.
[12:47] <tseng> i spend time on both, incidentally
[12:47] <srbaker> tseng, ahh.  you're wasing some of your time, then ;)
[12:47] <tseng> srbaker: the hardened gentoo project is currently a fair bit ahead of anyone else in the area.
[12:48] <tseng> unless you count security-by-marketability ala redhat
[12:48] <srbaker> fedora is pretty good at security
[12:48] <tseng> erm, not at hardening
[12:49] <tseng> ill not discuss it too much here, but there are several glaring flaws in ES, and their use of PIE is limited
[12:49] <tseng> and they ignore SSP entirely.
[12:50] <srbaker> not ES.  Fedora.
[12:50] <tseng> i assume you are talking about reactive security, which im not talking about
[12:50] <srbaker> ?
[12:50] <srbaker> no, i'm talking about preventative security
[12:51] <tseng> so whats good about it
[12:51] <srbaker> the default selinux policy is quite good
[12:52] <tseng> you mean the targetted policy?
[12:52] <tseng> it only protects a select few apps, same as their PIE strategy
[12:53] <tseng> but anyway, fedora is OT here, and ubuntu can do better.
[12:55] <dholbach> good night guys... i'm off to bed :-)
[12:55] <tseng> cya dholbach.
[12:55] <dholbach> and be sure to check out the new  coaster  packages :-)
[12:56] <dholbach> and be sure to check out the new  coaster  packages :-)
[12:57] <dholbach> tseng: damn, now i didnt look after the script you gave me
[12:58] <dholbach> *fiddle around*
[12:58] <tseng> i looked at your site
[12:58] <tseng> and that script wont help you much
[12:58] <tseng> it assumes all packages are in one dir
[12:59] <dholbach> tseng: every *.deb *.dsc *.orig.tar.gz *.diff.gz - everything?
[12:59] <tseng> heh, yes
[12:59] <dholbach> i erm... see
[12:59] <tseng> you could split deb and source
[12:59] <tseng> or use a more complex method
[12:59] <dholbach> no... it's complex enough for me... given the time ;-)
[12:59] <tseng> i havent experimented with multi dir repos
[01:14] <dholbach> i hate my internet connection :-/
[01:15] <dholbach> but it works... thanks tseng :-)
[01:15] <dholbach> so when this upload should *ever* be over... 
[01:31] <dholbach> the upload will still take like 15 minutes, but if anyone of you is interested in (1) amd64 binaries:   deb http://ubuntu.stufenseite.de/Repo ./   or  (2) sources:   deb-src http://ubuntu.stufenseite.de/Repo ./
[01:31] <dholbach> (of coaster and g*mm & co :-))
[01:32] <mdz> it's a bug, dude
[01:32] <jdub> that's why it's in the bug tracker!
[01:32] <mdz> which aspect of it triggered the boggle?
[01:33] <mdz> did you get my email about gnome-bt?
[01:33] <jdub> someone finding it and bothering to report the bug
[01:33] <jdub> yes
[01:33] <mdz> I installed it; the package seems quite sane
[01:33] <mdz> installed, clicked on .torrent in firefox, everything went
[01:40] <marcin_> jdub: sorry that I'm asking you a question about website contest, again - but are you really going to judge skins and mockups equally? even when these mockups won't be usable (to hard to implement as real skins or too "heavy" and require too much bandwidth) but just pretty?
[01:40] <jdub> marcin_: sure
[01:41] <jdub> marcin_: they'll be judged on their appropriateness for the ubuntu website
[01:41] <marcin_> jdub: i just have some projects as images and don't know if just send them as they are or work on html...
[01:41] <jdub> the announce says you're welcome to send images
[01:42] <tseng> jdub: tomboy! :P
[01:42] <marcin_> jdub: hmm ok - than I'll have them ready for tomorrow
[01:42] <jdub> tseng: i will put it on my list for today :)
[01:42] <marcin_> jdub: thanks :)
[01:42] <tseng> jdub: yay!
[01:43] <crimsun> (as an aside, mono* 1.0.5 builds on sid now; the build problem was resolved)
[01:43] <tseng> crimsun: yay some more
[01:43] <tseng> except i cant get to alioth currently..
[01:45] <crimsun> try http://www.meebey.net/debian/mono-suite, though it's currently not responding for me
[01:45] <tseng> yeah not much luck here either
[01:45] <mdz> jdub: any reason not to put gnome-bt into hoary and run with it?
[01:45] <jdub> mdz: i'll look at it today
[01:46] <mdz> ok
[01:46] <thom> mdz: is this week of the weird firefox bugs?
[01:46] <thom> :-)
[01:46] <jdub> i doubt i'd say no; we need one, even as a transition to something much nicer
[01:46] <jdub> thom: you've seen the weird text highlighting / overlap stuff?
[01:47] <thom> jdub: only with a really teeny font in a text entry box
[01:47] <jdub> hmm
[01:47] <jdub> i wonder if it's screenshottable
[01:47] <jdub> so there's two things i'm seeing:
[01:47] <thom> and then, only on our bugzilla
[01:48] <jdub> text seems to run outside right boundaries
[01:48] <jdub> like on my tabs atm, text runs off the right side (that's shottable)
[01:48] <thom> please screenshot and bug
[01:48] <jdub> second thing is when editing, the cursor appears a couple of letters to the left, and i don't see all the text i've typed
[01:49] <thom> i've seen that, and caillon has mentioned it also
[01:49] <mdz> thom: this has been happening to me for a while; I only just got around to reporting it
[01:49] <jdub> hmm, might try two at once
[01:49] <mdz> I just assumed it happened to everyone
[01:49] <thom> mdz: i blame squid (even if you don't have a squid proxy)
[01:50] <mdz> thom: I do use squid, but it happens without it, and even so, I can't think of any way that squid could cause that
[01:50] <mdz> why the hell would it use anything other than the URL to determine the filename to use?
[01:50] <thom> neither can i, but i can't imagine why firefox would append .tar.gz to everything
[01:51] <thom> it might be trying to be smart with the mime type
[01:51] <mdz> it's not everything; only .gz
[01:51] <jdub> thom: people.ubuntu.com/~jdub/screenshots/
[01:51] <mdz> so .orig.tar.gz -> .orig.tar.gz.tgz
[01:51] <mdz> and .diff.gz -> .diff.gz.tgz
[01:51] <mdz> I N S A N E
[01:51] <mdz> jdub: we're talking about #6020; any idea?
[01:52] <jdub> on sec
[01:52] <thom> mdz: that's pretty amazing, really
[01:53] <dholbach> upload finished
[01:53] <jdub> mdz: can't reproduce
[01:53] <mdz> wtf
[01:53] <mdz> it is "weird firefox bugs that only happen to mdz" week
[01:53] <mdz> I don't even know where to look for this bug
[01:53] <jdub> certainly a special one
[01:53] <mdz> that file saving dialog is gtk, right?
[01:53] <thom> mdz: yes
[01:54] <thom> EZ GTK BOOG
[01:54] <thom> ahem
[01:54] <mdz> it also seems odd that the "save in folder" selector is blank; is that also only me?
[01:55] <dholbach> good night guys... now i'm off
[01:55] <dholbach> *wave*
[01:55] <thom> mdz: mine comes up with Home by default
[01:55] <ajmitch> good afternoon all
[01:55] <thom> so yeah, seems like another one specially for you
[01:55] <mdz> thom: I have "save all files to this folder: /tmp" in my firefox prefs
[01:56] <mdz> though switching to "ask me every time" gives exactly the same results
[01:56] <mdz> I blame file-roller
[01:56] <mdz> or some other random GNOME component
[01:57] <thom> mdz: even with that setting, i don't get a blank Location
[01:57] <ajmitch> mono 1.0.5 in universe yet? meebey fixed the build failures with 1.0.4
[01:57] <mdz> maybe seb128 will have an idea
[01:57] <thom> mdz: OOI, if you move your .mozilla/firefox directroy out the way, do all these things still happen?
[01:57] <mdz> ajmitch: http://www.ubuntulinux.org/wiki/UpstreamVersionFreeze
[01:57] <thom> (and restart mozilla)
[01:57] <mdz> will try
[01:58] <mdz> it would be nice if firefox would restore my tabs
[01:58] <ajmitch> mdz: yes, I've been told it's a bit more flexible with universe
[01:58] <mdz> like galeon did about 5 years ago
[01:58] <ajmitch> especially as it gets a package building properly
[01:58] <mdz> ajmitch: yes, the policy is more relaxed, but no updates happen unless explicitly requested
[01:58] <thom> mdz: yes, well
[01:58] <ogra> thom: is this better ? http://www.grawert.net/hal_cpuinfo.png (no more /proc/acpi)
[01:59] <thom> mdz: firefox doesn't have xsm support yet, tabs are way more advanced ;-)
[01:59] <ajmitch> mdz: may I request it then? 
[01:59] <mdz> thom: still happens
[01:59] <thom> ogra: cool!
[01:59] <ogra> :)
[01:59] <mdz> though all my preferences are clearly still there
[01:59] <ajmitch> I don't think they've been uploaded to sid yet
[01:59] <mdz> maybe I need to move all of ~/.mozilla?
[02:00] <mdz> ajmitch: yes
[02:00] <thom> they shouldn't be. give it a whirl
[02:00] <mdz> ah, it's using ~/.firefox
[02:00] <ajmitch> nope, not in sid, just in meebey's local archive
[02:01] <mdz> is that abnormal?
[02:01] <thom> mdz: you *have* a .firefox?
[02:01] <mdz> of course
[02:01] <tritium> thom, the changelog says that gnomestripe theme is "enabled".  In fact, it seems to have completely replaced the default theme.
[02:01] <thom> tritium: yes
[02:01] <thom> tritium: bug already filed
[02:01] <tritium> thom, okay, thanks
[02:01] <thom> mdz: um, i think that's somewhat abnormal
[02:02] <mjg59> So, by hacking the cardbus driver, removing the ACPI processor module and doing some setpci calls on resume, I can get my old Thinkpad to have ACPI love
[02:02] <mjg59> thom: We're going to have to hack acpid. /etc/init.d/acpid stop only works by accident
[02:02] <mjg59> On slower machines, acpid is never stopped
[02:02] <mjg59> Or rather, it only gets stopped after resume, so it comes back up and acpid is no longer running
[02:02] <mdz> nuking my profile seems to fix the .tgz thing
[02:02] <mjg59> We need acpid to read a lock file and refuse to execute any events if it exists
[02:03] <mdz> but the folder selector is still blank
[02:03] <mdz> and I don't _want _ to nuke my profile ;-/
[02:03] <thom> interestingly, my laptop has a .firefox, my desktop does not
[02:04] <mdz> I have files in both ~/.firefox and ~/.mozilla/firefox with recent mtimes
[02:04] <mdz> it's clearly using both
[02:05] <mdz> I seem to have one profile in ~/.mozilla/mdz/nthoe233423 and one in ~/.firefox/default/udn2h34oue
[02:05] <thom> mjg59: lovely. agree on using lock file, will you file a bug?
[02:05] <mdz> my ~/.mozilla/firefox has only a couple of files in it
[02:06] <mdz> ~/.mozilla/firefox/profiles.ini says: Path=/home/mdz/.firefox/default/zw3md3kx.slt
[02:06] <mjg59> thom: Yeah, will do
[02:08] <mdz> thom: what does your ~/.mozilla/firefox/profiles.ini say in both places/
[02:08] <mdz> ?
[02:08] <mjg59> thom: 6026
[02:08] <mdz> my laptop has no ~/.firefox, and profiles.ini points to a relative path in ~/.mozilla
[02:08] <thom> mjg59: thanks
[02:08] <mdz> hell, I have a ~/.phoenix on my desktop
[02:08] <thom> my desktop is the same as your laptop
[02:09] <thom> holy crap, .phoenix is OLD SKOOL
[02:09] <mdz> this home directory goes way back
[02:09] <thom> and my laptop is the same as your desktop
[02:09] <mdz> I don't suppose you get cracked out .tgz behaviour on your laptop
[02:10] <thom> nopd
[02:12] <thom> uh, that was an attempt at nope
[02:14] <tseng> mdz: what do you mean by cracked out?
[02:14] <tseng> i have some pretty odd behaviour
[02:15] <tseng> opening a tgz in file-roller that ive already opened once.
[02:15] <tseng> from firefox
[02:16] <thom> tseng: this is firefox appending .tgz on the end of anyfile ending .gz
[02:17] <tseng> thats almost as gross.
[02:17] <tseng> but havent seen it
[02:31] <lupus_> fabbione, ping
[02:36] <thom> g'night folks
[02:36] <ogra> night
[02:38] <daniels> thom: 'night dude
[02:39] <tritium> goodnight thom
[03:14] <daniels>     if [ "$DEVICE_IDENTIFIER" = "ATI Technologies, Inc. Rage Mobility M3 (AGP)" ]  || \
[03:15] <daniels>        echo "$DEVICE_IDENTIFIER" | grep -q "Rage 128"; then
[03:16] <mjg59> Hahaha
[03:27] <mjg59> daniels: I ought to have a T42 with radeon power consumption issues to play with this week
[03:28] <tritium> mjg59, and if you can get your hands on a Dell C840, the double-power-button resume issue too ;)
[03:28] <daniels> mjg59: nice
[03:29] <tritium> mjg59, or, I'd make time to investigate with your assistance, if you're up for it.
[04:04] <zul> daniels: ping
[04:13] <daniels> zul: sup
[04:25] <jdub> mjg59: is there a useful way of figuring out which devices are sucking power?
[04:33] <zul> daniels: i saw your bug about the slmodem stuff, i thought the drivers were for the usb modems
[04:49] <bob2> btw, using udevsendfor /proc/sys/kernel/hotplug has broken ipw2100 as predicted
[06:57] <jdub>    * Remove speedo and v4l from the list of modules loaded per default.
[06:57] <jdub> daniels: yay!
[06:58] <daniels> glcore and dri gone, too
[06:58] <daniels> since all the dri drivers load dri if they want it
[06:59] <daniels> and that simplifies the nvidia process somewhat
[06:59] <jdub> elite :)
[06:59] <tritium> daniels, good idea
[07:01] <fabbione> morning guys
[07:02] <daniels> morning fabbione
[07:02] <fabbione> hi dani
[07:02] <mdz> daniels:    * Also from Mesa 6.2.x branch, grab fix for lockups on Radeon M7-class chips     (fd.o#2361).
[07:02] <mdz> daniels: that sounds like maybe the lockup I was experiencing?
[07:03] <daniels> mdz: ya-huh
[07:03] <mdz> yay, I'll give it a try once it's built
[07:03] <mdz> I had just downloaded the whole set of xserver/xlibmesa/etc. packages you suggested and was dreading having to trial-and-error my way through them
[07:03] <fabbione> ah there is a fix for the amd64 ia32 emulation crash
[07:04] <fabbione> good.. 
[07:04] <jdub> daniels: photos please.
[07:05] <sivang> Morning everyone
[07:08] <fabbione> mdz: is there anything important i need to look at before i go back and crash?
[07:08] <mdz> fabbione: you are still feeling sick, eh?
[07:08] <mdz> fabbione: no, nothing urgent
[07:08] <fabbione> mdz: fever is going down (to 38 today)
[07:09] <fabbione> but i don't feel good enough to spend the day in front of the pc
[07:09] <mdz> it must have been high
[07:09] <fabbione> mdz: top was 40,4 saturday night
[07:09] <pitti> Morning!
[07:09] <pitti> fabbione: still fever?
[07:09] <fabbione> pitti: yes :(
[07:11] <fabbione> rmdz: ok.. i am just fixing the amd64 ia32 emulation so that Kamion can test more and i am off again
[07:11] <sivang> morning pitti , fabbione 
[07:11] <fabbione> hi sivang 
[07:12] <pitti> Hi sivang!
[07:12] <pitti> sivang: What does g-s-t do? :-)
[07:12] <sivang> fabbione: feeling better?
[07:12] <fabbione> sivang: a bit, yes.. but still not good enough
[07:12] <sivang> pitti: trouble? ;-)
[07:12] <pitti> mdz: oh, thanks for signing my key
[07:12] <pitti> sivang: still? /msg me...
[07:13] <sivang> fabbione: thne you should rest until you're better, without the proper resting it could get longer..
[07:14] <fabbione> sivang: that's what i am going to do :-) but i had to get up a bit from the bed.. my gf is changing sheets and air :)
[07:14] <sivang> fabbione: eh, that's important when you're ill :) good
[07:21] <pitti> fabbione: hmm, would some kernel bugs cheer you up?
[07:21] <pitti> fabbione: (not that I had some...) :-)
[07:22] <fabbione> pitti: you mean fixes for some bug? yes :-)
[07:31] <dilinger> pitti: i bet not as much as some kernel security bugs
[07:32] <pitti> dilinger: hmm, mostly I talk about security bugs :-)
[07:40] <sivang> pitti: some people reported problem with reading parts of a website in hebrew, notebaly due to /usr/lib/mozilla-firefox/firefox having a variable MOZ_ENABLE_PANGO = 1 , you have any idea?
[07:40] <sivang> (the hebrew letters were presented backwards)
[07:40] <pitti> sivang: hmm, no
[07:41] <pitti> sivang: that means pango is somehow broken?
[07:41] <jdub> means that pango/firefox integration has issues
[07:41] <sivang> pitti: might be, because this wasn't apparent until a couple of upgrades a go..
[08:12] <pitti> ogra: ping
[08:50] <pitti> doko: here?
[08:51] <doko> pitti: yes
[09:07] <dholbach> morning!
[09:10] <sivang> dholbach: morning
[09:10] <dholbach> hi sivang
[09:12] <dholbach> sivang: i tested your g-s-t yesterday - it ran just fine :-)
[09:13] <dholbach> sivang: but the packaging needs a bit of love - shall i send you a couple of notes?
[09:13] <sivang> dholbach: cool, I am still working on it , have some quality stuff to fix :) 
[09:13] <sivang> dholbach: working already with pitt, no need :)
[09:14] <dholbach> ok
[09:30] <sivang> dholbach: but tnx
[09:30] <sivang> dholbach: if you have made them already, feel free to send them thought won't hurt more critisism :) It's always good to be better
[09:31] <dholbach> sivang: your mail adress is?
[10:00] <dholbach> hai mvo_
[10:01] <mvo_> hi dholbach 
[10:01] <mvo_> morning all
[10:02] <sivang> mvo_: morning
[10:02] <pitti> Hi mvo!
[10:02] <mvo_> hi sivang, hi pitti 
[10:02] <pitti> mvo_: what is required to build a package with bzip2 compression?
[10:04] <mvo_> pitti: never done it, but I think dpkg-deb --build on the .bz2 files
[10:04] <pitti> mvo_: no, I mean compressing the debs with bzip2 instead of gzip
[10:04] <pitti> mvo_: i. e. foo.deb -> control.tar.gz + data.tar.bz2
[10:05] <mvo_> I don't know if there is a automatic way yet, but repacking the data+control.gz to .bz2 and call dpkg-deb --build on it
[10:05] <pitti> bah
[10:06] <mvo_> pitti: keybuk is not around :) ?
[10:06] <pitti> no, not yet
[10:06] <pitti> mvo_: I wanted to catch him already last week, but he was on vac
[10:07] <mvo_> yes, I noticed. I wanted to ask him stuff about hct
[10:07] <pitti> I wanted him to fix a dpkg bug :-)
[10:07] <mvo_> hehe :)
[10:24] <Kamion> pitti: use the '-Z bzip2' flag to dpkg-deb
[10:24] <pitti> Kamion: ah, cool
[10:25] <pitti> Kamion: so, dh_builddep -- -Z bzip2 ?
[10:26] <Kamion> think so
[10:32] <pitti> elmo: ping
[10:41] <d3vic3> pitti, elmo is not around 
[10:41] <pitti> hmm
[10:42] <ogra> morning guys
[10:43] <ogra> pitti: seen this ? http://www.grawert.net/hal_cpuinfo.png :-D http://www.grawert.net/hal_meminfo.png
[10:43] <pitti> Hi ogra!
[10:43] <pitti> ogra: today there was an interesting thread on hal@fd.o
[10:43] <pitti> ogra: a guy presented his procfs code
[10:43] <pitti> ogra: and it will very likely be merged into hal cvs
[10:44] <pitti> ogra: however, not in the 0.4 branch
[10:44] <ogra> pitti: its already beckported ;)
[10:44] <pitti> ogra: oh, cool
[10:44] <ogra> back even
[10:44] <ogra> look at the screenshots above :)
[10:44] <pitti> looks great
[10:44] <pitti> ogra: also for powerpc?
[10:44] <ogra> thom convinced me to use /proc/cpuinfo istead of all this acpi ...
[10:44] <ogra> yup
[10:44] <ogra> tested on all 3 warty arches
[10:45] <pitti> dmidecode will follow?
[10:45] <ogra> i got a test package up (no clean patch yet) you can try it: http://www.grawert.net/hal_0.4.7-1ubuntu1_powerpc.deb
[10:46] <pitti> ogra: ahem, shouldn't that be 1ubuntu2?
[10:46] <pitti> ogra: or, even better 1ubuntu1ogra1 or so? :-)
[10:46] <ogra> pitti: just for a test ? 
[10:46] <pitti> nevermind :.-)
[10:47] <ogra> pitti: i dont want to steal it from sjoerd (will just send in patches) 
[10:48] <pitti> ogra: sjoerd will include this into sid?
[10:48] <pitti> that's even better...
[10:48] <ogra> ah, and this one: http://www.grawert.net/hal-device-manager_0.4.7-1ubuntu1_all.deb
[10:48] <ogra> pitti: dunno, if he likes....
[10:48] <pitti> would be cool
[10:50] <ogra> pitti: currently i'm struggling a bit wih th dmidecode idea... you know that it needs direct access to /dev/mem ?
[10:51] <pitti> ogra: uh, read-only?
[10:51] <pitti> ogra: that would mean that you need the kmem group for hal
[10:51] <ogra> pitti: nope, but it needs definately uid=0 or group kmem .... both not nice for hal
[10:52] <ogra> pitti: is this secure ?
[10:52] <pitti> ogra: could you create a separate kmem-sgid binary "hal-dmidecode-detect"
[10:52] <pitti> ogra: and call this from hald?
[10:52] <pitti> this would separate the privileges 
[10:52] <ogra> yup
[10:52] <pitti> and confine kmem rights to a minimum
[10:52] <ogra> i'll try...
[10:53] <pitti> running hald proper in kmem wouldn't be so nice
[10:53] <ogra> gah,i made a mistake in uploading glibmm ....
[10:53] <ogra> pitti: thats what i thought
[10:54] <ogra> pitti: the patch code of this guy was sent from heaven, its a really nice code testbed :)
[10:58] <pitti> ogra: so you indeed could use Richard Hughes' code
[10:58] <pitti> ?
[10:58] <ogra> pitti: thats what i'm talking about ;)
[10:59] <elmo> pitti: ?
[11:02] <pitti> elmo: mdz asked me to build the langpacks with bzip2 compression in the future
[11:02] <pitti> elmo: however, that requires the hoary version of dpkg in the langpack dchroot
[11:02] <pitti> elmo: is it possible to upgrade to this?
[11:03] <elmo> see this kind of crack is exactly why the bzip2 compression thing is so ridiculous
[11:03] <elmo> what would you do if we weren't using a chroot?  ask me to upgrade rookery to hoary?
[11:04] <infinity> Ubtuntu is moving to bzip2 debs without a skip-a-release policy?
[11:04] <aj> but bzip2 barely ever makes any difference anyway?
[11:05] <mjg59> jdub: Nope
[11:05] <elmo> infinity: pre-depends on relevant version of dpkg
[11:05] <elmo> and it's only being used where it does make a difference
[11:05] <infinity> elmo : Ugly.
[11:05] <elmo> and presumably pitti has figures to show it does for language packs
[11:05] <elmo> pitti: (right?)
[11:05] <elmo> infinity: *shrug* it fits more stuff on the CD - which is more of an issue for us than it is for Debian
[11:05] <infinity> A deb pre-depending on a versioned dpkg is sick.
.. Fair nuff.
[11:06] <pitti> elmo: 
[11:06] <pitti> -rw-r--r--  1 martin martin 2723900 2005-01-31 10:46 language-pack-de_20050128_all.deb
[11:06] <pitti> -rw-r--r--  1 martin martin 3173814 2005-01-31 10:45 language-pack-de_20050128_all.deb.gzip
[11:06] <elmo> btw, pre-depending on a versioned dpkg has plenty of precedent
[11:06] <aj> that doesn't work though does it? dpkg --unpack dpkg.deb foo.deb # will satisfy the pre-dep, but use the old dpkg to unpack the foo.deb with the pre-deps
[11:06] <infinity> I wonder if this "you can use -Z bzip2 if you predepend on dpkg >= foo" would fly in Debian as well.
[11:06] <pitti> 2.7 MB vs. 3.1 MB
[11:07] <elmo> infinity: it won't, you need the right dpkg on the katie machine too, which newraff doesn't have
[11:07] <elmo> there's checks in katie to enforce the pre-dependency tho
[11:07] <infinity> Check.
[11:08] <elmo> aj: err, unpacked doesn't satisfy pre-deps?
[11:08] <pitti> so it saves 15%
[11:08] <aj> elmo: ?
[11:08] <pitti> Morning seb128!
[11:08] <elmo> aj: I thought definition of pre-depends was that it must be installed _and_ configured?
[11:09] <aj> oh, i didn't think that applied to essential packages?
[11:09] <seb128> hello!
[11:09] <mvo_> hi seb128 
[11:09] <dholbach> hi seb128
[11:09] <ogra> morning seb128
[11:09] <seb128> pitti: you DOSed my box with udev, bad guy
[11:09] <seb128> pitti: I had to reboot :p
[11:09] <pitti> seb128: hmm?
[11:10] <aj> (note that apt never invokes dpkg like that anyway, so this isn't terribly important)
[11:10] <pitti> seb128: I did not even touch udev recently
[11:10] <mvo_> did the same to me at friday :)
[11:10] <pitti> seb128: ah, did your cpu go to 100% on hal upgrade?
[11:10] <infinity> aj : Won't your scenario just fork a new dpkg-deb for the second unpack anyway, thus using the newly installed binary?
[11:10] <seb128> pitti: friday I updated hal and after that load ~9 and a ton of udev stuff moving in the ps list
[11:10] <ogra> pitti: same here (only on amd64) ...
[11:11] <pitti> seb128, ogra: we are reasonably convinced that his is a kernel bug
[11:11] <seb128> pitti: and you were hidding from IRC :p (I should probably blame your ISP for this one :p)
[11:11] <ogra> pitti: udev freaks out after the update (cant verify it on ppc or i386)
[11:11] <pitti> it happens with older hal versions too, and it doesn't happen in Debian
[11:11] <seb128> pitti: so that's fabbione's fault ? :)
[11:11] <ogra> pitti: but they may be not up to date currently...
[11:12] <elmo> aj: debootstrap does tho, I guess?
[11:12] <pitti> seb128: yes, I was mostly offline friday morning :-(
[11:12] <pitti> ogra, seb128: were any of you able to identify the culprit?
[11:12] <aj> elmo: debootstrap assumes dpkg and other stuff is tar/gzip/ar'ed too
[11:12] <pitti> ogra: this is an udev issue?
[11:12] <elmo> aj: really?  neat
[11:13] <aj> elmo: it has to unpack dpkg before dpkg is installed
[11:13] <ogra> pitti: my log shows udev trying to create /dev/ramXX
[11:13] <elmo> aj: ok, but it doesn't make that assumption in general?
[11:13] <pitti> ogra: and it went mad on this one?
[11:13] <infinity> But once dpkg is installed, it uses dpkg-deb for the rest, right?
[11:13] <aj> elmo: it doesn't make any assumptions for stuff outside base, obviously
[11:13] <ogra> pitti: it does it over and over
[11:13] <elmo> if anyone suggests bzip-ing the data.tar of dpkg, I'll beat them senselesss
[11:13] <aj> elmo: it makes that assumption for, hrm, essential/required; probably nothing else
[11:13] <ogra> pitti: always the same devices....
[11:13] <infinity> elmo : How about you bzip2 the data.tar of dpkg?
[11:14] <seb128> pitti: http://rafb.net/paste/results/ofl3gX45.html
[11:15] <infinity> pitti : How good do you feel about that php4-curl patch?
[11:15] <seb128> pitti: this was moving a lot (ie: ps and ps again one second after and the totally different processes)
[11:16] <ogra> elmo: can you give me a hint for glibmm2.4 ? why is the sig not accepted ? i rebuilt the source package...so it should carry my sig, or am i wrong ?
[11:16] <aj> iU  dpkg           1.9.21         Package maintenance system for Debian
[11:16] <aj> aj@labrador:~$ sudo dpkg --unpack /var/cache/apt/archives/vim_6.1.018-1_i386.deb 
[11:17] <aj> Unpacking vim (from .../vim_6.1.018-1_i386.deb) ...
[11:17] <aj> aj@labrador:~$ dpkg -s vim | grep Pre-Dep
[11:17] <aj> Pre-Depends: dpkg (>= 1.6.8)
[11:17] <elmo> ogra: glibmm2.4 is in main
[11:17] <elmo> aj: score
[11:17] <ogra> elmo: oh ?
[11:18] <elmo>  glibmm2.4 |    2.4.5-1 |         hoary | source
[11:18] <ogra> elmo: sorry...
[11:18] <infinity> aj : Uhm.  1.9.21 is higher than 1.6.8, no? :)
[11:18] <elmo> libglibmm-2.4-1                                   | glibmm2.4                       | inkscape                                        | Bradley Bell <btb@debian.org>                                             |          113746 |             376
[11:18] <infinity> aj: Oh, I didn't notice dpkg was only unpacked.
[11:18] <aj> yeah
[11:18] <aj> it was previously configured at 1.9.21; but i don't think dpkg would've noticed that
[11:18] <ogra> elmo: ok, so we need a more uploader for the fixed pakages then :)
[11:19] <ogra> more potent...
[11:20] <ogra> seb128: would you like to be able to use gtkmm again ? dholbach prepared packages ....
[11:20] <pitti> seb128: hmm, thanks. I try to reproduce it.
[11:20] <infinity> aj : Still, in your "dpkg --unpack dpkg.deb foo.deb" scenario, doesn't dpkg fork an instance of dpkg-deb for each of those successive unpacks, and therefor the second dpkg-deb forked would be from the new dpkg.deb?
[11:20] <aj> oh, right
[11:20] <pitti> infinity: which patch? the one which respects open_basedir restriction?
[11:20] <infinity> pitti : Is there another one? :)
[11:20] <elmo> does dpkg even order the unpacking tho?
[11:20] <seb128> dholbach: hum, main, different issue ...
[11:21] <elmo> or just respect the order on the command line
[11:21] <pitti> infinity: well, I think I already explained in the BTS followup
[11:21] <pitti> infinity: if upstream does not want to support it
[11:21] <infinity> elmo : It's supposed to order complete operations for pre-deps, but I suppose only testing would confirm.
[11:21] <aj> i think it does the cmd line ordering; but it'd error if you tried it the otherway, so no big deal
[11:21] <pitti> infinity: then Debian and Ubuntu either should maintain it on their own
[11:21] <pitti> infinity: or drop it
[11:21] <seb128> dholbach: I'll have a look on the package 
[11:21] <pitti> infinity: but if nobody else actually uses it, then I think we should rather say the truth
[11:21] <infinity> pitti : I'm okay with maintaining it if you're more or less happy with the patch itself.
[11:22] <pitti> infinity: and tell that the open_basedir restriction is mostly bogus
[11:22] <dholbach> seb128: yes... unfortunately - i consulted configure.in and made sure the API wasnt broken - i tried inkscape/regexxer, which use it - but it 'd be great if some one else 'd have a look
[11:22] <pitti> infinity: I'm fine with the patch, it works well for me
[11:22] <aj> hrm, dpkg-deb is invoked, so it might be fine anyway
[11:22] <dholbach> seb128: deb-src http://ubuntu.stufenseite.de/Repo ./
[11:22] <pitti> infinity: it might have holes, but then again the whole open_basedir thingy has holes :-)
[11:22] <seb128> dholbach: thanks
[11:22] <infinity> pitti : open_basedir, basically, is guaranteed (modulo bugs) to work with zend and ext/standard.  Anything else is up in the air.  They have too many extensions to police.
[11:23] <ogra> seb128: there is also a working coaster package ;)
[11:23] <pitti> infinity: then I'd think, take it for now and drop it as soon as it causes trouble (new code and you have rejections, etc.)
[11:23] <pitti> infinity: what would you do with it?
[11:23] <infinity> pitti : On the other hand, patches have been recently submitted and accepted for fixing open_basedir issues in other extensions.  So it might just be the curl extension maintainer whose head is firmly up his ass.
[11:24] <infinity> pitti : I'll add it in the next Debian upload.  If I find a spare moment to argue with the 12-year-olds I call "upstream", I'll see about getting it where it belongs.
[11:24] <pitti> infinity: no chance that the php4 core maintainers accept it?
[11:25] <infinity> pitti : The core guys are some of the aforementioned 12 year olds...
[11:25] <pitti> argh
[11:25] <infinity> pitti : You want a good laugh, check out recent CVS and see how they'r ebreaking the build system right now.
[11:25] <pitti> infinity: so half of the web application world depends and relies on a bunch of 12 years old who refuse to accept security patches?
[11:25] <infinity> pitti : Bundling (an old, broken) libtool, making it harder to relibtoolize yourself if you don't like it, etc...
[11:25] <elmo> pitti: are we sure this language pack stuff isn't going to break debootstrap?
[11:25] <elmo> pitti: and this means you have to do another en-mass upload doesn't it? :/
[11:25] <aj> what's the language pack stuff?
[11:26] <pitti> elmo: I won't do another base upload just for that
[11:26] <ogra> pitti: you weren't before ?
[11:26] <pitti> ogra: not that much...
[11:26] <ogra> heh
[11:26] <pitti> elmo: _can_ it break debootstrap?
[11:26] <pitti> elmo: i. e. is anything of it part of the base system?
[11:26] <infinity> pitti : The latest addition to the team of 12 year olds seems to be an "if it compiles on my system, it ships" guy.  Several others have been cleaning up portability issues behind him.
[11:26] <elmo> aj: http://www.ubuntulinux.org/wiki/LanguagePacks
[11:27] <pitti> elmo: I really don't know about the internal workings of debootstrap
[11:27] <aj> i think dpkg-deb does make dpkg safe anyway
[11:27] <infinity> pitti : And here I am, trying to do a CVS snapshot release that isn't broken (because 4.3.10 /is/ broken)... Yay.
[11:27] <pitti> elmo: but AFAICS debootstrap shouldn't install language packs, should it?
[11:27] <pitti> infinity: I don't envy you...
[11:28] <aj> it'd be odd to have a language pack in base/debootstrap afaics?
[11:28] <elmo> aj: yeah, but as you say, it hardcodes the name of the data.tar.gz for 'required' packages - my concern is at least one language will become required
[11:28] <infinity> pitti : It's okay.  I have enough self-pity this week, I probably don't need any from third parties. :)
[11:28] <elmo> well I find it more odd that we'd strip _all_ translations from all packages, but maybe that's just me
[11:28] <aj> it's easy to install a language pack after base (same time as grub)?
[11:29] <pitti> elmo: what's odd about stripping the whole main section?
[11:29] <aj> warty doesn't do language packs, right?
[11:29] <elmo> aj: right
[11:29] <pitti> aj: right, this is all Hoary stuff
[11:29] <aj> gar, dpkg-reconfigure looks like it makes xserver-xorg work now
[11:30] <pitti> elmo: if you don't have any pack, you will just get plain "C" translations, i. e. none
[11:30] <pitti> elmo: that should usually result in English-ish
[11:30] <pitti> elmo: but AFAIUI the installer apt-get's the langpack after installing the base system
[11:31] <pitti> Kamion: ^ that right?
[11:31] <infinity> "English-ish"... Heh.
[11:31] <infinity> "Programmerlish"?
[11:31] <pitti> infinity: well, British guys might find some odd "colors" and so on... :-)
[11:32] <aj> doh, how do i make dpkg-reconfigure regenerate /etc/X11/xorg.conf?
[11:33] <ogra> aj: read the md5sum hints in the head of the file ;)
[11:34] <aj> ogra: hrm, too late; i already read /var/lib/dpkg/info/xserver-xorg.config :-/
[11:34] <aj> yay, there we go
[11:35] <elmo> pitti: meh, ok, done
[11:35] <aj> arrg, it worked
[11:35] <pitti> elmo: thanks
[11:43] <daniels> aj: if you have 6.8.1-1ubuntu12, there's a boatload of debconf tweaks in there that should make lots of stuff work
[11:44] <dholbach> brb
[12:31] <aj> daniels: upgrading from warty/xserver-xfree86 to hoary/xserver-xorg gave me an xorg.conf that didn't have horizsync/vertref, and a log that said "no such mode 1024x768, ..." and reverted back to 800x600 and 640x480 defaults. adding the horizsync/vertref lines fixed it; but i can't duplicate the behaviour now that i've fixed it to give your proper logs/config :-/
[12:32] <daniels> aj: heh, ah well
[12:46] <abelli> fabbione: ding
[12:56] <elmo> doko: 
[12:56] <elmo> doko: ?
[12:56] <elmo> fabbione: ?
[12:57] <thom> fabbione is still ill, i think
[01:00] <elmo> ok
[01:08] <thom> Mithrandir: you need to reply to the last post on u-devel
[01:10] <dholbach> hi tseng
[01:10] <tseng> hiya, dholbach 
[01:21] <dholbach> i hope i'll win the lottery to have enough money to sue every lottery-lot-selling "$&)/"$"$& that calls me on the phone
[01:24] <smurfix> dholbach: The real problem is to weasel any kind of contact info out of them. They *know* it's illegal.
[01:25] <dholbach> smurfix: i resorted to telling them that i'm absolutely happy at the moment and don't need *anything* at all
[01:26] <dholbach> smurfix: they give in fast that way :-)
[01:54] <elmo> there's still no way to relocate X clients across hosts, right? [</madly wishful>] 
[01:54] <mjg59> elmo: gtk has support for it
[01:55] <Mithrandir> elmo: xmove, or nx.
[01:55] <mjg59> But there's no authentication code written yet (AFAIK), so it's not widely supported
[01:57] <rburton> there are gtk "issues" with it, and you need full acccess to both servers to make it work
[01:57] <elmo> rburton: issues with which?  mjg59's comment or mithrandir's?
[01:57] <elmo> 'cos xmove looks semi-perfect
[01:58] <rburton> xmove is a hack :)
[01:58] <rburton> gtk apps can seamlessly disconnect from one display and re-connect to another
[01:58] <elmo> okay, so xchat's a gtk app.. how do I move it from my laptop to my desktop? :)
[01:58] <rburton> but its a bit buggy, xlib doesn't like the old screen being disconnected
[01:59] <rburton> elmo: you hack xchat to add a "move to other display" button. it's all a mess atm :(
[01:59] <rburton> elmo: never fear, there is work to make it just happen if an atom is set on the window
[01:59] <elmo> duh
[02:00] <mjg59> xmove doesn't support most of the X extensions that clients are likely to use
[02:00] <elmo> unless it's something old school like GNU Emacs, I guess
[02:00] <elmo> hmm, I don't suppose my network connections would survive the switch of hosts, anyway, in xchat
[02:01] <thom> gnu emacs supports migration anyway aiui
[02:01] <rburton> yeah, emacs can create frames on other displays
[02:01] <elmo> kind of
[02:01] <thom> certainly it's an oft-quoted example
[02:01] <elmo> I mostly brought up emacs as an example of a client that probably doesn't use new X extensions, unlike xchat or a web browser
[02:02] <elmo> so, we know dircproxy isn't a good plan - are there any good IRC proxies?
[02:05] <thom> elmo: just run irssi in screen?
[02:05] <Mithrandir> elmo: ask what joeyh uses?  ISTR he uses an IRC proxy.
[02:06] <elmo> thom: I really prefer xchat to irssi
[02:06] <elmo> I suspect joey uses irssi or another text-base client too
[02:06] <Mithrandir> I think he uses xchat.
[02:07] <thom> elmo: http://www.garion.org/irssi/irssi-proxy.php
[02:07] <Mithrandir> 04:57 -!- joeyh [joey@kitenet.net]  has quit ["Terminated with extreme prejudice - dircproxy 1.0.5"] 
[02:07] <thom> use irssi as the proxy! ;-)
[02:07] <Mithrandir> seems like he uses dircproxy.
[02:07] <elmo> meh, if that as bad as keybuk says, he really should, like, warn people
[02:09] <Mithrandir> what's so bad about it?
[02:09] <elmo> thom: how cute - and disturbed.  do you use it?
[02:10] <elmo> Mithrandir: he's upstream for it and abandoned it long ago, he reckons it's full of potential security holes
[02:10] <Mithrandir> elmo: oh, ok
[02:11] <thom> elmo: no, i just run irssi in screen
[02:17] <elmo> hmm, irssi isn't too bad, except for the moronic package name, the fact that it's in universe and that it doesn't have the anti-pasto feature of xchat
[02:17] <Treenaks> elmo: it does have an anti-paste feature
[02:18] <Treenaks> elmo: it'll ask "You pasted X lines, do you really want this?"
[02:18] <aj> elmo: irssi rox0rs, you lame gui-fed n00b
[02:19] <elmo> giggle
[02:19] <Mithrandir> we should probably move it into supported, IMHO.
[02:19] <Mithrandir> it's the irc client if you don't do GUI IRC.
[02:20] <elmo> do we have a hoary+1ProposedPackages yet?
[02:20] <elmo> Treenaks: ok, cool.. even for one line?
[02:20] <Treenaks> elmo: configurable
[02:20] <Treenaks> elmo: so, yes
[02:20] <Treenaks> (/set paste_verify_line_count 1)
[02:29] <elmo> gar, having laptop/desktop keyboards with ~ and | reversed from each other is a receipe for (increased) insanity 
[02:29] <infinity> My laptop's ~/` key is between [space]  and [alt]  on the right side.
[02:29] <infinity> And the keycap is missing.
[02:30] <Treenaks> infinity: yuk!
[02:30] <infinity> I'm finally starting to get used to the missing keycap, after a year.
[02:30] <smurfix> elmo: so swap them
[02:30] <elmo> smurfix: yeah, I am, I'm trying to decide which I prefer
[02:31] <Mithrandir> elmo: which is why a Norwegian keyboard layout is nice, since you then just lose the |, while the tilde stays in the same place.
[02:31] <Treenaks> Mithrandir: losing the | is nice?
[02:31] <elmo> boggle, what treenaks said
[02:31] <daniels> elmo: 'swhat you get for having a US keyboard
[02:32] <Mithrandir> Treenaks: no, not losing ~ is nice.  Half the lossage.
[02:32] <daniels> s/Us/UK/
[02:32] <elmo> my laptop has | next to return, which is nice for shell pipe-fests, and ~ next to z which is less nice when I (infrequently) use it
[02:33] <Treenaks> I have 3 keyboards.. one with "\|" between ENTER and Backspace, one with "\|" right of the right shift(!), and one with it next to ENTER (but there, the ENTER button is wide at the top instead of at the bottom..)
[02:33] <infinity> I may be an old skool IBMer, but I'm firmly of the opinion that ~/` belongs next to 1, and | above [enter] 
[02:34] <infinity> Treenaks : I had one with it next to the right shift.  That was a Zenith server keyboard.  Nice keyboard, weird layout.
[02:34] <smurfix> The Enter key is a desaster in itself. Just how many ways to shape the thing so that you hit something else instead are there??
[02:35] <Treenaks> infinity: yeah, me too.. have that on my Logitech here as well
[02:35] <thom> infinity: above enter? you're not one of those people who like vertically challenged enter keys, are you? :P
[02:35] <Treenaks> smurfix: I have one "-"-shaped one (like shift), one which is wider at the top, and one which is wider at the bottom
[02:35] <smurfix> none of the "hit Fn instead" crap
[02:35] <Treenaks> smurfix: ugh. laptops
[02:36] <infinity> thom : Yeah, I prefer enter to be long, but short.
[02:36] <infinity> thom : Blame IBM.
[02:36] <infinity> thom : They broke me.
[02:36] <smurfix> Treenaks: No, it's an USB keyboard
[02:36] <infinity> thom : Compaq too.
[02:36] <Treenaks> smurfix: USB keyboard with an Fn key?
[02:37] <smurfix> Treenaks: Yeah, I don't understand what the KeySonic people smoked when they designed it either, the only key you actually *need* is for is numlock.
[02:37] <Treenaks> smurfix: numlock is crack anyway
[02:37] <elmo> thom: meh, this proxy stuff doesn't seem to work
[02:38] <Treenaks> smurfix: (the LED is nice to show alternate group.. but that's another story :))
[02:38] <thom> elmo: blame JD in #debian-uk
[02:38] <daniels> infinity: Is there anything else?
[02:38] <elmo> thom: his suggestion, or ?
[02:38] <daniels> Treenaks: alternate group?  wassat?
[02:38] <thom> elmo: he's maintainer
[02:38] <smurfix> even though I don't do alternate groups.
[02:38] <Treenaks> daniels: oh, I use numlock to switch between "US" and "US International" layouts :)
[02:39] <Treenaks> daniels: US is nicer when coding, US Intl is nicer when writing long pieces of Dutch text :)
[02:39] <smurfix> daniels: Other, more sane, people use it to switch between ASCII and Crillic. For instance.
[02:39] <smurfix> *g*
[02:39] <smurfix> Cyrillic
[02:39] <daniels> woah.
[02:39] <infinity> Sane people type in Cyrillic?
[02:40] <Mithrandir> thom: my response on -devel being scary enough?
[02:40] <smurfix> infinity: If they're Russians, most probably.
[02:40] <smurfix> OK, on the other hand, scratch that.
[02:40] <rubenv> welcome to the none ascii world :)
[02:41] <thom> Mithrandir: that's about what i was hoping for
[02:41] <rubenv> try typing on a kedmanee thai keyboard, you'll hug your english for the rest of your life ;)
[02:42] <Mithrandir> thom: it's certainly possible, I did it with vawad.  I broke something in the process, though; glibc doesn't compile right any more.
[02:45] <thom> Mithrandir: suer
[02:45] <thom> sure, even
[02:47] <daniels> Mithrandir: what'd I miss?
[02:47] <Mithrandir> daniels: ubuntu-devel.  Guy asking how to upgrade from i386 to amd64.
[02:47] <daniels> heh
[02:47] <ogra> hehe, just reading that one :)
[02:48] <Mithrandir> this was actually the first time I've switched both distribution and arch at the same time, not just one of them.
[03:05] <zul> hilo
[03:43] <toresbe> Does ubuntu have a packages.debian.org equivalent?
[03:46] <toresbe> nm
[03:56] <zul> ooh...can i join lamont ;)
[03:56] <Mithrandir> lamont_r: I think there was an X upload last night?
[03:56] <lamont_r> Mithrandir: _AND_ linux-source
[03:56] <zul> heh
[03:56] <Mithrandir> lamont_r: yeah, true.
[03:56] <Treenaks> lamont_r: and seb with another load of GNOME
[03:57] <lamont_r> mirror-missing| more
[03:57] <lamont_r> # ubuntu 226
[03:57] <Mithrandir> thom: you could do an OOo-amd64 upload as there was a minor bump on the normal OOo a few days ago.
[03:57] <Treenaks> thom: typo fix?
[03:57] <Mithrandir> that's the single biggest package we have, I think.
[03:57] <thom> i doubt lamont mirrors amd64 tho
[03:58] <lamont_r> Mithrandir: I don't mirror *amd64*
[03:58] <Mithrandir> sad :(
[03:58] <lamont_r> and linux-source is good for a ~220 MB hit
[03:58] <Treenaks> lamont_r: how about ia64?
[03:58] <Mithrandir> thom: we should get lamont an amd64.
[03:58] <lamont_r> yeah, i386 and ia64 and source
[03:58] <Mithrandir> or we could make an ooo-ia64.
[03:58] <lamont_r> Mithrandir: that'd be cool
[03:58] <thom> really we should make OOo2 build
[03:58] <lamont_r> Mithrandir: that'd be a seed change....
[03:59] <thom> heh. so pwgen on freebsd builds with "-DDEBIAN"
[03:59] <lamont_r> thom: heh
[04:00] <Mithrandir> lamont_r: is ooo on the seed page limited to amd64, ppc and i386?
[04:01] <lamont_r> yes
[04:01] <Mithrandir> ook
[04:01] <lamont_r> _and_ germinate/ubuntu-meta knows how to deal with arch-specific things now.
[04:01] <lamont_r> again, even
[04:03] <lamont_r> gonna have to find someone to get to know in the CS dept of the uni here.
[04:04] <Treenaks> lamont_r: the coffee shop downstairs from here has some fat pipes..
[04:04] <Treenaks> lamont_r: but I think it's not the kind of pipe you're looking for 8)
[04:04] <lamont_r> feh
[04:04] <Kamion> elmo: did you see my query about Task: ubuntu-desktop on ia64?
[04:04] <lamont_r> actually, I'm seriously contemplating paying for DSL for the fire dept, so that I can work from there...
[04:05] <lamont_r> (the remote terminal for the area is at the firestation... should make for good bandwidth... :-)
[04:05] <elmo> Kamion: nope ?
[04:06] <lamont_r> Kamion: me neither.. :)
[04:07] <Kamion> elmo: openoffice.org still seems to have Task: ubuntu-desktop in binary-ia64/Packages.gz, despite being [amd64 i386 powerpc sparc]  in seeds/hoary/desktop
[04:08] <lamont_r> Mithrandir: you really want one?
[04:09] <Mithrandir> lamont_r: yes.
[04:09] <elmo> Kamion: err, you know the task overrides are arch inspecific, right?
[04:09] <Kamion> elmo: erm. can they not be?
[04:09] <lamont_r> Mithrandir: I'll shake the bushes later today and see what falls out
[04:09] <elmo> Kamion: not really
[04:09] <Mithrandir> lamont_r: in a desktop/tower size, preferably, I don't have a rack yet.
[04:09] <Mithrandir> lamont_r: thanks a lot. :)
[04:09] <Kamion> that seems like a fairly major bug
[04:10] <lamont_r> Mithrandir: most of what they've had lately have been towers, I'd have preferred a rackable one, but...
[04:10] <elmo> well, either someone fixes apt, or I suppose I could run apt-ftparchive <n> times for <n> architectures
[04:10] <Kamion> it'll bite whenever libraries have different sonames between arches or something
[04:10] <Mithrandir> lamont_r: it's standard ATX or something, isn't it?  So it could be remounted in a rack case?
[04:10] <Kamion> well, only if both old and new sonames are available I guess
[04:11] <lamont_r> Mithrandir: really cute rounded corners - not so rackable
[04:11] <Kamion> mdz: do you have any idea what's needed for architecture-specific task overrides in apt-ftparchive?
[04:11] <Mithrandir> lamont_r: I thought about taking the mobo out of the box.
[04:12] <lamont_r> Mithrandir: there's some serious cooling engineering there, as well as an 800W power supply... it _WANTS_ to stay in the case it shipped in....
[04:12] <Mithrandir> lamont_r: ah, ok. :)
[04:13] <lamont_r> including some neato foam pieces inside the chassis with dire warnings about how they're needed for normal operation, and must not be removed...
[04:13] <Treenaks> lamont_r: sounds hackish
[04:14] <lamont_r> Treenaks: nah - it's called channelled air cooling - the alternative was going liquid...
[04:14] <Treenaks> lamont_r: or reduce CPU wattage
[04:14] <lamont_r> when it first came out, itanium was the hottest chip on the market.
[04:14] <lamont_r> kinda fast, too.
[04:16] <Mithrandir> isn't the itanium still the hottest chip on the market?
[04:16] <lamont_r> Mithrandir: could be
[04:28] <Kamion> xfree86-driver-fglrx should be moved from restricted to multiverse, shouldn't it?
[04:28] <Kamion> daniels apparently wants to keep on supporting it, but xserver-xfree86 is in universe
[04:29] <elmo> umm, speaking of firegl, rene thinks fglrx-driver, fglrx-driver-dev are NBS
[04:29] <elmo> daniels: ?
[04:30] <thom> Kamion: hrm, current hoary installer doesn't find the usb keyboard on this powermac
[04:30] <thom> NBS?
[04:30] <Kamion> +  * Kill off fglrx-driver altogether, and have x{org,free86}-driver-fglrx
[04:30] <Kamion> +    Conflicts/Replaces/Provides it; ditto fglrx-driver-dev (closes:
[04:30] <Kamion> +    Ubuntu#5630).
[04:30] <Kamion> thom: hm, suck
[04:31] <elmo> oh, ok, looking at the changelog would actually make sense tho
[04:31] <Kamion> thom: can you have a look at the PCI class id-handling stuff in usb-discover and see what's going on?
[04:31] <thom> Kamion: how? no keyboard
[04:31] <Kamion> thom: serial console?
[04:31] <Kamion> tweaked initrd?
[04:31] <thom> Kamion: this is a graphite g4
[04:31] <thom> guess it's tweaked initrd
[04:31] <thom> no serial port
[04:32] <Kamion> you could do the evil open firmware telnetd trick; can't remember if it works that far into the installer
[04:32] <thom> Kamion: got a reference for the telnetd trick?
[04:32] <pitti> abelli: ping
[04:33] <abelli> pitti: dong when you want
[04:33] <pitti> abelli: I just uploaded new hardened kernels 
[04:33] <pitti> abelli: using wireless drivers now works for me
[04:33] <pitti> abelli: (on powerpc at least)
[04:34] <ogra> pitti:  ./dmiwrapper /dev/mem: Permission denied
[04:34] <ogra> # dmidecode 2.5
[04:34] <thom> nm, found it
[04:34] <ogra> sudo chmod g+s ./dmiwrapper
[04:34] <pitti> abelli: now I test the i386/k7 images with framebuffer
[04:34] <ogra>  ./dmiwrapper /dev/mem: Operation not permitted
[04:34] <ogra> pitti: suid group seems not to work :(
[04:35] <pitti> ogra: sudo chown root:kmem dmiwrapper
[04:35] <ogra> i did :(
[04:35] <pitti> ogra: sgid root could not work
[04:35] <zul> pitti: whats new in the hardneded stuff?
[04:35] <ogra> i know
[04:35] <pitti> ogra: did you mount your /home with nosuid?
[04:35] <pitti> ogra: (I did :-) )
[04:35] <pitti> zul: I updated to our latest Ubuntu Hoary kernel, and also to the latest grsec
[04:36] <zul> cool
[04:36] <ogra> pitti: is this a default ?
[04:36] <pitti> zul: now the wireless drivers seem to work, too
[04:36] <pitti> ogra: not really
[04:36] <abelli> ogra: mm.. dont think so..
[04:36] <pitti> ogra: but paranoids like me always so nosuid,nodev :-)
[04:36] <Kamion> thom: IIRC you type this at OF:
[04:36] <ogra> pitti: i can run it with suid root, but not with suid group kmem
[04:36] <Kamion> " enet:some-ip-address" io
[04:36] <pitti> ogra: btb
[04:36] <pitti> ogra: brb, even
[04:36] <Kamion> thom: then telnet to some-ip-address
[04:37] <thom> Kamion: yeah, it drops out as soon as the cdrom boots though :(
[04:37] <Kamion> mdz: shouldn't casper-reconfigure, er, actually chroot?
[04:37] <Kamion> thom: hm, damn
[04:42] <pitti> abelli: darn, vesafb is still broken
[04:42] <thom> Kamion: want me to try last array cd and see if works there? that at least may give me a working machine (it's new and OS-less atm)
[04:42] <Kamion> thom: yeah, please
[04:42] <Kamion> thom: was this warty?
[04:42] <pitti> abelli: other stuff works fine
[04:42] <Kamion> oh, no, you said hoary
[04:43] <abelli> pitti: can i try breaking it?
[04:43] <abelli> :)
[04:43] <pitti> abelli: sure, go ahead and beat me up :-)
[04:44] <ogra> pitti: -rwxr-s--x  1 root kmem 20060 2005-01-31 16:31 dmiwrapper
[04:44] <ogra> ./dmiwrapper /dev/mem: Operation not permitted
[04:45] <Hwolf> guys: sorry to bother here, but I've just set up printing on my warty box as I did previously, same driver etc, and I'm getting very erratic printing. Half the time it works in OO.o, and I haven't been able to print from firefox.
[04:45] <ogra> no way....
[04:45] <pitti> ogra: hmm, odd
[04:45] <pitti> ogra: ah
[04:45] <ogra> pitti: only suid root works... :(
[04:45] <pitti> ogra: wait, I think I know what's missing
[04:46] <pitti> ogra: hmm, could be that you need CAP_SYS_ADMIN for that, too
[04:47] <pitti> ogra: however, this capability is essentially root
[04:47] <ogra> pitti: regard the error, without suid group i get "permission denied", not "Operation not permitted"
[04:47] <pitti> right
[04:47] <pitti> that means that you can open the device node
[04:47] <pitti> but not read from it
[04:48] <ogra> pitti: gah
[04:48] <pitti> ogra: I think that's exactly the same as /proc/klog
[04:48] <pitti> ogra: the kernel restricts access to these files to processes with CAP_SYS_ADMIN 
[04:48] <ogra> pitti: so i'm doomed to use suid root ?
[04:48] <pitti> ogra: I'm afraid so
[04:48] <ogra> arghl
[04:49] <pitti> ogra: hmm, you will write this in C?
[04:49] <pitti> s/will write/have written/
[04:49] <ogra> i already did....its just parsing the output fron dmidecode
[04:49] <pitti> ah, you call dmidecode?
[04:49] <ogra> yup
[04:49] <pitti> then your own code does not need any privileges
[04:50] <pitti> ogra: do it like this:
[04:50] <ogra> you mean i shold set dmidecode suid root ?
[04:50] <pitti> no
[04:50] <pitti> - your program is suid root
[04:50] <pitti> - immediately at start you fork()
[04:50] <ogra> ok...
[04:50] <pitti> - one process execv()'s dmidecode and opens a pipe to it
[04:51] <ogra> is popen ok too ?
[04:51] <pitti> - the other process drops all privileges: setgid(getgid()); setuid(getuid());
[04:51] <pitti> - other process reads dmidecode output
[04:51] <sivang> rehi all
[04:51] <pitti> ogra: lemme have a look
[04:52] <pitti> ogra: bah, no
[04:52] <pitti> ogra: popen() is like system(), it invokes the shell
[04:52] <ogra> oh, ok
[04:52] <pitti> ogra: please rather not use it
[04:52] <ogra> then execv
[04:52] <pitti> ogra: use dup2() to redirect stdout
[04:53] <pitti> ogra: try to close stdin and stderr (or redirect stderr, too, if you need to)
[04:54] <ogra> ok, let me try.... you will have to review that anyway for security reasons ;)
[04:54] <pitti> ogra: sure, I will :-)
[04:55] <pitti> ogra: no, even better
[04:55] <pitti> ogra: CAP_SYS_RAWIO is sufficient
[04:56] <pitti> ogra: so you can drop everything but this cap
[04:56] <pitti> ogra: but we can do this afterwards
[04:58] <pitti> seb128: yay, gvfs hal is back?
[05:00] <lamont_r> pitti: I thought popen only invoked a shell if there were shell meta characters in the command
[05:00] <pitti> DESCRIPTION
[05:00] <pitti>        The  popen()  function  opens a process by creating a pipe, forking, and invoking the shell.
[05:00] <seb128> pitti: yeah, the lock is fixed and was not due to hal
[05:00] <lamont_r> pitti: hrm.
[05:00] <seb128> pitti: and since hal rocks :)
[05:00] <pitti> lamont_r: ^ I did not check the code, just looked at the manpage
[05:00] <lamont_r> ok
[05:00] <lamont_r> ok
[05:01] <pitti> lamont_r: if it doesn't use the shell, then it's probably fine
[05:01] <_elmo> btw, is the udev SNAFUness known?
[05:01] <pitti> _elmo: using 100% CPU after hal upgrade?
[05:01] <_elmo> yeah
[05:02] <_elmo> well, I dunno actually, I just upgraded for the fist time in several weeks and when I came back the next day hal and udev were sitting there beating the machine to death
[05:02] <lamont_r> _elmo: you mean that's not just hoary/ia64?  cool
[05:02] <pitti> _elmo: I encountered this too. but the odd thing was that no single process used up the cpu
[05:02] <pitti> _elmo: all processes were quiet, but the cpu in general was 100%
[05:03] <_elmo> pitti: I had something different then, when I found it, it was creating devices in a loop, again and again
[05:03] <pitti> _elmo: /dev/ramXX ?
[05:03] <smurfix> pitti: Hmmm... I see that too, something seems to be forking off small stuff like crazy.
[05:03] <ogra> pitti: if i reboot in this state, i get a message about a hanging process in the shutdown messages...
[05:03] <_elmo> pitti: a whole bunch of different ones, scsi, loop I remember
[05:04] <pitti> but after reboot everything works fine?
[05:04] <ogra> yup
[05:04] <pitti> (it did for me)
[05:04] <ogra> pitti: btw.... was quite time consuming to test my hal patches yesterday ;)
[05:04] <pitti> ogra: ?
[05:04] <ogra> every test a reboot....
[05:04] <pitti> ogra: you can reproduce it reliably?
[05:05] <lamont_r> very bad to require a reboot...
[05:05] <pitti> ogra: I can't
[05:05] <lamont_r> pitti: does dpkg --reinstall do it?
[05:05] <pitti> I was able to reproduce it once, but never again
[05:05] <ogra> i can, everytime i install hal and dbus/hal restarts
[05:05] <pitti> lamont_r: I currently do "sudo dpkg -i hal_0.4.7-1ubuntu1_i386.deb" over and over again
[05:05] <seb128> is LIBTOOL_IS_A_FOOL still needed ?
[05:05] <ogra> pitti: i have this only on amd64... my ppc and i386 work fine
[05:06] <lamont_r> t-bone saw it on a fresh? install on ia64, iirc
[05:06] <pitti> ogra: so what is the culprit exactly?
[05:06] <Kamion> yeah, T-Bone can reproduce it every time on install I think
[05:06] <pitti> lamont_r: --reinstall does not work (or, rather, does), too
[05:07] <Kamion> 'bterm': unknown terminal type
[05:07] <smurfix> pitti: udevd and udev (three instances) seem to be unkillable in that situation
[05:07] <Kamion> any idea what program might be emitting that message
[05:07] <Kamion> ?
[05:07] <ogra> pitti: dunno, as i said, udev tries to create /dev/ramXX wildly and i get a message about a hanging process on reboot then... after reboot everything is fine
[05:08] <ogra> pitti: i'm at the office currently, i can make more tests this evening...
[05:08] <smurfix> the fact that it amnages to do that at all is somewhat remarkable, much less that it still forks off stuff :-/
[05:08] <lamont_r> Kamion: make /usr/lib/terminfo/b/bterm a symlink to /etc/terminfo/b/bterm, and make that a named pipe....
[05:08] <pitti> now I down- and upgraded over and over again, I cannot reproduce it
[05:09] <lamont_r> Kamion: of course, that turns it from a nasty warning into a hang, but... :-)
[05:09] <pitti> ogra: if you encounter this again, please try to stop hal before upgrading
[05:09] <pitti> ogra: sudo /etc/dbus-1/event.d/20hal stop
[05:09] <Kamion> lamont_r: :-P
[05:09] <ogra> pitti: i will...i'll report back tonight
[05:10] <pitti> ogra: might help; if it does, I change the init scripts for a quickfix
[05:10] <ogra> yup
[05:10] <lamont_r> Kamion: that's the longwinded way of saying 'NFC' :)
[05:11] <pitti> lamont_r: can you reproduce the hal hang?
[05:11] <smurfix> Why doesn't "kill" (the command, not the syscall) report an error if the PID 'm killing doesn't exist??
[05:11] <lamont_r> pitti: haven't seen it yet
[05:11] <pitti> hrm
[05:12] <pitti> I now down-, up- and sidegraded the complete set of hal debs several times...
[05:13] <ogra> pitti: is your system upgraded from warty or a new hoary install ? (mine was an upgrade)
[05:13] <pitti> ogra: I freshly installed about a week ago
[05:13] <ogra> smurfix: and you ?
[05:13] <pitti> ogra: however, my ppc is a warty upgrade
[05:13] <pitti> ogra: and it works fine, too
[05:13] <ogra> hm
[05:14] <smurfix> Mine was a warty upgrade. Last reboot a week ago.
[05:14] <pitti> Hi Keybuk! Nice to see you again!
[05:14] <pitti> Keybuk: there is a pretty nasty dpkg bug (#184635) that we need to sort out soon
[05:14] <ogra> pitti: as i said before, i cant confirm the bug on ppc
[05:14] <Kamion> ah, it's 'clear'
[05:14] <pitti> Keybuk: (asymmetric Replaces:)
[05:15] <pitti> smurfix: and you can't reproduce it either?
[05:15] <pitti> Keybuk: do you think this can be handled soon? it's critical for the langpack updates
[05:16] <smurfix> pitti: I haven't rebooted yet. It's still happening (as soon as I kill -CONT udevd).
[05:16] <pitti> smurfix: that'd be cool
[05:16] <pitti> smurfix: so as soon as udevd runs, it creates devices over and over again?
[05:16] <pitti> seb128: tried to reproduce the hal hang?
[05:17] <pitti> smurfix: $ sudo ps aux|grep udev
[05:17] <pitti> Password:
[05:17] <pitti> root     27062  0.0  0.0   2808   648 ?        S<s  16:39   0:00 udevd
[05:17] <pitti> smurfix: sleeps like a baby...
[05:17] <smurfix> pitti: It forks off udev over and over again, whcih then proceeds to call various interesting scripts
[05:18] <pitti> smurfix: so udevd forks off udev?
[05:18] <pitti> hmm, I guess the hal upgrade is just the trigger for this bug
[05:18] <ogra> looks like
[05:19] <smurfix> pitti: send me a ssh key and I'll let you onto my system, that'd be easiest
[05:20] <smurfix> What's a reasonable pasetebin? pastebin.ca is *slow*
[05:20] <pitti> smurfix: http://www.piware.de/mpitt-ssh.pub
[05:20] <seb128> pitti: no, get a disk access issue, had to reboot ...
[05:21] <ogra> smurfix: #flood ?
[05:21] <seb128> pitti: I'm pretty confident that the patch for the lock is correct
[05:21] <smurfix> ogra: xchat doesn't do multi-line paste well
[05:22] <seb128> Keybuk: is LIBTOOL_IS_A_FOOL still needed ?
[05:22] <Keybuk> shouldn't be
[05:22] <Keybuk> libtool 1.5 hasn't linked library deps in a while
[05:22] <ogra> smurfix: ah, true 
[05:22] <Keybuk> (at least the Debian libtool)
[05:23] <seb128> k
[05:23] <seb128> thanks
[05:24] <smurfix> pitti: @kiste.smurf.noris.de. The interesting part (repeating strace output) is in /tmp/logsnippet.
[05:28] <pitti> smurfix: read(3, 0xbffffc54, 4)                  = -1 EAGAIN (Resource temporarily unavailable)
[05:28] <pitti> smurfix: ^^ that's because there are already too many children?
[05:28] <pitti> smurfix: are there already lots of udev childs?
[05:29] <smurfix> No, that's because fd3 is nonblocking and doesn't have data
[05:29] <pitti> hmm, now we need to know what fd's 3 and 4 are...
[05:30] <smurfix> pitti: it's a pipe
[05:30] <smurfix> pitti: ls -l /proc/31924/fd
[05:30] <pitti> smurfix: no permission :-)
[05:30] <smurfix> one that udevd uses to send data to itself
[05:30] <pitti> but I believe you :-)
[05:30] <smurfix> pitti: use sudo
[05:30] <sivang> pitti: back on the pkg
[05:35] <pitti> smurfix: hm, your cpu is at 40%, but most processes are quiet...
[05:35] <pitti> smurfix: is that still udev?
[05:35] <pitti> smurfix: or did you stop it again?
[05:36] <smurfix> pitti: check out "pstree -p | grep udev"
[05:36] <pitti> smurfix: hmm, already did that. okay
[05:36] <smurfix> pitti: it's forking off a new process every time through that loop
[05:37] <smurfix> pitti: to it twice and look at the pids
[05:37] <smurfix> that's a *lot* of processes, but they don't live long enough to register with top
[05:38] <pitti> smurfix: hmm, gdb'ing the parent process does not yield anything useful
[05:38] <pitti> smurfix: I think we need a debug-enabled udev for this
[05:38] <pitti> smurfix: may I ...?
[05:39] <smurfix> pitti: may you do what? Kill udevd? Not possible.
[05:39] <pitti> smurfix: rebuild udev with debugging and install it
[05:39] <pitti> smurfix: then you need to reboot and reproduce the situation again
[05:39] <smurfix> pitti: ... assuming I manage to do that. *Somehow*. Given that it's my work system.
[05:40] <pitti> smurfix: hmm, as you like. I don't want to disturb you
[05:40] <smurfix> pitti: Give me a debug package anyway
[05:41] <smurfix> pitti: My laptop hasn't been updated yet
[05:41] <smurfix> pitti: Maybe installing a debug udevd first, then rebooting, then updating will exhibit the problem
[05:42] <smurfix> pitti: No argument here, but we need to try anyway
[05:42] <smurfix> Anyway, how does udevd manage to block SIGKILL?
[05:43] <Keybuk> whoah, when did we hit #1 on DW?
[05:43] <smurfix> Keybuk: What's DW?
[05:43] <thom> distrowatch
[05:43] <smurfix> ah
[05:43] <pitti> smurfix: so far the only unkillable process that I encountered was a hald in kernel sleep (state 'D')
[05:43] <pitti> smurfix: but that isn't the case...
[05:44] <smurfix> pitti: Oh, I've seen plenty of USB jobs in "R", looping *somewhere*
[05:44] <smurfix> pitti: but never in user space like udevd is doing :-/
[05:44] <pitti> smurfix: debug version ready
[05:44] <pitti> smurfix: in ~pitti/udev_0.050-3ubuntu3.1_i386.deb
[05:45] <smurfix> pitti: OK
[05:45] <lamont_r> pitti: not -3ubuntu3debug1?
[05:45] <ogra> hehe
[05:46] <pitti> smurfix: hmm, I can perfectly kill every single udev/udevd...
[05:47] <pitti> smurfix: but I don't want to mess further with your system
[05:47] <smurfix> pitti: You can't kill the one with pid 31924
[05:47] <smurfix> ah, sorry
[05:47] <smurfix> my fault
[05:48] <lamont_r> pitti: while killall udev udevd ; do true; done doesn't count. :-P
[05:48] <smurfix> damn kill(1) which doesn't report that the process died
[05:48] <pitti> I did not yet try "killall -9 udevd" :-)
[05:48] <lamont_r> smurfix: you mean waits for it to die?  or bitches that it's already dead?
[05:49] <lamont_r> hrm.. already bitches
[05:49] <smurfix> lamont: The latter doesn't happen, which is a major no-no. "kill $RANDOM_PID" must complain if there is no such process.
[05:50] <bradb> Kamion: hey dude. What was the use case again that we discussed in Mataro for filing bugs on source packages? ISTR it was when one doesn't know the binary package.
[05:51] <lamont_r> bradb: or when the source fails to build
[05:51] <lamont_r> smurfix: kill 59000
[05:51] <lamont_r> bash: kill: (59000) - No such process
[05:52] <lamont_r> with current procps
[05:52] <smurfix> lamont: Try /bin/kill
[05:52] <smurfix> lamont: you're using the shell builtin
[05:52] <lamont_r> smurfix: yeah - that's bad
[05:52] <bradb> lamont_r: how would you (want to) specify "file against the binary package foo" vs. "file against the source package foo"?
[05:53] <abelli> pitti: ding
[05:53] <pitti> dong
[05:53] <abelli> pitti: acpi now doesnt work
[05:54] <pitti> that's a lie, it works for me :-)
[05:54] <pitti> no, really
[05:54] <lamont_r> bradb: good question - today, we don't. :-(
[05:54] <pitti> abelli: what exactly? booting?
[05:54] <pitti> abelli: or power management?
[05:54] <smurfix> pitti: The problem persists
[05:54] <abelli> pitti: no.. its just 
[05:54] <abelli> pitti: no.. its just fatal error: Could open /proc/acpi/toshiba/keys.
[05:54] <abelli> Please make sure that your kernel has enabled the Toshiba option in the ACPI section.
[05:54] <lamont_r> bradb: I'm not sure that I really need to be able to distinguish necessarily - it'd be nice.
[05:54] <smurfix> pitti: You may attack udevd with gdb mow
[05:55] <abelli> its just the toshiba extension
[05:55] <smurfix> now, even
[05:55] <pitti> abelli: do you try this as non-root?
[05:55] <lamont_r> bradb: but there are packages who's source name is diff from all the binary package names....  I should still be able to file against the source package there.
[05:55] <abelli> it just dont works..
[05:55] <abelli> doesnt work and say you need to run it as root
[05:55] <smurfix> pitti: I don't think udevd is the culprit, though
[05:55] <pitti> abelli: the hardened kernel restricts the access to /proc
[05:55] <pitti> smurfix: I still think it's a kernel bug
[05:55] <abelli> pitti: it worked
[05:56] <lamont_r> bradb: that is, I don't care about the namespace collision from the union - I just want to have the ability to file against the source package.
[05:56] <lamont_r> likewise, the maintainer needs to be able to query for bugs against all of the binaries (and source) that build from "this" source
[05:57] <Kamion> bradb: I think lamont's superseded anything I might say :)
[05:57] <abelli> pitti: another thing is that it hangs as i try to umount an external hdd
[05:58] <pitti> abelli: <abelli> pitti: it worked  <- does that mean it works now?
[05:58] <abelli> no, it used to work
[05:58] <abelli> :)
[05:59] <lamont_r> Kamion: sorry to take the words from your mouth, and all that
[05:59] <pitti> smurfix: I have a nice backtrace now
[06:00] <Kamion> lamont_r: no worries :-)
[06:00] <bradb> lamont_r, Kamion: ok cool, thanks for the insight
[06:01] <abelli> pitti: btw, ipw2100 seems to be unusable as well
[06:01] <pitti> abelli: bah. is the module loaded?
[06:02] <abelli> yes
[06:02] <pitti> abelli: with the old kernel module loading did not work for me, now it does
[06:02] <pitti> hrm
[06:05] <pitti> smurfix: can you try to reproduce the madness?
[06:06] <Hwolf> Guys; If I set up a printer, and it works from OOO, but not from FF, is that a bug? 
[06:06] <pitti> smurfix: I restarted udev in debugging mode, but right now it behaves 
[06:08] <smurfix> pitti: I'll have to boot the box (damn USB printer driver).
[06:08] <pitti> smurfix: please wait a bit
[06:08] <pitti> smurfix: I forgot to set the DEBUG compiler flag
[06:08] <smurfix> pitti: *grumble*
[06:08] <lamont_r> hrm.. time to go move the car... bbiam
[06:09] <lamont_r> fabbione: here?
[06:10] <ogra> lamont_r: you want fabbione to move your car ?
[06:11] <dholbach> Kamion: about LIBTOOL_IS_A_FOOL again: i have a library whose auto-foo provides Makefiles with -rpath -arguments to the linker included, which makes lintian whine about binary-or-shlib-defines-rpath - what do you reckon, i should do?
[06:11] <mdz> morning
[06:11] <ogra> morning
[06:11] <mdz> Kamion: no, casper-reconfigure is used after pivot_root
[06:11] <pitti> Hi mdz!
[06:11] <smurfix> mdz: evening ;-)
[06:11] <mdz> Kamion: arch-specific task overrides, no
[06:11] <lamont_r> ogra: heh
[06:12] <lamont_r> brb
[06:13] <lupus_> fabbione, ping
[06:13] <smurfix> pitti: done?
[06:13] <pitti> not yet
[06:13] <pitti> please gimme a minute for final testing
[06:14] <smurfix> pitti: my daughter wants her pictures printed ;-)
[06:14] <pitti> smurfix: okay, ready
[06:14] <pitti> smurfix: I need to restart udevd anyway
[06:14] <pitti> smurfix: to start it in the foreground
[06:15] <pitti> but I'd like to do that before you reinstall hal to trigger the bug
[06:15] <pitti> smurfix:  then I can watch the output messages
[06:15] <smurfix> pitti: OK, I've reinstalled udev.deb. Rebooting now. brb
[06:15] <abelli> pitti: i cant find any kind of error apart those in query
[06:18] <[m0rph] > hi
[06:18] <[m0rph] > some new gnome packages in hoary don't use my locale
[06:18] <Kamion> mdz: casper-reconfigure> oh, I see
[06:18] <Kamion> dholbach: I think you mean Keybuk
[06:19] <Kamion> mdz: tasks> hmm, is it liable to be really hard or a moment's work?
[06:19] <Kamion> hm, ok, I basically asked that already, sorry
[06:19] <Keybuk> dholbach: make the Makefiles not include the -rpath arguments
[06:20] <mdz> Kamion: I recall that the last time I worked with that code, the API needed to be reworked to support more interesting stuff
[06:20] <mdz> it had some annoying limitations which made life difficult if you wanted to have more than one type of matching
[06:20] <Kamion> elmo_: is calling apt-ftparchive once per architecture totally not an option?
[06:20] <mdz> there's a work in progress to add wildcard matching support
[06:20] <dholbach> Kamion: oh yes... sorry
[06:21] <dholbach> keybuk: about LIBTOOL_IS_A_FOOL again: i have a library whose auto-foo provides Makefiles with -rpath -arguments to the linker included, which makes lintian whine about binary-or-shlib-defines-rpath - what do you reckon, i should do?
[06:21] <elmo_> Kamion: no, it's an option I guess
[06:21] <Keybuk> dholbach: make the Makefiles not include the -rpath arguments
[06:22] <dholbach> Keybuk: i guess it's because examples are compiled with those libraries which are not-installed yet
[06:22] <Kamion> mdz: debconf passthrough frontend fix just uploaded which may affect you; not sure
[06:23] <Keybuk> right, when you install, libtool will relink the libraries without the rpath
[06:23] <mdz> Kamion: debian or ubuntu?
[06:23] <Kamion> mdz: checked into debconf upstream, uploaded to Ubuntu
[06:23] <dholbach> Keybuk: ok... thank you - i'll try to investigate
[06:26] <pitti> smurfix: I'm now watching the log
[06:26] <pitti> smurfix: can you try to reproduce the situation?
[06:27] <smurfix> The question is how
[06:27] <ogra> smurfix: reinstall hal
[06:27] <smurfix> ogra: OK
[06:31] <smurfix> pitti: you see the problem? :-/
[06:31] <mdz> Kamion: what is an invisible question?
[06:31] <pitti> smurfix: not at all, the syslog is quiet
[06:32] <pitti> smurfix: bah, it does not log anything ! 
[06:32] <smurfix> Well, it definitely occurs. :-/  Just look at pstree. Or the load.
[06:32] <ogra> pitti: daemon.log/kern.log ?
[06:32] <mdz> pitti,smurfix: are you looking at the udev madness?
[06:32] <smurfix> ogra: you wish
[06:32] <ogra> pitti: i definately sa output, cant remember which log though
[06:32] <pitti> ogra, smurfix: all other logs are in syslog
[06:33] <pitti> ogra, smurfix: and in daemon.log as well
[06:33] <pitti> mdz: yes
[06:33] <smurfix> mdz: pitti is
[06:33] <mdz> I have some logs
[06:33] <pitti> mdz: we already do for nearly an hour
[06:33] <smurfix> mdz: it seems to be perfectly reproducible on my system
[06:33] <pitti> mdz: I installed a debugging version on smurfix' machine
[06:33] <pitti> mdz: and gdb'ed it there
[06:33] <mdz> I had to disable the hotplug helper and reinstate it in order to get the system to calm down
[06:33] <pitti> mdz: but from the first sight it doesn't seem to do anything unusual
[06:34] <smurfix> mdz: not a good long-term solution
[06:34] <pitti> mdz: maybe it gets flooded with hotplug events
[06:34] <mdz> I'll send you my syslog, in case it helps
[06:34] <pitti> thanks, yes
[06:39] <pitti> smurfix: hrm, now /dev/log is missing and udev won't start again. grumpf
[06:39] <pitti> smurfix: I just installed new binaries...
[06:39] <Kamion> mdz: one that is not shown due to e.g. priority being too low
[06:40] <pitti> smurfix: init.d/udev stop/start doesn't help either
[06:40] <mdz> Kamion: ah
[06:40] <smurfix> pitti: restarted syslogd
[06:40] <smurfix> pitti: so it's back now
[06:40] <Kamion> mdz: basically you can end up with boolean questions not having a "true"/"false" value as a result; there's an X bug which I'm wondering if it might be related to this
[06:40] <mdz> Kamion: if I understand correctly, I'm surprised that didn't break anything
[06:41] <mdz> (noticeable)
[06:41] <pitti> smurfix: odd, it still exits
[06:41] <pitti> smurfix: this time for another reason (but the strace doesn't reveal it...)
[06:41] <pitti> smurfix: possible to reboot?
[06:42] <smurfix> pitti: why?
[06:42] <pitti> smurfix: well, if you can manage to run udev again?
[06:42] <pitti> hmm, I can start it manually
[06:42] <smurfix> pitti: it even logs what's broken
[06:42] <pitti> okay, let's try the hal update again
[06:42] <smurfix> Jan 31 18:42:34 udevd[10502] : main: bind failed, exit
[06:43] <Kamion> mdz: I think it only causes values in config.dat to be out of spec after a particular instance of the passthrough frontend exits, so unless you were reconfiguring something twice you might not notice
[06:43] <pitti> smurfix: that was my erroneous attempt to start it as user :-)
[06:43] <mdz> ah, ok
[06:43] <Kamion> unless you were paying close attention to errors in syslog
[06:43] <pitti> smurfix: now it _should_ run again
[06:43] <mdz> Kamion: syslog is dead by the time casper does its reconfiguring :-)
[06:43] <smurfix> pitti: running sudo dpkg -i /var/cache/apt/archives/hal_0.4.7-1ubuntu1_i386.deb
[06:43] <Kamion> heh
[06:43] <pitti> smurfix: ah
[06:44] <Kamion> "errors? what are those? LA LA LA LA"
[06:44] <pitti> smurfix: try sudo tail -f /var/log/syslog
[06:44] <mdz> Kamion: speaking of syslog
[06:44] <pitti> smurfix: now you get a nice flood
[06:44] <smurfix> pitti: ouch
[06:44] <mdz> Kamion: I think I'd like to save the d-i logs in casper
[06:44] <pitti> smurfix: I rather stop the process before the log fills up your disk
[06:44] <mdz> Kamion: which bit does that?
[06:45] <Kamion> mdz: prebaseconfig.d/93save-install-log
[06:45] <smurfix> pitti: it already did
[06:45] <pitti> smurfix: Jan 31 18:44:32 kiste syslogd: /var/log/daemon.log: No space left on device
[06:45] <pitti> smurfix: sorry...
[06:45] <Kamion> I've been meaning to do s/debian-installer/installer/ on that
[06:45] <pitti> smurfix: 27 MB
[06:45] <mdz> Kamion: I'd also been wanting to have it gzip them; mind if I make those changes?
[06:46] <pitti> smurfix: hmm, I was thrown out
[06:46] <mdz> the gzipping is especially significant under casper
[06:46] <pitti> smurfix: can you please safe (part of) the log somewhere?
[06:46] <smurfix> pitti: the fact that everything's logged three times doesn't exactly help
[06:46] <smurfix> pitti: /var/log/syslog's still there
[06:46] <pitti> smurfix: actually I wanted to check which events are coming to udev
[06:46] <Kamion> mdz: that's fine for /var/log/*, but please don't gzip the cdebconf stuff; doing that will break base-config
[06:46] <mdz> hmm
[06:46] <mdz> maybe I should just give casper a separate script, then
[06:46] <pitti> smurfix: I just can't ssh any more (I was just thrown out)
[06:47] <Kamion> mdz: that might make better sense
[06:47] <Kamion> I could have sworn there was an upstream bug about compressing logs
[06:47] <pitti> smurfix: another idea, just for testing:
[06:47] <Kamion> mdz: You didn't want prebaseconfig in casper anyway, IIRC ...
[06:47] <pitti> smurfix: right before reinstalling hal, could you do "sudo /etc/dbus-1/event.d/20hal stop"?
[06:47] <mdz> true
[06:48] <mdz> Kamion: is the db_x_save still necessary if I skip the debconf/priority hack?
[06:48] <Kamion> mdz: yes
[06:48] <smurfix> pitti: /dev/pts got unmounted
[06:49] <Kamion> mdz: at least I think so. cdebconf only saves the database between menu entries, by default.
[06:49] <smurfix> pitti: you can now get back
[06:49] <mdz> I don't think that's in debconf's confmodule
[06:49] <Kamion> no
[06:49] <smurfix> pitti: do it yourself ;-)
[06:49] <pitti> okay
[06:49] <Kamion> you could echo it and read the result ...
[06:49] <mdz> or add the functionality to debconf...
[06:50] <Kamion> I'd prefer not, it's a very cdebconf-specific extension that relies on knowledge of how d-i works
[06:50] <mdz> echoing it seems like major XXX material
[06:50] <mdz> and I've been trying to reduce the XXX count in casper, not increase it :-/
[06:51] <Kamion> I don't think echoing it is a big deal; the debconf protocol is plain-text and well-documented for a reason
[06:51] <mdz> I'm down to 3 :-)
[06:51] <mdz> ok
[06:51] <mdz> to fd 1 or fd 3?
[06:51] <Kamion> it's not very nice, but it's tolerable
[06:51] <Kamion> fd 1
[06:51] <Kamion> er, assuming that was your debconf communication fd, which it is by default
[06:52] <mdz> echo "X_SAVE"
[06:52] <mdz> read resultcode resulttext
[06:52] <mdz> something like that?
[06:52] <Kamion> yeah
[06:52] <Kamion> if it goes into debconf, one could probably argue that it shouldn't be X_ any more :-)
[06:52] <Kamion> post-sarge we all need to sit down and go over the debconf/cdebconf extensions and get the sane ones into the standard
[06:53] <Kamion> mdz: is there nowhere that you could use the cdebconf confmodule to do it?
[06:55] <mdz> Kamion: . /initrd/usr/share/debconf/confmodule
[06:56] <Hwolf> Is anyone here knowledgable about Postscript / Cups?
[06:57] <pitti> Hwolf: what's up?
[06:57] <mdz> hmm, ick
[06:58] <mdz> multiple dpkg-reconfigures means multiple db saves
[06:58] <mdz> I guess I should revert that split
[06:58] <pitti> smurfix: hmm, I restored your original udev for now and purged the logs
[06:58] <Hwolf> pitti: I've got a fresh warty install here, set up my printer, same box, same drivers. Works fine from OO.org, but printing from firefox/thunderbird/postscript viewer results in anything but prints. Cups going down or errors, or nothing at all, mostly.
[06:58] <mdz> though, hopefully that's only config.dat
[06:58] <smurfix> Hwolf: That kind of question is best asked in #ubuntu
[06:58] <mdz> if it's saving templates.dat, that's costing a lot of memory
[06:58] <Kamion> it should only save if there's a change
[06:58] <Hwolf> smurfix: I've tried for half a day, and on the forums too. :-S
[06:58] <pitti> Hwolf: please file a bug and append /var/log/cups/error.log
[06:59] <Kamion> should> "I think that's the current behaviour" rather than "it ought to be this way", IYSWIM
[06:59] <pitti> Hwolf: or send the cups log and a description to ubuntu-devel@lists.ubuntu.com
[06:59] <Hwolf> smurfix: Just trying to narrow down if it is my config this time, since I've had warty working with this printer / box before
[06:59] <mdz> Kamion: how awful is my fontconfig hack in your opinion?
[06:59] <mdz> there will be other cases like that, and we ought to have a standard way of doing it
[06:59] <pitti> smurfix: but /etc/init.d/udev restart won't start udevd, though
[07:00] <pitti> smurfix: I used a foreground instance, but to really repair it you need to reboot (or find out what's wrong)
[07:00] <mdz> I should skip the defoma part, too
[07:00] <mdz> maybe it should be a debconf template in fontconfig?
[07:01] <mdz> which I could preseed?
[07:02] <Kamion> why is it regenerating in the first place, rather than checking if it's up to date and if so exiting?
[07:03] <Kamion> came from #173949 apparently
[07:03] <mdz> dunno
[07:03] <mdz> even if it did, it would probably be quite slow
[07:03] <mdz> presumably it needs non-trivial information from the fonts
[07:03] <smurfix> pitti: it didn't restart from init.d because the udev database was still there. That's non-fatal though, udevsend will start udevd on its own when necessary. Anyway hotplugging still works.
[07:03] <Kamion> I guess if the cache format can change between versions of fontconfig, it needs to regenerate, or something
[07:03] <pitti> smurfix: okay, fine
[07:04] <smurfix> pitti: you done on my box?
[07:04] <Kamion> mdz: mm, so what are we doing at the moment for stuff that needs that information?
[07:04] <pitti> smurfix: I copied the log to my servr
[07:04] <pitti> smurfix: right now I don't know what to do further
[07:04] <mdz> Kamion: in this case, we know that the cache is in fact up-to-date, and we only want to effect the changes to the config file
[07:04] <Kamion> oh, the livefs build process updates the cache?
[07:05] <mdz> yes, as part of the process of installing fontconfig
[07:05] <mdz> the only reason we reconfigure it is to enable subpixel rendering on laptops
[07:06] <Kamion> mdz: how about making fontconfig.postinst not regenerate the cache if DEBCONF_RECONFIGURE=1?
[07:06] <mdz> Kamion: I thought it was naughty to pay attention to DEBCONF_RECONFIGURE
[07:06] <Kamion> would that break other things? I assume *some* config file changes can require the cache to be rebuilt
[07:06] <mdz> my understanding is that the cache only corresponds to the fonts on the system
[07:06] <mdz> and not the config file
[07:06] <Kamion> well, it is a bit, but no worse than adding any other environment variable to the postinst API I think
[07:07] <mdz> hm, the man page claims that it checks timestamps and does incremental updates
[07:07] <Kamion> I think it's better than FONTCONFIG_NO_CACHE_REGEN, assuming that nobody ever needs the cache rebuilt automatically on reconfigure
[07:07] <mdz> I wonder why it's so horrifically slow
[07:08] <Kamion> not when called with -f it doesn't
[07:08] <mdz> I can't say that with authority, but it's the impression I got from jdub
[07:08] <mdz> oh, so it is
[07:08] <Kamion>        -f           --force
[07:08] <Kamion>                  Force  re-generation  of  apparently up-to-date cache
[07:08] <Kamion>                  files, overriding the timestamp checking.
[07:08] <Kamion> how about only using -f if [ "$DEBCONF_RECONFIGURE" != 1 ] ?
[07:09] <Kamion> if you're reconfiguring, you want the cache to be rebuilt if it's totally fucked (e.g. missing), but not otherwise, I'd've thought
[07:09] <pitti> mdz: hm, you have the same logs as I got on smurfix' machine
[07:09] <Kamion> and if you really need that you can still run fc-cache -f by hand
[07:10] <mdz> yes, I think the postinst ought to only do what should be necessary for configuring the package
[07:10] <mdz> haven't looke dat that bug you mentioned
[07:10] <mdz> need to run to my appointment, back in a while
[07:10] <Kamion> mdz: it basically just says "please import this stuff from RH"
[07:10] <elmo_> hmm, if C-5 is ^[, what's a good way of getting a list of other keys?
[07:10] <mdz> if you see jdub or someone else who seems to know about fontconfig, maybe we can get an authoritative answer
[07:20] <smurfix> mdz, Kamion: any feedback on today's mail from me?
[07:24] <Kamion> smurfix: I'll try to get to it tomorrow for you
[07:27] <smurfix> Kamion: That'd be helpful.
[07:28] <Kamion> sorry, deep in my own features today :(
[07:32] <smurfix> Kamion: I noticed.
[07:41] <Kamion> smurfix: hm, what exactly were the "unknown localized field" errors you got?
[07:41] <Kamion> because I don't think you should be getting those
[08:04] <smurfix> Kamion: might have been caused by the fact that the cdebconf.conf in src/ isn't exactly useable for anything
[08:04] <smurfix> Kamion: .. which is why my patch creates a new one in src/test/
[08:07] <Kamion> smurfix: uh ... I'd rather not have one of those in the source package
[08:07] <Kamion> smurfix: doc/testing.txt explicitly documents that you have to tune it depending on what you're testing, and I often munge src/test/cdebconf.conf a lot
[08:08] <Kamion> dunno
[08:09] <Kamion> it's usable at the moment if you're making cdebconf talk to your real debconf database, which is an ultimate goal for cdebconf to be able to do reliably
[08:10] <smurfix> Kamion: Hmm, I'd rather have the one in src/test not touch anythoing outside that directory by default
[08:11] <smurfix> Kamion: and run out of the box otherwise so that you have a working baseline without havign to understand cdebconf's deep magic any more than you need to *anyway*. ;-)
[08:11] <smurfix> Kamion: those "unknown localized field" errors might be a case in point. Haven't reproduced them yet. :-/
[08:16] <Kamion> smurfix: that's true of src/test/ certainly. dunno, it's just a matter of how much stuff I have to be careful not to accidentally commit when I'm testing in an svn working copy
[08:18] <smurfix> Kamion: so test the have-to-be-careful-about stuff somewhere else. ;-)
[08:19] <Kamion> no, I'd rather not make my working habits deliberately inconvenient for myself :)
[08:20] <Kamion> I'll think about it, maybe there's some reasonable compromise
[08:29] <rubenv> just managed to fuck & delete my calendar >:[
[08:30] <rubenv> (note:  it managed to do that, i am just innocent user :-( )
[08:31] <rcaskey_> my nightly rsync saves my butt weekly
[08:31] <rubenv> my last backup was a month ago
[08:31] <rubenv> when I was still near university
[08:31] <rubenv> gah i'm mad
[08:50] <doko> elmo: pong
[09:02] <elmo> doko: doesn't matter
[09:11] <elmo> sweet
[09:11] <Kamion> should keep Mark happy ;)
[09:12] <elmo> Mark'll be happy when you make the code telepathic so it just pulls the answer directly from your mind :p
[09:12] <Treenaks> elmo: the DWIM interface!
[09:12] <Kamion> reassign xxxxxx python-telepathy
[09:38] <kent> have some one had problems with Ubuntu (hoary 2.6.10) and usb devices?  this weekend when i tried to get a webcam nx to work (playing with a driver from CVS..) my computer crashed twice. I dont blame ubuntu since i guessed it was the cvs driver. But now when i connected a olympuc c-310 digital camera via usb it mounted automaticly as a usb-drive (but i dont see it in Computer though), but if i take out the usb-plug, then the computer c
[09:38] <kent> rashed.
[09:39] <kent> Im not sure though if i am to blame my computer or the kernel. (it has problem with heat. If i leave it on to long and use it to much, it can crash.) But using the usb seems like it should not trigger a heat-effect :)
[09:59] <lamont_r> Kamion: no ppc livecd today?
[10:21] <mirak> why are you doing xord updates without updating the drivers ATI ?
[10:23] <Kamion> lamont_r: http://adare.buildd/%7Ebuildd/livecd/livecd-current.cloop:
[10:23] <Kamion> 08:04:36 ERROR 404: Not Found.
[10:23] <fabbione> hey guys
[10:24] <fabbione> Kamion: did -13 work?
[10:24] <Kamion> mirak: it got updated recently ... try xorg-driver-fglrx?
[10:24] <Kamion> fabbione: haven't tried yet, will probably try tomorrow
[10:24] <Kamion> thanks for the upload
[10:24] <fabbione> Kamion: cool! it has only the ia32 fix...
[10:24] <Kamion> ok, hope it's the right one :)
[10:25] <fabbione> no problem.. i wasn't really sure how long i was going to take to recover
[10:25] <lamont_r> Kamion: hrmpf.
[10:25] <fabbione> so when i saw it, i just did upload
[10:25] <fabbione> Kamion:
[10:25] <fabbione> #   [PATCH]  x86_64: fix crash on get_user_pages of ia32 vsyscall page before it's faulted in
[10:25] <fabbione> #   
[10:25] <fabbione> #   God invented symbolic names to help you.  Repeating magic constants by hand
[10:25] <fabbione> #   is begging to lose, especially when you get them wrong.  Don't be a loser.
[10:25] <fabbione> #   
[10:25] <fabbione> #   [ Editor's hint: 0xfffe000 vs 0xffffe000 ] 
[10:25] <fabbione> that was in the upstream changelog
[10:25] <fabbione> :P
[10:25] <lamont_r> fabbione: lol
[10:26] <mirak> Kamion: it doesn't appear in my list, vut maybe they don't need to be updated after all
[10:26] <Kamion> ok, I'll give it a shot :)
[10:26] <fabbione> Kamion: thanks
[10:26] <lifeless> Kamion: no more info needed I think, just no progress either :[
[10:26] <Kamion> mirak: it's definitely in the archive, in the restricted component
[10:26] <Kamion> lifeless: ok
[10:27] <lifeless> Kamion: does it happen on every changeset, or just some [how reproducible is it] 
[10:27] <Kamion> lifeless: it happened on all three I committed after upgrading to baz 1.1
[10:27] <Kamion> I haven't checked the ones since then
[10:27] <lifeless> ok, thanks.
[10:27] <Kamion> (that was just up to the bug report)
[10:27] <Kamion> let's see ...
[10:28] <lifeless> so the sequence is 1) commit to remote archive, 2) mirror from remote archive to other remote archive.
[10:28] <lamont_r> Kamion: symlink fixed.  will investigate what happened.
[10:28] <lamont_r> fabbione: thoughts on 6035?
[10:28] <Kamion> lifeless: right, mirroring from the same host so that .arch-cache is used; .arch-params/hook specifically
[10:28] <lifeless> ok, so your hook calls baz archive-mirror ?
[10:29] <Kamion> lifeless: yep
[10:29] <lifeless> thanks
[10:29] <Kamion> with a limit of the package-version
[10:29] <lifeless> yah
[10:30] <fabbione> lamont_r: bad ram? does it happen on all kernels? a corrupted filesystem?
[10:30] <lamont_r> fabbione: exactly.  I'll go ahead and follow up with the bug
[10:31] <fabbione> lamont_r: thanks.. i will check tomorrow as well. he is from .dk so perhaps i can just poop by his house :)
[10:31] <lamont_r> fabbione: thanks
[10:31] <lamont_r> you're much closer than I.
[10:31] <fabbione> no shit! :)
[10:34] <Kamion> lifeless: yeah, it's happened to every revision in cdimage--mainline--0 since patch-108, which was the first after I upgraded
[10:36] <lifeless> Kamion: thank you 
[10:36] <Kamion> if it helps though, I've only tried on powerpc
[10:37] <lifeless> I don't *think* we've got any punish-64-bit user code left.
[10:38] <Kamion> powerpc is 32-bit, but big-endian
[10:38] <lifeless> that so sucks, get a 801e or whatever it is.
[10:40] <mdz> smurfix: yes, haven't looked at the code yet, but I will
[10:41] <schweeb|work> quick question... got an XFS bug/issue, the bug is already reported to SGI, not sure if you guys would want a bugreport or not too...
[10:41] <tseng> schweeb|work: probably report a bug to ubuntu if you get a fix from sgi/linux-bk
[10:44] <schweeb|work> well, the bugs I've found at SGI that are similar are unclaimed, and have been since like may
[10:44] <tseng> =/
[10:44] <schweeb|work> indeed
[10:45] <tseng> if you do file a bug with ubuntu, be sure to link to those
[10:45] <tseng> not sure how much it will help either party, however
[11:02] <mako> ok.. someone want to help me identify a language and then translate out of it? :)
[11:02] <dholbach> mako: give an example
[11:02] <lamont_r> mako: you're asking, so I'll assume that japanese it isn't... :(
[11:02] <mako> cuo sam da se  moze naruciti vas prizvod pa  ako nije problem moze te li poslat UBUNTU LINUX
[11:03] <mako> something about getting ubuntu
[11:03] <mako> i suspect its slavic
[11:03] <dholbach> hungarian or something
[11:03] <lamont_r> yugoslavian, I bet
[11:03] <sivang> romania?
[11:03] <[Clint] > not hungarian
[11:03] <mako> that's basically the whole message
[11:03] <tseng> google the oddest word says
[11:04] <[Clint] > definitely looks slavic
[11:04] <tseng> Balkan Media Club first hit
[11:04] <marcin_ant> dholbach: absolutely not hungarian
[11:04] <marcin_ant> dholbach: and besides - hungarian != slavic
[11:04] <sivang> bulgerian?
[11:04] <lamont_r> google on 'cuo sam da se' gives a bunch of .yu sites.
[11:04] <mako> i'm actually more interesting in knowing what it says
[11:04] <mako> interested even
[11:04] <dholbach> marcin_ant, [Clint] : sorry - didn't say i was an expert :-)
[11:04] <marcin_ant> dholbach: ;)
[11:05] <dholbach> there's no #ubuntu-yu yet... hmmm
[11:05] <Josephus> it's not hungarian :)
[11:05] <[Clint] > mako: stalk joy
[11:05] <marcin_ant> dholbach: hungarian is propably the most strange language in the world ;)
[11:06] <marcin_ant> dholbach: a little example "hatlyba lp Fszekrakprogram segtsgvel llami garancival knnyebben juthatnak lakshoz" :)
[11:06] <dholbach> marcin_ant: that looks nice to me :-)
[11:06] <Josephus> it's one of the hardest
[11:07] <jbailey> mdz: For using busybox, is updating the package version to 1.0 an option, or should I use busybox-cvs?  Busybox 1.0 looks to have been released in October.
[11:08] <lamont_r> mako: sorry
[11:08] <sivang> marcin_ant: with ishtanem being the strangest to me as "god"
[11:09] <Josephus> it's "my god" actually
[11:09] <Josephus> isten (isthan) is "god"
[11:10] <sivang> Josephus: ah well, it's been a while since I Last heared hungerian :)
[11:10] <sivang> Josephus: and "em" means mine?
[11:10] <Josephus> yes
[11:12] <sivang> Josephus: always sounded to me like mixture of some langs..
[11:13] <marcin_ant> I got a question
[11:14] <ajmitch> mako: for signing CoC text, just copy & paste off the webpage?
[11:14] <marcin_ant> today is website contest deadline
[11:14] <mako> ajmitch: that's fine
[11:15] <lamont_r> mako: was that .yu email to info@?
[11:15] <marcin_ant> could you tell me in which timezone jdub is?
[11:16] <lamont_r> marcin_ant: .au somewhere
[11:16] <marcin_ant> I'm not sure if I can send submission or not now
[11:16] <lamont_r> like +7 or something
[11:16] <marcin_ant> lamont_r: australia...
[11:17] <lamont_r> yeah - +11 actually
[11:17] <lamont_r> it's 0916 feb 1 for him
[11:17] <mako> lamont_r: yes
[11:17] <lamont_r> figures
[11:17] <marcin_ant> lamont_r: whoo thanks :)
[11:18] <mako> well, i get *plenty* of non-english mail to mako@canonical.com
[11:18] <mako> a couple a day
[11:18] <marcin_ant> lamont_r: then I have some time to finish my job
[11:18] <sivang> mako: do you get hebrew ones? ;-)
[11:18] <mako> usually i can either make out the point or do machine translation to get enough of a point to repsond
[11:18] <mako> sivang: not yet
[11:18] <mako> i'm sure it's only a matter of time
[11:18] <sivang> mako: hehe, well, if you do, you know my address :)
[11:20] <ajmitch> mako: sent
[11:20] <Josephus> mako: i got translated that serbian line if you're interested :)
[11:20] <mako> ok.. i might not get to it today
[11:20] <ajmitch> I'm guessing that I first need the CC approval before I can be on the TB agenda for the next meeting?
[11:21] <mako> i'm not exagerating when i say i've been writing email for 6 hours *straight* right now
[11:21] <mako> ajmitch: it's up to them
[11:21] <ajmitch> alright
[11:21] <mako> ajmitch: but they could give you conditional approval upon membership being signed off by the cc next week
[11:21] <ajmitch> that could be useful
[11:22] <mako> i need to take a break and have tea or something..
[11:23] <gsuveg> re
[11:23] <lamont_r> mdz: you beat me to 6035 - thanks
[11:24] <mdz> Kamion: still here?
[11:24] <mdz> jbailey: busybox-cvs is what we use in the installer
[11:25] <mdz> jbailey: so it's where most of the Debian and Ubuntu development seems to happen
[11:25] <mdz> jbailey: confirm with Kamion, but I think busybox-cvs, yes
[11:25] <mdz> Kamion: speaking of which, still here?
[11:26] <jbailey> mdz: 'k, thanks.
[11:26] <thully> when does mjg59 log on here?  I wanted to ask him about the progress of suspend in hoary.
[11:26] <jbailey> mdz: It'll pretty much have to be.  The busybox package doesn't support 2.6 at all.
[11:27] <jbailey> The non-cvs one, that is.
[11:27] <jbailey> bbiam
[11:33] <mdz> mvo__: here?
[11:34] <mdz> mvo__: where is gnome-software-properties intended to be visible in the desktop?
[11:35] <dholbach> mdz: it's launched by update-manager's "properties" button
[11:35] <mdz> shouldn't it have a menu entry of its own?
[11:35] <mdz> it affects much more than update-manager
[11:38] <dholbach> mdz: i'm not sure if there are other visible ways... (desktop->system->update-manager is what i see too)  (i'm using german translation, so the wording may be incorrect)
[11:41] <lamont_r> back on in a bit
[11:48] <mako> Josephus: yes, go eahd
[11:52] <Josephus> "I heard that i can order ubuntu linux from you. Would you send me one if it's not a problem?"
[11:52] <Josephus> or something similar
[11:53] <mdz> Kamion: is there an install iso available with the new base-config-before-reboot stuff, or should I wait for the next daily before doing a round of install tests?