[00:04] Ampelbein: See http://tinyurl.com/6jjs2k [00:06] ScottK: ah, ok. thanks for the hint. [00:06] You're welcome. [01:03] TheMuso: Ping, re bug #182731 and my patch attached to the Debian bug. [01:03] Launchpad bug 182731 in alsa-plugins "Provide a lib32asound2-plugins package" [Wishlist,Confirmed] https://launchpad.net/bugs/182731 [01:18] RAOF: Let me catch up on email first, then I [01:18] RAOF: Let me catch up on email first, then I'll take a look./ [01:19] TheMuso: Thanks. I should have though of it earlier in the dev cycle, but it's only just popped back into my bugmail. I'd basically like your opinion on whether it'd be worth a FFe. [01:20] RAOF: Ok. [01:27] Is the gcc buildd breakage fixed? It seems gtk-nodoka-engine got hit on ia64 and hppa. The mail to ubuntu-devel seems somewhat ambiguous to me on this point. [05:15] RAOF: With your pulseaudio oddities, are you using kernel 2.6.27-2-generic? [05:15] TheMuso: Yes. [05:16] RAOF: And how did 0.9.11 go in comparison? Added to that, have you considered trying pulseaudio git master? [05:17] 0.9.11 introduced the pops & craziness; 0.9.10 worked fine. [05:17] I haven't tried pulseaudio git; I will if you like (once internet exists at home again). [05:18] I also haven't tried alsa/alsa-lib git. [05:19] (Although crimsun suggests that alsa git should fix it). [05:20] Right, I saw that. I'll checkout the latest alsa-lib git commits and see if I can find which one it is, and make a package for testing. [05:20] If not upload the aptch directly to intrepid. [05:21] TheMuso: Did you have any thoughts on the "make libasound-plugins generate libasound32-plugins" patch? [05:21] RAOF: Still not there yet. I am still processing bug mail. [05:21] Mail processing alone has tgaken me all day so far, due to having a week off, and having to catch up. [05:21] Aaah, of course! You're back from holday! [05:22] Sorry for adding to the pile. Feel free to ignore me for a while :) [05:22] (I trust your week off was fun/relaxing/profitable/enjoyable) [05:23] he probably spent the week thinking about bugs [05:23] RAOF: Very refreshing mentally, yes indeed. [05:25] Good to hear. [05:25] ajmitch: I actually managed to spend the week not thinking about work, which was my aim. :p [05:25] TheMuso: well done, I'm impressed :) [05:26] ajmitch: Its not that hard really. Just don't check ubuntu related email, and get off IRC. === EagleSn is now known as EagleScreen [06:15] jdong: google implies you know the answer to a question of mine: http://209.85.173.104/search?q=cache:W07g0VIiRf4J:irclogs.ubuntu.com/2006/12/05/%2523ubuntu-devel.html+ubuntu+%22amd64+to+x86%22&hl=en&ct=clnk&cd=9&gl=us [06:15] slangasek: Thanks for the heads up on the debian dmraid work. I was actually going to send my changes to them this week, but they beat me to it. I'll work with them now to get the code usable etc. [06:15] jdong: basically, how would one trick ubuntu into letting me reinstall all my pacakges as x86 if I'm on an amd64 install? [06:22] floam: I believe the answer is 'dpkg --get-selections > pkglist', followed by debootstrapping an IA32 install, followed by 'dpkg --set-selections < pkglist'. [06:23] RAOF: thanks. [06:26] RAOF: shall I manually remove packages that exist only in amd64 like "lib32gcc" from that list? [06:27] or will dpkg --set-selections not freak the heck out? [06:27] I don't believe that dpkg --set-selections will freak out, no. It just won't be able to install it. [06:27] Note that I haven't actually _performed_ this proceedure at any point; I'm quite happy with my x86-64 install. [06:28] I would be, but this is an install on a 64MB VPS, and I kind of didn't think of the RAM ramifications of 64bits when I first installed. [06:28] heh, RAMifications. sorry. [06:30] Yeah. More general purpose registers probably doesn't offset doubling the size of all your pointers ;) [06:37] ok, here it goes. I'm going to prey debootstrapping a mounted / doesn't cause fire. [06:44] RAOF: hm, I'm not sure it worked. [06:45] no errors, and debootstrap sure did a bunch of stuff [06:45] but after --set-selections nothing appears to want to be done if I apt-get install, and it's definitely not already occured [06:45] /sbin/init is x86-64, and anything else I check. [06:48] and it's going for amd64 debs even if I --reinstall something. [06:49] (I did a sudo 'debootstrap --arch=i386 intrepid /') [06:51] Hm. I'd've thought that would have worked. [06:52] hmmm [06:52] apt-get clean might have changed the situation [06:52] it's now going for i386 if I reinstall something. [06:52] but it's still not wanting to do that all on it's own. [06:53] Into / ? [06:53] Blink [06:53] StevenK: yep [06:53] Heh. "aptitude reinstall ~n"! [06:53] it's kind of okay if everything breaks, since I'd have to reinstall anyways to get what I want. [06:54] That's .... insane [06:55] RAOF: it sure got a big list of stuff to reinstall together [06:55] but [06:55] : I wasn't able to locate file for the libgpmg1 package. This might mean you need to manually fix this package. [06:55] floam: please, never ever ever write docs for ubuntu. thanks. [06:55] I guess that might mean it was something that was amd64 only, so I can nuke it [06:55] lifeless: I'd never dream of it. [06:56] nuking worked and it's going. [07:00] RAOF: it fetched a lot of stuff but "E: Couldn't configure pre-depend coreutils for dpkg, probably a dependency cycle." [07:00] don't think I'm going to nuke either of those. [07:00] That seems like a bad plan, yes. [07:00] is there a way to have it just reinstall every package irrespective of deps [07:00] since they shouldn't really matter, since I've got everything that it will end up needing one would think [07:11] TheMuso: great :) [07:16] RAOF: I'm doing it manually, I will achieve success at some point, or at least fail honorably [07:20] RAOF: re https://launchpad.net/bugs/182731 I thought you had attached a debdiff/implementation to the bug. I think its worth considering, but it depends on how much work it is to do it. [07:20] Launchpad bug 182731 in alsa-plugins "Provide a lib32asound2-plugins package" [Wishlist,Confirmed] [07:20] TheMuso: There's a debdiff attached to the Debian bug. [07:21] TheMuso: Sorry, I obviously didn't make it clear. [07:21] RAOF: NP, I'll dig that up. [07:22] I _think_ it applies directly to the Ubuntu package, too, but I can't test it until my internet works again! [07:25] RAOF: You say, connected to IRC. [07:25] ...At Uni. [07:25] I'm not entirely sure they'd be happy with me bootstrapping an Intrepid chroot and going buildd-crazy. [07:27] RAOF: Why not? It's like, what, 100MB? :-) [07:28] would only take a few minutes to build [07:28] Other impediments include: no root access. [07:28] RAOF: clearly, you should leave uni :P [07:29] RAOF: fakechroot :-P [07:29] RAOF: It wouldn't apply, as alsa-plugins in intrepid is now 1.0.17. You would also have to drop the jack build-depend. [07:30] RAOF: Without testing myself however, does any of the resulting new binary packages depend on ia32-libs? [07:30] RAOF: .. and at some point through this, the system is back to trying to use amd64 packages. I think I'm going to have to reinstall from scratch and give up. [07:30] Good morning [07:30] Morning pitti [07:30] TheMuso: I think they would, actually. Yes. [07:31] Well then its no go, as ia32libs is universe. [07:31] Arse. [07:31] Unless we split out new 32-bit packages for all pieces that ia32-libs is needed for. [07:31] I can't see that getting promoted, either [07:31] * TheMuso agrees with StevenK. [07:31] To be useful we'd need a libpulse32 at least. [07:32] RAOF: Yeah. This is something to consider for intrepid+1 though perhaps... [07:32] Unless TheMuso and I fly to Germany and threaten pitti with grevious bodily tickling until he gives in, or something. [07:32] TheMuso: Right. Or when magical dpkg fairies make no-change multiarch a reality. [07:32] StevenK: I'm of the opinion we just make bi-arch packages for the bits we need, like what RAOF is proposing re alsa-plugins. [07:33] But even so, thats for next cycle,.] [07:33] Morning pitti. [07:33] wow, no dist-upgrade today? [07:34] oh, broken gcc, right :/ [07:35] That's not fixed yet? [07:35] RAOF: No. [07:35] Bummer. It has, however, lead to my discovery of the "retry" button in launchpad. === tkamppeter_ is now known as tkamppeter [07:55] hi tkamppeter === superm1|away is now known as superm1 [08:10] hi pitti [08:11] did you have a look at my 2 new branches for jockey? [08:13] hey tseliot; not yet, last week I got again too distracted, but working on jockey this week [08:14] ok [08:17] pitti: BTW part of the code (x-kit, the recommended version) is already being tested in envyng 2.0 in Intrepid. [08:17] tseliot: right, and also from the screen size configuration applet, right? [08:17] pitti: yes. right [08:17] it's also in main since last Thursday or so, so we can use xkit in j now [08:18] yes, it's great news [08:26] hi pitti === RainCT is now known as RainCT_ [08:45] good morning [08:48] hi [08:48] anyone on bug #257215? [08:49] Launchpad bug 257215 in fop "Please add dependency on ant-optional" [Undecided,Confirmed] https://launchpad.net/bugs/257215 === superm1 is now known as superm1|away [08:57] liw: python-fstab> you seem to have everything in the .orig.tar.gz, resulting in "dpkg-source: warning: diff `./python-fstab_1.2-0ubuntu1.diff.gz' doesn't contain any patch". Is that deliberate or should it just be packaged as a native package? [08:58] cjwatson, er, it should be packaged as a native package... I'll see to it, thanks [08:59] liw: debian/copyright is inconsistent (v2 vs. v3) [08:59] liw: otherwise it's fine, let me know when that's fixed in bzr and I can sponsor it straight from there [09:00] hm, my build automation can't handle native packages, I thought I'd fixed that [09:01] pitti: do you happen to know what's likely to have broken thinkpad hotkeys in intrepid? [09:01] oh, the version number is not one for native packages, that's why [09:02] mdz: no idea, I'm afraid; hal and hal-info only changed marginally; are they controlled directly by the kernel? [09:02] pitti: they used to generate acpi events via thinkpad_acpi [09:02] right, just found /usr/share/hal/fdi/information/10freedesktop/30-keymap-module-thinkpad-acpi.fdi [09:03] pitti: ought they to show up in lshal -m? [09:03] some thinkpads do, some don't. There's 3 levels of fall-back; however RH were superseding that with a HAL replacement [09:03] hmm, no, apparently not [09:03] cjwatson, pushed the copyright change to bzr; will you build the whole source package from there, or shall I create a new tarball and dsc? [09:03] mdz: I really don't know, never had a thinkpad [09:04] the one which does work (the soft RF kill switch) doesn't generate an event in lshal -m [09:05] Why doesn't libgphoto2 install udev rules anymore? [09:06] mdz: /etc/acpi/events/ibm-wireless is handled by a shell script and doesn't get passed anywhere else [09:06] mdz: I don't get events for things like volume up/down either, Dells have their own custom smbios wiring for those; I just get lshal events for suspend/resume, lid close, etc. [09:06] I do see hal-addon-acpi read an ibm/hotkey HKEY event from acpid [09:07] liw: I can just change it in bzr, but I'll need you to adjust the changelog too [09:07] err, I meant "build it from bzr" [09:07] cjwatson, I thought I did [09:07] sladen: how are the others meant to work? via HAL or directly to acpi-support? [09:08] $ bzr up; head -n1 debian/changelog [09:08] Tree is up to date at revision 28. [09:08] python-fstab (1.2-0ubuntu1) intrepid; urgency=low [09:08] cjwatson, I didn't change the version, though [09:09] liw: I meant that it should be something that's right for native packages [09:09] cjwatson, oh, right -- something (lintian?) complained when I had it as a native package, but you're right, it should be one [09:10] (or rather, it should not be one, actually, but that's a bigger change) [09:10] mdz: I'm not sure of the status; acpi-support was supposed to be going away to be replaced by big-shiny-sledgehammer-solution (HAL). I don't mind other distros doing the work, but it would be good if the replacement worked [09:11] mdz: got frustated/lost interest [09:11] liw: right, should be properly either one thing or the other :) [09:13] volume keys still work without acpi-support, so that seems to be handled by something else now [09:13] the wifi kill stops working though [09:13] cjwatson, I'll make it properly non-native, if you can wait a few minutes [09:15] mdz: the volume keys are in hardware [09:15] liw: sure, thanks [09:15] sladen: what causes them to pop up the volume meter? [09:18] * StevenK gently prods pitti to do some NBS work. [09:18] cjwatson, ok, done; I split the .deb packaged version into its own branch (.../python-fstab.deb-packaging); I'll upload to REVU, so you can use the same .orig.tar.gz as I have, if that's ok? [09:18] mdz: recent thinkpads; ACPI events; older/fallback is (was) via the NVRAM listener, with both getting converted to keystrokes and ejected. The keystrokes are listened for by gnome-volume-manager which deisplays the change [09:19] s/gnome-volume-manager/g-s-d/ [09:19] s/ejected/injected/ [09:19] sladen: my sleep button is handled by sleepbtn.sh which uses acpi_fakekey which seems to have no effect, even when gnome-power-manager is running [09:20] pitti: evince-gtk-dbg evince-gtk libgucharmap6 can all be killed. [09:20] mdz: sleep button is a standard ACPI event; it'll work without any special thinkpad_blah extras [09:20] ..or not [09:21] pitti: does your sleep button work? [09:21] mdz: yes, perfectly, both the lid and the button itself [09:21] RFKill, too [09:22] StevenK: right, and I'll kill the empty ones while I'm at it [09:22] pitti: \o/ [09:22] pitti: this has all regressed for me in intrepid and I'm trying to work out why [09:22] liw: ok, sure [09:23] mdz: just for testing, could you boot with the hardy kernel and see whether it makes any difference? to check whether it's an user or kernel land problem? [09:23] I think the primary reason is bug 260314, but even when I manually run g-p-m it doesn't work [09:23] Launchpad bug 260314 in gnome-power "gnome-power-manager frequently crashes with SIGSEGV in IA__g_closure_invoke() or g_closure_invoke()" [Unknown,Fix released] https://launchpad.net/bugs/260314 [09:24] rfkill on thinkpads is entirely soft (doesn't even yank the USB). rfkill on most other laptops is hard for either the USB bluetooth and/or the rfkill on the wifi card [09:24] sladen: mine has two (a hard switch and a soft key) [09:24] the soft key seems to only affect bluetooth and 3g, while the hard one kills wifi as well [09:24] mdz: the Fn-F5 [09:25] mdz: the soft key not affecting wifi looks like a regression due to a kernel change [09:25] because /sys/class/net/wlan0/device/rf_kill no longer exists for iwl3945, at least [09:26] oh, I thought that would be a network-manager problem, it stopped working properly as soon as we switched to 0.7 [09:26] (had a quick discussion with asac, but no real debugging yet) [09:26] slangasek: I don't have that either with iwl4965, but I do have /sys/class/net/wlan0/device/rfkill:rfkill5 [09:27] interestingly, if I get gnome-power-manager running, it will sleep on lid close as expected [09:27] but still will not sleep with the sleep button [09:27] yes, that's analogous to what I see; so the interface has changed, I don't know yet if that's intentional [09:27] who's supposed to hear the sleep button if not g-p-m? [09:27] mdz: you may have to configure g-p-m with what action it should take on SLEEP prss [09:27] acpi-support did at least /have/ code at one point to suspend iff g-p-m is not running [09:28] sladen: this worked fine in hardy [09:28] mdz: Power Management->General->Action->When Suspend button is pressed, do: [. .... ] [09:29] sladen: 'Suspend' [09:29] sladen: which would still be a regression from hardy if it became un-set [09:29] but pressing the sleep button doesn't generate any activity in g-p-m --verbose [09:30] HAL was set to call pmi on Ubuntu; did pmi get replaced with one of the other suspend frameworks? [09:30] but you're not even seeing the D-Bus call go out from g-p-m to HAL [09:32] mdz: do System->Quit...-> do you get shown the Suspect option, as g-p-m queries for the available capabilities an if you get a timeout g-p-m won't have a positive assertion that the suspect capability is avilable to be called [09:34] cjwatson, it's now in REVU: http://revu.ubuntuwire.com/details.py?package=python-fstab [09:34] currently, I get ACPI events from Fn-F[1-3] and Fn-F[5-9]. Fn-F4 is the 'sleep' button; I assume it generated an ACPI event in hardy, but don't know for sure [09:34] sladen: running /usr/lib/hal/scripts/linux/hal-system-power-suspend-linux manually does work (though the -hybrid- version doesn't, I'm not sure which is actually called) [09:34] and the 'power' button doesn't generate an ACPI event [09:35] sladen: we don't have Quit at the moment in intrepid; we have the old upstream gnome logout/shutdown dialogs [09:35] neither shows sleep/suspend for me [09:35] ah, shutdown shows it iff g-p-m is running [09:37] slangasek: yes, hal has used pm-utils since at least hardy [09:37] I think that was meant for the other sla? :)0 [09:37] erm, sladen ^ [09:37] mdz: sorry, yes, my Intrepid laptop install failed a month ago and I grapped other one when leaving a month ago [09:37] mdz: no, we have the new upstream dialog ;-) [09:37] slangasek: yes, ETABDISEASE [09:38] seb128: btw, I find that much more pleasing already than the old upstream one; up to the point where it is actually *bearable* :-) [09:38] seb128: oh, i don't yet [09:38] mdz: maybe you didn't restart your session since the update? [09:38] seb128: btw bug 260314 seems to be fixed upstream, is there a new tarball available with the fix? [09:38] Launchpad bug 260314 in gnome-power "gnome-power-manager frequently crashes with SIGSEGV in IA__g_closure_invoke() or g_closure_invoke()" [Unknown,Fix released] https://launchpad.net/bugs/260314 [09:38] pitti: good ;-) we could get a variant listing all the action using this model [09:38] seb128: probably not, no [09:39] this session started 2 sep [09:39] seb128: that would get too big then again IMHO (7 buttons) [09:39] mdz: ted is supposed to working on the update, I'll ask him when he's around [09:40] mdz: right, might still be using the old dialog then, the new gnome-session has been uploaded the same day [09:40] liw: and r29 of python-fstab.deb-packaging? [09:40] pitti: right, depends if we want all the actions on one dialog [09:41] seb128: well, you know my opinion :) [09:41] seb128: but anyway, I think mpt should have the say here [09:41] right [09:41] cjwatson, that's the right one, yes [09:43] StevenK: NBS slaughtered [09:43] pitti: \o/ [09:44] liw: uploaded [09:44] StevenK: your's, libsmbios{1,xml1}, the empty ones, and linux* [09:44] soren: I think I have bad news for you: http://paste.ubuntu.com/44484/ [09:44] pitti: I suspect the list needs a regen after the next publisher run? [09:44] yes [09:44] (hardy amd64 host, intrepid guest) [09:45] cjwatson, thank you [09:47] seb128: while we're on the subject, have you seen bug #267018? :) [09:47] Launchpad bug 267018 in gnome-settings-daemon "regression: g-s-d no longer handles Fn+F7 as xrandr --auto" [Low,Confirmed] https://launchpad.net/bugs/267018 [09:47] slangasek: didn't before now but I'll have a look, thanks for the bug report ;-) [09:48] great, thanks. :) [09:50] I investigated it as far as I could, but I don't know how hal is supposed to pass the key from acpid to g-s-d so couldn't check if it was working right [09:53] oh, buildds are broken right, going to be fun to upload the new GNOME today [09:53] seb128: well, we'll need a giant give-back-everything anyway [09:54] doko: btw, I think I can get you an affected buildd chroot, if you need it for investigation? [09:55] seb128: ok, meanwhile I've backported that one fix because it's crashing for a lot of people and generating dupes [09:55] mdz: please upload, thanks ;-) [09:55] seb128: gnome-power-manager_2.23.6-0ubuntu2_source.changes: done. [09:55] cool [09:56] pitti: does suspend work for your D430 currently on intrepid? [09:56] seb128: yes [09:56] seb128: however, I remember BenC saying that 2.6.27-2 has a major regression, and that it is fixed in the coming -3 upload [09:56] ok [09:56] (regression in suspend) [09:57] was blocked by a5 [09:57] it doesn't for me, it blank the screen but doesn't power down [09:57] and doesn't wake up either [09:58] dholbach: Dear, oh dear. How did you do that? [09:58] the kernel part works fine for me, it's just harder to trigger without the sleep key working :-) [09:58] seb128: sudo pm-suspend works? [09:58] soren: booted it up, started an upgrade [09:58] soren: didn't do much [09:58] pitti: I'll try in a bit [10:00] pitti: when you press your sleep button, do you see output in gnome-power-manager --verbose? [10:01] mdz: yes, http://paste.ubuntu.com/44488/ [10:01] dholbach: "it"? :) [10:02] pitti: ah, so the event is coming from hal [10:02] soren: I the intrepid guest [10:02] s/I// [10:02] 11:02:24.277: computer_logicaldev_input_1 condition ButtonPressed = power [10:02] dholbach: Ok. Hardy host, still? [10:02] mdz: ^ lshal -m for power button [10:02] soren: yeah [10:03] pitti: is your power button set to suspend or something? [10:03] mdz: it triggers the logout/switch user dialog [10:03] just like ctrl+alt+del [10:03] pitti: oh, I am talking about the sleep button (moon symbol) which is supposed to suspend immediately [10:03] (which is wrong, it should trigger the shutdown/reboot/suspend dialog) [10:04] mdz: oh, I pressed the hardware power button [10:04] mdz: ok, trying [10:05] I would think that with evdev, this would actually have a *better* chance of working but it seems not [10:05] mdz: I see an applet for switching off, but not one for suspend? [10:05] pitti: applet? [10:05] mdz: well, which moon symbol do you mean then? [10:06] pitti: the one on the keyboard [10:06] oh, that [10:06] pitti: on my F4 key, there is a blue moon, and Fn+F4 in hardy put the system to sleep [10:06] pitti: sorry, I should have said key rather than button [10:06] mdz: right, I tend to forget about it, I mostly work docked with my kinesis :) trying... [10:07] mdz: however, in ealier verrsions, the moon was hibernate (since suspend is already lid close) [10:07] trying, brb [10:07] pitti: I have a separate key for that [10:08] mdz: right, confirmed; moon (Fn+F1 for me) does nothing, no gpm output either [10:08] pitti: do you know if it worked in hardy? [10:08] mdz: and Fn+F3 (battery status) doesn't work either any more (worked fine for hardy) [10:08] pitti: suspend seems to work today [10:09] mdz: yes, definitively worked in hardy (both keys) [10:09] pitti: I think evdev has broken this, but I'm not sure where to file the bug (hal-info?) [10:09] I've sometime the boot stopping on a corrupted flashing screen, does anybody knows what information could be useful for a bug report? === seb128_ is now known as seb128 [10:09] evdev has also toasted my media keys, and my compose key :/ [10:09] hm, I don't know about the evdev plumbing either, so it's as good as any for a starting point [10:10] mdz: watching hal in debugging mode might probably help, too [10:10] if hal reacts to the key, it sounds like hal-info problem; if nothing triggers hal, it's a lower-level -evdev problem [10:11] seb128: through normal lid close and g-p-m, too, or just with sudo pm-suspend? [10:12] pitti: I tried pm-suspend and then the gnome dialog [10:12] great [10:12] pitti: [5352]: 10:12:24.864 [D] addon-acpi.c:195: event is 'ibm/hotkey HKEY 00000080 00001004 [10:12] Hmm would someone be so kind to lookup why linux-lpia wasn't accepted yesterday evening and during this night? I tried pushing it twice from remote hosts, but I realize the process to prepare the .changes was special [10:13] lool: if you didn't get an email, I think you need to ask the soyuz team [10:13] mdz: I didn't; will do thanks [10:13] mdz: ah, a sign of life at least [10:13] pitti: however I know acpi-support is converting that into an input event [10:13] and I don't see anything receiving that [10:15] I think this all supposed to work through standard evdev events [10:15] how do those look like? (I don't know evdev at all, I'm afraid) [10:17] pitti,slangasek: the closest bug report I've found so far is bug 258177 [10:17] Launchpad bug 258177 in ubuntu "Special keys (dim display, lock screen) don't work anymore on intrepid wiht my X61s" [Undecided,New] https://launchpad.net/bugs/258177 [10:18] but that might be bug 255008 in disguise [10:18] Launchpad bug 255008 in xorg-server "Up arrow key mapped to Print [screen]" [High,Fix released] https://launchpad.net/bugs/255008 [10:18] shall we open a new bug report about ths and figure out where to put it later? [10:19] sure, as a place to collect all the debug info so far [10:25] pitti,slangasek: bug 267682 [10:25] Launchpad bug 267682 in ubuntu "Hotkeys no longer working in Intrepid (evdev?)" [Undecided,New] https://launchpad.net/bugs/267682 [10:25] linux-lpia> sorted elsewhere [10:26] classic "unsigned .changes => no mail telling you it went wrong" [10:29] I generated the checksums by hand and signed the .dsc then updated the .changes then forgot to sign it ah it's really to hard by hand; I should write some helper to do this [10:29] Simply the reverse of debrsign [10:29] cjwatson: thanks again [10:29] lool: It needs a --backward option? :-) [10:31] lool: debsign -r ? [10:31] lool: works fine for me [10:32] pitti: Oh yeah, that's more like it [10:47] Keybuk: Hey, we have a couple of issues with the upstart script we are using the start the Xorg session in ubuntu-mid images; the first issue is that when we moved to intrepid, startx would fail if called directly because the xinit "was this called from console" check was failing, this was solved by prepending the command with openvt; now the issue is that upstart seems to spawn multiple of these [10:48] currently it's exec openvt -w -s -- su -l ubuntu -c "startx -- -br" [10:48] err, I don't know anything about the first one [10:48] that sounds like xinit/startx voodoo [10:48] and I've _never_ understood why there are so many ways to start /usr/bin/X [10:48] Keybuk: Could it be that the upstart behavior with vts / consoles changed slightly? [10:48] if Upstart is spawning multiple, it sounds like your command is exiting? [10:49] Upstart doesn't really *have* any "behaviour" in this regard [10:49] -w wait for command to complete. If -w and -s are used together [10:49] then openvt will switch back to the controlling terminal when [10:49] the command completes. [10:49] sounds like openvt exits in the foreground ;) [10:49] can you really not start x from /dev/console? [10:50] Yeah, I suggested -e instead of -w, but wasn't sure whether upstart was happy with that, but I guess it would be [10:50] what is the exact error you get if you just do exec su -l ubuntu -c "startx -- -br" ? [10:50] Keybuk: Perhaps we can, I could try with /dev/console 2>&1 [10:50] Keybuk: If we just do this, we see nothing [10:50] lool: stdin/out/etc. should already be /dev/console! [10:50] you have "console owner" in your job file, right? === mdz_ is now known as mdz [10:51] Keybuk: One I added /dev/tty redirects, I started seeing the permission check for user is on console thing [10:51] Keybuk: We don't, but I tried using that [10:51] before coming up with openvt [10:51] permission check? [10:51] what does that look like? [10:51] I had to add console owner and dev/tty redirections to see the error spit by xinit [10:52] Keybuk: I mean the "is user on console" Xorg permission check [10:52] how does it check that? [10:53] I didn't look it up, I thought it was looking at permissions of current tty [10:53] there is no current tty [10:53] well the one of startx [10:53] that's what I mean [10:53] upstart doesn't actually activate any ttys [10:53] you're just on /dev/console at that point [10:54] which is whatever that's plumbed into in the kernel [10:54] it's not a tty itself [10:56] Keybuk: So I reverted to console owner + su only (no openvt), the error message displayed in loop after "start session" is "X: user not authorized to run the X server" [10:57] Keybuk: This wasn't the case in hardy, so either Xorg or upstart changed in that respect; perhaps the check was changed [10:57] lool: Actually, in Hardy, ume-config-common ran sed on Xwrapper.conf [10:57] StevenK: ahh that explains [10:58] sed -i -e 's/allowed_users=.*/allowed_users=anybody/' /etc/X11/Xwrapper.config [10:58] so we were disabling the security check, nice [10:58] Yes. [10:58] And you wanted reasons to boot ume-config-common out of the archive. [10:58] Oh the gconftool calls in postinst were good enough for me [10:58] Heh [10:59] Ok, so I'm really looking at a problem which exists since gutsy and was worked around by disabling security checks [11:00] Any archiver willing to help with bug 263863? It just needs to accept a new binary from hardy NEW. [11:00] Launchpad bug 263863 in claws-mail-extra-plugins "Some plugins don't load with the new 3.5.0 version" [Undecided,Confirmed] https://launchpad.net/bugs/263863 [11:02] hey StevenK [11:02] * StevenK waves [11:02] * NCommander waves back [11:03] How goes your $TIME_OF_DAY StevenK ? [11:03] * StevenK is about to cook curry for dinner [11:03] Damn, I haven't had good curry in years :-/ [11:10] NCommander: How do you survive!? [11:11] not easily [11:33] Keybuk: The "is user on console" check is a Debian one it seems (xorg/debian/local/xserver-wrapper.c) and is implemented with a fstat on stdin to check whether it's a char device with VT_MAJOR_DEV as major [11:34] Keybuk: I'm not sure /dev/console satisfies, it's major 5 instead of 4 [11:34] . o O { xinit-blacklist } [11:34] Keybuk: But we could add support for /dev/console in this Debian wrapper [11:34] that would seem sane [11:35] I first thought it was based on utmp info as login was setting this up before calling into pam, but it seems not [11:35]