[12:11] <zul> hmm...there seems to be people refering to ubuntuforums in gentoo's bugzilla
[12:12] <sivang> zul: hehe
[12:18] <edd> mjg59: hmm, i get nonrepeatability of sleep/resume with acpi-support which doesn't occur if i just use plain ol' echo 3 >/proc/acpi/sleep. i'll try and track down what's causing it, but i'm guessing some module removal/reinsert 
[12:18] <edd> mjg59: (on tosh r100)
[12:25] <mjg59> Hm. Interesting.
[12:26] <haggai> jdub: ping?
[12:29] <zul> hey tseng you might want to remove yourself from the community council agenda
[12:30] <tseng> oh.
[12:30] <zul> unless if you still want to be talked about
[12:30] <dholbach> tseng: did it an hour ago :-)
[12:30] <tseng> dholbach: thanks much.
[12:31] <dholbach> zul: i bet tseng enjoys that :-)
[12:31] <tseng> sure do
[12:31] <dholbach> tseng: oh no... i removed myself from it :-)
[12:31] <tseng> all the time people say stuff like: "someone should make an up to date mono repo for ubuntu"
[12:32] <zul> heh
[12:33] <tseng> done.
[12:43] <jdub> tseng: you've done 1.1?
[12:46] <tseng> jdub: no, its on the list for debian-mono dudes
[12:46] <tseng> jdub: working together with debian = rad
[12:48] <dholbach> i'm off to bed - sleep tight everyone
[12:48] <tseng> jdub: i passed one last tiny patch to the muine maintainer and he is getting ready to hopefully push muine + gtk-sharp2 to experimental. mono 1.1 comes after 1.0.5 in sarge
[12:49] <tseng> that little talk we had with miguel is just now hitting the pkg-mono list.. we'll see where that leads
[12:55] <jdub> tseng: haha, cool
[12:56] <mjg59> evolution sharp would be nice...
[12:56] <jdub> someone's done it
[12:56] <jdub> i have to check over it
[01:15] <sivang> does anybody know where can I download hoary daily builds through a torrent? (has anoyone got a url)
[01:16] <daniels> er, i don't think we do torrents for daily builds
[01:17] <sivang> daniels: ah ok then , I'll rsync, surely the rsync daemon is running for daily's right?
[01:17] <tseng> that wouldnt make sense, youd have few seeds.
[01:21] <sivang> (wanting it mainly to be able to continue an interrupted download)
[01:22] <ajmitch> sivang: rsync does that though
[01:25] <daniels> sivang: it runs over all of a.u.c/cdimage.u.c
[01:43] <sivang> daniels: cool, just before warty preview
[01:43] <daniels> sivang: hm?
[01:43] <daniels> sivang: where are you rsyncing from?
[01:44] <sivang> daniels: as in location?
[01:44] <daniels> yeah
[01:44] <sivang> daniels: oh, israel, have we got a mirror over here already?
[01:44] <daniels> oh, sorry, i meant which host
[01:45] <daniels> but cdimage.u.c::cdimage should have it
[01:45] <sivang> daniels: ah ok will do , thanks.
[03:18] <crypto-working> who does one contact to become a us mirror?
[03:24] <zul> hey mdz
[03:24] <mdz> hi
[03:25] <cryptoknight> anyone know?
[03:25] <zul> cryptoknight, have you checked the wiki?
[03:26] <cryptoknight> i did
[03:26] <cryptoknight> i could not locate information on this subject
[03:28] <whiprush> "If you set up a new mirror, please add it to this page and send contact information to  mirrors@canonical.com"
[03:28] <whiprush> http://www.ubuntulinux.org/wiki/Archive
[03:29] <cryptoknight> thank you
[08:01] <doko> good morning
[08:43] <Gagatan> HcE :)
[08:44] <HcE> Gagatan: =)
[08:47] <fabbione> morning
[08:47] <fabbione> daniels: ping
[08:49] <mdz> morning
[08:49] <fabbione> hey mdz
[08:54] <fabbione> daniels: WAKE UP MY LITTLE YOUNG FRIEND!
[08:55] <dilinger> fabbione: aren't you supposed to be getting married or something?
[08:55] <fabbione> i did
[08:55] <fabbione> last saturday
[08:56] <fabbione> what was the name of the software to create galleries on the fly?
[08:56] <fabbione> i have a bunch of pics already
[08:56] <Treenaks> fabbione: php? "gallery" :)
[08:57] <fabbione> Treenaks: doesn't matter the language
[08:57] <fabbione> Mithrandir was mentioning something you just run the pic dir
[08:57] <fabbione> and it will create the thumbs and the html
[08:57] <Treenaks> oh.. galrey
[08:59] <fabbione> thanks
[09:04] <fabbione> jdub: ping?
[09:21] <pitti> Hi guys
[09:22] <pitti> Happy valentine's day :-)
[09:22] <fabbione> hey pitti
[09:22] <pitti> fabbione: Congratulations for your marriage! I wish you all the best
[09:22] <fabbione> thanks man
[09:22] <pitti> fabbione: recovered from the long party? :-)
[09:22] <mvo_> hi pitti!
[09:22] <pitti> Hi mvo_ 
[09:22] <mvo_> congrats fabbione 
[09:22] <mvo_> :)
[09:22] <fabbione> pitti: + or -
[09:23] <fabbione> mvo_: thanks
[09:23] <pitti> fabbione: huh, you mean your marriage is signed now?
[09:23] <fabbione> doko: ping?
[09:24] <doko> fabbione: yes, congrats!
[09:24] <fabbione> doko: thanks.. gcc-3.3/3.4 question
[09:24] <fabbione> i can't build 3.4 on sparc 
[09:24] <fabbione>   gobjc-3.3: Depends: libobjc1 (>= 1:3.3.5-8ubuntu2) but it is not going to be i
[09:24] <fabbione> now.. 3.3.5-8ubuntu2 has built fine
[09:25] <doko> yes, built by gcc-4.0
[09:25] <fabbione> but there was no libobjc1 with ubuntu2 version
[09:25] <fabbione> ahhh ok
[09:25] <fabbione> gcc4 is still building
[09:25] <fabbione> gotcha
[09:25] <fabbione> thanks
[09:25] <doko> should work, built it last week
[09:26] <fabbione> doko: yes, sparc is lagging a bit
[09:27] <fabbione> i had a problem with the local mirror (+2 days of lag)
[09:27] <fabbione> and i did something totally stupid (+1 day of lag)
[09:27] <fabbione> so it's recovering slowly
[09:28] <doko> stupid? ehh, you regret the wedding that soon? *duck and run*
[09:28] <fabbione> ahahhaha
[09:28] <fabbione> i did already 20 minutes after :-)
[09:28] <fabbione> http://www.fabbione.net/wedding/IMG_0854.html
[09:28] <fabbione> just to give you an idea of the weather
[09:30] <pitti> elmo: awstats sync please (Ubuntu override ok)
[09:30] <Treenaks> fabbione: 1 word: thumbnails :P
[09:31] <fabbione> Treenaks: go to the index
[09:31] <zenrox> yes
[09:31] <fabbione> and you get the thumbs
[09:31] <Treenaks> fabbione: ah cool :)
[09:31] <fabbione> you can't see snow in the thumbs
[09:32] <Treenaks> fabbione: cool picture though :)
[10:15] <mdz> good night
[10:16] <fabbione> night mdz
[10:24] <mvo_> night mdz 
[10:25] <Astharot> bonjour
[10:28] <Treenaks> does anyone here know what those pictures with letters in them (on web forms, "type the letters from this picture") are called?
[10:37] <ogra> pitti: ping
[10:37] <pitti> ogra: pong
[10:37] <ogra> had som time to look over the last procfs patch from friday ?
[10:38] <pitti> not yet, sorry
[10:39] <pitti> but I will look at it ASAP
[10:39] <ogra> ah, ok... take your time
[10:41] <Mithrandir> fabbione: I mentioned curator, or you could use imageindex
[10:45] <pitti> ogra: btw, did you know that you can put printf macros in HAL_ERROR() and the like?
[10:46] <pitti> ogra: thus you could do HAL_ERROR (("cant open file in /proc")); -> HAL_ERROR (("cannot open %s", path))
[10:46] <ogra> pitti: oh, no, thats new to me....
[10:46] <ogra> great
[10:47] <pitti> ogra: it helps to improve the usability of debug messages a lot
[10:47] <ogra> yup....even if i wouldnt expect cpuinfo or meminfo to b there on every linux ;)
[10:47] <ogra> as long as proc is mounted
[10:47] <pitti> ogra: I know, but in general it is nice to know
[10:48] <pitti> ogra: btw, there are cases when /proc is not mounted
[10:48] <ogra> pitti: i will adjust it
[10:48] <pitti> ogra: think of testing hal in a chroot
[10:48] <ogra> pitti: thats why i left the osspec check there
[10:48] <pitti> ogra: patch looks fine
[10:48] <ogra> pitti: yay
[10:49] <ogra> pitti: see, youre a great techer :) thanks.....
[10:49] <ogra> s/techer/teacher/
[10:49] <pitti> ogra: so the still missing patch is dmidecode?
[10:49] <fabbione> Mithrandir: i used galrey
[10:49] <fabbione> Mithrandir: pretty ok for simple stuff
[10:49] <fabbione> Mithrandir: http://www.fabbione.net/wedding/
[10:49] <pitti> ogra: shall I upload a new hal with these two patches in the meantime?
[10:49] <ogra> and some device-manager stuff.... (the new features shall have icon too)
[10:50] <fabbione> Kamion: ping?
[10:50] <ogra> pitti: yeah
[10:50] <ogra> fabbione: may i send you my best wishes....
[10:50] <pitti> ogra: are you interested in creating the new package yourself? (patches, autofoo patch, etc.)? or shall I do it?
[10:50] <fabbione> ogra: thanks dude...
[10:51] <ogra> pitti: you are more familiar with it.... but you could leave me the neyt one if i'm lless busy ;)
[10:51] <ogra> s/neyt/next
[10:51] <pitti> ogra: okay, then I will do the package today and upload it
[10:52] <ogra> yippie
[10:52] <ogra> at least soething positive after a weekend with debian flames for me....
[10:52] <pitti> ;-)
[10:57] <ogra> pitti: seen this ? http://www.inittab.de/blog/2005/02/13#20050213_ion3-update
[10:58] <pitti> ogra: *chuckle*
[10:59] <ogra> yup.... btw... i said defaced....and he ripped the whole conversation out of context in ths one sentence....
[10:59] <ogra> profilneurotiker.....
[10:59] <pitti> :-)
[11:00] <Keybuk> ok, weird; when I plugged in my iAudio, the window appeared
[11:00] <ogra> but he also showed me the dark side....ther was not one sentence in our conversation where he didnt rant about apt 0.6
[11:00] <Keybuk> but now I can't find it in Desktop, Places, Computer, etc.
[11:00] <Keybuk> yet is still mounted in /meda
[11:01] <pitti> Keybuk: could be a cause of the broken inotify
[11:01] <ogra> ....which indeed was totally unrelated to the conversation....
[11:02] <Keybuk> pitti: does inotify affect hal's detection of filesystems?
[11:02] <pitti> Keybuk: no, it doesn't
[11:02] <Keybuk> because it doesn't appear as a filesystem in the open dialog, etc. either
[11:02] <pitti> Keybuk: inotify only affects the gnome stuff
[11:02] <pitti> Keybuk: is the file system recognized in hal-device-manager?
[11:03] <Keybuk> there's a block volume in there, yeah
[11:04] <pitti> Keybuk: and device and fstype are correct?
[11:19] <jdub> fabbione: pong
[11:20] <fabbione> jdub: thanks.. i have done :-)
[11:21] <haggai> jdub: I never got an ACCEPT mail, I guess it didn't like me uploading the .orig.tar.gz from a different IP
[11:22] <dholbach> hai!
[11:24] <Keybuk> pitti: I think so.  so "iz gtk bug" ?
[11:24] <pitti> Keybuk: as long as hal reports it fine and gvm mounts it, the Utopia part seems to work
[11:25] <pitti> Keybuk: I have the same odd behavior sometimes, though
[11:25] <pitti> Keybuk: devices are still displayed as mounted, although they were unmounted long ago, and similar thinkgs
[11:30] <Mithrandir> fabbione: congrats. :)
[11:35] <fabbione> Mithrandir: thanks :-)
[11:45] <Mithrandir> seb128: the evo segfaulting on amd64 bug should be fixed now
[11:47] <jdub> Mithrandir: yay!
[11:48] <Mithrandir> jdub: it was a problem with pthreads and krb4...
[11:49] <jdub> ouch
[11:50] <seb128> Mithrandir: rock, thanks!
[11:50] <Mithrandir> just a broken configure script, but evo is library hell so it took a while to track down.
[11:56] <Mithrandir> seb128: I haven't closed the bugs, but you might want to do that.
[11:56] <seb128> k
[11:56] <Mithrandir> gotten any further on the nautilus problem?
[11:59] <seb128> Mithrandir: no yet, but the diff between both version is not huge, I'll probably send you a patch to try today
[12:00] <Mithrandir> ok
[12:07] <mvo_> seb128: do you have a idea why metacity ignores "gdk_window_raise()" for top-level windows? is this the new focus-stealing stuff?
[12:08] <Kamion> fabbione: yo
[12:09] <seb128> mvo_: probably yep
[12:09] <fabbione> hey
[12:11] <pitti> ogra: ping
[12:17] <mvo_> seb128: do you know if there is a way to work around it ;) ?
[12:17] <seb128> mvo_: what are you trying to do ?
[12:18] <mvo_> seb128: if there is a synaptic already runing and it's started again, bring it in the foreground
[12:18] <mvo_> (the runing one)
[12:19] <ogra> pitti: pong
[12:19] <seb128> and that doesn't work ? or you just don't get the focus on it ?
[12:19] <mvo_> seb128: it does not work (no raise). it works with xfce though
[12:20] <pitti> ogra: never mind, had some troubles with autoconf, but solved it
[12:20] <ogra> ah, ok
[12:21] <ogra> pitti: caused through me ? (i mean do i have to regard anything special in the next patch ?)
[12:21] <pitti> ogra: no, caused by the gazillion different version combinations of libtool/automake/autoconf/autofuck/whatever
[12:22] <ogra> hehe... thats what i ran into when i tried it.....hal uses 1.9 apparently
[12:22] <seb128> mvo_: dunno, seems to be a bug yep
[12:23] <mvo_> seb128: I guess I need to recompile metacity to get all the nice "meta_verbose" messages?
[12:23] <ogra> pitti: that was why i asked you about special magic in one of my mails ;)
[12:23] <pitti> ogra: that's why I package the makefile updates as a patch instead of calling autofuck in debian/rules
[12:24] <ogra> yup... i understand that
[12:24] <seb128> mvo_: yep. I can ask to one of the metacity guy on IRC you want, that's probably faster (though he's not connected atm)
[12:24] <mvo_> seb128: that would be very nice, thanks
[12:24] <seb128> np
[12:28] <mvo_> seb128: just checked with the old metacity (warty version), seems to work with it
[12:32] <dholbach> bbl
[12:33] <pitti> ogra: this is the first time I actually _see_ your changes in h-d-m. Looks nice :-)
[12:33] <ogra> hey, thanks...
[12:33] <ogra> pitti: wait for the bios stuff ;)
[12:34] <pitti> ogra: ugh, the autoconf patch is 1.7 MB
[12:35] <ogra> argh
[12:35] <ogra> for only 2 additional lines in Makefile.am .... thats impressife
[12:36] <seb128> mvo_: yeah, but the focus stealing prevention change a lot of stuff on this plan
[12:36] <ogra> s/f/v/
[12:37] <ogra> pitti: in my tests there was a .deps dir or something created i think.... there were a lot of .obj files....are these needed ?
[12:38] <pitti> ogra: the patch doesn't contain them
[12:38] <pitti> ogra: it contains only Makefile.in changes and configure changes
[12:38] <ogra> oh, and still 1.7 MB
[12:39] <ogra> pitti: sure these are only my changes ?
[12:40] <pitti> ogra: it doesn't really matter how much you change the *.am files
[12:40] <pitti> ogra: this is just the totally ridiculous principle of automake/autoconf
[12:41] <pitti> ogra: hal_0.4.7-1ubuntu4_source.changes ACCEPTED
[12:41] <ogra> HOORAAY
[12:41] <ogra> :-D
[12:41] <Kamion> make sure you're using the same version of automake as was quoted in the original .in file
[12:41] <Kamion> or at least the same X.Y version
[12:44] <ogra> Kamion: hal uses 1.9.4 i think.... unbuntu has 1.9.5 afaik
[12:45] <Kamion> ogra: there automake1.4 | 1:1.4-p6-8 |         hoary | all
[12:45] <Kamion> automake1.6 |   1.6.3-11 |         hoary | source, all
[12:45] <Kamion> automake1.7 |    1.7.9-6 |         hoary | source, all
[12:45] <Kamion> automake1.8 |    1.8.5-2 |         hoary | source, all
[12:45] <Kamion> automake1.9 |    1.9.4-1 |         hoary | source, all
[12:45] <Kamion> pick one
[12:45] <Mithrandir> Kamion: don't you love automake? :)
[12:45] <Kamion> and preferably invoke it by 'automake1.9' or whatever if you want to be sure
[12:45] <ogra> hehe.... yes, i already ran into this....
[12:46] <ogra> i guess this has been aske a thousand times already.... shouldnt automake just link to the newest version....
[12:46] <ogra> s/aske/asked/
[12:46] <Kamion> it generally *does*, via alternatives
[12:46] <Kamion> alternatives are not the most reliable system on the planet though
[12:46] <ogra> hmm, so mine are broken it seems
[12:47] <Kamion> no idea, try 'update-alternatives --display automake'
[12:47] <Kamion> actually automake1.4 seems to have a higher priority
[12:47] <ogra> yup ...
[12:47] <Kamion> I assume there's a good reason
[01:15] <mantiena-baltix> Kamion, I have one question to you, as d-i developer, do you have some time to aswer ?
[01:16] <Kamion> mdz: please always run debconf-updatepo after changing template text, so that translation indexes get updated properly (e.g. anna)
[01:16] <Kamion> mantiena-baltix: don't ask to ask, just ask. :)
[01:17] <mantiena-baltix> ;)
[01:17] <mantiena-baltix> Kaloz, in ubuntu live cd casper udeb mounts filesystem.cloop on /target. debian-installer mounts newly created partitions also on /target :(
[01:18] <mantiena-baltix> it's not good for liveCD installer
[01:18] <Kamion> fix your tab completion, too :)
[01:18] <Kaloz> :D
[01:18] <Kamion> casper has already run pivot_root by the time your live CD installer would run
[01:18] <mantiena-baltix> Kamion, evil xchat
[01:18] <Kamion> the mount on /target is no longer relevant
[01:18] <Kamion> mantiena-baltix: try typing 'Kam' rather than 'Ka' before hitting tab. :P
[01:18] <mantiena-baltix> Kamion, too many typing ... ;)
[01:19] <Kamion> how much more typing is used by not watching what goes into the channel and having to deal with a conversation about it afterwards?
[01:20] <Kamion> but anyway, I don't see that the /target mount should be a problem
[01:21] <mantiena-baltix> I know, that casper does pivot_root, but I'm trying to make universal installer, which works in both modes - text mode without starting liveCD filesistem and in gui mode after liveCD (with GNOME environment) is started
[01:21] <mantiena-baltix> Kamion, so, /target is problem
[01:22] <Kamion> oh, I see; talk to mdz then
[01:22] <mantiena-baltix> Kamion, I don't want to duplicate casper's scripts in installer
[01:22] <Kamion> he's the casper guru :)
[01:22] <Kamion> I don't think moving /target elsewhere for casper would be a problem
[01:23] <mantiena-baltix> Kamion, I too ;)
[01:23] <mantiena-baltix> mdz, what you think ?
[01:23] <Kamion> (note mdz's asleep right now, I imagine he'll read scrollback though)
[01:24] <mantiena-baltix> hehe, different timezone ;)
[01:25] <mantiena-baltix> Kamion, what folder name you suggest for casper ? I'm coding installer right now ;)
[01:25] <Kamion> no idea :)
[01:25] <Kamion> pick one, I'm sure it will be utterly trivial to change later
[01:27] <mantiena-baltix> ;)
[01:28] <jbailey> Would you mind emailing them to me?
[01:28] <jbailey> ECHAN
[01:35] <dholbach> re
[01:54] <low> hi there
[01:54] <low> i think i've found why raid soft doesn't work while installing hoary (3&4)
[01:55] <low> anyone ?
[01:56] <Treenaks> just state the problem and your fix ;)
[01:56] <Treenaks> I guess
[01:56] <low> Treenaks: i've not yet the fix
[01:56] <low> but, /dev/md* nodes do not exist
[01:57] <Kamion> we use devfs device paths
[01:57] <Kamion> I imagine they're just called something else
[01:57] <pitti> should be /dev/md/n
[01:57] <Kamion> like /dev/md/
[01:57] <low> Kamion: hmmmm w8 a bit, i take a look at the other box
[01:57] <Kamion> also make sure that the relevant kernel modules are loaded
[01:58] <low> ok no suc /dev/md, /dev/raid or whatever
[01:59] <low> modules, taking a look...
[01:59] <low> raid[015] , md are loaded
[02:00] <Kamion> that might suggest that there are no md partitions on the system, then?
[02:01] <Kamion> elmo: please sync partman-md 20; just translation fixes
[02:01] <low> i've created partitions that are to be glued into md
[02:01] <low> but, but wanting to create the md node, it complains it can't find any raid autodetect partition
[02:03] <low> hmmm i'll try to boot with "devfs=nomount", brb
[02:03] <Kamion> no, don't bother
[02:03] <Kamion> you'll be wasting your time
[02:03] <Kamion> we do not use devfs itself, but udev in devfs compatibility mode
[02:05] <low> Kamion: current config: a64, 4 sata disks on sata_sil, 1 on sata_nv
[02:08] <Kamion> doesn't seem to be particularly dependent on configuration
[02:09] <mjg59> thom: We need to shift the sleep scripts to using acpid locking
[02:10] <low> Kamion: agreed, was just to let you know
[02:13] <thom> mjg59: yes
[02:20] <ogra> thom: i wrote a xscreensaver patch that beautifys the lock-win response... sent it to jdub....he did like the old behavior with big fonts better.....
[02:21] <ogra> thom: so he is the one to argue with then... ;)
[02:21] <thom> i shall lay the smackdown on him, then
[02:22] <ogra> thom: since my part is done...yes... i dont really care which way it works, although i like it better without "verifying" and "approved"
[02:22] <ogra> thom: but jeff loves the "denied" part very much :)
[02:23] <Kamion> low: ok, think I might see the problem; partconf-find-partitions looks broken
[02:23] <thom> ogra: heh
[02:23] <ogra> pitti: ping
[02:23] <jbailey> ogra: Hu?
[02:23] <pitti> ogra: bong
[02:23] <thom> jbailey: EWRONGJEFF
[02:24] <jbailey> Lovely, /me crawls back to the other IRC tab.
[02:24] <ogra> pitti: i just heard that other people have the hal-slow-startup problem too
[02:24] <pitti> ogra: probably due to a particular piece of hardware I don't have
[02:24] <ogra> pitti: it seems only to occur on amd64
[02:24] <pitti> ogra: for which versions does this happen?
[02:24] <pitti> ogra: ah, arch-specific may explain it, too
[02:24] <pitti> ogra: already for warty?
[02:25] <ogra> pitti: for me since your udev fix... i suspect udev responds very slow
[02:25] <ogra> pitti: nope, hoary
[02:25] <low> Kamion: ok. i'd be happy to test a fixed iso asap
[02:25] <pitti> ogra: ah, right. Yes, we call "udevstart" in the postinst
[02:25] <pitti> ogra: however, this should not affect _every_ startup
[02:25] <pitti> ogra: just upgrades
[02:26] <ogra> pitti: i found that my patches are the only thing that keep h-d-m from crashing, because they are there immediately :)
[02:26] <pitti> cool
[02:26] <ogra> pitti: it affects every startup here....
[02:26] <pitti> ogra: I did not touch /etc/dbus-1/event.d/20hal
[02:26] <pitti> ogra: and this file does nothing with udev
[02:26] <pitti> ogra: it just starts the hal daemon
[02:27] <ogra> hmm, but dholbach had the problem too, just a minute ago....
[02:27] <ogra> pitti: but i have no idea wher to look at in a bit more specific way...
[02:28] <pitti> ogra: maybe you can start hald in debug mode to see what takes so long?
[02:28] <ogra> i'll do....
[02:28] <pitti> ogra: sudo killall hald; sudo hald --verbose=yes --daemon=no --drop-privileges :-)
[02:28] <ogra> and probably a gdb in front if i dont see anything ;)
[02:29] <pitti> ogra: this will print out all the HAL_ERROR/HAL_INFO/whatever to the console
[02:29] <pitti> ogra: so you see at which device it hangs
[02:29] <ogra> Timeout (10000 ms) for callout 40-hal-hotplug-map.hal
[02:30] <ogra> ouch
[02:30] <ogra>  Cannot find callout for terminated child with pid 14046
[02:31] <ogra> pitti... just piping it to a file... i'll send it
[02:35] <ogra> pitti: http://www.grawert.net/hal.log
[02:37] <pitti> can you please see why the childs terminate prematurely? 
[02:38] <zul> hey
[02:40] <pitti> hi zul
[02:40] <zul> hey pitti how is it going?
[02:47] <enrico> Hello.  What distribution do I put in the changelog for Hoary?  Just "hoary" ?
[02:48] <Mithrandir> yes
[02:48] <dholbach> yes
[02:48] <dholbach> if someone bothered uploading my dh-make--patch... :-)
[02:48] <enrico> thanks!
[02:51] <thom> dholbach: jbailey could just upload it now :P
[02:51] <dholbach> thom: i found out dh-make was in main
[02:53] <trulux> heya
[02:53] <trulux> pitti: hey!
[02:53] <trulux> tritium: back from school
[02:53] <tritium> trulux, hello
[02:53] <trulux> tritium: howya?
[02:53] <jbailey> thom: Are you're point at me, why? =)
[02:54] <tritium> trulux, Just arrived at the office a bit ago.  Still drinking my coffee :)
[02:54] <jbailey> Oh, I see. =)
[02:56] <Kamion> dholbach: please use the lsb_release program rather than parsing /etc/lsb-release yourself
[02:56] <Kamion> i.e. lsb_release -c
[02:57] <tritium> trulux, working on it now
[02:58] <zul> lamont: ping
[02:58] <jbailey> "lsb_release -cs" looks exactly like what you want.
[02:58] <dholbach> Kamion: alright, i'll take care of it
[02:58] <trulux> tritium: I love coffee, it's reason why I can be still awake in the deep night 
[02:58] <trulux> ;)
[02:58] <Kamion> hm, yes, what jbailey said
[02:59] <lamont> zul - running out the door to take kids to school (late) back in about 90 minutes
[02:59] <zul> k
[03:02] <dholbach> Kamion, jbailey: so would you test for   -e /bin/lsb_release  ?
[03:03] <dholbach> Kamion,jbailey: i wouldn't let dh-make depend on lsb-release or anything
[03:03] <jbailey> dholbach: That sounds reasonable to me.
[03:03] <dholbach> alright
[03:12] <dholbach> jbailey, Kamion: fixed it
[03:17] <pitti> trulux: hi
[03:17] <pitti> ogra: cool, just saw the new xscreensaver when I returned
[03:17] <pitti> ogra: looks much better
[03:18] <ogra> pitti: iand i just saw that we both missed a line in my lsb patch...darn...
[03:18] <pitti> ?
[03:19] <ogra> pitti: either lsb adds the data to a nonexisting root device (its to fast) or i must set a callout in the end of the code....
[03:20] <ogra> pitti: t seems its actually triggered by the lsb patch....
[03:20] <pitti> hmm
[03:21] <pitti> EWORKSFORME
[03:21] <ogra> hmm
[03:21] <Treenaks> smells like a race somewhere?
[03:23] <ogra> Treenaks: happens only on amd64
[03:29] <mjg59> http://linux.slashdot.org/comments.pl?sid=139381&cid=11666527 - quality
[03:31] <fabbione> daniels: ping?
[03:31] <mvo_> ping lamont 
[03:32] <HrdwrBoB> fabbione: I have a suspicion he is in bed
[03:32] <mvo_> lamont: I would like to know if you still can reproduce #5666?
[03:32] <fabbione> HrdwrBoB: no. he should be around anytime soon
[03:32] <HrdwrBoB> ah ok
[03:33] <HrdwrBoB> I was just adding up time spend awak vs time sleeping and came up with sleep
[03:36] <ogra> mjg59: they mispelled mandela
[03:40] <zul> fabbione: i pushed some patches this weekend to lamont for uploading this week or something like that
[03:40] <zul> its still too early
[03:40] <fabbione> zul: cool
[03:41] <zul> oh and i have 2.6.11 as well
[03:43] <fabbione> zul: cool, does it work?
[03:43] <pitti> fabbione: 2.6.11 works fine for me, too
[03:43] <fabbione> sw33tn3ss
[03:44] <zul> fabbione: havent had a chance to try it yet, there is a couple of bug reports already about it
[03:44] <fabbione> it took me more time to figure out why arch all couldn't build than anything else :-)
[03:46] <Kamion> low: ok, I think I have most of it figured out now (and a test installation running), but I'm going out for a bit now
[03:46] <fabbione> zul: 2.6.11 -> experimental as mdz said
[03:46] <fabbione> zul: bugs are good, but they don't need to be prioritized
[03:46] <fabbione> not until we have a real 2.6.11
[03:47] <Kamion> elmo: please sync mdcfg 1.09; just translation fixes
[03:49] <opi> Hi there 
[03:50] <opi> I've been playing with a LiveCD customization
[03:52] <opi> I wonder (I don't have USB Key yet) is there a chance to install Ubuntu on USB, but not as LiveCD (ie. read only) but with ability to RW
[03:53] <enrico> Hello.  Question about packaging: I'm packaging the Ubuntu Docteam things (svn co https://docteam.ubuntu.com/repos/trunk) and it's various xml files with some common entities
[03:53] <enrico> I would like to make 3 packages out of that, as it's 3 pieces of documentation.  If you checkout the repository you'll find that the .deb packaging is done already
[03:54] <enrico> Now, I'd like to package the xml, and it appears it would be better if all the three packages install things in /usr/share/doc/ubuntu-docs instead of a different usr/share/doc/ directory each
[03:54] <enrico> the deal is that I can put the xml common entities in the ubuntu-docs package, then make the other packages depend on it, and let them install things in /usr/share/doc/ubuntu-docs as well
[03:55] <low> Kamion: ok, thanks a lot. any idea when the next test iso will be out ?
[03:55] <enrico> I don't know however how much that is doable (policy wise and debhelper-wise)
[03:56] <Kamion> low: daily builds
[03:56] <daniels> fabbione: heheh :) patience, jedi
[03:56] <Kamion> low: assuming I get it all uploaded today of course, which I don't guarantee
[03:56] <ogra> pitti: the only thing i find ... lseek(7, 0, SEEK_CUR) = -1 ESPIPE (Illegal seek)
[03:56] <Kamion> low: the next test release is planned for Wednesday
[03:56] <eruin> are any of you aware of hdparm -d (dma) bug reports?
[03:56] <fabbione> daniels: shut up padowa :P
[03:56] <low> Kamion: ok, i'll dl the next one on wednesday then. thx again !
[03:56] <Kamion> ok, I had to tweak grub a bit by hand, but other than that the install seems to have worked
[03:57] <daniels> fabbione: haha
[03:57] <enrico> Ok, forget about what I said.  Short version: I need a hand with packaging some documentation.
[03:57] <Kamion> /dev/md0              15954944    716888  14427584   5% /
[03:57] <ogra> pitti: this is in lsb.... and i have no idea who calls lseek...
[03:57] <enrico> Could please someone who did some scrollkeeper do "svn co https://docteam.ubuntu.com/repos/trunk" and join #ubuntu-doc ?
[03:58] <pitti> ogra: "in lsb" means, this is in your module?
[03:58] <pitti> ogra: understandable, you cannot seek pipes
[03:58] <daniels> lamont: ping
[03:58] <ogra> pitti: yes, in the end of the lsb call in my strace....
[03:59] <ogra> pitti: i'll upload the strace....wait a sec
[04:00] <ogra> pitti: http://www.grawert.net/hal.strace
[04:02] <pitti> ogra: okay, this is fdopen()'s fault
[04:02] <ogra> gah
[04:03] <ogra> but why does it only happen on amd64 ?
[04:03] <pitti> wait, I try that out on my box, too
[04:03] <pitti> I think it surely happens here
[04:04] <ogra> then its not the bug ...
[04:04] <pitti> ogra: in theory the program should just continue to run
[04:04] <pitti> ogra: i. e. ignore the lseek
[04:04] <ogra> ok...
[04:05] <pitti> bah, we should disable this stupid fstab-sync
[04:05] <ogra> yup
[04:06] <ogra> it only throws spam out...
[04:06] <pitti> ogra: however, no Timeout message for me
[04:06] <ogra> hmm
[04:06] <enrico> Question: can I install symliks in /usr/share/doc/ubuntu-docs pointing at /usr/share/ubuntu-docs?
[04:06] <low> see ya !
[04:06] <ogra> pitti: kernel bug ?
[04:07] <pitti> hmm, no I don't think so
[04:07] <ogra> what else ?
[04:07] <ogra> since it must be arch specific
[04:07] <pitti> ogra: can you please wrap the callouts into a script calling gdb/strace/whatever?
[04:07] <pitti> ogra: I think it is dependent on some hw or processor speed
[04:08] <ogra> hmm
[04:12] <Mithrandir> Keybuk: do you have pkg-config in arch somewhere?
[04:12] <Keybuk> nope
[04:13] <jordi> enrico: yes, you can
[04:13] <jordi> enrico: at least following debian-policy
[04:14] <enrico> jordi: thanks!
[04:14] <Mithrandir> Keybuk: any other VCS?
[04:14] <enrico> jordi: and can different packages all install stuff in /usr/share/ubuntu-docs?
[04:15] <jordi> enrico: sure. s$ubuntu-docs$/gnome/help$
[04:15] <enrico> thanks a lot!
[04:15] <jordi> enrico: np :P
[04:16] <jordi> that should have read s$ubuntu-docs$gnome/help$ though :)
[04:17] <lamont> moo
[04:17] <lamont> zul: will fetch your patches
[04:17] <fabbione> hey lamont 
[04:18] <fabbione> i might need some changes to the kernel pretty soon
[04:18] <fabbione> mind to wait to upload?
[04:18] <lamont> fabbione: I suppose we could...
[04:19] <lamont> you changing 2.6.10?
[04:19] <lamont> daniels: sup?
[04:20] <fabbione> lamont: daniels is
[04:20] <lamont> ah, ok
[04:20] <fabbione> he will give you the patch
[04:20] <lamont> oh, ok. 
[04:20] <lamont> so  it's "wait for daniels' patch", not "let fabbione upload a new kernel"
[04:20] <lamont> got it
[04:21] <daniels> lamont: hi! :)
[04:21] <Keybuk> Mithrandir: it's in freedesktop.org CVS
[04:21] <fabbione> lamont: exactly
[04:21] <Mithrandir> Keybuk: found it.
[04:21] <daniels> lamont: i'll bounce you the interdiff for an evdev patch, which is just adding one already-built module to input-modules*.udeb
[04:22] <daniels> lamont: and there's one trivialish thing to be done too -- where we have CONFIG_DRM=y, change to CONFIG_DRM=m, and add drm.ko (or drm-core.ko, whatever) to l-i where needed, although it should just drop straight in
[04:23] <daniels> lamont: sent
[04:23] <lamont> daniels: woot
[04:28] <fabbione> pitti: ping?
[04:28] <pitti> fabbione: pong
[04:29] <fabbione> pitti: for curiosity.. how does pmount decide under what user to do the mount?
[04:29] <pitti> fabbione: getuid()
[04:29] <fabbione> hmmm
[04:29] <pitti> fabbione: any better idea?
[04:29] <fabbione> so if i plug my usb whatever storage device...
[04:29] <fabbione> how does it detect the user?
[04:30] <fabbione> becuase i think there is a possible flaw there
[04:30] <pitti> fabbione: #4021 ?
[04:31] <pitti> fabbione: indeed, if more than one user is logged in, the wrong one might get the drive
[04:31] <pitti> fabbione: or, rather, if more than one user has a g-v-m instance running (not affecting console-only users)
[04:31] <fabbione> yes
[04:31] <fabbione> i think that needs to have a higher severity
[04:32] <pitti> fabbione: hard to decide for multi-X logins
[04:32] <fabbione> it is clearly a security flaw
[04:32] <fabbione> pitti: not really...
[04:32] <fabbione> pitti: you can use 2 approaches
[04:33] <pitti> fabbione: any idea how this could be solved? it is undecidable by design, I think
[04:33] <fabbione> one is to isolate certain usb hubs/addresses to a specific $DISPLAY
[04:33] <pitti> how should that work?
[04:33] <pitti> if two people use a common machine, but two heads?
[04:33] <fabbione> with a config file?
[04:34] <fabbione> i can tell that user on head one has this usb hubs dedicated
[04:34] <fabbione> same goes for the other head
[04:34] <fabbione> if the head is not local.. no mount
[04:35] <fabbione> or something like that
[04:35] <fabbione> or perhaps
[04:35] <fabbione> even better
[04:35] <pitti> you mean if $DISPLAY contains a hostname, g-v-m does not call pmount?
[04:35] <dholbach> erm... does anyone know charles majola's irc nick? 
[04:35] <pitti> no, that doesn't work
[04:35] <fabbione> you can also prompt for the user password in order to verify WHO actually connected the device is who claims to be
[04:35] <sjoerd> a lot of monitors have usb hubs these days, so that sounds nice ;)
[04:35] <thom> dholbach: d3vic3
[04:36] <fabbione> pitti: why not?
[04:36] <dholbach> thom: thanks
[04:36] <pitti> fabbione: ssh X-forwarding, there DISPLAY is a local port
[04:36] <pitti> (I think, might be wrong)
[04:36] <fabbione> hmm true
[04:36] <ogra> thom: shouldnt that be PythoNpackageMachin3 ?
[04:36] <pitti> fabbione: however, if two g-v-m instances ask for a password, you have the same race
[04:36] <HrdwrBoB> pitti: it's very high though, 11 iirc
[04:36] <pitti> fabbione: whoever types faster gets the drive
[04:37] <pitti> HrdwrBoB: right, it starts from 10
[04:37] <fabbione> pitti: but that require userA to know userB password
[04:37] <pitti> HrdwrBoB: but basing the decision on display numbers seems too fragile
[04:37] <pitti> fabbione: no, I mean if A types his password, but B types B's password faster, B will get it
[04:37] <fabbione> pitti: right
[04:38] <pitti> fabbione: I think the problem is not the authentication
[04:38] <pitti> fabbione: but the assignment of an USB device to a head
[04:38] <pitti> fabbione: however, if two people share the same physical host (including USB hubs), then there is no obvious "owner" of the device
[04:38] <fabbione> pitti: and if there is such mapping somewhere+?
[04:39] <pitti> fabbione: you had to map that manually
[04:39] <fabbione> pitti: let say that USB hub1 is assignined to head1
[04:39] <pitti> there is no "obviously right" mapping which could be decided automatically
[04:39] <fabbione> pitti: clearly
[04:39] <fabbione> pitti: i agree
[04:39] <fabbione> but AGAIN.. let say there is a mapping
[04:39] <pitti> then this mapping could be used, yes
[04:39] <lamont> zul??
[04:40] <fabbione> pitti: how complex would it be?
[04:40] <pitti> fabbione: you mean a mapping between USB ports and user names?
[04:40] <HrdwrBoB> USB ports and heads would be better
[04:40] <fabbione> a mapping between usb ports and head/display on the machine
[04:40] <pitti> HrdwrBoB: define "head" in terms of sysfs 
[04:40] <doko_> elmo: ping?
[04:41] <HrdwrBoB> well $DISPLAY
[04:41] <pitti> but $DISPLAY changes every time
[04:41] <pitti> we need a static map
[04:41] <fabbione> pitti: no it doesn't change everytime
[04:41] <HrdwrBoB> why would it change?
[04:44] <pitti> HrdwrBoB: hmm, right
[04:44] <lamont> HrdwrBoB: the alarm goes off at 1300UTC, whether I like it or not.
[04:44] <lamont> but the day begins with an hour to drive the kids to school (at 1345UTC)
[04:44] <HrdwrBoB> USB ports are physical devices, so map them to $DISPLAYS, which should be also physical
[04:45] <HrdwrBoB> lamont: ah damn, we just have a kitten who likes to sleep on our heads
[04:46] <pitti> HrdwrBoB: that doesn't work, we _have_ to map to user names, not to $DISPLAY values
[04:46] <pitti> HrdwrBoB: every user can alter the $DISPLAY which pmount is called with
[04:46] <HrdwrBoB> hm true
[04:47] <HrdwrBoB> could g-v-m provide it's $DISPLAY?
[04:47] <HrdwrBoB> its
[04:47] <pitti> no, that doesn't work
[04:47] <pitti> g-v-m is entirely user-privilege
[04:47] <pitti> d
[04:47] <pitti> we need something that pmount can check with its root privileges
[04:47] <pitti> a property an user can't change
[04:48] <HrdwrBoB> check it's $DISPLAY, check it's UID
[04:48] <HrdwrBoB> then check for an the correct X server with that UID?
[04:48] <lamont> HrdwrBoB: DISPLAY is completely user controlled
[04:48] <pitti> bah, checking for X servers in a low-level program like pmount is UGLY
[04:48] <HrdwrBoB> lamont: yeah but you can take that and verify it's correct
[04:48] <pitti> in particular since pmount does not only work for X
[04:49] <HrdwrBoB> well if $DISPLAY is undef it doesn't use it
[04:49] <pitti> HrdwrBoB: this stuff must work on the console, too
[04:49] <lamont> zul??
[04:49] <HrdwrBoB> it's ugly but mapping to usernames is not really optimal
[04:49] <pitti> HrdwrBoB: you cannot tell _anything_ from DISPLAY, you just cannot rely on it
[04:49] <sjoerd> pitti: fear... pam_console :)
[04:49] <pitti> sjoerd: how should that help?
[04:49] <HrdwrBoB> user1 changes console and suddenly his USB devices no longer work
[04:49] <lamont> ENOZUL
[04:50] <pitti> if user1 usually works on head1, but now on head2, he can't use the _same_ usb port any more?
[04:50] <pitti> that doesn't sound like our users would understand
[04:50] <sjoerd> pitti: dunno if pam_console can do that.. or something like it.. But you could change some properties at login time..
[04:50] <pitti> bah, but whicever user calls pmount first, gets the device
[04:50] <lamont> mvo_: that's after upgrading apt, yes?
[04:51] <pitti> sjoerd, HrdwrBoB: pmount should be entirely self-contained
[04:51] <lamont> mvo_: and which version of apt?
[04:51] <sjoerd> pitti: then it's a social problem and you can't fix it :)
[04:51] <mvo_> lamont: yes, I suspect it only happens with one of your apt-options
[04:51] <pitti> indeed
[04:51] <mvo_> lamont: any version, I don't think it's fixed, I just can't reproduce it
[04:51] <pitti> sjoerd: if two people share physical access to the same computer, there is not a big security issue anyway AFAICS
[04:52] <pitti> fabbione: ^
[04:52] <sjoerd> right
[04:52] <HrdwrBoB> pitti: I was just thinking of the 441 style systems
[04:52] <HrdwrBoB> if you had a usb port on each head
[04:52] <sjoerd> i used a shared gid to mount our camera when my parents and me were working on the same box
[04:52] <sjoerd> local and remote X..
[04:52] <lamont> mvo_: in 0.6.31, inside the chroot (no options), update works fine..
[04:52] <HrdwrBoB> you would want it per $DISPLAY, with four users it could get messy
[04:52] <fabbione> pitti: there is still the fact that i can plug my gpg private key and i don't want it mounted as the other user
[04:53] <pitti> fabbione: yes, I see that
[04:53] <sjoerd> fabbione: then you'll probably want it encrypted and impossible for somebody else to mount
[04:53] <mvo_> lamont: so #5666 (with a identical deb and deb-src line and a Release,Release.gpg file) does not fail for you anymore? sounds like we can close this bug then :)
[04:53] <sjoerd> as in, not even possible for them to use if that have it in there hands :)
[04:54] <sjoerd> s/that/they/
[04:54] <lamont> mvo_: hrm... sec
[04:54] <fabbione> sjoerd: if the encrypted device is still mounted under the wrong user, it will be impossible for me to loopmount it properly
[04:55] <lamont> and fails
[04:55] <ogra> python2.2-xmlbase: Depends: python2.2 (= 2.2.3-10) but 2.2.3-10ubuntu0.1
[04:55] <sjoerd> fabbione: with the ideas we had for encrypted stuff, it shouldn't be possible for somebody to mount it without a password..
[04:55] <ogra> ubuntu0.1 ???
[04:56] <pitti> fabbione: how that problem would look like if people work on a console rather than under X?
[04:56] <pitti> fabbione: i. e. if you don't have $DISPLAY (which cannot be trusted anyway)
[04:57] <sjoerd> HrdwrBoB, pitti: for 441, you should be able to do it at a gvm level (so only one person has it automagically mounted).. if people do it manually with pmount then it's a social problem imho
[04:57] <HrdwrBoB> sjoerd: yeah
[04:57] <HrdwrBoB> I think it's a g-v-m problem
[04:58] <pitti> but checking at the g-v-m level does not increase any trust (security-wise)
[04:58] <fabbione> pitti: on console hmmm 
[04:58] <fabbione> you don't have that problem on that environment
[04:58] <pitti> the check must be done within pmount
[04:58] <HrdwrBoB> pitti: it's not trustworthy anyway since you can simply pmount it
[04:58] <fabbione> because only one user can have console
[04:58] <HrdwrBoB> it just means that my default it won't automount other peoples stuff
[04:58] <HrdwrBoB> by
[04:58] <sjoerd> pitti: it depends on what problem your solving.. just the usability one or do you also want the same security as in a real seperated situation
[04:58] <dholbach> -> dogwalk
[04:59] <pitti> sjoerd: I think you really can't have the same security
[04:59] <HrdwrBoB> the security has to be in pmount or not at all
[04:59] <HrdwrBoB> otherwise you can always call it manually
[04:59] <sjoerd> pitti: correct.. i don't think you can solve the last problem
[04:59] <lamont> mvo_: does not reproduce with 0.6.29 for me.
[04:59] <pitti> fabbione: if we drop the security issue and just concentrate on the correct (untrusted) mapping, is that sufficient?
[05:00] <fabbione> pitti: for me it would be sufficient to get the correct icon on the correct dekstop
[05:00] <sjoerd> if you have a fool mounting your usb stick before you, just whack him on the head :)
[05:00] <pitti> fabbione: then we can just map $DISPLAY -> USB hub in g-v-m
[05:00] <mvo_> lamont: cool, thanks. I close it then. If you see it again, please just let me know
[05:00] <fabbione> pitti: ok.. that makes sence to me
[05:00] <fabbione> pitti: can you hint me on how to do that?
[05:00] <pitti> fabbione: or, rather USB hub -> display
[05:00] <lamont> ok.
[05:00] <fabbione> pitti: remember that i can use hotplug to generate proper events
[05:01] <pitti> fabbione: I can implement it, but we have to precisely define where and what we map (and where to configure it)
[05:01] <fabbione> and i have THAT power
[05:03] <lamont> daniels: how hot and heavy are you to get your evdev fix?
[05:03] <fabbione> lamont: ASAP
[05:03] <lamont> yeah - thought so...
[05:03] <lamont> one of zul's patches is 403, was hoping to get that in as well.
[05:03] <lamont> ZUL!!!
[05:54] <jinty> mdz: ping
[05:54] <dholbach> re
[06:14] <Kinnison> Hi, are there known issues with nautilus and the 2.6.8.1-4-686 kernels in warty?
[06:16] <Treenaks> Kinnison: log out once, with "save my settings" checked
[06:18] <Kinnison> what does that do for me?
[06:19] <pitti> Hi Astharot 
[06:19] <Astharot> bonsoire
[06:19] <Astharot> hi pitti 
[06:19] <Treenaks> Kinnison: it saves your session in some way
[06:19] <Treenaks> Kinnison: and it tends to un-break nautilus
[06:20] <Kinnison> Okay, I'll try that later when I don't have so much context waiting
[06:26] <trulux> pitti: how's going the work on hardened kernels?
[06:27] <pitti> trulux: it's next to zero, I don't have enough time for it
[06:34] <trulux> pitti: then you could give me the task
[06:34] <pitti> trulux: sure, go ahead
[06:34] <pitti> trulux: right now there are two major issues:
[06:34] <pitti> trulux: the kernel images don't contain firmware images (so many device drivers won't work)
[06:34] <trulux> I have experience with it: http://cvs.debian-hardened.org/cgi-bin/viewcvs/debian-hardened/kernel-2.6.7-dh/
[06:34] <pitti> trulux: and the vesa framebuffer is broken
[06:34] <trulux> pitti: why?
[06:35] <pitti> trulux: if I knew why, I had fixed it :-)
[06:35] <trulux> what happens to vsefb.c?
[06:35] <pitti> well, I didn't investigate it
[06:35] <trulux> vesafb.c
[06:35] <trulux> pitti: what happened to it?
[06:35] <pitti> dunno, I did not mess it up deliberately
[06:35] <pitti> maybe the grsecurity patch affects it
[06:36] <trulux> yeah, but it depends 
[06:36] <pitti> trulux: you can take the source packages from people.ubuntu.com/~pitti/linux-hardened/
[06:36] <trulux> grsec itself has nothing to do with low level drivers
[06:36] <pitti> trulux: or just branch my arch repo
[06:36] <trulux> ok
[06:36] <trulux> pitti: I'm still not a Ubuntu maintainer, but I've read the policy and such
[06:37] <trulux> pitti: http://cvs.debian-hardened.org/cgi-bin/viewcvs/debian-hardened/kernel-2.6.7-dh/HARDENING?rev=1.3&content-type=text/vnd.viewcvs-markup
[06:37] <trulux> pitti: that's how *we* must handle hardened kernels
[06:37] <trulux> we *must* specify in sources what changed
[06:37] <trulux> from vanilla
[06:42] <trulux> pitti: who would want to sponsor me in fron of the board to be a maintainer candidate?
[06:43] <pitti> trulux: you need to do some uploads before I can do that
[06:43] <pitti> trulux: i. e. if Ubuntu gets ssp pacakges or improved hardened kernel packages
[06:43] <pitti> trulux: then I can sponsor you
[06:44] <mdz> morning
[06:44] <mdz> jinty: pong
[06:45] <pitti> Hi mdz
[06:45] <jinty> hey mdz
[06:45] <jinty> morning!
[06:45] <jinty> it's about the schooltool packages...
[06:49] <trulux> pitti: ok, give me a roadmap and I will fill it
[06:49] <T-Bone> lamont: ping?
[06:49] <trulux> better, I will remove entries from it
[06:49] <lamont> T-Bone: ack
[06:50] <pitti> trulux: there is no roadmap
[06:51] <pitti> trulux: do whatever you like (fix the hardened kernels, e.g.)
[06:52] <jinty> mdz: later sometime then, cheers
[06:52] <mdz> jinty: what about them?
[06:54] <marcin_ant> hi - any Eclipse user here?
[06:54] <jinty> wait, i think doko may take care of it for me, I'll come back if i need something else
[07:04] <trulux> pitti: we need a roadmap
[07:04] <trulux> we need to know where our feet should walk
[07:04] <trulux> or we will get lost
[07:04] <pitti> trulux: well, fix the outstanding issues, upload into universe soon
[07:05] <pitti> trulux: they should be uploaded very quickly, we are already past feature freeze
[07:05] <pitti> trulux: but since the packages are in universe, we can still add new ones
[07:05] <pitti> trulux: once they are in universe, the outstanding issues shuold be fixed
[07:06] <pitti> mdz: what do you think about uploading the hardened kernels and linux-hardened-support into universe?
[07:07] <mdz> pitti: as long as no changes to packages in main are required, universe can still receive new packages and features
[07:07] <pitti> mdz: no, the pacakges are entirely self-hosting
[07:08] <pitti> elmo: ping
[07:09] <pitti> mdz: btw, could you test the latest hpoj crack?
[07:10] <mdz> pitti: is there a version newer than 0.91-3ubuntu3?
[07:10] <pitti> mdz: no, I mean that one
[07:10] <zul> ok im back...problems with users at work
[07:10] <pitti> mdz: that was the version that installs the usermap and hotplug script
[07:10] <mdz> pitti: that's the version I tested
[07:11] <mdz> it works fine
[07:11] <pitti> cool
[07:11] <pitti> mdz: time for main then?
[07:11] <mdz> pitti: yes
[07:11] <pitti> mdz: okay, I update the seeds.
[07:12] <pitti> supported, I think, right?
[07:12] <mdz> yes
[07:12] <mdz> maybe we can find a way to move it into desktop post-hoary
[07:12] <mdz> mvo_: ping?
[07:12] <mvo_> mdz: pong
[07:12] <mdz> mvo_: hpoj gave me an idea
[07:13] <mdz> mvo_: there are some pluggable devices which require/recommend certain software to be used
[07:13] <mdz> mvo_: we could set up a hotplug script so that when one of these devices is connected, it creates an update-notifier hook which invites the user to install the necessary package(s)
[07:14] <mvo_> mdz: that sounds pretty cool
[07:15] <trulux> pitti: OK, so, in short, tell me what exactly needs to be fixed in hardened kernels
[07:15] <pitti> trulux: I already did? vesa framebuffer and firmware inclusion
[07:16] <mvo_> mdz: it should be pretty easy with the current infrastructure, synaptic supports non-interactive installs via script and update-notifier can display the needed information. very cool indeed. do we have a list about such devices?
[07:16] <pitti> lamont: did it fail because of the derooting? or in general?
[07:16] <lamont> pitti: failed to bind kind of bitchiness
[07:16] <lamont> what do I need to do to re-root it?
[07:16] <pitti> lamont: install the sid version
[07:17] <lamont> this is a new printer, so no clue what the root cause is...
[07:17] <pitti> lamont: well, grab 0.91-3 from the morgue
[07:17] <mdz> lamont: please help work out the issues rather than re-rooting it
[07:17] <trulux> pitti: what's needed for the firmaware inclusion?
[07:17] <lamont> mdz: not what I meant.
[07:17] <pitti> lamont: sure; I just mean, if -3 works, but 3ubuntu3 not, we should fix that
[07:18] <lamont> once I have it working _AT_ALL_ then I can figure out what change breaks it
[07:18] <pitti> trulux: dunno, the default kernel ships firmware images, but mine doesn't
[07:18] <pitti> trulux: it must be somewhere in the docs (or packaging)
[07:18] <trulux> pitti: who is the guy that maintains those images? elmo?
[07:18] <pitti> trulux: I did not deal with that, I was just notified that they are missing
[07:18] <lamont> mdz: printing works just fine, it's scanning that's still nonexistant in the house
[07:18] <pitti> trulux: fabbione 
[07:18] <trulux> pitti: ok
[07:18] <trulux> fabbione: ping
[07:19] <pitti> lamont: has the device in /proc the right permissions? I. e. 0660 root:scanner?
[07:19] <tritium> trulux, hello
[07:19] <mdz> lamont: printing and scanning are working for me; maybe the test used to set perms doesn't work with your model
[07:19] <trulux> tritium: hey!
[07:19] <lamont> pitti: which file?
[07:19] <mdz> haggai: ping
[07:20] <pitti> lamont: /proc/bus/usb/<hub>/<device>
[07:20] <pitti> lamont: find it out with lsusb
[07:20] <tritium> trulux, did you like the figures?
[07:20] <pitti> lamont: s/hub/bus/
[07:21] <elmo> pitti/kamion: done
[07:21] <pitti> elmo: done what? (try to remember my sync request...)
[07:22] <elmo> awstats
[07:22] <trulux> tritium: yeah, you did a great job
[07:22] <pitti> ah, thanks
[07:22] <lamont> sane-find-scanner 
[07:22] <lamont> found USB scanner (vendor=0x03f0, product=0x3611) at libusb:001:003
[07:22] <lamont>  ls -l /proc/bus/usb/001/003 
[07:22] <lamont> -rw-r--r--  1 root root 170 2005-02-11 22:50 /proc/bus/usb/001/003
[07:22] <lamont> sudo chgrp scanner /proc/bus/usb/001/003 
[07:22] <tritium> trulux, thanks :)
[07:22] <pitti> elmo: can you please sync the following packages, too? netkit-rwho zhcon newspost playmidi
[07:22] <trulux> tritium: I've added also the correspondiong info in Ack. about your new contrib.
[07:22] <lamont> scanimage -L still says no scanner identified
[07:22] <pitti> lamont: chmod 660 ?
[07:22] <elmo> pitti: done
[07:22] <pitti> thx
[07:22] <tritium> trulux, cool, thanks
[07:23] <lamont> pitti: still no love with 664
[07:23] <trulux> tritium: you're welcome again :)
[07:23] <lamont> or even 666
[07:23] <pitti> lamont: hm, then it seems it's not a deroot problem...
[07:23] <pitti> lamont: the whole point of the usermap and hotplug stuff is to set the permissions
[07:24] <lamont> pitti: well, it didn't recognize the device, which would make it the problem if things were otherwise working...
[07:25] <pitti> hmm, that requires knowledge of the sysfs attributes then
[07:25] <lamont> pitti: where do I change to fix the usermap/hotplug stuff?
[07:26] <pitti> lamont: /etc/hotplug/usb/hpoj (script) and hpoj.usermap (device filter)
[07:26] <tritium> trulux, send me the latest revision, if you don't mind
[07:26] <lamont> hrm... as root, sane-find-scanner is a bit more verbose:
[07:26] <lamont> found USB scanner (vendor=0x03f0 [hp] , product=0x3611 [psc 2400 series] ) at libusb:001:003
[07:27] <lamont> but even as root, scanimage -L is unhappy
[07:27] <pitti> lamont: you need the interface id/version (in sysfs)
[07:27] <pitti> lamont: the usermap filters on it
[07:27] <pitti> lamont: or maybe from lsusb -v
[07:28] <pitti> lamont: bInterface{Class,SubClass,Protocol} presumably
[07:29] <trulux> tritium: sure
[07:29] <lamont> interesting... scanner doesn't show up in lsusb output...
[07:29] <trulux> tritium: let me finish some stuff
[07:30] <tritium> okay, please email it since I'm not always at the computer
[07:30] <seb128> mako: around ?
[07:31] <lamont> sorry - case issues
[07:32] <lamont>       bInterfaceNumber        0
[07:32] <lamont>       bInterfaceClass       255 Vendor Specific Class
[07:32] <lamont>       bInterfaceSubClass    204 
[07:32] <lamont>       bInterfaceProtocol      0 
[07:32] <lamont>       bInterfaceNumber        2
[07:32] <lamont>       bInterfaceClass       255 Vendor Specific Class
[07:32] <lamont>       bInterfaceSubClass    212 
[07:32] <lamont>       bInterfaceProtocol      0 
[07:32] <lamont> #1 is the printer, #3 is the mass-storage
[07:32] <pitti> #3?
[07:33] <pitti> #2 you mean?
[07:33] <lamont> it has a camera flash thing
[07:33] <lamont> no, there are a total of 4
[07:33] <lamont> I just didn't bother to paste #1 or #3
[07:33] <lamont> just 0 and 2
[07:33] <pitti> lamont: hm, we don't have 255/212/0
[07:33] <pitti> lamont: look in hpoj.usermap for the recognized combinations
[07:34] <lamont> 0 and 2 are almost certainly the scanner and the fax, in some order
[07:34] <trulux> tritium: ok
[07:34] <pitti> lamont: _if_ your scanner works, then 255/204 and 255/212 (in hex) should be added to the usermap
[07:34] <lamont> hpoj claims to support it - I'm tempted to blame udev next. :-)
[07:35] <pitti> hm, could you please add this combination to the usermap then? and check that it works?
[07:36] <lamont> Feb 12 10:22:37 mix ptal-mlcd: ERROR at ExMgr.cpp:3762, dev=<mlc:usb:probe@/dev/usb/lp0>, pid=28506, e=1, t=1108228957         Couldn't claim interface=2!
[07:36] <lamont> Feb 12 10:22:37 mix ptal-mlcd: ERROR at ExMgr.cpp:2559, dev=<mlc:usb:probe@/dev/usb/lp0>, pid=28506, e=25, t=1108228957         Couldn't set up MLC interface!
[07:36] <lamont> that's what I was getting saturday
[07:37] <lamont> pitti: what should the line look like?  no clue what number is what?
[07:37] <pitti> lamont: copy&paste an existing line
[07:37] <lamont> hpoj             0x0701      0x03f0   0x0000    0x0000       0x0000    0x00         0x00            0x00            0xff            0xd4    0x00               0x00000000
[07:37] <pitti> lamont: the number 0xff is the INterface Class
[07:37] <lamont> that sure looks like 255/212
[07:37] <pitti> s/0xd4/hex(212)/
[07:37] <pitti> oh, it is?
[07:37] <pitti> hmm
[07:38] <pitti> indeed
[07:38] <pitti> sorry
[07:40] <pitti> lamont: can you put some logger debug statements into /etc/hotplug/usb/hpoj?
[07:41] <pitti> lamont: to see whether it is called and whether the DEVICE is right?
[07:41] <lamont> ok
[07:41] <mdz> amu, haggai, Riddell: did you guys read my mail to -devel about the packages which want to move to main for Kubuntu?
[07:41] <mdz> amu,haggai,Riddell: I'd appreciate input from one or all of you on this subject
[07:42] <Riddell> mdz: ubuntu-devel or kubuntu-devel?
[07:42] <mdz> Riddell: ubuntu-devel
[07:44] <mako> seb128: yes
[07:44] <mako> seb128: whats up
[07:45] <mdz> mako: dude
[07:45] <mdz> mako: I made a rad contact this weekend on computer recycling stuff
[07:46] <mako> mdz: dude
[07:46] <mako> mdz: oh yeah?
[07:46] <mdz> totally
[07:46] <mako> let me hear
[07:46] <mdz> can I hand him off to you?
[07:46] <mako> yeah, that sounds awesome
[07:46] <mako> man.. i love computer recycling..
[07:46] <lamont> daniels: should the xorg debconf question about xkb really say "most users should enter 'xfree86'"??
[07:47] <mako> free software + computer recycling + grants/cheap/free computer is like pornogrgraphy for me
[07:48] <amu> mdz: 4674     Feb 11 Matt Zimmerman  ( 107) Kubuntu packages to be promoted to main 
[07:50] <lamont> mako: recycling as in finding new homes for old hardware?
[07:51] <mdz> amu: yes, that is the thread
[07:51] <elmo> grr, WTH is vi-ese for M-% ?
[07:52] <pitti> elmo: what does M-% do?
[07:52] <thom> what does M-% do?
[07:52] <pitti> :-)
[07:52] <ogra> M = meta ?
[07:52] <thom> ogra: yes
[07:52] <elmo> M-x query-replace
[07:52] <pitti> yes, but %?
[07:52] <Treenaks> elmo: %s/something/somethingelse/gc ?
[07:52] <thom> :%s/foo/bar/gc
[07:52] <crimsun> :%s/foo/bar/g
[07:52] <elmo> i.e like, s/foo/bar/, but interactive, asking at each occurence
[07:52] <Treenaks> the "c" does that
[07:52] <crimsun> ah, you need 'c'
[07:52] <elmo> aha, thanks
[07:55] <mdz> mako: ok, sent email
[07:56] <mdz> mako: basically this guy has a facility set up in LA where they handle inventory of donated hardware, they refurbish machines, and people can come and receive both the machine, and have someone show them how to use it
[07:56] <mdz> mako: and he seems to have information about a lot of related organizations, both in the US and internationally
[08:00] <mako> lamont: sort of.. sometimes it actually involves breaking it down and recovering metals
[08:00] <mako> lamont: but usually taking old machines, refurbishing them into new, good machines
[08:00] <lamont> kewl
[08:00] <mako> lamont: there are *so* many old machines.. you'd be amazed at how picky you can be
[08:01] <lamont> mako: where do you think I get _my_ hardware?
[08:01] <mako> lamont: there is this awesome place in portland that takes the old machines, has volunteers take a class where they learn to build computers by building computers.. then they build 10 and take the last one home
[08:01] <mako> lamont: me too.. also my furniture
[08:01] <lamont> mako: if you toss me contact info for them, I think my brother (in portland - well beaverton) might be interested in getting involved
[08:02] <mako> lamont: http://www.freegeek.org/
[08:02] <mako> they stick a debian-based on them, train people on it, before they sell it
[08:02] <mako> they have multiple isp's in portland officially supporting debian now as a result!
[08:03] <mako> it's like a solid waste recylcling + computer shop + vocational training + computer give-away + free software advocacy organization
[08:03] <mako> it's totally awesome
[08:04] <mako> there are a few other freegeek's now i think too.. and some other recyclers are looking at free software as well
[08:07] <amu> mdz: i was never in a closer touch with them, only as a kde build depends, except gpgme, which is a part of Aegypten2, and activ maintained ex. by Werner Koch and Intevation     
[08:08] <mdz> amu: please follow up to the list
[08:08] <mantiena> Hi all
[08:09] <mantiena> mdz, I just lost network connection, so it seems didn't got all your messages
[08:12] <lamont> pitti: works just &T*&) fine on my laptop.
[08:13] <pitti> lamont: well, that's at least partly good news :-)
[08:13] <mdz> mantiena: no, I didn't say anything more to you
[08:14] <lamont> pitti: yeah, something like that
[08:14] <lamont> it means that I keep the scanner
[08:15] <pitti> lamont: you mean that the same scanner works on a different computer?
[08:15] <pitti> okay, THAT's really odd
[08:15] <mantiena> mdz, so, how you suggest to test my d-i component ?
[08:15] <lamont> pitti: the desktop is (1) not fully current hoary :-(, and (2) has really funky USB
[08:16] <crimsun> elmo: would it be possible to sync rox-filer from Sid please?
[08:17] <mdz> mantiena: you asked how I did my testing, and I told you that I boot d-i to test
[08:19] <mantiena> mdz, hehe, this is too slow for me, I'm not debian-installer guru
[08:20] <mantiena> Kamion, maybe you could help me to test my d-i component, which replaces base-installer ?
[08:20] <mdz> Kamion also uses d-i to test d-i components
[08:23] <mantiena> mdz, it's ok to use d-i to test d-i components, but I have problems with starting d-i from chroot environment
[08:32] <seb128> mako: any news about https://bugzilla.ubuntu.com/show_bug.cgi?id=5330 .
[08:32] <seb128> ?
[08:33] <mako> seb128: hm... yes i think we can fix it with fonts and fonts alone let me revive my discussion i was having on this
[08:33] <seb128> mako: k, thanks
[08:39] <mantiena> mdz, btw, there is one problem with casper - currently cas[er select same folder (/target) for mounting filesystem.cloop like d-i. It's not good for installing live CD,  could you use another folder ?
[08:39] <mdz> mantiena: no, not without modifying the other d-i components which use /target
[08:40] <mdz> it was not an arbitrary choice; casper uses /target because it invokes other parts of d-i which expect /target
[08:41] <mdz> mantiena: over the weekend, I wrote several messages to ubuntu-devel about installing from the live CD; you should read those if you are planning to work on it
[08:47] <Mithrandir> thom: re the size of the component selector;  couldn't it be possible to use mod_gzip for the .js files?
[08:56] <thom> Mithrandir: i was wondering about deflating them
[09:03] <mdz> lamont: what's the status of the patch review?
[09:04] <lamont> doh - was going to send out a status saturday night, and fell over into bed.
[09:04] <lamont> I have looked at about 50% of the patches, and divided them up into various buckets
[09:05] <lamont> those buckets include "ask so and so", as well as NOBUGFILED, BRANDING, INIT, etc
[09:05] <lamont> the interesting ones are the NOBUGFILED and XXXPENDING (which could mean NOBUGFILED, or not...)
[09:05] <mdz> lamont: have you started filing bugs for the ones which need it?
[09:06] <lamont> no - was hoping to progress faster, and wanted to get a first sweep through - I'll file bugs today
[09:07] <Kamion> ok, car successfully jump-started, and now off to karate - *sigh* what a day
[09:07] <lamont> http://people.ubuntu.com/~lamont/patch-status
[09:07] <ajmitch> yay, got dsl back after 18 hours
[09:08] <lamont> meanwhile, kernel test build looking pretty good so far - hope to upload that shortly
[09:09] <Kamion> mdz: sorry if you called me and I missed it, today has been ueber-complicated
[09:10] <mdz> Kamion: no problem; if you're free later, let's try to connect then, otherwise tomorrow
[09:11] <lamont> very interesting... xchat grabbed focus, and I can't make it give it back...
[09:11] <Kamion> mdz: ok, will be back at 10ish so we'll see then
[09:11] <Kamion> (er, 2200 UTC)
[09:11] <lamont> but whacking metacity helps...
[09:12] <mdz> the only focus stealing that happens to me is metacity's attempt at focus-stealing-prevention
[09:12] <mdz> which has the opposite effect
[09:12] <dredg> in other news /me  cdbs. that is all.
[09:14] <lamont> mdz: gconf edit, set it to 'strict'
[09:14] <Mithrandir> seb128: any progress on nautilus?
[09:14] <jbailey> dredg: Aww, a heart for cdbs on valentines day.  That's sweet ;)
[09:15] <seb128> Mithrandir: not yet
[09:15] <mdz> lamont: we can't tell our users that
[09:15] <Mithrandir> seb128: have you started debugging or should I
[09:15] <Mithrandir> ?
[09:15] <dredg> jbailey: yeah, elsewhere i've outlawed valentine's day :)
[09:16] <lamont> mdz: very true
[09:16] <lamont> mdz: and the good news is that the stealing code is getting better at not stealing when it shouldn't, for most use cases.
[09:16] <seb128> Mithrandir: I've some idea on which commit could do that, but there is probably not a lot of changes between both version, so if you want to have a quick look feel free
[09:16] <seb128> mdz: when does it happen ?
[09:16] <Mithrandir> seb128: ok, I'll take a look
[09:16] <mdz> seb128: I commented on the bugzilla bug
[09:16] <mdz> with two examples
[09:17] <seb128> k
[09:17] <mdz> https://bugzilla.ubuntu.com/show_bug.cgi?id=3159#c15
[09:17] <dredg> i think the only single app that ever made me want to cry wrt focus stealing was gaim
[09:18] <lamont> what was the meatcity hotkey to iconify everything?
[09:19] <lamont> hrm.. that was painfully reproducible
[09:19] <seb128> mdz: right, gaim issue is due to gaim and I don't get the gt one as said on the bug
[09:20] <lamont> seb128: I'll update my system before I bitch about my pain... :-)
[09:20] <seb128> k :)
[09:20] <mantiena> mdz, which emails I should read ? "Merging Live and Install CDs" ?
[09:21] <mdz> seb128: I wasn't CCed on the bug, so I didn't see
[09:21] <mdz> mantiena: yes
[09:21] <seb128> mdz: k
[09:21] <mdz> mantiena: ignore the ones which are about crazy designs, and focus on the other subthread :-)
[09:22] <mdz> seb128: I cannot reproduce it anymore after a crash+reboot yesterday, perhaps my metacity was old
[09:22] <seb128> mdz: k, so we just have "gaim is crap" :)
[09:22] <seb128> that's not that bad
[09:22] <mdz> what is gaim doing wrong?
[09:23] <ogra> stealing focus
[09:23] <mdz> I have the opposite problem
[09:23] <seb128> mdz: by default metacity doesn't raise nor give the focus, apps have to ask for it
[09:23] <mdz> I have people asking me why I am not responding on jabber, and it is because the jabber window is hidden behind something else, and I never sa wit
[09:23] <mdz> saw it
[09:24] <ogra> no sound notification ?
[09:24] <mantiena> mdz, I don't find any reasons which forbids mounting filesystem.cloop on other folder than /target
[09:24] <mdz> ogra: sound notification only works if I am listening at the exact moment the message arrives
[09:24] <mdz> mantiena: I explained that to you less than an hour ago, in this channel
[09:26] <ogra> mdz: hm, sure...
[09:26] <elmo> jesus christ, the component selectors at almost a Mb
[09:27] <pitti> elmo: ah, that's the reason it takes ages with a modem
[09:27] <mantiena> mdz, you don't explained, at least I don't see any reasons. you don't need to modify any d-i components, only AFAIK casper mounts filesystem.cloop could you give some example which component should be modified if you change filesystem.cloop mount point to other folder ?
[09:28] <mdz> mantiena: localechooser
[09:28] <mdz> mantiena: netcfg
[09:28] <mantiena> mdz, these components runs before casper
[09:29] <mdz> mantiena: you may find this difficult to accept, but I do know what I am talking about with regard to casper
[09:29] <mdz> repeatedly telling me that I am wrong does not help you to understand
[09:29] <mantiena> mdz, I understand, that you know all about casper ;)
[09:29] <mdz> look at /usr/lib/casper/pre.d
[09:30] <mantiena> mdz, I looked at this
[09:31] <mdz> if you looked at it, you would have seen that /target is used in the localechooser and netcfg scripts, at least
[09:32] <mantiena> mdz, hehe, there are no such scripts in casper-udeb, because of this I don't find reasons ;)
[09:33] <mdz> they aren't in casper-udeb
[09:33] <mdz> they are in localechooser and netcfg
[09:33] <mantiena> mdz, now I understand
[09:33] <dredg> :q
[09:33] <mantiena> mdz, it seems ubuntu-installer is more different than debian-installer
[09:33] <dredg> argh
[09:34] <mantiena> s/than/from
[09:40] <mdz> mantiena: casper does not even exist in Debian
[09:49] <mantiena> mdz, I know, I thought that d-i and ubuntu-installer's components are almost identifical, only casper is added in ubuntu ;)
[09:51] <mdz> elmo: look on the bright side
[09:51] <mdz> elmo: dan jacobson will never be able to use our bugzilla
[09:52] <thom> *giggle*
[10:02] <thom> Mithrandir: in answer to your question; no, we can't deflate the javascript
[10:02] <Mithrandir> thom: why not?
[10:02] <thom> Mithrandir: just tried it and it broke horribly
[10:02] <Mithrandir> thom: how so?
[10:02] <thom> no products
[10:02] <Mithrandir> that's kinda bad.
[10:03] <Mithrandir> or a feature, depending on your point of view.
[10:03] <thom> well, it got a lot faster
[10:03] <mantiena> mdz, I've read your emails in ubuntu-devel, but don't find info which I should care :( maybe you could point me on needed letters ?
[10:03] <trulux> sivang: hey
[10:07] <mdz> mantiena: never mind; I don't have time to spend on it.  this feature is something that I am interested in working on for hoary+1, but right now I need to focus on hoary
[10:13] <jdub> ogra: so with the xscreensaver patches
[10:13] <ogra> yup
[10:14] <jdub> ogra: the only bad bit about the old one is that it flashes a bit going from password entry to VERIFYING to APPROVED
[10:14] <ogra> yup, exactly...
[10:14] <jdub> perhaps if it only switched once to either ACCESS DENIED or PASSWORD ACCEPTED (ha ha), it would not be so flashy
[10:15] <thom> could it not say anything for accepted
[10:15] <thom> pretty please
[10:15] <ogra> jdub: i thought about merging them... but currently mdz owns all my spare time ;)
[10:16] <mdz> thom++
[10:16] <mdz> "accepted" is when it gives you your desktop back
[10:17] <thom> persactly
[10:17] <ogra> did you guys see the new patch ?
[10:18] <ogra> jdub: did you send it around ?
[10:20] <mdz> thom: I don't see how we can ship netapplet in its current state
[10:20] <mdz> thom: please give me some good news
[10:20] <Keybuk> netapplet is better than the "LOOK AT ME!  LOOK AT ME!  LOOK AT ME!" network monitor
[10:20] <jdub> ogra: oh, no, i didn't upload it
[10:21] <ogra> jdub: i didnt mean did you package it ;)
[10:22] <ogra> jdub: i think replacing the verifying part wirt the faded dots would be a good thing.... leaving the DENIED as it is and dropping the APPROVED in favor of switching directly to the desktop after the dots fadet
[10:23] <ajmitch> ogra: spicing it up even more?
[10:24] <ogra> ajmitch: dunno if i'll find the time, just trying to find the right way _if_ i got some time left....
[10:24] <zul> later
[10:24] <dholbach> bye zul
[10:24] <ogra> ajmitch: since the flickering isnt to beautiful....
[10:25] <thom> mdz: i know, i'm working on it
[10:27] <thom> mdz: what specific complaints do you have currently?
[10:27] <jdub> ogra: ok, cool
[10:27] <mdz> thom: switching between interfaces or wireless networks seems to stall frequently, with no user feedback
[10:28] <ogra> jdub: ok, i'll put it on my list this way... lets see about my time....
[10:29] <thom> mdz: nod
[10:30] <bluefoxicy> does anyone know of a resource for how to make debs with complex dependencies
[10:31] <bluefoxicy> I don't see it in the debian new maintainer's guide section 4.1
[10:31] <ajmitch> what do you mean by complex though?
[10:32] <mdz> elmo: apparently, logging into the website doesn't work on ubuntu.com, only ubuntulinux.org
[10:32] <mdz> at least that's my experience
[10:32] <bluefoxicy> I want to do something like DEPENDS:  ((policy-grsec && policy-grsec-mypackage-1.0) || !policy-grsec), ((policy-selinux && policy-selinux-mypackage-1.0) || !policy-selinux)
[10:35] <Keybuk> bluefoxicy: it's called "you can't do that"
[10:35] <dholbach> hi azeem
[10:35] <azeem> hi
[10:36] <jdub> mdz: what's the cost of setting up a new germinate?
[10:37] <bluefoxicy> Keybuk:  damn
[10:37] <bluefoxicy> Keybuk:  I want it so that if I install policy-grsec, every package with a grsec policy demands that I install th egrsec policy; and if I remove policy-grsec, every package demands that i remove the policy
[10:38] <bluefoxicy> witohut making the packages depend on policy-grsec
[10:38] <mdz> jdub: I think it's pretty cheap; check with Kamion
[10:40] <Keybuk> bluefoxicy: there's no way to represent that
[10:41] <bluefoxicy> Keybuk:  damn.
[10:45] <Keybuk> however
[10:45] <Keybuk> make all the package grsec policy packages depend on policy-grsec and provide grsec-policy
[10:46] <Keybuk> make policy-grsec depend grsec-policy
[10:46] <Keybuk> make all the packages suggest their grsec policy
[10:46] <Keybuk> actually, the middle is probably a Recommends
[10:47] <mantiena> mdz, btw, why en_ZA.UTF-8, en_GB.UTF-8 and en_US.UTF-8 locales are generated every time when liveCD starts ? it wastes a lot of time on average computers (~1 Ghz, 256 RAM) :(
[10:54] <bluefoxicy> Keybuk:  I want a hard dependency
[10:54] <Keybuk> sorry, I'm too busy smirking to answer that :p
[10:55] <bluefoxicy> in a system with grsecurity, policy-grsec would be what allows programs to actually run; without the policy fragment for the package, no user (even the administrator) could run the program
[10:55] <mantiena> I think we should simply generate needed locales in filesystem.cloop when building CD and /usr/lib/casper/pre.d/15localechooser should just check for missing locale (if user chooses another language) and generate only not already generated locale
[10:55] <bluefoxicy> so the problem of course is that it's really a dependency, not a recommendation (as much as libc6 is a dependency and not a recommendation)
[10:55] <Keybuk> then make it a dependency
[10:55] <bluefoxicy> whereas in an SELInux system, policy-selinux would be enabled, but would be ahard dependency too
[10:55] <Keybuk> or just include the policies in the package
[10:56] <bluefoxicy> too/instead, depending on if your admin is insane
[10:56] <bluefoxicy> Keybuk:  yeah, I thought of including it in the package.  It's possible, but even security devs fuck up
[10:56] <bluefoxicy> imagine "the openoffice policy fragment is fucked.  releasing openoffice.org-2.0-1 with new policy, 180M download"
[10:57] <bluefoxicy> plus that means you can't actually . . .not install the policy
[10:57] <bluefoxicy> which was my goal :)
[10:58] <Keybuk> what's the drawback of installing the policy when you don't need it?
[10:59] <bluefoxicy> just space usage really, unless you're experimenting in  maintaning your own policy (for academic purposes)
[11:00] <bluefoxicy> though, there's LIDS, SELinux, GrSecurity, and RSBAC
[11:00] <bluefoxicy> and DiSec I dunno how they do their policy
[11:00] <Mithrandir> bluefoxicy: that's like "ooo maintainer script is fucked up, 180M download".
[11:00] <bluefoxicy> Mithrandir:  yeah exactly.
[11:01] <Keybuk> make the policies config files
[11:02] <bluefoxicy> heh
[11:03] <jdub> lamont: any movement on inotify crasher?
[11:03] <bluefoxicy> Keybuk:  i don't want to force install 10 policies for 10 macs  :)
[11:03] <lamont> jdub??
[11:03] <lamont> new inotify patch from zul, if that's what you mean
[11:03] <jdub> ok
[11:05] <pitti> hey, there really is somebody whose machine _didn't_ crash due to this? :-)
[11:05] <jdub> yay, grumpy editor likes gthumb
[11:05] <ogra> crash ?
[11:06] <Mithrandir> pitti: what bug?
[11:06] <pitti> ogra: yes, the machine randomly freezed when doing something (or sometimes when doing nothing) with removable drives
[11:06] <pitti> Mithrandir: ^ that one
[11:07] <Mithrandir> I don't use many removable drives on this laptop, so.
[11:07] <ogra> pitti: ah, ok... didnt know it....
[11:07] <lamont> pitti: what's a removable device? :-)
[11:07] <lamont> bad cdebconf
[11:07] <Mithrandir> lamont: hotplug SCA drives.
[11:08] <ogra> hehe
[11:08] <pitti> lamont: one you can bite in without breaking your back when you lift it :-)
[11:09] <lamont> heh.  sometimes
[11:14] <amu> hmm daily-live ( i386 ) has some trouble with booting, Kernel Panic - nit syncing: VFS: Unable to mount root fs on unknown-block(8,3) 
[11:15] <amu> s/nit/not
[11:16] <jdub> seb128: eeek, that crazy screen fadeout thing is in our gksu?
[11:17] <seb128> jdub: yep, but that's easy to change if you want
[11:18] <seb128> we can drop the patch
[11:18] <sivang> hey all
[11:18] <jdub> seb128: would prefer we lost it, it's really extreme ;)
[11:18] <seb128> we have added it because some people were complaining in bugzilla and the list
[11:18] <seb128> now you want to drop it
[11:18] <seb128> grrr :p
[11:18] <seb128> (I don't like it to be honest)
[11:19] <seb128> jdub: BTW since you are here, file monitoring doesn't work with gamin ....
[11:19] <seb128> jdub: ie: try to clear the recent documents in the place menu, or add a gtk bookmark
[11:19] <ogra> jdub: the one from the logout dialog 8O
[11:23] <ogra> n, do not show window decorations, us ??
[11:25] <jdub> seb128: i'll upload without the 0.19 support patch
[11:25] <jdub> seb128: actually
[11:26] <jdub> seb128: have you seen mvo's workaround for single file monitoring?
[11:26] <jdub> seb128: perhaps that's the problem with .recently-used
[11:26] <seb128> jdub: nop, heard about it, but not read the code yet
[11:26] <seb128> jdub: file monitoring is not working
[11:26] <seb128> jdub: that's the issue with recently-used, that's the issue with the bookmarks, etc
[11:27] <jdub> it's working here...
[11:27] <seb128> seriously ?
[11:27] <jdub> i am serious
[11:27] <jdub> i shit you not
[11:27] <seb128> have you tried to clear the recent documents ?
[11:27] <mvo_> jdub: my workaround shouldn't be used :) it's really a hack 
[11:27] <seb128> mvo_: bad guy
[11:27] <jdub> seb128: yeah
[11:28] <jdub> seb128: however
[11:28] <mvo_> oh, wait
[11:28] <seb128> mvo_: you should kick jdub do get gamin fixed instead of cheating
[11:28] <jdub> seb128: now that i test in /tmp, it is not working
[11:28] <seb128> ah ah
[11:28] <jdub> seb128: but it works on stuff in my nfs-mounted homedir :)
[11:28] <jdub> i will remove that patch and see what happens
[11:28] <seb128> perhaps that's a local fs specific bug :p
[11:29] <seb128> I don't think that's the patch
[11:29] <jdub> whatever it is
[11:29] <seb128> mvo pointed the issue with 0.21 or 0.22
[11:29] <jdub> it's caused by the french ;)
[11:29] <seb128> jdub: true :p
[11:30] <seb128> mvo_: BTW metacity doesn't raise your window because that's evil, the goal is to avoid beeing annoyed by app like yours acting in a bad way :)
[11:30] <jdub> no, see, if i restart nautilus after i restart gam_server
[11:30] <jdub> it's fine
[11:30] <jdub> i get notifications in /tmp, for recent documents, etc.
[11:30] <Hwolf> Is there any way to couple two windows together in one virtual window? 
[11:30] <seb128> hum
[11:30] <Kamion> jdub: what do you want out of germinate?
[11:31] <mvo_> seb128: actually I think my use-case is a valid one. I only want a single instance of a application. if that application is already runing and the user tries to start it twice, instead of opening up a new window it opens a existing one. not too evil :)
[11:31] <jdub> Kamion: was wondering what the cost of setting up a new one, alongside ubuntu and kubuntu would be, but only for a livecd (this is not at all crucial)
[11:31] <seb128> mvo_: yeah, but you should give the focus too, so you don't use the right function with gdk_raise_window () :)
[11:31] <jdub> mvo_: i agree
[11:31] <mvo_> jdub: I noticed that too, if the gam_server is killed/restarted it seems to work again
[11:32] <mvo_> seb128: I with gtk_window_present() now :)
[11:32] <jdub> mvo_: monitoring in general, or the single-file monitoring bug you had?
[11:32] <seb128> jdub: killall gam_server gnome-panel doesn't fix it here, and running GAM_SERVER=1 gnome-panel should that it doesn't get an event on the clear 
[11:32] <mvo_> jdub: the single file case IIRC (but I tested it last week, I may be wrong)
[11:32] <Kamion> jdub: "new germinate" <- EPARSE
[11:32] <Kamion> jdub: I think you mean "a new set of seeds"?
[11:33] <seb128> mvo_: correct, I just asked why raise_window () doesn't raise it (BTW that's written in the API, for a top_level windows that's decided by the wm)
[11:33] <jdub> Kamion: sure
[11:33] <seb128> jdub: I'm speaking about monitoring *one* file (ie .recently-used or .gtk-bookmarks)
[11:33] <seb128> jdub: nautilus works fine
[11:33] <jdub> seb128: oh man, i've already cleaned out my recent documents
[11:33] <Kamion> jdub: have a look at what the arch revision kubuntu-devel@lists.ubuntu.com/seeds--hoary--0--base-0 did; it's about that expensive plus ten minutes of my time setting up mirroring and stuff
[11:34] <jdub> seb128: yeah, worked again
[11:34] <seb128> doh
[11:34] <seb128> my box is cursed
[11:34] <Kamion> jdub: (with the proviso that modifying the base seed is, for the moment, not useful)
[11:34] <jdub> heh, ok
[11:34] <seb128> I'm sure that's a bug fr_FR specific, you hate french
[11:35] <seb128> (vuntz has it too)
[11:35] <jdub> Kamion: what will it take to start doing livecd builds from different seeds?
[11:35] <Kamion> jdub: you mean the Hoary live CD, or something else?
[11:35] <Kamion> (the Hoary live CD already uses the casper and live seeds to do different stuff from the install CD)
[11:35] <jdub> seb128: running 2.6.10-16?
[11:36] <jdub> Kamion: new, not-entirely-ubuntu livecd builds from those different seeds
[11:36] <jdub> Kamion: mostly concerned about resources
[11:36] <Kamion> jdub: lamont will need to do different rootfs builds off the different seeds (either different metapackage or just a big apt-get install)
[11:36] <seb128> jdub: 2.6.10-3-k7
[11:37] <Kamion> jdub: and then cdimage needs to do daily builds, etc., so a couple of GB/day churn
[11:37] <jdub> seb128: but -16 package version?
[11:37] <Kamion> jdub: we're not really set up for massively parallel CD building just yet
[11:37] <jdub> Kamion: mmm
[11:37] <Kamion> in particular cdimage really doesn't do proper locking yet ;)
[11:37] <jdub> Kamion: how long does it take to build a rootfs atm?
[11:38] <seb128> jdub: ups, yep
[11:38] <Kamion> jdub: dunno, lamont would probably know
[11:38] <Kamion> the log file doesn't have timestamps
[11:39] <Kamion> daily-live builds on cdimage take ~5 minutes
[11:39] <jdub> ah well
[11:39] <jdub> thanks
[11:40] <Kamion> np
[11:41] <Kamion> in general I'm happy to extend germinate to do pretty much whatever ... I want it to be general. *at the moment* I think it has enough to do all the seeds we might want, but it might not in the future :)
[11:43] <whiprush> jdub: heh, all the ltsp stuff here is running on ubuntu
[11:49] <ogra> troll alert in #ubuntu
[11:52] <pitti> argh
[11:52] <ogra> could someone ban that guy
[11:53] <jdub> whiprush: rockin' :)
[11:53] <jdub> whiprush: at the ltsp booth?
[11:55] <whiprush> yeah, then they're feeding OOo, GNOME, and a few others' thin clients
[11:55] <whiprush> I'll get a coolio Ubuntu desktop pic
[11:56] <jdub> whiprush: wow, nice one :-)
[11:56] <jdub> whiprush: up for doing an ubuntu report? ;)
[11:59] <whiprush> from here? sure.
[11:59] <jdub> whiprush: and one for gnome too? ;)
[11:59] <Mithrandir> CRRAAAAACCCKKK