=== Richie is now known as WelshDragon [00:34] cjwatson: okay, no worries; changes reverted, uploaded again [00:49] dtchen: I am awaiting a fix for the ARM FTBFs for pulseaudi obefore I upload it. [00:49] gah typing [00:52] TheMuso: hmm, should pull in http://git.debian.org/?p=pkg-pulseaudio/pulseaudio.git;a=commitdiff;h=f188f05eebcc5c28a5c3d98a35872c2e6c5d625c too [00:53] dtchen: I'm aware of that, but I was asked to drop the arm stuff from debian/rules completely. [00:53] TheMuso: right, didn't know what the plan was for ARM [00:53] 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] 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] that is simple terms I'm sure, but I just want the general idea [00:59] chuckf: approximately, yes - http://wiki.ubuntu.com/NewReleaseCycleProcess for the gory details [00:59] I'll go read a bit, thanks cjwatson === dendrobates is now known as dendro-afk [01:26] 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] 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] is there a "mega-package" of all the dependencies for building gnome projects? [01:29] meanburrito920_: try gnome-core-devel [01:29] meanburrito920_: what are you trying to build? try "apt-get build-dep gnome-terminal", for example. [01:29] probably more than you need, but [01:30] I'm trying to build gedit [01:30] 'apt-get build-dep gedit', then :) [01:30] yes ;) [01:30] cjwatson: wow, thats a lot of packages :) [01:30] works for anything that's already packaged in Ubuntu [01:31] 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] thanks! === dendro-afk is now known as dendrobates === micahg1 is now known as micahg === dendrobates is now known as dendro-afk [03:00] Hmm... I think this boot parallelism has been taken a shade too far [03:00] My GDM just started despite fscks still being ongoing [03:00] .... including the volume containing my homedir === baytes-vm is now known as baytes-vm|sleep === jono_ is now known as jono [04:38] lifeless: bah. right [04:38] * lamont puts a pasteit on the monitor [04:59] didrocks, ping? === vorian_ is now known as vorian [06:46] jono: pong [06:48] didrocks, hey [06:48] didrocks, http://www.jonobacon.org/2009/11/25/introducing-lernid/ :-) [06:48] Quickly made this much easier :) [06:49] jono: oh, sweet! [06:49] quickly is rocking my world :) [06:49] jono: thanks for the notice ;) [06:50] jono: nice [06:50] jono: there's an IRC component? [06:50] do not hesitate to open a bug on any whishlist/request you have [06:50] lifeless, it uses webchat.freenode.net [06:50] thanks didrocks [06:50] lifeless, although an embedded IRC widget would be nice [06:51] 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] but linking with telepathy framework can be nice :) [06:55] I really think that tool can be very handy, good opportunities to contribute there, it rocks jono! [06:55] didrocks, thanks pal :) [06:55] I wanted to get it out so we can start refining it ready for Ubuntu Developer Week [06:56] right, still some week remaining to polish it [06:57] yeah :) [06:57] it also means we can file bugs and accept patches :) [06:57] so thanks again didrocks, Quickly awesome :) [06:57] thanks to you for you rocking work :) [06:58] I also wrote https://edge.launchpad.net/flarebook in Quickly but havent had time to push a PPA yet [06:58] need to fix some last remaining bugs [06:58] :) [06:58] I really promis GPG key setup will be easier in 0.4 :) [07:00] jono: that looks good :) [07:00] didrocks, hehe, sounds good :) [07:01] 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] ajmitch, thanks! [07:01] spm, lol! [07:15] Good morning [07:16] hi pitti [07:16] hey ajmitch, how are you? [07:17] good, how are you? recovered from UDS? [07:17] yes, I did; and I skipped the Ubuflu this time \o/ [07:17] yay! [08:01] good morning === dholbach_ is now known as dholbach [09:30] morning dholbach [09:30] hi directhex [09:30] 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] directhex: were you asking me specifically? because I wasn't at that session :) [09:32] dholbach, more seb128 or pitti i think [09:32] alright [09:32] directhex, yes, that change is following the uds discussion [09:32] directhex: pretty much, yes [09:33] directhex, we talked with upstream about the changes we need there... [09:33] seb128, ah, cool. wasn't sure how much interaction you have w/ stephane [09:42] 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] pitti: sounds good to me, its short, but the task it needs to do is short as well :) [09:44] mvo: exactly; main purpose of this is to track progress === Tonio__ is now known as Tonio_ [09:57] pitti, I have a question regarding autosyncing! [09:57] !ask | LucidFox [09:57] LucidFox: Please don't ask to ask a question, simply ask the question (all on ONE line and in the channel, so that others can read and follow it easily). If anyone knows the answer they will most likely reply. :-) [09:57] 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] LucidFox: I guess none of the archive admins got to it yet [09:58] LucidFox: let me start an auto-import run [09:58] yep, they are in new-source [09:59] I did an new-source run at UDS, I guess they dropped to testing after that [10:00] yay 3.0 packages [10:00] Ah ha [10:00] No, before UDS. [10:00] If they're 3.0, you can't have them yet [10:00] Hmm, they aren't using the 3.0 quilt format. [10:01] It can still be 3.0 even if it has diff.gz? [10:01] * StevenK looks [10:01] LucidFox: no, not those particular two [10:01] there are just others in the list which are [10:01] ah [10:23] LucidFox: E: x11vnc is trying to override x11vnc_0.9.3.dfsg.1-1ubuntu2 without -f/--force. [10:23] LucidFox: apparenty it moved to a new source package? [10:24] 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] [BIOS]dnivra: best to just ask your question [10:27] 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] create it [10:29] <[BIOS]dnivra> there's nothing wrong with pbuilder installation is there? [10:30] installing a package never creates files in your home directory [10:30] <[BIOS]dnivra> well gnupg did [10:30] no, it didn't [10:30] running the program gpg did [10:30] installing the package gnupg did not [10:30] important distinction :) [10:30] <[BIOS]dnivra> i didn't run it! [10:30] <[BIOS]dnivra> just installed it [10:30] something did, even if it was not you explicitly [10:31] <[BIOS]dnivra> right [10:31] 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] 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] 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] [BIOS]dnivra: it needs to be 600 (-rw-------) [10:56] and ~/.gnupg/ should be 700 (drwx------) [10:56] <[BIOS]dnivra> tsimpson: ok [11:00] it's fine for gpg.conf itself to be mode 644, as long as the containing directory's permissions are tight [11:00] also your home directory needs to not be group- or world-writable [11:01] will there be a lucid release for sparc? perhaps lucid-server only? [11:03] same as usual for ports, we'll release whatever CDs work although they won't be supported [11:03] (by Canonical anyway) [11:04] doing sync is no fun nowadays [11:05] there is a zillion of v3 sources now [11:05] need to edit the list and run sync-source a zillion times [11:05] hm. I hoped that canonical would intend to continue the sparc port. so hardy was the last canonical supported release :-( [11:05] seb128: are you doing ftp-master work right now? could you perhaps cleanup the emacs section confusion? (emacs22 -> universe, emacs23 -> main) [11:06] 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] siretart`: we announced this some time ago [11:07] cjwatson: ok, seems I've missed it. thanks [11:08] 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] siretart`: indeed, 8.04 was not supported on sparc either. https://lists.ubuntu.com/archives/ubuntu-devel-announce/2008-March/000400.html [11:08] seb128: I consider it as a 'normal' upstream version upgrade, only that the name of the source package changed [11:09] siretart': still it needs something to pull it in main, it's not archive side only [11:09] either a seed or a depends [11:09] oh, I see. I'll check that [11:16] seb128: okay, I've updated the seeds in bzr now. anything else I need to do? [11:46] seb128: Why are you blacklisting v3 sources? They shouldn't crash sync-source any more -- they should just be rejected harmlessly later. [11:46] "I: imvirt [universe] -> imvirt_0.3.1-1 [universe]. [11:46] * command was 'dpkg-source -sn -x /home/lp_archive/syncs/imvirt_0.3.1+svn426-1.dsc' [11:46] [dpkg-source output:] dpkg-source: error: Unsupported format of .dsc file (3.0 (quilt)) [11:46] E: 'dpkg-source -x' failed for /home/lp_archive/syncs/imvirt_0.3.1+svn426-1.dsc [return code: 2304]. [11:46] " [11:46] wgrant, I keep running into those [11:46] Oh. [11:46] and sync-source -a stops [11:47] any better way? [11:47] That's because of cocoplum's old dpkg, not lack of LP support :( [11:47] Damn. [11:49] cjwatson, elmo: ^ do you know if that's something being worked? [11:50] Sorry, I completely forgot that sync-source unpacked the source beforehand, so didn't work around that as well. [11:51] wgrant, nothing to be sorry about, thanks for the work you do ;-) [12:00] seb128: yes, there's an RT ticket and stuff [12:10] 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] dtchen, talking about pulse indeed :) [12:12] cjwatson, ok thanks [12:16] 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] 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] mvo: no we dropped that in karmic, kwin's detections seems to work fine on its own [12:29] go go go mvo! [12:30] are grub2 vga/gfxpayload supposed to not work with karmic under no-guestadditions vbox? [12:37] dijmen: doesn't work particularly well period [12:38] 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] Riddell: great, thanks [12:38] seb128: heh :) [12:38] cjwatson: is it grub2 only? [12:38] 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] dijmen: yes [12:42] cjwatson: but I tried vga=792 too. doesn't this mean it's not a gfxpayload issue? === jamie is now known as Guest27292 [12:43] seb128: tea! [12:43] dijmen: it's complicated :) [12:44] dijmen: grub2 uses Linux' 32-bit boot protocol, which works differently [12:44] 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] dijmen: vga= doesn't fit all that well with KMS, though, in my understanding, so it probably has a pretty finite lifetime anyway === MacSlow is now known as MacSlow|lunch [12:53] cjwatson: thank you [13:03] Who can tell me what's up with the rt61pci driver. Since Koala my wifi isn't working any more. [13:05] "Gwibber is shipping by default in Lucid. Let’s help it make a great first impression." [13:06] So let me get this straight... They're removing GIMP, yet introducing this ridiculously specific application? [13:08] Well GIMP is a pretty specific application too. [13:08] LucidFox: you won't have to use lucid [13:09] I'd say image editing is probably a function more demanded by the average user than microblogging. [13:09] How many % of Ubuntu users are going to use microblogging at all, let alone a desktop client for it? [13:12] 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] 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] I'm not putting them in direct opposition. :) [13:13] I think you did, above [13:13] 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] at least it really did come across that way [13:14] 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] LucidFox: "So let me get this straight... They're removing GIMP, yet introducing this ridiculously specific application?" [13:15] not least because of its size [13:15] I'm not 100% happy with it, but it doesn't seem a totally unreasonable decision either [13:15] f-spot can do basic photo editing ... [13:16] and there's time to get f-spot better [13:16] LucidFox: given a good usefulness/size ratio, any feature could and should make it in the default installation [13:18] 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] cjwatson: does it look like these gfxpayload issues will be fixed any time soon? [13:19] dijmen: no [13:19] dijmen: I wouldn't bother with gfxpayload if I were you [13:19] at least not for a while [13:19] cjwatson: what should I do instead? I love a high-resolution tty! [13:20] 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] dijmen: use a graphics card for which KMS is supported, or else use vga= with linux16/initrd16 [13:20] cjwatson: how do I force linux16/initrd16? [13:20] where KMS is supported, you already get a high-resolution tty out of the box [13:20] you'd have to edit /etc/grub.d/10_linux I think [13:21] cjwatson: some text search pattern tip inside 10_linux? [13:21] it's not that long. Sorry I'm not going to have time to walk you through it step by step :( [13:22] thank you anyway (actually I was just asking for a relevant word) [13:24] dijmen: "linux" is accurate but might be considered to be unhelpful ... [13:24] :) [13:25] By the way, why doesn't Ubuntu include an IRC client by default but Kubuntu does? [13:26] LucidFox: It does, it's just hiding. [13:26] Empathy? [13:26] LucidFox: Yup [13:26] Its IRC support is even less intuitive than Pidgin's, I think. [13:26] StevenK: then kubuntu has two [13:27] Kopete also technically has IRC support, yet Kubuntu still ships Quassel separately. [13:27] LucidFox: that's exactly what I meant [13:28] kopete doesn't have irc now [13:28] Not since KDE3 times. [13:28] Riddell: just add an account [13:29] 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] oh, dijmen is here too [13:42] Tm_T: yeah, I'm trying to offer some help [13:45] dijmen: I know (: [13:45] dijmen: Kopete doesn't have IRC-protocol supported currently because noone is working on it, it's broken [13:46] dijmen: thus, Kubuntu has only one client [13:50] ping persia === tkamppeter_ is now known as tkamppeter === chuck_ is now known as zul [14:02] free: hi - re bug 484861 - could you update the test case to have more detailed steps? [14:02] Launchpad bug 484861 in smart "Smart doesn't import proxy information from Landscape" [Medium,Fix committed] https://launchpad.net/bugs/484861 === MacSlow|lunch is now known as MacSlow === robbiew_ is now known as robbiew === korn_ is now known as c_korn [14:56] mutt [14:56] err.. [14:57] 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] hal is still in the archive. What's openct? [14:59] tolonuga: http://wiki.ubuntu.com/Halsectomy [14:59] and indeed, hal is actually still installed by default [15:00] and it's still installed by default, because at least xserver-xorg needs it [15:00] I hope this isn't argument by rumour :) [15:01] soren: http://www.opensc-project.org/openct/ [15:02] I'm puzzled that our openct packages don't depend on hal, if they need it [15:02] cjwatson: once I install the kms module, how do I enable it in grub2? [15:02] azteech: Ah, opensc I know about :) [15:03] dijmen: um [15:03] :) [15:03] 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] dijmen: kms isn't a module, and it has no direct support in grub2. Can you reformulate your question? [15:03] it might have been broken before [15:03] (not that it makes things better) [15:04] 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] if your system doesn't already support KMS, you are unlikely to have much luck trying to plumb it in yourself! [15:05] cjwatson: so are you sure installing vbox's guest additions won't add KMS support? [15:06] 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] 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] 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] 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] tolonuga: udev can't forget [15:11] the device name is basically the only thing that the kernel *tells* udev [15:13] 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] interface without device) [15:14] tolonuga: just about everything you said there is wrong [15:14] perhaps you should say what the problem you're having is [15:14] and I'll try to help [15:16] 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] something like [15:18] 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] How do I change my launchpad username in bazzar? [15:18] so now it is funny ubuntu promotes udev instead of hal (if I understand things right) [15:19] SUBSYSTEM=="usb", ATTR{bInterfaceClass}=="b", ATTRS{idProduct}=="xxxx", ATTRS{idVendor}=="yyyy" [15:19] ^ that should match your device's interface [15:19] worth trying [15:19] tolonuga: when did you ask? the plumbing layer has been undergoing rapid development over the last few years [15:19] HAL is entirely deprecated now, and expected to go away completely within the next year [15:20] well 2-3 years ago they started to push us from udev to hal. [15:20] there you go [15:20] 2-3 years ago is practically a different world as far as this stuff is concerned ;) [15:20] 2-3 years before that we didn't even *have* hotplug [15:20] 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] pitti: implied by checking for bInterfaceClass ;-) [15:21] not true, I did usb hotplugging with /sbin/hotplug interface in 2001. [15:21] nice [15:21] tolonuga: I don't remember it being around back then ;) [15:21] I remember hotplug being new and shiny when we did warty [15:21] * soren chuckles [15:21] and being one of the first distros to actually use this stuff [15:21] lol those were the days [15:21] Yeah. Good times. [15:22] :) [15:22] but we could argue about that, or I could help you fix your problem :) [15:22] I'm easy either way [15:22] and no longer mounting devfs... [15:22] I didn't know we had that many historians here :-) [15:22] * pitti sheds a tear for pmount [15:22] pitti: Ubuntu contributes upstream product, Fedora rewrites it instead of adopting it? [15:22] what about rules like KERNEL=="[0-9]*:*", WAIT_FOR_SYSFS="bInterfaceProtocol" -- still needed? that was for some race protection in udev. [15:23] tolonuga: god no [15:23] that was kernel race protection [15:23] we fix those in the kernel now [15:23] should I simply cross fingers, remove all the old cruft, and hope for fixes in udev/kernel. [15:23] tolonuga: if you're using karmic, you don't need any of that [15:23] so first [15:23] SUBSYSTEM=="usb", ATTR{bInterfaceClass}=="b", ATTRS{idProduct}=="xxxx", ATTRS{idVendor}=="yyyy" [15:23] does that match your device? [15:23] RUN+="/usr/bin/touch /tmp/foo" is a good trick [15:24] I have that rule (see the link I mentioned), and it works - except for the races we sometimes had under load. [15:24] ok [15:24] and does $name expand to the /dev/bus/usb name of the interface? [15:24] does ubuntu tell me the device file name?in which variable? [15:24] (if you have that rule) [15:24] tolonuga: $parent oddly enough [15:24] normal is USB_DEVICEFS [15:24] 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] the ATTRS bit causes a parent match [15:25] so fills the parent device node name into $parent [15:25] or DEVNAME [15:25] I can also guess it with "udevinfo" or "udevadm info" [15:25] tolonuga: or you could listen ;) [15:26] ENV{DEVTYPE}=="usb_interface", SYSFS{bInterfaceClass}=="0b", SYSFS{bInterfaceSubClass}=="00", SYSFS{bInterfaceProtocol}=="00" RUN+="@udevdir@/openct_usb" [15:26] is ok? [15:26] no none of that [15:26] that's not what I said at all [15:26] see [15:26] mpt: need them this week..have to review Lucid items with mark next week [15:27] 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] tolonuga: how about you just do what I said? [15:28] since I am the Ubuntu udev maintainer [15:28] and an upstream maintainer [15:28] so I know a _little_ bit about this stuff ;) [15:28] so the rule I gave you is probably "correct" [15:28] 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] (modulo some tweeking) [15:28] ah, great to find the man in charge, super! [15:29] tolonuga: all major distributions instead of Debian have the same udev stuff [15:29] except Debian, I mean [15:29] ah,ok. that wasn't always the case I remember :( [15:29] can you have a short look at http://www.opensc-project.org/svn/openct/trunk/etc/openct.udev.in [15:30] tolonuga: that file is for an ancient version of udev [15:30] 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] no, it won't work [15:30] did udev stay compatible? or do I rewrite it? [15:30] it'll parse that file still [15:30] for now [15:30] but it won't work how you want [15:30] the new rules are much better [15:31] "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] pitti: Marco still refuses to adopt the same rules directory as everyone else [15:32] tolonuga: almost certainly massively out of date [15:33] 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] that's one approach yeah [15:34] SUBSYSTEM=="usb", ATTR{bInterfaceClass}=="0b", ATTRS{idVendor}=="0b97", ATTRS{idProduct}=="7762", RUN+="/bin/echo /dev/$parent" [15:34] I just used that rule on a random usb device I have here [15:34] udevadm test on the interface gives me [15:34] udevadm_test: run: '/bin/echo /dev/bus/usb/002/005' [15:34] which is, I think, what you want? [15:34] the "S" on the end of ATTRS is the important bit here [15:35] match rules without an "S" match the exact kernel object [15:35] 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] so in that case, we're matching a kernel object in the "usb" subsystem with a bInterfaceClass attribute of "0b" [15:35] ACTION="add" is still there? [15:35] pitti: no, it won't [15:35] pitti: that's the entire point I'm trying to convey here, you _can't_ split these rules [15:35] tolonuga: if you want to run something, yes [15:35] tolonuga: it's best to write ACTION!="add", GOTO="end" at the top of the file, as you already do [15:36] Keybuk: but that's what he's looking for? [15:36] but right, pitti's advice on the action bit works [15:36] pitti: but that's wrong [15:36] * Keybuk rewinds himself [15:36] we're matching a kernel object in the "usb" subsystem with a bInterfaceClass attribute of "0b" [15:36] pitti: yes, I have that,so was wondering if it should still work. [15:36] then once we have that match, we have two further ATTRS rules to process [15:36] Keybuk: ^ why? [15:36] or devices with different InterfaceClass (e.g. 0xff), but a certain product/vendor id. [15:36] these are special [15:36] ending with an "S" means "look up parent object" [15:37] ah, for selecting $parent [15:37] 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] but for ENV{DEVTYPE} you would use $name, not $parent? [15:37] this matches not only the device, but it's parent [15:37] pitti: ignore DEVTYPE, it's really not important [15:37] seems that I need to re-learn udev rules myself [15:38] 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] Keybuk: but here we don't know what vendor/product ID should be, if we already have the iface class? [15:38] so now we've matched an interface device, and its actual parent physical device [15:38] the /dev name of the physical device will be in $parent [15:38] mneptok: thank you! [15:38] pitti: ? [15:38] so s/SYSFS/ATTR and adding /dev/$parent to RUN+= are the changes I find. done. [15:38] tolonuga: no [15:38] the important thing is that the matches are both on the same line [15:38] Keybuk: iface class=="0b" OR vendor/product match.. [15:38] ivoks: nema na čemu! [15:38] pitti: not following still? [15:39] mneptok: hahaha [15:39] ivoks: please do not try to sort by that last word ;) [15:39] 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] pitti: why not? [15:39] mneptok: true [15:39] I looked at the same rules file as you [15:39] it's easy [15:39] 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] just convert all those SYSFS{}... lines into lines like the one I pasted [15:40] Keybuk: you don't know the vendor/product IDs [15:40] tolonuga: some distributions disable it, others don't [15:40] does ubuntu keep compiling kernel with USB_DEVICEFS? [15:40] pitti: there's a list of them in the rules file [15:40]