[00:02] <phil_ps1> general question regarding libraries....the answer will save me time...
[00:03] <phil_ps1> is it possible to have a program and its plugin both use the same instance of a library?
[00:03] <phil_ps1> there is a problem with globals...
[00:06] <maxb> provided it's a dynamic library (.so) it should work fine, IIUC
[00:08] <lifeless> phil_ps1: its normal
[00:08] <lifeless> phil_ps1: its a problem for a progrm and plugin to use different instances
[00:09] <phil_ps1> I don't understand how to make them the same instances...
[00:09] <phil_ps1> *how to make them use the same instances...
[00:09] <lifeless> they will by default
[00:10] <phil_ps1> okay, maybe this is not the problem.  I just read it was...have to verify it
[00:10] <lifeless> you have to go to some effort [or some special edge cases] to avoid it
[00:10] <phil_ps1> read it on a bug report....https://bugs.launchpad.net/ubuntu/+source/pidgin-otr/+bug/248684
[00:10] <lifeless> packaging is potentiall one such edge case :P
[00:11] <phil_ps1> asked here because people would know about libraries...sorry if its the wrong topic...
[00:11] <lifeless> phil_ps1: https://bugs.edge.launchpad.net/ubuntu/+source/pidgin-otr/+bug/248684/comments/7
[00:12] <lifeless> phil_ps1: not libraries in general, one specific library, apparently.
[00:12] <phil_ps1> yeah that is what I read...trying to find a fix...without exhaustively removing globals
[00:13] <phil_ps1> okay, I will read more about libgcrypt...thanks lifeless
[00:16] <lifeless> phil_ps1: so, its nothing to do with libraries
[00:16] <Skiess1> graphics on my Lifebook C1020 default to vesa, which I think is wrong...
[00:16] <lifeless> phil_ps1: imagine you have two different uses for the gcrypt functions in one program, - two unrelated uses.
[00:17] <phil_ps1> okay
[00:17] <lifeless> phil_ps1: as long as that works, without the programing needing its own globals, it will work fine if the gcrypt stuff is in alibrary; if not it won't
[00:17] <lifeless> [IOW, globals are bad, get rid of them]
[00:17] <phil_ps1> yeah, pidgin dies when a whole bunch of threads are spawned...
[00:17] <phil_ps1> so there is a shared state
[00:18] <phil_ps1> yes, I agree, globals are bad
[00:18] <phil_ps1> (what does IOW mean, I am new. :)
[00:19] <StevenK> In Other Words
[00:19] <phil_ps1> I should make a program that first finds globals...would help in my parallel computing research...
[00:19] <phil_ps1> thanks StevenK
[00:19] <phil_ps1> oh, wait I have one....
[00:19] <phil_ps1> by my professor...
[00:20] <phil_ps1> for grading student's assignments
[00:20] <phil_ps1> we enforce no globals, no public data, cyclomatic complexity of function < 10, line count of function < 50 lines
[00:23] <phil_ps1> maybe things in here will fix my problem...http://olympus.het.brown.edu/cgi-bin/dwww?type=file&location=/usr/share/doc/libgcrypt11-doc/html/gcrypt_2.html#SEC9
[00:24] <phil_ps1> also my ibm desktop ubuntu installation doesn't work...
[00:24] <phil_ps1> I get as far as a login screen and then just a black screen
[00:24] <phil_ps1> is this because no video driver?
[00:25] <slangasek> Tonio___: knemo seems to have the same problem, no FFe for a new package
[00:25] <slangasek> (and not even a needs-packaging bug for this one)
[00:25] <lamont> why is my jaunty debootstrap pulling in an MTA?
[00:25] <lamont> admittedly, the script is also installing a boatloadd of build-deps
[00:25] <Tonio___> slangasek: yeah, I discussed this with Riddell... it was in the repos as a KDE3 app but was removed in the KDE4 transition...
[00:25] <Tonio___> slangasek: shouldn't be considered a new app for him, as well as kblogger
[00:25] <slangasek> Riddell: ^^ is knemo ok to re-add to the archive (FFe)?
[00:26] <slangasek> lamont: which MTA?
[00:26] <Tonio_> slangasek: I know a bug would have been nice, but I expected him to take care of that sooner, hehe :)
[00:26] <slangasek> lamont: oh, you're running a script - SEP :-P
[00:27] <slangasek> Tonio_: ok, I can just leave those in the queue for Riddell to review ;)
[00:27] <Tonio_> sladen: yup, that should concern kblogger and knemo, and skrooge is waiting for your or his approval...
[00:28] <lamont> slangasek: halley:~lamont/make-chroot.sh
[00:29] <Riddell> slangasek: yeah I'll get to them tomorrow
[00:30] <slangasek> lamont: so maybe the 'ssmtp' listed as a build-dep is the clue? :)
[00:30] <slangasek> lamont: also, did you mean to install git-core instead of git? :)
[00:31] <lamont> heh
[00:31] <lamont> dunno
[00:31] <slangasek> oh, you're grabbing the build-deps /of/ the packages listed in builddep... hmm
[00:31] <lamont> slangasek: it'll have git-core and a few other things (kernel builddeps) before I'm done with it
[00:32] <slangasek> anyway, smartmontools Recommends: mailx | mailutils, mailx Depends: m-t-a
[00:32] <lamont> ah ha
[00:32] <Tonio_> Riddell: thanks :)
[00:32] <lamont> it was more one of "wtf??" without otherwise looking at it
[01:37] <mrooney> Hmm, anyone have any input on bug 336992, is that expected?
[02:07] <greg-g> pitti: what is the likelihood of getting an update of apport for hardy/intrepid to include the apport-collect feature? as it is a new feature I don't believe it qualifies for a SRU.
[02:18] <mrooney> greg-g: that could be pretty awesome
[02:19] <greg-g> pitti: after testing it, I see it requires a new dependency (python-launchpadlib) so that probably decreases the chances even more.
[02:19] <greg-g> mrooney: yeah, it would be great
[02:24] <calc> doko: are you in charge of libxalan2-java? :)
[02:56] <roy_hobbs> Hey, if I'm commenting on a bug in launchpad, how do I reference a bug properly so that it shows up as a link to that bug?
[02:57] <ScottK> Bug #nnnnnn is enough
[02:57] <roy_hobbs> thanks
[02:57] <ScottK> YW
[03:35] <leftyfb> where can I go to find the changes in the latest kernel/headers/restricted modules ?
[03:48] <ebroder> I know this is a little off-topic, but does anyone know of a package that will list the files that dpkg's database doesn't know about?
[03:50] <TheMuso> ebroder: apt-file
[03:51] <LaserJock> TheMuso: will that list files that dpkg doesn't know about?
[03:51] <ebroder> No, no - I'm trying to figure out where all of my data is so I know what to backup on this machine. I want to know the files that are currently on my system that dpkg didn't put there
[03:51] <TheMuso> LaserJock: it will list files from packages that dpkg doesn't yet know about
[03:51] <TheMuso> ebroder: ah ok
[03:52] <TheMuso> well you could script something.
[03:52] <TheMuso> get a list f all files on your system, dump all package file lists of isntalled packages, and compare.
[03:52] <ebroder> Yeah, sure
[03:52] <ebroder> That was what I was going to do if someone hadn't done it already :)
[03:52] <LaserJock> I suspect that'll be very unhelpful though
[03:53] <leftyfb> Anyone know where can I go to find the changes in the latest kernel/headers/restricted modules ?
[03:53] <LaserJock> maybe not "very", but there's a lot of stuff there that are created postinst, for instance
[03:53] <TheMuso> LaserJock: good point
[03:53] <ebroder> LaserJack: Maybe. I'm willing to see what it comes up with. It might be filterable by-hand
[03:53] <LaserJock> and you've got things like /var
[03:54] <ebroder> Hmm...yeah, but a lot of the files I want this script to track down are in /var. Maybe I can come up with a relatively short blacklist
[03:54] <LaserJock> anyway, not saying you shouldn't do it, but you're like to get thousands of files and going through by hand might be a bit tedious
[03:54] <LaserJock> *likely
[03:58] <foxbuntu> leftyfb, look here: http://packages.debian.org/search?keywords=kernel&searchon=names&suite=stable&section=all
[03:59] <leftyfb> foxbuntu: how does that help me?
[03:59] <leftyfb> that's not ubuntu or the latest kernel
[04:00] <foxbuntu> leftyfb, the Ubuntu kernel comes from upstream Debian
[04:00] <leftyfb> I didn't think every update came from upstream. There is a kernel dev team at ubuntu
[04:00] <LaserJock> leftyfb: are you wanting changelog or patches?
[04:01] <foxbuntu> leftyfb, they submit upstream
[04:01] <leftyfb> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/322879
[04:01] <LaserJock> foxbuntu: not everything comes from Debian
[04:01] <dtchen_> leftyfb: http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-jaunty{,-lrm}.git;a=summary
[04:01] <leftyfb> i'm looking to see if that was fixed in the latest update that was pushed yesterday
[04:01] <foxbuntu> LaserJock, not saying it does
[04:01] <dtchen_> leftyfb: replace jaunty with the intended Ubuntu release
[04:01] <leftyfb> it seems to be working, but I'd like to confirm it was fixed and then submit that that bug be closed
[04:02] <leftyfb> dtchen_: 403 Forbidden - No such project
[04:02] <dtchen_> leftyfb: that's shorthand for http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-jaunty.git;a=summary and http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-jaunty-lrm.git;a=summary
[04:04] <ebroder> LaserJack: Apparently `diff -u <(sort -u /var/lib/dpkg/info/*.list) <(find / -xdev)` runs pretty damn fast :)
[04:06] <leftyfb> dtchen_: thanks ... might have found what I was looking for
[04:06] <leftyfb> do you think "  * USB: gadget: cdc-acm deadlock fix" is what fixed the bug i posted previously?
[04:09] <ScottK> foxbuntu: The kernel is one place we explicitly do not take from Debian.  Generally we are on a newer version than Debian and the kernel team works directly from upstream kernel sources.
[04:10] <foxbuntu> ScottK, ah, well thanks for clearing that up for me
[04:10] <TheMuso> However the way the kernels are built is loosely derived from Debian.
[04:10] <ScottK> True.
[04:10] <ScottK> So if your interested in kernel packaging methods, Debian is a good place to look.
[06:34] <Ademan> does anyone know how I could run a process after a given amount of idle time? (as root) is that something i could do via upstart?
[06:51] <jdong_> haha what's "idle time" defined as?
[07:00] <Ademan> jdong_: user idle time I guess?  based on mouse/keyboard use.
[07:00] <jdong_> I don't think at this time that's an upstart answerable question
[07:01] <jdong_> I guess you can have a proxy in each user's X session that reports whether it's idle
[07:02] <Ademan> jdong_: :-/  any idea how gnome-screensaver does it?  I'm not sure I want to depend on the same mechanism, but if that's the best i've got i'm interested
[07:02] <bryce> tjaalton_: hmm, on fdo #19574 it is said that our patch 156 should be upstream, however the change doesn't appear to be present in our xserver git tree
[07:02] <Ademan> i suppose xscreensaver probably uses the same method, whatever it is,
[07:02] <bryce> tjaalton_: this is our bug 311254 btw
[07:03] <jdong_> Ademan: yeah I would guess it's a *-screensaver API call on the GNOME side
[07:03] <jdong_> Ademan: also look at how gnome-power-manager grabs idle time for DPMS blanking
[07:03] <jdong_> because that also works on the KDE side
[07:04] <Ademan> thanks jdong i'll poke around
[07:04] <jdong_> which leads me to believe there's some DBUS-ish call for it
[07:04] <jdong_> or other freedesktop.org tpye call
[07:04] <Ademan> hrm, i didn't think kde 3.x used dbus at all... either way... freedesktop may have a spec for that, thanks
[07:33] <pitti> Good morning
[07:33] <ion_> Ditto
[07:33] <bluefox_> http://sourceware.org/ml/binutils/2009-03/msg00032.html  Relevant to anyone who likes playing with the toolchain
[07:33] <pitti> calc: ah, thanks for the heads-up
[07:34] <bluefox_> and also because I'm crazy and need attention so I can fill an information gap (i.e. why the hell does/doesn't this work and why hasn't it been done this way if it actually works as I think)
[07:34] <pitti> greg-g: apport-collect> indeed; you can get it from http://people.ubuntu.com/~pitti/scripts/apport-collect and ask people to run it; it will point out that you need to install python-launchpadlib
[07:34] <a|wen> cprov: can see you are a soyuz contact, i'm sorry for disturbing you this unorthodox way, but we are a little in a hurry, kde4.2.1 is due out today and we've reach the limit in the ppa for release packaging -> https://answers.launchpad.net/soyuz/+question/62925
[07:36] <Hobbsee> morning pitti
[07:37] <Mithrand1r> yo, Hobbsee
[07:37]  * Hobbsee stomps on Mithrand1r's feet
[07:37] <Hobbsee> hello, imposter!
[07:37]  * ion_ returns Mithrandir’s i, thanks for the loan.
[07:38] <Mithrandir> 08:37 -NickServ(NickServ@services.)- 31 failed logins since last login.
[07:38] <Mithrandir> hmm
[07:38] <StevenK> 31 imposters?
[07:38] <Mithrandir> or just one who's trying a fair bit.
[07:39] <Hobbsee> unless it was yours :P
[07:40] <Mithrandir> last time I checked, I did not irc off a host in Germany.
[07:41] <StevenK> Perhaps you need to check again
[07:41] <Hobbsee> blame pitti.
[07:41] <lifeless> .com?
[07:41] <Hobbsee> it must be pitti's fault.
[07:44] <pitti> sheesh!
[07:53] <StevenK> pitti: architecture-mismatches.txt looks tasty. I'm happy to sort it out, but should I be demoting or promoting?
[07:55] <lifeless> ugh, I'm lost where on cdimage.ubuntu.com/releases/intrepid/release is a plain ol 32-bit live CD
[07:55] <StevenK> lifeless: It's on releases.u.c
[07:55] <StevenK> http://releases.ubuntu.com/intrepid/
[07:55] <lifeless> *thats* not confusing at all. No really.
[07:58] <lifeless> (thanks btw)
[07:58] <lifeless> I could rant more if you like
[08:12] <lifeless> if hal loses the plot
[08:12] <lifeless> how do I get it to release the .hal-mtab lock and start over
[08:46] <pitti> StevenK: promote; it's recommended by libgpod4
[08:47] <pitti> StevenK: that is, gpod-common; python-gpod doesn't have main rdepends, so that should be demoted
[08:47] <StevenK> pitti: Okay, gpod-common gets a promote, and python-gpod gets demoted. I'll sort it out.
[08:47] <pitti> StevenK: great, thanks
[09:01] <seb128> pitti, StevenK: if somebody of you does some NEW could you give a quick review to nautilus-sendto-universe and evolution-mapi? I did work with the contributors on those so would be nice to have somebody else checking too
[09:30] <lool> mvo: You might recall I had lost my keybindings in compiz after an upgrade?  this was on my desktop and it hit my laptop yesterday (hadn't updated it for a while)
[09:41] <seb128> lool: is the gnome compat option enabled?
[09:54] <lool> seb128: I can't check on the laptop right now, but it was enabled on my desktop
[09:55] <mvo_> lool: I suspect the gnome compat module, I'm not 100% sure what the best way to fix it is, but I have it on my radar
[10:00] <lool> seb128, mvo_: Was disabled indeed
[10:00] <lool> mvo_: Ok if you know about it then I'm fine
[10:40] <mok01> Keybuk: ping
[10:40] <Keybuk> mok01: hello
[10:40] <mok01> Keybuk: hi
[10:40] <mok01> Keybuk: have you seen I've proposed a branch for merge with m-o-m
[10:40] <mok01> ?
[10:41] <Keybuk> no
[10:41] <mok01> Keybuk:  https://code.edge.launchpad.net/~ubuntu-core-dev/merge-o-matic/trunk/+merges
[10:41] <mok01> Keybuk: it's a couple of very simple things
[10:43] <Keybuk> could you e-mail me, and I'll take a look at some point
[10:43] <mok01> Keybuk: sure
[10:43] <Keybuk> someone else is working on a redesign of MoM's pages (RainCT), you might want to co-ordinate with him
[10:43] <mok01> Keybuk: it's rainct
[10:44] <mok01> Keybuk: will do, ok! Thanks!
[11:07] <Keybuk> pitti: gnargh
[11:07] <Keybuk> I have to update all my slides
[11:07] <Keybuk> DeviceKit is no more
[11:07] <pitti> Keybuk: huh?
[11:08] <TheMuso> wooa if thats true
[11:08] <pitti> Keybuk: 003 was just released yesterday
[11:08] <pitti> http://hal.freedesktop.org/releases/
[11:08] <TheMuso> as in my goodness
[11:08] <pitti> Keybuk: is it DavidKit now?
[11:08] <Keybuk> did you read the release notes? :)
[11:08] <pitti> Keybuk: no
[11:08] <pitti> what, back to hal?
[11:08] <Keybuk> ah, read them ;)
[11:08] <pitti> Keybuk: url?
[11:08] <Keybuk> no
[11:09] <Keybuk> basically the current DK will become simply the D-Bus API to udev
[11:09] <Keybuk> and the D-Bus name will be just org.kernel.udev
[11:09] <Keybuk> you'll still have DeviceKit-power and stuff
[11:10] <pitti> aah
[11:10] <pitti> Keybuk: I didn't see release notes on http://cgit.freedesktop.org/DeviceKit/DeviceKit/tree/
[11:10] <TheMuso> are there still plans for device kit sound, as that seems pointless now, at least to me
[11:10] <Keybuk> TheMuso: pointless how?
[11:10] <pitti> Keybuk: nice if it just gets integrated into udev
[11:11] <Keybuk> http://lists.freedesktop.org/archives/devkit-devel/2009-March/000123.html
[11:11] <TheMuso> Keybuk: well most sound related stuff goes through alsa-lib
[11:11] <TheMuso> if not all of it
[11:12] <Keybuk> I didn't know there were plans for a DK-sound
[11:12] <Keybuk> since HAL doesn't really have any kind of sound API right now
[11:12] <TheMuso> Keybuk: I thought there were, but I don't know where i heard that
[11:27] <lifeless> is there an offline bug reader for lp ?
[11:38] <pitti> email?
[11:41] <Keybuk> random Q of the day
[11:41] <lifeless> pitti: bah
[11:41] <Keybuk> does anyone have a machine that doesn't have ACPI anymore?
[11:41] <lifeless> pitti: that doesn't go back in time
[11:42] <lifeless> Keybuk: is that new or old? I have a pentium that I still can't boot a current ubuntu kernel on ...
[11:42] <Keybuk> lifeless: when was the last time you could boot it?
[11:42] <lifeless> Keybuk: couple of releases back, its my firewall :P
[11:42] <Keybuk> did it work on hardy?
[11:43] <geser> lifeless: try leonov, iirc it has some caching so you can use it offline
[11:43] <lifeless> Keybuk: don't think so, I thik thats where I started complaining to ben :P
[11:45] <lifeless> Keybuk: anyhow, if you want before-acpi, that may qualifyt
[11:46] <Keybuk> I'm asking because we don't have any bugs that I can see that non-ACPI machines aren't working anymore
[11:46] <Keybuk> and we think they've been broken for a couple of releases now
[11:46] <Keybuk> and since nobody's complained
[11:46] <Keybuk> and we hadn't actually noticed they were broken
[11:46] <apw> lifeless, i have an old clunker which does work even though acpi says "noooooo"
[11:46] <Keybuk> that maybe we should just note that we don't support them anymore :p
[11:46] <lifeless> Keybuk: how can I tell its non-acpi ?
[11:46] <apw> lifeless, what is the symptoms?
[11:47] <apw> if you can't boot it it is hard
[11:47] <lifeless> apw: my one, is hard-lock on boot
[11:47] <apw> last thing it says?
[11:47] <lifeless> apw: no monitor :P
[11:47] <cjwatson> I don't understand this "nobody's complained" mentality
[11:47] <apw> heh
[11:47] <lifeless> apw: and I last tried about 9 months back
[11:47] <cjwatson> doesn't it mean "I haven't seen any complaints"?
[11:47] <lifeless> apw: because its such a high hurdle to test
[11:47] <cjwatson> unless you read all bug reports and all forums posts :-)
[11:48] <lifeless> best way to tell if a machine (thats running) is acpi ?
[11:48] <apw> cjwatson, yeah it means the machine is blowing up and noone has brought it to the attention of <someone who cares>
[11:48] <cjwatson> I suspect it may just be that developers are biased towards newer machines, and so there is a higher chance that people with older machines will report problems in the "wrong place"
[11:48] <cjwatson> I'm not sure that translates accurately into "nobody complained"
[11:48] <apw> cjwatson, i think that is very likely
[11:48] <lifeless> 2.6.15-23-386,
[11:48] <apw> we are demand dirven though as we have nothing to test on
[11:49] <lifeless> model name      : Pentium 75 - 200
[11:49] <apw> it took me half a day to get this machien with a floppy to even work
[11:49] <cjwatson> no, I understand that, I just dislike the "nobody managed to file bug reports, let's bin it" approach
[11:49] <lifeless> cjwatson: me too :P
[11:49] <lifeless> Keybuk: its running 8.04
[11:50] <apw> cjwatson, indeed, but if we lost something and didn't notice and need to maek a kernel change to fix it but cannot as we have none, its very hard to do anything about
[11:50] <lifeless> apw: do you know, how I can tell if this is acpi or not ?
[11:50] <apw> there are acpi_available and apm_available iirc
[11:50] <apw> which exit 0 if there is some of that
[11:51] <apw> apw@dm$ acpi_available ; echo $?
[11:51] <apw> 0
[11:51] <apw> apw@dm$ apm_available ; echo $?
[11:51] <apw> 1
[11:51] <lifeless> apw: neither command exists
[11:51] <apw> gurgle
[11:51] <lifeless> :)
[11:52] <Keybuk> [ -d /proc/acpi ]
[11:52] <Keybuk> :p
[11:52] <apw> cat /proc/apm
[11:52] <apw> ls -l /proc/acpi
[11:52] <lifeless> $ [ -d /proc/acpi ]
[11:52] <lifeless> robertc@lifelessgwy:~$ echo $?
[11:52] <lifeless> 1
[11:52] <apw> so no acpi
[11:52] <apw> apm ?
[11:52] <lifeless> cat /proc/apm
[11:52] <lifeless> cat: /proc/apm: No such file or directory
[11:52] <Keybuk> apw: apm only covers power, not device discovery/enablement
[11:53] <apw> right, but having apm tells us you don't have acpi
[11:53] <lifeless> Keybuk: so, I can't until next weekend, but then I can, get a newer kernel and see if its bootable and report back
[11:53] <lifeless> Keybuk: and if it boots answer any other queries while I upgrade from 8.04
[11:53] <apw> lifeless, sounds good to me
[11:53] <Keybuk> apw: not necessarily
[11:53] <Keybuk> I have a laptop that has both
[11:54] <apw> double gurble
[11:54]  * apw climbs back into his nice shiney acpi only world, la la la, can't hear you
[11:55] <lifeless> Keybuk: will that help you?
[11:56] <Keybuk> cjwatson: I'd claim the opposite
[11:56] <Keybuk> thost people who are trying to run Linux on older machines are more likely to be tech savvy and trying to keep the older machines running, so more likely to complain in the right place
[11:56] <Keybuk> (or at least complain somewhere audible)
[11:56] <Keybuk> lifeless: I'd be interested to see the results
[11:56] <lifeless> Keybuk:
[11:57] <lifeless> bah.
[11:57] <apw> Keybuk, a resonable conjecture
[11:57] <lifeless> ok, will fiddle around to get a newer kernel and a monitor and give it a spin
[11:57] <lifeless> if it doesn't work, I may bite the bullet and replace it, and shit it to you. Its about 1/8th of a cubic metre.
[11:58] <cjwatson> Keybuk: neither of our opinions is supported by data, I suppose :-)
[11:58] <Keybuk> lifeless: hey, I didn't say I was going to _fix_ it :p
[11:58] <apw> Keybuk, that reminds me, if you are shipping an empty modprobe.d how are we handling blacklisting
[11:58] <Keybuk> I'm somewhat concious that the amount of work needed to put code into the kernel to deal with the non-ACPI cases is so large and error-prone that it may simply not be worth it
[11:58] <cjwatson> I keep reading stuff at the moment about how people are more likely to be recycling old machines in the depths of a recession, rather than buying new ones
[11:59] <Keybuk> apw: they're probably going in /lib/modules/$(uname -r)/modules.conf
[11:59] <apw> so we will be cslurping them up basically
[11:59] <Keybuk> cjwatson: "old" in this case does mean "1999 and before though", no?
[11:59] <apw> yeah i was amazed to find there was a floppy on a machine that worked any more
[11:59] <apw> for osmeone to complain about it
[11:59] <cjwatson> I've learned never to make that kind of generalisation :-)
[12:00] <cjwatson> I was trying to get Ubuntu to work last night with a monitor that doesn't support DDC
[12:00] <Keybuk> heh
[12:00] <cjwatson> I'd say the monitor is at least 15 years old, at a guess
[12:00] <apw> Keybuk, so are you handling the integration with the kernel or does someone here need to start thinking about it?
[12:00] <Keybuk> "Writing X Mode lines for dummies"
[12:00] <Keybuk> cjwatson: I think that's the point though - we don't actually support those monitors either right now, do we?
[12:00] <TheMuso> cjwatson: Interesting you should say that, some cheap KVM switches out there don't support DDC either.
[12:00] <cjwatson> I gave up, but I'd rather argue that I shouldn't have to
[12:00] <cjwatson> because if I weren't an Ubuntu developer, I'd be installing some other operating system on it right now
[12:00] <Keybuk> apw: I'll handle it ;)
[12:01] <apw> Keybuk, ok cool.  /me scuttles off to his tunnels
[12:01] <Keybuk> cjwatson: I'd be intrigued to know whether the current version of any other operating system works either <g>
[12:01] <Keybuk> I'd wager lots of money that neither Vista nor Mac OS X would support that monitor
[12:01] <cjwatson> I could, for example, reinstall the Windows 2000 that was on there when I got it
[12:01] <Keybuk> Win 2000 is EOL
[12:01] <Keybuk> you could install warty on it
[12:01]  * apw wonders if hardy would work
[12:01] <cjwatson> so what? (from the point of view of somebody who isn't an OS person)
[12:01] <cjwatson> works > current
[12:02] <Keybuk> I guess I don't see "the current version doesn't work -> use an older one" as a problem
[12:02]  * sistpoty|work wonders wether qemu than does work OOTB with a daily, since iirc it doesn't support ddc either
[12:02] <apw> we probabally don't recommend it loudly enough
[12:02] <Keybuk> since that's generally the solution
[12:02] <cjwatson> the operating system that was already there will get a free pass in a lot of people's minds, whether it's old or not
[12:02] <apw> "if you have pre-2000 h/w" you might want to start with this version
[12:02] <lifeless> Keybuk: security fixes
[12:02] <cjwatson> some *other* old operating system will not get that same free pass
[12:02] <Keybuk> lifeless: Win 2000 doesn't have security fixes from MS anymore
[12:03] <lifeless> Keybuk: I don't use win2000, so thats irrelevant :)
[12:03] <Keybuk> cjwatson: and this is the end of the world?
[12:03] <cjwatson> Keybuk: oh FFS
[12:03] <cjwatson> "this is a bug, I'm trying to get you to acknowledge that" != "end of the world"
[12:03] <cjwatson> stop turning everything into the worst possible extreme
[12:03] <Keybuk> I'm not saying it's not a bug
[12:03] <Keybuk> I'm saying its a bug I'm inclined to Won't Fix
[12:03] <cjwatson> or even "we should fix this" != "end of the world"
[12:04]  * TheMuso has jaunty running on a dual celeron 466 box, and the board was from 1999. Works fine, appart from the broken mga driver for the matrox card in there last I checked. :)
[12:04] <apw> TheMuso, woh thats old!
[12:04] <apw> i should introduce it to my thinkpad 570e, they are the same age
[12:05] <cjwatson> sistpoty|work: qemu support some modeline that X tries by default; this monitor apparently doesn't
[12:05] <Keybuk> cjwatson: maybe that's where we're disagreeing here
[12:05] <TheMuso> apw: heh, its an abit BP6. I keep it around because it has ISA slots, which allows me to muck around with some ISA hardware speech synthesizers i have.
[12:05] <apw> cjwatson, the right thing to do is fedex the thing to bryce ...
[12:05] <Keybuk> cjwatson: I'm not disagreeing that things don't work (they clearly don't)
[12:05] <cjwatson> Keybuk: I have consistently been given direction that we are to support the long tail of hardware in Ubuntu
[12:05] <Keybuk> I'm claiming that the effort to fix those things is probably too large compared to the benefit
[12:05] <sistpoty|work> cjwatson: ah, makes sense
[12:06] <Keybuk> cjwatson: and at some point, the tail has to end
[12:06] <Keybuk> we can't support all hardware ever created
[12:06] <Keybuk> maybe we'd like to
[12:06] <Keybuk> but that's an awful lot of work
[12:06] <cjwatson> I acknowledge that; I think you perhaps overestimate how frequently people upgrade hardware, though
[12:06] <evand> I don't pretend to know what I'm talking about here, but just an idea, what if we only rip out support for non-ACPI machines in the desktop kernel.  That would allow people who really cared about getting Ubuntu running on their P2 to still do so through the server CD.
[12:06] <cjwatson> I think we're cutting off a bigger tail than you think
[12:06] <Keybuk> and you'd get into the strange situation that the exotic hardware you're supporting only exists in your labs, because you purchased all available models of that hardware to test it on ;)
[12:07] <cjwatson> evand: this is about the work required to reintroduce support dropped due to a bug
[12:07] <evand> oh, my mistake then
[12:07] <cjwatson> evand: it's not about the space required to keep support
[12:07] <apw> i would say peoples first experience with ubuntu is as often as not installed on their 'old' laptop after an upgrade
[12:07] <Keybuk> it's not necessarily "because of a bug"
[12:07] <cjwatson> Keybuk: that's a gross exaggeration, and unhelpful in this case
[12:07] <cjwatson> pre-ACPI hardware is not as rare as all that
[12:07] <Keybuk> it's not a "oh, look, a one line patch"
[12:07] <Keybuk> or a "this little patch broke non-ACPI machines"
[12:08] <cjwatson> "due to a bug"> OK, that was an excessive abbreviation
[12:08] <Keybuk> it's "the kernel really assumes ACPI for a lot of things now, and there's no equivalent non-ACPI code"
[12:08] <apw> cjwatson, i wonder if machines booted acpi=off count
[12:08] <Keybuk> (and there probably wasn't any non-ACPI code before - since the kernel didn't bother with such niceties in those days)
[12:08] <Keybuk> ie. we never had non-ACPI hotplug
[12:09] <apw> it cirtainly assumed synchronised userspace
[12:09] <apw> we did have userspace hotplug though
[12:09] <apw> and its our removal if that which broke things
[12:09] <Keybuk> we used to run isapnp and write config files, and then use those
[12:09] <cjwatson> so the appropriate way to do this would be to post somewhere very public saying "we've discovered that we don't appear to support pre-ACPI machines any more; do you care? if so, please write to us"
[12:09] <Keybuk> apw: nah, that was just how we _found_ this underlying problem
[12:10] <apw> that is hotplug in userspace
[12:10] <cjwatson> and assess the responses objectively
[12:10] <Keybuk> cjwatson: which was my suggestion
[12:10]  * TheMuso still has an ISApnp sound card, that actually still works.
[12:10] <Keybuk> TheMuso: it should work on an ACPI-machine
[12:10] <cjwatson> Keybuk: I didn't see that suggestion - where?
[12:10] <TheMuso> Keybuk: It does.
[12:10] <cjwatson> you said
[12:10] <cjwatson> 11:46 <Keybuk> that maybe we should just note that we don't support them anymore :p
[12:10] <cjwatson> which sounded like a release note "hi guys, unsupported, you lose" :-)
[12:10] <TheMuso> anyway, bed time for me.
[12:11] <Keybuk> cjwatson: somewhere, this conversation has crossed three channels and several bugs now ;)
[12:11] <cjwatson> heh
[12:11] <Keybuk> I started by asking lifeless ;P
[12:11] <Keybuk> and I did start here by asking <g>
[12:11] <Keybuk> (generally)
[12:11] <cjwatson> right, and several people said that they had machines with issues
[12:11] <cjwatson> didn't they?
[12:11] <Keybuk> just lifeless so far
[12:12] <cjwatson> and apw
[12:12]  * apw has a machine whcih is affected too for the record
[12:12] <apw> though i prefer not to admit its existance
[12:13] <apw> Keybuk, i wonder if some combination of my fixes are appropriate
[12:13] <Keybuk> whoo
[12:13] <apw> to generate pnp event IFF acpi is not working
[12:13] <Keybuk> I get a full-on kernel panic trying to boot with acpi=off
[12:13] <mneptok> james_w: meep.
[12:13] <james_w> mneptok: ahoy
[12:13] <apw> Keybuk, what from?
[12:13] <Keybuk> apw: the problem there is you have to then patch all the pnp modules to also support the other subsystem
[12:13] <Keybuk> apw: somewhere insire parport_pc_init
[12:14] <Keybuk> and pnp_register_driver
[12:14] <mneptok> james_w: are you responsible for kurts_self_image.deb? if so, you're doing a terrible job as package maintainer. allow me to send you a 14 page e-mail with details ....
[12:14] <StevenK> My firewall is too early for the cutoff too.
[12:14] <apw> Keybuk, well yes we'd need some new aliases
[12:14] <apw> but other than that probabally not
[12:14] <Keybuk> apw: dunno, am reading through the code of many of them
[12:15] <james_w> mneptok: oh, I thought we were using a different image of you now? mnempolo.deb?
[12:15]  * StevenK twitches
[12:15] <StevenK> james_w: I did *not* need a reminder of that.
[12:16] <mneptok> :D
[12:16] <mneptok> StevenK: install Kees' usplash ... you know you want to ....
[12:17] <StevenK> mneptok: I'd rather burn out my optic nerves
[12:17] <mneptok> like i said. install the PPA.
[12:18] <Mithrandir> a mneptok!
[12:18] <apw> Keybuk, ok at least one of my machines boots acpi=off
[12:19] <mneptok> Mithrandir! Mithrandir!
[12:19]  * mneptok feels like a juvenile hobbit about to see fireworks
[12:19] <apw> Keybuk, on the module aliases for isa those actually are already in place in a lot fo cases
[12:19] <apw> as i got some broken modules loaded as a result
[12:20] <Mithrandir> mneptok: how's the new job?
[12:20] <apw> when i started generating pnp:dPNP700 style ones
[12:23] <mneptok> Mithrandir: delightfully busy and stressful :)
[12:24] <Keybuk> apw: err, well, there's about 6 modules with them
[12:24] <Keybuk> and those modules don't look like they've been touched in years
[12:24] <Keybuk> so those aliases are probably only in there by accident <g>
[12:25] <Keybuk> hmm
[12:25] <Keybuk> interestingly there is a struct pnp_device_id
[12:25] <apw> yep, there is a full infrastructre to get them to modules.modaliases
[12:25] <apw> but nothing generates them right now, other than my patch of course
[12:25] <Keybuk> which is odd
[12:26] <Keybuk> look at parport_pc for an example
[12:26] <Keybuk> it only has the pnp_device_id DEVICE_TABLE
[12:26] <Keybuk> but it ends up with both acpi: and pnp: aliases
[12:26] <apw> the device is also listed in the acpi tables independantly
[12:26] <Keybuk> is it?
[12:27] <apw> for it to have an acpi thing i would say yes
[12:27] <Keybuk> I can't find _that_ code
[12:27] <apw> i think udev fakes the events
[12:28] <Keybuk> nope
[12:28] <apw> there are modalias files in /sys for somethings
[12:28] <apw> i thought udev had to scan there for things that appeared before it did
[12:28] <apw> and i had been assuming it did so using the modalias files in /sys
[12:29] <Keybuk> udev doesn't touch those
[12:29] <apw> how does it find old things, things that preceeded its first invokation
[12:30] <Keybuk> it just writes "add" to all the uevent files
[12:30] <Keybuk> which makes the kernel resend the netlink messages
[12:30] <apw> which is probabally why the kernel keeps them in modalias
[12:31] <Keybuk> that's mostly just for debugging
[12:34] <apw> Keybuk, if you have a machine with a floppy with acpi could you let me have your udev log
[12:35] <apw> want to see how it would interact should i introduce a modalias on the pnp events too
[12:35] <Keybuk> http://people.ubuntu.com/~scott/udev
[12:35] <Keybuk> you'd get two different MODALIAS strings from two different devices on two different subsystems
[12:35] <Keybuk> which would be bad
[12:35] <Keybuk> (both resolving to the same module)
[12:35] <apw> why would that be bad
[12:35] <apw> you would get two events anyhow
[12:35] <apw> one with each
[12:36] <Keybuk> the pnp devices aren't "under" the acpi ones
[12:36] <Keybuk> likewise the acpi ones aren't "under" the pnp ones
[12:37] <Keybuk> it'd be interesting to find out why the kernel did it this way in the first place
[12:37] <apw> actually you don't get the pnp events at all on yours
[12:37] <Keybuk> ooooh
[12:37] <Keybuk> I just had a thought
[12:37] <apw> the events in my log with the APW: on them i didn't add those events they were there
[12:37] <Keybuk> could we make the MODALIAS for the pnp thing only show up if pnpacpi isn't working?
[12:38] <apw> yeah we could indeed though i suspect you arn't getting them anyhow already
[12:38] <Keybuk> should be
[12:38] <Keybuk> I have /devices/pnp0 and stuff
[12:38] <apw> whats in your /proc/bus/pnp
[12:39] <Keybuk> ENOENT
[12:39] <Keybuk> quest scott% ls /sys/bus/pnp/devices
[12:39] <Keybuk> 00:00@  00:02@  00:04@  00:06@  00:08@  00:0a@
[12:39] <Keybuk> 00:01@  00:03@  00:05@  00:07@  00:09@  00:0b@
[12:39] <Keybuk> for example
[12:39] <Keybuk> you have
[12:39] <Keybuk> UEVENT[1236073926.075992] add      /devices/pnp0/00:11 (pnp)
[12:39] <Keybuk> UDEV_LOG=3
[12:39] <Keybuk> ACTION=add
[12:39] <Keybuk> DEVPATH=/devices/pnp0/00:11
[12:39] <Keybuk> SUBSYSTEM=pnp
[12:39] <Keybuk> MODALIAS=APW:dPNP0700
[12:39] <Keybuk> SEQNUM=979
[12:39] <apw> right ... i had those events even before i added APW: to them
[12:39] <apw> just without alias
[12:40] <Keybuk> I have them too
[12:40] <Keybuk> UEVENT[1235981705.266498] add      /devices/pnp0/00:09 (pnp)
[12:40] <Keybuk> ACTION=add
[12:40] <Keybuk> DEVPATH=/devices/pnp0/00:09
[12:40] <Keybuk> SUBSYSTEM=pnp
[12:40] <Keybuk> SEQNUM=2129
[12:40] <Keybuk> (that id file contains PNP0401)
[12:40] <apw> so i don't see why it would be an issue to have the pnp: style aliases on there
[12:40] <Keybuk> the trouble is, I also have
[12:40] <apw> (i missed them somehow)
[12:40] <Keybuk> UEVENT[1235981705.260729] add      /devices/LNXSYSTM:00/device:00/PNP0A08:00/PNP0401:00 (acpi)
[12:40] <Keybuk> ACTION=add
[12:40] <Keybuk> DEVPATH=/devices/LNXSYSTM:00/device:00/PNP0A08:00/PNP0401:00
[12:40] <Keybuk> SUBSYSTEM=acpi
[12:40] <Keybuk> MODALIAS=acpi:PNP0401:
[12:40] <Keybuk> SEQNUM=1967
[12:40] <apw> but thats not an issue
[12:40] <apw> loading the modules twice isn't an issue
[12:40] <Keybuk> the issue is that why does pnpacpi exist at all?
[12:41] <Keybuk> I'm trying to understand why the kernel doesn't already do it the way you describe
[12:41] <apw> we simply don't have the aliases on there as far as i can see
[12:41] <Keybuk> right, but when upstream fixed that problem
[12:41] <Keybuk> they did it completely differently
[12:41] <apw> and as you have found we have some destinations
[12:41] <Keybuk> it would have been far simpler to do your patch
[12:41] <apw> well if our userspace was anything to go by
[12:41] <Keybuk> but instead they wrote this entire new pnpacpi subsystem
[12:42] <apw> they were allowing udev to generate them
[12:42] <Keybuk> and, most notably
[12:42] <apw> _ahh_
[12:42] <Keybuk> your patch makes pnpacpi irrelevant
[12:42] <Keybuk> at least, apparently so
[12:42] <apw> the one problem i found is there is no way to generate mroe than one
[12:42] <apw> event per device
[12:42] <Keybuk> sure there is, just attach multiple kobjects to it
[12:42] <apw> note the proggy in the 80-* patch does a while <> { }
[12:42] <apw> well not in the interface as it is
[12:42] <Keybuk> ie. why isn't it /devices/pnp0/00:09/PNP0401
[12:43] <Keybuk> apw: note the Author in the patch you're reading <g>
[12:43] <apw> right, so there is no way at the bus level which is where they are generated
[12:43] <apw> to produce all the aliases there
[12:43] <Keybuk> so how does pnpacpi do it?
[12:43] <apw> it cheats right
[12:43] <apw> and produces acpi:id1:id2:id3
[12:44] <apw> not sure if that is right, if it is that is why we have to load
[12:44] <apw> all matching modules not just the first
[12:44] <apw> MODALIAS=acpi:PNP0A08:PNP0A03:
[12:44] <apw> that is carrying two things
[12:44] <apw> though i have yet to understand why we would not just make the format
[12:45] <apw> MODALIAS=acpi:PNP1 acpi:PNP2
[12:45] <Keybuk> you can't have spaces in a modalias
[12:45] <apw> and do the right thing with those in udev
[12:45] <apw> there isn't a space, there are two aliases
[12:45] <apw> and modprobe would do the right thing
[12:45] <apw> it might need an option i can't remember but nothing insoluable
[12:46] <apw> but thats getting hugely far ahead of ourselves
[12:46] <Keybuk> simplicity of interface, I guess
[12:46] <Keybuk> MODALIAS being a single string you pass to modprobe has its elegance
[12:46] <apw> but i think the line in udev would be the same
[12:47] <Keybuk> and it actually lets you do things like have modules that say
[12:47] <apw> we we do pass it in such a way if it has spaces its N arguments
[12:47] <Keybuk>   acpi*:PNP1:PNP2:*
[12:47] <Keybuk> ie. a module that handles devices that export two pnp ids
[12:47] <apw> yeah, though those two id's repreent separat functionalities
[12:47] <apw> so that would be strange
[12:47] <apw> and you could just as well say
[12:47] <apw> MODALIAS(acpi*:PNP1*)
[12:48] <apw> MODALIAS(acpi*:PNP2*)
[12:48] <apw> but hey
[12:48] <Keybuk> then you'd be loaded for both
[12:48] <Keybuk> not for once device that implements both
[12:48] <Keybuk> *shrug*
[12:48] <apw> but i can't really see any reason not to produce pnp: style aliases at the PNP level as well
[12:48] <Keybuk> I figured out where the pnp:/acpi: aliases come from
[12:48] <apw> other than as i have discovered new modules _do_ get loaded, and some of them PANIC
[12:49] <Keybuk> hmm
[12:49] <Keybuk> if a device is currently using acpi
[12:49] <Keybuk> you only want it loaded on the acpi: device
[12:49] <Keybuk> since you need the acpi subsystem to have been init'd
[12:49] <Keybuk> if a device is using pnp: you can load it on either the pnp: device or the acpi: device
[12:49] <Keybuk> that's the problem
[12:49] <apw> i assume the acpi: ones have more information in them, such as the device id's
[12:50] <Keybuk> if you generate pnp: modaliases for all pnp devices, including acpi: ones
[12:50] <Keybuk> udev will load the modules
[12:50] <Keybuk> possibly before the pnpacpi stuff has even been initialised
[12:50] <Keybuk> or while it's being initialised
[12:50] <apw> if the device is found using acpi it will have to necessarily have ACPI up by then
[12:50] <Keybuk> ahh
[12:50] <Keybuk> no you're misordering things
[12:50] <Keybuk> these devices can be found by either pnp *or* acpi
[12:50] <Keybuk> they are in fact found by *both*
[12:50] <Keybuk> however some drivers now assume acpi
[12:51] <Keybuk> while older drivers assume pnp
[12:51] <apw> right but actually they are only found way after that
[12:51] <Keybuk> floppy happens to assume pnp
[12:51] <apw> cause udev isn't there to see the event order
[12:51] <Keybuk> battery for example assumes acpi
[12:51] <Keybuk> not necessarily
[12:51] <apw> find me a way you can get to userspace before acpi is complete
[12:52] <Keybuk> config PNPACPI=m
[12:52] <Keybuk> meh, that's a bool :p
[12:53] <apw> i think it would have to be
[12:53] <apw> i just don't see why it is bad that way
[12:53] <apw> udev has been doing it that way before
[12:53] <apw> even if we did fake up the rules
[12:53] <Keybuk> I'm trying to forsee why your patch will be rejected upstream
[12:53] <apw> completly reasonable
[12:53] <Keybuk> and right now, it will be rejected because "we already have these modaliases, they are generated by pnpacpi"
[12:53] <apw> i would be suggesting ripping out all the aliases as part of it
[12:54] <apw> (the pnp: ones
[12:54] <Keybuk> why the pnp: ones?
[12:54] <geser> doko (or any other main sponsor): have you time to review the debdiff for bug #336871 and sponsor it? (python 2.6 transition)
[12:54] <apw> or generating them in a differennt form
[12:54] <apw> as they ahve risk, as i discovered, if you have the events
[12:54] <apw> then the modules which are marked get loaded, and that blows up my machine
[12:54] <apw> as the modules are crap
[12:54] <doko> geser: yes, will do
[12:54] <Keybuk> isn't it just that the modules are assuming ACPI?
[12:55] <apw> possibly dunno yet
[12:55]  * apw thinks
[12:55] <Keybuk> the logic line I'm thinking is
[12:56] <apw> perhaps there does need to be something thats used !acpi
[12:56] <Keybuk>  - we need MODALIASes from the pnp subsystem when pnpacpi doesn't generate them
[12:56] <Keybuk>  - if we generate them from pnp subsystem, we don't need the ones pnpacpi generates
[12:56] <Keybuk>  - pnpacpi exists for a reason
[12:56] <Keybuk>  - so we're missing something :p
[12:57] <apw> i am suspicious that your 3 there is false and thats your 4
[12:57] <apw> i will go spend half an hour trying to find out its origins
[12:57] <Keybuk> I wonder whether this all fundamentally comes down to pnp configuration
[12:58] <Keybuk> ie. loading device configuration
[12:58] <apw> well first thing, acpipnp is very very old
[12:58] <Keybuk> ~2004
[12:59] <Keybuk> that's about the midpoint of driver-core development
[12:59] <Keybuk> (assuming you mean the code)
[13:01] <ScottK> Sorry to come late to the party (just finished the backscroll).  I've got a server running that's pre-2000 and so pre-ACPI.  It's running Intrepid apparently successfully.
[13:01] <ScottK> Or is it?
[13:01]  * ScottK checks
[13:02] <Keybuk> some things seem to work, some don't
[13:03] <apw> Keybuk, where did you find the acpi:'s being gnerated
[13:03] <Keybuk> apw: which bit?
[13:03] <Keybuk> there's two types of "generated"
[13:03] <ScottK> Still hardy
[13:03] <Keybuk> MODALIAS for a hardware device
[13:03] <apw> the kernel generating the uevents
[13:03] <Keybuk> or alias line inside a module
[13:04] <apw> the MODALIAS=foo part
[13:04] <Keybuk> apw: drivers/acpi/scan.c
[13:04] <Keybuk> with the actual device ids created by drivers/pnp/pnpacpi/core.c
[13:04]  * Keybuk looks at pnpbios with interest
[13:05]  * ScottK considers continuing to forget to upgrade that one.
[13:05] <apw> there is some mad shit still in there
[13:05] <Keybuk> this is quite, quite, evil
[13:06] <Keybuk> btw, can I see your patch?
[13:07] <ScottK> So if you need something tested, I can do it on that box.  It's not actually busy with any real tasks currently.
[13:08] <apw> Keybuk, how does udev decide on ordering of its requests when catching up in the beginning?
[13:08] <apw> as i note your acpi: events come out before you pnp events
[13:09] <Keybuk> apw: tree order
[13:09] <Keybuk>  /a/b comes after /a
[13:09] <Keybuk> which was the original problem I was alluding to
[13:09] <apw> hmmmm ...
[13:09] <apw> so they ahppen to be in the right order
[13:10] <Keybuk> the /devices/pnp0/* and /devices/LNXSYSTM:00/device:00/PNP*:00/PNP*:00 are unrelated in the tree
[13:10] <Keybuk> so there are no ordering guarantees
[13:10] <apw> creation order to some degree i guess
[13:10] <Keybuk> no
[13:10] <Keybuk> just sunspot order
[13:11] <apw> i bet they will be in creation order in each directory, but no guarenttes over time
[13:11] <Keybuk> I'm guessing you added a .uevent = pnp_bus_uevent line to pnp_bus_type
[13:11] <Keybuk> and in that function added MODALIAS to the uevent?
[13:11] <apw> yes exactly, nothing magic
[13:12] <apw> i suspect that is an error for this
[13:12] <Keybuk> I'm trying to work out what you need to put in the MODALIAS
[13:12] <apw> i suspect there must be an enumerator which is not the acpipnp which i shoul dhave hooked
[13:12] <Keybuk> based on pnp_bus_match
[13:13] <Keybuk> yeah, I suspect that's probably more technically correct
[13:13] <Keybuk> figure out what's adding the pnp devices in the first place
[13:13] <apw> in the absence of acpi to do it
[13:13] <apw> i think i have some isa busses on there which are not there else
[13:13] <Keybuk> how do you mean?
[13:13] <apw> i'll let you know waht i find
[13:13] <Keybuk> you have things in /sys/bus/pnp/devices that don't show up as ACPI platform devices?
[13:14] <Keybuk> btw. interestingly, pnpacpi sets pnp_platform_devices = 1
[13:14] <apw> this is a non acpi machine
[13:14] <apw> and i have stuff in pnp
[13:14] <apw> machine is booting
[13:14] <apw> machine is still booting
[13:15] <apw> Keybuk, can't you speed this boot up or something :-P
[13:15] <Keybuk> silly question
[13:15] <Keybuk> what calls pnp_add_device () if it's not pnpacpi?
[13:15] <apw> pnpbios
[13:15] <apw> and pnpacpi
[13:16] <apw> i suspect i need to hook the latter
[13:16] <Keybuk> pnpbios isn't enabled in our kernels is it? :P
[13:16] <Keybuk> at least, it doesn't show up in /boot/config-*
[13:16] <apw> its enabled
[13:16] <apw> debian/config/i386/config:CONFIG_PNPBIOS=y
[13:16] <Keybuk> sorry
[13:16] <Keybuk> someone must have renamed the option
[13:16] <Keybuk> it shows up in jaunty
[13:16] <Keybuk> just not intrepid
[13:17] <apw> ahh, there is also an isapnp directory here
[13:17] <Keybuk> dmesg | grep PnPBIOS
[13:17] <Keybuk> ?
[13:18]  * apw waits
[13:18] <Keybuk> (I had to look at /var/log/dmesg because my dmesg is full of TKIP)
[13:18] <apw> PnPBIOS: Scanning ...
[13:18] <apw> and finding 20 nodes
[13:18] <Keybuk> aha!
[13:18] <Keybuk> I see
[13:18] <apw> also isapnp speaks
[13:18] <Keybuk> PnPBIOS: Disabled by ACPI PNP
[13:18] <apw> so thats my likely target
[13:18] <Keybuk> yeah
[13:19] <Keybuk> it sounds like we just need PnPBIOS to add MODALIASES in almost the same form as acpi: but different
[13:19] <apw> pnpbios:dNNNNN
[13:19] <apw> or something
[13:19] <Keybuk> then we can have file2modalias spit out pnp: acpi: and pnpbios: MODALIASes for anything with a pnp_device_id
[13:19] <Keybuk> I'd go with pnpbios:PNPXXXX:PNPYYYY: just like acpi
[13:19] <apw> yeah
[13:19] <Keybuk> since then you can probably just steal the code ;)
[13:19] <Keybuk> anything using acpi_device_id will only work if you have ACPI
[13:19] <apw> who me i would never, 10yyp
[13:20] <Keybuk> but those drivers probably only work if you have ACPI anyway
[13:20] <apw> agreed
[13:20] <Keybuk> anything using pnpbios directly wouldn't work if you have ACPI
[13:20] <Keybuk> but I don't think there are such a thing
[13:20] <Keybuk> and ancient legacy drivers (like floppy!) would work on ACPI or PnPBIOS
[13:20] <Keybuk> and I'll rework my floppy patch to use pnp_device_id
[13:21] <apw> Keybuk, i would leave your patch alone
[13:21] <apw> as that is much more suitable for intrepid
[13:21] <Keybuk> apw: actually, it's arguably wrong if I use acpi_device_id
[13:21] <apw> maybe jaunty too depending on upstream
[13:21] <apw> perhaps os
[13:21] <Keybuk> pnp_device_id would be correct
[13:21] <Keybuk> match the other drivers nearby
[13:21] <apw> ok then
[13:21] <Keybuk> and make it work on intrepid and jaunty
[13:21] <apw> ack
[13:21] <Keybuk> (pnp_device_id exists already - this would not depend on your patch)
[13:22] <Keybuk> and the kernel already turns pnp_device_id lines into acpi*:PNPxxxx: matches for modules.alias
[13:22] <apw> oh fine then
[13:22] <Keybuk> lots of things will still be broken for non-ACPI machines
[13:22] <Keybuk> but their floppy drive will work!
[13:22] <apw> heh
[13:23] <Keybuk> and probably their soundblaster too ;)
[13:36] <ScottK> doko: Would you please look at the xdelta3 package.  I've rebuilt it for Python 2.6 with layout=deb and all and while it provides python2.5/2.6-xdelta3 is manages still to depend on python2.4, python2.5 which is clearly wrong and I have no idea why.
[13:37] <doko> ScottK: your debdiff?
[13:38] <ScottK> doko: It's in Jaunty already.  I didn't notice before I uploaded.
[13:40] <ScottK> doko: Here's what I changed http://pastebin.com/fdbb8fc
[13:43] <doko> ScottK: a .dirs file in debian creates a python2.4 dir, and xdelta3-regtest.py uses 2.5 as versioned interpreter (dh_examples is called *after* fixing the interpreter names)
[13:44] <geser> ScottK: look at the shebang line of the examples in the usr/share/doc/python-xdelta3/examples: one uses python2.4 and the other python2.5 as interpreter
[13:44] <ScottK> doko: I missed that.  Thanks.
[13:45] <ScottK> geser: Thanks.
[13:59] <nxvl> robbiew: hi robbie, just looking at the Karmic Release Schedule, is this FeautreDefinitionFreeze a new thing?
[14:01] <nxvl> cjwatson: ^^
[14:04] <Hobbsee> mvo_: ping?
[14:04] <pitti> nxvl: it was formerly called "Specifications must be finished" or so
[14:06]  * Keybuk gnarghs @ fuse
[14:06] <Keybuk> evil install rule
[14:11] <Keybuk> slangasek: around?
[14:15] <nxvl> pitti: yeah, i understand what i means, i'm just curious since i see a lot of new Freezes that weren't there before
[14:16] <nxvl> pitti: well, a lot of "Notes" have been moved to Freezes actually
[14:16] <Keybuk> pitti: you've made some uncommited changes to acpi-support
[14:17] <pitti> Keybuk: indeed, we should get those in at some point
[14:18] <vbgunz> part 2. suspending to ram seems to work flawlessly. 2 issues though. 1. I have no way to associate the power button with "suspend to ram", powerdevil doesn't work here. 2. selecting "suspend to ram" in kickoff successfully works. pressing the power button successfully wakes up *but* the screen is not locked :/ . what would be nice is, press the power button, sleep, press it again, wake up with the screen locked
[14:18] <vbgunz> I just installed kpowersave and configured it to do this and it actually works *but* I already have powerdevil and want to keep it. what can I do to help powerdevil actually work here?
[14:18] <cjwatson> nxvl: the only additions, I believe, are feature definition freeze and new packages freeze (I'm not sure how well the latter will work; I queried that)
[14:19] <Keybuk> pitti: do you know why you were asked not to just upload?
[14:19] <cjwatson> nxvl: this cycle some of the specs landed very late, and I do think that's a problem we should address
[14:23] <nxvl> cjwatson: yup, i think the same, just cheking :D
[14:24] <pitti> Keybuk: can't remember any more, I'm afraid
[15:03] <RainCT> cjwatson: that's funny.. I've just re-opened a bug of yours someone closed and pointed them to the rant on planet.ubuntu.com and now I see that's actually a post from you :)
[15:03]  * cjwatson grins
[15:06] <cjwatson> RainCT: BTW I don't want it to be an argument from authority ("Ubuntu developer told me to do it this way, so I must obey")
[15:07] <seb128> worth noticing that bug triaging practice changes between maintainers and teams
[15:07] <cjwatson> some practices are just wrong wherever they sit
[15:08] <cjwatson> closing bugs without having taken the time to understand them and determine where they best live is one of those practices
[15:09] <seb128> well, we do agressive bug closing on desktop bugs which I'm pretty sure other maintainers would disagree with, but we just have enough good quality bugs to be busy until end of time
[15:09] <seb128> so there is no need to keep tons of low quality bugs which might turn to something useful after hard work
[15:09] <cjwatson> was my bug low-quality?
[15:09] <cjwatson> I'm genuinely asking - if it wasn't, I don't see how this point is remotely relevant
[15:10] <cjwatson> the problem is that some of the people closing bugs are *unable to tell the difference*
[15:10] <cjwatson> and that's wrong no matter whether it's desktop or anywhere else
[15:11] <seb128> well, we do close crash bugs which are not sent using apport for example
[15:11] <cjwatson> not relevant to this bug
[15:11] <seb128> which I'm pretty sure you will disagree with
[15:11] <seb128> oh, I don't know of what specific bug you are speaking about
[15:11] <cjwatson> bug 328486
[15:11] <seb128> I just read some comments about bug triagers work
[15:12] <seb128> I don't discuss specifically this one
[15:12] <RainCT> cjwatson: Heh. I think yours was fine :). I'm not familiar with the recent changes so mvo_ will have to tell, though :P
[15:12] <cjwatson> if desktop practices could effectively be confined to desktop work, I would have much less issue with it
[15:12] <cjwatson> part of the problem is that people see desktop practices and think they are appropriate everywhere
[15:12]  * RainCT writes down "do not file crash reports for desktop bugs" *g*
[15:13] <cjwatson> seb128: crash / not apport> *shrug* I don't feel strongly about that, actually
[15:13] <cjwatson> seb128: I wouldn't if it were mine, but I can understand why you do that and it doesn't seem totally unreasonable
[15:13] <seb128> we also close duplicate without sending those probably as duplicate some time which tend to make some people unhappy too
[15:13] <seb128> anyway dealing with lot of bugs is not easy
[15:14] <seb128> some time -> sometimes
[15:14] <cjwatson> again, I don't feel strongly about that; I think it would be *better* if you could duplicate them properly but I understand that it is a lot of work
[15:14] <RainCT> seb128: Yeah I understand that. I don't agree, but sometimes I'm tempted to do the same ^^
[15:14] <cjwatson> the problems I have with bug triage are not ones that I think developers would generally accept; they are usually closely related to bug triagers working without particular regard to what developers need
[15:15] <cjwatson> if you work closely with bug triagers, then almost certainly they're generally doing things that fit well with your practices
[15:15] <cjwatson> my problems are when bug triagers do things that don't fit well with my practices as a developer, and don't put any effort into checking
[15:16] <cjwatson> and I don't really see that as likely to be controversial among developers?
[15:16] <cjwatson> the point of bug triage is to improve the state of bugs so that it's easier for developers to fix them efficiently
[15:16] <cjwatson> if it's making developers' lives more difficult, then it is failing
[15:17] <cjwatson> and the point of bugs, of course, is to improve the software
[15:17]  * broonie notes that he doesn't often report bugs to Ubuntu largely because of the triage.
[15:17] <cjwatson> yes, I've heard the same sentiment from many people
[15:17] <seb128> right
[15:18] <cjwatson> I am deeply disturbed by this state of affairs and want to get it fixed if at all possible
[15:18] <seb128> I just know that I tend to read argument on #ubuntu-bugs between agressive closing or letting lot of bugs which lack details open
[15:18] <broonie> It's particularly disturbing in that there are humans implementing what looks entirely like a mindless automated system.
[15:19] <cjwatson> seb128: I don't mind closing bugs that genuinely don't have enough information to fix them, and where the reporter isn't responsive
[15:19] <seb128> ie we often get people who argue that we shouldn't close duplicate without marking them as proper duplicate even if we know they are dups for sure
[15:19] <cjwatson> seb128: I *do* mind us closing bugs when the triager simply doesn't understand the information that was given
[15:19] <cjwatson> seb128: or doesn't understand what information the developer needs, and so asks for a bunch of completely useless stuff
[15:19] <seb128> right
[15:20] <seb128> I agree with you on that
[15:20] <cjwatson> seb128: this is a situation I see regularly, and is essentially what I'm complaining about. I'm not complaining about the desktop team's practices
[15:20] <cjwatson> and I don't think that, to date, the Ubuntu development team has really stood up and said "look, this isn't what we want, and it isn't what we need" in an organised way
[15:21] <cjwatson> that's sort of what I was trying to kick-start
[15:21] <seb128> cjwatson: right, I didn't take your post as something again desktop bug triaging, my comment was rather a follow up to some other comments I read on IRC since yesterday
[15:21] <seb128> ideally people who don't understand what they are doing should not be in bugsquad and allow to close bug to start
[15:22] <cjwatson> (BTW, I ran it past heno before posting, since I didn't want to be taken as having a go at the people who *are* doing a good job of Ubuntu QA)
[15:22] <seb128> allow -> allowed
[15:38] <Keybuk> quest linux-jaunty% git rebase --onto gnargh c09024e129f515dd87e0abafc7ff3a4791216838 topic/modprobe
[15:38] <Keybuk> *sometimes*
[15:38] <Keybuk> just
[15:38] <Keybuk> *sometimes*
[15:38] <Keybuk> I like git
[15:55] <pitti> wohoo :)
[15:56] <pitti> Keybuk: that extracts a patch and applies it to a different branch/file?
[15:56] <Keybuk> it reapplies the branch of patches since the revid I gave to my current branch
[16:04] <pitti> seb128: ah, you already saw the weird amd64 retracer error and removed lock?
[16:04] <seb128> pitti: yes
[16:05] <pitti> thanks
[16:05] <seb128> pitti: it seemed to be a launchpad timeout or something
[16:05] <seb128> np
[16:05] <pitti> seb128: as I said, might be that weird python-apt thing again
[16:05] <seb128> right
[16:05] <pitti> but well, at least it's so much better than a couple of weeks ago
[16:05] <seb128> it doesn't seem to be happened as often though
[16:05] <pitti> it wouldn't finish two bugs without a timeout back then
[16:05] <seb128> right
[16:06] <pitti> seb128: after the UIF rush I'll see to switch to launchpadlib, get backports for hardy/intrepid, and update the retracers to use it
[16:06] <seb128> cool
[16:06] <pitti> but that sounds like an entire day of work
[16:24] <pitti> tseliot: there's a sponsoring bug 95444; do you think you can have a look at it in the next nvidia-180 upload?
[16:25] <tseliot> pitti: sure
[16:56] <jdstrand> seb128: does evolution-mapi have an FFe? was it discussed somewhere off-list?
[16:56] <seb128> jdstrand: expection granted, it's part of GNOME 2.26 official and I can grant universe desktop exceptions
[16:57] <jdstrand> seb128: ok cool
[16:59] <jdstrand> seb128: just out of curiosity, I guess JRiddell can do the same for KDE?
[17:00]  * pitti args at Rosetta spam
[17:01] <seb128> jdstrand: not sure, MOTU sent an email with the delegation lists for teams, I would expect so yes
[17:01] <jdstrand> seb128: ok, I'll check that out. thanks :)
[17:01] <seb128> you're welcome
[17:02] <seb128> jdstrand: "Feature Freeze this Thursday" on u-d-a
[17:02] <seb128> jdstrand: this email has the detailed list
[17:02] <jdstrand> seb128: excellent
[17:03] <Riddell> jdstrand: yes I can
[17:04] <asac> slangasek: something funny: http://mail.gnome.org/archives/networkmanager-list/2009-March/msg00010.html
[17:04] <jdstrand> cool, got it
[17:05] <asac> slangasek: seems they try to achieve quite the oposite
[17:06] <asac> which might mean we need a different solution. at best getting a property into udev/hal
[17:06] <asac> for virtual stuff
[17:25] <slangasek> Keybuk: moo
[17:26] <slangasek> asac: hrm, surely hal should show a driver associated with those modules whether or not they're compiled in?
[17:26] <Keybuk> slangasek: acpi-support
[17:26] <slangasek> since "driver" != "module"
[17:26] <Keybuk> why are we holding off uploading?
[17:26] <slangasek> Keybuk: mm, are we?
[17:27] <Keybuk> slangasek: you'd asked pitti not to upload acpi-support
[17:27] <Keybuk> and I'm pretty sure you asked me not to too
[17:27] <slangasek> Keybuk: that may have been an offer to do the upload that I failed to make good on
[17:28] <Keybuk> may I?
[17:28] <slangasek> yes, please :)
[17:29] <Keybuk> done
[17:29] <asac> slangasek: i think its a hal bug. yes
[17:29] <asac> slangasek: but i doubt its a fixable one for jaunty
[17:29] <asac> (guts feeling)
[17:29] <Keybuk> yeah, this sounds one of those HAL being stupid problems
[17:31] <slangasek> asac: it surprises me if that's the case; seems to me that it should be straightforward to resolve via sysfs
[17:31] <slangasek> asac: except actually, the guy is talking about coLinux, so that may really be a virtual device and they have a different problem there
[17:31] <Keybuk> huh
[17:31] <Keybuk> actually
[17:31] <Keybuk> HAL resolves the last element
[17:31] <Keybuk> so it should work with compiled-in
[17:33] <Keybuk> $ readlink /sys/bus/pci/devices/0000:00:1f.1/driver
[17:33] <Keybuk> ../../../bus/pci/drivers/ata_piix
[17:33] <Keybuk> $ lshal | grep atea_piix
[17:33] <Keybuk>   info.linux.driver = 'ata_piix'  (string)
[17:33] <Keybuk> (ignore spelling mistake typing from one screen to the other)
[17:35] <Keybuk> $ readlink /sys/bus/pci/drivers/ata_piix/module
[17:35] <Keybuk> $ echo $?
[17:35] <Keybuk> 1
[17:35]  * slangasek nods
[17:38] <asac> slangasek: are we actually sure that virtual devices cannot be used like normal devices? e.g. dhlicent, get IP, and so on.
[17:39] <slangasek> asac: no - but there are definitely *some* set of virtual devices that should not be managed by NM, and the ones that can be should be identified and whitelisted
[17:39] <slangasek> and this patch restores the behavior from 8.10
[17:41] <slangasek> I think coLinux in particular is a case where you would want NM managing a virtual device.  You might have the same thing with e.g., VMware, depending how the network device looks from userspace
[17:41] <jdstrand> mathiaz: fyi, I deNEWd evolution-mapi source
[17:41] <slangasek> but, those are special cases
[17:41] <mathiaz> jdstrand: \o/ - thanks you!
[17:41] <mathiaz> ivoks: ^^
[17:42] <ivoks> mathiaz: jdstrand great
[17:42] <asac> slangasek: personally i would prefer if we could mark devices that cannot be managed than the other way around ... and only blacklist those that are marked like that
[17:42] <ivoks> mathiaz: i'll test it tomorrow
[17:42] <slangasek> asac: I think that's upside-down for the case of virtual devices; virtual devices that NM shouldn't touch are, I believe, the common case
[17:43] <slangasek> asac: I believe kees had this same problem on a different sort of virtual device
[17:43] <asac> slangasek: we will see. i will get this uploaded today i hope
[17:43] <mathiaz> ivoks: great - could you drop me an email with some testing instructions?
[17:43] <asac> slangasek: i know that there were complains from kees, you and soren ... and some bugs
[17:43] <ivoks> mathiaz: sure, once i try it my self
[17:43] <asac> slangasek: lets see how many complain when we dont do that anymore ;)
[17:43] <mathiaz> ivoks: so that I can write a call for testing and have other test the plugin too
[17:43] <mathiaz> ivoks: sure
[17:44] <asac> slangasek: i will try to get feedback from QA team and maybe soren to check VMs
[17:44] <seb128> jdstrand: thanks
[17:44] <slangasek> ok :)
[17:44] <asac> i just fear that we introduce yet another upgrade regression by flipping the coin
[17:45] <slangasek> asac: it would be an upgrade regression confined to jaunty, and if someone complains, then we'll have information about what kinds of virtual devices it makes sense for NM to manage :)
[17:47] <mathiaz> slangasek: openldap 2.4.15 seems to be an bug-fix only release. Should I request an FFe to merge from Debian?
[17:47] <slangasek> mathiaz: I haven't analyzed whether it's bugfix-only, I'll leave that to your judgement whether it needs an FFe. :)
[17:50] <jdstrand> mathiaz, ivoks, seb128: np
[18:09] <Daviey> Keybuk: Is there much chance of getting a FFe for a conversion from init.d to upstart?  Once any potential upgrade regressions are tested?
[18:13] <kees> asac: I'm not sure my corner-cases of network interface madness really need to be considered until the NM core is more stable.
[18:22] <Keybuk> Daviey: not this release ;)
[18:23] <slangasek> kees: hey, a little support here, I'd like it if configuring openvpn didn't cause NM to screw up my default route ;)
[18:23] <ogra> heh, upstart as FFe ?
[18:23] <ogra> funny thought
[18:24] <ogra> Keybuk, did we drop the hwclock initscript call on shutdown as well with your cleanup ?
[18:25] <Keybuk> no
[18:25] <asac> kees: right. i will decide whether we really fix the virtual-shoudlnt-be managed based on feedback i get during beta
[18:25] <ogra> :( ... sad that would have solved a lot of probs on ARM :)
[18:25] <kees> slangasek: heh, sorry.  :)  Yes, while I'd like NM to work sanely given my crackful configs, I'm not convinced it's possible in the short-term.
[18:25] <asac> kees: also: the NM core is quite stable now
[18:25] <asac> kees: at least architecture wise
[18:26] <kees> asac: I'm happy to start opening bugs if you think it's the right time for it.
[18:26] <asac> kees: lets wait for 0.7.1 to be final ;)
[18:26] <kees> asac: between libvirt, my bridge, and VLAN interfaces, it gets really really upset at me.
[18:26] <kees> heh, okay
[18:26] <asac> should happen in a few days ;)
[18:26] <kees> cool
[18:27] <Daviey> Keybuk: forgive me, i mean just for one package.  Wasn't clear :)
[18:28] <Keybuk> Daviey: what package?
[18:28] <Daviey> mythtv-backend
[18:28] <Keybuk> what's the rule?
[18:29] <Keybuk> the upstart job, sorry
[18:29] <Daviey> ahh
[18:29] <Daviey> currently just
[18:29] <Daviey> respawn
[18:29] <Daviey> exec /usr/bin/mythbackend --daemon --logfile /var/log/mythtv/mythbackend.log
[18:29] <Daviey> (iirc)
[18:30] <Daviey> (and the "start on/stop on" ofc)
[18:31] <Keybuk> that job will not work with upstart 0.5
[18:31] <Keybuk> what's your upgrade plan?
[18:31] <Keybuk> how will you cope if people change the file between now and the next release?
[18:32] <Daviey> It was the intention to tear out the old init.d using rm_conffile in packaging
[18:32] <Keybuk> it's not the init script I'm concerned about
[18:32] <Daviey> ofc, a warning might be prudent
[18:32] <Keybuk> it's the migration between upstart versions
[18:32] <Keybuk> the next version of Upstart in Ubuntu does not have a compatible configuration file format
[18:32] <Keybuk> they're not even in the same directory
[18:33] <Daviey> ahh, jobs.d ?
[18:33] <Keybuk> no
[18:33] <Keybuk> (this is me saying I'd recommend not converting things to Upstart just yet, btw :p)
[18:34] <Daviey> (i guessed as such :) )
[18:34] <Daviey> thanks
[18:34] <Keybuk> you'd only be creating more work for yourself
[18:34] <Keybuk> with no immediate benefit
[18:35] <superm1> well other than having the ability to automatically respawn the init script to cope with crashes
[18:35] <superm1> i think that was the driving feature for wanting to convert to upstart
[18:36] <Daviey> yep.. it's just that we've been umming and arrr'ing over switching for a couple of releases now :).  Currently we don't have a watcher, like mysql etc.  A crash goes unnoticed.. Ah well, good things will come from kinky koala
[18:36] <Daviey> Keybuk: ^^
[18:37] <Daviey> thanks
[19:00] <liw> hmm... https://bugs.launchpad.net/evolution/+bug/150963 shows the bug as confirmed/unknown in the Evolution project (that's upstream), and Fix released/wishlist on Ubuntu. because of the upstream status, it shows up in the list of bugs related to me.
[19:00] <liw> is there something I can to get it off the list?
[19:01] <directhex> ask #launchpad imho
[19:02] <LaserJock> is there any place that says that spec wiki pages should use a particular namespace (such as Spec/ or Specs/)?
[19:02] <LaserJock> or a category like CategorySpec
[19:03] <liw> directhex, ack, good point
[19:09] <jcastro> do we have an lp tag for bugs/patches that are major deltas from upstream or debian?
[19:09] <slangasek> liw: use https://bugs.launchpad.net/ubuntu/+bugs?field.subscriber=$me ?
[19:10] <liw> slangasek, I reported the bug, and I sort of feel I should stay subscribed, though
[19:10] <liw> the status for the upstream project is wrong, that is
[19:10] <slangasek> using that url certainly doesn't unsubscribe you, it just gives you a view that hides non-Ubuntu tasks
[19:11] <slangasek> oh
[19:12] <liw> slangasek, otoh, the url you gave is probably better for me anyway :)
[19:13] <liw> slangasek, incidentally, since you're awake -- do you have any
[19:13] <liw> er...
[19:14] <liw> slangasek, incidentally, since you're awake -- do you have any timetable for finalizing the debian/copyright spec in Debian? I expect it won't happen before jaunty releases
[19:14] <slangasek> for finalizing it - yeah, I don't think that'll happen before jaunty
[19:15] <slangasek> I do want to still get a decision on harmonizing with Fedora's naming scheme done before then
[19:15] <slangasek> (with enough lead time to be able to deploy some of these in jaunty)
[19:17] <directhex> the spec's going to be actually finalized? :o
[19:45] <bigon> does somebody know if I can get an upstream version freeze for dbus-glib with that debdiff? http://www.pastebin.be/16987 ?
[20:11] <ScottK> pitti: Are you interested to be subscribed to bugs that affect gnome-stracciatella-session?
[21:12] <rtg> ogra, lool: https://edge.launchpad.net/%7Etimg-tpi/+archive/ppa/+sourcepub/506110/+listing-archive-extra
[21:25] <lool> rtg: Ah it's great to see your efforts, thanks a lot; I'll try having a look tomorrow (late-ish here)
[21:25] <lool> ogra: Would love if you could have a look
[21:25] <rtg> lool: yeah, now I need to make sure it all still works.
[21:29] <lool> rtg: I'm not sure how I'll test it yet, but I'm NCommander and ogra have use cases already
[21:29] <lool> s/I'm/
[21:30] <rtg> lool: I have an x86_64 test case, which is my primary interest
[21:31] <lool> rtg: I think NCommander was testing under qemu/armel
[21:31] <rtg> lool: I'm pretty sure kexec itself will work. I've had mor issuers with initramfs hooks and such.
[22:19] <mdke> hi there. Is the removal of the log out and shut down buttons from the System menu in jaunty intentional?
[22:19] <mdke> (am asking for documentation purposes - that affects quite a few of our docs)
[22:20] <Nafallo> mdke: they come back if you remove the FUSA-applet from the panel is my understanding.
[22:20] <mdke> ah, so they do
[22:20] <slangasek> IOW: yes, it's intentional
[22:20] <superm1> nifty; i didn't know there was a way to get them back
[22:21] <mdke> ok, so we'll have to try and explain that there are two possibilities in the documentation
[22:21] <Nafallo> well... they are not gone then ;-)
[22:21] <Nafallo> just hidden
[22:23] <mdke> it's not very obvious how th get the FUSA applet back again :)
[22:23] <mdke> it has a different icon in the Add to Panel dialogue
[22:24] <mdke> so people who accidentally remove the applet may have some trouble turning off their computer...
[22:24] <mdke> unless we document both ways
[22:24] <mdke> so I guess the documents will have to explain both as alternatives
[22:43] <slangasek> lamont: why does https://launchpad.net/ubuntu/+source/ia32-libs/2.7ubuntu3/+build/849008/+files/
[22:43] <slangasek> lamont: why does https://launchpad.net/ubuntu/+source/ia32-libs/2.7ubuntu3/+build/849008/+files/buildlog_ubuntu-jaunty-ia64.ia32-libs_2.7ubuntu3_FAILEDTOBUILD.txt.gz show ia32-libs FTBFS on ia64 when running a command that's not what it was told to run?
[22:44] <slangasek> lamont: nah, ignore me, reading comprehension fail
[22:49] <slangasek> doko: do you know why lib32gcc1 on ia64 is being built from ia32-libs instead of from gcc-4.3?
[22:50] <slangasek> net result is that ia32-libs is FTBFS on ia64 since intrepid, AFAICS
[22:52] <doko> slangasek: ia64 doesn't have a biarch setup, would require a ia64->i386 cross compiler; I never did care much about doing this cross toolchain
[22:52] <slangasek> doko: that's fair
[22:52] <doko> but I can have a look at ia32-libs tomorrow
[22:53] <slangasek> doko: ok - no hurry as far as I'm concerned, I just TIL but I don't particularly want to lose a whole day trying to wrangle the stupid thing
[22:57] <directhex> are the ia64 buildds itanic 1 or 2?
[22:59] <mdke> didrocks: the latest update of yelp seems to have broken the adapt 04_new_ubuntu_layout.patch
[22:59] <mdke> didrocks: scratch "adapt" from that, was a bad paste
[23:00] <mdke> didrocks: yelp doesn't show the Ubuntu frontpage anymore, but rather the upstream TOC
[23:03] <seb128> mdke: he's sleeping now I think but I will sort that with him tomorrow
[23:04] <mdke> seb128: ok, thanks very much. I can send an email or file a bug. It's not clear to me whether it's the change he made or an upstream change causing the problem
[23:04] <seb128> mdke: let me have a look
[23:04] <mdke> seb128: no rush, thanks for looking into it
[23:09] <seb128> mdke: nothing obvious, the patch is still there, didn't change a lot and applied during the build
[23:09] <mdke> yeah, I saw it applied ok
[23:10] <seb128> mdke: seems to be rather an upstream change, will sort that with him tomorrow
[23:10] <mdke> seb128: thank a lot
[23:11] <seb128> you're welcome
[23:11] <seb128> there is not so many upstream changes, weird
[23:11] <mdke> yeah, I was wondering if it was 2.24.1
[23:11] <mdke> but that's in intrepid too, right?
[23:12] <mdke> oh, maybe not
[23:12] <seb128> no
[23:12] <seb128> no such version in the NEWS or changelog
[23:13] <mdke> yeah
[23:13] <mdke> mysterious. I will try and get hold of DonS if we can't figure it out over the next few days
[23:14] <ryanakca> On the UDS sponsorship form, the ``crew'' does what? Setup tables / chairs / sound systems / errands / etc?
[23:14] <seb128> should be easy to revert the few commits between version and figure which one breaks it
[23:18] <khem> On jaunty after applying updates from yesterday my wireless stopped working. I have a T61 before I investigate I thought to ask if someone else is seeing same
[23:22] <maxb> khem: I have a Z61p, still working... probably too different to be relevant... anyway, probably #ubuntu+1 would be a better place?
[23:23] <khem> maxb: thx
[23:30] <maxb> Oops, I spoke too soon, after a reboot my wireless is gone too
[23:31] <maxb> Oh no, it was just being slow to associate
[23:45] <ebroder> I'm...having a hard time debootstrapping a jaunty chroot - I'm getting an error about libstdc++.so.6 when I try to do an apt-get update within the newly created chroot. Did something about libc/libc++ change recently (or not so recently)?
[23:45] <ebroder> (I'm debootstrapping on a lenny machine. I've tried lenny's, unstable's, and jaunty's debootstrap package, and it errors out the same way each time)
[23:47] <ebroder> ...oh wait. "W: Couldn't download package libstdc++6" is probably relevant
[23:53] <maxb> :-)
[23:53] <ebroder> It looks like te mirror I was using sucks