[00:34] <kirkland> cjwatson: okay, no worries; changes reverted, uploaded again
[00:49] <TheMuso> dtchen: I am awaiting a fix for the ARM FTBFs for pulseaudi obefore I upload it.
[00:49] <TheMuso> gah typing
[00:52] <dtchen> TheMuso: hmm, should pull in http://git.debian.org/?p=pkg-pulseaudio/pulseaudio.git;a=commitdiff;h=f188f05eebcc5c28a5c3d98a35872c2e6c5d625c too
[00:53] <TheMuso> dtchen: I'm aware of that, but I was asked to drop the arm stuff from debian/rules completely.
[00:53] <dtchen> TheMuso: right, didn't know what the plan was for ARM
[00:53] <TheMuso> And unfortunately, since there is no lucid chroot on the Canonical arm porter, or so I was told at least, I can't test anything myself.
[00:58] <chuckf> I have a question about the repos. When the project goes from karmic to lucid is the process simply to create a new repo called lucid from the packages released for karmic and proceed from there?
[00:59] <chuckf> that is simple terms I'm sure, but I just want the general idea
[00:59] <cjwatson> chuckf: approximately, yes - http://wiki.ubuntu.com/NewReleaseCycleProcess for the gory details
[00:59] <chuckf> I'll go read a bit, thanks cjwatson
[01:26] <meanburrito920_> where can I get the gnome toolchain? I've checked their site but I can't seem to find any info on it.
[01:28] <meanburrito920_> or really, a collection of all their build dependencies. I can't build any of their projects because I'm missing some random dependency that I have to hunt down.
[01:28] <meanburrito920_> is there a "mega-package" of all the dependencies for building gnome projects?
[01:29] <cjwatson> meanburrito920_: try gnome-core-devel
[01:29] <mpontillo> meanburrito920_: what are you trying to build? try "apt-get build-dep gnome-terminal", for example.
[01:29] <cjwatson> probably more than you need, but
[01:30] <meanburrito920_> I'm trying to build gedit
[01:30] <cjwatson> 'apt-get build-dep gedit', then :)
[01:30] <mpontillo> yes ;)
[01:30] <meanburrito920_> cjwatson: wow, thats a lot of packages :)
[01:30] <cjwatson> works for anything that's already packaged in Ubuntu
[01:31] <cjwatson> meanburrito920_: like I say, no doubt more than you need - alternatively, just deal with it case-by-case for a while and soon enough you'll have a pretty complete environment
[01:32] <meanburrito920_> thanks!
[03:00] <maxb> Hmm... I think this boot parallelism has been taken a shade too far
[03:00] <maxb> My GDM just started despite fscks still being ongoing
[03:00] <maxb> .... including the volume containing my homedir
[04:38] <lamont> lifeless: bah.  right
[04:38]  * lamont puts a pasteit on the monitor
[04:59] <jono> didrocks, ping?
[06:46] <didrocks> jono: pong
[06:48] <jono> didrocks, hey
[06:48] <jono> didrocks, http://www.jonobacon.org/2009/11/25/introducing-lernid/ :-)
[06:48] <jono> Quickly made this much easier :)
[06:49] <didrocks> jono: oh, sweet!
[06:49] <jono> quickly is rocking my world :)
[06:49] <didrocks> jono: thanks for the notice ;)
[06:50] <lifeless> jono: nice
[06:50] <lifeless> jono: there's an IRC component?
[06:50] <didrocks> do not hesitate to open a bug on any whishlist/request you have
[06:50] <jono> lifeless, it uses webchat.freenode.net
[06:50] <jono> thanks didrocks
[06:50] <jono> lifeless, although an embedded IRC widget would be nice
[06:51] <didrocks> hum, not sure that exists in pure gtk. I'll try to have a look in the next few months if noone has the time
[06:52] <didrocks> but linking with telepathy framework can be nice :)
[06:55] <didrocks> I really think that tool can be very handy, good opportunities to contribute there, it rocks jono!
[06:55] <jono> didrocks, thanks pal :)
[06:55] <jono> I wanted to get it out so we can start refining it ready for Ubuntu Developer Week
[06:56] <didrocks> right, still some week remaining to polish it
[06:57] <jono> yeah :)
[06:57] <jono> it also means we can file bugs and accept patches :)
[06:57] <jono> so thanks again didrocks, Quickly awesome :)
[06:57] <didrocks> thanks to you for you rocking work :)
[06:58] <jono> I also wrote https://edge.launchpad.net/flarebook in Quickly but havent had time to push a PPA yet
[06:58] <jono> need to fix some last remaining bugs
[06:58] <jono> :)
[06:58] <didrocks> I really promis GPG key setup will be easier in 0.4 :)
[07:00] <ajmitch> jono: that looks good :)
[07:00] <jono> didrocks, hehe, sounds good :)
[07:01] <spm> jono: my 2c is we need you to attend more events further away more often; oh, and ensure you have a powerplug in your aircraft seat ;-)
[07:01] <jono> ajmitch, thanks!
[07:01] <jono> spm, lol!
[07:15] <pitti> Good morning
[07:16] <ajmitch> hi pitti
[07:16] <pitti> hey ajmitch, how are you?
[07:17] <ajmitch> good, how are you? recovered from UDS?
[07:17] <pitti> yes, I did; and I skipped the Ubuflu this time \o/
[07:17] <ajmitch> yay!
[08:01] <dholbach> good morning
[09:30] <directhex> morning dholbach
[09:30] <dholbach> hi directhex
[09:30] <directhex> hm. is http://1.bp.blogspot.com/_rihgl8Kfuew/SwqlbBnUxlI/AAAAAAAADW8/Pm2dnGqk-u0/s1600/Screenshot-F-Spot+View.png the kind of thing being talked about in the default apps session at UDS?
[09:31] <dholbach> directhex: were you asking me specifically? because I wasn't at that session :)
[09:32] <directhex> dholbach, more seb128 or pitti i think
[09:32] <dholbach> alright
[09:32] <seb128> directhex, yes, that change is following the uds discussion
[09:32] <pitti> directhex: pretty much, yes
[09:33] <seb128> directhex, we talked with upstream about the changes we need there...
[09:33] <directhex> seb128, ah, cool. wasn't sure how much interaction you have w/ stephane
[09:42] <pitti> mvo: https://blueprints.edge.launchpad.net/ubuntu/+spec/desktop-lucid-jockey-hotplug-support is ready for review; it's a very short one; I think it's sufficient, but let me know if you want more details
[09:43] <mvo> pitti: sounds good to me, its short, but the task it needs to do is short as well :)
[09:44] <pitti> mvo: exactly; main purpose of this is to track progress
[09:57] <LucidFox> pitti, I have a question regarding autosyncing!
[09:57] <pitti> !ask | LucidFox
[09:57] <LucidFox> I've been waiting for two new packages, x11vnc and dbus-c++, to be autosynced from testing for a long while, but it hasn't happened. Any idea why?
[09:57] <pitti> LucidFox: I guess none of the archive admins got to it yet
[09:58] <pitti> LucidFox: let me start an auto-import run
[09:58] <pitti> yep, they are in new-source
[09:59] <StevenK> I did an new-source run at UDS, I guess they dropped to testing after that
[10:00] <pitti> yay 3.0 packages
[10:00] <StevenK> Ah ha
[10:00] <LucidFox> No, before UDS.
[10:00] <StevenK> If they're 3.0, you can't have them yet
[10:00] <LucidFox> Hmm, they aren't using the 3.0 quilt format.
[10:01] <LucidFox> It can still be 3.0 even if it has diff.gz?
[10:01]  * StevenK looks
[10:01] <pitti> LucidFox: no, not those particular two
[10:01] <pitti> there are just others in the list which are
[10:01] <LucidFox> ah
[10:23] <pitti> LucidFox: E: x11vnc is trying to override x11vnc_0.9.3.dfsg.1-1ubuntu2 without -f/--force.
[10:23] <pitti> LucidFox: apparenty it moved to a new source package?
[10:24] <pitti> can the ubuntu changes be ditched?
[10:26] <[BIOS]dnivra> i am currently looking at logs of Ubuntu Developer Week and have some doubts; which is the IRC channel to ask help on this?
[10:26] <[BIOS]dnivra> is it this?
[10:27] <[BIOS]dnivra> someone please respond: i've been to 4 different channels asking for this in vain
[10:27] <dholbach> [BIOS]dnivra: best to just ask your question
[10:27] <cjwatson> and please be patient, IRC is pretty asynchronous and a minute is a very short time to wait for a response
[10:27] <[BIOS]dnivra> oh ok
[10:28] <[BIOS]dnivra> well i'm looking at Getting started with Ubuntu Development(right what you took dholbach)
[10:28] <[BIOS]dnivra> and am currently configuring pbuilder
[10:28] <[BIOS]dnivra> it says i need to add a line to the file ~/.pbuilderrc
[10:29] <[BIOS]dnivra> but i don't have a file thus
[10:29] <[BIOS]dnivra> the logs don't suggest that i need to create one
[10:29] <[BIOS]dnivra> do i have to create one or something wrong with my installation of pbuilder
[10:29] <cjwatson> create it
[10:29] <[BIOS]dnivra> there's nothing wrong with pbuilder installation is there?
[10:30] <cjwatson> installing a package never creates files in your home directory
[10:30] <[BIOS]dnivra> well gnupg did
[10:30] <cjwatson> no, it didn't
[10:30] <cjwatson> running the program gpg did
[10:30] <cjwatson> installing the package gnupg did not
[10:30] <cjwatson> important distinction :)
[10:30] <[BIOS]dnivra> i didn't run it!
[10:30] <[BIOS]dnivra> just installed it
[10:30] <cjwatson> something did, even if it was not you explicitly
[10:31] <[BIOS]dnivra> right
[10:31] <cjwatson> packages can't mess around in users' home directories - among other things, it tends to break when people are using NFS home directories
[10:31] <cjwatson> so anyway, just create the file
[10:32] <[BIOS]dnivra> cjwatson: ok thanks
[10:44] <[BIOS]dnivra> i keep getting unsafe permissions on ~/.gnupg/gpg.conf. is there some setting i need to change?
[10:50] <johe|work> hi, an mantainer of snmpd online?
[10:53] <[BIOS]dnivra> i am currently trying to create my gpg key and i keep getting error that unsafe permission on configuration file
[10:54] <[BIOS]dnivra> what is  exactly wrong with permissions of ~/.gnupg/gpg.conf? I am the owner. Is it something else?
[10:55] <tsimpson> [BIOS]dnivra: it needs to be 600 (-rw-------)
[10:56] <tsimpson> and ~/.gnupg/ should be 700 (drwx------)
[10:56] <[BIOS]dnivra> tsimpson: ok
[11:00] <cjwatson> it's fine for gpg.conf itself to be mode 644, as long as the containing directory's permissions are tight
[11:00] <cjwatson> also your home directory needs to not be group- or world-writable
[11:01] <siretart`> will there be a lucid release for sparc? perhaps lucid-server only?
[11:03] <cjwatson> same as usual for ports, we'll release whatever CDs work although they won't be supported
[11:03] <cjwatson> (by Canonical anyway)
[11:04] <seb128> doing sync is no fun nowadays
[11:05] <seb128> there is a zillion of v3 sources now
[11:05] <seb128> need to edit the list and run sync-source a zillion times
[11:05] <siretart`> hm. I hoped that canonical would intend to continue the sparc port. so hardy was the last canonical supported release :-(
[11:05] <siretart`> seb128: are you doing ftp-master work right now? could you perhaps cleanup the emacs section confusion? (emacs22 -> universe, emacs23 -> main)
[11:06] <seb128> siretart': I'm doing syncs now but I can fix that one, is there a bug about it? is anything in main depending on emacs23?
[11:07] <cjwatson> siretart`: we announced this some time ago
[11:07] <siretart`> cjwatson: ok, seems I've missed it. thanks
[11:08] <siretart`> seb128: not that I knew, I was told that it should be handled during regular archive cleanups, but since it hasn't happend yet, I assume that this was wrong.
[11:08] <cjwatson> siretart`: indeed, 8.04 was not supported on sparc either. https://lists.ubuntu.com/archives/ubuntu-devel-announce/2008-March/000400.html
[11:08] <siretart`> seb128: I consider it as a 'normal' upstream version upgrade, only that the name of the source package changed
[11:09] <seb128> siretart': still it needs something to pull it in main, it's not archive side only
[11:09] <seb128> either a seed or a depends
[11:09] <siretart`> oh, I see. I'll check that
[11:16] <siretart`> seb128: okay, I've updated the seeds in bzr now. anything else I need to do?
[11:46] <wgrant> seb128: Why are you blacklisting v3 sources? They shouldn't crash sync-source any more -- they should just be rejected harmlessly later.
[11:46] <seb128> "I: imvirt [universe] -> imvirt_0.3.1-1 [universe].
[11:46] <seb128>  * command was 'dpkg-source -sn -x /home/lp_archive/syncs/imvirt_0.3.1+svn426-1.dsc'
[11:46] <seb128>  [dpkg-source output:] dpkg-source: error: Unsupported format of .dsc file (3.0 (quilt))
[11:46] <seb128> E: 'dpkg-source -x' failed for /home/lp_archive/syncs/imvirt_0.3.1+svn426-1.dsc [return code: 2304].
[11:46] <seb128> "
[11:46] <seb128> wgrant, I keep running into those
[11:46] <wgrant> Oh.
[11:46] <seb128> and sync-source -a stops
[11:47] <seb128> any better way?
[11:47] <wgrant> That's because of cocoplum's old dpkg, not lack of LP support :(
[11:47] <wgrant> Damn.
[11:49] <seb128> cjwatson, elmo: ^ do you know if that's something being worked?
[11:50] <wgrant> Sorry, I completely forgot that sync-source unpacked the source beforehand, so didn't work around that as well.
[11:51] <seb128> wgrant, nothing to be sorry about, thanks for the work you do ;-)
[12:00] <cjwatson> seb128: yes, there's an RT ticket and stuff
[12:10] <ogra> dtchen, around ? i'm trying to fix the armel patch in debian/rules to clear the FTBFS, but the current bzr branch seems not to be for pulse-0.9.20
[12:11] <ogra> dtchen, talking about pulse indeed :)
[12:12] <seb128> cjwatson, ok thanks
[12:16] <ogra> TheMuso, ^^^ any hint ? did you guys change the default branch for pulse or is there just an upload of 0.9.21 missing ?
[12:27] <mvo> Riddell: hi, there is a new compiz that gets rid of the compiz-wrapper script and does the checks inside the binary itself. do you still use that wrapper for kde4?
[12:28] <Riddell> mvo: no we dropped that in karmic, kwin's detections seems to work fine on its own
[12:29] <seb128> go go go mvo!
[12:30] <dijmen> are grub2 vga/gfxpayload supposed to not work with karmic under no-guestadditions vbox?
[12:37] <cjwatson> dijmen: doesn't work particularly well period
[12:38] <cjwatson> dijmen: the kernel doesn't know how to display text when started with gfxpayload, so you don't get any text until/unless it manages to bring up a framebuffer
[12:38] <mvo> Riddell: great, thanks
[12:38] <mvo> seb128: heh :)
[12:38] <dijmen> cjwatson: is it grub2 only?
[12:38] <seb128> mvo, you will get lot of free tea at next sprint or uds if you manage to speed compiz this cycle ;-)
[12:38]  * seb128 hugs mvo
[12:41] <cjwatson> dijmen: yes
[12:42] <dijmen> cjwatson: but I tried vga=792 too. doesn't this mean it's not a gfxpayload issue?
[12:43] <mvo> seb128: tea!
[12:43] <cjwatson> dijmen: it's complicated :)
[12:44] <cjwatson> dijmen: grub2 uses Linux' 32-bit boot protocol, which works differently
[12:44] <cjwatson> dijmen: if you use the older 16-bit boot protocol (use the linux16/initrd16 commands instead of linux/initrd), then you may be able to get vga= to work; vga= is implemented by 16-bit code before Linux switches to 32-bit
[12:45] <cjwatson> dijmen: vga= doesn't fit all that well with KMS, though, in my understanding, so it probably has a pretty finite lifetime anyway
[12:53] <dijmen> cjwatson: thank you
[13:03] <zanshin> Who can tell me what's up with the rt61pci driver. Since Koala my wifi isn't working any more.
[13:05] <LucidFox> "Gwibber is shipping by default in Lucid. Let’s help it make a great first impression."
[13:06] <LucidFox> So let me get this straight... They're removing GIMP, yet introducing this ridiculously specific application?
[13:08] <ScottK> Well GIMP is a pretty specific application too.
[13:08] <dijmen> LucidFox: you won't have to use lucid
[13:09] <LucidFox> I'd say image editing is probably a function more demanded by the average user than microblogging.
[13:09] <LucidFox> How many % of Ubuntu users are going to use microblogging at all, let alone a desktop client for it?
[13:12] <dijmen> LucidFox: what's wrong with gwibber? it's small and gets the job done. I don't see why it should be dropped.
[13:13] <cjwatson> mm, gwibber is, to be fair, a fraction of the size of gimp. I'm not sure they should be considered in direct opposition like this (and honestly I have no data on image editing vs. microblogging, I don't know if you do but it isn't obvious to me)
[13:13] <LucidFox> I'm not putting them in direct opposition. :)
[13:13] <cjwatson> I think you did, above
[13:13] <LucidFox> Just, out of all the features that could be shipped with Ubuntu by default, desktop microblogging doesn't exactly seem the most wanted one.
[13:13] <cjwatson> at least it really did come across that way
[13:14] <cjwatson> gimp has been pretty much next on the list of things to be dropped from the default installation for quite a while now
[13:14] <dijmen> LucidFox: "So let me get this straight... They're removing GIMP, yet introducing this ridiculously specific application?"
[13:15] <cjwatson> not least because of its size
[13:15] <cjwatson> I'm not 100% happy with it, but it doesn't seem a totally unreasonable decision either
[13:15] <ogra> f-spot can do basic photo editing ...
[13:16] <Laney> and there's time to get f-spot better
[13:16] <dijmen> LucidFox: given a good usefulness/size ratio, any feature could and should make it in the default installation
[13:18] <LucidFox> Granted, you can call me biased because I'm annoyed by the Twitter fad, don't "get" microblogging and don't use it myself. And it's not like I can affect the minds of the people who make these decisions.
[13:19] <dijmen> cjwatson: does it look like these gfxpayload issues will be fixed any time soon?
[13:19] <cjwatson> dijmen: no
[13:19] <cjwatson> dijmen: I wouldn't bother with gfxpayload if I were you
[13:19] <cjwatson> at least not for a while
[13:19] <dijmen> cjwatson: what should I do instead? I love a high-resolution tty!
[13:20] <cjwatson> we'll be taking a somewhat different approach to framebuffer init in lucid, but making the grub->linux transition smooth basically requires importing KMS code into grub
[13:20] <cjwatson> dijmen: use a graphics card for which KMS is supported, or else use vga= with linux16/initrd16
[13:20] <dijmen> cjwatson: how do I force linux16/initrd16?
[13:20] <cjwatson> where KMS is supported, you already get a high-resolution tty out of the box
[13:20] <cjwatson> you'd have to edit /etc/grub.d/10_linux I think
[13:21] <dijmen> cjwatson: some text search pattern tip inside 10_linux?
[13:21] <cjwatson> it's not that long. Sorry I'm not going to have time to walk you through it step by step :(
[13:22] <dijmen> thank you anyway (actually I was just asking for a relevant word)
[13:24] <cjwatson> dijmen: "linux" is accurate but might be considered to be unhelpful ...
[13:24] <dijmen> :)
[13:25] <LucidFox> By the way, why doesn't Ubuntu include an IRC client by default but Kubuntu does?
[13:26] <StevenK> LucidFox: It does, it's just hiding.
[13:26] <LucidFox> Empathy?
[13:26] <StevenK> LucidFox: Yup
[13:26] <LucidFox> Its IRC support is even less intuitive than Pidgin's, I think.
[13:26] <dijmen> StevenK: then kubuntu has two
[13:27] <LucidFox> Kopete also technically has IRC support, yet Kubuntu still ships Quassel separately.
[13:27] <dijmen> LucidFox: that's exactly what I meant
[13:28] <Riddell> kopete doesn't have irc now
[13:28] <ScottK> Not since KDE3 times.
[13:28] <dijmen> Riddell: just add an account
[13:29] <dijmen> ScottK: well, that's because they removed it
[13:32]  * Riddell not quite sure where this argument is going but suspects he and ScottK won it
[13:32]  * ScottK considered suitable replies and came up empty.
[13:42] <Tm_T> oh, dijmen is here too
[13:42] <dijmen> Tm_T: yeah, I'm trying to offer some help
[13:45] <Tm_T> dijmen: I know (:
[13:45] <Tm_T> dijmen: Kopete doesn't have IRC-protocol supported currently because noone is working on it, it's broken
[13:46] <Tm_T> dijmen: thus, Kubuntu has only one client
[13:50] <rgreening> ping persia
[14:02] <mathiaz> free: hi - re bug 484861 - could you update the test case to have more detailed steps?
[14:56] <fatal^> mutt
[14:56] <fatal^> err..
[14:57] <tolonuga> ubuntu dropped hal, but didn't even touch packages depending on hal like "openct" so they are totaly broken now. where can I find information about the hal replacement, so I can fix the package?
[14:58] <soren> hal is still in the archive. What's openct?
[14:59] <cjwatson> tolonuga: http://wiki.ubuntu.com/Halsectomy
[14:59] <cjwatson> and indeed, hal is actually still installed by default
[15:00] <dholbach> and it's still installed by default, because at least xserver-xorg needs it
[15:00] <cjwatson> I hope this isn't argument by rumour :)
[15:01] <azteech> soren: http://www.opensc-project.org/openct/
[15:02] <cjwatson> I'm puzzled that our openct packages don't depend on hal, if they need it
[15:02] <dijmen> cjwatson: once I install the kms module, how do I enable it in grub2?
[15:02] <soren> azteech: Ah, opensc I know about :)
[15:03] <cjwatson> dijmen: um
[15:03] <azteech> :)
[15:03] <dholbach> there seem to be a number of openct bugs, most of which predate any hal/devicekit changes: https://bugs.launchpad.net/ubuntu/+source/openct
[15:03] <cjwatson> dijmen: kms isn't a module, and it has no direct support in grub2. Can you reformulate your question?
[15:03] <dholbach> it might have been broken before
[15:03] <dholbach> (not that it makes things better)
[15:04] <dijmen> cjwatson: I asked "what should I do instead? I love a high-resolution tty!" and you replied "use a graphics card for which KMS is supported, or else use vga= with linux16/initrd16"... so what do I do now? :)
[15:04] <cjwatson> if your system doesn't already support KMS, you are unlikely to have much luck trying to plumb it in yourself!
[15:05] <dijmen> cjwatson: so are you sure installing vbox's guest additions won't add KMS support?
[15:06] <tolonuga> cjwatson: was udev fixed in the meantime or is it still that buggy? we found several issues with udev, so the udev developers at some point asked us to use hal instead, to avoid all those race conditions.
[15:07] <tolonuga> cjwatson: issue 1: sometimes a script is run by udev, before udev created /dev/bus/usb/nnnn/mmmm so you can't access the device it reports it created. (fork&sleep in background works, but ugly hack).
[15:08] <tolonuga> cjwatson: issue 2: udev gets kernel signals about a new usb device and about usb interfaces that device has. by the time udev looks at the interfaces of the device, it forgot what the device file name for the device was, so it can't tell that to scripts matching the interface.
[15:09] <tolonuga> cjwatson: ah,openct doesn't depend on hal, because for serial smart card readers hal is not needed. but for usb it is.
[15:11] <Keybuk> tolonuga: udev can't forget
[15:11] <Keybuk> the device name is basically the only thing that the kernel *tells* udev
[15:13] <tolonuga> Keybuk: hu? they broke usb kernel/user space again? the last time I checked the kernel issues seperate events for the device itself and for interfaces it has (e.g. think keyboard with build in smart card reader -> 2 interfaces, 2 extra events), and udev processed them serially - by the time it got the event about the smart card interface it had forgotten what the name of the device was (or maybe even didn't process that event so far, so it knew about an
[15:14] <tolonuga> interface without device)
[15:14] <Keybuk> tolonuga: just about everything you said there is wrong
[15:14] <Keybuk> perhaps you should say what the problem you're having is
[15:14] <Keybuk> and I'll try to help
[15:16] <tolonuga> ok, fine. I want a script to be called everytime a usb smart card reader is plugged in. I have a) listof vendor/product id and b) interface class "b", and need to get called for both types of devices. I need the file name of the /dev/bus/usb/nnnn/mmmm device, and it should be already created (preferably, so I don't need to fork and sleep/loop in the background to wait for it)
[15:16] <Keybuk> something like
[15:18] <tolonuga> an udev rule file is at http://www.opensc-project.org/svn/openct/trunk/etc/openct.udev.in - but the udev developers (kay sievers and greg k-h) told us to move to hal, because of the races and problems we had with udev...
[15:18] <davidboy> How do I change my launchpad username in bazzar?
[15:18] <tolonuga> so now it is funny ubuntu promotes udev instead of hal (if I understand things right)
[15:19] <Keybuk> SUBSYSTEM=="usb", ATTR{bInterfaceClass}=="b", ATTRS{idProduct}=="xxxx", ATTRS{idVendor}=="yyyy"
[15:19] <Keybuk> ^ that should match your device's interface
[15:19] <Keybuk> worth trying
[15:19] <Keybuk> tolonuga: when did you ask?  the plumbing layer has been undergoing rapid development over the last few years
[15:19] <Keybuk> HAL is entirely deprecated now, and expected to go away completely within the next year
[15:20] <tolonuga> well 2-3 years ago they started to push us from udev to hal.
[15:20] <Keybuk> there you go
[15:20] <Keybuk> 2-3 years ago is practically a different world as far as this stuff is concerned ;)
[15:20] <Keybuk> 2-3 years before that we didn't even *have* hotplug
[15:20] <pitti> Keybuk: shouldn't you check for ENV{DEVTYPE}=="usb_device" as well? or is SUBSYSTEMS=="usb" sufficient for matching a /dev/bus/usb/... kind of device?
[15:21] <Keybuk> pitti: implied by checking for bInterfaceClass ;-)
[15:21] <tolonuga> not true, I did usb hotplugging with /sbin/hotplug interface in 2001.
[15:21] <pitti> nice
[15:21] <Keybuk> tolonuga: I don't remember it being around back then ;)
[15:21] <Keybuk> I remember hotplug being new and shiny when we did warty
[15:21]  * soren chuckles
[15:21] <Keybuk> and being one of the first distros to actually use this stuff
[15:21] <jdong> lol those were the days
[15:21] <soren> Yeah. Good times.
[15:22] <soren> :)
[15:22] <Keybuk> but we could argue about that, or I could help you fix your problem :)
[15:22] <Keybuk> I'm easy either way
[15:22] <jdong> and no longer mounting devfs...
[15:22] <dholbach> I didn't know we had that many historians here :-)
[15:22]  * pitti sheds a tear for pmount
[15:22] <Keybuk> pitti: Ubuntu contributes upstream product, Fedora rewrites it instead of adopting it?
[15:22] <tolonuga> what about rules like KERNEL=="[0-9]*:*", WAIT_FOR_SYSFS="bInterfaceProtocol" -- still needed? that was for some race protection in udev.
[15:23] <Keybuk> tolonuga: god no
[15:23] <Keybuk> that was kernel race protection
[15:23] <Keybuk> we fix those in the kernel now
[15:23] <tolonuga> should I simply cross fingers, remove all the old cruft, and hope for fixes in udev/kernel.
[15:23] <Keybuk> tolonuga: if you're using karmic, you don't need any of that
[15:23] <Keybuk> so first
[15:23] <Keybuk> SUBSYSTEM=="usb", ATTR{bInterfaceClass}=="b", ATTRS{idProduct}=="xxxx", ATTRS{idVendor}=="yyyy"
[15:23] <Keybuk> does that match your device?
[15:23] <Keybuk> RUN+="/usr/bin/touch /tmp/foo" is a good trick
[15:24] <tolonuga> I have that rule (see the link I mentioned), and it works - except for the races we sometimes had under load.
[15:24] <Keybuk> ok
[15:24] <Keybuk> and does $name expand to the /dev/bus/usb name of the interface?
[15:24] <tolonuga> does ubuntu tell me the device file name?in which variable?
[15:24] <Keybuk> (if you have that rule)
[15:24] <Keybuk> tolonuga: $parent oddly enough
[15:24] <tolonuga> normal is USB_DEVICEFS
[15:24] <mpt> robbiew, that list of USC work items, would it be ok if mvo and I prioritized those on Monday? Or do you want it sooner than that?
[15:24] <Keybuk> the ATTRS bit causes a parent match
[15:25] <Keybuk> so fills the parent device node name into $parent
[15:25] <tolonuga> or DEVNAME
[15:25] <tolonuga> I can also guess it with "udevinfo" or "udevadm info"
[15:25] <Keybuk> tolonuga: or you could listen ;)
[15:26] <tolonuga> ENV{DEVTYPE}=="usb_interface", SYSFS{bInterfaceClass}=="0b", SYSFS{bInterfaceSubClass}=="00", SYSFS{bInterfaceProtocol}=="00" RUN+="@udevdir@/openct_usb"
[15:26] <tolonuga> is ok?
[15:26] <Keybuk> no none of that
[15:26] <Keybuk> that's not what I said at all
[15:26] <Keybuk> see
[15:26] <robbiew> mpt: need them this week..have to review Lucid items with mark next week
[15:27] <tolonuga> I either have product/vendor id pairs, or I have the bInterfaceClass "b" (then I don't care about product/vendor), so I have two rules for those.
[15:28] <Keybuk> tolonuga: how about you just do what I said?
[15:28] <Keybuk> since I am the Ubuntu udev maintainer
[15:28] <Keybuk> and an upstream maintainer
[15:28] <Keybuk> so I know a _little_ bit about this stuff ;)
[15:28] <Keybuk> so the rule I gave you is probably "correct"
[15:28] <tolonuga> is there some document, which environment variables are set by udev, or do I simply test and hope the other distributions have it the same way.
[15:28] <Keybuk> (modulo some tweeking)
[15:28] <tolonuga> ah, great to find the man in charge, super!
[15:29] <Keybuk> tolonuga: all major distributions instead of Debian have the same udev stuff
[15:29] <Keybuk> except Debian, I mean
[15:29] <tolonuga> ah,ok. that wasn't always the case I remember :(
[15:29] <tolonuga> can you have a short look at http://www.opensc-project.org/svn/openct/trunk/etc/openct.udev.in
[15:30] <Keybuk> tolonuga: that file is for an ancient version of udev
[15:30] <tolonuga> it is the file we used for a long time,till kay told us to move to hal. it should work still I guess, and maybe we can cut rules no longer needed.
[15:30] <Keybuk> no, it won't work
[15:30] <tolonuga> did udev stay compatible? or do I rewrite it?
[15:30] <Keybuk> it'll parse that file still
[15:30] <Keybuk> for now
[15:30] <Keybuk> but it won't work how you want
[15:30] <Keybuk> the new rules are much better
[15:31] <tolonuga> "writing udev rules" by danial drake on reactivated.net version 0.74 is still authorative, or is that one outdated too?
[15:31]  * pitti gently reminds Keybuk that Debian now has a more recent udev than lucid :)
[15:32] <Keybuk> pitti: Marco still refuses to adopt the same rules directory as everyone else
[15:32] <Keybuk> tolonuga: almost certainly massively out of date
[15:33] <tolonuga> ok. what is my best progress from here? subscribe to hotplug-devel (or whatever list), and post my old rules for review/suggestions for the new ones?
[15:33] <Keybuk> that's one approach yeah
[15:34] <Keybuk> SUBSYSTEM=="usb", ATTR{bInterfaceClass}=="0b", ATTRS{idVendor}=="0b97", ATTRS{idProduct}=="7762", RUN+="/bin/echo /dev/$parent"
[15:34] <Keybuk> I just used that rule on a random usb device I have here
[15:34] <Keybuk> udevadm test on the interface gives me
[15:34] <Keybuk> udevadm_test: run: '/bin/echo /dev/bus/usb/002/005'
[15:34] <Keybuk> which is, I think, what you want?
[15:34] <Keybuk> the "S" on the end of ATTRS is the important bit here
[15:35] <Keybuk> match rules without an "S" match the exact kernel object
[15:35] <pitti> tolonuga: if you split that, one rule tests ATTR{bInterfaceClass}, the  other tests ENV{DEVTYPE}="usb_device", ATTRS{idVendor}=="xxx", .., it should DTRT
[15:35] <Keybuk> so in that case, we're matching a kernel object in the "usb" subsystem with a bInterfaceClass attribute of "0b"
[15:35] <tolonuga> ACTION="add" is still there?
[15:35] <Keybuk> pitti: no, it won't
[15:35] <Keybuk> pitti: that's the entire point I'm trying to convey here, you _can't_ split these rules
[15:35] <Keybuk> tolonuga: if you want to run something, yes
[15:35] <pitti> tolonuga: it's best to write ACTION!="add", GOTO="end" at the top of the file, as you already do
[15:36] <pitti> Keybuk: but that's what he's looking for?
[15:36] <Keybuk> but right, pitti's advice on the action bit works
[15:36] <Keybuk> pitti: but that's wrong
[15:36]  * Keybuk rewinds himself
[15:36] <Keybuk> we're matching a kernel object in the "usb" subsystem with a bInterfaceClass attribute of "0b"
[15:36] <tolonuga> pitti: yes, I have that,so was wondering if it should still work.
[15:36] <Keybuk> then once we have that match, we have two further ATTRS rules to process
[15:36] <pitti> Keybuk: ^ why?
[15:36] <tolonuga> or devices with different InterfaceClass (e.g. 0xff), but a certain product/vendor id.
[15:36] <Keybuk> these are special
[15:36] <Keybuk> ending with an "S" means "look up parent object"
[15:37] <pitti> ah, for selecting $parent
[15:37] <Keybuk> so once we've found a USB 0x0b device, we use ATTRS to look up its idVendor and idProduct attribute to check that's correct
[15:37] <pitti> but for ENV{DEVTYPE} you would use $name, not $parent?
[15:37] <Keybuk> this matches not only the device, but it's parent
[15:37] <Keybuk> pitti: ignore DEVTYPE, it's really not important
[15:37] <pitti> seems that I need to re-learn udev rules myself
[15:38] <mneptok> ivoks: thanks for the bug report. i'm on vacaton the next 3 days, but i will try to get one of the Maria core devs to look at the issue before my holiday.
[15:38] <pitti> Keybuk: but here we don't know what vendor/product ID should be, if we already have the iface class?
[15:38] <Keybuk> so now we've matched an interface device, and its actual parent physical device
[15:38] <Keybuk> the /dev name of the physical device will be in $parent
[15:38] <ivoks> mneptok: thank you!
[15:38] <Keybuk> pitti: ?
[15:38] <tolonuga> so s/SYSFS/ATTR and adding /dev/$parent to RUN+= are the changes I find. done.
[15:38] <Keybuk> tolonuga: no
[15:38] <Keybuk> the important thing is that the matches are both on the same line
[15:38] <pitti> Keybuk: iface class=="0b" OR vendor/product match..
[15:38] <mneptok> ivoks: nema na čemu!
[15:38] <Keybuk> pitti: not following still?
[15:39] <ivoks> mneptok: hahaha
[15:39] <mneptok> ivoks: please do not try to sort by that last word ;)
[15:39] <pitti> Keybuk: I know what you are trying to achieve with "selecting" the right parent with ATTRS, but we don't know what to compare with
[15:39] <Keybuk> pitti: why not?
[15:39] <ivoks> mneptok: true
[15:39] <Keybuk> I looked at the same rules file as you
[15:39] <Keybuk> it's easy
[15:39] <tolonuga> Keybuk: btw: some while ago the usb developers diskussed obsoleteing some kernel code for usbfs, that would end up putting a lot less info into the uevent received by udev. any idea if that happened?
[15:39] <Keybuk> just convert all those SYSFS{}... lines into lines like the one I pasted
[15:40] <pitti> Keybuk: you don't know the vendor/product IDs
[15:40] <Keybuk> tolonuga: some distributions disable it, others don't
[15:40] <tolonuga> does ubuntu keep compiling kernel with USB_DEVICEFS?
[15:40] <Keybuk> pitti: there's a list of them in the rules file
[15:40] <Keybuk> tolonuga: I don't think so
[15:40] <pitti> Keybuk: right, for those
[15:40] <Keybuk> (otherwise I go beat the kernel developers again)
[15:40] <pitti> but I'm talking about hte replacement for
[15:40] <pitti> ENV{DEVTYPE}=="usb_interface", SYSFS{bInterfaceClass}=="0b", SYSFS{bInterfaceSubClass}=="00", SYSFS{bInterfaceProtocol}=="00" RUN+="@udevdir@/openct_usb"
[15:41] <Keybuk> pitti: that's the rule he needs the parent device for
[15:41] <Keybuk> which is why he needs to write lots of them
[15:41] <Keybuk> that should be
[15:41] <pitti> but why bother, and not just use DEVTYPE==usb_device?
[15:41] <tolonuga> ah, in my 2.6.31 from ubuntu it is still enabled. would I change any of these rules if it was disabled on other distros (or would that be a lost case anyway)?
[15:41] <Keybuk> SUBSYSTEM=="usb", ATTR{bInterfaceClass}=="0b", ATTR{bInterfaceSubClass}=="00", ATTR{bInterfaceProtocol}=="00", ATTRS{idVendor}=="xxxx", ATTRS{idProduct}=="yyyy", RUN+="openct_usb"
[15:41] <Keybuk> for each device
[15:42] <Keybuk> tolonuga: no, these rules are written assuming it doesn't exist
[15:42] <tolonuga> so I need $parent only if I match the interface, but not if I match the whole device (with product/vendor id)?
[15:42] <Keybuk> pitti: because that doesn't help!
[15:42] <Keybuk> pitti: that matches the device, not the interface
[15:42] <Keybuk> he's trying to match the interface
[15:42] <tolonuga> ATTR{idVendor}=="0529", ATTR{idProduct}=="050c", RUN+="/openct_usb /dev/$parent"
[15:42] <Keybuk> tolonuga: right, if you just match the device, you don't need the interface stuff or $parent ;)
[15:42] <Keybuk> because you can match it directly
[15:42] <tolonuga> for example is for a device without "b" as interfaceclass
[15:42] <Keybuk> tolonuga: yes, but that only matches the device, not the interface
[15:42] <Keybuk> the interface devices may not exist when that happens
[15:43] <tolonuga> then the usb device file name is in $DEVNAME? or in which environment variable?
[15:43] <soren> Just add a "sleep 2"
[15:43]  * soren runs away
[15:43] <Keybuk> soren: actually, udev will block for the completion of the RUN rule before even processing the interfaces
[15:43] <Keybuk> so that really won't help
[15:43] <Keybuk> tolonuga: $name :)
[15:44] <Keybuk> though it's often better form to use %N (temporary device node with the same major/minor)
[15:44] <soren> Write a wrapper script that goes into the background, sleeps for a couple of seconds and then runs the other command. :)
[15:44]  * soren runs away some more
[15:45] <pitti> ah, *headdesk*
[15:45] <tolonuga> Keybuk: temporary might be a problem, since the script runs app A, which has a look at the device and then runs app B, so it still needs to exist then...
[15:49] <tolonuga> the best place to put scripts to be run by udev is still /lib/udev/somename ? or some other place?
[15:52] <pitti> tolonuga: so, Keybuk and I think that your first rule should work with sth. like ATTR{bInterfaceClass}=="0b", ATTRS{idVendor}=="?*", RUN+="foo /dev/$parent"
[15:52] <pitti> the vendor/product ones as above
[15:54] <tolonuga> do I need the vendor if I don't care about it?
[15:54] <pitti> tolonuga: the ?* means "nonempty"
[15:54] <pitti> tolonuga: i. e. it means "select the first parent device which has any vendor ID
[15:54] <pitti> which should be the usb_device
[15:55] <tolonuga> my first two rules are:
[15:55] <pitti> . o O { sometimes I wish there was an ENVS{DEVTYPE}=="usb_device" ... }
[15:55] <tolonuga> SUBSYSTEM!="usb", GOTO="openct_usb_rules_end"
[15:55] <tolonuga> ACTION!="add", GOTO="openct_usb_rules_end"
[15:55] <tolonuga> so I should be clean of non-usb devices. but if you suggest to match the vendor anyway, I can add that.
[15:55] <Keybuk> pitti: that'll match just abotu every usb device with a comms port ;)
[15:55] <Keybuk> which is pessimal
[15:56] <tolonuga> does it hurt to also match ATTR{bInterfaceSubClass}=="00", ATTR{bInterfaceProtocol}=="00" ? (I do that, as I only support that revision)
[15:56] <pitti> well, with teh subclalss/interface protocol, of course
[15:56] <pitti> tolonuga: no, you should do that; I was only sketching the form
[15:56] <pitti> I don't know if that's tight enough to only select devices you can handle
[15:57] <tolonuga> and I have as first test: ENV{DEVTYPE}=="usb_interface", - keep or remove?
[15:57] <pitti> I think it's redudant, but harmless
[15:57] <tolonuga> ok, thanks.
[15:58] <cjwatson> dijmen: I don't know how vbox's guest extensions work, I'm afraid; I only use kvm
[16:00] <dijmen> cjwatson: but from what you know about the way kms works, it's most likely that they can't just enable it on the next reboot, or this is what you implied, right?
[16:01] <cjwatson> dijmen: KMS is a major piece of engineering; it requires significant kernel support, not just a switch. I have no information on whether vbox guests support it
[16:03] <dmart> Hi; can anyone tell me which package gcc's debug symbols are in?  I've tried searching for gcc{,-4.4}.*dbg, but didn't find anything (I do have a suitable ddebs.ubuntu.com entry in my sources list)
[16:03] <primes2h> pitti: Hello, when you have time, could you have a look at this bug #441835 please? It should be a permission issue and it should be addressed to Karmic and Lucid too
[16:04] <primes2h> https://bugs.launchpad.net/ubuntu/+source/devicekit-disks/+bug/441835
[16:05] <pitti> primes2h: I'll have a look later
[16:05] <primes2h> pitti: ok, thank you very much. :)
[16:06] <pitti> primes2h: I can't promise an easy solution; my last floppy went out of the house many years ago, and my neighbor/parents/in-laws don't have one either
[16:06] <pitti> so I'll need some more debugging info
[16:06] <pitti> primes2h: do you have one?
[16:07] <primes2h> pitti: yes, ask me whatever you want.
[16:07] <primes2h> and you need
[16:10] <primes2h> pitti: I have some pcs with a floppy device so I can help in debugging.
[16:15] <pitti> primes2h: whatever you want> great! so what is the meaning of live, the universe, and everything?
[16:15] <pitti> j/k
[16:15] <pitti> primes2h: I followed up to the bug, let's keep the discussion there; I'm subscribed now
[16:15] <primes2h> pitti: :D not that "whatever you want" ;)
[16:16] <primes2h> pitti: ok
[16:17]  * primes2h don't have supernatural powers yet ;)
[16:17] <pitti> 42!
[16:17] <primes2h> but he's working on it
[16:18] <pitti> (well, it's not actually the answer, but that's now opening a greater philosophical debate about the hitchhiker)
[16:20] <primes2h> pitti: lol
[16:40] <tormod> pitti, can you please take a look at the debdiff in bug 478874?
[16:40] <jpds> /3/33
[17:01] <mpt> robbiew, ok, I'll review them with mvo tomorrow.
[17:01] <robbiew> thanks a lot!
[17:02] <mvo> Riddell: did plasma/framesvg.h change location? compiz ftbfs currently
[17:02] <mvo> Riddell: or kwin? kdecoration.h and friends?
[17:03] <Tm_T> mvo: in which version?
[17:04] <mvo> Tm_T: lucid
[17:06] <Tm_T> mvo: hmm, I cannot tell any change in paths, but perhaps I'm not best one to tell
[17:06] <ScottK> mvo: There was a binary incompatible change between Qt 4.6 beta and RC1.  We're in the middle of rebuilding all the affected packages.  Without looking at details, I'd be suprised if anything built that uses kdebase-workspace stuff right now.
[17:06] <ScottK> If that from kdelibs, then it should be rebuilt.
[17:07] <ScottK> I don't recall which that bit is in.
[17:07] <mvo> ScottK: ok, thanks. so I just wait a bit and rebuild?
[17:07] <Tm_T> ScottK: kdelibs both
[17:08] <Tm_T> ScottK: mvo: no, kdecoration.h and friends are in kdebase (:
[17:08] <ScottK> mvo: Since it's kdelibs, it should be done (as of a couple of hours ago).  If you didnt' try recently, I'd retry.
[17:09] <mvo> thanks, I will try that
[17:09]  * mvo queues rebuild and goes for dinner in the meantime
[17:10] <pitti> tormod: hm, the original problem was that the firmware files are shipped in the wrong directory, wasn't it? how does that patch help then?
[17:10] <pitti> shouldn't the package just move the fw bits then?
[17:25]  * Keybuk does his first package update using bzr and pbuilder
[17:25] <Keybuk> if I upload using dput, then I have finally changed all of my ways from my Debian days ;)
[17:26] <maco> do you normally ftp your files?
[17:26] <ogra> what did you use in debian ?
[17:26] <Keybuk> dupload
[17:26] <ogra> dupload ?
[17:26] <ogra> ah :)
[17:26]  * Keybuk iz old skool
[17:27] <ogra> morsing ones and zeroes eh to the internet ? :)
[17:27]  * cjwatson still uses dupload, and doesn't see a reason to change :)
[17:27] <tormod> pitti, no the files are shipped in the right place for linux-wlan-ng, the original description is a bit misleading
[17:27] <Keybuk> cjwatson: yes, you you'd still use dselect if you could <g>
[17:28] <cjwatson> well, yeah :) but dput was really just "rewrite in python because the author hated perl", it's not like it adds much
[17:28] <Keybuk> discovering dput ppa:... was a big win ;)
[17:28] <tormod> pitti, moving the files would be a workaround
[17:29] <Keybuk> "you mean I don't have to edit .dupload.conf each time I add a new PPA?"
[17:30] <Keybuk> ogra: is there any way to make pbuilder not need sudo all the time?
[17:31] <ogra> i dont think so
[17:31] <maco> cant chroot without it, can ya?
[17:31] <ogra> it uses system dirs for most of its stuff
[17:31] <ogra> right and it chroots
[17:31] <maco> maybe could put your user as NOPASSWD in sudoers for chroot, but that sounds.... :-/
[17:31] <Keybuk> sudo keeps eating my ARCH=i386 ;)
[17:31] <superm1> Keybuk, woah, that works?  (dput ppa:...).  i've been editing dput.cf every time....
[17:32] <Keybuk> superm1: yeah, dput ppa:ubuntu-boot/staging ... dput ppa:scott/ppa ... it's all automatic
[17:32] <superm1> i need to figure out what release that started working.  that can simplify some of logic on an automated build box
[17:34] <superm1> looks like jaunty according to debian/changelog
[17:34] <Keybuk> jamesh: there should be a bzr pbd that's like bd but implies pbuilder ;)
[17:48] <cjwatson> Keybuk: perfectly possible to do that in dupload, I'll have you know. :)
[17:49] <cjwatson> it's the kind of thing where if you already have it you might as well leave it there
[17:50] <cjwatson> (if anyone's curious, you start off .dupload.conf like this: http://paste.ubuntu.com/327847/)
[17:53] <Daviey> superm1: fancy backporting dput? :)
[17:53] <Daviey> we are running hardy.
[17:55] <superm1> Daviey, well from reading debian/changelog and looking, it's just changes to dput.cf that enable this stuff
[17:55] <ebroder> Daviey: My build machine is Hardy, too. You can put http://paste.ubuntu.com/327854/ in your ~/.dput.cf
[17:55] <superm1> we can probably just put it in our dput.cf that we override anyway, and that should do the trick
[17:55] <superm1> or what he said :)
[17:57] <Daviey> superm1: eww, i forgot how ugly our dput.cf was.
[17:58] <superm1> yeah so this would be much prettier
[17:58] <superm1> and not need touching every time there is a new upstream release
[17:58] <Daviey> thanks ebroder
[18:05] <cody-somerville> cjwatson, Keybuk: Is there plans for xubuntu-dev to be setup with upload permissions like kubuntu-dev and mythubuntu-dev?
[18:07] <cjwatson> ultimately, yes, we've just not got round to you guys yet :)
[18:07] <Keybuk> cody-somerville: you basically need to have something like https://wiki.ubuntu.com/Kubuntu/KubuntuDevelopers approved by the TB
[18:07] <Keybuk> in parallel with sorting out the Xubuntu seed (which hasn't happened yet), if your team decided on your policies, that would speed up the process slightly
[18:11]  * cody-somerville nods.
[18:12] <tormod> pitti, I updated the description in 478874 to explain the whole situation better.
[18:14] <pitti> tormod: hm, I don't understand -- why shouldn't the normal kernel mechanism load the firmware?
[18:14] <tormod> pitti, because it is WIP
[18:14] <pitti> so it wouldn't work in the karmic package?
[18:15] <tormod> pitti, I hope to use it for lucid, but for Karmic it would be better to do it the old way
[18:15] <pitti> okay
[18:16] <tormod> pitti, it would have been a 2.6.31-only solution
[18:17] <tormod> pitti, even with the kernel mechanism working, we would like to have l-w-n working for those non-usb devices
[18:29] <Keybuk> Undefined subroutine &Getopt::Long::GetOptionsFromArray called at /home/scott/tmp/debhelper-7.4.3ubuntu2/Debian/Debhelper/Dh_Getopt.pm line 79.
[18:29] <Keybuk> huh
[18:29] <Keybuk> where do I get that from?
[18:32]  * Keybuk backports perl too
[18:33] <Keybuk> How Hard Could It Be?
[18:33]  * Keybuk wonders how anyone survives running an LTS on production machines
[18:33] <Keybuk> it's soooo out of date :'(
[18:33] <\sh> Keybuk, don't play with the devil...use only software from the LTS repos ;)
[18:34] <Keybuk> \sh: but I want the newer bootchart <g>
[18:34] <Keybuk> which means I need newer debhelper
[18:34] <\sh> Keybuk, so play with the devil ;)
[18:34] <Keybuk> which means I need newer Perl
[18:34] <\sh> Keybuk, typical developer ;) always wanting new stuff ;)
[18:34] <Keybuk> I'm sure this will break something else
[18:34] <Keybuk> really, this box is LTS with everything I care about backported from karmic ;)
[18:34] <Keybuk> so basically karmic
[18:35]  * Keybuk adds the lucid python-cairo into the mix
[18:37]  * sebner proposes to use lucid to Keybuk :P
[18:38] <Keybuk> sebner: but it's a server! :p
[18:38] <sebner> Keybuk: does this change anything? I'd say no :P
[18:39] <\sh> Keybuk, pfff ;)
[19:03] <Keybuk> huh
[19:03] <Keybuk> now I can't make python-support work
[19:10] <Keybuk> \o/
[19:10] <Keybuk> right, that's all that forced in ;p
[19:10] <Keybuk> seb128_: that's me moved over to Python bootcharts too
[19:10] <Keybuk> so I guess we should just kill the java one
[19:10] <Keybuk> seeing as it doesn't work anyway
[19:11] <tormod> what emits(?) tty-device-added?
[19:12] <Keybuk> upstart-udev-bridge
[19:14] <tormod> Keybuk, thanks, I was looking through all .conf files but any program can initctl emit anything all the time I guess?
[19:14] <Keybuk> correct
[19:15] <tormod> so there is no directory of possible emit sources, I have to strings|grep the exectables?
[19:15] <Keybuk> right
[19:15] <Keybuk> application authors are "encouraged" to use the "emits" stanza
[19:16] <tormod> I just started to look at upstart, because I want to make sure gdm is started _after_ radeon is loaded for KMS
[19:16] <Keybuk> e.g. /etc/init/mountall.conf
[19:16] <Keybuk> tormod: radeon creates a graphics (drm) device
[19:16] <Keybuk> tormod: so gdm already has that
[19:16] <tormod> hmm
[19:17] <Keybuk> (otherwise this wouldn't work on Intel - and it definitely works there :p)
[19:17] <tormod> so the emits stanzas are just decoration?
[19:17] <Keybuk> yes
[19:17] <Keybuk> just documentation
[19:21] <tormod> Keybuk, how does that work for cards with no drm ?
[19:23] <tormod> anyway, more important: why does it seem like X starts before radeon is initialized here?
[19:24] <tormod> and what emits graphics-device-added? udev?
[19:32] <Keybuk> tormod: same, upstart-udev-bridge
[20:10] <tormod> Keybuk, so is the problem that upstart is starting gdm faster than the radeon module can set up its dri stuff?
[20:16] <kklimonda> Are we going to use glibc 2.11 in lucid?
[20:24] <Keybuk> tormod: the problem might be that it's assuming you don't have drm ;)
[20:25] <tormod> Keybuk, it?
[20:26] <\sh> upstart is a self maintained entity ;) just like an alien ;)
[20:26] <Keybuk> tormod: things
[20:27] <tormod> for a second I wondered if you were saying there is a bug in u pstart
[20:28] <Keybuk> no, shouldn't think so
[20:28] <Keybuk> the problem is that we have to support starting X with a drm device
[20:29] <Keybuk> and starting X without one
[20:29] <Keybuk> maybe something odd about the radeon driver means it returns from module init/init_one before actually creating the device?
[20:29] <Keybuk> so udevadm settle finishes, so gdm starts
[20:29] <Keybuk> without waiting for the drm device
[20:30] <Keybuk> (the gdm job waits for the first of drm and udevadm finishing)
[20:30] <\sh> Keybuk, you should implement a "wait-for <signal>" func ;)
[20:31] <\sh> start on (whatever and wait-for <something else needs to be there>)
[20:31] <Keybuk> that's exactly what it does
[20:31] <Keybuk> the problem is it's waiting for one of two things ;)
[20:31] <Keybuk> and the other thing is happening
[20:31] <Keybuk> (assumedly)
[20:55] <Cheery> in ubuntu there are couple of software that's activation is joined into keyboard combos.
[20:56] <Cheery> I have a thought about character sheet that starts when I press the SUPER -button.
[20:56] <Cheery> and stays as long as SUPER -button is pressed down.
[20:57] <Cheery> then, when I press any other key while keeping SUPER-button down, I'd like to get characters from that sheet.
[20:57] <dtchen> ogra: 0.9.21 hasn't been uploaded yet. Luke was awaiting the armel FTBFS fix before uploading, but I guess you beat him to it?
[20:58] <\sh> T-2m until I shutdown the internet...oh well, only our internet @company
[20:58] <Cheery> I'd like to implement such device, any guidance that'd avoid me the maximum trouble?
[20:59] <Cheery> (ultimately there already exists such software I'm about to implement, though I'd feel good about writing it myself if it doesn't exist)
[21:02] <TheMuso> asac, ogra, lp:~ubuntu-core-dev/pulseaudio/ubuntu
[21:04] <seb128> hey TheMuso
[21:05] <Cheery> it was sort of a pie in the sky anyway that anybody would answer my question.
[21:05] <Cheery> during the short time I bothered to wait for it.
[21:06] <TheMuso> Hey seb128.
[21:06] <Cheery> darn if I'd even know what are those things called in gnome.
[21:07] <Cheery> stuff that starts from shortcuts and floats on top of anything running, even opengl apps.
[21:07] <Cheery> and then causes stuff like workspace/active window change or virtual input of characters.
[21:11] <Cheery> well, another example would be XF86AudioRaiseVolume
[21:12] <Cheery> of such program I'd like to come up with.
[21:12] <Cheery> for looking documentation on those feels quite tricky because I don't know what is those sort of software called.
[21:13] <Cheery> erm. oops.
[21:13] <Cheery> that's a keysym.
[21:18] <Cheery> gah, I'm getting sleep, obviously some answers later, memo me or something if you still bother.
[21:18] <Cheery> gn
[21:46] <Keybuk> ok
[21:47] <Keybuk> I really prefer the python bootchart now
[21:47]  * Keybuk finishes hacking useful things into it <g>
[23:29] <chelz> kirkland: in the Ubuntu Manpage Repository "locate(1)" is missing from all but dapper: http://manpages.ubuntu.com/cgi-bin/search.py?q=locate
[23:43] <Keybuk>                               
[23:43] <Keybuk> quest pybootchartgui% bzr mark-uploaded
[23:43] <Keybuk> bzr: ERROR: Unknown target distribution: lucid
[23:43] <Keybuk> ...
[23:43] <Keybuk> huh
[23:44] <Keybuk> jamesh: ! :)
[23:44] <Keybuk> err, wrong james ;)
[23:44] <lifeless> Keybuk: could you file that on bzr-builddeb
[23:44] <lifeless> also, we should make sure that 'debrelease' does mark-uploaded for us.
[23:44] <Keybuk> lifeless: I suspect it knows in lucid
[23:44] <Keybuk> the karmic version doesn't
[23:48] <lifeless> Keybuk: trunk does.
[23:49] <lifeless> Keybuk: still, we should publish a version of it in e.g. bzr PPA with lucid support for karmic.
[23:49] <Keybuk> yeah
[23:49] <Keybuk> want a bug to remind you?
[23:51] <lifeless> please
[23:52] <Keybuk> seems to be bug #476530 already
[23:52] <lifeless> k
[23:53] <Keybuk> http://people.canonical.com/~scott/daily-bootcharts/20091120-max.png
[23:53] <Keybuk> yay
[23:54] <Keybuk> cropped and annotated charts ;-)
[23:54] <ion> Nice
[23:55] <Keybuk> it's not 100% accurate
[23:55] <Keybuk> it looks for the first point at which the load is < 25%
[23:55] <Keybuk> and the average load for the next three seconds is < 25%
[23:56] <Keybuk> so if there's a bit of a blip, it can miss it
[23:56] <Keybuk> but it's good enough