[00:19] <Hobbsee> Fujitsu: hmm, was the hal fixing the dimming brightness for you too for a while?
[00:19] <Hobbsee> or am i just going mad?
[00:43] <bryce> is anyone here running Xgl?  If so could you run xvinfo | grep Xgl ?
[00:43] <jdong>   Adaptor #0: "Xgl Generic Texture Video"
[00:43] <jdong> bryce: ^^ :)
[00:44] <jdong> after all these years, fglrx 8.40.4+Xgl is STILL the most stable/smooth setup for my mobility x1400
[00:44] <jdong> I just gave up on Catalyst 8-3 after a week's time with it
[00:49] <bryce> jdong whoohoo thanks!
[00:49] <bryce> jdong: could you also run 'xrandr -v' ?
[00:49] <jdong> Server reports RandR version 1.2
[00:50] <bryce> interesting!  thanks
[00:55] <RAOF> jdong: That's disappointing.  I was hoping that xgl could go away.
[00:55] <bryce> jdong: fwiw, my bet is that Xgl+fglrx 8.40.4 does not actually do xrandr 1.2, so the xserver is sort of fibbing a little
[00:59] <jdong> RAOF: tell me about it; I actually shed some tears when catalyst 8-3 failed to deliver
[00:59] <jdong> bryce: I agree
[01:55] <RAOF> tjaalton: Do you have any debugging tips you'd like done for bug #194214?  It's annoying, and doesn't seem to be the kernel's fault.
[01:55] <ubotwo> Launchpad bug 194214 in xorg-server "Keys get "stuck" down" [High,Confirmed] https://launchpad.net/bugs/194214
[03:17] <compbrain> Anyone happen to know if there is a py module kicking around for reading .dsc's?
[03:20] <james_w> compbrain: python-debian should do it.
[03:20] <lamont> slangasek: you around?
[03:21]  * ScottK wonders about python-apt
[03:21] <james_w> ScottK: python-apt can do it as well probably, but doing it in python-debian is pretty simple.
[03:24] <compbrain> ScottK: I didn't see anything in python-apt that could do stuff with a non-deb
[03:32] <emgent> heya fabbione :)
[03:39] <ScottK2> compbrain: OK.  I guess I won't wonder anymore
[04:29] <fabbione> hi emgent
[04:33] <slangasek> lamont: moo
[04:35] <fabbione> morning guys
[04:41]  * slangasek waves
[05:31] <nxvl> how do i write new blueprints?
[05:31] <nxvl> i don't find the option
[05:32] <emgent> nxvl, https://blueprints.edge.launchpad.net/specs/+new
[05:41] <nxvl> emethnx
[05:42] <nxvl> emgent: thnx
[05:42] <emgent> np :P
[06:00] <tjaalton> RAOF: sorry no, it needs to be reported upstream
[06:08] <tjaalton> RAOF: I've been meaning to do that, but instead selfishly prioritized the bugs that I'm seeing when triaging ;)
[06:09] <tjaalton> hm, s/when.*//
[07:06] <RAOF> tjaalton: That's OK.  I was going to try building xserver without the smart scheduling patch, on the basis that it seems to have been added around the time this started and seems vaguely like a candidate.
[07:06] <RAOF> tjaalton: Following that, I was going to try raw upstream git xserver.
[07:08] <dholbach> good morning
[07:23] <pitti> Good morning
[07:25] <Hobbsee> morning pitti, dholbach
[07:25] <Fujitsu> Hi Hobbsee, pitti, dholbach.
[07:30] <tjaalton> RAOF: excellent, thanks
[07:59] <pitti> doko_: ah, python-xml in component-mismatches \o/ demoted
[08:00] <pitti> doko_: p-pysqlite2: http://paste.ubuntu.com/5609/
[08:04] <pitti> lool: ah, elisa finally starts up, thanks!
[08:05] <pitti> lool: apparently I'm just too dumb to do anything with it :/ the configuration area just has themes, the photo/video thingies don't allow me to set any file path, and the audio file browser does not go above my home dir
[08:23] <doko> pitti: python-xml: asked ScottK to do the same in universe, and then remove it
[08:27] <lool> pitti: I think your initial experience with elisa is interesting to note down
[08:27] <lool> pitti: I'm sure you can easily workaround your issues with the config file(s); but it's interesting to see how it was a pain for you to start with
[08:28] <pitti> lool: it would be nice if there was 'paths' section in the configuration, where I could point it to the root dirs of my audio/video/photos
[08:28] <lool> pitti: To some extent, it's meant to be configured once (or using the defaults) on a dedicate box near your TV
[08:29] <dwa> hello, my x keeps hanging when i use an ftp mount. Is there a known bug about this?
[08:29] <pitti> lool: how is that done? vi .elisa/config?
[08:29] <lool> pitti: /usr/share/doc/elisa/FIRST_RUN
[08:30] <lool> pitti: In .elisa/elisa.conf
[08:30] <lool> pitti: Also, elisa is supposed to have grown client/server capabilities, a bit like mythtv; I didn't play with it myself, it's new with these uploads, but if you do I'm interested in your experience as well
[08:33] <lool> pitti: I'm happy to relay your impressions to the elisa folks; I'm sure they would be interested
[08:35] <pitti> lool: ah, that works now, I added the paths to the config file
[08:35] <pitti> I find it a bit difficult to steer (pressing Esc always throws me out of the entire program, no obvious method to pause/continue a video, etc.), but it looks nice
[08:36]  * pitti hugs lool, thanks for your work for fixing it
[08:42] <lool> pitti: FIRST_RUN covers the important keybindings (enter for play/pause)
[08:43] <pitti> lool: right, just getting used to it :)
[08:43] <lool> Keybuk: I think you had issues with elisa as well; it might be a good occasion to give it a try as well
[08:43] <lool> pitti: Oh reminds me: are you still looking at its main promotion?
[08:43] <pitti> lool: yes, now that it actually works
[08:45] <lool> pitti: Also FYI, there's a bugfix release which came out yesterday; it's currently held up by understanding a python-central bug wiht egg-info files and finding a fix or workaround
[08:45] <lool> But shouldn't change SONAME or anything, just bug fixes AIUI
[08:48] <ogra_cmpc_> wow
[08:48]  * ogra_cmpc_ just noticed the vesa driver is as fast as the intel driver on the cmpc .... while eating only half the ram i810 does
[08:51] <pitti> Riddell: hey
[08:51] <ogra_cmpc_> lool, you had a consolekit hack for for startx in mobile, right ? how evil is that change ? its really mean to disable all users that use startx from doing administrative desktop tasks imho so if it doesnt rip huge security holes that would probably be a nice addition...
[08:51] <pitti> Riddell: I'd like to have your opinion about hwdb-client in bug 195519
[08:51] <pitti> Riddell: i. e. do you rather want to keep hwdb-client-kde, or drop it entirely, given that it is mostly useless?
[08:52] <ogra_cmpc_> pitti, cr3 had promised me the new gui would be done for hardy (doesnt seem to be the case though :( )
[08:52] <lool> ogra_cmpc_: We're working on it, but it isn't working for now
[08:53] <ogra_cmpc_> ah, k, i thought you had it solved already
[08:53] <lool> ogra_cmpc_: What we managed doing is starting a CK session; there are many ways to do this
[08:53] <lool> The problem we're facing at the moment is making that session the active one
[08:53] <pitti> seb128: FYI, I gave-back gnome-games, libgnomeui, eel, and eog for now
[08:53] <ogra_cmpc_> yeah, i have a similar prob with ltsp logins
[08:53] <pitti> seb128: sorry if that causes some more FTBFS spam
[08:53] <lool> It would seem that using a root-only CK call to start the session with the relevant params might help it, but we didn't solve this yet
[08:54] <seb128> pitti: thanks, don't worry about the mails, I just mark those all read usually
[08:54] <lool> ogra_cmpc_: Finally, we have a stop gap workaround ATM which is to use a root running daemon to fix the CK session
[08:54] <cjwatson> lool: I have code that marks the session active by hand, if it would help
[08:54] <lool> cjwatson: Does it require root?
[08:54] <ogra_cmpc_> well, in any case it would be nice to have it un the general distro package so we can make use of it everywhere if its not to hackishj
[08:54] <pitti> seb128: I wait until libgnomeui is built and published, then I'll give back everything else
[08:54] <lool> cjwatson: Anyway, any contribution at this point is useful
[08:54]  * lool grabs bug id
[08:55] <seb128> pitti: alright
[08:55] <lool> https://bugs.edge.launchpad.net/ubuntu/+source/xinit/+bug/199486
[08:55] <lool> ogra_cmpc_, cjwatson ^^^
[08:55] <lool> pitti: You're also welcome to comment
[08:55] <cjwatson> lool: not certain
[08:55] <lool> I discussed this with mccann and he told us to use ck-start-session or something, which is only available in newer consolekit
[08:56] <ogra_cmpc_> is that like the pam thing wrapped ?
[08:56] <lool> However it's not helping as it's not aware of the DISPLAY at the moment it's launching the session
[08:56] <lool> ogra_cmpc_: Exactly, so doesn't solve the issue we're having
[08:56] <ogra_cmpc_> yeah
[08:56] <lool> I didn't have time to resume discussion
[08:56] <cjwatson> you probably don't want to use the pam module as such
[08:56] <ogra_cmpc_> right
[08:56] <lool> cjwatson: Oh why not?  We planned doing so
[08:57] <cjwatson> why doesn't xinit have root privileges?
[08:57] <cjwatson> oh, if you're willing to hack complete PAM support into xinit, sure
[08:57] <lool> cjwatson: It wasn't enough, but I think it did as well as ck-start-sesison
[08:57] <cjwatson> I didn't think it started a PAM session at the moment, though
[08:57] <lool> cjwatson: We're using "su" before starting startx
[08:57] <cjwatson> starting a PAM session requires root at *some* point
[08:57] <pitti> lool: if ck-launch-session helps you, we can certainly port it
[08:57] <lool> pitti: I think not
[08:57] <pitti> lool: sounds just like a shallow wrapper around open_session_with_parameters()?
[08:57] <lool> pitti: Michael checked the code and it basically does what the xinit patch did
[08:58] <ogra_cmpc_> pitti, it does the same as the already existing pam module
[08:58] <pitti> ah, ok
[08:58] <lool> pitti: Unfortunately that call is root-only
[08:58] <pitti> so the problem is not that you need a CLI tool instead of a lib call, but the place where to do it
[08:58] <lool> pitti: So we'd have to move to the Xorg server *shiver*
[08:58] <lool> pitti: Exactly
[08:58] <pitti> lool: right, it must be root only
[08:58] <lool> pitti: I'm just mentionning this because upstream told us so, but I think it was misguiding
[08:58] <cjwatson> lool: I've attached the openssh patch to the bug, but I'm not sure how much it'll help you
[08:58] <lool> cjwatson: Thanks
[08:59] <cjwatson> lool: why is starting the CK session as root not an option? As you say, you do have root at some point in the process
[08:59] <lool> cjwatson: Because we don't have the display at that time
[09:00] <lool> cjwatson: It's basically su launching startx as ume which spawns Xorg as root
[09:00] <lool> (I mean Xorg is suid root)
[09:00] <cjwatson> oh, right
[09:00] <lool> cjwatson: Thanks for the patch
[09:01] <cjwatson> doing it in the X server would be too evil for words
[09:01] <lool> cjwatson: What's the reason for merging it into ssh instead of pushing for the PAM module?  Is this for non-PAM sshd uses?
[09:01] <lool> cjwatson: haha
[09:01] <cjwatson> you can't use the PAM module with openssh for reasons too tedious to enumerate
[09:01] <cjwatson> basically privilege separation awkwardness
[09:01] <lool> Is this a design issue of the CK PAM module?
[09:01] <cjwatson> no
[09:02] <lool> As in, it should be using some helper to gain the privs it needs
[09:02] <lool> AH
[09:02] <cjwatson> no, it's just how openssh internals are arranged
[09:02] <cjwatson> actually sort of similar to your problem in some ways - when the PAM session is opened, you don't know DISPLAY yet
[09:02] <lool> It's sad to have PAM and to not be able touse it
[09:02] <cjwatson> because the client hasn't yet requested the forwarded X connection
[09:02] <lool> Oh
[09:02] <lool> Ok
[09:03] <cjwatson> or, for that matter, the tty
[09:03] <cjwatson> you can have ttyless ssh sessions, you see ...
[09:03] <lool> Sure
[09:03] <lool> I understand the tty can be requested at any time, just like you can add port forwarding or X11 forwarding
[09:03] <lool> And it's way too late to hope to use sshd root rights or PAM
[09:04] <cjwatson> openssh actually does have a method to get back to root
[09:04] <lool> cjwatson: Thanks for the explanations
[09:04] <cjwatson> which in fact is used by the consolekit patch
[09:04] <ogra_cmpc_> you could probably ssh -X localhost and have a sshd listen on lo
[09:04] <cjwatson> but I don't think that's relevant to your problem
[09:04] <lool> cjwatson: Oh; I wouldn't have expected that
[09:04] <cjwatson> it's very carefully constrained
[09:04] <lool> cjwatson: It's not relevant, but interesting nevertheless :)
[09:04] <ogra_cmpc_> i.e. bring up your X server and loop back to run xinint though ssh
[09:04] <cjwatson> if you see a mention of the "monitor" in openssh source, that's what that's doing
[09:05] <cjwatson> lool: I sort of feel that, instead of running the whole of startx under su, the su ought to be deeper
[09:05]  * lool slaps ogra_cmpc_ 
[09:05] <ogra_cmpc_> heh
[09:05] <lool> ;)
[09:05] <cjwatson> so that you can pass some bits of information back up to something running as root that can open the CK session for you
[09:06] <cjwatson> of course there is a certain historical expectation that running startx as a mortal user will DTRT
[09:06] <lool> Yes
[09:06] <ogra_cmpc_> ++
[09:06] <lool> I've used it for years when I considered gdm dangerous for my X sessions
[09:06] <ogra_cmpc_> gdm is fine as long as you dont want to restart or stop it :)
[09:07] <lool> Also, I guess it's going to make us start a Xsession as root too
[09:07] <cjwatson> exactly which dbus call is root-only?
[09:07] <lool> cjwatson: The one with params
[09:07] <lool> cjwatson: Which are required to pass the x11-display
[09:07] <lool> cjwatson: The FD bug has some details of the params which we might want to set
[09:07] <cjwatson> because I thought I remembered testing this as an ordinary user
[09:08] <lool> Michael Frey told me it wouldn't work as it was root only I think
[09:08] <lool> He commented as such in the FD bug
[09:09] <cjwatson> ah, yes, you're right
[09:09]  * ogra_cmpc_ thinks it was to early for CK inclusion
[09:09] <lool> Now, I wonder whether it would make sense to let Xorg report to CK when a display is spawned and a VT allocated
[09:09] <cjwatson> I guess I must have been using sudo dbus-send
[09:09] <cjwatson> this really doesn't feel right in the X server at all
[09:09] <lool> I understand we don't want to start a CK session there, but as Xorg is setting the VT etc.
[09:10] <lool> cjwatson: But Xorg is the exact place where the system objects are requested/created
[09:10] <lool> And where the DISPLAY comes to life
[09:10] <lool> Naturally, I'm not happy with DBus coming into play with Xorg  :-/
[09:10] <pitti> to me it feels slightly ugly to make X.org depend on CK
[09:10] <pitti> (for a library call)
[09:11] <pitti> it's less ugly to try and call ck-create-session, and just ignore if it isn't there
[09:11] <lool> What about a Xorg module?
[09:11] <cjwatson> the X server is wrong because if you're using remote X then it is on the wrong machine
[09:11] <cjwatson> the CK session is a client-side concept, not server-side
[09:12] <cjwatson> (with the usual confused X meanings of client and server)
[09:12] <lool> cjwatson: I see; so we can have multiple sessions with the same display?
[09:12] <cjwatson> consider X sessions forwarded over ssh
[09:12] <cjwatson> they share an X server, but the actual DISPLAY variable is something different on a different host
[09:12] <cjwatson> same goes for xdmcp
[09:13] <cjwatson> this is why it should be the responsibility of the session manager
[09:13] <cjwatson> or the display manager if relevant
[09:13] <lool> Yes, but then apps launched in the remote SSH session are going to which CK session?  One spawned by sshd and related to the virtual DISPLAY, no?
[09:13] <cjwatson> maybe you just need a trivial display manager
[09:13] <lool> Or is this extending the local CK session?
[09:14] <cjwatson> right, in the case of ssh the CK session is started by sshd, because sshd is effectively acting as a trivial display manager
[09:14] <cjwatson> and session manager, rolled into one
[09:14] <lool> cjwatson: So sshd is where the virtual DISPLAY comes to birth
[09:15] <cjwatson> sort of, but I think that's the wrong way to think about it
[09:15] <ogra_cmpc_> its a proxy server
[09:15] <cjwatson> display managers are actually quite easy to write
[09:15] <cjwatson> if you aren't trying to be gdm
[09:16] <cjwatson> LTSP has a trivial one called ldm, and I wrote adapted versions of that for oem-config and ubiquity
[09:16] <lool> cjwatson: Do we have anything close to such a dumb DM?
[09:16] <lool> Ah LDM, thanks
[09:16] <cjwatson> it's 100-odd lines of Python
[09:16] <ogra_cmpc_> well, ldm is C now
[09:16] <cjwatson> right, oem-config-dm isn't though ;-)
[09:16] <ogra_cmpc_> look at the pre gutsy code for ldm in python
[09:16] <lool> cjwatson, ogra_cmpc_, pitti: mind if I copy this log to the bug report?
[09:16] <cjwatson> oem-config-dm is probably a better place to start as it doesn't have the ssh stuff
[09:16] <cjwatson> not at all
[09:17] <pitti> of course not
[09:17] <ogra_cmpc_> fine with me
[09:17] <pitti> it's publically logged anyway
[09:17] <lool> pitti: (Yeah, but I asked for politeness ;)
[09:17] <cjwatson> in oem-config-dm's case, it is told the display by its caller
[09:18] <cjwatson> but the same usually goes for xinit as called by startx, doesn't it?
[09:18] <lool> Yes
[09:18] <ogra_cmpc_> yep
[09:18] <cjwatson> I guess providing a display to startx isn't mandatory
[09:18] <lool> I think the act of creating the CK session in xinit makes sense; we just have to figure a way for it do provision the DISPLAY information
[09:19] <lool> From what I understand, xinit starts the server and then a client and it does know about the VT and the DISPLAY
[09:19] <lool> It just needs enough power to tell CK about it
[09:19] <cjwatson> the display manager could do that - it starts processes inside the display
[09:19] <asac> ArneGoetje: do you still need someone who still sees the scim issue?
[09:20] <cjwatson> oem-config-dm starts X, a window manager, stuff like gnome-settings-daemon, and the main "greeter" (in this case, oem-config
[09:20] <cjwatson> )
[09:20] <lool> cjwatson: But when you just "startx", you don't have a DM
[09:20] <cjwatson> right, I'm suggesting not using startx
[09:21] <lool> Yeah, I got your suggestion about using a DM for our concrete problem right now, but I thought we were back to discussing the CK fix for startx users
[09:21] <lool> Since after all this ought to work as well
[09:21] <cjwatson> oh, if we're talking *theory*
[09:21] <lool> Well would we fix startx we wouldn't have to use a DM either
[09:22] <cjwatson> maybe xinit needs to be setuid
[09:22] <lool> So I've noted that we have some sample DMs that I could look into, and I think we'll probably use that, but the original problem is about xinit CK awareness
[09:22] <cjwatson> and drop privileges when executing the client, obviously
[09:22] <lool> Perhaps we could tell CK to please update it's information by looking at DISPLAY?
[09:22] <lool> This kind of helper might not need any special rights at all
[09:23] <cjwatson> if you can't do OpenSessionWithParameters as root, then logically you ought not to be able to do the same thing in other ways
[09:23] <lool> "Hey, I think you should try to connect to :0.0 and see what VT it uses, you might want to add the data you find to your database"
[09:23] <cjwatson> if you can, then either consolekit's permissions are too strict, or we are attempting to exploit a security hole
[09:23] <cjwatson> which is all very well but not a good thing to build an application around
[09:23] <lool> Well OpenSessionWithParameters implies that the params will be trusted
[09:24] <lool> While what I'm proposing is that CK be pinged to please refresh its info
[09:24] <cjwatson> sorry, I meant "if you can only do OpenSessionWithParameters as root" above
[09:24] <cjwatson> CK does have helpers to figure stuff out from an X display
[09:24] <lool> Oh perhaps it's the only thing we're missing
[09:25] <lool> We have bits to start a session
[09:25] <lool> We just need to tell it about VT and DISPLAY of this session
[09:25] <lool> Hmm this is probably the security limit
[09:25] <cjwatson> you only need to tell it DISPLAY
[09:26] <cjwatson> (in theory)
[09:26] <ogra_cmpc_> and the content of DISPLAY needs to contain your hostname ... then the session will become active automatically i was told
[09:26] <lool> The security limit is probably related to "who are you to tell me what DISPLAY this CK session is using" I guess
[09:27] <lool> Ah well, let's just stop at the conclusions that xinit might need to be suid and that we should use a trivial DM for now
[09:27] <lool> Thanks all for discussion
[09:28] <ogra_cmpc_> thanks for answering my question :)
[09:28]  * ogra_cmpc_ beats i810 with a bat
[09:28] <ogra_cmpc_> why the heck does that thing eat 50M extra if i use it ...
[09:29] <cjwatson> lool: have you tried just calling org.freedesktop.ConsoleKit.Manager.OpenSession?
[09:29] <cjwatson> and letting it guess?
[09:30] <cjwatson> of course the process that calls that needs to run for the lifetime of the session, otherwise dbus will notice and close the session on you
[09:30] <cjwatson> so it can't just be dbus-send
[09:30] <cjwatson> (we need a dbus-send --exec=command or something)
[09:30] <lool> cjwatson: I didn't try this
[09:32] <lool> I wonder why I didn't try to start the session under Xorg
[09:32] <cjwatson> it looks in /proc/blah/environ to fish out DISPLAY
[09:33] <lool> But just ck-launch-session from within Xorg should simply work
[09:33] <ogra_cmpc_> and i wonder why we dont make it mandatory to have that dbus call in x-session-manager ...
[09:33] <ogra_cmpc_> that way we wouldnt need to hack up all display managers
[09:33] <lool> I'll try to hook it to Xsession.d
[09:34] <cjwatson> does ck-launch-session spawn a subprocess with the rest of your session?
[09:34] <lool> I don't know; we don't have it; I think it does based on the xinit patch I've seen from fedora
[09:35] <lool> http://cvs.fedoraproject.org/viewcvs/devel/xorg-x11-xinit/xinitrc?r1=1.3&r2=1.4
[09:35] <cjwatson> yes, it appears to
[09:35] <cjwatson> http://gitweb.freedesktop.org/?p=ConsoleKit.git;a=blob;h=73111816d3785996ee25c18dc24e0a3657272428;hb=4740245c6f6137175ef51be2207c35185f4d98f1;f=tools/ck-launch-session.c
[09:35] <cjwatson> that would be perfect, then
[09:36] <lool> I really have a brain bug
[09:36] <cjwatson> it wraps OpenSession, not OpenSessionWithParameters
[09:36] <cjwatson> so it doesn't require root
[09:36] <lool> So it exactly does what it's supposed to do: look at the DISPLAY of the calling process
[09:36] <cjwatson> so the whole discussion above is overengineering :-)
[09:36] <lool> Ok, let us ship a Xsession script within consolekit then?
[09:37] <cjwatson> hmm, it should only call ck-launch-session if XDG_SESSION_COOKIE isn't already set
[09:37] <cjwatson> but yes, that does sound like a good solution
[09:37] <lool> Sure
[09:37] <doko> pitti: please demote the python-qt4-gl binary package, we don't want to have the pyopengl dependency in main
[09:39] <pitti> doko: hm, that's not in component-mismatches; I wonder what holds it in main
[09:39] <pitti> (argh, ENOSSH again)
[09:39] <doko> pitti, hmm I see it there
[09:40] <YokoZar> I have a package (zsnes) that recently started building on amd64.  The last upload added amd64 arch to the control file, and it builds fine if I use dpkg-buildpackage.  However, looking it up on launchpad, the build daemon isn't even trying to build it on amd64, and gnome-app-install has it unclickable still
[09:40] <pitti> doko: I don't
[09:40] <pitti> doko: (should be in 'binary-only demotion')
[09:41] <doko> http://people.ubuntu.com/~ubuntu-archive/component-mismatches.txt shows it in "Source and binary promotions to main"
[09:42] <pitti> doko: right; most likely it's just held in main as part of a "rescued..." (i. e. trying to keep all binaries in main)
[09:42] <pitti> doko: once I get back ssh, I'll demote it
[09:42] <lool> cjwatson: Interestingly, it also means starting a CK session from PAM would be harmful
[09:46] <Mirv> seb128: there's a rather weird problem that came with today's updates: tsclient and policykit-gnome lost their .desktop translations and f-spot reverted to upstream's (tested with two machines). any idea if it's a bug in language packs or somewhere else?
[09:47] <seb128> Mirv: what did you update?
[09:47] <seb128> Mirv: tsclient didn't change for a while, not like due to it, did you update language packs today?
[09:48] <Mirv> seb128: everything since yesterday, it's hard to say but indeed tsclient lost its X-Ubuntu-Gettext-Domain patch already months ago but somehow the .desktop translation was there until today. I did update the language packs, but I'm not sure what the actual problem is.
[09:48] <Mirv> policykit-gnome never even had that tag, but somehow the translation was there until today
[09:49] <Mirv> (and there's no upstream translation for policykit-gnome)
[09:49] <Mirv> seb128: the translations for the .desktop items are still there in the .mo files for all of those three
[09:49] <seb128> ah, I know
[09:49] <seb128> will fix it
[09:50] <seb128> it's all lool fault ;-)
[09:50] <seb128> he asked for a glib2.0 sync
[09:50] <seb128> but we have a gettext patch there which is not in the debian serie
[09:50] <Mirv> seb128: whee, great. I feel so like a poor bug reporter since I have no clue what happened :)
[09:50] <seb128> fixing it now
[09:54] <TheMuso> n/
[09:54] <TheMuso> ugh
[09:56] <seb128> carlos: how do you build your "not uptodate list"?
[09:56] <seb128> carlos: ie, gnome-desktop is on it but the build log indicates that it generates a pot correctly, is that just because it was waiting for rosetta import when you made the list?
[10:00] <YokoZar> https://edge.launchpad.net/ubuntu/+source/zsnes/1.510-2ubuntu1   <--- note how architectures = i386 and amd64, but there is no build attempt for amd64 (successful or failed). What do I do here?
[10:01] <lool> doko: I think it would be excellent if we could get PySignal_SetWakeupFd() in our python
[10:01] <lool> doko: Do you think that's risky/doable?
[10:01] <cjwatson> lool: not if XDG_SESSION_COOKIE were set, which it would be
[10:01] <lool> cjwatson: Well if we don't start a session when XDG_SESSION_COOKIE is set, how does CK know about the display?
[10:02] <lool> doko: Background in http://bugzilla.gnome.org/show_bug.cgi?id=481569
[10:02] <lool> doko: This is included in our pygobject and pygtk
[10:04] <ArneGoetje> asac: if you have time, please do. :)
[10:06] <doko> lool: hmm, I thought I had this done, but apparently not ...
[10:06] <Riddell> pitti: I'm fine with dropping hwdb-client-kde.  I'd like to see a Qt version of hwtest soon though if that's the replacement but obviously too late for hardy.
[10:07] <pitti> doko: demoted python-qt4-gl
[10:07]  * lool &
[10:08] <pitti> Riddell: thanks
[10:08] <carlos> seb128: I check that the upload date is newer than latest template update and that it's already published and that there is no .pot file in the import queue pending to be imported
[10:08] <pitti> Riddell: so, I'll just unseed it for Kubuntu then?
[10:09] <carlos> seb128: but I guess there may be some race conditions
[10:09] <seb128> carlos: ok
[10:09] <carlos> seb128: like gnome-desktop one
[10:09] <Riddell> pitti: I'll do it
[10:09] <pitti> Riddell: ok, please let me commit the changes to ubuntu/gobuntu first
[10:09] <pitti> Riddell: so that it can become  a proper merge
[10:10] <pitti> Riddell: committed to ubuntu.hardy, feel free to merge now
[10:12] <pitti> ogra_cmpc: would you mind merging the edubuntu.hardy seed? it's nontrivial
[10:12] <ogra_cmpc> pitti, you sure thats needed ? edubuntu depends on ubuntu-desktop
[10:13] <Riddell> pitti: merging the seeds doesn't really work any more
[10:13] <pitti> ogra_cmpc: ah, right, seems it's not; so they are not real branches any more
[10:13] <ogra_cmpc> right
[10:13] <pitti> Riddell: I see; ok, then just kill hwdb-client, please
[10:13] <ogra_cmpc> there is a dependency chain in place now
[10:14] <pitti> hm, I still had to do it for gobuntu
[10:14] <pitti> seems that isn't converted yet then?
[10:14] <pitti> (maybe ubuntu should be on top of gobuntu, since ubuntu adds restricted stuff?)
[10:16] <TheMuso> 661/c
[10:16] <TheMuso> damn wireless keyboard needs resyncing again...
[10:16] <pitti> TheMuso: .00000220333333333333
[10:17]  * dholbach likes the new pitti-bot
[10:17] <dholbach> pitti: 100 Rupies in Euros
[10:18] <pitti> dholbach: 6250
[10:18] <YokoZar> pitti: poke
[10:18] <pitti> hi YokoZar
[10:18] <pitti> TheMuso: .00000220485870603287 actually :)
[10:18] <YokoZar> pitti: Any idea why the buildd doesn't seem to be attempting to build this on amd64?  https://edge.launchpad.net/ubuntu/+source/zsnes/1.510-2ubuntu1
[10:18] <TheMuso> pitti: heh
[10:18] <dholbach> . o O { pitti-bot needs a serious update }
[10:19] <YokoZar> pitti: amd64 was added to control as an arch last upload
[10:19] <pitti> YokoZar: control file has Architecture: i386 here
[10:19] <pitti> in 1.510-1
[10:19] <YokoZar> Err that link is to 1.510-2ubuntu1
[10:20] <YokoZar> Which is newer
[10:20] <pitti> oh, it's in universe now, sorry
[10:20] <YokoZar> On the left of that page launchpad says its for amd64 and i386
[10:20] <pitti> I bet it's P-a-S'ed
[10:21] <YokoZar> Did it just get demoted or something?
[10:22] <pitti> $ grep zsnes /srv/launchpad.net/builddmaster/Packages-arch-specific
[10:22] <pitti> zsnes: i386     # Mostly written in i386 assembler
[10:22] <pitti> there we go
[10:22] <pitti> YokoZar: something for infinity or lamont to fix
[10:23] <YokoZar> pitti: Ahh, cool.  Should I bug them or you?
[10:23] <pitti> YokoZar: we keep them in sync with Debian, so I can't change them
[10:23] <ogra_cmpc> woah, i think vesa is the solution for all my probs i ever had on the classmate ....
[10:23]  * pitti wonders why it needs a Pas entry in the first place
[10:23]  * ogra_cmpc cant belive that
[10:23] <pitti> if the Architecture: is right, we shouldn't need it?
[10:23] <pitti> lamont, infinity: ^
[10:24] <pitti> ogra_cmpc: ... vesa? there goes your performance?
[10:24] <YokoZar> pitti: Yeah.  If the control file just says i386 no need to hardcode that elsewhere.
[10:24] <ogra_cmpc> pitti, exactly the opposite o_O
[10:24] <YokoZar> People have been managing to build it on amd64 according to forum posts (though the current version of the package is segfaulting for me)
[10:25] <YokoZar> By linking with 32 bit libraries (in much the same way Wine works on 64 bit)
[10:26] <ogra_cmpc> pitti, well, performance migh get a very small not really noticeable overhead ... but it saves 50M ... which means i currently have a classmate that has firefox, aisle riot, abiword, gnumeric and two gnome terminals running at the same time and the system uses 170M of the acailable 241 ... and it still feels totally snappy
[10:27] <ogra_cmpc> *available
[10:27] <pitti> ogra_cmpc: awesome
[10:27] <pitti> YokoZar: ah, ia32-libs to the rescue? :)
[10:27] <ogra_cmpc> .... and i never even thought remotely about testing vesa here ... just did that by accident
[10:27] <cjwatson> lool: XDG_SESSION_COOKIE is set after the CK session is created, not the other way round
[10:28] <cjwatson> pitti: I didn't quite get as far as converting the Gobuntu seeds to the new world order
[10:28] <YokoZar> pitti: Indeed.  We seem to be getting more dependent on it every release, when the intention was to use it as a temporary solution, heh.
[10:31] <pitti> it's a hideous hack and a maintenance nightmare (not even mentioning unfixed security bugs)
[10:31] <doko> pitti: please accept openjdk-6 (binary NEW)
[10:32] <YokoZar> pitti: Is there even a mechanism to push a new build of ia32-libs whenever one of its components gets a security update?  Right now it seems like packages need to be freshened manually
[10:32] <pitti> YokoZar: that's usually not a problem for the development release
[10:33] <pitti> but that thing bitrots fast in stables
[10:33] <YokoZar> On the plus side, only a few programs seem to depend on it
[10:36] <YokoZar> On the down side, we're never going to get Wine to not depend on it (or separately made 32 bit versions of all the 20+ components it uses ala lib32z1), and Wine isn't going away.
[10:37] <YokoZar> Actually I wonder if this would be a worthwhile project for Hardy +1 -- slowly phasing out everything in ia32-libs into separate lib32foo type packages
[10:37] <RAOF> YokoZar: Please implement multiarch dpkg.  kthxbye
[10:38] <pitti> YokoZar: that'll introduce a lot of source changes and complex multibuild setups
[10:38] <pitti> YokoZar: you should just be able to apt-get install an i386 deb on amd64 and be done with it
[10:38] <YokoZar> pitti: and have it magically go into /usr/lib32 ;)
[10:39] <pitti> there are other issues, like file conflicts to all other files to the amd64 .deb
[10:39] <pitti> so they would need some special magic, right
[10:39] <YokoZar> pitti: Yeah, it's a huge mess, which is why no one's really done it.  Still, would making lib32-* packages be less bad than ia32-libs?
[10:39] <pitti> but I guess the best answer for now is "if you can't live without i386, then install it and forget about amd64"
[10:40] <pitti> or, as a compromise, debootstrap an i386 chroot
[10:40] <Fujitsu> Is the default SCIMሆትከይ ጎኢንግ ቶ አህችናገ አት ሳኦመ ፖኢንት?
[10:40] <Fujitsu> Erm.
[10:40] <Fujitsu> That didn't work.
[10:40] <Fujitsu> Is the default SCIM hotkey going to change at some point?
[10:40] <pitti> Fujitsu: it's disabled by default again
[10:40] <Fujitsu> (for reasons shown above)
[10:40] <Fujitsu> Ah, good.
[10:40] <pitti> Fujitsu: for us poor souls^Wdaily upgraders, disable it in the language chooser
[10:41] <Fujitsu> What's such a thing doing in the tool traditionally used to install new languages?
[10:42] <YokoZar> pitti: I'm not sure we're ever going to get rid of 32 bit i386 support completely.  Especially because of Wine and all the 32 bit apps out there it'll want to run.  Hell, even MS can't get rid of 16 bit windows libs (Wine can handle these though ;) )
[10:43] <RAOF> There _was_ that multiarch spec lying dead on a Debian wiki somewhere.  Can it be resurrected?
[10:43] <pitti> YokoZar: why do you run amd64 in the first place then, if you need that many i386 apps?
[10:44] <YokoZar> pitti: Most users don't though.  They just need that one.  Which is about 90% of the use case of Wine, really - that one old legacy app.
[10:45] <TheMuso> pitti: I can think of one situation where I would want to run an amd64 app but also use i386 apps via wine. Its called audio production to use > 2GBof RAM for audi osamples, plus audio VTS plugins via wine for virtual instruments not availab el in Linux yet.
[10:46] <ogra_cmpc> mvo !!!!!!!!!!!!!!!!!
[10:47] <ogra_cmpc> mvo, i just installed atlantik from universe on the cmpc .... USING G-A-I !!!
[10:47]  * ogra_cmpc dances
[10:47] <mvo> ogra_cmpc: ROCK! what did you had to change to make it work?
[10:47] <ogra_cmpc> and that even with a gnome-terminal open running htop (which steals about 20M extra)
[10:47] <ogra_cmpc> mvo, using vesa
[10:48] <ogra_cmpc> that gained me more than 50M while only having a minimal performance loss
[10:48] <mvo> cool!
[10:48] <ogra_cmpc> my only prob now is that gdm starts up in panning mode (800x60)
[10:48] <ogra_cmpc> *600
[10:49] <YokoZar> So the last mail to the multiarch mailing list was in July 2006.
[10:52] <ogra_cmpc> seb128, is there any way that i could inject a xrandr call into gdm so it resizes the screen yo proper 800x480 ? i tried /etc/gdm/Init/ but that didnt seem to work
[10:52] <ogra_cmpc> s/yo/to/
[10:53] <seb128> ogra_cmpc: no idea
[10:53] <seb128> ogra_cmpc: why not updating the xorg configuration rather?
[10:55] <ogra_cmpc> seb128, becuse i need a panning mode ... my xorg.conf has a Virtual directive that sets the screen to 800x600 ... the i810 driver defaults gdm to what it gets from the display and uses panning in the session only ... vesa operates exactly the other way round, so i have a panning gdm screen
[10:56] <ogra_cmpc> seb128, and i would like to switch to vesa ... but that means convincing gdm to not start in the biggest size it can find in xorg.conf
[10:57] <ogra_cmpc> inside the session, even in Xsession.d a call to xrandr -s 800x480 works fine ...
[10:57] <ogra_cmpc> just not for the initial screen
[10:58] <seb128> no idea about the issue
[10:58] <ogra_cmpc> well, isnt /etc/gdm/Init/Default to be executed after X is up and beforre the greeter shows up ?
[11:01] <YokoZar> pitti: I think having a discussion about how to best kill ia32-libs is a good idea for next UDS ;)
[11:01] <seb128> ogra_cmpc: look to the gdm documentation, it tries :0, hostname, and then default
[11:01] <seb128> ogra_cmpc: maybe you have one of the others which is used?
[11:01] <pitti> YokoZar: heh, yeah
[11:02] <seb128> ogra_cmpc: I never tried that though so I'm not sure if it works correctly
[11:02] <ogra_cmpc> seb128, thanks i'll look i dont have anything inside /etc/gdm/Init but Default though
[11:02] <seb128> ogra_cmpc: upstream are responsive on their list
[11:02] <ogra_cmpc> ok
[11:02] <seb128> you can try there
[11:03] <soren> Can someone who has just a smidgeon of emacs knowledge grab bug 188218? I have *no* clue.
[11:03] <ogra_cmpc> well, mccann is a resident in #ltsp recently i'll ping him this afternoon
[11:05] <asac> ArneGoetje: [reed] in #ubuntu-mozillateam appears to still have issues
[11:06] <jdstrand> doko, cjwatson, slangasek: as the author of ufw, I still believe shorewall should be in main. ufw works well as a host-based firewall, but shorewall is more complete (routing firewall, qos, etc)
[11:07] <cjwatson> jdstrand: ok, that's good to know, thanks
[11:08] <jdstrand> ufw won't hinder qos or routing mind you, but it doesn't help any more than iptables-restore helps in that regard
[11:30] <TheMuso> Wow! First time I've been able to reliably differ between my user being in, and not being in, the pulse-rt group for pulseaudio...
[11:33] <TheMuso> tjaalton: Yeah I've seen that pulse hangs around after logout. I'll confirm your bug now, but don't have any ideas at this point.
[11:34] <tjaalton> TheMuso: cool
[11:37] <TheMuso> Hrm. What package is responsible for GNOME's logging out? I wonder if it tries to kill a non-existant esd process, and simply needs a tweak to killa pulseaudio process...
[11:38] <soren> TheMuso: gnome-session, I guess.
[11:38] <seb128> they moved esd things out of there though
[11:38] <seb128> now gnome-settings-daemon does the server init
[11:38] <seb128> I don't think anything try to stop esd on logout
[11:39] <TheMuso> seb128: Yeah, thats what I'm trying to remember. I don't remember if esd used to get killed on logout either.
[11:39] <tjaalton> I've used the gdm PostSession hooks to kill stray processes
[11:39] <seb128> TheMuso: gnome-session used to do that
[11:40] <TheMuso> seb128: Right, so I guess if esd was used now, similar behavior would be experienced.
[11:40] <seb128> what is the issue?
[11:40] <TheMuso> Hrm, I'll have to test that one.
[11:40] <TheMuso> seb128: After one logs out, pulseaudio is still running.
[11:41] <TheMuso> bug 201359
[11:42] <seb128> TheMuso: shouldn't it autoexit if nothing is using it for some time?
[11:43] <TheMuso> seb128: It releases its hold on the sound device yes, but it doesn't shut down/kill itself if thats what you mean.
[11:43] <seb128> it should
[11:43]  * TheMuso logs out of another box with pulse running, and lets it sit to see what happens...
[11:50] <Hobbsee> die scim, die.
[11:51] <Hobbsee> hm
[11:51] <Hobbsee> i can't even run any commands on the command line, as scim puts my text into chinese or something.
[11:51] <Hobbsee> way cool.  whenever i hit "c"
[11:53] <Hobbsee> or v.
[11:53] <Hobbsee> yet whenever i purge it, my apps all take forever to come up, and start crashing.
[11:54] <Hobbsee> and exit doesn't exit the thing.
[11:55]  * Hobbsee sets it back to the english/european again
[11:56] <Hobbsee> and now space.
[11:57] <ogra_cmpc> seb128, gdm behaves sane, its xrandr thats mad with my issue
[11:57] <seb128> ogra_cmpc: ok, good ;-)
[11:58] <jdstrand> cjwatson, doko, slangasek: IMO, ufw should stay in standard seed and shorewall in supported, or 'desktop-supported' if that ever comes to be
[11:59] <jdstrand> ufw is very well suited for desktops and bastion hosts
[11:59] <TheMuso> Ok, as expected, after a box sitting there for 5 minutes doing nothing after logging out of GNOME with pulse being active in the user session, the pulseaudio process is still active.
[12:00] <doko> jdstrand: ok, I'll readd shorewall to the supported seed
[12:00] <jdstrand> doko: thanks!
[12:07] <Hobbsee> hurrah.  purged enough, all the way down to im-switch.
[12:07] <Hobbsee> i can type multiple words in non-kde programs now!  \o/
[12:07] <Hobbsee> instead of a few letters, then nothing.
[12:13] <cjwatson> Hobbsee: 'sudo update-alternatives --auto xinput-all_ALL' should have cleared it up
[12:13] <cjwatson> or language-selector, check and uncheck the checkbox
[12:13] <lool> cjwatson: What I mean is that if we don't create a new session in the new Xsession snippet, and rely on one created by pam-ck-connector, the session will lack info on the new DISPLAY, no?
[12:14] <lool> So this would mean that if the XDG COOKIE thing is set, we should probably remove it and create a new session
[12:14] <cjwatson> lool: don't use pam-ck-connector then
[12:14] <cjwatson> I think if it is used then you should trust it and leave it alone
[12:14] <cjwatson> the display manager might have known what it was doing
[12:14] <cjwatson> in your case, you should take care not to use pam-ck-connector
[12:15] <lool> Hmm ok
[12:15] <lool> I hope they don't merge the xinit CK support then
[12:15] <cjwatson> if they do, one hopes that they would arrange to tell it about DISPLAY
[12:16] <Hobbsee> cjwatson: grumble.  that wasn't on the bug, but thanks.
[12:27] <ion_> doko: Since you made the last kexec-tools change, perhaps you’d be interested in bug #201094 (there’s a debdiff).
[12:28] <ion_> doko: Oh, no URL bot. https://bugs.launchpad.net/ubuntu/+source/kexec-tools/+bug/201094
[12:28] <doko> ion_: debdiff?
[12:29] <doko> ahh, int the report
[12:30] <ScottK2> doko: I've run into what appears to be a python-central (or some python tool chain) problem in my python-xml transition work.  When I test build eric python:depends claims it depends on python-central 0.6 (which obviously isn't going to work).  Same package built against Sid wants python-central 0.5.8.
[12:32] <doko> ScottK: why not?
[12:32] <ScottK2> Do we have 0.6 in Ubuntu and I missed it?
[12:32]  * ScottK2 looks
[12:33] <ScottK2> Sure enough
[12:33] <ScottK2> doko: Nevermind.  Looks like my pbuilder was more up to date than my system.
[12:33] <doko> heh
[12:36]  * ScottK2 makes note about having test box pointing at a mirror when the pbuilder points at a.u.c.
[12:52] <cjwatson>   * Add 100_sloppy_lock.diff, which reverses the locking logic, ie. sloppy
[12:52] <cjwatson>     locking is the default. To disable that, set the environment variable
[12:52] <cjwatson>     LIBXCB_DISABLE_SLOPPY_LOCK to any value. (LP: #87947)
[12:52] <cjwatson> tjaalton: I hope that's "any value other than 1"?
[12:52] <cjwatson> tjaalton: ... oh, never mind, it was previously LIBXCB_ALLOW_SLOPPY_LOCK not DISABLE
[12:55] <lool> cjwatson: I saw your comments on policy on update-alternatives; I believe update-rc.d is in a similar situation with the new sysv replacements
[12:55] <lool> (e.g. we had to update-rc.d remove forcefully dbus on upgrades to move it around the init sequence)
[12:55] <cjwatson> kind of, though that's in exceptional cases rather than routine
[12:55] <cjwatson> in the case of update-alternatives, you get this problem all the time
[12:56] <lool> Sure; the similarities made me want to mention them to you though
[12:56] <doko> ion_: done
[12:56] <ion_> doko: Thanks
[12:59] <cjwatson> lool: yeah, there are definitely similarities elsewhere; I'm mostly trying to get it through Manoj's head that it's worth documenting
[12:59] <cjwatson> not least because I don't even know the most correct way to use it, and I've studied it
[13:06] <TomaszD> \sh, hi. Remember https://bugs.launchpad.net/ubuntu/+source/wine/+bug/198761 ? Someone screwed up along the way, because it seems the translation was copied and pasted from the browser window, without changing the encoding to UTF8, now the translation looks horrible.
[13:07] <\sh> TomaszD: please file a bug :) YokoZar or I are dealing with it
[13:07] <TomaszD> \sh, right-o.
[13:07] <\sh> TomaszD: thx :)
[13:07] <YokoZar> TomaszD: my fault.  I thought I enabled the locale in firefox before doing that, apparently not
[13:07] <jdstrand> pitti: I told apport to ignore further crashes with a particular version, is there a way to 'unignore'? (please just point me to docs if it's written up somewhere)
[13:08] <YokoZar> TomaszD: Just reopen that bug actually
[13:08] <TomaszD> YokoZar, ok.
[13:09] <TomaszD> YokoZar, done
[13:12] <pitti> jdstrand: just remove ~/.apport-ignore.xml, or edit it if you need other ignores
[13:12] <jdstrand> pitti: ah thanks
[13:13] <jdstrand> pitti: actually it was /root/.apport-ignore.xml here
[13:13] <pitti> ah, for system crashes, yes
[13:16] <seb128> lool, Mithrandir: can any of you look to bug #190700 (gnome-bluetooth new version sponsoring request)? it looks easy, if you don't I'll do it
[13:17] <TheInfinity> tjaalton, bryce: hmm ... just a question for a bug - can you look at https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/196242 soon if you have some time for this? because its difficult to make alphatesting of live cd without xorg ... thanks :)
[13:21] <tjaalton> TheInfinity: 64bit with nvidia?
[13:21] <TheInfinity> tjaalton: yes
[13:22] <tjaalton> TheInfinity: try disabling usplash with nousplash
[13:22] <tjaalton> TheInfinity: on the kernel cmdline
[13:22] <TheInfinity> ok i'll test it :)
[13:51] <seb128> hum
[13:51] <seb128> is anybody looking at updating consolekit in hardy?
[13:51] <seb128> we have 0.2.3 where upstream has 0.2.10
[13:52] <pitti> seb128: anything that we particularly need from the new version?
[13:52] <pitti> seb128: there was a huge discussion about that new CK feature to control shutdown/reboot, and many people want it reverted
[13:52] <ogra_cmpc_> pitti, didnt you talk bout ck-register-session before today ?
[13:53] <ogra_cmpc_> that would likely require the new version
[13:53] <pitti> right
[13:53]  * ogra_cmpc_ scratches head about whiptails menu function ...
[13:53] <pitti> but I'm not comfortable with updating such a fundamental thing now just because it's a new version number
[13:54] <pitti> IOW, we should consider it if the new version has things we really need
[13:54] <seb128> pitti, TheMuso: discussing with a redhat guy the esd not stopped on logout issue
[13:54] <pitti> seb128: pulse in our case?
[13:54] <seb128> yes
[13:54] <pitti> ah
[13:54] <seb128> he says that consolekit is supposed to revoke the right on the sound device
[13:55] <ogra_cmpc_> so i have a tag and an item for every line in the whiptail --menu function ... with --noitem it supresses the item, else it shows both  ... if i select somethng tag is returned .... why do i have item at all then ?
[13:56]  * ogra_cmpc_ doesnt understand the purpose ... apart from adding comments or so as item text
[13:56] <seb128> pitti: do you know what set the permission on the sound device at login?
[13:56] <pitti> seb128: how on earth should CK revoke access to the soundcard?
[13:56] <ChickenCutlass> I would vote for upgrading to the new consolekit -- UME needs the new utility ck-launch-session, that is included
[13:57] <pitti> seb128: it never changes in Ubuntu, it's always root:audio 660
[13:57] <seb128> pitti: I don't understand how the thing work
[13:57] <pitti> seb128: we haven't CK'ized sound card device access yet
[13:57] <pitti> (not sure we should either)
[13:57] <huats> seb128: I have put the debdiff for the new yelp
[13:57] <pitti> what we should do is to kill pulse on session shutdown
[13:57] <seb128> huats: thanks
[13:58] <huats> I am putting the bug number on the wiki...
[13:58] <huats> seb128: and thanks to you ;)
[13:58] <ogra_cmpc_> pitti, CK is still pretty immature imho ... the less we have of it in hardy the better
[13:59] <cjwatson> ChickenCutlass: there are other ways to deal with that, such as a backport
[13:59] <pitti> ogra_cmpc_: well, we have used it since gutsy, but we use it for more things in hardy admittedly
[13:59] <ogra_cmpc_> right
[14:00] <cjwatson> the Debian consolekit maintainer has some serious objections to the newer consolekit and refuses to update; there was a long thread on the hal list about it; while I'm not sure I necessarily agree, we shouldn't just ignore those objections
[14:00] <ChickenCutlass> cjwatson, true
[14:00] <cjwatson> and objections like that are a pretty good reason not to make such a substantial update during feature freeze
[14:00] <ogra_cmpc_> i dont say the code or design is flawed ... but its not been used in context much yet ...
[14:00] <pitti> it would just have been pretty much (pointless) work to work against upstream and make gnome work without CK/PK
[14:00] <ogra_cmpc_> and is still pretty much in flux
[14:01] <ogra_cmpc_> yeah
[14:01] <ogra_cmpc_> i dont say its our fault :)
[14:01] <ogra_cmpc_> i just think upstream switched to early
[14:01] <cjwatson> ChickenCutlass: I suspect a backport is fairly straightforward; when I looked at the ck-launch-session code it seemed fairly self-contained
[14:02] <ChickenCutlass> cjwatson, yes -- I already looked at it as well.  I am going to try it and see if it solves our problem this week
[14:10] <seb128> pitti: I've no real reason for the update, I just noticed we were many version behind and was wondering if that's an update we should consider
[14:10] <seb128> TheMuso: http://bugzilla.gnome.org/show_bug.cgi?id=522017
[14:15] <doko> lool: PySignal_SetWakeupFd is now uploaded, had it backported, but not applied. please wait until both python2.4 and python2.5 are built on all archs
[14:17]  * pitti wonders why our different hardy kernels switch back and forth between hda and sda (i. e. using scsi drivers for IDE drives)
[14:20] <ogra_cmpc> pitti, i thought that was generalized to scsi for everything now
[14:20] <pitti> right, I had that for quite a while
[14:20] <pitti> but nowadays I'm back to hda
[14:20] <pitti> BenC: ^ is that intended?
[14:21] <BenC> pitti: yeah, just needed settling down
[14:24] <soren> pitti: How do you notice that?
[14:25] <pitti> soren: well, I have /dev/hda*
[14:25] <soren> I know how to check it, sure, but I'd never notice if it changed on my box, I think.
[14:25] <soren> UUID based fstab ftw.
[14:25] <pitti> it just occured to me by accident, when I tried to run my 'test-fsck' script from a few weeks ago
[14:25] <pitti> yeah, UUIDs DTRT here for mounting
[14:26] <pitti> but the script died with pain and anger because /dev/sda3 didn't exist any more
[14:26] <soren> I was just surprised since we have the same laptop, and I hadn't noticed anything like that at all.
[14:27] <pitti> soren: I'm speakign about my desktop
[14:28] <pitti> soren: my laptop has SATA, I think they have always been treated as SCSI
[14:29] <soren> pitti: Oh, ok.
[14:33] <lool> doko: Cool, thanks!
[14:49] <Loevborg> I hope this is the right place to ask. I´m thinking about creating a modified version of ubuntu for the asus eeepx (small laptop w/ 4GB of flash disk). What I want to do is, among other things, add a modified madwifi driver and change some of the defaults of desktop applications.
[14:50] <Loevborg> For instance, thunderbird´s icons should be smaller by default.
[14:51] <Loevborg> So I think creating a custom USB stick install would be the right thing to do, and keep everything as close to ubuntu as possible. What I worry about is packages being updated to a stock Ubuntu version when apt-get updating.
[14:52] <Loevborg> Are there any active projects that do something like this, i.e. customize Ubuntu for specific hardware?
[14:53] <ogra_cmpc> Loevborg, i'm the guy developing the classmate version
[14:54] <ogra_cmpc> i have a builder script and an installer that works with such devices and creates an installable image out of a squashfs ... currently its classmate specific but i plan to make it more generic in intrepid
[14:55] <ogra_cmpc> Loevborg, http://people.ubuntu.com/~ogra/classmate/images/
[14:55] <ogra_cmpc> its *very* hw specific though and the classmate has way worse specs than the eeepc
[14:55] <Loevborg> ogra_cmpc: sounds great. So I guess you´re facing the same problems? Will you use standard ubuntu apt repository?
[14:55] <ogra_cmpc> but you could try out one of these :)
[14:55] <ogra_cmpc> indeed i will
[14:56] <ogra_cmpc> s/will/do :)
[14:56] <ogra_cmpc> there is only one universe package i add (915resolution) ... all the rest is standard
[14:56] <ogra_cmpc> from the main archive
[14:57] <Loevborg> is there a mailing list or something/
[14:57] <Loevborg> ?
[14:57] <ogra_cmpc> no
[14:58] <ogra_cmpc> i was thinking about starting a subnotebook desktop project
[14:58] <ogra_cmpc> bryce, ^^^ how about that ?
[14:58] <Loevborg> ogra_cmpc: that would be awsome
[14:58] <Nafallo> ogra_cmpc: eee covered?
[14:58] <ogra_cmpc> Nafallo, 800x480 low power machines covered
[14:59] <Nafallo> :-)
[14:59] <ogra_cmpc> not hw specific
[14:59] <bryce> ogra_cmpc: badly needed
[14:59] <ogra_cmpc> its about the desktop
[14:59] <Loevborg> there already are some EEEpc ubuntu customiyations, but they are hackish AFAICT
[14:59] <Nafallo> Loevborg: they really are.
[14:59] <Daviey> There is a asus eeepc kernel module
[15:00] <ogra_cmpc> Loevborg, the classmate one as well ... well, not hackish but for example not dist-upgradeable by design
[15:00] <Loevborg> I thought it is time for a soultion done right.
[15:00] <Nafallo> Daviey: that does what?
[15:00] <Daviey> Nafallo: Gives you extra ACPI control
[15:00] <ogra_cmpc> the prob is that you cant do it right if you go with such heavy desktop HW
[15:00] <ogra_cmpc> s/HW/SW
[15:00] <Nafallo> Daviey: ah. the overclock button :-P
[15:00] <ogra_cmpc> and with heavy i include xfce here ....
[15:01] <Loevborg> Daviey: yes, the eeepc might need a custom kernel. Or maybe it doesn´. It would be better if it worked without one.
[15:01] <Daviey> Nafallo: been to scared to try that - more switching the fan off :)
[15:01] <Daviey> too*
[15:01] <ogra_cmpc> Loevborg, i thinnk it works without specific kernel changes ... but ypou need extra stuff for wlan etc
[15:02]  * ogra_cmpc envys the eee users for their HUGE keyboard
[15:02] <Daviey> Loevborg: imo, there isn't a problem with big customisations - providing it's all packaged and a subnotebook-desktop meta package created :)
[15:02] <Loevborg> ogra, yes, the keyboard perfectly usable
[15:03] <Loevborg> Daviey: what about changed font defaults for thunderbird etc.? that´s what makes the default xandros on the eeepc neat.
[15:04] <Loevborg> ogra_cmpc: where do I find the script you mentioned?
[15:04] <ogra_cmpc> on my build machine
[15:04] <ogra_cmpc> as soon as i'm done (end of teh week) i'll release a bzr branch
[15:05] <Daviey> Loevborg: I think that is a whole custom theme for thunderbird
[15:05] <Daviey> and one for FF AIUI
[15:05] <Loevborg> ogra, could you drop me a line when it´s done?
[15:05] <ogra_cmpc> sure
[15:05] <ogra_cmpc> Loevborg, btw http://people.ubuntu.com/~ogra/LightBrowser/
[15:05] <ogra_cmpc> and bryce works on a 800x480 inkscape version atm
[15:06] <Daviey> ooo, that is lightweight
[15:06] <Daviey> ogra_cmpc: gecko based?
[15:06] <bryce> ogra_cmpc: that was just a prototype/proof-of-concept btw, I'm not actively developing that - it was just to stimulate other inkscape developers to work on
[15:07] <ogra_cmpc> Daviey, xulrunner based
[15:07] <bryce> ogra_cmpc: good news is that several people are already working actively on that for 0.47
[15:07] <ogra_cmpc> bryce, cool
[15:07] <Daviey> Loevborg: I'd quite like to get involved with this.
[15:07] <ogra_cmpc> i'm looking for a javascript eager develope to take over lightbrowser :)
[15:08] <Loevborg> Daviey: so a custom ff/thunderbird can just be dropped in without changing the ff/tb package?
[15:08] <Daviey> i'm yet to meet a developer keen on js
[15:08] <bryce> ogra_cmpc: https://blueprints.launchpad.net/inkscape/+spec/kidscape-project,https://blueprints.launchpad.net/inkscape/+spec/toolbar-resize
[15:08] <Daviey> Loevborg: hmm, might need a package on top that depends on standard FF/TB
[15:09] <ogra_cmpc> oh, wow, you specced it already
[15:10] <Loevborg> Daviey: Cool. It would be great to have a few people working on a general solution. so you also have an eee?
[15:11] <Daviey> Loevborg: I have 2 :)
[15:15] <Loevborg> ogra_cmpc: my email address is pesterhayz@gmx.net btw
[15:15] <Loevborg> rats
[15:15] <Loevborg> ogra_cmpc: pesterhazy@gmx.net
[15:16] <ogra_cmpc> oki
[15:16] <ogra_cmpc> ogra@ubuntu.com fwiw
[15:21] <mvo> tseliot: thanks for your mails, I will answr today
[15:31] <tseliot> mvo: thanks :-)
[15:32] <ScottK2> slangasek: Do you have any feelings either way about further new package exceptions for OLPC/Sugar related packages?
[15:33] <ogra_cmpc> ScottK, getting the squeak update ready (and past the license police) would also be a good thing (tm)
[15:33] <ogra_cmpc> i know its used a lot on OLPC
[15:33] <ogra_cmpc> (as well as in edubuntu :) )
[15:33] <ScottK2> ogra_cmpc: I'm not packaging it, I'm just trying to get some RM feedback to help decide on a Universe FFe.
[15:34] <ogra_cmpc> ah
[15:39] <pitti> mvo: did you ever encounter bug 174128 again?
[15:39] <ubotwo> Launchpad bug 174128 in dhcp3 "asks debconf question on dapper->hardy upgrade" [Undecided,Incomplete] https://launchpad.net/bugs/174128
[15:39] <ion_> doko: kexec-tools failed to build because something set LDFLAGS=-Wl,-Bsymbolic-functions and the Makefile did ld $(LDFLAGS) instead of cc $(LDFLAGS). I’ll post a debdiff in a while. Should i use 20070330-4ubuntu2 or 20070330-4ubuntu3?
[15:42] <kbueno> !ciao
[15:42] <ubotwo> How should I know?
[16:11] <ion_> doko: Here’s a debdiff that should fix the FTBFS: http://heh.fi/tmp/kexec-tools_20070330-4ubuntu2.debdiff. I hope it’s ok i used 20070330-4ubuntu2 as the version number instead of bumping it.
[16:27] <geser> ion_: it needs a new version, as -4ubuntu2 already exists in the archive (in this case only a source)
[16:37] <slangasek> ScottK2: well, my feeling is that it would be nice to have some follow-through on things like bug #183021, #183015, #183017 before piling in new packages...
[16:37] <ubotwo> Launchpad bug 183021 in sugar-datastore "package-installs-python-pyc" [High,Confirmed] https://launchpad.net/bugs/183021
[16:37] <ubotwo> Launchpad bug 183015 in sugar-presence-service "python-script-but-no-python-dep" [Medium,Confirmed] https://launchpad.net/bugs/183015
[16:37] <ubotwo> Launchpad bug 183017 in sugar-datastore "python-script-but-no-python-dep" [Medium,Confirmed] https://launchpad.net/bugs/183017
[16:40] <ScottK> slangasek: Thanks.
[16:40] <ion_> geser: Alright, thanks.
[16:45] <jdstrand> keescook: re bug #144900
[16:45] <ubotwo> Launchpad bug 144900 in usplash "usplash crashed with SIGSEGV in __svgalib_get_perm()" [Medium,Confirmed] https://launchpad.net/bugs/144900
[16:46] <jdstrand> I rebooted into the -12 kernel and it crashed.  I then rebooted back into the -11 kernel and it did not
[16:47] <jdstrand> I only did each reboot once though
[16:50] <ion_> doko: http://heh.fi/tmp/kexec-tools_20070330-4ubuntu3.debdiff
[17:54] <bdmurray> pitti: I've heard of a couple of apport-crashes where ubuntu-crashes-universe had to be subscribed manually
[17:58] <compbrain> wth does &>> not work in bash?
[18:05] <pitti> bdmurray: probably because apport-retrace was buggy at that time (broken p-lp-bugs), so it removed the tag, and then crashed before sub'ing the team
[18:07] <bdmurray> pitti: okay, its working now?
[18:09] <slangasek> compbrain: instead of >>  2>&1 ?
[18:12] <pitti> bdmurray: yes, should
[18:22] <keescook> jdstrand: usplash crash> does it crash every time you boot -12 ?
[18:22] <jdstrand> keescook: I knew you were going to ask that ;)
[18:22] <keescook> haha
[18:22] <jdstrand> keescook: I can't reboot right now, but I'll let you know
[18:23] <keescook> jdstrand: okay, I think I saw this crash when I booted -12 for the first time (when snd was missing), but on the next attempt, it didn't (with working snd)
[18:23] <compbrain> slangasek: Yeah.
[18:23] <compbrain> zsh does the right thing, bash bails
[18:23] <jdstrand> keescook: maybe I don't understand usplash at all, but am curious why snd has anything to do with it
[18:23] <keescook> what's very very odd-ball about the crash is that it's during an "in" instruction ... the only way that can crash is if the kernel allowed the ioperm() call, and then later revoked it... which ... I thought wasn't possible
[18:24] <keescook> jdstrand: right, I doubt that's the cause, but I meant I'm suspicious of -12 too
[18:24] <keescook> I'll try a few reboots now for fun... :P
[18:24] <jdstrand> keescook: I see
[18:24] <slangasek> compbrain: "the right thing" is defined by the documentation of the app in question; that's not standardized by any stretch of the imagination
[18:26] <cjwatson> compbrain: FYI, http://www.opengroup.org/onlinepubs/009695399/utilities/xcu_chap02.html#tag_02_07 is the standard for shell redirections
[18:27] <jdstrand> keescook: well, maybe I'm still seeing the crash because my nvidia driver doesn't load anymore
[18:28] <jdstrand> keescook: based on our conversation, and I don't know why this would be the case at all, if there is some sort of error on boot then usplash crashes
[18:35] <cjwatson> mathiaz: I don't understand how bug 193696 is an installer bug
[18:35] <ubotwo> Launchpad bug 193696 in postgresql-8.3 "Postgresql 8.3 not installed on hardy-server - unable to create /dev/null" [Low,Invalid] https://launchpad.net/bugs/193696
[18:36] <cjwatson> mathiaz: d-i most definitely doesn't create a system with a broken /dev/null, or we'd know about it from more than pg :-)
[18:39] <mathiaz> cjwatson: hum.. So where the message "Mar 11 03:19:59 in-target: SH: CANNOT CREATE /DEV/NULL: PERMISSION DENIED^M" would come from ?
[18:40] <cjwatson> mathiaz: are you sure your bug is the same as Murray's? Even if it is, all you've demonstrated is that postgres fails in both scenarios
[18:40] <ogra_cmpc> /etc/udev/rules.d/40-permissions.rules ?
[18:41] <cjwatson> mathiaz: Murray says it fails outside d-i, you say it fails inside d-i. That doesn't suggest a d-i bug
[18:41] <mathiaz> cjwatson: right - I start to think that murray's bug is different
[18:41] <cjwatson> mathiaz: they may well be the same
[18:41] <mathiaz> cjwatson: well - an apt-get install postgresql-8.3 works for me in hardy
[18:41] <cjwatson> all I'm saying is you haven't demonstrated it either way :)
[18:42] <mathiaz> cjwatson: correct - I'll try to look into that.
[18:42] <cjwatson> if you can't reproduce Murray's problem in a similar environment, we need to talk with Murray to find out how his environment differs
[18:43] <cjwatson> mathiaz: also, checking permissions on /target/dev/null when that happens would be useful
[18:43] <mathiaz> cjwatson: right - so I may need to open a new bug then.
[18:43] <cjwatson> mathiaz: please don't yet
[18:43] <cjwatson> mathiaz: another possibility is that some other package is trashing /dev/null
[18:43] <cjwatson> for example, if a maintainer script did 'rm /dev/null' (or similar) before postgresql-8.3 is installed, then you'd see these symptoms
[18:43] <mathiaz> cjwatson: ok - but there is definetly a bug with the postgresql tasksel in d-i.
[18:43] <ogra_cmpc> wow, intresting that you are actually the first person on the bug asking for ls output of /dev/null
[18:43] <cjwatson> mathiaz: and that would not be a d-i bug, but a bug in the package that does this
[18:44] <mathiaz> cjwatson: whether it's the same bug as the one reported by murray is still be discussed
[18:44] <cjwatson> indeed, but it may well provide clues
[18:44] <cjwatson> I will download the Hardy server CD and try to reproduce as well
[18:44] <mathiaz> cjwatson: this has been around at least since alpha3
[18:45] <cjwatson> if a package is indeed trashing /dev/null, then that's very serious and may well be biting people in all kinds of ways
[18:45] <cjwatson> and it would be easy to ask if Murray has that package installed
[18:47]  * ogra_cmpc wonders what happens if something cats to /dev/null before udev it creates ... does udev just overwrite it ?
[18:48] <slangasek> ogra_cmpc: debootstrap is supposed to create /dev/null as part of its initial chroot
[18:49] <ogra_cmpc> h, indeed, no udev running inside the chroot ..
[18:52] <slangasek> isn't udev supposed to be involved in setting up in-target nodes, so that bootloaders work right?
[18:53] <cjwatson> slangasek: yes, it is
[18:53] <cjwatson> slangasek: but that doesn't prevent some maintainer script removing a node that udev had previously created
[18:53] <slangasek> yes, true
[18:54] <slangasek> I was just wondering about ogra_cmpc's comment about no udev running inside the chroot; I don't know whether there's supposed to be, or if it's handled by the main process running outside the chroot
[18:56] <cjwatson> udev is bind-mounted into /target by base-installer
[18:56] <cjwatson> I didn't see ogra_cmpc's comment due to ISP breakage
[18:57] <slangasek> ah, so
[18:57] <cjwatson> oh, actually, that bind-mount is just for the duration of base-installer and doesn't in general apply to in-target
[18:58] <ogra_cmpc> not in d-i: before udev runs there is a static dev with the most basic devices you need ... that gets moved to /dev/.static/dev  if udev starts up
[18:58] <ogra_cmpc> i guess thats the /dev deboostrap created
[18:58] <cjwatson> MAKEDEV creates /dev/null with proper permissions though
[18:59] <cjwatson> $ deb-extract-file /mirror/ubuntu/pool/main/d/debootstrap/debootstrap-udeb_1.0.8_all.udeb ./usr/share/debootstrap/devices.tar.gz | tar tzvf - | grep null
[18:59] <cjwatson> crw-rw-rw- root/root       1,3 2008-01-15 12:48 dev/null
[18:59] <slangasek> it also shouldn't be 'cannot create [...]' if it were a permissions error, either
[18:59] <cjwatson> right
[18:59] <cjwatson> if /dev/null had been removed, then the next thing to do >/dev/null would need to have write permission to /dev
[19:00] <cjwatson> which would be consistent with the error message
[19:00] <cjwatson> we've seen occasional instances of /dev/null winding up as a regular file, but never been able to track them down; those are almost certainly caused by something removing /dev/null, too
[19:00] <cjwatson> (since if the next thing to write to /dev/null is running as root, it can create it as a regular file)
[19:01] <candrews> https://bugs.launchpad.net/ubuntu/+bug/199754 That package has been completed, builds, and works on Ubuntu. How does it get included in the repository?
[19:01] <ubotwo> Launchpad bug 199754 in ubuntu "[needs-packaging] mod_auth_cas" [Wishlist,Incomplete]
[19:03] <ogra_cmpc> candrews, through REVU ... the guys in #ubuntu-motu cen help you
[19:03] <ogra_cmpc> *can
[19:04] <candrews> thank you - I'll redirect my question there
[19:21] <juliank> Could we get ndisgtk added to the ship and ship-live seeds (amd64,i386)?  I am no core-dev, so I can't do this.
[19:22] <ogra_cmpc> juliank, the quesion is why ...
[19:22] <ogra_cmpc> ... are you no core-dev yet :)
[19:23] <ogra_cmpc> juliank, do you know if that was discussed and agreed on ?
[19:26] <juliank> ogra_cmpc: The MIR bug got "Fix released" and pitti wrote: " - get it seeded to somewhere, so that it will stay in main", that's what I want to do now. What is needed to do this?
[19:28] <rsc> Good evening. Is somebody able to tell me, whether Ubuntu builds ships openssl linked against kerberos5 per default?!
[19:30] <compbrain> slangasek: Yeah.
[19:30] <compbrain> cjwatson: Thanks
[19:30] <ogra_cmpc> juliank, added
[19:32] <juliank> ogra_cmpc: thx
[19:51] <yennes> has anyone sucessfully installed boost
[19:54] <yennes> ??
[19:55] <Seveas> yennes, #ubuntu for support
[19:57] <alex-weej> i really need an ubuntu archive mirror that is reasonably up to date and that doesn't crawl along at 80kB/s on my 20Mb connection
[19:58] <alex-weej> are the main mirrors doing throttling on purpose?
[19:58] <alex-weej> both the UK and the main archive are dog slow
[19:59] <Chipzz> alex-weej: just put 2 mirrors in your sources.list?
[20:00] <Chipzz> if you put them in te right order it will fetch files it can fetch from the faster mirror, and the other files from the other one
[20:00] <Keybuk> alex-weej: it could be your ISP, you're on NTL so anything is possible :-/
[20:00] <alex-weej> yeah could be :/
[20:01] <pochu> or select the option in software-properties to download the packages in the background
[20:01] <alex-weej> they do run their own mirror
[20:01] <alex-weej> but it's literally days out of date i think
[20:01] <alex-weej> Chipzz: that's a good idea...
[20:02] <alex-weej> Chipzz: how do i do this then? i want the repo data to be taken from archive.ubuntu.com but the files from virginmedia when possible
[20:12] <alex-weej> virgin media is like 4 days out of date... :(
[20:12] <alex-weej> should be peer to peer
[20:13] <alex-weej> man that would rock
[20:19] <twb> Is there an equivalent to snapshot.debian.net for Ubuntu?
[20:21] <ScottK2> Not that I know of.
[20:42] <keescook> slangasek: can you take a look at bug 199674 in the hopes of me getting it uploaded before beta freeze?
[20:42] <ubotu> Launchpad bug 199674 in inkscape "Feature Freeze Exception for 0.46 final" [Undecided,New] https://launchpad.net/bugs/199674
[20:46] <dajhorn> If I have a package with an open bug, and the bug is fixed upstream, but I cannot increase the main version, should the LaunchPad ticket be set "closed" or "fixed committed"?
[20:47] <dajhorn> Or "in progress" or somesuch.  I don't see the answer in the policy document.
[20:49] <cjwatson> dajhorn: there should be two tasks on the Launchpad bug, one for Ubuntu and one for upstream; the upstream task should be fix released (if it's a bug tracking system that Launchpad understands, it'll do this for you)
[20:49] <cjwatson> if you do it that way then it shows up in searches for "bugs fixed elsewhere"
[20:50] <dajhorn> cjwatson: Ty.
[20:51] <dajhorn> cjwatson: The dev in charge is closing the tickets, they are being re-reported and marked as duplicates, and so we're getting some hate mail.
[21:04] <slangasek> keescook: I have a couple in the queue ahead of that one, but I'll look at it today, does that suffice?
[21:05] <keescook> slangasek: yup, that's cool.  I've just been itching to dput it.  :)
[21:13] <xipietotec> hey, weird question, can anyone tell me what the suspend/hibernate daemon (service, kernel module, whatever) that ubuntu uses by default in gutsy? I err, installed suspend2, and broke everything
[21:14] <YokoZar> lamont + infinity: Did you see pitti's request above?
[21:14] <YokoZar> zsnes should build on amd64 now but it's PASed: https://bugs.edge.launchpad.net/ubuntu/+source/zsnes/+bug/184255
[21:15] <ubotu> Launchpad bug 184255 in zsnes "[patch] build amd64 package of zsnes" [Wishlist,Confirmed]
[21:16] <lamont> YokoZar: no - hadn't seen it...
[21:16] <lamont> is that zsnes in debian as well??
[21:17] <YokoZar> lamont: not sure.  Probably not actually.
[21:17] <YokoZar> lamont: but the package only lists i386 in its control file anyway, so it doesn't really need to be PASed at all
[21:18] <YokoZar> Err, the package now also lists amd64, but the debian one is probably only i386
[21:18] <lamont> However, apt-get --build source zsnes will work (though when I did this it would segfault on startup). Something weird is going on.
[21:18] <lamont> so...  does it actually work?
[21:18] <slangasek> I suspect it builds with -m32 :-P
[21:20] <compbrain> Today on bad ideas: strace -f a debootstrap process...
[21:21]  * lamont decides to leave zsnes for infinity to decide about, although I might poke joshk about it if I see him any time soon
[21:21] <lamont> compbrain: sounds, uh, lengthy
[21:21] <compbrain> lamont: Indeed.
[21:21]  * milli recalls that lamont needs to be somewhere
[21:22] <lool> Would it make sense to promote desktop-file-utils to desktop-common?
[21:22] <YokoZar> lamont: it segfaults for me too, but according to forum posts some people have gotten it working
[21:22] <lool> AFAIK, it's common to XDG DE
[21:22] <lamont> YokoZar: I'd kinda like to see it "just work" if installed, rather than require lots of hackery
[21:22] <lool> It's pulled by Xfce and GNOME thingies ATM
[21:22] <YokoZar> lamont: so the segfaulting is likely just a problem with the package build script, one I'm pretty sure hasn't gone checked since, well, the package isn't being built at all now
[21:23] <lamont> esp since adding it to PaS will result in the debian maintainer getting bugs when it fails to build or whatever.
[21:23] <lool> In fact it's pulled by ubuntustudio-desktop, ubuntu-desktop, thunar
[21:23] <YokoZar> lamont: no it's in PaS already and needs to be removed from there.  The control file should be preventing its build on anything but i386 as is.
[21:23] <lamont> it's getting built by both the people who get segvs and the people who don't....
[21:23] <lool> and gobuntu-desktop
[21:23] <slangasek> lamont: so when are you going to put P-a-s in bzr so that we can have separate Debian and Ubuntu branches? ;)
[21:24] <lamont> slangasek: EPAIN
[21:24] <lamont> as in OMFG NO
[21:24] <slangasek> pff
[21:24] <lool> Hmm as mobile is based on minimal, it wouldn't work anyway
[21:24] <slangasek> 'bzr pull' -- done
[21:24] <lamont> merge conflicts would be _PLENTIFUL_
[21:25] <Fujitsu> lamont: Just write your own merge algorithm for P-a-s.
[21:25] <slangasek> not if you continued to use the Debian one as the main branch and only diverged in the Ubuntu branch
[21:25] <lamont> slangasek: not true.
[21:25] <lamont> debian changes a line, and ubuntu changes 2 lines away...
[21:25] <lamont> pain
[21:26] <lamont> and then there's the whole git vs bzr discussion for the debian tree.
[21:26] <slangasek> er?  surely bzr's merge algo is better than that?
[21:26] <lamont> does bzr allow me to hit a git repo and be happy these days?
[21:26] <lamont> slangasek: maybe..... dunno
[21:26] <slangasek> I think bzr lets you hit any drugs you want and be happy
[21:26] <lamont> most files find that things next to each other are _uh_ related.
[21:27] <lamont> note that happy and successful are not necessarily congruent.
[21:27] <YokoZar> lamont: in the case of zsnes, which in debian has i386 only in its control file and ubuntu has i386 amd64, you agree with me that there's no need for it?
[21:27] <lamont> gah.
[21:27] <lamont> coffee shop times out in it's nat config... gonna have to turn on keepalives, it looks like
[21:30] <milli> lamont: you can tunnel out through hashmal via openvpn if you need to, just have to gen you a client key.  Varous ports are blocked at that coffee shop.
[21:31] <lamont> milli: I'll bug you later
[21:31] <lamont> is EOD for me, kids to fetch and such
[21:33] <lamont> milli: it's more the ssh windows going *poof* without warning, mixed with me not remembering which system they were on, that is the issue.
[21:33] <lamont> the far end is a screen session, so it's not a bad thing, just an annoying thing
[21:35] <james_w> lamont: hopefully soon we'll support specialist merge algorithms, so you can ignore context in the merge, and so you want get a conflict.
[21:35] <james_w> and we'll also be able to merge debian/changelog as well.
[21:36] <james_w> but unfortunately bzr-git is still pretty poor.
[21:38] <milli> lamont: screen is your friend, of course.
[22:01] <wasabi> This is silly. System keeps resetting my timezone to Monterrey.
[22:02] <seb128> wasabi: why would your timezone change automatically?
[22:02] <wasabi> Got me. Looks like everytime I reboot.
[22:03] <wasabi> Hmmm. What significance does /etc/timezone have anymore? None?
[22:03] <seb128> it's the timezone you are using
[22:03] <wasabi> Is set to US/Central.
[22:04] <wasabi> Which does not even appear as an option anymore in the gnome-UI
[22:04] <Chipzz> twb: you can get old versions of packages on launchpad though
[22:04] <seb128> not sure what the clock applet is using
[22:04] <slangasek> /etc/timezone doesn't appear to really be read by anything
[22:05] <Chipzz> alex-weej: sbeen a while since I had such a setup; basically you just have 2 deb lines for the some distro/release etc, and order matters
[22:05] <Chipzz> alex-weej: you put the out-of-date one first iirc
[22:05] <Chipzz> but
[22:06] <twb> Chipzz: I don't understand.
[22:06] <Chipzz> the repo data will always be taken from both mirrors
[22:06] <twb> Chipzz: the whole point of the exercise is to get old versions; why is this a "... though"?
[22:06] <Chipzz> twb: well, if you want an older version of a package, you click around on launchpad
[22:06] <Chipzz> the binary debs are there
[22:06] <slangasek> wasabi: go to the clock applet, "edit", select your location (what city, BTW?), "edit", choose America/Chicago
[22:06] <wasabi> I did.
[22:06] <slangasek> and it reset after that?
[22:06] <Chipzz> twb: yes, and you can
[22:06] <wasabi> I did it yesterday. Just a moment ago I noticed it was back to Monterry
[22:06] <wasabi> Yeah.
[22:07] <slangasek> hmm
[22:07] <twb> Chipzz: oh, sorry.
[22:07] <slangasek> I haven't had it reset on me in that fashion
[22:07] <twb> Chipzz: I also asked the question in #ubuntu-server, and I got an answer there
[22:07] <wasabi> I can't think of anything that might potentially do that other than dhclient.
[22:07] <slangasek> once you save, the value is supposed to be saved to gconf
[22:07] <wasabi> But if /etc/timezone isn't even used....
[22:07] <twb> Chipzz: I thought you were continuing that discussion ^_^;;
[22:07] <wasabi> hmm. It makes me authenticate to change it.
[22:07] <wasabi> Which I thought was required because it was a system setting.
[22:07] <Chipzz> twb: launchpad just does not provide you with the possibility of putting date-based deb lines in your sources.list
[22:08] <Chipzz> you download files manually
[22:08] <Chipzz> alex-weej: the out-of-date mirror will be used for downloading packages that are available there; the other mirror will be used for the packages which are not
[22:09] <slangasek> wasabi: /etc/localtime is the relevant file, which is copied from /usr/share/zoneinfo; /etc/timezone is at most a hint about which file to copy
[22:10] <wasabi> /etc/localtime is a symlink to America/Chicago
[22:10] <wasabi> So, that's right.
[22:10] <wasabi> So something is resetting it somewhere.
[22:10] <wasabi> first suspicion is dhclient
[22:10] <slangasek> mine is gnome-panel
[22:11] <slangasek> because I've seen how special the new gnome-panel's timezone handling is :P
[22:11] <wasabi> Heh.
[22:11] <seb128> there is not real reason it should trigger a timezone change if you don't use it though
[22:11] <wasabi> Does it consult /etc/timezone at all?
[22:11] <seb128> to be sure you can remove it from the panel and reboot and look if that's still happening
[22:12] <slangasek> no, it doesn't consult /etc/timezone
[22:12] <wasabi> I wonder if it's not finding a match for what's in /etc/timezone, and so setting it to the default.
[22:12] <wasabi> k
[22:12] <slangasek> it consults getenv("TZ"), or it looks at your list of configured locations
[22:13] <slangasek> /etc/timezone is used by tzdata to store information about what zone to copy to /etc/localtime
[22:13] <slangasek> I don't think it's used for anything else
[22:14] <seb128> slangasek: it does
[22:14] <seb128> tz.c tz_get_system_timezone()
[22:14] <seb128>   etc_timezone = g_fopen ("/etc/timezone", "r");
[22:14] <slangasek> oh, so it does, sorry
[22:15] <wasabi> Hmm. So when a program cares about the timezone, it reads /etc/localtime?
[22:15] <seb128> the code is really confusing
[22:15] <slangasek> wasabi: what does gconftool -g /apps/panel/applets/clock_screen0/prefs/cities give you for the timezone value?
[22:15] <seb128> it has all sort of different cases
[22:16] <wasabi> [<location name="Dallas" timezone="America/Monterrey" latitude="32.896946" longitude="-97.021942" code="KDFW" current="true"/>]
[22:16] <wasabi> Haha
[22:16] <slangasek> the comment says "This tries to get the system timezone from: + TZ environment variable + OS specific stuff + /etc/timezone + /etc/localtime"
[22:16] <wasabi> I am actually in Dallas. But US/Dallas i not an option.
[22:16] <wasabi> Where else would Dallas be stored?
[22:17] <slangasek> wasabi: right; that's to be expected, worldclock's TZ autodetection is off its rocker
[22:17] <wasabi> Oh I seeeeee.
[22:17] <slangasek> it looks for the city with a timezone named after it which is geographically closest to you
[22:17] <wasabi> It's set in Locations.
[22:17] <wasabi> Which is not realated to the timezone cpanel.
[22:17] <wasabi> or something.
[22:17] <wasabi> This is all stupid. I miss US/Central.
[22:17] <Nafallo> ehrm
[22:18]  * Nafallo hides
[22:18] <slangasek> replacing this with a useful city->TZ database is impractical in the near term
[22:18]  * Nafallo curses cpanel a bit more and then hides again
[22:18] <wasabi> I'd prefer a plain TZ selection, until such a point where we have a useful database.
[22:18] <slangasek> so I think we'd be better off fixing the clock to, by default, only prompt you for a timezone and not a city
[22:18] <wasabi> At least offer the user a choice he can make properly.
[22:18] <slangasek> yes, exactly
[22:18] <wasabi> You can't offer him an unanswerable question. That just sucks.
[22:19] <wasabi> Evolution was the first app I noticed with this method... I hated it then.
[22:19] <wasabi> I don't even remember adding Dallas to this list.
[22:19] <wasabi> And also that the option is in two places is sort of bad. =)
[22:22] <seb128> wasabi: is that the wrong timezone, like wrong hour?
[22:22] <wasabi> Monterry is wrong.
[22:22] <wasabi> Dallas should be... Chicago.
[22:22] <seb128> wasabi: wrong time or just not the nearest?
[22:22] <wasabi> Oh I see.
[22:23] <wasabi> It's an hour off.
[22:23] <seb128> ah, that is not good
[22:23] <wasabi> This 10 page timezone menu is a bit unwieldy.
[22:23] <seb128> ?
[22:23] <wasabi> To change the timezone. I have to scroll for ages. =)
[22:24] <wasabi> It's a drop down with every possible timezone in it.
[22:24] <seb128> ah
[22:24] <seb128> right
[22:24] <wasabi> I don't understand this. There's this database of Cities... which maps me to America/Monterrey... which is also a database of cities.
[22:24] <wasabi> As far as I can tell.
[22:24] <seb128> what do you mean?
[22:25] <slangasek> seb128: wrong DST rule
[22:25] <slangasek> also wrong country
[22:25] <wasabi> Why would Dallas map to America/Monterry and not US/Central
[22:25] <wasabi> Why is this American/Monterry thing even an issue?
[22:25] <seb128> wasabi: the code to select a timezone for a town seems to be buggy
[22:25] <seb128> but I didn't look at this one yet
[22:25] <slangasek> wasabi: as I said, the algorithm it uses is one of geographical proximity
[22:25] <wasabi> Yeah, what I mean is why are timezones represented as cities?
[22:25] <wasabi> Hmm.
[22:25] <seb128> wasabi: they are not
[22:26] <wasabi> Even if asked to manually select a timezone, why are my options America/Chicago and not US/Central.
[22:26] <seb128> wasabi: it just tries to be helpful and set a timezone near of your city
[22:26] <slangasek> which is singularly unhelpful
[22:26] <slangasek> because the values of "near" are huge
[22:26] <seb128> right, this dialog is really ugly
[22:26] <wasabi> I guess maybe my question is not understood. Dallas is in the city list when I hit "Find..."
[22:27] <seb128> wasabi: that's the list of weather stations
[22:27] <slangasek> wasabi: that database doesn't include timezone information; it does include lat/lon coordinates
[22:27] <wasabi> oh.
[22:27] <seb128> you pick a town which has a weather station
[22:27] <seb128> and he gives you a timezone for free
[22:27] <slangasek> wasabi: so what this clever applet does is find the nearest city with a timezone named after it
[22:27] <seb128> you can change that if you don't agree
[22:27] <wasabi> Oh. Okay.
[22:27] <seb128> but since it's wrong I think it should pick nothing
[22:27] <wasabi> Okay, let me once again rephrase my question. I live in the US. I know my timezone as "Central"
[22:27] <wasabi> It's what the TV stations say. "4 PM CST"
[22:28] <wasabi> I know Pacific and Eastern and Mountain.
[22:28] <wasabi> Why are my options that of cities?
[22:28] <seb128> what cities?
[22:28] <wasabi> Chicago.
[22:28] <seb128> the first choice is a town for weather
[22:28] <seb128> the second combo is a timezone
[22:28] <wasabi> And teh second is a list of cities ALSO
[22:28] <seb128> no
[22:28] <seb128> it's a list of timezone
[22:29] <seb128> I think the second one is what tzdata lists
[22:29] <seb128> which is what we usually have in other GNOME applications
[22:29] <wasabi> I recognize what you are telling me technically, but it's wrong.
[22:29] <slangasek> wasabi: because for whatever reason, that's how the timezones are named in glibc: America/Los_Angeles, America/Boise, America/Chicago, America/New_York, ...
[22:29] <wasabi> Yes, it's a list of tzdata. But it's a completely useless list.
[22:29] <wasabi> I need to see a list offering choices of Central, Eastern, Pacific and MOuntain.
[22:29] <seb128> it's not
[22:30] <wasabi> Not cities I may or may not know are close or in the same timezone as myself.
[22:30] <slangasek> seb128: he's right that most users don't associate their time zones with city names
[22:30] <seb128> america is likely different from europe
[22:30] <slangasek> perhaps
[22:30] <seb128> we don't have weird names for timezones
[22:30] <wasabi> If I went around the office right now, and asked people what timezone chicago was in, most would not know.
[22:30] <tritium> It's not useless, but it isn't preferable.
[22:30] <wasabi> Simple as that.
[22:31] <seb128> wasabi: well, that's not new issue
[22:31] <tritium> seb128: and we don't associate our times zones with other cities that we don't live in
[22:31] <seb128> wasabi: evolution and gst have similar timezone lists since warty
[22:31] <wasabi> seb128: I *used* to select my timezone in tzdata and had options such as US/Central.
[22:31] <wasabi> Which is still reflected in my /etc/timezone file.
[22:31] <ScottK2> slangasek: I'd like to upload an update to tasksel to fix a missed a spot in the mail-server task.  Since we're so close to the freeze, I thought I'd check with you.  It's the last debdiff listed in Bug #164837
[22:31] <ubotu> Launchpad bug 164837 in dovecot "Dovecot SASL for postfix" [Low,In progress] https://launchpad.net/bugs/164837
[22:31] <wasabi> What happened to US/Central?
[22:31] <mjg59> Yeah, tzdata includes the US timezones as US timezones
[22:31] <mjg59> But the UI isn't presenting that
[22:31] <slangasek> right
[22:32] <slangasek> and if it did, given the UI, it'd take an hour to scroll to them :-P
[22:32] <wasabi> seb128: ANd yes, Evo has this same issue, and it is equally an issue.
[22:32] <mjg59> Yeah, the UI is stab-in-the-face bad
[22:33] <seb128> the new location selection UI is really ugly, I'm wondering who wrote that
[22:33] <wasabi> Crap, I'd prefer a UI that let me select +6 GMT.
[22:33] <infinity> Somewhere along the way, something forced my timezone to switch from "Canada/Mountain" to "America/Edmonton" too.  I assume this is all the same meta-bug.
[22:34] <slangasek> ScottK2: er, wow, this is considered an appropriate way to configure tasks?
[22:34] <slangasek> infinity: yep
[22:34] <wasabi> Sub menus are not THAT hard in Gtk. :0
[22:34] <wasabi> Or a treeview heh
[22:34] <TheMuso> ScottK2: You are aware that there is an ubuntu tasksel bzr branch right?
[22:35] <ScottK2> TheMuso: No
[22:35] <slangasek> the one problem with doing US/Mountain and whatnot is that your configured TZ becomes less accurate in case of those cities who've historically been unable to make up their minds
[22:35] <ScottK2> slangasek: I'm only personally acquainted with the postfix end of the change and for that, yes.  This is the best way to do it.
[22:36] <ScottK2> slangasek: You can torture ivoks over the dovecot part if you want.
[22:36] <tritium> slangasek: that's becoming a smaller set of cities as time goes on.  AZ and IN have changed recently.
[22:36] <slangasek> so historical timestamps on files would suddenly become inaccurate
[22:36] <slangasek> tritium: no, it becomes a *larger* set of cities because the TZ rules have more permutations over time
[22:36] <wasabi> Hmm. How is it less accurate?
[22:37] <infinity> slangasek: Canada/Mountain gets along a bit better than all of US/Mountain.
[22:37] <slangasek> infinity: they get along to where?
[22:37] <wasabi> Users in those cities are certainly aware of what their timezoen is.
[22:37] <infinity> slangasek: (Canada/Mountain and America/Edmonton are likely identical)
[22:37] <slangasek> infinity: sure; but everyone in Canada/Mountain knows where Edmonton is ;)
[22:37] <wasabi> In fact, as I see it, attempting to hard code a database full of city->TZ mappings is what's hardest to deal with.
[22:37] <infinity> slangasek: Perhaps, yes. :)
[22:38] <infinity> slangasek: I still think that identifying timezones by city (except when cities are the exception to the rule) tends to be contentious, if only superficially.
[22:38] <infinity> slangasek: (ie: Screw Edmonton, the Oilers suck, Wayne Gretzky was a pansy, I don't want to be in that timezone!)
[22:39] <infinity> slangasek: There must be parts of the world where it's slightly more politically charged than just hockey rivalry, though. :)
[22:39] <slangasek> ScottK2: well, patching another package's config file in a task postinst sets off warning bells for me.  This strikes me as a policy violation... in terms of whether it's ok to upload now I have no release-based objections, I just wonder if it's a reasonable thing to upload ever :)
[22:39] <ScottK2> Right
[22:40] <ScottK2> slangasek: For postfix, calling postconf is the defined tool for doing that.  Let me look at the other again.
[22:40] <tritium> slangasek: I'm not suggesting you keep track of historical changes.  The present set of cities that don't follow DST is smaller than it was a year ago.
[22:41] <slangasek> wasabi: it's less accurate because if you know that your timezone is "Central" because that's what the government says you are, but in reality you've been following different timezone rules than the usual CST/CDT group up until 6 months ago, listing yourself as US/Central is going to break your local timestamp reckoning for everything older than that
[22:41] <mathiaz> slangasek: well - I'd risk to ask if tasksel postinst scripts are considered as maitainer scripts ?
[22:41] <slangasek> tritium: you may have noticed that computers are occasionally used for keeping track of historical data...
[22:41] <slangasek> mathiaz: IMHO they should be
[22:41] <mathiaz> slangasek: the postinst script for a task wouldn't be allowed to modify the configuration file ?
[22:42] <ScottK2> slangasek: After looking at the dovecot stuff again I tend to agree with you.  I'll hold off.
[22:42] <tritium> slangasek: sure, but when configuring my time zone, I care about the present
[22:42] <ScottK2> slangasek: Thanks for looking at it.
[22:42] <infinity> Since when do tasks have postinsts anyway?
[22:42] <wasabi> slangasek: Works on Windows.
[22:42]  * wasabi ducks.
[22:42] <infinity> (And does "apt-get install task^" run them?)
[22:42] <slangasek> wasabi: yeah, everyone *loves* Windows TZ handling
[22:42] <wasabi> Just the UI.
[22:42] <mathiaz> infinity: well - that's what we choose to use tasks postinst to handle dovecot/postfix integration
[22:42] <slangasek> wasabi: Windows == no monotonic clock == loss
[22:43] <wasabi> What's that mean?
[22:43] <mathiaz> infinity: we couldn't do it from the package postinst script
[22:43] <slangasek> mathiaz: I would note that if this patch were uploaded, it would be the only task on my system that *has* a postinst script...
[22:43] <mathiaz> infinity: so we've tried to use a postinst script from tasksel task
[22:43] <wasabi> Oh, you mean to adjust the time by fast forwarding
[22:43] <slangasek> yes
[22:43] <mathiaz> slangasek: correct.
[22:44] <tritium> Well, I don't live in Denver, nor do I have any association whatsoever with Denver (other than my city is also one mile above sea level), yet that is my timezone selection.  Quite annoying...
[22:44] <wasabi> Well, seperate subject from the UI.
[22:44] <mathiaz> slangasek: so what are the purpose of postinst task scripts ?
[22:44] <wasabi> service has determined which time sample is best, based on the above criteria, it adjusts the local clock rate to allow it to converge toward the correct time. I
[22:44] <slangasek> wasabi: or by stepping it back; the result either way is that you have a discontinuity across DST changes that makes log keeping a problem
[22:44] <wasabi> ^ From 2000
[22:44] <mathiaz> IIUC tasks are used to install a set of packages and then glue them so that they're integrated correctly.
[22:45] <slangasek> mathiaz: presumably, the same as for regular package postinst scripts except when you install a task
[22:45] <wasabi> Windows does in fact have whatever you just said it didn't.
[22:45] <keescook> hm, where did the "removable drives" settings in "removable drives and media settings" go?
[22:45] <slangasek> wasabi: er?
[22:45] <mathiaz> slangasek: so what's the difference between a meta-package and a task in tasksel ?
[22:45] <slangasek> mathiaz: I don't know anymore
[22:46] <infinity> Doing something like this in tasksel, instead of a meta-package, strikes me as just plain wrong.
[22:46] <infinity> Nevermind the wrongness of futzing with other packages' config files in the first place.
[22:46] <mathiaz> infinity: well - tasksel is what is used in the installer
[22:46] <infinity> "apt-get install mail-server^" won't have the same effect as installing from tasksel.
[22:47] <wasabi> slangasek: Since 2k it does gradually slow down or speed up the clock to correct small differences.
[22:47] <wasabi> As long as it's within 3 minutes, it says.
[22:47] <slangasek> wasabi: which is either not relevant in the case of DST changes, or completely the wrong solution
[22:47] <mathiaz> infinity: does apt-get understand tasks from tasksel ?
[22:47] <slangasek> right - that doesn't give you correction for a 1-hour difference
[22:47] <wasabi> Eh? I do not see how convergence is relative to time zones.
[22:47] <wasabi> I said that when you first brought it up.
[22:48] <infinity> mathiaz: Oh, is mail-server not a "real" task?  (ie: not in the seeds, not in Packages.gz?)
[22:48] <mathiaz> infinity: for now it don't see the difference between a meta-package and a task in taskel
[22:48] <infinity> No, it's a real task...
[22:48] <slangasek> wasabi: I didn't say "convergence", I said "discontinuity"
[22:48] <infinity> adconrad@ziggup:~$ apt-cache show postfix | grep ^Task
[22:48] <infinity> Task: mail-server
[22:48] <mathiaz> infinity: I guess I'm not fully aware of the difference between the two.
[22:48] <wasabi> slangasek: I guess I don't know waht you mean. File times on NT are kept in UTC.
[22:48] <wasabi> slangasek: So the DST is unrelated to all of that.
[22:48] <infinity> mathiaz: apt-get just installs "all packages with a Task header matching 'task^'".
[22:49] <slangasek> wasabi: well, that's an improvement over what I remember then; but isn't the BIOS clock still kept in local time?
[22:49] <wasabi> slangasek: But that's been true since NT4.
[22:49] <infinity> mathiaz: A metapackage would be a package that depends on a bunch of other packages, and has a postinst, preinst, etc.
[22:49] <wasabi> Yes, the bios clock is still local time. That does suck
[22:49] <mathiaz> infinity: gotcha. So what's the difference between a tasksel task and a meta-package ?
[22:49] <infinity> mathiaz: A task could certainly point at a metapackage, but having a task have "magic" on its own that's outside the packaging system is, IMO, wrong.
[22:49] <wasabi> First thing NT does is read it, convert it to current timezone, and use keep time in software (like linux)
[22:49] <mathiaz> infinity: it's just that it shows up during the install ?
[22:50] <infinity> mathiaz: A task is a group of packages.  A metapackage is a package that depends on packages.
[22:50] <slangasek> mathiaz: historically, the difference between tasks and metapackages was "recommends"
[22:50] <slangasek> well, that's true even today on Ubuntu
[22:50] <wasabi> Uh huh.
[22:50] <wasabi> This is all NT stuff. 9x was all screwed up, which everybody admits.
[22:50] <wasabi> But that was a long time ago now.
[22:51] <infinity> slangasek: I could be way out of touch, having not ever wanted to even look at tasksel, but any task that can't be reproduced with "apt-get install <package, package, package>" or "apt-get install task^" seems broken to me.
[22:51] <wasabi> Do we have any source of data defining regions of the earth that are under a timezone? Not cities, but lat/lon regions.
[22:51] <mathiaz> infinity: well - then what is the purpose of tasksel ?
[22:51] <wasabi> Combining that with the weather database which has lat/long seems more reasonable.
[22:51] <infinity> slangasek: To be honest, I'd prefer to see something like this in a "postfix-sasl-integration" package, which could then be part of the mail-server task.
[22:52] <infinity> mathiaz: The purpose of tasksel is to select tasks? :)
[22:52] <infinity> mathiaz: (It also used to be the canonical list of tasks, before we had a Task: header in Packages.gz)
[22:52] <slangasek> infinity: tasks can have "optional" packages that are installed by default if available; metapackages cannot, without recommends-by-default
[22:52] <infinity> slangasek: Yeah, there's that too.  That line's blurry in Ubuntu.
[22:52] <mathiaz> slangasek: isn't recommends-by-default the default for hardy ?
[22:53] <infinity> slangasek: Either way, a task having a postinst (rather than depending on a package with a postinst) feels broken.
[22:53] <slangasek> wasabi: no; nor do we have code in gnome-panel that lets us calculate whether a given lat/lon pair is within a bounded region... :)
[22:53] <slangasek> mathiaz: I thought we still didn't have recommends-by-default in hardy
[22:53] <infinity> mathiaz: A more practical example of this breakage is that if we set a precedent here, someone may decide to (god forbid) add a tasksel postinst to "ubuntu-desktop"...
[22:54] <slangasek> mathiaz: not in apt-get, that is
[22:54] <infinity> mathiaz: ubuntu-desktop, on the livecds (and, hence, the installer), is installed with apt-get, not tasksel.
[22:54] <infinity> mathiaz: So, alternate installs would differ from livecd installs.
[22:54] <mathiaz> slangasek: but aptitude does it, right ?
[22:54] <seb128_> wasabi: I think the easiest thing to do for hardy is either to let the code like this or to not select a timezone when picking a city
[22:54] <slangasek> mathiaz: yes, aptitude has for quite some time; but aptitude is not the default package management tool in Ubuntu
[22:55] <slangasek> seb128_: I believe the latter is the correct course of action
[22:55] <seb128_> wasabi: but not picking a timezone mean every user has to go through this ugly list to select one
[22:55] <mathiaz> slangasek: agreed - just trying to understand this whole thing.
[22:55] <wasabi> seb128, a real issue is that there are two places to configure this independently, one which overrides the other. The Date & Time cpanel lets you chagne timezone.
[22:55] <wasabi> But then the gnome-panel thing resets it.
[22:55] <seb128_> slangasek: I would agree if the timezone selection widget was easier to use
[22:55] <wasabi> That's probably required to fix for release
[22:55] <seb128_> wasabi: yes, that's a bug
[22:55] <slangasek> wasabi: I don't see a "Date & Time" selector anywhere here, is that installed by default?
[22:55] <wasabi> Eh. Time and date
[22:56] <infinity> mathiaz: Anyhow, the whole discussion (and me wondering why tasksel even ALLOWS this) are perhaps windy and off-topic.
[22:56] <seb128_> slangasek: system, administration
[22:56] <slangasek> another bug is that you pick a timezone in the installer, but gnome-panel doesn't see this
[22:56] <wasabi> Can't this crap just be knocked out of Gnome-panel?
[22:56] <slangasek> seb128_: right, I didn't think to look under "T" :-)
[22:56] <wasabi> Until somebody does it right?
[22:56] <infinity> mathiaz: But I still think the "better" way to do this is to have a "postfix-sasl-integration" package that does what you want it to do, and add that package to the "mail-server" task.
[22:56] <seb128_> what is standard timezone location, not speaking about GNOME
[22:56] <slangasek> wasabi: it was done right, then they replaced it with the worldclock ;)
[22:56] <seb128_> rather the system one
[22:56] <infinity> mathiaz: That way, people using apt-get can have it work the same way, people who already have half the packages installed can just grab the integration package, etc.
[22:57] <wasabi> seb128 /etc/timezone seems to be used by tzdata, which also has it stored in debconf
[22:57] <seb128_> is that just a matter to write to timezone rather than localtime?
[22:57] <slangasek> seb128_: hrm, but as usual GNOME seems to believe it is the system ;) - if you choose a different location in the panel, the system timezone changes
[22:57] <seb128_> in which case we should update the panel code to prefer timezone over localtime
[22:57]  * lamont wonders if he wants to be involved in the postfix discussion
[22:57] <wasabi> No, /etc/timezone is the NAME of the time.  Just state. /etc/localtime is a symlink to the tzdata information in /usr/share/tz/data/$(cat /etc/timezone)
[22:57] <wasabi> apparently.
[22:58] <seb128_> that applet really didn't land the best way
[22:58] <infinity> lamont: Not when you see the diff involved, you don't.
[22:58] <seb128_> that was a change suse had
[22:58] <seb128_> redhat did work on something similar
[22:58] <slangasek> on most systems, /etc/localtime is a copy of the tzdata, not a symlink
[22:58] <lamont> infinity: heh
[22:58] <wasabi> Oh. My system has it as a symlink.
[22:58] <seb128_> and upstream decided to just land the change in a hurry rather than having random distro adding different patches to do that
[22:58] <wasabi> Oh. Heh. I just reconfigured tzdata and it replaced it.
[22:58] <wasabi> Go figure.
[22:58] <slangasek> right :)
[22:59] <slangasek> wasabi: "copy" because if /usr isn't available at boot, you can't get the timezone
[22:59] <slangasek> and fsck goes wobbly
[23:00] <tritium> I'd just prefer to choose an actual timezone, e.g. US/Mountain, not a city in another state.  Cities are not timezones.
[23:00] <slangasek> so, then you keep /etc/timezone around so you can figure out the name of the currently-configured system timezone without having to walk all of /usr/share/zoneinfo and hope you find a current match
[23:00] <wasabi> Hee hee.
[23:00] <seb128_> tritium: you don't select a city as timezone
[23:00] <wasabi> tritium: Apparently everywhere other than the US that is the case.
[23:00] <tritium> seb128_: yes, I select America/Denver, even though it's 6 hours away.
[23:00] <wasabi> Think this is a language barrier. In the US we do not refer to our timezones by city name.
[23:01] <wasabi> Europe seems to.
[23:01] <tritium> Perhaps.
[23:01] <seb128_> how many timezone do you have? 8?
[23:01] <wasabi> Maybe that's why they say stuff like "Paris time"
[23:01] <seb128_> you have a name to remember for every of those?
[23:01] <slangasek> seb128_: you pick a timezone that's named for a city, which is the same thing for those of us in countries who don't normally label our timezones that way
[23:01] <tritium> seb128_: more like 4
[23:01] <wasabi> seb128, most people don't leave their own.
[23:01] <slangasek> US/Central, US/Pacific, US/Mountain, US/Hawaii, US/Eastern, US/Alaska, ...
[23:02] <wasabi> But yes, 8.
[23:02] <wasabi> Samoa, Hawaii
[23:02] <seb128_> that's complicated ;-)
[23:02] <wasabi> Atlantic
[23:02] <slangasek> US/Arizona
[23:02] <seb128_> I like the european way better
[23:02] <slangasek> Atlantic isn't a US timezone, it's a Canadian one
[23:02] <seb128_> you go to england you select the london timezone
[23:02] <wasabi> Wait, let me see what Windows lists!
[23:02] <slangasek> seb128_: if you go to Spain, which timezone do you choose?
[23:02] <seb128_> madrid
[23:02] <wasabi> Yeah. So that's it.
[23:03] <slangasek> are you sure? :)
[23:03] <wasabi> Windows lists the european timezones by city name.
[23:03] <seb128_> or barcelona
[23:03] <slangasek> the Canary Islands are part of Spain
[23:03] <wasabi> But hte US ones are listed by US name.
[23:03] <seb128_> any spain town will do
[23:03] <slangasek> and aren't in the same timezone
[23:03] <seb128_> slangasek: they are in the list
[23:03] <wasabi> Pacific Time (US & Canada); Tijuana
[23:03] <Ng> could the map that shows timezones not actually show the timezones, like on normal maps that show timezones? :)
[23:03] <seb128_> slangasek: I pick the nearest city in the country
[23:03] <wasabi> seb128 what if that crosses tz borders?
[23:04] <Ng> (also, is the map zooming in the alpha6 installer going to stay?)
[23:04] <slangasek> seb128_: but when you're in spain and you ask them what timezone you're in, I don't think they're going to tell you "Madrid", so how do you know where the border is between the timezones unless you know the other name for the zone?
[23:04] <slangasek> (ok, Atlantic/Canary might be obvious enough...)
[23:04] <ion_> wasabi: How about taking a single look at a local clock? :-P
[23:05] <slangasek> some of us like to know the time before we land ;-)
[23:05] <wasabi> GMT +01 (Brussels, Copenhagen, Madrid, Paris)
[23:05] <Ng> wrt the panel locations thing, I object to using the Find thing to drill down to europe, UK, London, City Airport when the whole country is a single timezone. show me a map with the timezones :)
[23:05] <seb128_> slangasek: not sure to understand the question, ask said I go to uk I use london, continental spain madrid, canary canary, etc
[23:05] <seb128_> slangasek: we usually have 1 timezone by country
[23:05] <slangasek> Ng: yes, that's the other thing - you're really picking a weather zone and getting the TZ autopopulated, when the opposite would be more useful by default :)
[23:05] <wasabi> http://www.time.gov/
[23:05] <tritium> seb128_: that's great for smaller countries, geographically
[23:06] <seb128_> canary is not spain
[23:06] <slangasek> seb128_: huh?  The Canary Islands are Spain
[23:06] <seb128_> slangasek: right, but that's like saying that reunion is france
[23:06] <slangasek> seb128_: Russia is another example, though
[23:06] <slangasek> erm
[23:06] <seb128_> those are french island but they are no near
[23:06] <seb128_> and I'll not expect those to be on continental time
[23:06] <slangasek> Las Canarias are only 1 hour offset from Madrid, IIRC
[23:07] <Ng> slangasek: indeed. being able to select a city isn't the worst thing in the world if you use it to track the time of the people you converse with, but at least the system timezone and the installer timezone should just let you click on the bands of one of these: http://members.shaw.ca/emg.pbm/timezone.gif
[23:07] <seb128_> well, wouldn't work much better with a system like the us one
[23:07] <theunixgeek> What do you think of gtkmm over GTK+? (C++ GTK vs C GTK)
[23:07] <wasabi> oh hey
[23:07] <Ng> but anyway, I have more urgent things to try and get fixed :)
[23:07] <seb128_> right, that going off track
[23:08] <tritium> Ng: that would be nice.
[23:08] <ion_> ng: Agreed.
[23:08] <seb128_> let's not try to solve how countries use timezone
[23:08] <seb128_> and see what we can do which is not too intrusive for hardy
[23:08] <slangasek> :-)
[23:08] <slangasek> step one would probably be to get a saner timezone selector instead of the single pull-down list
[23:09] <seb128_> right
[23:09] <seb128_> logical choice would be a map
[23:09] <tritium> seb128_: we're not solving how countries use timezones.  But we are pointing out that the chooser forces ways that countries do _not_ use timezones.
[23:09] <seb128_> like ubiquite, evolution, gst are using
[23:09] <slangasek> sure.  then if that's done, we can flip the location/timezone choices
[23:09] <slangasek> so that you choose a timezone first, and optionally a location after
[23:09] <seb128_> tritium: it does not
[23:09] <seb128_> tritium: there is just a bug which is that the interface doesn't list the US timezones
[23:10] <tritium> seb128_: yes, the US does _not_ use city names for timezones, e.g. America/Denver.  It uses US/Mountain.
[23:10] <seb128_> it should list what is has now, and US*
[23:10] <seb128_> tritium: that's just a bug, not a design issue
[23:10] <tritium> okay, seb128_
[23:11] <wasabi> Depends on your definition of bug. =)
[23:11] <slangasek> seb128_: what about Brazil, Canada, Chile, Mexico?  These each have directories in /usr/share/zoneinfo but aren't in the selector
[23:11] <mathiaz> infinity: slangasek: thanks for your explanation on the tasksel stuff.
[23:11] <slangasek> mathiaz: sure
[23:12] <mathiaz> infinity: slangasek: so now the question is: what are the other option to automate the integration of dovecot and postfix ?
[23:12] <ScottK2> mathiaz: I didn't see anything in the dovecot patch that was obviously wrong for the default config provided by dovecot.
[23:14] <mathiaz> ScottK2: so we could shipp a default dovecot file that provides the necessary bits for postfix integration ?
[23:15] <seb128_> slangasek: I officially hate this configuration dialog
[23:15] <slangasek> seb128_: what's tricky about this is that, for some time now, I believe we've been using the America/Los_Angeles [...] zones as the authoritative choices for time zones in Debian/Ubuntu; but we've never made users have to pick a city name before
[23:15] <slangasek> seb128_: I'm glad we're on the same page ;)
[23:16] <mathiaz> ScottK2: so whenever dovecot is installed it would provide a socket in /var/spool/postfix/private/auth even if postfix is not installed ?
[23:16] <seb128_> slangasek: one thing we could do is to make the applet not set timezone for one thing
[23:16] <seb128_> slangasek: and keep using the dialog we had before
[23:16] <seb128_> slangasek: I think it's nice to be able to list different location there and the local time and weather
[23:16] <seb128_> but we can still use the admin tool for configuration the zone to use
[23:16] <slangasek> seb128_: I'm not sure I understand you; are you saying that if there's only one location configured, don't change the timezone?
[23:17] <slangasek> that seems like a workaround to me
[23:17] <seb128_> no
[23:17] <seb128_> but the applet will have no timezone by default in the list
[23:17] <seb128_> you can add some
[23:17] <seb128_> you will get the time and weather for those
[23:18] <seb128_> which is nice and informative
[23:18] <slangasek> how do you get the time for it if you don't set a timezone?
[23:18] <slangasek> remember, part of the problem is that cities close together have different timezones
[23:18] <seb128_> well, that's still an issue
[23:18] <seb128_> I'm trying to solve the "don't mix with the system timezone config" first
[23:18] <seb128_> which is the important one
[23:18] <slangasek> well
[23:18] <seb128_> then we can deal with the UI issue for adding extra timezones
[23:18] <slangasek> I wouldn't mind it messing with the system timezone, if it did it *right* :)
[23:19] <ScottK2> mathiaz: Since postfix is our default/standard MTA, I don't see a problem with configuring other programs to work with it by default.
[23:19] <slangasek> i.e., was able to correctly pull the timezone configured at install time as an initial default location; don't guess at timezone based on distance
[23:19] <slangasek> ScottK2: +1
[23:19] <mathiaz> ScottK2: right.
[23:20] <mathiaz> But to make things clear, calling postconf from a maintainer script isn't against the policy ?
[23:21] <ScottK2> mathiaz: I certainly don't think so.  That's what it's for.  I don't recall the policy reference exactly, but IIRC that's how it says to do it.
[23:21] <slangasek> postconf is a package-provided interface; so as long as it doesn't get called in ways that will *repeatedly* stomp on the local config...
[23:22] <ScottK2> mathiaz: ^^^ Which is why I was against using it in an init script.
[23:23] <mathiaz> ScottK2: right - but what about calling postconf on every package upgrade ?
[23:23] <slangasek> that would be bad
[23:23] <slangasek> :)
[23:23] <slangasek> because it means a user who disagreed with one of your settings could never override it without uninstalling that package
[23:23] <mathiaz> hum - actually we don't need to call on each upgrade - just on install
[23:23] <slangasek> right
[23:28]  * slangasek tries to understand why a bug requesting a freeze exception for inkscape gets marked as applying to Baltix
[23:29] <ScottK2> slangasek: I often wonder the same thing about Ubuntu Backports bugs.
[23:29] <slangasek> pitti: btw, would you mind doing the FFe request for samba?  I think it might be better to have someone other than me doing it
[23:29] <mathiaz> ScottK2: so what about this: modify the default dovecot configuration file to export its sasl socket to /var/spool/postfix/private/auth, create a new package that depends on postfix and dovecot and call the postconf commands to setup postfix to run with sasl from the postinst script ?
[23:29] <slangasek> ScottK2: I can at least see in theory how a backport bug might apply to more than one distribution
[23:30] <ScottK2> slangasek: I suppose, but it's the "Ubuntu Backports" project.  Even if they want the same package, it's off topic for the bug.
[23:30] <lamont> slangasek: because the baltix guys like to mark everything as applying to them?  dunno
[23:30] <lamont> that's because the backport bug is a task, not a bug.
[23:30] <ScottK2> mathiaz: And then mail-server tasksel can install that?
[23:31] <mathiaz> ScottK2: yes - we'd add the new package to the mail-server task
[23:31] <ScottK2> lamont: It is a bug against a separate project
[23:31] <ScottK2> mathiaz: Sounds much saner than what we have now.
[23:31] <slangasek> ScottK2: well, bugs can apply to more than one project, that's how we mark upstream tasks ttoo..
[23:31] <ScottK2> I'd run it by slangasek
[23:31] <mathiaz> ScottK2: now I wonder if we could add the postconf call in dovecot postinst script
[23:32] <ScottK2> mathiaz: I'd say not.  Not all those things are specific to dovecot integration.
[23:32] <mathiaz> ScottK2: right - actually it's just postfix specific
[23:33] <mathiaz> ScottK2: it's just a package that configures postfix to run with sasl
[23:33] <ScottK2> mathiaz: Yes.
[23:35] <slangasek> ScottK2: sounds fine to me
[23:36] <mathiaz> ScottK2: slangasek: great ! I'll update the bug with the proposal
[23:37] <lamont> slangasek: what (if anything) do you need before you can sync bind9 from sid (bug 200739)
[23:37] <ubotu> Launchpad bug 200739 in bind9 "bind9 apparmor profile is named apparmor-profile" [Undecided,Fix committed] https://launchpad.net/bugs/200739
[23:37] <slangasek> lamont: a time transplant
[23:37] <lamont> meh
[23:37] <lamont> because of freeze, or something else?
[23:39] <slangasek> lamont: because the worldclock stole my time and sold it to Monterrey
[23:39] <lamont> heh
[23:39] <slangasek> lamont: seriously, it's on my list; I don't think I'm missing any info for it, I just need to get to it
[23:39] <lamont> no worries
[23:39] <lamont> I just wanted to make sure it was on the list.
[23:39]  * Hobbsee adds a bug to the beta list, and knocks one out.  yay!
[23:40] <lamont> and not blocked on something stupid from me.
[23:40] <lamont> Hobbsee: bad to play with overflow like that
[23:40] <Hobbsee> heh
[23:40] <slangasek> lamont: oh - actually, that wasn't an FFe, which means it's really on the list of whoever's on archive duty today ;)
[23:43] <keescook> mjg59: did you push a branch with the usplash/libdisasm goo somewhere?
[23:43] <slangasek> bryce, keescook: hnngh, who puts a changelog in *alphabetical* order?
[23:44] <Hobbsee> slangasek: |sort does?  :0
[23:44] <slangasek> inkscape == sort, gotcha
[23:44] <keescook> slangasek: something that auto-extracts from a svn log?
[23:45] <Hobbsee> slangasek: should i just chuck a blanket "no" on anything filed 24h bfeore beta?
[23:45] <slangasek> Hobbsee: heh, your prerogative to do so if you'd like to
[23:46] <Hobbsee> slangasek: gnumeric would be nice though, having seen the last one
[23:46] <Hobbsee> slangasek: (i've no idea if you want me doing u-release bugs)
[23:46] <slangasek> Hobbsee: also your prerogative if you'd like to, I won't turn away the help :)
[23:46] <Hobbsee> slangasek: heh :)
[23:47] <Hobbsee> slangasek: i still have the mighty powers.  haven't wanted to risk them being taken away though
[23:47] <slangasek> Hobbsee: in fact, you're welcome to review samba, which I'm recusing myself on
[23:47] <Hobbsee> ew
[23:48]  * Hobbsee pukes
[23:48] <Hobbsee> Nexuiz is packaged a little "strangely." There's no source package, per se, but there are source zip files contained in the binary release.
[23:48] <Hobbsee> wth?
[23:49] <keescook> niiice
[23:49] <keescook> Hobbsee: is that new?  I swear I compiled something when I was playing with nexuiz and the hardening options (benchmarks)
[23:49] <Hobbsee> ScottK2: any objections to putting a blanket "no" on most of the release stuff?
[23:49] <Hobbsee> keescook: i've no idea.  i'm just going thru the quuee
[23:50] <keescook> Hobbsee: the only thing in the queue I'd really like to see get through is setools
[23:50] <ScottK2> Hobbsee: For universe we still have a fair amount of time.  I think we should still look at them.
[23:51] <Hobbsee> ScottK2: a lot of them require archive admin stuff
[23:51] <TheMuso> ScottK2: I agree.
[23:51] <Hobbsee> keescook: main or universe?
[23:51] <ScottK2> Hobbsee: For New packages I agree.
[23:52] <ScottK2> For sync's I think it's no so bad.  If you're worried about that we can just have motu-release use syncpackage.py
[23:52] <Hobbsee> ScottK2: just ones which create new binaries, etc.
[23:53] <ScottK2> OK
[23:53] <ScottK2> Those I'd look very hard at.
[23:54] <keescook> Hobbsee: universe (for main, I'm hoping to get inkscape through)
[23:54] <Hobbsee> (split into -data, etc)
[23:54]  * Hobbsee keeps trying to drop the queue size
[23:55] <Hobbsee> 50 down to...31!
[23:58] <Hobbsee> keescook: done setools, but please do the transitional packages too