[00:04] <ScottK> Ampelbein: See http://tinyurl.com/6jjs2k
[00:06] <Ampelbein> ScottK: ah, ok. thanks for the hint.
[00:06] <ScottK> You're welcome.
[01:03] <RAOF> TheMuso: Ping, re bug #182731 and my patch attached to the Debian bug.
[01:18] <TheMuso> RAOF: Let me catch up on email first, then I
[01:18] <TheMuso> RAOF: Let me catch up on email first, then I'll take a look./
[01:19] <RAOF> 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] <TheMuso> RAOF: Ok.
[01:27] <RAOF> 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] <TheMuso> RAOF: With your pulseaudio oddities, are you using kernel 2.6.27-2-generic?
[05:15] <RAOF> TheMuso: Yes.
[05:16] <TheMuso> RAOF: And how did 0.9.11 go in comparison? Added to that, have you considered trying pulseaudio git master?
[05:17] <RAOF> 0.9.11 introduced the pops & craziness; 0.9.10 worked fine.
[05:17] <RAOF> I haven't tried pulseaudio git; I will if you like (once internet exists at home again).
[05:18] <RAOF> I also haven't tried alsa/alsa-lib git.
[05:19] <RAOF> (Although crimsun suggests that alsa git should fix it).
[05:20] <TheMuso> 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] <TheMuso> If not upload the aptch directly to intrepid.
[05:21] <RAOF> TheMuso: Did you have any thoughts on the "make libasound-plugins generate libasound32-plugins" patch?
[05:21] <TheMuso> RAOF: Still not there yet. I am still processing bug mail.
[05:21] <TheMuso> Mail processing alone has tgaken me all day so far, due to having a week off, and having to catch up.
[05:21] <RAOF> Aaah, of course!  You're back from holday!
[05:22] <RAOF> Sorry for adding to the pile.  Feel free to ignore me for a while :)
[05:22] <RAOF> (I trust your week off was fun/relaxing/profitable/enjoyable)
[05:23] <ajmitch> he probably spent the week thinking about bugs
[05:23] <TheMuso> RAOF: Very refreshing mentally, yes indeed.
[05:25] <RAOF> Good to hear.
[05:25] <TheMuso> ajmitch: I actually managed to spend the week not thinking about work, which was my aim. :p
[05:25] <ajmitch> TheMuso: well done, I'm impressed :)
[05:26] <TheMuso> ajmitch: Its not that hard really. Just don't check ubuntu related email, and get off IRC.
[06:15] <floam> 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] <TheMuso> 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] <floam> 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] <RAOF> floam: I believe the answer is 'dpkg --get-selections > pkglist', followed by debootstrapping an IA32 install, followed by 'dpkg --set-selections < pkglist'.
[06:23] <floam> RAOF: thanks.
[06:26] <floam> RAOF: shall I manually remove packages that exist only in amd64 like "lib32gcc" from that list?
[06:27] <floam> or will dpkg --set-selections not freak the heck out?
[06:27] <RAOF> I don't believe that dpkg --set-selections will freak out, no.  It just won't be able to install it.
[06:27] <RAOF> Note that I haven't actually _performed_ this proceedure at any point; I'm quite happy with my x86-64 install.
[06:28] <floam> 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] <floam> heh, RAMifications. sorry.
[06:30] <RAOF> Yeah.  More general purpose registers probably doesn't offset doubling the size of all your pointers ;)
[06:37] <floam> ok, here it goes. I'm going to prey debootstrapping a mounted / doesn't cause fire.
[06:44] <floam> RAOF: hm, I'm not sure it worked.
[06:45] <floam> no errors, and debootstrap sure did a bunch of stuff
[06:45] <floam> 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] <floam> /sbin/init is x86-64, and anything else I check.
[06:48] <floam> and it's going for amd64 debs even if I --reinstall something.
[06:49] <floam> (I did a sudo 'debootstrap --arch=i386 intrepid /')
[06:51] <RAOF> Hm.  I'd've thought that would have worked.
[06:52] <floam> hmmm
[06:52] <floam> apt-get clean might have changed the situation
[06:52] <floam> it's now going for i386 if I reinstall something.
[06:52] <floam> but it's still not wanting to do that all on it's own.
[06:53] <StevenK> Into / ?
[06:53] <StevenK> Blink
[06:53] <floam> StevenK: yep
[06:53] <RAOF> Heh.  "aptitude reinstall ~n"!
[06:53] <floam> it's kind of okay if everything breaks, since I'd have to reinstall anyways to get what I want.
[06:54] <StevenK> That's .... insane
[06:55] <floam> RAOF: it sure got a big list of stuff to reinstall together
[06:55] <floam> but
[06:55] <floam> : I wasn't able to locate file for the libgpmg1 package. This might mean you need to manually fix this package.
[06:55] <lifeless> floam: please, never ever ever write docs for ubuntu. thanks.
[06:55] <floam> I guess that might mean it was something that was amd64 only, so I can nuke it
[06:55] <floam> lifeless: I'd never dream of it.
[06:56] <floam> nuking worked and it's going.
[07:00] <floam> RAOF: it fetched a lot of stuff but "E: Couldn't configure pre-depend coreutils for dpkg, probably a dependency cycle."
[07:00] <floam> don't think I'm going to nuke either of those.
[07:00] <RAOF> That seems like a bad plan, yes.
[07:00] <floam> is there a way to have it just reinstall every package irrespective of deps
[07:00] <floam> since they shouldn't really matter, since I've got everything that it will end up needing one would think
[07:11] <slangasek> TheMuso: great :)
[07:16] <floam> RAOF: I'm doing it manually, I will achieve success at some point, or at least fail honorably
[07:20] <TheMuso> 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] <RAOF> TheMuso: There's a debdiff attached to the Debian bug.
[07:21] <RAOF> TheMuso: Sorry, I obviously didn't make it clear.
[07:21] <TheMuso> RAOF: NP, I'll dig that up.
[07:22] <RAOF> I _think_ it applies directly to the Ubuntu package, too, but I can't test it until my internet works again!
[07:25] <StevenK> RAOF: You say, connected to IRC.
[07:25] <RAOF> ...At Uni.
[07:25] <RAOF> I'm not entirely sure they'd be happy with me bootstrapping an Intrepid chroot and going buildd-crazy.
[07:27] <StevenK> RAOF: Why not? It's like, what, 100MB? :-)
[07:28] <ajmitch> would only take a few minutes to build
[07:28] <RAOF> Other impediments include: no root access.
[07:28] <lifeless> RAOF: clearly, you should leave uni :P
[07:29] <StevenK> RAOF: fakechroot :-P
[07:29] <TheMuso> 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] <TheMuso> RAOF: Without testing myself however, does any of the resulting new binary packages depend on ia32-libs?
[07:30] <floam> 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] <pitti> Good morning
[07:30] <StevenK> Morning pitti
[07:30] <RAOF> TheMuso: I think they would, actually.  Yes.
[07:31] <TheMuso> Well then its no go, as ia32libs is universe.
[07:31] <RAOF> Arse.
[07:31] <TheMuso> Unless we split out new 32-bit packages for all pieces that ia32-libs is needed for.
[07:31] <StevenK> I can't see that getting promoted, either
[07:31]  * TheMuso agrees with StevenK.
[07:31] <RAOF> To be useful we'd need a libpulse32 at least.
[07:32] <TheMuso> RAOF: Yeah. This is something to consider for intrepid+1 though perhaps...
[07:32] <StevenK> Unless TheMuso and I fly to Germany and threaten pitti with grevious bodily tickling until he gives in, or something.
[07:32] <RAOF> TheMuso: Right.  Or when magical dpkg fairies make no-change multiarch a reality.
[07:32] <TheMuso> 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] <TheMuso> But even so, thats for next cycle,.]
[07:33] <TheMuso> Morning pitti.
[07:33] <pitti> wow, no dist-upgrade today?
[07:34] <pitti> oh, broken gcc, right :/
[07:35] <RAOF> That's not fixed yet?
[07:35] <TheMuso> RAOF: No.
[07:35] <RAOF> Bummer.  It has, however, lead to my discovery of the "retry" button in launchpad.
[07:55] <pitti> hi tkamppeter
[08:10] <tseliot> hi pitti
[08:11] <tseliot> did you have a look at my 2 new branches for jockey?
[08:13] <pitti> hey tseliot; not yet, last week I got again too distracted, but working on jockey this week
[08:14] <tseliot> ok
[08:17] <tseliot> pitti: BTW part of the code (x-kit, the recommended version) is already being tested in envyng 2.0 in Intrepid.
[08:17] <pitti> tseliot: right, and also from the screen size configuration applet, right?
[08:17] <tseliot> pitti: yes. right
[08:17] <pitti> it's also in main since last Thursday or so, so we can use xkit in j now
[08:18] <tseliot> yes, it's great news
[08:26] <tkamppeter> hi pitti
[08:45] <dholbach> good morning
[08:48] <quadrispro> hi
[08:48] <quadrispro> anyone on bug #257215?
[08:57] <cjwatson> 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] <liw> cjwatson, er, it should be packaged as a native package... I'll see to it, thanks
[08:59] <cjwatson> liw: debian/copyright is inconsistent (v2 vs. v3)
[08:59] <cjwatson> liw: otherwise it's fine, let me know when that's fixed in bzr and I can sponsor it straight from there
[09:00] <liw> hm, my build automation can't handle native packages, I thought I'd fixed that
[09:01] <mdz> pitti: do you happen to know what's likely to have broken thinkpad hotkeys in intrepid?
[09:01] <liw> oh, the version number is not one for native packages, that's why
[09:02] <pitti> mdz: no idea, I'm afraid; hal and hal-info only changed marginally; are they controlled directly by the kernel?
[09:02] <mdz> pitti: they used to generate acpi events via thinkpad_acpi
[09:02] <pitti> right, just found /usr/share/hal/fdi/information/10freedesktop/30-keymap-module-thinkpad-acpi.fdi
[09:03] <mdz> pitti: ought they to show up in lshal -m?
[09:03] <sladen> some thinkpads do, some don't.  There's 3 levels of fall-back; however RH were superseding that with a HAL replacement
[09:03] <mdz> hmm, no, apparently not
[09:03] <liw> 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] <pitti> mdz: I really don't know, never had a thinkpad
[09:04] <mdz> the one which does work (the soft RF kill switch) doesn't generate an event in lshal -m
[09:05] <amitk> Why doesn't libgphoto2 install udev rules anymore?
[09:06] <sladen> mdz: /etc/acpi/events/ibm-wireless is handled by a shell script and doesn't get passed anywhere else
[09:06] <pitti> 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] <mdz> I do see hal-addon-acpi read an ibm/hotkey HKEY event from acpid
[09:07] <cjwatson> liw: I can just change it in bzr, but I'll need you to adjust the changelog too
[09:07] <cjwatson> err, I meant "build it from bzr"
[09:07] <liw> cjwatson, I thought I did
[09:07] <mdz> sladen: how are the others meant to work? via HAL or directly to acpi-support?
[09:08] <cjwatson> $ bzr up; head -n1 debian/changelog
[09:08] <cjwatson> Tree is up to date at revision 28.
[09:08] <cjwatson> python-fstab (1.2-0ubuntu1) intrepid; urgency=low
[09:08] <liw> cjwatson, I didn't change the version, though
[09:09] <cjwatson> liw: I meant that it should be something that's right for native packages
[09:09] <liw> cjwatson, oh, right -- something (lintian?) complained when I had it as a native package, but you're right, it should be one
[09:10] <liw> (or rather, it should not be one, actually, but that's a bigger change)
[09:10] <sladen> 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] <sladen> mdz: got frustated/lost interest
[09:11] <cjwatson> liw: right, should be properly either one thing or the other :)
[09:13] <mdz> volume keys still work without acpi-support, so that seems to be handled by something else now
[09:13] <mdz> the wifi kill stops working though
[09:13] <liw> cjwatson, I'll make it properly non-native, if you can wait a few minutes
[09:15] <sladen> mdz: the volume keys are in hardware
[09:15] <cjwatson> liw: sure, thanks
[09:15] <mdz> sladen: what causes them to pop up the volume meter?
[09:18]  * StevenK gently prods pitti to do some NBS work.
[09:18] <liw> 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] <sladen> 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] <sladen> s/gnome-volume-manager/g-s-d/
[09:19] <sladen> s/ejected/injected/
[09:19] <mdz> 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] <StevenK> pitti: evince-gtk-dbg evince-gtk libgucharmap6 can all be killed.
[09:20] <sladen> mdz: sleep button is a standard ACPI event;  it'll work without any special thinkpad_blah extras
[09:20] <sladen> ..or not
[09:21] <mdz> pitti: does your sleep button work?
[09:21] <pitti> mdz: yes, perfectly, both the lid and the button itself
[09:21] <pitti> RFKill, too
[09:22] <pitti> StevenK: right, and I'll kill the empty ones while I'm at it
[09:22] <StevenK> pitti: \o/
[09:22] <mdz> pitti: this has all regressed for me in intrepid and I'm trying to work out why
[09:22] <cjwatson> liw: ok, sure
[09:23] <pitti> 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] <mdz> I think the primary reason is bug 260314, but even when I manually run g-p-m it doesn't work
[09:24] <sladen> 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] <mdz> sladen: mine has two (a hard switch and a soft key)
[09:24] <mdz> the soft key seems to only affect bluetooth and 3g, while the hard one kills wifi as well
[09:24] <sladen> mdz: the Fn-F5
[09:25] <slangasek> mdz: the soft key not affecting wifi looks like a regression due to a kernel change
[09:25] <slangasek> because /sys/class/net/wlan0/device/rf_kill no longer exists for iwl3945, at least
[09:26] <pitti> oh, I thought that would be a network-manager problem, it stopped working properly as soon as we switched to 0.7
[09:26] <pitti> (had a quick discussion with asac, but no real debugging yet)
[09:26] <mdz> slangasek: I don't have that either with iwl4965, but I do have /sys/class/net/wlan0/device/rfkill:rfkill5
[09:27] <mdz> interestingly, if I get gnome-power-manager running, it will sleep on lid close as expected
[09:27] <mdz> but still will not sleep with the sleep button
[09:27] <slangasek> yes, that's analogous to what I see; so the interface has changed, I don't know yet if that's intentional
[09:27] <mdz> who's supposed to hear the sleep button if not g-p-m?
[09:27] <sladen> mdz: you may have to configure g-p-m with what action it should take on SLEEP prss
[09:27] <slangasek> acpi-support did at least /have/ code at one point to suspend iff g-p-m is not running
[09:28] <mdz> sladen: this worked fine in hardy
[09:28] <sladen> mdz: Power Management->General->Action->When Suspend button is pressed, do: [. .... ]
[09:29] <mdz> sladen: 'Suspend'
[09:29] <slangasek> sladen: which would still be a regression from hardy if it became un-set
[09:29] <mdz> but pressing the sleep button doesn't generate any activity in g-p-m --verbose
[09:30] <sladen> HAL was set to call pmi on Ubuntu;  did pmi get replaced with one of the other suspend frameworks?
[09:30] <sladen> but you're not even seeing the D-Bus call go out from g-p-m to HAL
[09:32] <sladen> 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] <liw> cjwatson, it's now in REVU: http://revu.ubuntuwire.com/details.py?package=python-fstab
[09:34] <slangasek> 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] <mdz> 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] <slangasek> and the 'power' button doesn't generate an ACPI event
[09:35] <mdz> sladen: we don't have Quit at the moment in intrepid; we have the old upstream gnome logout/shutdown dialogs
[09:35] <mdz> neither shows sleep/suspend for me
[09:35] <mdz> ah, shutdown shows it iff g-p-m is running
[09:37] <pitti> slangasek: yes, hal has used pm-utils since at least hardy
[09:37] <slangasek> I think that was meant for the other sla? :)0
[09:37] <pitti> erm, sladen ^
[09:37] <sladen> mdz: sorry, yes, my Intrepid laptop install failed a month ago and I grapped other one when leaving a month ago
[09:37] <seb128> mdz: no, we have the new upstream dialog ;-)
[09:37] <pitti> slangasek: yes, ETABDISEASE
[09:38] <pitti> 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] <mdz> seb128: oh, i don't yet
[09:38] <seb128> mdz: maybe you didn't restart your session since the update?
[09:38] <mdz> seb128: btw bug 260314 seems to be fixed upstream, is there a new tarball available with the fix?
[09:38] <seb128> pitti: good ;-) we could get a variant listing all the action using this model
[09:38] <mdz> seb128: probably not, no
[09:39] <mdz> this session started 2 sep
[09:39] <pitti> seb128: that would get too big then again IMHO (7 buttons)
[09:39] <seb128> mdz: ted is supposed to working on the update, I'll ask him when he's around
[09:40] <seb128> mdz: right, might still be using the old dialog then, the new gnome-session has been uploaded the same day
[09:40] <cjwatson> liw: and r29 of python-fstab.deb-packaging?
[09:40] <seb128> pitti: right, depends if we want all the actions on one dialog
[09:41] <pitti> seb128: well, you know my opinion :)
[09:41] <pitti> seb128: but anyway, I think mpt should have the say here
[09:41] <seb128> right
[09:41] <liw> cjwatson, that's the right one, yes
[09:43] <pitti> StevenK: NBS slaughtered
[09:43] <StevenK> pitti: \o/
[09:44] <cjwatson> liw: uploaded
[09:44] <pitti> StevenK: your's, libsmbios{1,xml1}, the empty ones, and linux*
[09:44] <dholbach> soren: I think I have bad news for you: http://paste.ubuntu.com/44484/
[09:44] <StevenK> pitti: I suspect the list needs a regen after the next publisher run?
[09:44] <pitti> yes
[09:44] <dholbach> (hardy amd64 host, intrepid guest)
[09:45] <liw> cjwatson, thank you
[09:47] <slangasek> seb128: while we're on the subject, have you seen bug #267018? :)
[09:47] <seb128> slangasek: didn't before now but I'll have a look, thanks for the bug report ;-)
[09:48] <slangasek> great, thanks. :)
[09:50] <slangasek> 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] <seb128> oh, buildds are broken right, going to be fun to upload the new GNOME today
[09:53] <pitti> seb128: well, we'll need a giant give-back-everything anyway
[09:54] <pitti> doko: btw, I think I can get you an affected buildd chroot, if you need it for investigation?
[09:55] <mdz> seb128: ok, meanwhile I've backported that one fix because it's crashing for a lot of people and generating dupes
[09:55] <seb128> mdz: please upload, thanks ;-)
[09:55] <mdz> seb128:   gnome-power-manager_2.23.6-0ubuntu2_source.changes: done.
[09:55] <seb128> cool
[09:56] <seb128> pitti: does suspend work for your D430 currently on intrepid?
[09:56] <pitti> seb128: yes
[09:56] <pitti> 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] <seb128> ok
[09:56] <pitti> (regression in suspend)
[09:57] <pitti> was blocked by a5
[09:57] <seb128> it doesn't for me, it blank the screen but doesn't power down
[09:57] <seb128> and doesn't wake up either
[09:58] <soren> dholbach: Dear, oh dear. How did you do that?
[09:58] <mdz> the kernel part works fine for me, it's just harder to trigger without the sleep key working :-)
[09:58] <pitti> seb128: sudo pm-suspend works?
[09:58] <dholbach> soren: booted it up, started an upgrade
[09:58] <dholbach> soren: didn't do much
[09:58] <seb128> pitti: I'll try in a bit
[10:00] <mdz> pitti: when you press your sleep button, do you see output in gnome-power-manager --verbose?
[10:01] <pitti> mdz: yes, http://paste.ubuntu.com/44488/
[10:01] <soren> dholbach: "it"? :)
[10:02] <mdz> pitti: ah, so the event is coming from hal
[10:02] <dholbach> soren: I the intrepid guest
[10:02] <dholbach> s/I//
[10:02] <pitti> 11:02:24.277: computer_logicaldev_input_1 condition ButtonPressed = power
[10:02] <soren> dholbach: Ok. Hardy host, still?
[10:02] <pitti> mdz: ^ lshal -m for power button
[10:02] <dholbach> soren: yeah
[10:03] <mdz> pitti: is your power button set to suspend or something?
[10:03] <pitti> mdz: it triggers the logout/switch user dialog
[10:03] <pitti> just like ctrl+alt+del
[10:03] <mdz> pitti: oh, I am talking about the sleep button (moon symbol) which is supposed to suspend immediately
[10:03] <pitti> (which is wrong, it should trigger the shutdown/reboot/suspend dialog)
[10:04] <pitti> mdz: oh, I pressed the hardware power button
[10:04] <pitti> mdz: ok, trying
[10:05] <mdz> I would think that with evdev, this would actually have a *better* chance of working but it seems not
[10:05] <pitti> mdz: I see an applet for switching off, but not one for suspend?
[10:05] <mdz> pitti: applet?
[10:05] <pitti> mdz: well, which moon symbol do you mean then?
[10:06] <mdz> pitti: the one on the keyboard
[10:06] <pitti> oh, that
[10:06] <mdz> pitti: on my F4 key, there is a blue moon, and Fn+F4 in hardy put the system to sleep
[10:06] <mdz> pitti: sorry, I should have said key rather than button
[10:06] <pitti> mdz: right, I tend to forget about it, I mostly work docked with my kinesis :) trying...
[10:07] <pitti> mdz: however, in ealier verrsions, the moon was hibernate (since suspend is already lid close)
[10:07] <pitti> trying, brb
[10:07] <mdz> pitti: I have a separate key for that
[10:08] <pitti> mdz: right, confirmed; moon (Fn+F1 for me) does nothing, no gpm output either
[10:08] <mdz> pitti: do you know if it worked in hardy?
[10:08] <pitti> mdz: and Fn+F3 (battery status) doesn't work either any more (worked fine for hardy)
[10:08] <seb128_> pitti: suspend seems to work today
[10:09] <pitti> mdz: yes, definitively worked in hardy (both keys)
[10:09] <mdz> pitti: I think evdev has broken this, but I'm not sure where to file the bug (hal-info?)
[10:09] <seb128_> I've sometime the boot stopping on a corrupted flashing screen, does anybody knows what information could be useful for a bug report?
[10:09] <slangasek> evdev has also toasted my media keys, and my compose key :/
[10:09] <pitti> hm, I don't know about the evdev plumbing either, so it's as good as any for a starting point
[10:10] <pitti> mdz: watching hal in debugging mode might probably help, too
[10:10] <pitti> 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] <pitti> seb128: through normal lid close and g-p-m, too, or just with sudo pm-suspend?
[10:12] <seb128> pitti: I tried pm-suspend and then the gnome dialog
[10:12] <pitti> great
[10:12] <mdz> pitti: [5352]: 10:12:24.864 [D] addon-acpi.c:195: event is 'ibm/hotkey HKEY 00000080 00001004
[10:12] <lool> 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] <mdz> lool: if you didn't get an email, I think you need to ask the soyuz team
[10:13] <lool> mdz: I didn't; will do thanks
[10:13] <pitti> mdz: ah, a sign of life at least
[10:13] <mdz> pitti: however I know acpi-support is converting that into an input event
[10:13] <mdz> and I don't see anything receiving that
[10:15] <mdz> I think this all supposed to work through standard evdev events
[10:15] <pitti> how do those look like? (I don't know evdev at all, I'm afraid)
[10:17] <mdz> pitti,slangasek: the closest bug report I've found so far is bug 258177
[10:18] <mdz> but that might be bug 255008 in disguise
[10:18] <mdz> shall we open a new bug report about ths and figure out where to put it later?
[10:19] <pitti> sure, as a place to collect all the debug info so far
[10:25] <mdz> pitti,slangasek: bug 267682
[10:25] <cjwatson> linux-lpia> sorted elsewhere
[10:26] <cjwatson> classic "unsigned .changes => no mail telling you it went wrong"
[10:29] <lool> 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] <lool> Simply the reverse of debrsign
[10:29] <lool> cjwatson: thanks again
[10:29] <StevenK> lool: It needs a --backward option? :-)
[10:31] <pitti> lool: debsign -r ?
[10:31] <pitti> lool: works fine for me
[10:32] <lool> pitti: Oh yeah, that's more like it
[10:47] <lool> 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] <lool> currently it's exec openvt -w -s -- su -l ubuntu -c "startx -- -br"
[10:48] <Keybuk> err, I don't know anything about the first one
[10:48] <Keybuk> that sounds like xinit/startx voodoo
[10:48] <Keybuk> and I've _never_ understood why there are so many ways to start /usr/bin/X
[10:48] <lool> Keybuk: Could it be that the upstart behavior with vts / consoles changed slightly?
[10:48] <Keybuk> if Upstart is spawning multiple, it sounds like your command is exiting?
[10:49] <Keybuk> Upstart doesn't really *have* any "behaviour" in this regard
[10:49] <Keybuk>        -w     wait for command to complete. If -w and  -s  are  used  together
[10:49] <Keybuk>               then  openvt  will  switch back to the controlling terminal when
[10:49] <Keybuk>               the command completes.
[10:49] <Keybuk> sounds like openvt exits in the foreground ;)
[10:49] <Keybuk> can you really not start x from /dev/console?
[10:50] <lool> 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] <Keybuk> what is the exact error you get if you just do exec su -l ubuntu -c "startx -- -br" ?
[10:50] <lool> Keybuk: Perhaps we can, I could try with </dev/console >/dev/console 2>&1
[10:50] <lool> Keybuk: If we just do this, we see nothing
[10:50] <Keybuk> lool: stdin/out/etc. should already be /dev/console!
[10:50] <Keybuk> you have "console owner" in your job file, right?
[10:51] <lool> Keybuk: One I added /dev/tty redirects, I started seeing the permission check for user is on console thing
[10:51] <lool> Keybuk: We don't, but I tried using that
[10:51] <lool> before coming up with openvt
[10:51] <Keybuk> permission check?
[10:51] <Keybuk> what does that look like?
[10:51] <lool> I had to add console owner and dev/tty redirections to see the error spit by xinit
[10:52] <lool> Keybuk: I mean the "is user on console" Xorg permission check
[10:52] <Keybuk> how does it check that?
[10:53] <lool> I didn't look it up, I thought it was looking at permissions of current tty
[10:53] <Keybuk> there is no current tty
[10:53] <lool> well the one of startx
[10:53] <Keybuk> that's what I mean
[10:53] <Keybuk> upstart doesn't actually activate any ttys
[10:53] <Keybuk> you're just on /dev/console at that point
[10:54] <Keybuk> which is whatever that's plumbed into in the kernel
[10:54] <Keybuk> it's not a tty itself
[10:56] <lool> 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] <lool> Keybuk: This wasn't the case in hardy, so either Xorg or upstart changed in that respect; perhaps the check was changed
[10:57] <StevenK> lool: Actually, in Hardy, ume-config-common ran sed on Xwrapper.conf
[10:57] <lool> StevenK: ahh that explains
[10:58] <StevenK>     sed -i -e 's/allowed_users=.*/allowed_users=anybody/' /etc/X11/Xwrapper.config
[10:58] <lool> so we were disabling the security check, nice
[10:58] <StevenK> Yes.
[10:58] <StevenK> And you wanted reasons to boot ume-config-common out of the archive.
[10:58] <lool> Oh the gconftool calls in postinst were good enough for me
[10:58] <StevenK> Heh
[10:59] <lool> Ok, so I'm really looking at a problem which exists since gutsy and was worked around by disabling security checks
[11:00] <norsetto> Any archiver willing to help with bug 263863? It just needs to accept a new binary from hardy NEW.
[11:02] <NCommander> hey StevenK
[11:02]  * StevenK waves
[11:02]  * NCommander waves back
[11:03] <NCommander> How goes your $TIME_OF_DAY StevenK ?
[11:03]  * StevenK is about to cook curry for dinner
[11:03] <NCommander> Damn, I haven't had good curry in years :-/
[11:10] <wgrant> NCommander: How do you survive!?
[11:11] <NCommander> not easily
[11:33] <lool> 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] <lool> Keybuk: I'm not sure /dev/console satisfies, it's major 5 instead of 4
[11:34] <Keybuk> . o O { xinit-blacklist }
[11:34] <lool> Keybuk: But we could add support for /dev/console in this Debian wrapper
[11:34] <Keybuk> that would seem sane
[11:35] <lool> 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] <Keybuk> never rely on utmp ;)
[11:36] <lool> Yeah utmp stuff is scary
[11:36] <Keybuk> it's not scary so much as wildly inaccurate
[11:36] <lool> Like it strips "/dev/" and then "tty" to setup your utmp record
[11:37] <Keybuk> that's pretty usual
[11:37] <lool> I find it weird to rely on pathnames
[11:38] <alien> sabdfl: ping
[11:38] <Keybuk> utmp dates back to the days when you could trust your fellow users ;)
[11:38] <lool> Exactly how it feels
[11:38] <Keybuk> it's from the security thought processes that gave us NFS
[11:38] <lool> The ordering of calls isn't very paranoiac
[11:39] <Keybuk> utmp is intended to tell you which user is on which console
[11:39] <Keybuk> and it's so good at it, and so reliable, it's been reinvented at least twice :p
[11:39] <Keybuk> (pam_foreground, ConsoleKit, etc.)
[11:39] <lool> Heh
[11:56] <lool> bryce: Mind if I push to the ubuntu branch of git.debian.org:/git/pkg-xorg/debian/xorg?
[11:56] <lool> bryce: Or would you rather review and pull?  I never pushed to the ubuntu branches
[12:02]  * pochu waves
[12:03]  * ion_ substitutes pochu’s wave function with one without aliasing.
[12:04]  * NCommander uses his COM magic to generate a return_wave callback
[12:07] <pitti> nerds!
[12:07] <pitti> o/ pochu
[12:10] <pochu> hey pitti :)
[12:24] <tjaalton> lool: what do you mean by push?
[12:24] <lool> tjaalton: to git.d.o/git/pkg-xorg/debian/xorg.git (ubuntu branch)
[12:25] <tjaalton> lool: you have changes?
[12:25] <lool> tjaalton: git.debian.org:~lool/public_git/pkg-xorg/debian/xorg
[12:25] <tjaalton> cool, I'll have a look
[12:25] <lool> I'm discussing with jcristau (hey) whether it would make sense to merge in the Debian branch
[12:34] <lool> tjaalton: When building the ubuntu branch, I get ./debian/changelog.Debian.old: no such file or directory; is this something missing from git, or shall I be running something before building this branch?
[12:34] <lool> It's mentionned in debian/x11-common.install
[12:38] <doko> pitti: now that infinity is around, maybe it is more straight forward to have a look at the buildd
[12:39] <tjaalton> lool: seems like it was dropped recently
[12:43] <tjaalton> lool: I'm unable to use that repo of yours..
[12:48] <tjaalton> lool: and the changelog was mistakenly dropped for some reason I fail to see
[12:56] <ogra> mumble ... evolution doesnt like me anymore :(
[13:01] <davmor2> ogra: turn your top shelf ornament 20 degrees counter clockwise should work fine then :)
[13:01]  * ogra tries ... 
[13:01]  * ogra cries ... now the ornament fell off 
[13:02] <tjaalton> lool: changelod.Debian.old added back
[13:02] <ogra> davmor2, it has a print on the back "only turn clockwise" :P
[13:03] <davmor2> ogra: are you by chance trying imap into an account?
[13:03] <ogra> no, i subscribed my evo cal to my google cal last friday
[13:03] <davmor2> ogra: np's turn it 340 degrees clockwise ;)
[13:04] <ogra> since then i expericence hangs and lockups ... and none of the google appointments show up
[13:04] <davmor2> ah pass I never got that to work properly so quit :)
[13:05] <ogra> well, it works for various distro calendars and for the fridge schedule
[13:05] <ogra> so i expected it to work with my googe cal as well ... but apparently i'm wrong :P
[13:05] <ogra> *google
[14:03] <lool> tjaalton: What's the issue with my repo?
[14:04] <mdz> doko: what is the latest news on un-breaking intrepid builds?
[14:04] <lool> tjaalton: Oh sorry, handed you a ssh:// link; try with git://git.debian.org/git/users/lool/pkg-xorg/debian/xorg
[14:06] <tjaalton> lool: yeah, thanks
[14:06] <tjaalton> lool: but still, it only has the .git directory if I clone it?
[14:07] <lool> tjaalton: Didn't set a HEAD, you can either check ubuntu or my feature branch
[14:08] <tjaalton> lool: ah, much better
[14:08] <lool> tjaalton: There, I've setup a HEAD for you (pointing at ubuntu branch)
[14:09] <lool> I also pushed the dev-console-support branch if like jcristau you mind the way I merged in ubuntu
[14:17] <ogra> tjaalton, seems nsc has the same issue as the vga drievr
[14:17] <ogra> *driver
[14:18] <ogra> tjaalton, (with Xorg -configure)
[14:21] <tjaalton> ogra: yes, is -nsc still needed?
[14:21] <ogra> no idea
[14:21] <tjaalton> ogra: I know geode doesn't support all hardware yet..
[14:21] <ogra> we'd need to ask Q-Funk
[14:22] <ogra> i updated bug 265035
[14:22] <ogra> psb doesnt seem to be causing the hang
[14:22] <tjaalton> -nsc recently got support for pciaccess though, so it's fixed upstream
[14:22] <ogra> i dont even get any message about it anymore
[14:22] <ogra> ah
[14:22] <ogra> needs a sync i bet
[14:23] <tjaalton> it'll likely get removed from debian ;)
[14:23] <ogra> -nsc ?
[14:23] <ogra> i thought that was the new one
[14:23] <tjaalton> no, -geode
[14:23] <ogra> wasnt -amd split into -geode and -nsc ?
[14:25] <tjaalton> ogra: I'm not sure but don't think so
[14:25] <ogra> i think it was
[14:25] <\sh> hmm...something seems wrong with the detection of raid controller on HP hw...
[14:26] <Riddell> mvo: synaptic question, should this work?
[14:26] <Riddell> gksudo "echo libxine1-ffmpeg i | synaptic --set-selections --non-interactive"
[14:26] <\sh> I have a p400i and a p800 (additional card)...p400i is the default boot controller regarding the bios...but our kernel just don't want to boot from /dev/cciss/c1d0 (which is somehow the p400i in our kernel)
[14:28] <ogra> tjaalton, dropping it would mean that we lose all GX1 geodes
[14:29] <ogra> that would be a pretty bad idea
[14:29] <ogra> (-geode only suports GX2 and LX)
[14:29] <ogra> *supports
[14:31] <tjaalton> ogra: right, so we won't drop it until geode supports those
[14:31] <ogra> ah
[14:32] <mvo> Riddell: yes, is it not working for you?
[14:33] <Riddell> mvo: no, just exits here
[14:33] <mvo> Riddell: and libxine1-ffmpeg is not already installed?
[14:33] <Riddell> mvo: nope
[14:39] <mvo> Riddell: let me check
[14:43] <mvo> Riddell: its possible that gksudo is playing tricks here, when I run this as regular root it works fine, I check further
[14:45] <mvo> Riddell: could you please try  gksudo "sh -c 'echo \"2vcard i\"|synaptic --non-interactive --set-selections'" ?
[14:45] <mvo> Riddell: out of curiosity, what do you need it for?
[14:47] <Riddell> mvo: that works
[14:48] <Riddell> mvo: it's for amarok's codec install script
[14:49] <mvo> cool
[15:21] <tjaalton> lool: btw, what's the use case for the change?
[15:22] <tjaalton> s/use case/motivation/
[15:23] <lool> tjaalton: See also above discussion with Keybuk: when we try to startx from an upstart job in ubuntu-mid images, we fail the "user is on console" permission check
[15:23] <tjaalton> lool: ah, ok
[15:23] <lool> tjaalton: This is because stdin/stdout/stderr point at /dev/console, not ttyN
[15:24] <lool> tjaalton: I don't quite know what the intent of the console check is in startx though; perhaps it's opening too much if we allow /dev/tty?
[15:35] <StevenK> pitti: Can you please bump the priority of linux-lpia so it builds before the backlog?
[15:36] <tkamppeter> pitti, I have answered all your stuff about CUPS today in the morning. Did you see it?
[15:36] <Hobbsee> StevenK: bumped.
[15:37] <StevenK> Hobbsee: Danke
[15:37] <Hobbsee> you're welcome
[15:54] <kwwii> pitti: Andreas and lots of others have suggested using a newer snapshot of the murrine engine which apparently fixes bugs
[15:54] <kwwii> pitti: the original snapshot I made was just a random day early in the cycle
[15:56] <pitti> tkamppeter: yep, saw it, thanks! the only missing thing is re-proposing the (recommended) patch upstream, other stuff was settled
[15:56] <pitti> StevenK: done
[15:58] <Hobbsee> pitti: i presume you've got a fixed version of buildd.py somewhere, that lets you rescore?
[15:58] <pitti> Hobbsee: I didn't touch it in weeks
[15:58] <pitti> it just works
[15:59]  * norsetto hugs doko
[15:59] <pitti> kwwii: sure, if you tested it and it works well
[15:59] <Hobbsee> pitti: strange - 'im not sure if it does, as i just manually rescored them.  And i bumped the prio's before via buildd.py, but nothing happened.
[15:59] <pitti> I'm off for a long phone call
[16:04] <tedg> Should debian/change log be chronological or sorted by version number?
[16:05] <Hobbsee> tedg: uh?...
[16:05] <Hobbsee> tedg: both.  but primarily version #.
[16:06] <tedg> Hobbsee: So if someone added a patch to an older version, but one wants to merge that patch in, where should that person's changelog entry go?
[16:06] <StevenK> tedg: One should ignore it, and add a new changelog entry
[16:06] <Hobbsee> what steve said.
[16:06] <StevenK> tedg: Also stating the work came from "x"
[16:07] <Hobbsee> tedg: the idea is that the only changelog entries there are teh ones where the package actually went into the archive.
[16:07] <Hobbsee> (which then makes the question void)
[16:08] <tedg> Hmm, but when I've merged stuff from Debian previously I've kept their changelog entires, should I not be doing that?
[16:08] <tedg> I've kept them, but put them in bellow a top one which explains the complete change.
[16:09] <Hobbsee> er, excluding debian stuff, then.
[16:09] <Hobbsee> or where archive = {debian, ubuntu} archive.
[16:13] <tedg> Hobbsee: Okay, thanks.
[16:15] <Hobbsee> tedg: y/w
[16:15] <StevenK> tedg: Sure, but that's merging stuff from Debian which exists in another archive. This is a patch from someone else, which hasn't been seen by either
[16:17] <tedg> Well, actually in this case the patch was pushed to the archive, but my changes haven't been.  So I think it's clear that I should include their entry, and then view mine as deltas against theirs as users (turns out there are some people who don't follow my PPA) would view it as a change.
[16:33] <Keybuk>  16:33:30 up 1 day, 19:20,  6 users,  load average: 58.62, 39.70, 19.22
[16:33] <Keybuk> I need a unicode "eep" character
[16:36] <vinu76jsr3> I have a jar file and I want to convert it to debian package(.deb) what are the steps
[16:39] <geser> vinu76jsr3: first find the source code for it
[16:39] <vinu76jsr3> I have the jar file of the app and I created it myself
[16:40] <vinu76jsr3> so I have .java source also
[16:41] <geser> vinu76jsr3: then read https://wiki.ubuntu.com/PackagingGuide/ and if you have questions please ask in #ubuntu-motu
[16:52] <tedg> Keybuk: No, we just need to wait for Intel to sponsor a little line in there "Upgrading to Intel's new 64 core processor will help" :)
[16:53] <Keybuk> tedg: heh
[16:53] <Keybuk> I suspect the real problem is that it's a UML
[16:53] <Keybuk> and the ultrasuperhypermegavisor isn't bothering to give the guest any time
[16:54] <soren> Keybuk: Linode?
[16:54] <geser> @archive admins: do we need to sync the last version from debian where the only reason for the upload was to get it moved from contrib to main before we can move it from multiverse to universe?
[16:54] <Keybuk> soren: Bytemark
[16:54] <soren> Ah.
[16:55] <soren> Those things look pricy.
[16:59] <cjwatson> geser: no
[17:00] <cjwatson> geser: it might confuse somebody a bit less down the line if we do, but it's not mandatory
[17:21]  * calc will be uploading OOo 3.0rc1 later today to ppa
[17:46] <kees> geser: does your experience of 262843 include NFS?
[17:49] <geser> kees: no, I don't have NFS here
[17:49] <kees> geser: okay, good -- that removes some variables from the issue.  :)
[17:53] <geser> kees: I've only seen this happen with 2.6.27-2.3. I currently using 2.6.27-1.2 again.
[17:55] <kees> geser: ah, interesting.
[18:28] <tkamppeter> pitti, about the (recommended) patch, I think it will not be possible to convince Mike to revert his step of filtering out (recommended).
[18:37] <pitti> tkamppeter: are other distros carrying it as well?
[18:39] <pitti> bye everyone, have a nice evening
[19:11]  * ogra pokes todays archive admin ... mighty slangasek 
[19:11] <slangasek> ?
[19:11] <ogra> slangasek, i'D like to close bug 261873 partially
[19:12] <ogra> err
[19:12] <ogra> sorry wrong bug
[19:12] <ogra> bug 263493 rather
[19:12] <ogra> three apps are sitting in NEW
[19:12] <ogra> (window-picker-applet, go-home-applet and maximus)
[19:13] <slangasek> well, a number of other things are sitting in new ahead of them. :)
[19:13] <ogra> all had a REVU review and i am the release manager for ubuntu-mobile to allow FFe's
[19:13] <ogra> (which i did at the bug)
[19:13] <slangasek> ok
[19:13] <ogra> oh, did you plan to do more today ?
[19:14]  * ogra wasnt expecting :)
[19:15] <un> i dunno if this is a good channel to ask, but my Makefile.am keeps generating a 'dist dist-all' rule when it should be 'dist-all' only... anybody got any ideas, or *channel
[19:17] <ogra> un, -> #ubuntu-motu might be a better one
[19:18] <un> ogra: thnks
[19:22] <slangasek> ogra: hmm?  it's still before noon my time
[19:22] <ogra> heh, yeah, i need to stop judging by daylight i guess ... dark here
[19:25] <un> ogra: i think they are busy... do you know of an autotools specific channel?
[19:25] <asac> cjwatson: does NM detect your driver name with 2.6.27 kernel properly now? or do you still see this "NULL(info.linux.driver)" thing in syslog?
[19:26] <ogra> un, not really
[19:26] <cjwatson> Sep  4 11:09:16 sarantium NetworkManager: <info>  eth1: driver is 'NULL(info.linux.driver)'.
[19:26] <cjwatson> asac: it seems to be *working*, but ...
[19:26] <un> ogra: thx anyway
[19:27] <cjwatson> (well, aside from it leaving both eth0 and eth1 up simultaneously)
[19:27] <asac> cjwatson: damn. so the driver still isnt fixed :(
[19:27] <asac> cjwatson: is that b43?
[19:27] <cjwatson> asac: I think this is with wl, FWIW
[19:27] <cjwatson> 0c:00.0 Network controller: Broadcom Corporation BCM94311MCG wlan mini-PCI (rev 01)
[19:27] <cjwatson>         Kernel modules: ssb, wl
[19:28] <cjwatson> b43 may well have been fixed, can't easily tell right now
[19:28] <un> cjwatson: i just installed b43 from the fwcutter and im wifi'ing right now...
[19:28] <asac> cjwatson: ok. thanks. do you know what will be the default in intrepid? (me confused about the broadcom mess)
[19:28] <cjwatson> un: sure, like I say it works
[19:29] <cjwatson> un: (I'm not looking for wireless help here; this is a continuation of an old exchange with asac)
[19:29] <cjwatson> asac: I can't swear to the exact state; I suspect it depends on the exact PCI ID
[19:29] <un> cjwatson: sry...
[19:31] <cjwatson> un: (the point of wl, BTW, is to get rid of the need for fwcutter)
[19:32] <un> cjwatson: schweet...
[19:38] <alex-weej> does anyone know what happened to the multi-arch stuff that was planned for debian? it was my understanding at the time (handful of years ago) that it would be the end of the need for things like an ia32libs amd64 package
[19:39] <lool> slangasek: When you have some time, I'd like to discuss elisa 0.5.x
[19:41] <johanbr> cjwatson, asac: Adam Williamson made an interesting point on the bcm43xx list: maybe it'd be possible to cut the firmware out of the wl driver, since that's redistributable and the firmware by itself isn't ?
[19:43] <cjwatson> I can't say I know any of the details myself
[19:43] <cjwatson> presumably whether that's worthwhile depends on whether the wl driver is pretty inside
[19:47] <mnemo> apparently, the old games "heretic" and "hexen" has been released under the GPL now --> http://sourceforge.net/forum/forum.php?forum_id=864305  would be nice to have them packaged in debian/ubuntu
[19:48] <ogra> mnemo, try #ubuntu-motu ... https://wiki.ubuntu.com/UbuntuDevelopment/NewPackages
[19:53] <un> anyone know of a decent autotools channel?
[19:55] <torkel> un: you already asked it about half an hour ago
[19:56] <un> torkel: fine...
[20:15] <slangasek> ogra, StevenK: the debian/copyright in go-home-applet is wrong, it says GPL v3 "or any later version" and the source only says v3
[20:16] <ogra> ouch
[20:16] <slangasek> ogra, StevenK: can I get a reupload with this fixed?
[20:16] <s0u][ight> hello is there somewhere i can find linux-image-2.6.26-5-generic
[20:16] <s0u][ight> because it is removed in the intrepid repos
[20:17] <s0u][ight> and 2.6.27-2-generic refuses to compile compat-wireless
[20:17] <s0u][ight> or is there someone who could help me with it
[20:17] <s0u][ight> http://pastebin.ca/1197397
[20:17] <geser> s0u][ight: LP has it still, you need to dig a little to find it there
[20:17] <s0u][ight> launchpad?
[20:17] <ogra> slangasek, is dropping "or any later version" ok for you for now ?
[20:18] <ogra> cause i know upstream is massively busy :)
[20:18] <slangasek> ogra: that's what needs fixed, yes
[20:20] <s0u][ight> someone who knows what the problem is with the error i get
[20:21] <geser> s0u][ight: my quick guess is that the kernel interface changed in the meantime
[20:22] <s0u][ight> any suggestion to fix the problem?
[20:23] <ogra> slangasek, ubuntu2 uploaded
[20:24] <slangasek> ogra: heh, why not a reupload as ubuntu1?
[20:24] <ogra> because i want to keep a record of the change :)
[20:24] <slangasek> ok
[20:25] <ogra> version numbers are so cheap :)
[20:25] <s0u][ight> i'm not familiar with launchpad can someone help me finding the image and headers for intrepid 2.6.26-5-
[20:25] <slangasek> ogra: for maximus, I see several source files with copyright holders that aren't listed in debian/copyright...
[20:25] <slangasek> ./src/eggaccelerators.c: * Copyright (C) 2002  Red Hat, Inc.; Copyright 1998, 2001 Tim Janik
[20:25] <ogra> sigh ... i really thought they were proper
[20:25] <slangasek> ./src/tomboykeybinder.c: * Copyright (C) 2008 Novell
[20:25] <ogra> ugh
[20:26] <slangasek> that's, er, roughly half the source code in the package :)
[20:26]  * ogra grabs source and adds names ... 
[20:28] <ogra> slangasek, err
[20:28] <slangasek> ?
[20:28] <ogra> i'm not sure we look at the same debian/copyright
[20:28] <s0u][ight> found something i think
[20:28] <ogra> src/eggaccelerator.{c,h} are Copyright Red Hat, authored by Havoc
[20:28] <ogra> Pennington and Tim Janik and are under the terms of the LGPL 2 or later.
[20:28] <ogra> src/tomboykeybinder.{c,h} are Copyright Novell, and are also under the terms
[20:28] <ogra> of the LGPL 2 or later.
[20:28] <ogra> thats in debian/copyrght here
[20:29] <cjwatson> s0u][ight: https://launchpad.net/ubuntu/+source/linux should be a good place to start
[20:29] <slangasek> ogra: checking again
[20:29] <s0u][ight> cjwatson, i need binaries :)
[20:29] <slangasek> ogra: whoops, you're right; sorry
[20:29] <ogra> :)
[20:29] <s0u][ight> but found it never mind
[20:29] <cjwatson> s0u][ight: yes, you can get to it from there. the bit that may not be obvious is that at some point (once you've clicked through to the version you want), you need to select "build for i386" or some such
[20:29] <cjwatson> s0u][ight: ok
[20:30] <slangasek> ogra: I don't find it very clear to list the licensing blurbs interspersed between the copyright statements like that :/
[20:30] <s0u][ight> but i have allready installed 2.6.27 will these 2 conflict
[20:30] <s0u][ight> meaning with gcc or so?
[20:30] <cjwatson> they shouldn't
[20:30] <cjwatson> you can coinstall images and headers of different versions
[20:31] <cjwatson> in the specific case of the kernel, anyway; that's not true in general
[20:31] <s0u][ight> do these kernel images and headers need any other dependencies
[20:31] <ogra> slangasek, yeah, agreed, i'll fix that with the next upload if thats enough for you
[20:31] <s0u][ight> meaning can i install them just like dpkg -i
[20:32] <slangasek> ogra: I've accepted it, if you agree that it should be fixed then feel free to do so at any point :)
[20:32] <ogra> i surely will, its confusing :)
[20:33] <cjwatson> s0u][ight: if you already have another kernel image and set of headers installed, their dependencies should be sufficient; the dependencies don't change often
[20:33] <cjwatson> s0u][ight: you may need to grab the corresponding linux-restricted-modules as well if you rely on those
[20:34] <s0u][ight> cjwatson, yes i was going to download that .deb package too
[20:34] <s0u][ight> because i installed that one of intrepid's latest too
[20:34] <s0u][ight> :)
[20:37] <slangasek> ogra: ok, all three accepted
[20:37] <ogra> gracias :)
[20:37] <s0u][ight> cjwatson, is it normal that i only find x86/86_64 version of the kernel headers?
[20:37]  * ogra sends a hug in slangasek's direction
[20:37] <s0u][ight> will it cause problems?
[20:38] <cjwatson> s0u][ight: you're looking on the wrong architecture then, I presume. Yes, it will cause problems
[20:38] <s0u][ight> :s
[20:38] <slangasek> ogra: hope that can make it through customs unmolested :)
[20:39] <ogra> heh
[20:39] <s0u][ight> can you help me with finding the i386 version
[20:39] <cjwatson> s0u][ight: start at https://launchpad.net/ubuntu/+source/linux/2.6.26-5.17/+build/693768
[20:40] <cjwatson> s0u][ight: also https://launchpad.net/ubuntu/+source/linux-restricted-modules/2.6.26-5.12/+build/690347
[20:40] <s0u][ight> cjwatson, no binaries?
[20:41] <cjwatson> they're there
[20:41] <cjwatson> look in the "resulting binaries" column. Yes, you have to follow a bunch of links I'm afraid
[20:41] <cjwatson> behind those links, there's a "Downloadable files" section
[20:42] <jpds> Can somewhere remind me where the -dbg builds are?
[20:43] <s0u][ight> only the headers remained to download :)
[20:45] <s0u][ight> cjwatson, installing atm :)
[20:46] <cjwatson> jpds: ddebs.ubuntu.com
[20:47] <jpds> cjwatson: Thank you very much.
[20:47] <s0u][ight> cjwatson, while installing the headers i get dependency is not satisfiable
[20:48] <cjwatson> ok, sorry my prediction was wrong, but you'll need to sort that out on your own system; #ubuntu may be able to offer help
[20:49] <s0u][ight> but what is wrong?
[20:49] <s0u][ight> anyway this sucks and i need to go
[20:50] <s0u][ight> so anyway laters
[20:50] <cjwatson> the problem you're having with 2.6.27-2 is likely to be best fixed by updating compat-wireless from somewhere, or bugging the ath5k maintainer if there's no update
[20:50] <cjwatson> rather than by reverting
[20:50] <Nilbus> I'm the president of NCSU LUG, and we're looking to host linux installfest right after the 8.10 release.  Any idea how early or late in the month that is likely to be released?
[20:50] <cjwatson> Nilbus: http://wiki.ubuntu.com/IntrepidReleaseSchedule
[20:50] <s0u][ight> cjwatson, it is the latest compat-wireless
[20:51] <Nilbus> cjwatson, thank you.
[20:51] <Nilbus> Oct 30
[20:51] <Nilbus> so late :P
[20:51] <jpds> Nilbus: All good things take time.
[20:51] <Nilbus> :)
[20:51] <Nilbus> I am excited anyway
[22:01] <lool> Keybuk: Hmm I finished investigating the other way we were starting the MID desktop (the openvt thing), and using openvt's -e fixed many issues, as you guessed -w was causing forks, but I face a stupid problem:
[22:02] <lool> Keybuk: the xorg vt is switched to near the end of the boot, I see Xorg starting up, and then I'm moved back to one of the other ttys, presumably because they startup as well
[22:03] <lool> Keybuk: Nothing particular in syslog, I guess this is just racy; I guess the only option is to explicitely trigger an event after the other ttys are all loaded if that's what I care to keep, to then trigger the xorg session job?
[22:15] <android6011> how is support for ar5007eg wireless cards coming in intrepid?
[22:50] <Haegin> suggestion for the next possible version of ubuntu:
[22:50] <NCommander> Haegin, Jumpy Jackrabbits
[22:50] <Haegin> when going into recovery mode, don't mount anything other than /boot and / and don't check discs
[22:51] <NCommander> oh, features ;-)
[22:51] <NCommander> Not names
[22:51] <Haegin> no, a feature
[22:52] <Haegin> thought i would mention it while i wait for ubuntu to finish failing to check my 200GB partition I am currently trying to get to root mode to check
[22:52] <Haegin> just a good thing it isn't my 500GB drive else I might be here all night
[22:52] <NCommander> Haegin, you can Ctrl-C the disk check ...
[22:52] <Haegin> nope
[22:53] <NCommander> WOrked fine for me the other night
[22:53] <Haegin> hangs for a moment if i hold the button down but keeps on trucking
[22:53] <slangasek> Haegin: why should /boot and / be treated differently than the others?  If there's a fs recovery issue, it could be on either of those filesystems as well
[22:53] <Haegin> ill try the othre 2 keyboards that are pulgged in
[22:53] <Haegin> slangasek: because you need them to get to the root terminal to fix problemn
[22:53] <slangasek> you certainly don't need /boot for that
[22:54] <slangasek> and there are various rescue activities one can do without first mounting / ...
[22:54] <Haegin> you need boot to boot the system though which is necessary to get to mounting /
[22:54] <Haegin> slangasek: i don't care if they are not checked
[22:54] <slangasek> no, you never need to mount /boot as part of the boot.
[22:55] <Haegin> but /boot and / shouldn't take long anyway to check as they should never be too big
[22:55] <Haegin> whereas my media drives take forever
[22:55] <slangasek> well, I think that's an arbitrary line between /boot and $other_filesystems
[22:55] <Haegin> and are certainly not needed for me to get to the root shell
[22:55] <Haegin> slangasek: fine, don't check boot
[22:56] <Haegin> just don't check $other_filesystems either, it is pointless as far as i can see
[22:57] <Haegin> spending 30minutes waiting for something to fail is annoying to say the least
[22:58] <slangasek> Haegin: I think the right place where this would need to be changed is in sysvinit; perhaps you could file a bug report?
[22:59] <Haegin> ok, will do, thanks
[23:04] <android6011> so noone know anything about ar5007eg atheros wireless support?
[23:05] <slangasek> android6011: no, at any given moment #ubuntu-devel is not likely to be the right place to ask about support for a particular piece of hardware; you could try #ubuntu-kernel, or else you might want to file a bug report against the kernel (or if one is already filed, subscribe to it)
[23:05] <android6011> ok thanks
[23:06] <Haegin> android6011: also try #madwifi for that
[23:07] <android6011> Haegin: I know there is a working driver, I am just looking to see if it is in interpid at all
[23:07] <Haegin> android6011: ah, compile it in if it isn't
[23:08] <android6011> ya i know, i have in several disks, im also just wanting to know for live cd use
[23:11] <calc> cool! suspend/resume works on my laptop finally on amd64 arch
[23:11] <calc> just booted up intrepid alpha5, i think i will upgrade to it since i can run amd64 now, whee! :)
[23:14]  * calc thinks the logout window is a bit of a downgrade from the old one
[23:14] <calc> all wordy and stuff
[23:14] <wgrant> The italics and bad icons are particularly odd.
[23:15] <mathiaz> slangasek: jdstrand told me that you've granted a FFexception for landscape-client.
[23:15] <slangasek> mathiaz: yes
[23:16] <mathiaz> slangasek: is there a bug number somewhere ?
[23:16] <slangasek> no, it was verbal
[23:16] <slangasek> is that still not uploaded?
[23:16] <mathiaz> slangasek: ok - I'm about to upload the package
[23:16] <slangasek> ok, yes please :)
[23:17] <mathiaz> slangasek: ok. thanks for confirming this.
[23:28] <slangasek> lool: do we still need to talk about elisa 0.5, if I just approved the FFe? :)
[23:29] <Laney> Are we getting the Hardy logout window back?
[23:31] <lool> slangasek: haha well if you'd approve it we'd both skip discussing it :)
[23:31] <slangasek> lool: ok :)
[23:31]  * lool hopes the beer / FFEs exchange rate isn't too bad these days
[23:32] <slangasek> it gets better the more beers I have, right?
[23:34] <lool> slangasek: For you, yeah
[23:34] <slangasek> heh
[23:34] <slangasek> I was thinking supply and demand :)
[23:39] <lool> seb128: Do you mind if I defer testing and pushing of pango1.0 to tomorrow?  packaging committed, but I'm a bit tried TBH
[23:39] <seb128> lool: not at all, I'll go to bed soon too, there is still around 18 tarballs to update tomorrow + the new that will be rolled later
[23:48] <lool> slangasek: thanks
[23:48]  * lool waves 'night
[23:48]  * slangasek waves
[23:49] <seb128> 'night lool