[12:11] <calc> booted
[12:13] <calc> takes 2 min to X then another 2 min to gnome startup, lol
[12:15] <calc> doesn't look like NM wants to connect to the open ap in ubuntu i386 tribe-3
[12:16] <stgraber> ok, result here are : WPA -> keep asking the key, public -> connected successfully
[12:16] <calc> stgraber: which did you try first?
[12:16] <calc> stgraber: open or wpa?
[12:16] <stgraber> so exact same test results as I had with Kubuntu just before (WPA failed at the beginning and worked after a moment)
[12:16] <stgraber> calc: wpa, then an open, then another wpa
[12:17] <calc> when i tried open first then wpa it didn't work for either
[12:18] <calc> so 1. open (fail) 2. wpa (asked lots of times) 3. open (passed)
[12:19] <stgraber> so looks like we need to try a WPA before being able to connect to open :)
[12:19] <stgraber> funny
[12:19] <calc> yea i think so
[12:19] <stgraber> but I'd prefer being able to connect to WPA rather than public :)
[12:19] <calc> if you can reproduce that on yours as well then it is confirmed
[12:19] <calc> stgraber: i was able to connect to WPA earlier somehow, but not anymore
[12:20] <stgraber> ok, let's me reload NM (both daemon and applet)
[12:20] <stgraber> calc: yes, me too :)
[12:20] <calc> something is really buggy
[12:21] <calc> er now it worked, wtf
[12:21] <calc> beat on it long enough and it starts working for no reason
[12:21] <calc> grr
[12:23] <calc> looks like i am still stuck on feisty for my dev work in a gutsy chroot
[12:24] <asac> stgraber: please try manual wpa_supplicant
[12:24] <asac> stgraber: starting in a fresh state
[12:24] <asac> thats all i can do for network manager
[12:24] <asac> if it works that way ... we should be able to get it work in nm as well
[12:25] <asac> stgraber: you said on amd64 it didn't work at all?
[12:25] <calc> asac: its probably just so flakey that he thought it didn't work at all...
[12:25] <calc> asac: that is what i am seeing here on both i386 and amd64, it rarely works
[12:26] <calc> it seems to somewhat reliably work for open if i try to connect to wpa first
[12:26] <asac> calc: you get ioctrl warnings?
[12:26] <calc> 1. wpa (fail) 2. open (work)
[12:26] <calc> asac: hmm not that i recall, i did get it when trying to force wpa-driver to ipw in network/interfaces before
[12:27] <asac> ah
[12:27] <calc> i don't see any ioctl messages in daemon.log though
[12:27] <stgraber> ok, I had the same behaviour as calc, you can't directly connect to a public AP :)
[12:29] <asac> stgraber: what ap_scan method does nm use (in syslog)
[12:30] <elmo> err - I'm confused
[12:30] <elmo> I just mke2fs'ed a new partition - how do I get it to appear in /dev/disk/by-uuid/ ?
[12:30] <stgraber> asac: AP_SCAN 1
[12:31] <asac> stgraber: if you use the sequence in log manually ... does it work?
[12:32] <stgraber> I just tried with the sequence I pasted before, it works but there is a 2-3 minutes delay before when I try the command and when it finds the AP and connect
[12:33] <calc> stgraber: when it worked for me earlier when doing the manual way it took several minutes as well
[12:33] <asac> stgraber: but it connects at some point?
[12:33] <calc> which seems odd
[12:33] <asac> stgraber: if you look at syslog
[12:33] <asac> nm adds more info to wpa_supplicant
[12:33] <asac> maybe that boosts a bit?
[12:35] <stgraber> asac: NM gives up before wpa_supplicant manage to connect, I'm currently trying with the syslog sequence
[12:36] <stgraber> ok, worked as well after two disconnects and a 1-2 min delay
[12:36] <asac> can you capture a log for that?
[12:36] <asac> i want to see if i can see in code whats going on with wpa_supplicant ... what is it doing all the time?
[12:37] <stgraber> http://paste.stgraber.org/2259 <-- this is the used sequence
[12:38] <asac> line 19-END takes 1+ minutes?
[12:38] <calc> its not doable on a boot cd but would be interesting to see if it was the kernel at fault somehow
[12:38] <stgraber> asac: nope, line 18 to end
[12:39] <stgraber> like if it didn't find the AP before
[12:39] <asac> do you have wpa_supplicant log?
[12:39] <asac> with -dd ?
[12:39] <asac> you only see the fall-out on wpa_cli console
[12:42] <stgraber> asac: http://www.stgraber.org/download/wpa-output
[12:42] <stgraber> asac: this time went faster, don't really know why though
[12:43] <stgraber> faster = 40s to associate which is still a lot (I don't know what is the timeout for nm-applet)
[12:43] <asac> yeah
[12:43] <asac> what the hell does Wireless event: new AP: 00:00:00:00:00:00
[12:43] <asac> mean
[12:44] <asac> stgraber: how many ssids do you have?
[12:45] <stgraber> asac: receiving 5, sometimes 7
[12:46] <asac> 00:14:d1:c0:39:80 ??
[12:46] <asac> thats the one finally connected to?
[12:46] <stgraber> asac: yes
[12:47] <asac> its getting blacklisted multiple times
[12:47] <asac> Added BSSID 00:14:d1:c0:39:80 into blacklist
[12:48] <asac> everytime before that we get a "Wireless event: new AP: 00:00:00:00:00:00"
[12:48] <calc> i got some things about all 0's ap in the wpa_cli
[12:48] <calc> earlier today
[12:48] <asac> somehow like this events prematurately kills our right association attempt
[12:48] <calc> when it failed to assoc
[12:49] <stgraber> yes, I just don't really see where the hell does this 00 AP comes from :)
[12:49] <asac> welll its really just the 00:00:00:00 ping pong
[12:49] <asac> that appears to consume that time
[12:49] <asac> once this ping-pong is stopped by some timeout
[12:49] <calc> and kills the assoc attempts i think as well
[12:49] <asac> it directly connectes
[12:50] <calc> apparently after several minutes
[12:50] <asac> Removed BSSID 00:00:00:00:00:00 from blacklist (clear)
[12:50] <asac> Removed BSSID 00:14:d1:c0:39:80 from blacklist (clear)
[12:50] <asac> i think the timeout is one minute
[12:50] <asac> maybe if you have bad luck you get multiple runs of these
[12:50] <asac> stgraber: can you try to get a long of an attempt that takes longer?
[12:50] <asac> e.g. 2-3 minutes?
[12:50] <elmo> evand: ping
[12:51] <stgraber> asac: I think I may get one if I completely reload ipw3945
[12:51] <calc> asac: i have to leave now :\ but i can work with you more tomorrow if you would like
[12:53] <asac> calc: right ... i will ping you if i need more info :)
[12:53] <asac> thanks!
[12:54] <stgraber> asac: I had a 50s long one with 3 disconnects
[12:55] <stgraber> asac: maybe using the proto, key_mgmt, pairwise and group params make things a bit faster (no need to detect)
[12:55] <calc> asac: it sounds like stgraber has the exact same issue as I am having, so between the three of us we should figure it out
[12:55] <asac> stgraber: ok ... can you try without these details?
[12:55] <stgraber> sure
[12:56] <asac> calc: my feeling is that wpasupplicant is the problem
[12:59] <stgraber> asac: without the settings, it took much time to try to associate for the first time, then it goes pretty fast (only two disconnects)
[12:59] <stgraber> so only a bit more than a minute
[01:00] <asac> you have a log of the long run?
[01:00] <asac> the first?
[01:00] <stgraber> asac: http://www.stgraber.org/download/wpa-output1 <-- 3 disconnects (50s)
[01:00] <asac> stgraber: great
[01:00] <stgraber> asac: http://www.stgraber.org/download/wpa-output2 <-- 2 disconnects (1m)
[01:00] <asac> can you keep those files up for a few days?
[01:00] <asac> i have to sleep now :)
[01:00] <stgraber> sure
[01:00] <stgraber> yeah, me too :)
[01:00] <asac> thanks for your help!
[01:00] <calc> asac: that would make sense, since open ap with dhclient connects immediately
[01:01] <stgraber> yes, this association to 00:00:00:00:00:00 seems to be the problem
[01:01] <stgraber> as blacklisting, unblacklisting and then retrying to connect takes a while
[01:02] <asac> the problem is that it tries to deal with that imo
[01:03] <stgraber> so it shouldn't be arch dependant, that's already a good news :), now it's about finding a patch upstream (if any)
[01:03] <asac> yeah
[01:04] <calc> we could try downgrading to the version in feisty as well
[01:04] <calc> to see if that helps
[01:04] <calc> i tried 0.5.8 which might already have been buggy in that respect
[01:06] <calc> if 0.5.7 is new enough to work with the current kernel, etc
[01:06] <calc> 2007-05-28 - v0.5.8
[01:06] <calc> 	* updated driver_wext.c to build with the current wireless-dev.git tree
[01:06] <calc> 	  and net/d80211 changes
[01:06] <calc> one of the modifications in 0.5.8...
[01:13] <asac> in fact 00:00:00... events are disconnect events from driver
[01:13] <asac> when looking where those are actually handled i found this ...
[01:14] <asac> http://pastebin.mozilla.org/178297
[01:14] <asac> read line 6-10
[01:15] <asac> apparently we run through this ... and full disconnect is scheduled
[01:15] <asac> so for our case its not
[01:15] <asac> wpa_s->key_mgmt == WPA_KEY_MGMT_WPA_NONE
[01:15] <asac> and neither is:
[01:15] <asac> #
[01:15] <asac> wpa_s->wpa_state == WPA_4WAY_HANDSHAKE &&
[01:15] <asac> #
[01:15] <asac>             (wpa_s->key_mgmt == WPA_KEY_MGMT_PSK ||
[01:15] <asac> #
[01:15] <asac>              wpa_s->key_mgmt == WPA_KEY_MGMT_FT_PSK)
[01:17] <stgraber> asac: there's also line 25
[01:18] <stgraber> asac: which seems to be about this 00:00:00:00:00:00 ssid
[01:18] <asac> yes ... but that is just a rescan scheduling
[01:18] <asac> in case it was associated
[01:18] <asac> at least i think it is ... should be ok
[01:18] <asac> ... though it might consume time
[01:19] <asac> hmmm ... that is about bssid
[01:24] <asac> maybe we should just ignore disconnect events when associating
[01:24] <asac> and instead hope for a timeout to kick in
[01:28] <evand> elmo: pong
[01:29] <elmo> evand: unping
[01:29] <asac> stgraber: can you try this ugly patch for wpasupplicant?
[01:29] <asac> stgraber: http://people.ubuntu.com/~asac/test_ignore_disconnect.patch
[01:30] <stgraber> yes
[01:36] <stgraber> asac: I made a dpatch and I'm currently updating my pbuilder
[01:37] <asac> ah ok
[01:37] <asac> i think you could have just patches against unpacked source tree ... but well :)
[01:37] <asac> its safer this way
[01:41] <stgraber> asac: compile failed
[01:41] <asac> can you fix it?
[01:41] <stgraber> it's about the events.c file
[01:42] <asac> yeah tell me the line and error
[01:42] <stgraber> http://paste.stgraber.org/2260
[01:42] <asac> oh
[01:42] <asac> yeah ... go to the patch
[01:42] <asac> add a { at the end of the line
[01:42] <asac> of the if
[01:42] <asac> you see that?
[01:43] <asac> stgraber: should look like the if line below
[01:43] <stgraber> oh, didn't see it while working on the patch :)
[01:43] <asac> good
[01:44] <asac> i updated the patch http://people.ubuntu.com/~asac/test_ignore_disconnect.patch
[01:44] <asac> in case
[01:44] <asac> but just edit the patch in place ;)
[01:47] <stgraber> ok, compiled and installed
[01:48] <asac> doe it break everything?
[01:48] <asac> :)
[01:54] <asac> stgraber: any update?
[01:54] <stgraber> asac: seems like disconnects has been replaced by timeout
[01:54] <stgraber> but no association anymore
Authentication with 00:00:00:00:00:00 timed out.
Trying to associate with 00:14:d1:c0:39:80 (SSID='graber-wifi' freq=2412 MHz)
[01:55] <stgraber> it already did that 8 times
[01:58] <asac> ok
[01:58] <asac> what state are you in?
[01:58] <asac> do you see that in supplicant log?
[01:59] <asac> is it ASSOCIATING?
[01:59] <asac> or SCANNIG?
[01:59] <stgraber> I see that in wpa_cli
[01:59] <stgraber> it seems to be ASSOCIATING
[02:00] <stgraber> it does : DISCONNECT -> SCANNING -> ASSOCIATING (looking at the wpa_supplicant window)
[02:01] <stgraber> then start again at DISCONNECTED (once the MAC is blacklisted)
[02:09] <asac> stgraber: ok ... i have to go :) ... many thanks.
[02:09] <stgraber> asac: np :), ping me when you have a new wpa_supplicant to test
[02:24] <ash211> Can someone please take a look at bug 127551?
[02:24] <ubotu> Launchpad bug 127551 in Ubuntu "[feisty]  dpkg-reconfigure xserver-xorg: failure because of missing package xresprobe" [Undecided,New]  https://launchpad.net/bugs/127551
[02:25] <ash211> Why would xresprobe be in the LiveCD but not the Alternate?
[02:30] <mneptok> because the alternate never invokes X
[02:30] <mneptok> but it should still install it
[02:31] <mneptok> [mneptok@set]  mneptok :: which xresprobe
[02:31] <mneptok> /usr/sbin/xresprobe
[02:31] <mneptok> ^^ installed from alternate ^^ (but Feisty)
[02:48] <mneptok> ryanakca: is it necessary?
[02:48] <ryanakca> mneptok: http://blog.ryanak.ca/archives/40
[02:49] <ryanakca> Sysadmin Appreciation Day, stop in to say thanks :D
[02:50] <mneptok> yeah, i don't think making the channel a target of spambots and kids wanting help with Apache is a great way to say thank you ;)
[02:50] <crimsun> while the thought would be appreciated, I would err on the side of caution.
[02:50] <mneptok> buy beer. it's meaningful.
[02:50] <mneptok> :)
[02:50] <ryanakca> Okies then. *snips it out*
[02:51] <ryanakca> mneptok: better?
[02:51] <mneptok> smells like home cookin' :)
[03:07] <wick2o> hello
[03:07] <wick2o> i have found something missing with the hylafax-server package
[03:08] <wick2o> I'm not sure who/where would be best to give the info too
[03:09] <wick2o> in the setup.cache file there is a BASECONFIG='/usr/bin/uunecode'
[03:09] <wick2o> it SHOULD be BASECONFIG='/usr/bin/uuencode -m [03:10] <wick2o> the package wont forward any attachments if this isnt changed
[03:10] <wick2o> i just spend 8 hours troubleshooting this issue
[03:11] <soren> wick2o: https://launchpad.net/ubuntu/+source/hylafax/+filebug
[03:12] <wick2o> thank you soren
[03:12] <Vorbote> wick2o: as hylafax is in universe, you may find a more sympathetic audience in #ubuntu-motu as as well as filing a bug
[03:12] <wick2o> k
[03:13] <wick2o> Just tring to save some other people the hassle of what i had to do today
[06:31] <calc> i have an issue
[06:32] <calc> how do i do an and statement in shell
[06:32] <calc> eg
[06:32] <calc>  [ -s $$f (and) ! -h $$f ] 
[06:33] <Hobbsee> calc: it seems [ -s $$f -a ! -h $$f ]  from man test, if i'm reading it right
[06:33] <Hobbsee> calc: may need to put brackets around each expression, though
[06:34] <StevenK> -a is frowned upon
[06:34] <StevenK> [ -s $$f ]  && [ ! -h $$f ] 
[06:34] <Hobbsee> there you go, StevenK can answer then
[06:34] <calc> ok
[06:34] <Hobbsee> i was wondering about that, though
[06:34] <calc> thanks :)
[06:34] <calc> i couldn't find -a in bash manpage so that was why i had to ask
[06:34] <calc> i thought it was something like -a but wasn't certain and didn't want to break this code, heh
[06:35] <StevenK> calc: man test
[06:35] <StevenK> not bash
[06:35] <ajmitch> since [ is special & all
[06:35] <ajmitch> weird unixy stuff
[06:35] <calc> StevenK: ah ok
[06:35] <StevenK> [ is a symlink to test :-)
[06:36] <ajmitch> StevenK: symlink?
[06:36] <StevenK> Hrm, I thought it was
[06:36] <calc> a symlink apparently counts as a regular file as far as -s is concerned
[06:36] <ajmitch> doesn't appear to be so now
[06:36] <calc> duh i mean -f
[06:37] <calc> so i changed it to -s and ! -h to see if that helps
[06:38] <calc> grr it still doesn't do what i want, how is this getting by my test
[06:40] <calc> http://pastebin.com/d5a36c142
[06:40] <calc> any ideas about how symlinks are getting uuencoded?
[06:42] <calc> does that code look correct?
[06:45] <calc> hmm actually it is working i am too tired or something
[06:45] <calc> its working perhaps too good
[06:45] <Mithrandir> personally, I much prefer -L to -h, but that might just be me.
[06:54] <calc> i forgot the thing i was trying to encode was in the orig.tar.gz oops
[06:54] <Mithrandir> Hobbsee: bad Hobbsee!
[06:54] <Hobbsee> Mithrandir: i'm not bad!  *looks around innocently*
[06:58] <ajmitch> Hobbsee: sure, you've convinced me *cough*
[06:58] <infinity> StevenK: You're lucky they're up at all, don't complain.
[06:58] <calc> is there a way to use test to check if the beginning of a filename matches some chars?
[06:58] <calc> eg if filename starts with src680 ignore the file
[06:59] <StevenK> infinity: :-P
[06:59] <StevenK> calc: case
[07:09] <calc> StevenK: http://pastebin.com/d223cfa88
[07:09] <calc> StevenK: is that what it should look like
[07:09] <calc> StevenK: i thought it would work like that but for some reason it still ends up encoding the src680 files
[07:10] <calc> er is what i thought it should look like
[07:10] <StevenK> $$f might not start with src680
[07:11] <StevenK> *src680*, perhaps?
[07:11] <StevenK> Morning pitti
[07:11] <calc> ah ok, yea it probably starts with src/src680
[07:11] <calc> thanks for the help! :)
[07:11] <pitti> Good morning
[07:12] <ajmitch> hi pitti
[07:13] <pitti> hey ajmitch
[07:13] <calc> that worked
[07:14] <Hobbsee> ajmitch: :P
[07:14] <Hobbsee> morning pitti
[07:15] <Hobbsee> mneptok!
[07:15] <mneptok> where?!
[07:34] <Hobbsee> @btlogin
[08:00] <pitti> doko: two glibc uploads every day? :-)
[08:03] <doko> pitti: fixing bugs at a fast pace =)
[08:05] <pitti> doko: don't feed the buildds too much, lest they get too fat :-)
[08:56] <kt`> hola!
[08:56] <kt`> anyone around
[08:57] <Hobbsee> perhaps
[08:57] <kt`> :o
[08:58] <kt`> I have a few questions relating to Pulp.
[08:58] <\sh> happy sysadmin day to all of you :)
[08:58] <kt`> heh
[08:58] <kt`> it is sysadmin day
[08:59] <stdin> kt`: http://www.sysadminday.com/ :)
[08:59] <kt`> im there :P
[08:59] <kt`> i searched it when he said that was there before the link :D
[09:00] <kt`> anywho, anyone familiar with Pulp?
[09:02] <asac_> hi all
[09:04] <kt`> hi
[09:09] <soren> There's a quite vocal discussion on the ubuntu-server mailing list about people wanting separate repositories for server packages to make it clearer which packages are covered by the 5 years of support in our LTS releases. Could someone who has been around a bit longer than I perhaps shed some light on the issues?
[09:09] <soren> Is it just the packages in http://people.ubuntu.com/~ubuntu-archive/germinate-output/dapper/server that are covered, or is it "server installations"?
[09:10] <stdin> soren: all the packages in the "main" repository are covered by the LTS suppost
[09:10] <ajmitch> afaik, it's the packages in the server seed for the 5 year support
[09:10] <Mithrandir> stdin: no, that's not correct.
[09:10] <soren> stdin: Yes, but LTS means 3 years for desktop and 5 years for servers.
[09:10] <ajmitch> but I don't have any more info than you do, I suspect :)
[09:10] <Mithrandir> stdin: that is, not all of them are covered with a 5 year support guarantee.
[09:10] <soren> Mithrandir: It's not?
[09:11] <soren> Mithrandir: Ah, right.
[09:11] <ivoks> there is no disctinction betwean server and desktop packages
[09:11] <soren> ivoks: That's always been my impression, too.
[09:11] <soren> ivoks: I've always thought it was "server installations".
[09:11] <ajmitch> ivoks: no visible distinction, but I've consistently heard that it's seed-based - best to ask the canonical support crew
[09:12] <stdin> Mithrandir: which aren't?  I thought that main was the officially supported repo?
[09:12] <soren> ajmitch: I suppose.
[09:12] <ajmitch> soren: "server installations" is suitably vague, as we've seen on the lsit
[09:12] <ivoks> for next LTS, this could be solved trough 'Section'
[09:12] <Mithrandir> stdin: firefox for instance is not supported for five years.
[09:13] <ivoks> or... another header for packages
[09:13] <kt`> anyone familiar with Pulp?
[09:14] <ajmitch> ivoks: it wouldn't be hard to do more binary package mangling for selected packages, if it's worthwhile
[09:15] <ivoks> i think it is
[09:15] <ivoks> people ask support related questions on mailling list
[09:15] <ivoks> and with additional header it would be possible to inform admin that packages are not longer supported
[09:16] <ivoks> just an idea...
[09:30] <pitti> hey mvo!
[09:32] <mvo> hey pitti
[09:38] <soren> pitti: How would you make the distinction between which packages to support (in terms of security fixes) for 5 years vs. 3 years? The server seed?
[09:39] <pitti> soren: I don't have a very good idea about this ATM; server seed germination is obvious, but there might be more that we need to support
[09:40] <pitti> soren: pretty bad that we did not talk about this when releasing dapper
[09:40] <pitti> soren: in theory we could probably demote everything that is not supported any more to universe in dapper, but that would be really hackish
[09:40] <soren> pitti: Quite. There's a bit of discussion on this subject going on on the ubuntu-server mailing list, and I'd like to be able to give some sort of clear answer, but I haven't got it. :(
[09:41] <pitti> this deserves an in-depth discussion at next UDS IMHO, since it is not trivial to define and communicate
[09:41] <soren> Are you subscribed to the ml?
[09:41] <pitti> no, I'm not
[09:41] <soren> Ok.
[09:44] <ivoks> Tonio_: hi
[09:45] <Tonio_> hey ivoks :)
[09:45] <Tonio_> ivoks: how are you ? such a long time we didn't discuss ;)
[09:46] <ivoks> Tonio_: busy as hell :/ finishing my faculty and working \; no time for anything :) how are you?
[09:47] <Tonio_> ivoks: working as hell, no time for anything :)
[09:47] <Tonio_> ivoks: welcome to the capitalist world :)
[09:47] <ivoks> hehe
[09:48] <ivoks> been there for some time already :)
[09:48] <Tonio_> well the point is that my new job is based at 200 km from home, so that's kinda hard to loose so much time in the train....
[09:48] <ivoks> with TGV that's 5mins ;)
[09:51] <Tonio_> ivoks: dream on, no TGV from Orlans to Paris
[09:51] <Tonio_> ivoks: just a stupid TER train......
[10:16] <cjwatson> soren: the clear answer is "if you have doubts, talk to your contacts in the Canonical support department"
[10:16] <cjwatson> Mithrandir: test -L is clearer, but test -h is more portable (if you care about Solaris, which many people don't; of course then you have to forgo test -e as well)
[10:17] <infinity> Does anyone actually still care about portability to Solaris's braindead shell?
[10:18] <Hobbsee> oh uni site, i hate thee...
[10:18] <soren> cjwatson: Sure, but the perception in the community seems to be that it's the packages on the server CD and nothing else, and that seems to stop them from using Ubuntu (becuase they need software not on the CD).
[10:18] <ivoks> CD's should be called 'install CD'
[10:19] <cjwatson> soren: that's certainly incorrect, but I don't think it's up to anyone else to tell the support department what they're going to support, so the right answer's always going to be to contact support in case of doubt
[10:19] <cjwatson> infinity: I hope not
[10:20] <cjwatson> but it's a reason why some people still have the test -h habit
[10:20] <Hobbsee> clearly they havent heard of the idea of "put the important stuff in bold / bigger / otherwise different" from the help files, and other unimportant stuff.  and actually leaving whitespace on the webpage.
[10:21] <soren> cjwatson: I agree, but if this perception is as common as it seems to be, it's something we should handle somehow. Just being more clear than "free security updates and commercial technical support
[10:21] <soren> will be available for three years on the desktop, and five years on
[10:22] <soren> the server" (From Dapper's release announcement) will help a lot.
[10:22] <soren> What the..
[10:22] <soren> will be available for three years on the desktop, and five years on the server" (From Dapper's release announcement) will help a lot.
[10:22] <soren> ffs..
[10:22] <soren> cjwatson: I agree, but if this perception is as common as it seems to be, it's something we should handle somehow. Just being more clear than "free security updates and commercial technical support will be available for three years on the desktop, and five years on the server" (From Dapper's release announcement)  will help a lot.
[10:24] <cjwatson> soren: I don't have a problem with being more specific, but it should be the support team making the statement (preferably in the form of a modified web page on www.ubuntu.com or something) rather than distro team staff
[10:28] <soren> cjwatson: Good point.
[10:32] <soren> cjwatson: Well.. It's still going to affect the security team, as I suspect the period of time the support team will support a package will have to correspond to the period of time the security team will support it.
[10:32] <soren> cjwatson: I'll talk to support about it.
[10:39] <lifeless> whats the right way to get 'cryptsetup' to work from within a udev rule ?
[11:03] <siretart> lifeless: there has been a bit of discussion in Sevilla about this
[11:04] <siretart> lifeless: I think we'll need some password manager frontend (ideally one console only and a graphical one) for secure typing of your password
[11:05] <siretart> lifeless: the udev rule would detect that it has to mount a crypted device, connects/starts up the password frontend and tries to mount
[11:06] <siretart> lifeless: In my opinion, (I'm not sure if Keybuk agreed with me here), it should be possible to provide a path to a keyfile in /etc/crypttab, so that you can have your home volume encrypted with a keyfile stored on a usb stick
[11:10] <lifeless> siretart: well, /etc/crypttab should not be needed
[11:10] <lifeless> when /etc/fstab is populated with guids
[11:12] <lifeless> then cryptsetup makes the volid for /home or /root etc appear, so udev rules that mount as volumes become available in fstab, will just work
[11:14] <soren> How does vol_id make sure that the guid stays the same for encrypted filesystems? With LUKS, there's a superblock with meta-info about the filesystem, but using plain cryptsetup it just looks like gibberish, doesn't it? AFAIK, there's no metainformation about the volume at all.
[11:14] <siretart> lifeless: err, and how would you specify the path to your keyfile in /etc/fstab?
[11:15] <siretart> lifeless: and btw, you are aware that the current cryptsetup package in debian/ubuntu already uses a /etc/crypttab?
[11:16] <lifeless> siretart: I know it claims to use one, however have you looked closely at what it tries to do? its madness
[11:16] <lifeless> soren: I only care about luks
[11:16] <lifeless> soren: also, you have two volume ids: the volid of the encrypted partition; and the volid of the decrypted partition
[11:17] <lifeless> the volid of the former is the volid of e.g. /dev/sda1, AIUI that comes from the partion table no?
[11:19] <soren> lifeless: No, vol_id looks at the contents.
[11:19] <soren> lifeless: Otherwise it'd be a bit hard to make i globally unique, I guess.
[11:19] <lifeless> soren: meh, I'm using the wrong terms perhaps. the GUID - that appears happily stable for luks fs's.
[11:20] <soren> lifeless: Imagine two users with identical hard drives both selecting "guided partitioning" in the installer. They'd have identical partition tables.
[11:20] <soren> lifeless: Yes, because LUKS keeps a GUID in the LUKS superblock.
[11:20] <lifeless> ok, cool.
[11:21] <soren> lifeless: vol_id first tries to detect what sort of block device it's looking at (disk, generic partition, raid partition, vfat partition, ext3 partition, etc.) and the uses a special GUID generation algorithm based on that.
[11:22] <lifeless> btw, two users selecting guided partitioning would not end up with the same exact partition table on more exotic disklabels where the whole thing is GUID driven
[11:23] <soren> lifeless: It has to, really, because it needs to be globally unique, while staying static for a particular block device, and since different types of block devices keep their static bits in different places (ext3 has the superblock in the beginning of the volume (IIRC), while a pv for lvm has its pv superblock at the end.
[11:23] <lifeless> soren: sure, I can see what vol_id needs to do; I've just never felt the need to read the source.
[11:24] <soren> lifeless: Probably not, I was just illustrating why basing GUID on partition table info would be insufficient.
[11:24] <soren> lifeless: I wish I could say the same. :)
[11:24] <lifeless> a simpler example btw would be to say 'dd /dev/sda1 /dev/sda2 && dd /dev/zero /dev/sda1' is defined as moving where the guid points at
[11:27] <Mithrandir> (dd if=/dev/sda1 of=/dev/sda2 or dd < /dev/sda1 > /dev/sda2)
[11:27] <siretart> lifeless: I'm currently using current crpytsetup's /etc/crypttab. for the simple case (luks and password from terminal) it is surely overkill
[11:27] <siretart> lifeless: I wonder how you want to manage the keyfile case
[11:27] <lifeless> Mithrandir: meh, I'm still recovering
[11:28] <lifeless> siretart: the keyfile contains a password right ?
[11:28] <siretart> lifeless: the keyfile IS the password. only longer
[11:28] <siretart> (yes)
[11:30] <lifeless> siretart: well, its either a passphrase, or a private key I guess?
[11:30] <siretart> lifeless: exactly
[11:31] <lifeless> siretart: I would suggest /etc/cryptkeys/GUID
[11:31] <siretart> actually, it can be both. you have up to 8 keyslots IIRC
[11:31] <siretart> lifeless: and if you want it to place on a removable media?
[11:32] <lifeless> siretart: so there are two cases here
[11:32] <lifeless> udev finds the crypted partition before the removable media exists
[11:33] <lifeless> and thus inserting the removable media needs to trigger decryption of the crypted partion
[11:33] <lifeless> second case:
[11:33] <lifeless> removable media is inserted/found first, so udev should decrypt the crypted partition as it finds it
[11:33] <lifeless> is this for a user partition, or for something for all users
[11:33] <lifeless> ?
[11:34] <siretart> I think both crypted  home and crypted shared data volumes are possible here.
[11:35] <siretart> (with crypted share data might even be the rootfs)
[11:35] <lifeless> right, my root is crypted
[11:36] <lifeless> anyhow
[11:36] <lifeless> cheap answer:
[11:37] <lifeless> ln -s /media/FOO/keyfile /etc/cryptkeys/GUID
[11:37] <siretart> well, if we agree that we need a password entering frontend, well, I think that would be the natural place to look for keyfiles on removable media, no?
[11:37] <siretart> can you ensure that a usb stick gets always mounted on the same mountpoint?
[11:38] <lifeless> ln -s /dev/by-id/GUID/keyfile /etc/cryptkeys/GUID2
[11:38] <lifeless> oh, I agree that we need password entry
[11:38] <lifeless> I don't use external keyfiles myself; just need the ability to enter a password from inside a udev rule
[11:39] <siretart> the symlinkery should indeed work
[11:39] <siretart> we 'just' need to make sure that usb sticks get either mounted automatically in initramfs, or make the frontend mount them
[11:39] <siretart> what would you prefer?
[11:40] <lifeless> well
[11:40] <lifeless> for me, I don't care about the external media, so suit yourself.
[11:40] <lifeless> :)
[11:40] <siretart> we are talking about breaking users systems, you know?
[11:41] <lifeless> I'd like to see a simple setup like mine so easy and robust its default in 2 or 3 releases
[11:41] <lifeless> crypto for all
[11:41] <lifeless> external media keyfiles are not simple enough to explain to mom n pop
[11:41] <siretart> but the symlinkery idea sounds really sane to me.
[11:41] <lifeless> cool
[11:42] <lifeless> I'm happy to help you with your preferred setup; just noting its not what I'm actually *aiming at*
[11:42] <siretart> as said, we 'just' need to make sure it gets mounted in initramfs, I'm not sure how hard that will be
[11:42] <lifeless> udev rules FTW
[11:43] <siretart> special rules for initramfs usage only. on a real system, we hal et. al
[11:43] <siretart> ok, cool. glad to hear you are working on that! :)
[11:44] <lifeless> working, well not so much. At this point knowing there is a missing link is useful though;
[11:59] <Tonio_> seb128, pitti: I'm a bit lost on that build with the buildd... https://launchpad.net/ubuntu/+source/knetworkmanager/1:0.2-1ubuntu2
[11:59] <Tonio_> seb128, pitti: only fails for i386 for a reason I can figure out....
[12:00] <Tonio_> seb128, pitti: local i386 build works in pbuilder btw, so it looks like a buildd server config issue, but I'm unsure....
[12:00] <seb128> maybe give a build retry
[12:01] <Tonio_> seb128: should I reupload for this or can you or someone else relaunch the build ?
[12:01] <seb128> pitti can
[12:02] <Tonio_> seb128: oki ;) lett's wait for pitti then
[12:02] <infinity> I can.
[12:02] <Tonio_> infinity: so can you please ?
[12:02] <infinity> That doesn't look lik a buildd issue to me.
[12:03] <Tonio_> infinity: well the error is a bit weird, as it just worked with others architectures..... that's why I'm a bit lost....
[12:03] <infinity> I'll retry it for kicks, but that looks like a bug to me.
[12:03] <Tonio_> infinity: packaging bug ?
[12:03] <infinity> Timestamp skew messing with the way autoconf gets run, I suspect.
[12:04] <Tonio_> infinity: interesting.... so autoconf is only called with i386, causing the issue....
[12:04] <Tonio_> infinity: then I suspect missing +x flag on scripts due to diff.gz can cause the issue
[12:05] <Tonio_> infinity: I'll try to chmox +x the scripts within rules and we'll see....
[12:06] <StevenK> infinity: Ping. Any news about libnss-db?
[12:07] <infinity> StevenK: lpia's consumed all my time, so far, but I'm stuck in a London timezone still (jetlag and I are having "words"), so I have plenty of workday ahead. :)
[12:08] <StevenK> infinity: Heh
[12:08] <infinity> Tonio_: The retry may magically work (it all depends on if one gets the timestamp skew required to force autoconf to run), but the bug will resurface.
[12:09] <infinity> Tonio_: If you don't want autoconf running, read the autotools-dev readme, and so something about the timstamp skew in debian/rules.
[12:12] <Tonio_> infinity: well I may try to fix the packaging so that autoconf doesn't crash when called..... I'm pretty sure that's just due to the scripts addition in diff.gz, missing executable flag
[12:13] <Tonio_> infinity: that weird, but due to tarball issue..... would be easier to rebuild it in fact (what I may do if that still fails after next upload)
[12:13] <StevenK> Hrm. Hopefully libc6 build sparc the second will finish soonish
[12:14] <Tonio_> infinity: best is to get the tarball fixed upstream I guess :)
[12:16] <infinity> Tonio_: Timestamp skew isn't a tarball issue, really (unless you count "not using AM_MAINTAINER_MODE" as a tarball issue)
[12:18] <Tonio_> infinity: I know, but appart from the Timestamp thing, autoconf shouldn't crash when called right ?
[12:18] <infinity> Tonio_: Oh, well, yeah, it would be nice if it was executable, I suppose. :)
[12:18] <Tonio_> infinity: timestamp skew is causing autotools to be called, that's the point, but that doesn't explain the crash...
[12:19] <Tonio_> infinity: hehe, I just missed that adding admin/ entry in diff.gz would loose the +x flag in fact :)
[12:19] <Tonio_> infinity: and debian packaging can't be merge due to universe dep to get admin/ entry copied
[12:20] <Tonio_> infinity: that's why I have to do all that crap to make it to work..... I'll probably just rebuild the tarball and ping upstream for nice tarball in the future, instead of doing crap packaging....
[12:29] <cjwatson> pitti: bug 62986 is another possible candidate for 6.06.2
[12:29] <ubotu> Launchpad bug 62986 in debconf "edgy installer randomly hangs on Core 2 Duo, Dell D620" [High,Confirmed]  https://launchpad.net/bugs/62986
[12:30] <pitti> doko: any idea about the lib32gcj things on http://people.ubuntu.com/~ubuntu-archive/testing/gutsy_probs.html ?
[12:31] <pitti> cjwatson: indeed, thanks for digging it out; it's the "Retry flock() on EINTR" bit, I assume?
[12:31] <cjwatson> no
[12:31] <cjwatson>   * Make sure that apt status commands and debconf protocol commands under
[12:31] <cjwatson>     debconf-apt-progress are properly interleaved. Closes: #425397
[12:31] <pitti> ah, that one
[12:31] <cjwatson> always assuming that it actually works
[12:32] <pitti> cjwatson: there's no patch attached, I take it it's reasonably unintrusive?
[12:32] <cjwatson> retry-flock-on-EINTR was for problems I saw occasionally on the live CD
[12:32] <pitti> cjwatson: I had lots of fun with EINTR in Python programs; that's one of the nasties things I ever saw :/
[12:32] <cjwatson> but that's in Feisty already
[12:33] <geser> can someone look at the apache2 build failure? http://launchpadlibrarian.net/8577358/buildlog_ubuntu-gutsy-i386.apache2_2.2.4-2_FAILEDTOBUILD.txt.gz
[12:33] <geser> it fails nearly at the end with "dpkg-deb: building package `apache2-mpm-worker-dbgsym' in `../apache2-mpm-worker-dbgsym_2.2.4-2_i386.ddeb'.", "objcopy: debian/apache2-dbg/usr/lib/debug/usr/sbin/apache2-mpm-worker: Invalid operation"
[12:33] <pitti> geser: oh, noes, that one again
[12:34] <pitti> geser: I'll have a look later
[12:34] <geser> thanks
[12:34] <pygi> siretart, poke
[12:34] <cjwatson> pitti: unfortunately the patch is rather large
[12:35] <pitti> cjwatson: TBH I don't feel qualified to judge an installer patch; if it backports well and works in gutsy, and you are convinced about it, I take your work for it; it does seem quite nasty, given the server focus
[12:36] <cjwatson> pitti: http://launchpadlibrarian.net/8582373/debconf.r2214.diff
[12:36] <pitti> s/your work/your word/
[12:36] <cjwatson> problem is that I've never been able to reproduce it, so I'm not *giving* my word until I've got some affected people to test it
[12:36] <cjwatson> just wanted to let you know it was on the radar
[12:37] <pygi> siretart, going to eat now, but please poke me when you get time
[12:37] <pitti> cjwatson: ok, thanks for the heads-up
[12:37] <geser> can an ubuntu-main-sponsor look at bug #128614? this should make libtritonus-java build on amd64
[12:37] <ubotu> Launchpad bug 128614 in libtritonus-java "[Sync Request]  Sync libtritonus-java_20070428-3 from Debian unstable (main)" [Undecided,New]  https://launchpad.net/bugs/128614
[12:40] <pitti> geser: it's an universe package, so you can ack it yourself
[12:42] <geser> pitti: because I only looked at the source portlet in the bug itself where is still main
[12:42] <pitti> geser: it's new in gutsy, it might have accidentally been synced to main and moved l ater
[12:42] <geser> seems so
[12:58] <StevenK> Neat. I haven't seen a buildd say that before.
[12:58] <StevenK> "NOT OK : Builder returned BUILDERFAIL when asked for its status"
[12:58] <alesan> I am trying to fix what I think it is a bug or at least an incorrect behaviour in ubuntu:
[12:58] <alesan> basically when you have multiple (remote) X displays and you plug in a USB key that key gets assigned to a random user/session
[12:59] <alesan> I think it should be always assigned to the local user
[12:59] <alesan> do you have an idea where I could play with options like this?
[01:03] <infinity> StevenK: Hardcoded path to /usr/bin/bunzip2 in buildd scripts disagrees with the Debian maintainer's brilliant plan to move bzip2 from /usr to / without linking it.
[01:03] <infinity> StevenK: Or, rather, he linked it, it broke on Hurd, he removed the link, and provided no migration path.
[01:03] <infinity> StevenK: And we seem to have absorbed the bug and done nothing about it either.  Go us.
[01:05] <iwj> Why would it use an absolute path anyway ?
[01:05] <infinity> iwj: Oh, it really shouldn't, and I'm fixing that in my LP branch (not my code, don't shoot the messenger), but moving binaries willy-nilly is still sick n' wrong.
[01:06] <iwj> I think it's perfectly sensible and that's what PATH is for.
[01:07] <seb128> iwj: hi. Should I do a MIR for consolekit or do you want to do it since you started looking at it?
[01:07] <iwj> There's one drafted already although I don't think it's finished.
[01:07] <iwj> I'm still playing with it and will MIR when I'm done.
[01:07] <iwj> It's looking quite good, though.
[01:08] <seb128> ok, good, thanks
[01:11] <cjwatson> whoa, what set my gdm theme to debian-moreblue?
[01:11] <Mithrandir> cjwatson: unsure, but I saw the same this morning
[01:12] <alesan> it seems I should configure gnome-volume-manager to assign usb keys to a fixed X session, any idea how to do that?
[01:14] <seb128> cjwatson: I've fixed the bug this morning with 2.19.4-0ubuntu3
[01:14] <iwj> cjwatson: Welcome to current gutsy :-).
[01:14] <iwj> Oh, too late!
[01:16] <seb128> cjwatson: I've merged gdm with the new Debian packaging (we didn't merge for some cycles since the debian version used to have everything in the diff.gz and that was manageable), the merge was not trivial and I might have make some small mistakes like this one
[01:18] <pitti> alesan: you can't do that with current g-v-m
[01:19] <alesan> pitti, what do you mean? is current version not implementing that but a later revision?
[01:19] <alesan> or is it just not possible
[01:19] <pitti> alesan: it's not possible
[01:20] <pitti> alesan: USB devices are always mounted as the owner of the current foreground X session
[01:20] <alesan> well, ... any possible workaround
[01:20] <alesan> ?
[01:22] <cjwatson> seb128: ah right, thanks
[01:23] <cjwatson> evidently my mistake was running apt-get upgrade relying on the automatic update :-P
[02:05] <hunger>  /etc/pam.d/[kg] dm is reading /etc/default/locales now. Where is that file created? I don't have it and some apps complain about a not existing locale setting.
[02:05] <Hobbsee> MOTU meeting in #ubuntu-meeting for anyone interested
[02:06] <doko> pitti: not built anymore, should be removed from the archive
[02:09] <pitti> doko: weird, it doesn't appear in archive-cruft-check
[02:11] <pitti> doko: gcc-defaults builds lib32gcj-bc
[02:11] <doko> ahh, ok, will remove it for the next upload
[02:11] <pitti> doko: and gcj-4.1 still builds lib32gcj7-dev
[02:12] <pitti> doko: great, thanks
[02:13] <cjwatson> hunger: /etc/default/locale (no s) is created by the installer. It's a bug either that [gk] dm don't fall back to /etc/environment, or that the file isn't created on upgrade, I'm not sure which.
[02:26] <pitti> Tonio_: shouldn't network-manager-kde Conflicts:/Replaces: knetworkmanager?
[02:27] <Kano> hi, when will be fuse 2.7.0 in ubuntu? it is in sid...
[02:28] <Kano> i already reported a bug
[02:28] <Kano> waiting
[02:28] <doko> iwj: the gij memory problems should be fixed with the last of the glibc uploads
[02:28] <Kano> Hobbsee: i think it was 2 days before
[02:29] <seb128> Kano: there is no bug on launchpad abou tit
[02:29] <Tonio_> pitti: hum true, indeed... as I changed the naming of the package to sync with debian....
[02:29] <Kano> seb128: you can be sure that there is one, as i added it
[02:29] <Tonio_> pitti: sorry for the error, fixing this now
[02:29] <pitti> Tonio_: I binary-NEWed it for now, but fixing appreciated
[02:29] <seb128> Kano: well, it has not been confirmed and ubuntu-archive has not been subscribed if you prefer
[02:29] <cjwatson> bug 128292
[02:29] <ubotu> Launchpad bug 128292 in fuse "fuse 2.7.0 needed to fix issues with ntfs-3g and uuids in fstab" [Undecided,New]  https://launchpad.net/bugs/128292
[02:29] <cjwatson> (to save anyone else looking it up)
[02:30] <Kano> seb128: when i report a bug it is confirmed (by myself)
[02:30] <Tonio_> pitti: thanks, will upload the fix in a couple of minutes
[02:30] <cjwatson> seb128: ubuntu-archive shouldn't be subscribed since there are Ubuntu modifications and a developer needs to merge them
[02:30] <seb128> Kano: somebody should do the new version merge
[02:30] <seb128> cjwatson: yeah, I misread what Kano was saying, I though he was waiting for a sync to be processed
[02:31] <pitti> mvo: we have another pending tzdata SRU; I'd appreciate if you could handle that: bug 123366
[02:31] <ubotu> Launchpad bug 123366 in langpack-locales "Update to tzdata 2007f" [High,Fix committed]  https://launchpad.net/bugs/123366
[02:31] <Kano> so lets see if it is in tomorrow. thats one major package
[02:32] <Kano> as it is in main
[02:33] <Kano> there have been same issues before for feisty and the needed update (a cvs snapshot with same fix) did not get in. therefore feisty was unusable for ntfs-3g + uuid
[02:33] <seb128> Kano: not likely to be there tomorrow if nobody does the merge
[02:34] <Tonio_> pitti: you'll hate me but can you please drop the upload I've done 1 minute ago...
[02:34] <seb128> Kano: and there is no hurry, gutsy is still unstable for some months
[02:35] <Kano> btw. when will aufs used? every day there is another tool broken in live mode on amd64
[02:35] <Kano> it was sudo, then date...
[02:36] <Kano> Hobbsee: the bugs are major for me
[02:37] <Hobbsee> Kano: how about you go and do the merge, and subscribe ubuntu-main-sponsors when you've done it, seeing as you're clearly a linux expert, and very interested.
[02:37] <Kano> when you dont use ntfs-3g then not for you
[02:37] <mvo> pitti: will look at it
[02:37] <Hobbsee> Kano: the co-author of kantonix should surely be able to process a merge, instead of whine repeatedly on a development channel, which will likely get him ignored due to immense painfulness.
[02:38] <cjwatson> Kano: thank you for your report. Full ntfs-3g integration is on the feature schedule for gutsy, so it's already on the list. However the people involved have other urgent things they're working on so we cannot promise you that it will be fixed tomorrow.
[02:39] <Kano> cjwatson: well tomorrow is not the problem, but next week would be fine
[02:39] <cjwatson> I'll link your bug from the spec so that it doesn't get forgotten
[02:39] <cjwatson> I can't promise next week either. Feature freeze is a few weeks from now
[02:39] <Kano> btw. i patched every avm driver that is downloaded by the fixed avm script
[02:40] <Kano> the current restricted modules package is not that clear. i reported a few bugs against that too
[02:40] <cjwatson> (https://wiki.ubuntu.com/WriteSupportForNTFS)
[02:40] <Hobbsee> Kano: with patches, and did you subscribe ubuntu-main-sponsors after  the patches were applied?
[02:40] <Kano> Hobbsee: i just added the file to one bug report
[02:42] <Kano> the restricted modules is one package i do not fully understand. how these half build modules are made
[02:42] <Hobbsee> Kano: you may want to see https://wiki.ubuntu.com/MOTU/Sponsorship/SponsorsQueue.  it is the universe one, but most applies to main too.  this will make sure that your fixes get in quicker, and will get you a lot further than just whining about how $yourpetbug hasnt been fixed.
[02:42] <Hobbsee> that applies to any bug, not just the restricted modules.
[02:42] <cjwatson> pitti: good news is that debconf-apt-progress at least doesn't appear entirely buggered in gutsy ...
[02:43] <Kano> Hobbsee: instead of fixing the restricted modules i updated a kanotix avm package, the used getscript is the same also i use a combined patch to fix 2.6.22 issues
[02:44] <Kano> Hobbsee: i test the ubuntu kernel on etch, recompiled with some fixes
[02:44] <Hobbsee> Kano: l-r-m, and kernel stuff is in #ubuntu-kernel.
[02:44] <Hobbsee> Kano: but updating fuse would be useful.  thankyou for effectively volunteering to do it.
[02:45] <Kano> when you want ntfs-3g even as mount.ntfs then you need it
[02:45] <Hobbsee> then i'll mentally thank you for fixing it, and contributing to ubuntu development in that way.
[02:45] <Hobbsee> as will the other users.
[02:47] <Kano> for ntfs there must be some things broken currently in kde, is it due to those preparations?
[02:47] <Kano> like when you use ntfs usb drives
[02:47] <Kano> you get an error when you are not root. same for linux filesystems, only fat works
[02:49] <Kano> will try your hal...
[02:50] <iwj> doko: Oh, good.
[02:50] <Chipzz> alesan: I think your idea is fundamentally broken
[02:51] <Chipzz> alesan: there is no such thing as "the logged in user"
[02:51] <Chipzz> not when it needs to be strictly defined
[02:51] <doko> iwj: a bug fixed eight months ago on FC, but never forwarded upstream to glibc 2.6 branch or trunk :-/
[02:51] <Chipzz> consider fast user switching, or starting 2 X sessions from the console
[02:52] <Chipzz> who's session does the usb key get mounted in?
[02:52] <Chipzz> *whose
[02:53] <alesan> Chipzz,
[02:53] <Chipzz> or maybe nobody is logged in at all
[02:53] <Kano> Hobbsee: in the write support for ntfs i see no mentioned kde changes?
[02:53] <Kano> only gnome?
[02:53] <alesan> Chipzz, well current's Ubuntu behavior *is not* good for a multiuser system
[02:54] <Hobbsee> Kano: i dont know.  i dont follow ntfs-3g development
[02:54] <alesan> Chipzz, it basically auotmount a usb disk based on which X session has foreground at that moment.
[02:54] <Chipzz> which, given the alternatives, is the most sane solution I'ld say?
[02:56] <alesan> Chipzz, well that is a problem, the quick and dirty solution is the user that is logged in on the local X display. Or maybe make this configurable.
[02:56] <alesan> or, at least, mount the device with "open" permissions to all users :)
[02:57] <Chipzz> there'll always be cases where that solution breaks, so there is no perfect solution I'ld say
[02:57] <Chipzz> oh btw
[02:57] <Chipzz> another use case
[02:58] <Chipzz> (quite marginal, but hey)
[02:58] <Chipzz> multi-seat
[02:58] <Chipzz> (2 keyboards/mouse/screens)
[02:59] <alesan> actually, this resembles our situation, we have 6 seats for every PC using a special PCI card
[03:00] <alesan> still, a "master" seat could be defined
[03:00] <alesan> afk?
[03:00] <ScottK> Away From Keyboard.
[03:03] <hunger> Is there an example of /etc/default/locale available somewhere so I can copy it onto my system?
[03:04] <Chipzz> back
[03:06] <alesan> Chipzz, the soultion imho would be that those messages should appera on a configurable display, not on a random one :(
[03:07] <geser> hunger: my /e/d/l has only a LANG variable set (the same as in /etc/environment)
[03:12] <soren> Our current udev ruleset doesn't have a rule that automatically mounts a removable device when inserted (given it has a proper UUID=-style entry in fstab and all that), does it?
[03:15] <Chipzz> alesan: the most sane solution to me sounds like using a keyboard with built-in usb hub, and assign devices according to the hub toi which they're attached to
[03:19] <alesan> Chipzz, our solution does not allow to use such (uncommon) thing
[03:21] <alesan> a very good solution for me would be not to start gnome-volume-manager for the remote X sessions
[03:21] <alesan> but only for the local one
[03:26] <pygi> hunger, poke?
[03:27] <alesan> how do I stop gnome-volume-manager to be started?
[03:28] <pygi> hunger, please poke when you are around, thanks
[03:33] <siretart> pygi: you're poking quite some ppl today, no? ;)
[03:34] <pygi> siretart, well, yes, people shouldn't just sit around and drinking *insert some beverage* :)
[03:35] <pygi> siretart, how are you?
[03:36] <pygi> I've got a lot of mails from our dear friend today ... and wanted to make sure you know about it. I also wanted to warn people not to respond to his attacks (like hunger did)
[03:38] <pygi> s/drinking/drink
[03:39] <hunger> pygi: poke.
[03:39] <hunger> pygi: That schilli guy?
[03:39] <pygi> hunger, may I suggest for most part that you ignore the replies from schilli?
[03:39] <hunger> pygi: OK.
[03:40] <pygi> hunger, thanks ;)
[03:40] <hunger> pygi: If that helps you.
[03:42] <pygi> siretart, you disappeared again :(
[03:42] <siretart> yes
[03:42] <pygi> hunger, there's just no point in argument :P
[03:42] <pygi> siretart, o well, poke if you ever come to life
[03:43] <siretart> pygi: coworker visted my, I'm in my office
[03:43] <hunger> pygi: Is that the cdrecord guy?
[03:43] <pygi> siretart, no worries, we'll talk later
[03:43] <pygi> hunger, yup
[03:43] <pygi> siretart, you just enjoy
[03:43] <siretart> pygi: about what? cdrecord?
[03:43] <pygi> siretart, yup
[03:43] <siretart> pygi: sorry, I still didn't have time to analyse the source
[03:44] <pygi> siretart, don't worry about the source now, it's something else
[03:44] <siretart> what?
[03:44] <pygi> siretart, I ain't pushing you, don't worry ... we'll get it sorted =)
[03:44] <hunger> pygi: Thought so:-( I just found the idea of me upgrading to some code from out of ubuntu so ridiculous that I could not stop myself from replying.
[03:44] <pygi> siretart, well, the fact that I got cca. 50 mails from schilly on launchpad?
[03:44] <pygi> siretart, just wanna somehow make sure nobody responds there
[03:45] <pygi> hunger, don't worry ;)
[03:45] <siretart> pygi: on launchpad? as in bugmail?
[03:45] <siretart> pygi: can you give me some bugnumbers?
[03:45] <pygi> siretart, as in that, yes
[03:45] <pygi> siretart, sure, gimme a sec (but please dont respond anything)
[03:46] <doko> pitti: please demote gnat-4.2-doc libgnatprj4.2
[03:46] <pygi> siretart, 69603, 65700, 66710, 45939, 60710
[03:46] <pygi> how many more do you want?
[03:47] <siretart> bug 69603
[03:47] <ubotu> Launchpad bug 69603 in cdrtools "can't burn cd's at all" [Undecided,New]  https://launchpad.net/bugs/69603
[03:47] <siretart> pygi: can you try to make sure they all appear here: https://bugs.launchpad.net/~ubuntu-burning?
[03:48] <pygi> siretart, yup
[03:49] <pygi> siretart, cdrecord bugs/u-burning can be seen here as well, but I get your point:
[03:49] <pygi> https://bugs.launchpad.net/~ubuntu-burning/+packagebugs-search?field.distribution=ubuntu&field.sourcepackagename=cdrtools&field.status=New&field.status=Incomplete&field.status=Confirmed&field.status=Triaged&field.status=In+Progress&field.status=Fix+Committed&search=Search
[03:52] <pygi> siretart, it's basically all of "his" software bugs that have comments on them
[03:53] <pygi> brb soon
[03:54] <soren> He's telling people to not use the Ubuntu packages?
[04:06] <pygi> soren, yes
[04:12] <soren> pygi: How rude.
[04:13] <pygi> soren, haha :)
[04:13] <pygi> persia, lemme look it up
[04:14] <pygi> ah, yes
[04:14] <pygi> persia, sadly that bug (and similar) are not without mistakes and wrong assumptions as well
[04:15] <persia> pygi: Completely agreed.  Just an example of why argument is not always constructive.
[04:16] <pygi> persia, I do plan to write a "letter" of some kind or something, just dunno yet where to post it since I've got no blog
[04:20] <Amaranth> soren: he always does that
[04:21] <pygi> Amaranth, please, let's not go into discussion
[04:21] <Amaranth> For him to support your setup you have to be using kernel 2.4.x with ide-scsi emulation
[04:21] <Amaranth> oops, too late
[04:21] <pygi> everything is under control, so don't worry
[04:25] <pygi> Amaranth, oh well
[04:26] <pygi> Amaranth, people have been using his tools for 20 years, so a little respect
[04:26] <Amaranth> I didn't know cd burners were even that old
[04:27] <pygi> In 2006 we were celebrating the 20th anniverary of the scg driver and libscg
[04:27] <pygi> In the first week of August 1986, I created the world's first SCSI generic pass-through system
[04:28] <Amaranth> In 1986 I was busy being born. :)
[04:29] <pygi> I wasn't born back then yet =)
[04:29] <pygi> Amaranth, you didn't had time for exploring that system then, right? :)
[04:30] <Tonio_> pitti: I had to rebuild the tarball for knetworkmanager to workarround an upstream problem in the tarball structure. Debian workarrounded adding a builddep to a kde template package, but I can't do that since it is in universe
[04:31] <pitti> AssertionError: Wrong bugreport Expression (bug #124360)
[04:31] <ubotu> Bug 124360 on http://launchpad.net/bugs/124360 is private
[04:31] <Tonio_> pitti: in order not to crap the packaging I decided to rebuild the tarball, but I can't seem to be able to upload now due to different md5sum..... is there a way to workarround this ?
[04:31] <pitti> oh, that would be it
[04:31] <pitti> slightly confusing error message, though
[04:31] <Amaranth> pitti: yeah, that tripped me up about 3 times
[04:31] <Tonio_> pitti: I don't want to crap the packaging in order to fix a crap tarball in fact ^_^
[04:31] <tkamppeter> hi pitti
[04:32] <pitti> Tonio_: you need a new upstream version
[04:32] <pitti> Tonio_: patching doesn't work?
[04:32] <pitti> hi tkamppeter
[04:32] <Tonio_> pitti: damn......
[04:32] <tkamppeter> pitti, did you succeed to set up and manipulate print queues with the s-c-p now?
[04:33] <Tonio_> pitti: can be done that way, indeed, but I then have to make files executable in debian/rules, rebuild the makefiles etc.......
[04:33] <pitti> tkamppeter: no, as I said, it doesn't even connect
[04:33] <Tonio_> pitti: the all admin/ folder is missing which is very problematic for a kde app
[04:33] <pitti> tkamppeter: oh, hmm, seems to work today; it didn't yesterday
[04:33] <tkamppeter> Has your cupsd.conf a line "Listen *:631" or "Port 631"?
[04:33] <Tonio_> pitti: debian uses a kapptemplate package, which I synced, but the build can't perform since there is a dep in universe...
[04:34] <tkamppeter> pitti, did you do an auto-update between yesterday and today?
[04:34] <Tonio_> pitti: I'll try to get a fixed tarball, but as this is an opensuse thing, I don't expect a release just today, just for me....
[04:37] <pitti> tkamppeter: yes
[04:38] <tkamppeter> pitti, then there was perhaps some buggy library which someone has fixed (not me).
[04:40] <mwolson> siretart: around?
[04:40] <pitti> tkamppeter: yeah, maybe *shrug*
[04:40] <pitti> hi thekorn
[04:40] <pitti> thekorn: unping then
[04:41] <tkamppeter> So with queue manipulation working you are now in a good state, once to investigate usability (see especially my bug reports on LP), porting the method for restarting CUPS after a cupsd.conf change from g-c-m, plug'n'print with hal-cups-utils.
[04:42] <thekorn> pitti, I promise you will never get that bad error messages in the future, but a '403' instead :)
[04:42] <pitti> thekorn: ah, sweet :) thanks
[04:42] <pitti> thekorn: I don't care much about the current trunk, if it's all good in your's
[04:43] <thekorn> pitti: I'm almost done with the chages, but need to add some documentation
[04:45] <elcuco> hi, who handles this page? https://wiki.ubuntu.com/LoCoTeamList
[04:45] <Hobbsee> elcuco: elkbuntu does, i suspect
[04:45] <alesan> I've heard from the gnome developers that gnome-volume-manager has the concept to only start for the local console
[04:46] <elcuco> the reason i am asking, is that i am part of the loco-team-hebrew, and i was not aware that the ubuntu-il.com site is an official site of my team
[04:46] <alesan> it seems ubuntu doesnt not honor this or there is a misconfiguration
[04:46] <alesan> in fact, gnome-volume-manager is started for all displays
[04:46] <elcuco> it seems that i am missing something
[04:46] <elcuco> elkbuntu: ping?
[04:46] <pitti> alesan: right, but it only considers events from the currently active display in Ubuntu
[04:46] <pitti> alesan: the latest upstream version doesn't do this
[04:46] <pitti> alesan: it'll happily race with all active g-v-m's
[04:47] <pitti> alesan: we patched the Ubuntu version to look at the foreground console
[04:49] <alesan> pitti, let me understand better.
[04:49] <alesan> I give you an example
[04:49] <alesan> I have on this machine one standard X display, :0.0, and 6 other display
[04:50] <alesan> I use a speacial device from www.ncomputing.com
[04:50] <pygi> hunger, :P
[04:50] <alesan> whenever I insert a USB key in the host, a *random* terminal takes possession of it
[04:50] <alesan> the other displays show a error message
[04:50] <pitti> alesan: ah, right; neither the latest upstream nor Ubuntu version has a particuarly good solution for that ATM
[04:51] <alesan> pitti, on a gnome channel I've been told gnome-volume-manager has the concept to only run for the local console user
[04:51] <pitti> alesan: it'll hopefully get better soon when consolekit support gets released in Gnome
[04:52] <pitti> alesan: maybe in the svn head version, I didn't check it; not in 2.17.0
[04:52] <pitti> alesan: I don't know the details, but if you have six parallel X servers which are all active and 'foreground', and local, then no automatic mechanism can tell where the usb device should pop up
[04:53] <pitti> alesan: that's a mapping you can only define yourself
[04:53] <alesan> pitti, I would like the popup on the local display, :0.0
[04:53] <alesan> where should I define that mapping in your opinion?
[04:54] <pitti> alesan: as I said, there's no support for that yet
[04:54] <elkbuntu> elcuco, pong?
[04:54] <pitti> alesan: only hackish solution is to stop g-v-m on the other X sessions
[04:55] <elcuco> elkbuntu: hi, some questions about loco teams, do you have some minutes?
[04:55] <elkbuntu> elcuco, loco discussion happens in #ubuntu-locoteams
[04:55] <elcuco> kk, moving
[05:14] <pitti> mvo: the bug submitter in bug 123062 replied; is that helpful for figuring out why python-apt fails to determine a source package?
[05:14] <ubotu> Launchpad bug 123062 in apport "apport-gtk crashed with AssertionError in __setitem__()" [Undecided,Incomplete]  https://launchpad.net/bugs/123062
[05:16] <LaserJock> cjwatson: I've got an app-install-data-edubuntu package uploaded with the data to make that change to the Edubuntu Addon CD
[05:16] <LaserJock> I just need it in Main *cough* pitti *cough*
[05:17] <pitti> doesn't sound too scary
[05:17] <LaserJock> cjwatson: I can send you a patch to debian-cd, does that sound ok?
[05:17] <cjwatson> LaserJock: yes
[05:17] <LaserJock> pitti: it's not scary at all
[05:18] <pitti> doko: is the interface in bug 125551 suitable for you? if so, I'll start hacking on it
[05:18] <ubotu> Launchpad bug 125551 in gcc-4.2 "Support for gcc ICEs" [Wishlist,Triaged]  https://launchpad.net/bugs/125551
[05:19] <PHPnerd> hello
[05:21] <doko> pitti: <executable name> would be cc1/cc1plus?
[05:22] <doko> I would keep the temporary file (that's the current behaviour)
[05:22] <pitti> doko: any executable that exists and is shipped in the package which is actually at fault (like gcc-4.1)
[05:23] <doko> ok
[05:23] <pitti> doko: cc1 is cpp-4.1, not gcc-4.1, but the source package is the same, so it doesn't matter that much
[05:23] <pitti> doko: I only need it to determine the package, then its version, and its dependencies, etc.
[05:24] <pitti> doko: wrt. file vs. pipe, I'll support both; it's trivial to implement
[05:24] <doko> pitti: I'll keep the file.
[05:24] <pitti> doko: if you think executable name is not appropriate, and you have something else which identifies the package/version, I'm all ears
[05:24] <doko> no, that's ok
[05:25] <pitti> doko: I just thought that argv[0]  would be easy enough for you to get and for me to process
[05:25] <pitti> great
[05:26] <doko> pitti: fine, and how to catch reports, when gcc is run in a chroot? ;)
[05:26] <pitti> doko: that should work if apport is installed in the chroot
[05:27] <doko> ahh, ok
[05:27] <pitti> doko: it doesn't do anything with the kernel, it just writes /var/crash/... directly; of course the 'outside' update-notifier won't pick that up
[05:27] <pitti> doko: you can still submit it manually with apport-gtk -c /path/to/crash/file, of course
[05:28] <doko> pitti: ok, so we have to find a way for the buildds to report these ...
[05:28] <pitti> doko: oh, you meant to have that on the buildds? hmm :)
[05:28] <pitti> doko: I guess that'd require an sbuild hack
[05:29] <pitti> doko: right now there's no fully noninteractive reporting mode due to the need of LP authentication
[05:29] <pitti> doko: so either a buildd admin grabs it and submits it manually, or I'll think about building cookie support etc. into the client side
[05:43] <LaserJock> cjwatson: patch sent
[05:44] <geser> pitti: bug 123062: I've done a small test and moved my sources.list info sources.list.d/gutsy.list, run apt-get update and tried the test from bug report and it still finds it
[05:44] <ubotu> Launchpad bug 123062 in apport "apport-gtk crashed with AssertionError in __setitem__()" [Undecided,Incomplete]  https://launchpad.net/bugs/123062
[05:44] <pitti> geser: oh, thanks
[05:45] <pitti> geser: still curious, you do not need apt or even apt sources at all to determine the source package of an installed binary package, that's why I wonder
[05:45] <mvo> the source-package name should be in the dpkg status pkg record
[05:47] <pitti> $ dpkg-query -W -f '${Source}\n' apport-retrace
[05:47] <pitti> apport
[05:47] <pitti> mvo: right
[05:47] <pitti> mvo: so doesn't python-apt use that for the .sourcepackage attribute?
[05:48] <mvo> it should
[05:51] <mvo> pitti: just to be clear: packaging.get_source(package) returns None, right?
[05:52] <pitti> mvo: python -c "import apt; print apt.Cache()['seahorse'] .sourcePackageName" prints nothing
[05:52] <pitti> mvo: it should print 'seahorse'
[05:53] <pitti> mvo: (nothing except the apt API warning, of course, see bug trail)
[05:53] <keescook> kylem: ping
[05:53] <pitti> mvo: I would have thought that print would output 'None', instead of nothing, hmm
[05:54] <mvo> geser: can you reproduce that bug?
[05:54] <mvo> pitti: yeah, that puzzles me
[05:54] <geser> mvo: not yet
[05:54] <pitti> mvo: well, packaging.get_source() just wraps that apt.Cache()['seahorse'] .sourcePackageName call and returns the result
[05:55] <mvo> pitti: yeah, I'm currently looking at the python-apt source and wonder where a "" return could come from
[05:55] <geser> pitti: what about that the reporter used an older version of apport?
[05:55] <geser> apport-gtk 0.86 and gutsy has now 0.93
[05:55] <pitti> geser: hm, let me check out 0.86 and see
[05:56] <pitti> geser: hm, last change to get_source was in 0.78, so that's not it
[05:56] <pitti> bzr blame FTW :)
[05:58] <geser> might a change in apt fixed it? the gutsy system from the reporter doesn't seem to be uptodate
[06:01] <jdong> bug 128721
[06:01] <ubotu> Launchpad bug 128721 in feisty-backports "Please backport 2.6.22 kernel from Gutsy to Feisty" [Undecided,Invalid]  https://launchpad.net/bugs/128721
[06:01] <pitti> whoa
[06:01] <ion_> Hehe
[06:01] <geser> pitti, mvo: I can reproduce it
[06:01] <pitti> "Please backport gutsy to feisty"
[06:01] <mvo> geser: how?
[06:01] <pitti> geser: oooh?
[06:01] <jdong> pitti: lol :)
[06:02] <mvo> geser: can you please run http://paste.ubuntu-nl.org/31559/ and paste the result somewhere? I'm curious about it
[06:02] <geser> it's the something to do with the line break in the command the bug reporter used
[06:02] <pitti> jdong: well, I actually do not know whether gutsy's kernel would work with feisty's udev/hal/etc.; it's not totally impossible
[06:03] <jdong> pitti: in the past it's not worked too great, so I'm not all that optimistic
[06:03] <jdong> and for sure it replaces linux-libc-dev and friends
[06:03] <pitti> yep
[06:03] <jdong> and you're kinda stuck without linux-meta magic too :)
[06:03] <jdong> all in all IMO a bad idea (tm)
[06:03] <pitti> jdong: right; I meant, if someone actually wants, he can just grab the gutsy packages and install them
[06:03] <jdong> right
[06:04] <geser> mvo: http://paste.ubuntu-nl.org/31560/
[06:05] <mvo> geser:  and python -c "import apt; print apt.Cache()['seahorse'] .sourcePackageName"
[06:05] <geser> pitti: python -c "import apt; print apt.Cache()['seahorse'] .sourcePackageName" works but when you introduce a  line break between the print and apt.Cache it doesn't print anything
[06:06] <geser> mvo: the usual warning and "seahorse"
[06:06] <pitti> geser: ah, naturally
[06:06] <mvo> ok, so it maybe that the reported used the command wrongly?
[06:06] <pitti> geser: I had assumed that was just a line break in LP
[06:07] <mvo> I attached some testcode that should (hopefully) cleanup the confusion
[06:08] <pitti> mvo, geser: thanks
[06:11] <ion_> bryce, seb128: xserver-xorg-core 2:1.3.0.0.dfsg-6ubuntu3 makes X segfault when starting an OpenGL program. Im running the proprietary nvidia driver and compiz. Downgrading to -ubuntu2 fixes the problem.
[06:12] <seb128> bryce: ^
[06:12] <seb128> ion_: can you send a crash bug with apport if there is not already one?
[06:13] <siretart> mwolson: yes, I finished my phone call
[06:13] <ion_> seb128: apport didnt seem to notice the crash. The only thing that indicated a segfault was a mention of signal 11 in Xorg.0.log.
[06:13] <seb128> weird
[06:13] <seb128> ion_: no crash file in /var/crash?
[06:13] <pitti> hm, maybe X.org has its own crash handler then?
[06:13] <mwolson> siretart: OK, shall we begin the emacs22 discussion with pitti and seb128 then?
[06:13] <ion_> seb128: Nope.
[06:14] <ion_> Ill install 2:1.3.0.0.dfsg-6ubuntu3 and post the Xorg log after it crashes.
[06:14] <siretart> if pitti and seb128 agree :)
[06:15] <pitti> siretart: your mail was pretty good
[06:15] <siretart> pitti: thanks :)
[06:15] <seb128> hum
[06:15] <seb128> we are supposed to speak about emacs22?
[06:16] <siretart> pitti: I checked the 25MB diff to the debian package. I'm quite confused about this, since debian ships a totally different upstream tarball
[06:16] <pitti> mwolson: so you actually want to maintain emacs22 on your own for a while? TBH this looks like more effort than necessary to me (joining the Debian and Ubuntu team together to maintain a synced emacs22 seems much more valuable to me?)
[06:16] <siretart> pitti: I have no idea what they have done. I know that our emacs22 package uses the pristine source tarball
[06:16] <siretart> well, not totally different, but it looks nearly like another upstream version to me
[06:16] <mwolson> pitti: yes.  it is an absolutely necessary effort because Debian has maimed the package by stripping out its manuals and the GNU Manifesto
[06:16] <pitti> siretart: note that I'm not saying that the Debian version is better in any way
[06:16] <mwolson> due to their GFDL policy
[06:17] <pitti> mwolson: as long as they package it separately, that's not a big problem; we can just add a dependency to the -doc package
[06:17] <mwolson> i am willing to invest the effort to maintain this package indefinitely, because I care about the manuals
[06:17] <mwolson> pitti: they don't package it separately.  they completely strip the manuals out
[06:17] <pitti> so a good compromise would be to leave the package split for Debian's sake and just sync it into Ubuntu's main
[06:17] <pitti> mwolson: hm, that's evil
[06:17] <mwolson> yes, it is
[06:18] <pitti> mwolson: are there key differences in the non-doc bits?
[06:18] <pitti> mwolson: maintaining the -doc package on our own is still much less effort
[06:18] <siretart> mwolson: don't the debian packages ship the gnu manifesto and gnu manuals in emacs22-common-non-dfsg? what's in there?
[06:18] <mwolson> siretart: oh, forgot about that
[06:19] <mwolson> so retract what i said about them stripping the manuals out completely
[06:19] <Nafallo> we should throw out emacs and all those things that use it from the archive
[06:19] <Nafallo> ;-)
[06:19] <siretart> /ignore Nafallo ;)
[06:19] <Nafallo> hehe
[06:20] <mwolson> pitti: i based my emacs22 package on the emacs-snapshot package, which has had a considerably more active maintainer
[06:20] <mwolson> so that's one reason to keep my changes
[06:20] <siretart> and emacs-snapshot keeps being actively maintained, it's just not happening in debian, but on Romains private archive
[06:21] <pitti> mwolson: did you contact the Debian maintainer of emacs22? if he doesn't want to cooperate, we have to bite the bullet, but maybe he would actually appreciate it
[06:23] <mwolson> pitti: i haven't contacted him.  but it would be a massive effort to enumerate the improvements that the emacs-snapshot guy made, and i feel that it might trod on the style of the Debian maintainer.  but i could be wrong.
[06:23] <siretart> I agree that we should indeed work together with debian to minimize the 25MB debdiff to something more reviewable
[06:23] <ion_> bryce, seb128: http://heh.fi/tmp/Xorg.0.log (nothing else seems to differ from a normal log than the very last lines)
[06:23] <mwolson> also, just Recommending Debian's nondsfg documentation sends a bad message to newbie users -- they will think that the manuals are tainted in some way, which is completely not the case
[06:23] <seb128> ion_: do you have the dbgsym installed?
[06:24] <mwolson> s/documentation/documentation package/
[06:24] <siretart> mwolson: we can easily change that to a hard depends in ubuntu
[06:24] <pitti> mwolson: well, newbies won't care, I think
[06:25] <siretart> pitti: newbies are totally lost without the manual. even advanced users need the manual quite often
[06:25] <ion_> seb128: Ill install it now. Should i install other -dbgsym packages in addition to xserver-xorg-core-dbgsym?
[06:25] <pitti> mwolson: I still think that it's a very low effort to contact the Debian maintainers of emacs22 and emacs-snapshot and try to form a team to create One True emacs22 instead of the current mess
[06:25] <mwolson> pitti: by "newbies", i meant "somewhat experienced GNU/Linux users who are trying out Ubuntu for the first time"
[06:25] <pitti> siretart: I meant, newbies won't care if the version has some 'dfsg' in it; of course they care about the doc
[06:25] <siretart> indeed
[06:25] <mwolson> (not a general definition of "newbie" by any standards, but meh)
[06:25] <seb128> ion_: not sure, I'll tell you when you get a new backtrace ;)
[06:26] <mwolson> pitti: in what particular way is this a "mess"?
[06:26] <seb128> I agree with pitti, what users will care about is to have the documentation
[06:26] <seb128> not how to package is named
[06:26] <pitti> mwolson: having -snapshot and -22 which are both 22, actually maintaining the package outside of Debian in addition, and forking it in Ubuntu
[06:27] <pitti> mwolson: that makes four different sources which should actually just be one
[06:27] <pitti> and if Debian names the -doc package 'blabla-gfdl' and put it into non-free, and we just sync it to main, both Debian and we will be happy
[06:27] <mwolson> pitti: the primary reason that I doubt we could form a "one true Emacs22" team is that of ideological differences w.r.t. the GFDL.  there were some very strong opinions voiced on the debian-emacsen list on this issue
[06:28] <pitti> ('gfdl' isntead of something scary like 'non-free' or 'evil' :) )
[06:28] <seb128> mwolson: right, and I think that's why the emacs-snapshot maintainer stopped working on the Debian package
[06:28] <pitti> mwolson: I wasn't suggesting to try coercing the Debian guys to change it
[06:28] <mwolson> pitti: no, -snapshot is not Emacs22.  it is a snapshot of current CVS, updated every two weeks, and needs to stay distinct from the emacs22 package
[06:28] <pitti> mwolson: I see no problem at all to split the package
[06:29] <seb128> mwolson: Debian will not stop splitting the dfsg documentation, but as pitti says having the 2 packages in Ubuntu main is not a problem
[06:29] <pitti> mwolson: right, but (1) the packaging shuold be more or less identical, and (2) it shuold be maintained by the same team
[06:30] <pitti> mwolson: heh :) sorry, I didn't mean to confuse you, I just braindumped my thoughts about it
[06:31] <mwolson> pitti: also, debian will be the one splitting the emacs-snapshot if they opt to do so; we will get it from the real maintainer; but more likely is that Debian will simply drop emacs-snapshot.  or so i have read on the bug report that orphaned emacs-snapshot
[06:31] <mwolson> so there will be only two different sources: our emacs22 and theirs
[06:32] <pitti> mwolson: right; but what's the reason why our diff needs to be 25 MB instead of just the dependency to -doc?
[06:32] <siretart> debian has already dropped emacs-snapshot
[06:32] <pitti> indeed
[06:32] <mwolson> pitti: clarify "diff".  against Debian or upstream?
[06:32] <pitti> siretart, mwolson: want me to remove it from gutsy as well? or do you care aobut it?
[06:32] <siretart> pitti: NO!
[06:32] <seb128> pitti: well, looks like the mess is on the Debian side there
[06:32] <pitti> mvo: against Debian's emacs22
[06:32] <mwolson> pitti: i care about it.
[06:33] <siretart> pitti: I'm regularily request syncs from Romains private archive to ubuntu!
[06:33] <pitti> seb128: right, I never questioned that
[06:33] <pitti> mwolson: ok
[06:33] <seb128> pitti: emacs-snapshot doesn't come from Debian
[06:33] <pitti> siretart: ah, that one; I see
[06:33] <siretart> mwolson: http://patches.ubuntu.com/e/emacs22/ has the the uptodate diff  between the ubuntu and debian emacs22 package
[06:33] <mwolson> haha
[06:33] <siretart> pitti: :)
[06:35] <siretart> as said, I think we should work on minimizing that 25MB diff. However, from what I've seen is that most of the diff comes from debian using a different orig.tar.gz
[06:35] <mwolson> siretart: i haven't seen that diff yet.  i will take a look at it this weekend and see if there are things that can be brought closer together
[06:36] <pitti> siretart: ok, that's not unreasonable; what's the filterdiff -i */debian/*'?
[06:36] <siretart> that's why I don't think that we can minimize it for gutsy, but if we work with debian together, we can do it for gutsy+1
[06:36] <siretart> thats managable
[06:36] <pitti> siretart: if the 25 MB is by and large removed documentation, then merging the packages continuously is not a problem
[06:36] <mwolson> however, i honestly don't think we need to worry about minimizing diffs against Debian's package.  i am maintaining it separately, and will track Debian's changes.  i think this is a specials case where diff minimalization ought not to be a primary goal.
[06:37] <siretart> we are using quilt, debian is using the cdbs patch system
[06:37] <mwolson> s/specials case/special case/
[06:37] <siretart> the patches are called differently
[06:37] <seb128> (hate quilt)
[06:37] <mwolson> siretart: actually, Debian is also using quilt.
[06:37] <siretart> oh?
[06:37] <mwolson> but they format the headers differently
[06:37] <seb128> it's too complicated to use and breaks all the time
[06:37] <siretart> seb128: we don't force you to work on emacs22 ;)
[06:37] <mwolson> which might account for a lot of the changes
[06:38] <mwolson> seb128: it still beats the hell out of dpatch
[06:38] <seb128> siretart: good ;)
[06:38] <seb128> mwolson: well, I like easy things but I'll not argue
[06:38] <mwolson> seb128: i hate having to edit files in /tmp in order to commit changes
[06:38] <seb128> I use simple-patchsys and cdbs :p
[06:38] <seb128> understandable on a big package
[06:38] <bryce> ion_: thanks for reporting the regression.  The only change between *ubuntu2 and *ubuntu3 was that a patch to turn off clipping in composite was added
[06:39] <seb128> I hate having to push, add, edit, pop, etc to edit a patch
[06:39] <mwolson> *scrolls back a few screens to see if he missed anything*
[06:39] <seb128> anyway that's not the topic ;)
[06:39] <siretart> pitti: mwolson: http://paste.debian.net/33534 has the effective diffstat of the packaging difference
[06:39] <bryce> ion_: are you experiencing the crash when compiz is on or off?
[06:40] <mwolson> OK, i think i'm caught up now :^)
[06:40] <pitti> siretart: quite a lot in rules, and quite a lot of noise in many other files, hmm
[06:41] <siretart> pitti: indeed. I agree that we should work to minimize that
[06:41] <mwolson> pitti: some of the changes to debian/control will likely get picked up by Debian soon, since we (preemptively) fixed a bug in their BTS about binNMU builds
[06:42] <pitti> mwolson: just a side note, we do not need to care about binNMU; we don't do them
[06:42] <ion_> bryce: Only when compiz is running, and i start any OpenGL application.
[06:42] <mwolson> ok
[06:42] <siretart> mwolson: that 'tuned' diff ist still 223K big
[06:42] <ion_> seb128: Installing xserver-xorg-code-dbgsym made no difference: http://heh.fi/tmp/Xorg.0.log
[06:43] <siretart> large parts (about 30%) is because of debian/changelog and debian/copyright*
[06:43] <siretart> another large part is of course because we use another 'patch format'
[06:43] <mwolson> i think our debian/rules is cleaner in many places and easier to understand
[06:43] <siretart> (headers of debian/patches/*) and such
[06:44] <mwolson> as an example, Debian uses two or three temp files to generate some contents in README.Debian.  we use none.
[06:44] <avoine> the package base-files depend on awk but awk is a meta-package that you have to choose between gawk,mawk,etc which awk it's take?
[06:44] <siretart> which also blows up the diff
[06:44] <siretart> How do we want to proceed from here? pitti, do you think that coordination with debian is a prequisite for having emacs22 in main?
[06:44] <siretart> I'd expect that would mean that we won't have it for gutsy, but for gutsy+1.
[06:45] <pitti> siretart: I don't consider it a prerequisite, but it should happen nonetheless; if we ask and they refuse and don't respond, that's ok; but if they appreciate building a team, we should do it, also for Debian's sake and avoiding redundant work
[06:45] <pitti> mwolson, siretart: in any case, thanks for the heads-up
[06:46] <ion_> Would it make sense to disable the X crash handler so that apport would catch the crashes?
[06:46] <siretart> pitti: does this mean you'd prefer to have emacs21 in gutsy/main for now?
[06:46] <pitti> ion_: disabling it is not really necessary, it's enough if it would just re-raise the signal after doing what it wants to
[06:46] <pitti> siretart: no, I don't have any strong opinion about it
[06:47] <pitti> siretart: I don't use emacs myself, so I can only rely on testers
[06:47] <mwolson> i think people will be very disappointed not to have a GTK+ 2 capable Emacs in main  (which would be the case if emacs21 is in main, but emacs22 isn't)
[06:47] <siretart> pitti: it would perhaps help to get rid of gtk1 ;)
[06:47] <pitti> so, if emacs22 works well, and is supported upstream, and mwolson and maybe others will maintain it, let's update
[06:47] <mwolson> \o/
[06:47] <pitti> siretart: that went to universe some time ago and will never come back :)
[06:47] <siretart> oh wait, does emacs21 use gtk at all?
[06:48] <pitti> siretart: we might have patched it, not sure
[06:48] <siretart> aah, I confuse that with xemacs
[06:48] <siretart> that one used gtk1, I'm sorry
[06:49] <mwolson> yeah
[06:49] <siretart> mwolson: I'd say we'll prepare an email with 'our' differences to the debian maintainers and see if they are interested in minimizing the diff
[06:49] <mwolson> siretart: sounds good
[06:50] <mwolson> siretart: i'll begin working on that tomorrow night (now+1 day+7 hours)
[06:50] <pitti> mwolson: you should also ask if they are interested in team maintenance in a shared VCS repo or so
[06:50] <pitti> mwolson: alright, thanks a lot!
[06:50] <siretart> mwolson: thanks a lot!
[06:50] <siretart> :)
[06:51] <pitti> siretart: seems you just voluntold to sponsor mwolson's uploads once it's in main? :-)
[06:51] <siretart> pitti: I already do. I've done it for the previous uploads
[06:51] <pitti> siretart, mwolson: oh, does that also update the 'emacs' metapackage, for an automatic update?
[06:52] <pitti> seems not
[06:52] <pitti> mwolson: it would be good if emacs22 would build 'emacs' as well
[06:52] <siretart> hmmm
[06:53] <siretart> the debian emacs22 package already builds 'emacs' as well as the emacs21 package..
[06:53] <cjwatson> avoine: mawk is Priority: required and is thus installed by debootstrap and used by default
[06:53] <pitti> if emacs21 goes to universe and emacs22 to main, we shuoldn't leave upgraders with an unmaintained one
[06:53] <mwolson> pitti: i'm still very hesitant to ask.  i might sound them out on some proposed changes first, and see how willing they are to implement them
[06:53] <mwolson> pitti: hmm, it would be nice if emacs22 could Provide emacs or somesuch
[06:54] <pitti> mwolson: right; no need to throw two tons of patches at them immediately; just explain the situation and offer some comaintaining, or mutual merging, or somethign (depending on how close they want to work with you)
[06:54] <mwolson> ok
[06:54] <pitti> mwolson: Provide: is not enough, we should merge the Debian change which builds the emacs metapackage and Depends: emacs22
[06:54] <siretart> I volunteer fix the breakage caused by swapping emacs21/emacs22 wrt. the 'emacs' metapackage
[06:54] <mwolson> pitti: ah, i think i see what you mean now
[06:54] <pitti> siretart: NB that it's not a problem to have two emacs packages in the archive, at least for a while
[06:55] <cjwatson> pitti: don't we have an emacs-meta?
[06:55] <cjwatson> oh, we used to, it vanished, ok
[06:55] <pitti> cjwatson: not any more (dropped in feisty)
[06:55] <siretart> pitti: ok
[06:55] <pitti> well, as long as you guys don't break my vim.... /me ducks
[06:56] <siretart> I expect we need to update some build-dependencies as well, like auctex
[06:56] <pitti> auctex
[06:56] <pitti> bbdb
[06:56] <pitti> calc
[06:56] <pitti> emacs
[06:56] <pitti> emacs-goodies-el
[06:56] <pitti> gnus
[06:56] <pitti> malaga-mode
[06:56] <pitti> python-mode
[06:56] <pitti> not too bad
[06:57] <siretart> oh, that reminds me, I wanted to teach emacs-goodies-el about gutsy...
[06:57] <pitti> most of them can probably be changed to "Depend: emacs | emacsen"
[06:57] <pitti> which would make it more future-proof, too
[06:58] <siretart> pitti: is that reliable even for build-dependencies?
[06:58] <siretart> I remember something on the mailing list by Ian lately..
[06:58] <pitti> siretart: right, but emacs is a real package, so as long as it doesn't actually depend on a particular emacs version, that's ok
[06:58] <mwolson> siretart: was the emacs-goodies-el stuff taken care of by Bug #123902?
[06:58] <ubotu> Launchpad bug 123902 in emacs-goodies-el "Candidate revision emacs-goodies-el_26.11-1ubuntu1" [Wishlist,Confirmed]  https://launchpad.net/bugs/123902
[06:59] <pitti> siretart: "Build-Depends: emacsen" would be wrong (virtual package only)
[06:59] <pitti> siretart: prefered (first) alternative must not be virtual
[06:59] <siretart> pitti: ok
[06:59] <pitti> siretart: we compromise on that in Ubuntu for the sake of avoiding deltas just for that
[06:59] <siretart> mwolson: partly. I wanted to do an ubuntu2 upload which knows about the ubuntu releases as well
[07:00] <siretart> but I got lost in the 'next-upstream-version' function
[07:00] <desrt> seb128; did you write keith about my thoughts on the compiz bug?
[07:00] <mwolson> siretart: ah
[07:00] <seb128> desrt: no, didn't have too, he fixed the patch upstream
[07:00] <desrt> nice
[07:00] <mwolson> siretart: need any help with the elisp part of that?
[07:00] <seb128> desrt: and I've confirmed that the new version works fine ;)
[07:01] <desrt> what ws wrong?
[07:01] <siretart> mwolson: well, I might indeed need some help here.
[07:01] <pitti> siretart: promoted to main now
[07:01] <seb128> desrt:
[07:01] <seb128> -+    if (pWin->parent && pWin->redirectDraw != RedirectDrawNone)
[07:01] <seb128> ++    if (pWin->parent && pWin->redirectDraw == RedirectDrawNone)
[07:01] <siretart> mwolson: the package contains it own algorithm for calculating the next upstream version when doing a C-c C-v
[07:01] <pitti> siretart: we need both in main for the time of the depends: transitions, then I'd like to drop emacs21 and get the emacs package point to emacs22
[07:01] <desrt> seb128; hm.  ok :)
[07:02] <siretart> mwolson: I tried to change that it doesn't just increments the revision, but introduces -Nubuntu1 and so on. and set gutsy instead of unstable
[07:02] <siretart> like recent dch does
[07:02] <siretart> pitti: you rock! :)
[07:02] <pitti> siretart: I didn't do anything but whine, nevermind :)
[07:03] <siretart> mwolson: I tried, and defered the idea for ubuntu3 (but forgot to finish and upload ubuntu2) :/
[07:03] <mwolson> siretart: do you want me to start work against my ubuntu1 or your ubuntu2 (would need to know where to get it), or some working directory?
[07:04] <siretart> mwolson: I work in a bzr branch, but haven't publised it yet. I need to go home now, and will publish it then, okay?
[07:05] <siretart> mwolson: I think I can easily merge anything based on ubuntu1 to my branch
[07:06] <siretart> need to leave now, cu later!
[07:07] <mwolson> siretart: OK
[07:08] <mwolson> later
[07:08] <tkamppeter> pitti, any progress on s-c-p?
[07:10] <pitti> tkamppeter: I didn't do anything with it today
[07:10] <tkamppeter> pitti, then we should perhaps better continue with this in the beginning of next week.
[07:11] <pitti> tkamppeter: right, I still need some time to file some bugs, as per yesterday's distro meeting, but today's archive day of mine took a lot of time, sorry
[07:28] <avoine> thanks cjwatson for the reply about awk and sorry for the delay :/
[07:50] <bryce> ion_: it probably would be a good idea to try that
[07:52] <bryce> ion_: I checked to see if debian has any relevant fixes for this issue, but didn't spot anything close.  I'm going to check xorg's bug tracker to see if it's been reported there
[07:52] <Ng> should I be using -i810 or -intel for a 852GM/855GM (I think it's the 855)?
[07:53] <bryce> ion_: would you also mind testing to see if it occurs with the -nv driver?  If it does, it might be easier to troubleshoot than the binary driver
[07:53] <bryce> Ng, I believe there are still some outstanding issues for 855 with -intel, however if you can get -intel to work okay, that's the better choice
[07:53] <bryce> -810 is legacy so we're encouraging people to move to -intel where possible
[07:54] <Ng> bryce: ok. I was using -intel on feisty for better resuming and it's stuck with that on gutsy, but I get some weird renderng with compiz
[07:54] <Ng> (no drop shadows and earlier when i switched it replaced each window with a box of noise ;)
[07:54] <bryce> Ng, hmm, that sounds suspiciously like an issue seb128 and I were looking at
[07:54] <bryce> what version of xorg-server do you have installed?
[07:55] <Ng> 7.2-3ubuntu4
[07:55] <bryce> xorg-server should be 1.3.0something
[07:56] <bryce> xorg-server 2:1.3.0.0.dfsg-6ubuntu3 is the latest available
[07:56] <Ng> sorry, I typed xserver-xorg. xorg-server isn't installed or available (this is gutsy)
[07:56] <seb128> xserver-xorg-core
[07:57] <Ng> 2:1.3.0.0.dfsg-6ubuntu3
[07:57] <bryce> hmm, actually I think the issue we were looking at was noise in icons, not in windows in general.  could be something different
[07:57] <seb128> diner time, bbl
[07:58] <Ng> this was literally everything. I flipped on desktop effects and it all went crazy. it all still worked and I could figure out which button turned it back into metacity ;)
[07:58] <bryce> hmm, well debian has a dfsg-11 available, but I've reviewed the changelog and didn't see anything that looked like it fix your issue or ion_'s
[07:59] <bryce> Ng, had you been able to run compiz successfully previously?
[07:59] <Ng> bryce: yeah. when I'm at home I'll reboot and get everything into a clean state and compare -i810 and -intel
[08:00] <Ng> (successfully modulo getting white boxes instead of drop shadows)
[08:00] <bryce> ok cool
[08:00] <bryce> in general -intel seems to work quite well with compiz from what I've seen
[08:04] <bryce> so this bug sounds pretty unusual and interesting
[08:13] <jwendell> Hi, i'd like to call 'autoconf' after the patch be applied (and before it calls configure). What rule in debian/rules should i use (CDBS) ?
[08:13] <jwendell> configure/xxx:: is called after it runs configure...
[08:14] <jwendell> makebuilddir/xxx:: is called before it apply the patches...
[08:14] <jwendell> seb128, can you help me?
[08:16] <Seveas> jwendell, post-patches:: looks like a candidate :)
[08:16] <jwendell> Seveas, thanks.
[08:16] <jwendell> i didn't found this on its docs ;)
[08:17] <Seveas> I read the source :)
[08:17] <Seveas> /usr/share/cdbs/1/rules/simple-patchsys.mk
[08:17] <jwendell> Seveas, it didn't work...
[08:18] <Seveas> darn
[08:18] <Seveas> do you use simple-patchsys?
[08:19] <jwendell> Seveas, yep
[08:19] <jwendell> Seveas, the patch is being applied
[08:19] <jwendell> but i want to run 'autoconf' because the patch changes configure.ac
[08:23] <Seveas> jwendell, common-configure-{arch,indep}:: from /usr/share/cdbs/1/rules/buildcore.mk line 151 (gutsy) could be suitable candidates
[08:26] <jwendell> nope
[08:26] <Seveas> then I give up :)
[08:26] <Seveas> cdbs is still black magic
[08:26] <jwendell> Seveas, a possible solution is add it on post-configure and the call configure again
[08:26] <jwendell> hehe
[08:39] <asisak> Any REVU admins here, please?
[08:40] <somerville32> Try #ubuntu-motu
[08:40] <asisak> Sorry, I've already tried #ubuntu-motu.
[10:16] <mr_pouit> could someone push xfce4-places-plugin to main? mir has been approved (https://wiki.ubuntu.com/MainInclusionReportXfce4PlacesPlugin), but it is still in universe
[10:17] <seb128> mr_pouit: it'll be promoted when something in main depends on it
[10:18] <seb128> mr_pouit: or if it's seeded
[10:18] <mr_pouit> it is already seeded
[10:19] <mr_pouit> seb128: in xubuntu.gutsy
[10:21] <_StefanS_> hi there..
[10:21] <_StefanS_> is it on purpose that subpixel hinting is disabled in the freetype for gutsy?
[10:23] <seb128> mr_pouit: promoted
[10:23] <seb128> will be available on next publisher run
[10:23] <mr_pouit> seb128: thanks :)
[10:23] <seb128> you're welcome
[10:24] <seb128> mr_pouit: you work on xubuntu? Maybe you want to merge gnumeric with the new version available in debian experimental? ;)
[10:25] <mr_pouit> seb128: ok, I'll give a look (I think gpocentek usually take care of it, I'll see with him)
[10:25] <seb128> ok, thanks
[10:25] <seb128> asisak: ^
[10:26] <asisak> thanks seb128 for arraging this
[10:26] <seb128> you're welcome ;)
[10:34] <iwj> seb128: consolekit+gdm+gnome-screensaver are looking OK to me but there's still one annoying bug for which the fix involves inventing a new dbus message which is soooo teeeediiiouuus.
[10:35] <iwj> So I'm going to finish that up on Monday.
[10:35] <seb128> iwj: ok, good
[10:35] <iwj> How do people cope with dbus ?  Don't their fingers wear out ?
[10:35] <iwj> dbus_set_bit_number_176_of_some_message_with_extended_connection_state_to_1()
[10:35] <seb128> iwj: should I send your gnome-screensaver patches upstream or are you going to do it?
[10:36] <iwj> I'm doing it.
[10:36] <seb128> yeah for verbose descriptions ;)
[10:36] <seb128> ok
[10:36] <iwj> I'm sending to gnome bugzilla and uploading, although not all of the patches are in both places yet.
[10:37] <iwj> Anyway, it's too late still to be working and my dinner will be along any moment.
[10:38] <seb128> there is no hurry for it, the next tribe is in 10 days so there is time to upload and give it some testing
[10:38] <iwj> Have a nice weekend :-).
[10:38] <iwj> Right.
[10:38] <seb128> thanks, you too
[11:04] <capiira> hmmm hi i already asked in #ubuntu but nobody answered my question! Does ubuntu use dash or bash, anyone know ?
[11:05] <pygi> bash
[11:05] <capiira> ahh ok thx and dash is not used at all ?
[11:05] <xxxxx1> capiira, by default /bin/sh is a symlink to /bin/dash
[11:05] <thom>  /bin/sh is dash by default
[11:06] <stgraber> capiira: ls -l /bin/sh would have answered your question
[11:06] <xxxxx1> capiira, btw, the default user shell is bash.
[11:06] <capiira> ahh ok thats all for what dash is used ?
[11:07] <ScottK> Dapper/Edgy are Bash.  Feisty and follow are Dash.
[11:07] <capiira> ahh ok
[11:08] <capiira> thank you
[11:09] <capiira> now i can search for proper books :)
[11:09] <thom> ScottK: uh, wrong. Edgy is dash
[11:09] <capiira> heh
[11:10] <ScottK> Ah.  Sorry.  Misremembered the transition point.
[11:10] <thom> capiira: for dash, you just need to follow posix sh standards
[11:11] <capiira> then it will work in dash and bash shells ?
[11:14] <thom> posix sh is the standard, yes
[11:14] <capiira> ahh nice that's exactly what i'm looking for
[11:14] <capiira> something that works everywhere
[11:14] <capiira> thank you