[00:19] Fujitsu: hmm, was the hal fixing the dimming brightness for you too for a while? [00:19] or am i just going mad? [00:43] is anyone here running Xgl? If so could you run xvinfo | grep Xgl ? [00:43] Adaptor #0: "Xgl Generic Texture Video" [00:43] bryce: ^^ :) [00:44] after all these years, fglrx 8.40.4+Xgl is STILL the most stable/smooth setup for my mobility x1400 [00:44] I just gave up on Catalyst 8-3 after a week's time with it [00:49] jdong whoohoo thanks! [00:49] jdong: could you also run 'xrandr -v' ? [00:49] Server reports RandR version 1.2 [00:50] interesting! thanks === RAOF_ is now known as RAOF [00:55] jdong: That's disappointing. I was hoping that xgl could go away. [00:55] 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] RAOF: tell me about it; I actually shed some tears when catalyst 8-3 failed to deliver [00:59] bryce: I agree === dijital1_away is now known as dijital1 [01:55] 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] Launchpad bug 194214 in xorg-server "Keys get "stuck" down" [High,Confirmed] https://launchpad.net/bugs/194214 [03:17] Anyone happen to know if there is a py module kicking around for reading .dsc's? [03:20] compbrain: python-debian should do it. [03:20] slangasek: you around? [03:21] * ScottK wonders about python-apt [03:21] ScottK: python-apt can do it as well probably, but doing it in python-debian is pretty simple. [03:24] ScottK: I didn't see anything in python-apt that could do stuff with a non-deb [03:32] heya fabbione :) [03:39] compbrain: OK. I guess I won't wonder anymore [04:29] hi emgent [04:33] lamont: moo [04:35] morning guys [04:41] * slangasek waves [05:31] how do i write new blueprints? [05:31] i don't find the option [05:32] nxvl, https://blueprints.edge.launchpad.net/specs/+new [05:41] emethnx [05:42] emgent: thnx [05:42] np :P [06:00] RAOF: sorry no, it needs to be reported upstream [06:08] RAOF: I've been meaning to do that, but instead selfishly prioritized the bugs that I'm seeing when triaging ;) [06:09] hm, s/when.*// === cjwatson_ is now known as cjwatson [07:06] 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] tjaalton: Following that, I was going to try raw upstream git xserver. [07:08] good morning [07:23] Good morning [07:25] morning pitti, dholbach [07:25] Hi Hobbsee, pitti, dholbach. [07:30] RAOF: excellent, thanks [07:59] doko_: ah, python-xml in component-mismatches \o/ demoted [08:00] doko_: p-pysqlite2: http://paste.ubuntu.com/5609/ [08:04] lool: ah, elisa finally starts up, thanks! [08:05] 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 === doko_ is now known as doko [08:23] pitti: python-xml: asked ScottK to do the same in universe, and then remove it [08:27] pitti: I think your initial experience with elisa is interesting to note down [08:27] 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] 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] pitti: To some extent, it's meant to be configured once (or using the defaults) on a dedicate box near your TV [08:29] hello, my x keeps hanging when i use an ftp mount. Is there a known bug about this? [08:29] lool: how is that done? vi .elisa/config? [08:29] pitti: /usr/share/doc/elisa/FIRST_RUN [08:30] pitti: In .elisa/elisa.conf [08:30] 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] pitti: I'm happy to relay your impressions to the elisa folks; I'm sure they would be interested [08:35] lool: ah, that works now, I added the paths to the config file [08:35] 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] pitti: FIRST_RUN covers the important keybindings (enter for play/pause) [08:43] lool: right, just getting used to it :) [08:43] 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] pitti: Oh reminds me: are you still looking at its main promotion? [08:43] lool: yes, now that it actually works [08:45] 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] But shouldn't change SONAME or anything, just bug fixes AIUI [08:48] 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 === pbn_ is now known as pbn [08:51] Riddell: hey [08:51] 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] Riddell: I'd like to have your opinion about hwdb-client in bug 195519 [08:51] Riddell: i. e. do you rather want to keep hwdb-client-kde, or drop it entirely, given that it is mostly useless? [08:52] pitti, cr3 had promised me the new gui would be done for hardy (doesnt seem to be the case though :( ) [08:52] ogra_cmpc_: We're working on it, but it isn't working for now [08:53] ah, k, i thought you had it solved already [08:53] ogra_cmpc_: What we managed doing is starting a CK session; there are many ways to do this [08:53] The problem we're facing at the moment is making that session the active one [08:53] seb128: FYI, I gave-back gnome-games, libgnomeui, eel, and eog for now [08:53] yeah, i have a similar prob with ltsp logins [08:53] seb128: sorry if that causes some more FTBFS spam [08:53] 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] pitti: thanks, don't worry about the mails, I just mark those all read usually [08:54] 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] lool: I have code that marks the session active by hand, if it would help [08:54] cjwatson: Does it require root? [08:54] 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] seb128: I wait until libgnomeui is built and published, then I'll give back everything else [08:54] cjwatson: Anyway, any contribution at this point is useful [08:54] * lool grabs bug id [08:55] pitti: alright [08:55] https://bugs.edge.launchpad.net/ubuntu/+source/xinit/+bug/199486 [08:55] ogra_cmpc_, cjwatson ^^^ [08:55] pitti: You're also welcome to comment [08:55] lool: not certain [08:55] 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] is that like the pam thing wrapped ? [08:56] However it's not helping as it's not aware of the DISPLAY at the moment it's launching the session [08:56] ogra_cmpc_: Exactly, so doesn't solve the issue we're having [08:56] yeah [08:56] I didn't have time to resume discussion [08:56] you probably don't want to use the pam module as such [08:56] right [08:56] cjwatson: Oh why not? We planned doing so [08:57] why doesn't xinit have root privileges? [08:57] oh, if you're willing to hack complete PAM support into xinit, sure [08:57] cjwatson: It wasn't enough, but I think it did as well as ck-start-sesison [08:57] I didn't think it started a PAM session at the moment, though [08:57] cjwatson: We're using "su" before starting startx [08:57] starting a PAM session requires root at *some* point [08:57] lool: if ck-launch-session helps you, we can certainly port it [08:57] pitti: I think not [08:57] lool: sounds just like a shallow wrapper around open_session_with_parameters()? [08:57] pitti: Michael checked the code and it basically does what the xinit patch did [08:58] pitti, it does the same as the already existing pam module [08:58] ah, ok [08:58] pitti: Unfortunately that call is root-only [08:58] 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] pitti: So we'd have to move to the Xorg server *shiver* [08:58] pitti: Exactly [08:58] lool: right, it must be root only [08:58] pitti: I'm just mentionning this because upstream told us so, but I think it was misguiding [08:58] lool: I've attached the openssh patch to the bug, but I'm not sure how much it'll help you [08:58] cjwatson: Thanks [08:59] 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] cjwatson: Because we don't have the display at that time [09:00] cjwatson: It's basically su launching startx as ume which spawns Xorg as root [09:00] (I mean Xorg is suid root) [09:00] oh, right [09:00] cjwatson: Thanks for the patch [09:01] doing it in the X server would be too evil for words [09:01] 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] cjwatson: haha [09:01] you can't use the PAM module with openssh for reasons too tedious to enumerate [09:01] basically privilege separation awkwardness [09:01] Is this a design issue of the CK PAM module? [09:01] no [09:02] As in, it should be using some helper to gain the privs it needs [09:02] AH [09:02] no, it's just how openssh internals are arranged [09:02] actually sort of similar to your problem in some ways - when the PAM session is opened, you don't know DISPLAY yet [09:02] It's sad to have PAM and to not be able touse it [09:02] because the client hasn't yet requested the forwarded X connection [09:02] Oh [09:02] Ok [09:03] or, for that matter, the tty [09:03] you can have ttyless ssh sessions, you see ... [09:03] Sure [09:03] I understand the tty can be requested at any time, just like you can add port forwarding or X11 forwarding [09:03] And it's way too late to hope to use sshd root rights or PAM [09:04] openssh actually does have a method to get back to root [09:04] cjwatson: Thanks for the explanations [09:04] which in fact is used by the consolekit patch [09:04] you could probably ssh -X localhost and have a sshd listen on lo [09:04] but I don't think that's relevant to your problem [09:04] cjwatson: Oh; I wouldn't have expected that [09:04] it's very carefully constrained [09:04] cjwatson: It's not relevant, but interesting nevertheless :) [09:04] i.e. bring up your X server and loop back to run xinint though ssh [09:04] if you see a mention of the "monitor" in openssh source, that's what that's doing [09:05] 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] heh [09:05] ;) [09:05] 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] of course there is a certain historical expectation that running startx as a mortal user will DTRT [09:06] Yes [09:06] ++ [09:06] I've used it for years when I considered gdm dangerous for my X sessions [09:06] gdm is fine as long as you dont want to restart or stop it :) [09:07] Also, I guess it's going to make us start a Xsession as root too [09:07] exactly which dbus call is root-only? [09:07] cjwatson: The one with params [09:07] cjwatson: Which are required to pass the x11-display [09:07] cjwatson: The FD bug has some details of the params which we might want to set [09:07] because I thought I remembered testing this as an ordinary user [09:08] Michael Frey told me it wouldn't work as it was root only I think [09:08] He commented as such in the FD bug [09:09] ah, yes, you're right [09:09] * ogra_cmpc_ thinks it was to early for CK inclusion [09:09] 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] I guess I must have been using sudo dbus-send [09:09] this really doesn't feel right in the X server at all [09:09] I understand we don't want to start a CK session there, but as Xorg is setting the VT etc. [09:10] cjwatson: But Xorg is the exact place where the system objects are requested/created [09:10] And where the DISPLAY comes to life [09:10] Naturally, I'm not happy with DBus coming into play with Xorg :-/ [09:10] to me it feels slightly ugly to make X.org depend on CK [09:10] (for a library call) [09:11] it's less ugly to try and call ck-create-session, and just ignore if it isn't there [09:11] What about a Xorg module? [09:11] the X server is wrong because if you're using remote X then it is on the wrong machine [09:11] the CK session is a client-side concept, not server-side [09:12] (with the usual confused X meanings of client and server) [09:12] cjwatson: I see; so we can have multiple sessions with the same display? [09:12] consider X sessions forwarded over ssh [09:12] they share an X server, but the actual DISPLAY variable is something different on a different host [09:12] same goes for xdmcp [09:13] this is why it should be the responsibility of the session manager [09:13] or the display manager if relevant [09:13] 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] maybe you just need a trivial display manager [09:13] Or is this extending the local CK session? [09:14] 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] and session manager, rolled into one [09:14] cjwatson: So sshd is where the virtual DISPLAY comes to birth [09:15] sort of, but I think that's the wrong way to think about it [09:15] its a proxy server [09:15] display managers are actually quite easy to write [09:15] if you aren't trying to be gdm [09:16] LTSP has a trivial one called ldm, and I wrote adapted versions of that for oem-config and ubiquity [09:16] cjwatson: Do we have anything close to such a dumb DM? [09:16] Ah LDM, thanks [09:16] it's 100-odd lines of Python [09:16] well, ldm is C now [09:16] right, oem-config-dm isn't though ;-) [09:16] look at the pre gutsy code for ldm in python [09:16] cjwatson, ogra_cmpc_, pitti: mind if I copy this log to the bug report? [09:16] oem-config-dm is probably a better place to start as it doesn't have the ssh stuff [09:16] not at all [09:17] of course not [09:17] fine with me === \sh_away is now known as \sh [09:17] it's publically logged anyway [09:17] pitti: (Yeah, but I asked for politeness ;) [09:17] in oem-config-dm's case, it is told the display by its caller [09:18] but the same usually goes for xinit as called by startx, doesn't it? [09:18] Yes [09:18] yep [09:18] I guess providing a display to startx isn't mandatory [09:18] 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] From what I understand, xinit starts the server and then a client and it does know about the VT and the DISPLAY [09:19] It just needs enough power to tell CK about it [09:19] the display manager could do that - it starts processes inside the display [09:19] ArneGoetje: do you still need someone who still sees the scim issue? [09:20] oem-config-dm starts X, a window manager, stuff like gnome-settings-daemon, and the main "greeter" (in this case, oem-config [09:20] ) [09:20] cjwatson: But when you just "startx", you don't have a DM [09:20] right, I'm suggesting not using startx [09:21] 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] Since after all this ought to work as well [09:21] oh, if we're talking *theory* [09:21] Well would we fix startx we wouldn't have to use a DM either [09:22] maybe xinit needs to be setuid [09:22] 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] and drop privileges when executing the client, obviously [09:22] Perhaps we could tell CK to please update it's information by looking at DISPLAY? [09:22] This kind of helper might not need any special rights at all [09:23] 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] "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] if you can, then either consolekit's permissions are too strict, or we are attempting to exploit a security hole [09:23] which is all very well but not a good thing to build an application around [09:23] Well OpenSessionWithParameters implies that the params will be trusted [09:24] While what I'm proposing is that CK be pinged to please refresh its info [09:24] sorry, I meant "if you can only do OpenSessionWithParameters as root" above [09:24] CK does have helpers to figure stuff out from an X display [09:24] Oh perhaps it's the only thing we're missing [09:25] We have bits to start a session [09:25] We just need to tell it about VT and DISPLAY of this session [09:25] Hmm this is probably the security limit [09:25] you only need to tell it DISPLAY [09:26] (in theory) [09:26] and the content of DISPLAY needs to contain your hostname ... then the session will become active automatically i was told [09:26] The security limit is probably related to "who are you to tell me what DISPLAY this CK session is using" I guess [09:27] 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] Thanks all for discussion [09:28] thanks for answering my question :) [09:28] * ogra_cmpc_ beats i810 with a bat [09:28] why the heck does that thing eat 50M extra if i use it ... [09:29] lool: have you tried just calling org.freedesktop.ConsoleKit.Manager.OpenSession? [09:29] and letting it guess? [09:30] 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] so it can't just be dbus-send [09:30] (we need a dbus-send --exec=command or something) [09:30] cjwatson: I didn't try this [09:32] I wonder why I didn't try to start the session under Xorg [09:32] it looks in /proc/blah/environ to fish out DISPLAY [09:33] But just ck-launch-session from within Xorg should simply work [09:33] and i wonder why we dont make it mandatory to have that dbus call in x-session-manager ... [09:33] that way we wouldnt need to hack up all display managers [09:33] I'll try to hook it to Xsession.d [09:34] does ck-launch-session spawn a subprocess with the rest of your session? [09:34] 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] http://cvs.fedoraproject.org/viewcvs/devel/xorg-x11-xinit/xinitrc?r1=1.3&r2=1.4 [09:35] yes, it appears to [09:35] http://gitweb.freedesktop.org/?p=ConsoleKit.git;a=blob;h=73111816d3785996ee25c18dc24e0a3657272428;hb=4740245c6f6137175ef51be2207c35185f4d98f1;f=tools/ck-launch-session.c [09:35] that would be perfect, then [09:36] I really have a brain bug [09:36] it wraps OpenSession, not OpenSessionWithParameters [09:36] so it doesn't require root [09:36] So it exactly does what it's supposed to do: look at the DISPLAY of the calling process [09:36] so the whole discussion above is overengineering :-) [09:36] Ok, let us ship a Xsession script within consolekit then? [09:37] hmm, it should only call ck-launch-session if XDG_SESSION_COOKIE isn't already set [09:37] but yes, that does sound like a good solution [09:37] Sure [09:37] pitti: please demote the python-qt4-gl binary package, we don't want to have the pyopengl dependency in main [09:39] doko: hm, that's not in component-mismatches; I wonder what holds it in main [09:39] (argh, ENOSSH again) [09:39] pitti, hmm I see it there [09:40] 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] doko: I don't [09:40] doko: (should be in 'binary-only demotion') [09:41] http://people.ubuntu.com/~ubuntu-archive/component-mismatches.txt shows it in "Source and binary promotions to main" [09:42] 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] doko: once I get back ssh, I'll demote it [09:42] cjwatson: Interestingly, it also means starting a CK session from PAM would be harmful [09:46] 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] Mirv: what did you update? [09:47] Mirv: tsclient didn't change for a while, not like due to it, did you update language packs today? [09:48] 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] policykit-gnome never even had that tag, but somehow the translation was there until today [09:49] (and there's no upstream translation for policykit-gnome) [09:49] seb128: the translations for the .desktop items are still there in the .mo files for all of those three [09:49] ah, I know [09:49] will fix it [09:50] it's all lool fault ;-) [09:50] he asked for a glib2.0 sync [09:50] but we have a gettext patch there which is not in the debian serie [09:50] seb128: whee, great. I feel so like a poor bug reporter since I have no clue what happened :) [09:50] fixing it now [09:54] n/ [09:54] ugh [09:56] carlos: how do you build your "not uptodate list"? [09:56] 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] 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] doko: I think it would be excellent if we could get PySignal_SetWakeupFd() in our python [10:01] doko: Do you think that's risky/doable? [10:01] lool: not if XDG_SESSION_COOKIE were set, which it would be [10:01] cjwatson: Well if we don't start a session when XDG_SESSION_COOKIE is set, how does CK know about the display? [10:02] doko: Background in http://bugzilla.gnome.org/show_bug.cgi?id=481569 [10:02] doko: This is included in our pygobject and pygtk [10:04] asac: if you have time, please do. :) [10:06] lool: hmm, I thought I had this done, but apparently not ... [10:06] 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] doko: demoted python-qt4-gl [10:07] * lool & [10:08] Riddell: thanks [10:08] 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] Riddell: so, I'll just unseed it for Kubuntu then? [10:09] seb128: but I guess there may be some race conditions [10:09] carlos: ok [10:09] seb128: like gnome-desktop one [10:09] pitti: I'll do it [10:09] Riddell: ok, please let me commit the changes to ubuntu/gobuntu first [10:09] Riddell: so that it can become a proper merge [10:10] Riddell: committed to ubuntu.hardy, feel free to merge now === ogra_cmpc_ is now known as ogra_cmpc [10:12] ogra_cmpc: would you mind merging the edubuntu.hardy seed? it's nontrivial [10:12] pitti, you sure thats needed ? edubuntu depends on ubuntu-desktop [10:13] pitti: merging the seeds doesn't really work any more [10:13] ogra_cmpc: ah, right, seems it's not; so they are not real branches any more [10:13] right [10:13] Riddell: I see; ok, then just kill hwdb-client, please [10:13] there is a dependency chain in place now [10:14] hm, I still had to do it for gobuntu [10:14] seems that isn't converted yet then? [10:14] (maybe ubuntu should be on top of gobuntu, since ubuntu adds restricted stuff?) [10:16] 661/c [10:16] damn wireless keyboard needs resyncing again... [10:16] TheMuso: .00000220333333333333 [10:17] * dholbach likes the new pitti-bot [10:17] pitti: 100 Rupies in Euros [10:18] dholbach: 6250 [10:18] pitti: poke [10:18] hi YokoZar [10:18] TheMuso: .00000220485870603287 actually :) [10:18] 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] pitti: heh [10:18] . o O { pitti-bot needs a serious update } [10:19] pitti: amd64 was added to control as an arch last upload [10:19] YokoZar: control file has Architecture: i386 here [10:19] in 1.510-1 [10:19] Err that link is to 1.510-2ubuntu1 [10:20] Which is newer [10:20] oh, it's in universe now, sorry [10:20] On the left of that page launchpad says its for amd64 and i386 [10:20] I bet it's P-a-S'ed [10:21] Did it just get demoted or something? [10:22] $ grep zsnes /srv/launchpad.net/builddmaster/Packages-arch-specific [10:22] zsnes: i386 # Mostly written in i386 assembler [10:22] there we go [10:22] YokoZar: something for infinity or lamont to fix [10:23] pitti: Ahh, cool. Should I bug them or you? [10:23] YokoZar: we keep them in sync with Debian, so I can't change them [10:23] 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] if the Architecture: is right, we shouldn't need it? [10:23] lamont, infinity: ^ [10:24] ogra_cmpc: ... vesa? there goes your performance? [10:24] pitti: Yeah. If the control file just says i386 no need to hardcode that elsewhere. [10:24] pitti, exactly the opposite o_O [10:24] 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] By linking with 32 bit libraries (in much the same way Wine works on 64 bit) [10:26] 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] *available [10:27] ogra_cmpc: awesome [10:27] YokoZar: ah, ia32-libs to the rescue? :) [10:27] .... and i never even thought remotely about testing vesa here ... just did that by accident [10:27] lool: XDG_SESSION_COOKIE is set after the CK session is created, not the other way round [10:28] pitti: I didn't quite get as far as converting the Gobuntu seeds to the new world order [10:28] 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] it's a hideous hack and a maintenance nightmare (not even mentioning unfixed security bugs) [10:31] pitti: please accept openjdk-6 (binary NEW) [10:32] 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] YokoZar: that's usually not a problem for the development release [10:33] but that thing bitrots fast in stables [10:33] On the plus side, only a few programs seem to depend on it [10:36] 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] 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]