[00:45] <lajjr> hello pitti
[01:08] <lajjr> Hi pitti
[04:26] <ccheney> anyone know how long it takes to get from the madrid airport to the train station?
[04:27] <stgraber> depends what terminal you're at
[04:28] <ccheney> i'm not sure
[04:28] <stgraber> ^ forget that
[04:28] <stgraber> (wrong airport ;))
[04:28] <ccheney> i have to get from madrid airport to renfe to go to caceres
[04:29]  * stgraber tries to remember Madrid
[04:32] <ccheney> hmm it appears it stops at 'atocha' station will need to look for a madrid train map
[04:33] <ccheney> ah i found one :)
[04:33] <superm1> ccheney, it took us about an hour, but it really depends on what terminal you fly into because some are 20-40 minutes from the metro stop
[04:35] <ccheney> superm1: ah, fun
[04:36] <superm1> there should be about 2 transfers on the metro you gotta do too
[04:37]  * ccheney wonders if he can possibly make the train trip from caceres and the flight on the same day
[04:37] <ccheney> it sounds like it would be very tight time wise to be able to do it
[06:21] <dholbach> good morning
[06:36]  * hyperair wonders if anyone could sync nautilus-share from debian unstable
[06:38] <TheMuso> hyperair: Have you filed a bug about it?
[06:39] <dholbach> TheMuso: it's unmodified in Ubuntu
[06:48] <TheMuso> dholbach: Oh, it should automatically sync then.
[06:49] <dholbach> right-o, or when ever big sync command is run
[06:50] <TheMuso> yeah
[07:12] <pitti> Good morning
[07:13] <pitti> slangasek: hah, sounds like a good idea
[07:14] <pitti> slangasek: there is: ENV{DMI_VENDOR}=="MICRO-STAR*", RUN+="keymap $name micro-star"
[07:15] <pitti> slangasek: I agree, having udev-extras conflict sounds appropriate, since this takes over keymaps
[07:22] <superm1> pitti, next time you do an upload of udev extras can you add something like a debian/README.Debian explaining how the branch is constructed for uploads from upstream checkouts? when i was porting hid2hci over to it I was quite perplexed trying to do it from bzr as I still had to run autogen.sh and have a whole slew of extra build depends to make it work
[07:22] <pitti> hi superm1
[07:23] <superm1> good morning pitti
[07:23] <pitti> superm1: incidentally I'm just at preparing a new upload (one bug fix and upstream pull)
[07:23] <superm1> pitti, ah good to know, then i'll do an upload disabling hid2hci in bluez too
[07:24] <pitti> superm1: okay, I'll add a debian/README.source
[07:24] <superm1> thanks, most appreciated :)
[07:30] <slangasek> pitti: the micro-star map is not a complete replacement for what was in the micro-star-infinity hal-info one, AFAICS
[07:33] <pitti> slangasek: in some cases I merged entries for models which didn't collide
[07:33] <pitti> slangasek: IIRC that happened with the  INFINITY and the two special cases
[07:35] <tkamppeter> pitti, can you upload CUPS to Debian and Ubuntu ASAP, in your 1.3.9-3 release you have also deactivated pdftopdf and not only pdftoopvp.
[07:35] <pitti> tkamppeter: okay; what did that break?
[07:37] <tkamppeter> pitti, you have commented out the line in addtocups which adds pdftoopvp to the Makefile. This line also added pdftopdf. I have fixed that already in the BZR.
[07:37] <pitti> tkamppeter: right, I saw; I mean, did that break a lot?
[07:37]  * infinity wonders if he should start typing PITTI in all-caps to see if it hilights for him.
[07:38] <pitti> infinity: it doesn't :)
[07:38] <infinity> Dang.
[07:38] <pitti> I don't like to be yelled at
[07:38] <tkamppeter> pitti, it switched CUPS simply back to the old PostScript printing workflow.
[07:38] <StevenK> Haha
[07:38] <StevenK> I wonder if it's case-sensitive for my client
[07:39] <nellery> STEVENK
[07:39] <StevenK> Yeah, it does. :_)
[07:39] <tkamppeter> pitti, and I added also some patch to CUPS which should improve multiple copies printing with OOo and it should make the PDF workflow obeying optionm settings from Windows clients.
[07:40] <StevenK> pitti: Oh, you broke something in udev-extras as opposed to trying to summon infinity?
[07:41] <pitti> StevenK: yes, that was a laptop model name
[07:41] <StevenK> Ahhh
[07:41] <pitti> superm1: http://bazaar.launchpad.net/%7Eubuntu-core-dev/udev-extras/ubuntu/annotate/head%3A/debian/README.source
[07:42] <superm1> pitti, ah ha.  makes much more sense now. thanks!
[07:43] <pitti> superm1: well, it's still hideously complicated, but it avoids calling autotools at build time (which Keybuk doesn't like)
[07:43] <superm1> what's wrong with autotools at build time?
[07:43] <StevenK> superm1: Non-deterministic results
[07:43] <pitti> you upload something that you didn't actually test-built before
[07:44] <lifeless> people have different opinions
[07:44] <pitti> and they tend to break over time
[07:44] <lifeless> I prefer to build dep on autotools and avoid tar timestamp related bugs
[07:44] <lifeless> tar + patch I mean
[07:46] <superm1> well surely you still test build, and normally your sbuild/pbuilder env should be mirror the archive though.  by doing autotools at build time, the diffs between two different uploads can actually have a sane delta
[07:47] <superm1> i'd take it more of the worry is if you have to do a rebuild later and it just adds another variable for failure when you dont want it
[07:48] <infinity> Yeah.  It can leave you with unbuildable source packages.  Though, really, that would be an autotools bug, generally.
[07:48] <infinity> I'm of two minds.
[07:48] <infinity> I've historically patched .in files and run autotools at build-time.
[07:48] <infinity> But if you run them locally using the same versions as upstream, the diffs still remain small and readable.
[07:48] <pitti> infinity: autotools bug> which there are plenty of, apparently :(
[07:48] <infinity> At which point, it becomes reasonably moot.
[07:49] <infinity> pitti: In all my time doing the "patch .in, run autotools at build time" with the AMP stack, I only ran into one or two times when autotools rendered me unbuildable at a later date.
[07:49] <infinity> pitti: Then again, those packages were updated and uploaded frequently enough that they never really suffered code rot.
[07:51] <lifeless> pitti: if it randomly becomes unbuildable its straight forward enough to change styles
[07:51] <lifeless> mind you the autotool stack is broken-by-design anyway; so its hard to really care.
[07:54] <superm1> mvo, would it be feasible to add a hook to update manager querying if a kernel module is loaded while update manager is running, and if so, to mark a package for installation during the upgrade?
[07:55] <superm1> i'm thinking that would be the better transition than the currently proposed solution for bug 381684
[08:13] <mvo> superm1: adding such a hook is certainly feasible, I can add it
[08:13]  * mvo reads the bugreport
[08:15] <superm1> mvo, okay cool, more or less if you see 'wl' is loaded, install bcmwl-kernel-source
[10:10] <lifeless> pitti: how would you feel about https://launchpad.net/mnemosyne being removed/renamed in favour of https://launchpad.net/mnemosyne-proj? I haven't asked the mnemosyne devs yet, but it was certainly confusing for me to find the former when looking for the latter
[10:11] <pitti> lifeless: I don't care about this any more, it was an early-abandoned GSoC project
[10:12] <liw> a flat namespace for project names is becoming an increasingly large problem
[10:12] <lifeless> quick, claim your name
[10:12] <lifeless> or propose a hash based solution :)
[10:12] <liw> though still luckily very small (and yay for known _two_ obscure languages to pick names from :)
[10:13] <liw> lifeless, <suspicous> are you making facebook references at me?
[10:19]  * directhex claims "default.aspx" as a project name
[10:19] <lifeless> liw: would I?
[10:19] <lifeless> directhex: take con.1, that will break all asp sites :)
[10:20] <directhex> lifeless, if mono is immune to that, can i use it as an argument that microsoft is a poor platform for asp.net?
[10:20] <lifeless> http://blog.bitquabit.com/2009/06/12/zombie-operating-systems-and-aspnet-mvc/
[10:21] <directhex> lifeless, i know!
[10:21] <lifeless> I think you can yes; read the above link for a laugh.
[10:22] <directhex> jms@osc-bigmac:~/testy$ curl http://localhost:8080/con.1


ASP.NET Hello World</title>
[10:22] <directhex> winnar
[10:23] <ajmitch> as long as it's not as bad as the old blue screen whenever a windows system viewed a webpage referencing c:\con\con
[10:23] <directhex> ajmitch, awesome
[10:23] <ajmitch> directhex: so easy to put in an img tag
[10:23] <lifeless> ajmitch: score!
[10:25] <ajmitch> that bug even has its own wikipedia page
[10:26] <directhex> man, people actually used windows with bugs like that? o_o
[10:28] <AnAnt__> Hello, will nvidia 180.60-0ubuntu1 be backported to Jaunty ?
[10:28] <lifeless> is there a SRU bug open for it?
[10:29] <AnAnt__> nope, but there is a bug about instability of Jaunty's nvidia driver
[10:29]  * mvo hugs liw for the apt-sync spec
[10:29] <lifeless> apt-sync?
[10:29] <AnAnt__> LP 353502
[10:30] <lifeless> mvo: where is the PPA UI now?
[10:30] <mvo> lifeless: delta deb downloads b
[10:30] <lifeless> oh cool
[10:30] <mvo> lifeless: in software-properties
[10:31] <mvo> lifeless: just add "ppa:lifeless" there in the add dialog
[10:31] <directhex> mvo, we need a different name for them than "delta deb" though. "ddeb" is taken.
[10:31] <AnAnt__> tseliot: ping
[10:31] <mvo> lifeless: the script is not (yet) included
[10:31] <mvo> directhex: true
[10:31] <directhex> oh, i have an awesome idea
[10:31] <directhex> since we force-feed people utf-8.....
[10:31]  * ajmitch cringes
[10:31] <lifeless> mvo: is that 'software sources'?
[10:31] <wgrant> Hahaha.
[10:31] <mvo> *autsch*
[10:32] <mvo> lifeless: yes
[10:32]  * ogra wonders if there is a gree letter for "deb"
[10:32] <lifeless> mvo: so its in synaptic too?
[10:32] <ogra> *greek
[10:32] <directhex> δdeb
[10:32] <AnAnt__> mvo: oh, you're the guy working on adding PPA support in update-manager ?
[10:32] <mvo> lifeless: yes
[10:32] <lifeless> cool
[10:32] <mvo> AnAnt__: yes
[10:32] <directhex> or Δdeb
[10:32] <liw> mvo, I would welcome feedback on the spec
[10:32] <directhex> either way, totally awesome and fun to tab-complete
[10:33] <AnAnt__> mvo: so, will it also be able pull the key of this PPA ?
[10:33] <lifeless> mvo: are you using the same approach I did, of a list.d file, with ppa name driving the disk file ?
[10:33] <lifeless> mvo: (I want to convert the things I used ppa-enable on to use the 'official' code
[10:33] <directhex> mvo, ooh, can i ask for changelog support for PPAs in update-manager?
[10:33] <lifeless> directhex: file a bug
[10:33] <lifeless> :)
[10:33] <mvo> AnAnt__: yes
[10:34] <ogra> directhex, will be added after Δdeb :P
[10:34] <james_w> directhex: you can ask...
[10:34] <AnAnt__> mvo: cool, thanks
[10:34] <directhex> james_w, awesome, here goes:
[10:34] <mvo> lifeless: it adds it to the main sources.list currently, but that is a implementation detail, your approach is nicer
[10:34] <mvo> lifeless: it looks the same in the UI
[10:34] <directhex> mvo, please add changelog support for PPAs in update-manager while you're at it!
[10:34] <lifeless> mvo: ! copy my code!
[10:35] <AnAnt__> mvo: so probably there is no need for this package: http://revu.ubuntuwire.com/details.py?package=sabily-keyring , right ?
[10:35] <lifeless> mvo: or do you need me to give you a patch?
[10:35] <mvo> lifeless: I want to merge your script into some package (not sure which one yet) so that its available on servers as well
[10:36] <mvo> lifeless: I can not just copy it, the software-properties bits use aptsources for the dealing with the sources.list, so its slightly different
[10:36] <lifeless> mvo: sure; I appreciate layers etc.
[10:37] <mvo> AnAnt__: that should no longer be required
[10:37] <AnAnt__> mvo: ok, thanks
[10:37] <james_w> directhex: it's not that easy
[10:37] <james_w> directhex: and probably not an update-manager change
[10:38] <mvo> directhex: there is a patch for this, it had some issues, it also will hammer launchpad quite a bit (and LP does not provide the changelog in "raw" format)
[10:38] <ajmitch> mvo: sounds like a change needs to be made on launchpad for it then
[10:39] <mvo> ajmitch: yeah
[10:44] <AnAnt__> mvo: ok, I archived it
[10:46] <geser> is there a location where one can check when the last auto-sync from Debian was done?
[10:46] <cjwatson> not to my knowledge
[10:47] <cjwatson> but if this is code for "please run an auto-sync", I can do that now
[10:49] <geser> cjwatson: yes, please and thanks for doing it
[11:05] <ogra> seb128, did anything in the evo folder format change with a recent upgrade ? i cant get to my mail, its only "savig folder" over and over
[11:05] <seb128> no
[11:06] <ogra> hmm, weird then
[11:06] <lifeless> I'm running tip and its fine for me
[11:06] <ogra> oh, now it recieves ...
[11:06] <lifeless> still does way to much IO
[11:06] <lifeless> ogra: look at IO top when its like that
[11:06] <lifeless> ogra: its probably doing 1 MB/sec of IO :P
[11:06] <ogra> lifeless, yeah, i usually just need to ask seb128 and it starts working again :)
[11:07] <ogra> its finally getting my 600 waiting mails
[11:07] <Ng> all gnome apps fear seb
[11:07] <ogra> i'll check with iotop next time
[11:07] <Tm_T> Ng: then what seb fears?
[11:08] <lifeless> ogra: feel free to confirm/sub to http://bugzilla.gnome.org/show_bug.cgi?id=584602
[11:08]  * ogra puts a bookmark up ... 
[11:09] <ogra> it definately does take to much IO
[11:10] <ogra> (it also definately recieves to much spam, but that might not be evos fault :P )
[12:44] <indus_> hello all
[12:50] <mok0> Has selinux been introduced into karmic?
[12:51] <cjwatson> geser: (done, by the way)
[12:53] <mok0> Apparently gcl has some issues with selinux, so if that has been introduced into karmic it would explain an FTBFS I am working on
[12:54] <hyperair> mok0: apparently yes it has
[12:54] <cjwatson> we've had selinux packages in the archive for eons
[12:54] <hyperair> CONFIG_SECURITY_SELINUX=y
[12:55] <cjwatson> ah
[12:55] <hyperair> i'm not sure about previous kernels
[12:55]  * mok0 was so happy not having to deal with selinux crap anymore after leaving redhat behind :-(
[12:56] <mok0> hyperair: where is that config?
[12:57] <hyperair> mok0: /boot/config*
[12:57] <hyperair> i think it can be disabled though
[12:57] <mok0> hyperair: thanks, will look into that
[12:57] <hyperair> =)
[12:58] <mok0> hyperair: you wouldn't dream of the grief selinux has cost me over the years.
[12:58] <hyperair> what grief?
[12:59] <mok0> hyperair: compilations fail with the most incomprehensible errors
[12:59] <hyperair> heheh
[12:59] <hyperair> access violations and whatnot i bet =p
[12:59] <hyperair> i really hated selinux's guts when i was maintaining a centos server
[12:59] <mok0> hyperair: and you spend hours and hours debugging until you discover that it was stupid selinx interfering without letting you know
[12:59] <hyperair> heheh
[13:00] <mok0> hyperair: seriously I hate selinux with a passion
[13:00] <hyperair> don't we all =P
[13:00] <hyperair> on a side note, i think the kernels have selinux disabled by default
[13:00] <hyperair> compiled in, just not enabled
[13:01] <hyperair> CONFIG_SECURITY_SELINUX_BOOTPARAM_VALUE=0
[13:01] <hyperair> unless i'm misunderstanding something =\
[13:01] <mok0> hyperair: I don't have /boot/config/
[13:01] <hyperair> mok0: it's not /boot/config/, it's /boot/config-`uname -r`
[13:01] <soren> hyperair: /boot/config-`uname -r`
[13:01] <mok0> right ><
[13:01] <hyperair> hehe
[13:35] <mok0> Any suggestions as how to deal with this problem in a builder? See here: http://pastebin.com/f73508858¨
[13:35] <mok0> http://pastebin.com/f73508858
[13:38] <mok0> Let me change that again: http://pastebin.com/m20327b7a
[13:39] <mok0> And if that's done, will axiom be able to run without changes to the kernel?
[13:49] <mok0> trying to compile using setarch ... -R
[13:53] <soren> mok0: Axiom? As in the computer algebra system?
[13:53] <mok0> soren, yes
[13:53] <mok0> soren, working on the ftbfs
[13:53] <soren> Oh!
[13:53]  * soren hugs mok0
[13:54] <mok0> heh
[13:54] <soren> I've been wondering about that one for... Well, *years* I suppose.
[13:54] <soren> Not actively all the time, mind you.
[13:54] <soren> but still.
[13:54] <mok0> soren: trying to build the newest version
[13:55] <mok0> soren: looks as if the setarch ... -R gets me a bit further
[13:56] <mok0> soren: but I am afraid the resulting app might need to work under the same environment
[14:11] <jerroome> hello, I would like to start an application on startup. Therefor, I edited the /etc/event.d/tty1 file. I replaced the /sbin/getty with my application. Some parts of the application is launched; but the main visual part isn't. It's a text based application. Does anybody know what I'm doing wrong ?
[14:12] <mok0> jerroome: is your program a getty replacement?
[14:13] <jerroome> no, it isn't
[14:14] <mok0> jerroome: it sounds like a very unconventional way to start a process
[14:14] <jerroome> I also tried to give my program as argument to getty, but the result is the same
[14:14] <jerroome> before, it was started inside inittab
[14:14] <mok0> jerroome: what does your program do
[14:14] <mok0> ?
[14:15] <mok0> jerroome: why don't your put "program &" in /etc/rc.local?
[14:15] <jerroome> hmm, because I thought that wasn't the way to do ...
[14:16] <mok0> jerroome: replacing getty is the completely wrong way
[14:16] <jerroome> ok
[14:16] <mok0> getty is for watching tty connections, terminals, modems and that sort of thing
[14:17] <mok0> jerroome: you can also place a script to start your program in /etc/init.d
[14:17] <jerroome> I thought I had to put it there if I needed my app to run inside vt1
[14:17] <mok0> jerroome: just for output?
[14:18] <jerroome> you mean vt1  ?
[14:19] <mok0> jerroome: yes, you want to re-direct output to vt1?
[14:20] <jerroome> I need the application to run there because I'm asked to, I think it's for communication with some serial ports
[14:21] <jerroome> I'm porting an app which was developped for fc6 onto ubuntu ...
[14:22] <jerroome> It's an automatic bike renting application which is connected to different serial devices ..
[14:25] <jerroome> as I thought, the application doesn't run correctly when launched through /etc/rc/local
[14:25] <jerroome> /etc/rc.local
[14:27] <mok0> jerroome: a bit beyond my experience I'm afraid. Try #ubuntu-server
[14:28] <jerroome> ok, however, thank you for your advices
[15:16] <pitti> does anyone have a multi-format SD/MMC/CF card reader, or any SCSI device with multiple LUNs? (quick test: "lshal | grep storage.lun" outputs something)
[15:17] <mok0> soren, axiom compiled, but then segfaults :-(
[15:17] <soren> /o\
[15:18] <Nafallo>   storage.lun = 0  (0x0)  (int)
[15:18] <Nafallo>   storage.lun = 0  (0x0)  (int)
[15:18] <Nafallo> pitti: you didn't say I had to have something plugged in, so hopefully that wasn't the case :-)
[15:18] <pitti> Nafallo: could you pastebin or email the output of "lshal" and "udevadm info --export-db"?
[15:19] <Nafallo> pitti: http://pastebin.com/f577b3f6e
[15:19] <pitti> Nafallo: no, I just wonder how to get the SCSI LUN from udev
[15:19] <mok0> soren: I suspect it could be a problem with gcl. Do you know of any gcl packages that *work*?
[15:19] <Nafallo> pitti: http://pastebin.com/f609ed562
[15:20] <Nafallo> pitti: oki :-)
[15:20]  * Nafallo wonder how he can teach pastebinit to use the right pastebin :-P
[15:20] <pitti> Nafallo: and perhaps udevadm info --attribute-walk --path=/devices/pci0000:00/0000:00:1f.2/host0/target0:0:0/0:0:0:0
[15:22] <Nafallo> pitti: http://pastebin.com/f17f1bf6f
[15:25] <mok0> soren, bug 387255 in case you want to subscribe to it. I'm stuck for now
[15:27] <Nafallo> pitti: enough info you reckon? :-)
[15:27] <pitti> Nafallo: yeah, I think I got it
[15:27] <pitti> Nafallo: many thanks!
[15:27] <Nafallo> pitti: no worries mate :-)
[15:30] <JonReagan> Keybuk, you on?
[15:30] <Keybuk> JonReagan: just about to have a call, grab me a bit later?
[15:30] <JonReagan> k, no prob
[15:58]  * Riddell sends bug 374973 back to kees, sorry for the delay
[16:11] <superm1> pitti, can I get another set of eyes on the udev rules for hid2hci?  I swear I checked that everything worked before I submitted it, but for some reason, the rule is launching hid2hci --method dell -v  -p  --mode hci (rather than injecting the numbers via $attr{})
[16:13] <pitti> superm1: TBH I don't really know what these are all about, but one thing catches my eye:
[16:13] <pitti> superm1: you match on ATTRS in the first rule, but run with $attr
[16:14] <pitti> superm1: i. e. the first rule will match on any child device, any of which's parent has idVendor==413c; but the device itself won't have this attribute
[16:14] <superm1> pitti, I thought that's the syntax though?  looking through /lib/udev/rules.d, that's how 75-persistent-net-generator.rules does it too
[16:14] <pitti> superm1: the other rules should be okay
[16:14] <superm1> oh.. $attr{} doesn't grab from child devices at all?
[16:14] <pitti> superm1: s/child/parent/
[16:14] <pitti> superm1: no, I don't think that there's a $attrs{}
[16:15] <superm1> pitti, hm well that would definitely explain it.  I'll have to rethink that first rule then. thanks
[16:15] <pitti> superm1: is it just the first rule which is broken, or others, too? (the others look fine to me)
[16:15] <superm1> I've only got the hardware for the first rule
[16:15] <superm1> and that's the one I really care about
[16:15] <pitti> superm1: I guess KERNEL== will select a particular subdevice of the entire physical device which has vendor/product ID
[16:16] <pitti> superm1: oh, and another thing
[16:16] <superm1> pitti, it's perplexing then how I  got this working before when I submitted it. ..
[16:16] <pitti> superm1: the parent device which SUBSYSTEMS selects must also have the idVendor/idProduct attributes
[16:17] <pitti> superm1: I think it's more robust to move this line to the start:
[16:17] <pitti> SUBSYSTEM!="usb", GOTO="hid2hci_end"
[16:17] <pitti> oh, and use SUBSYSTEMS
[16:18] <pitti> unless you are sure that SUBSYSTEM=="usb", ATTR{idVendor} are on the _same_ parent device
[16:18] <superm1> pitti, okay thanks for the tips.  i'll see I can strike a combination that works better and see which devices really have these different attributes with udevadm
[16:19] <pitti> superm1: hang on, seems that I lied
[16:19] <pitti> $attr does follow the parental chain
[16:20] <pitti> superm1: so the only possible explanation that I have is that SUBSYSTEMS, idVendor, and bmAttributes don't all match on the same parent device
[16:40] <superm1> Keybuk, pitti and I were trying to debug a problem with a udev rule and it looks like some really weird behavior is happening.  the rule is in udev-extras (62-hid2hci), and supposed to match ATTR{idVendor} and then pass $attr{idVendor} to the command.  it's properly matching, but passing " " to the command instead.  can you take a look if perhaps this looks like a bug that developed in udev traversing parents? http://pastebin.com/f29b3e865
[16:41] <Keybuk> do you have the rule handy?
[16:41] <pitti> Keybuk: in particular, s/udev traversing/$attr traversing/
[16:41] <Keybuk> $attr doesn't traverse parents
[16:41] <pitti> Keybuk: the manpage claims otherwise
[16:41] <Keybuk> the manpage is wrong
[16:42] <pitti> If the matching device does not have such
[16:42] <pitti>            an attribute, follow the chain of parent devices and use the value
[16:42] <pitti>            of the first attribute that matches.
[16:42] <Keybuk> yeah, it's wrong
[16:42] <pitti> Keybuk: well, that'd explain it :)
[16:42] <Keybuk> most of the matching stuff in the manpage is bogus these days
[16:42] <Keybuk> ATTR, DEVICE, SUBSYSTEM, etc. all match the exact device being operated on
[16:42] <pitti> Keybuk: could he instead use $env{ID_PRODUCT} ?
[16:42] <Keybuk> ATTRS, SUBSYSTEMS, etc. all match the *same* parent
[16:42] <Keybuk> ie. ATTRS{foo}=="x", ATTRS{bar}=="y" will only match a single parent that has both foo=x and bar=y
[16:43] <Keybuk> $attr{} expands to the exact device *or* the matched parent
[16:43] <pitti> Keybuk: right, the matching already works, we went through that
[16:43] <pitti> Keybuk: ATTRS{idProduct} _does_ match, we verified that; but $attrs{idProduct} in RUN is empty
[16:43] <Keybuk> can you show me the rule?
[16:43] <pitti> KERNEL=="mouse*", SUBSYSTEMS=="usb", ATTRS{idVendor}=="413c", ATTRS{bmAttributes}=="e0", \
[16:43] <pitti>     RUN+="hid2hci --method dell -v $attr{idVendor} -p $attr{idProduct} --mode hci"
[16:44] <Keybuk> hmm, so that _should_ work
[16:44] <Keybuk> because $attr{} can match the match parent
[16:44] <pitti> that's what I thought
[16:44] <Keybuk> idVendor doesn't get expanded?
[16:44] <superm1> right and neither does idProduct
[16:44] <pitti> superm1: if you s/$attr{idVendor}/$env{ID_VENDOR}/ does it work then?
[16:44] <pitti> superm1: (likewise with product)
[16:45] <pitti> superm1: usb_id attaches those
[16:45] <Keybuk> env won't work
[16:45] <Keybuk> oh, sorry, yes I see
[16:45] <superm1> pitti, yeah $env{ID_VENDOR} works
[16:45]  * Keybuk checks the code
[16:46] <Keybuk>                         /* try to read the attribute of the parent device, other matches have selected */
[16:46] <Keybuk>                         if (value == NULL && event->dev_parent != NULL && event->dev_parent != event->dev)
[16:46] <Keybuk>                                 value = udev_device_get_sysattr_value(event->dev_parent, attr);
[16:46] <Keybuk> that should work
[16:46] <pitti> Keybuk: "the" parent device is the one that *S matched on?
[16:46] <Keybuk> yes
[16:47] <pitti> superm1: sounds like worth a bug report then
[16:47] <Keybuk> superm1: could you run udevadm with UDEV_LOG=debug before it?
[16:47] <pitti> superm1: the rule, --attribute-walk output and udevadm test output should be attached
[16:48] <superm1> Keybuk, sure, the same udevadm test command with UDEV_LOG you mean right?
[16:48] <Keybuk> actually, that won't work ;)
[16:48] <Keybuk> don't worry
[16:50] <Keybuk> hmm
[16:50] <Keybuk> WFM
[16:50] <Keybuk> udevadm_test: run: '/usr/bin/touch /tmp/mouse-045e'
[16:50] <Keybuk> err
[16:50] <Keybuk> superm1: where did you get udev 142 from? ! :p
[16:51] <pitti>      udev |      142-2 |        karmic | source, amd64, i386
[16:51] <pitti> ?
[16:51] <superm1> Keybuk, us.archive.ubuntu.com :) ?
[16:51] <Keybuk> oh, did I upload that?
[16:51] <pitti> -- Scott James Remnant <scott@ubuntu.com>  Wed, 13 May 2009 11:04:31 +0100
[16:52] <pitti> actually, I'm TIL, but I just added the apport hook
[16:52] <Keybuk> udevadm_test: run: '/usr/bin/touch /tmp/mouse-045e-008c'
[16:52] <Keybuk> weird
[16:52] <Keybuk> it definitely works for me
[16:52]  * Keybuk tries 142
[16:53] <superm1> while you're at that, i'll try downgrading to 141
[16:54] <superm1> works fine in 141
[16:54] <pitti> the only other $attr in a RUN that we have is
[16:54] <pitti> /lib/udev/rules.d/50-udev-default.rules:KERNEL=="fd[0-9]", ACTION=="add", ATTRS{cmos}=="?*", RUN+="create_floppy_devices -c -t $attr{cmos} -m %M -M 0640 -G floppy $root/%k"
[16:54] <pitti> I doubt that a missing floppy device would be noticed very fast :)
[16:55] <Keybuk> works for me on 142 too
[16:56] <superm1> oh wait, no it doesnt work in 141 for me either.
[16:56] <superm1> (was running with the env{ID_VENDOR} in place)
[16:57] <Keybuk> I used this rule@:
[16:57] <Keybuk> KERNEL=="mouse*", SUBSYSTEMS=="usb", ATTRS{idVendor}=="046d", ATTRS{bmAttributes}=="a0", RUN+="/bin/echo hid2hci --method dell -v $attr{idVendor} -p $attr{idProduct} --mode hci"
[16:57] <Keybuk> that's basically identical to yours, right?
[16:58] <Keybuk> http://pastebin.com/m25b63e4c
[16:58] <superm1> yeah basically
[16:59] <Keybuk> specifically, note:
[16:59] <Keybuk> #
[16:59] <Keybuk> udevadm_test: run: '/bin/echo hid2hci --method dell -v 046d -p c047 --mode hci'
[17:02]  * superm1 is quite perplexed now why this isn't functioning
[17:23] <superm1> Keybuk, pitti something about matching with that KERNEL device was messing things up.  using this rule works, so i'll just submit this upstream instead I think: ATTR{bInterfaceProtocol}=="02" ATTRS{idVendor}=="413c", ATTRS{bmAttributes}=="e0", \
[17:23] <superm1>     RUN+="hid2hci --method dell -v $attr{idVendor} -p $attr{idProduct} --mode hci"
[17:24] <pitti> superm1: but shouldn't that at least ensure that it's an USB device?
[17:24]  * pitti -> dinner
[17:24] <superm1> pitti, i moved it to the top of the file
[17:25] <pitti> superm1: sounds good
[17:25] <znh> Hello :-)
[17:26] <znh> I'm working on a system to help users find solutions to their problems is this the right place to share this?
[17:32] <znh_> any reply yet on the above? Changed connections
[17:33] <maxb> znh_: Your question is so very broad, it's unclear what a useful response might be.
[17:33] <znh_> well I'm working on a website that lists questions asked in #ubuntu with replies based on that question. I'd like to share this in some way.
[17:35] <znh_> kinda like a knowledge base
[17:35] <maxb> Interesting. Though as I have given up on #ubuntu as being too high traffic to be useful, I'm probably not a useful person to talk to about this.
[17:39] <evanrmurphy> znh_: I also think it's interesting. Do you have a link?
[17:39] <znh_> Yes, does this work? http://62.163.12.248/print.php
[17:40] <evanrmurphy> znh_: Sure does. Hmmm...
[17:41] <znh_> It's still very primitive but the parsing part is reaching it's goal
[17:43] <ccheney> can someone process suitesparse for me, its in new and needed by new version of OOo
[17:44] <evanrmurphy> znh_: I'm very much in favor of an innovation along these lines. Speaking broadly and with more pickiness, I'd rather see an advancement integration of Ubuntu's current communication tools rather than the introduction of a new one.
[17:44]  * ccheney is going to locally build the package so he can continue his work
[17:45] <dajhorn> znh_: Would it be sensible to add this functionality to ubottu?
[17:45] <evanrmurphy> znh_: Imagine a way that questions on IRC could tap into the archives of Ubuntu Forums and Launchpad Answers...
[17:46] <znh_> Hmm...
[17:47] <znh_> or a system that asks input from the user and checks multiple locations
[17:47] <znh_> like Google but more targeted
[17:49] <slangasek> ccheney: I'll be a-newin' shortly
[17:49] <evanrmurphy> znh_: Well there are the various Google customizations for Ubuntu, two examples: http://www.googlubuntu.com/, http://crunchbang.org/ubuntu-search-engine/
[17:51] <znh_> okay. How do you imagine the linkage with Ubuntu Forums and Launchpad?
[17:51] <evanrmurphy> +1 to dajhorn's question of possible integration with bot functionality.
[17:51] <ccheney> slangasek: thanks
[17:51] <evanrmurphy> znh_: Wow, good question. Lemme think about that...
[17:54] <evanrmurphy> znh_: I remember while reading the about page for Launchpad Answers, that it touted its advantage over IRC and Ubuntu Forums as being the indexing of questions in a searchable database with useful status indicators (new question, open question, etc.).
[17:55] <znh_> in that case this database could be expanded with entries generated on IRC in a manner that Launchpad accepts
[17:59] <evanrmurphy> znh_: Btw, as you're looking for the best venues to discuss this project, you should consider the ubuntu-irc mailing list (https://lists.ubuntu.com/mailman/listinfo/Ubuntu-irc). I haven't read or posted to it before, but the description (basically meta-discussion about IRC) seems relevant.
[17:59] <evanrmurphy> znh_: Yes, I think so (to what you just said).
[18:01] <znh_> I'll give it a thought. Thanks for the feedback :-)
[18:03] <evanrmurphy> znh_: There might be some important hunting around to do for the big shots in Launchpad and Ubuntu Forums to get their advice on the feasibility of something like this. If it's possible, I think it could be a big breakthrough for the Ubuntu community and facilitate our communications substantially.
[18:05] <evanrmurphy> znh_: Needless to say, I'm excited and interested in the project. Will you keep me posted in the near future as you continue to scout this out? I may be willing to pitch in with the work.
[18:30] <lajjr> Hello pitti
[18:35] <directhex> oh, for the love of..... dear requestsync, please comprehend the idea of u-u-s not being u-m-s
[18:36] <directhex> i appear to have inadvertently ack'd my own mono sync
[18:38] <slangasek> sounds like a requestsync regression
[18:38] <slangasek> but that's ok, I was going to come pester you again about that outstanding merge anyway, so I'll just ack it myself when I do the sync. :)
[18:46] <directhex> slangasek, there's a pending -5 upload being prepared which fixes a kfreebsd regression. tell me how much you care about that one :p
[19:03] <slangasek> directhex: sounds critical to me - how else will we ship tomboy by default with the kfreebsd port?
[19:04] <directhex> slangasek, i'm sure all sane & rational minds are happy with "tomboy | openoffice.org-writer" to catch funny arches
[19:06] <mib_f0ikvw> kees: Sorry to disturb you with this, but if you could spare 5 mins, needed to bring up  the discussion you have had here with TJ on an apparently fixed major bug - https://bugs.launchpad.net/ubuntu/+source/devmapper/+bug/358654/+activity.
[19:17] <elfan> Is there a standard location for where source code for packages resides.  For example, https://code.launchpad.net/ubuntu/karmic/+source/xorg-server is empty yet there is clearly a changelog being generated from somewhere
[19:18] <slangasek> elfan: the only standard location is in the Ubuntu archive; 'apt-get source' is an interface for downloading these sources
[19:20] <cjwatson> code.launchpad.net will get populated for all source packages at some point during this release cycle (not to invalidate what slangasek said, I agree)
[19:21] <elfan> But right now if I want the latest (ie 'trunk') code for a package, I just just download the latest tarball?
[19:21] <james_w> cjwatson: I just happen to be starting up the scripts now :-)
[19:25] <slangasek> heh :)
[19:27] <decipherstatic> bryce: I tried grabbing the gpg key for the XServer with no backfill PPA but keep on getting a timeout error.  Is the ubuntu keyserver down? or just this PPA?
[19:27] <bryce> decipherstatic: no idea, probably just launchpad flakiness
[19:28] <decipherstatic> bryce: :) k anywhere else I can grab the key?
[19:29] <bryce> decipherstatic: afaik only from the ppa
[19:30] <decipherstatic> bryce: k thanks
[19:31] <Keybuk> valgrind: m_scheduler/scheduler.c:1144 (vgPlain_scheduler): the 'impossible' happened.
[19:31] <Keybuk> valgrind: VG_(scheduler), phase 3: run_innerloop detected host state invariant failure
[19:31] <Keybuk> sweeeeeeet :D
[19:43] <slangasek> ccheney: suitesparse accepted
[19:44] <ccheney> slangasek: thanks :)
[19:44] <DGMurdockIII> can i get the source code for the ubuntu oem installer?
[19:45] <DGMurdockIII> is the source code for the ubuntu oem installer avable?
[19:46] <slangasek> pitti: ok, you're right; dunno how I misread that earlier, but I see now that all the microstar infinity keys are in that file
[19:47] <cjwatson> I answered DGMurdockIII's question on #ubuntu-installer
[19:47] <cjwatson> james_w: oh good :)
[19:47] <cjwatson> elfan: yes
[19:51] <debfx> slangasek: may I merge ptlib 2.6.3-1?
[19:52] <slangasek> pitti: is there documentation somewhere of what's contained in the default keymap, or a way to query it in the current regime?  that might help eliminate some of these hotkey requests I've been reassigning to udev-extras, if we can show that they're already in the default map; or maybe not
[19:52] <slangasek> debfx: if you're meaning to ask the last person who merged it, that's not me
[20:06] <debfx> slangasek: ah yeah, sorry
[20:49] <ccheney> is every small bug in Ubuntu now a hundred papercut bug? :)
[20:50]  * ccheney sees a lot his have gotten marked this way
[20:50] <ccheney> or maybe it just happens to be coincidence that they are the ones i am looking at
[20:51] <ajmitch> ccheney: I think the papercut thing caught on too well
[20:52] <ccheney> the last one i saw i am fixing with my upload today but it seemed odd to see so many of them
[20:52] <ccheney> ajmitch: yea
[20:52] <ajmitch> perhaps people think it's a way to get those bugs fixed quickly
[20:52] <ccheney> ajmitch: well as long as someone is going to actually fix the bugs its a good thing, right :)
[20:54] <ajmitch> sure, if they're not all just wishlist or rather specific bugs
[20:54]  * ccheney thinks the people nominating hundred papercut bugs should be the ones fixing them
[20:54] <ccheney> otherwise how would they know if they are 'easy' to fix bugs
[20:55] <ccheney> iirc that was part of the definition of what to nominate
[20:56] <ajmitch> I don't think that part was made clear originally
[21:01] <ScottK> By definition any bug I don't have to fix is easy for me ....
[21:04] <ccheney> slangasek: so the ooo 8.04.3 issue was already fixed just not thoroughly investigated before it seems (/me reading OOo bugmail today)
[21:04] <ccheney> slangasek: erm wrt OOo itself i mean
[21:04] <mdz> slangasek: hotkey-setup being removed is expected, yes?
[21:04] <slangasek> mdz: yes
[21:05] <slangasek> ccheney: yep
[21:05] <mdz> slangasek: hooray!
[21:05] <slangasek> :)
[21:05] <ccheney> slangasek: ok
[21:06] <marctw> when you specify partition sizes during creation, the prompt is in block size unless you append a "k/m/g" to it?
[21:53] <slangasek> james_w: python-oauth debian/control: s/libarary/library/
[22:14] <james_w> slangasek: is that it?
[22:14] <james_w> I'll re-upload if so
[22:14] <slangasek> james_w: only thing I saw on the way through... :)  Accepted already
[22:14] <slangasek> so upload with a new number, please
[22:15]  * james_w commits for later upload
[22:15] <james_w> thanks for the reviews
[22:24] <directhex> yays, thanks slangasek
[22:51] <BUGabundo> tedg: ping
[22:51] <tedg> BUGabundo: Hello.
[22:51] <BUGabundo> tedg: another user, trying to debug GPM and getting no output at the cli
[22:52] <BUGabundo> same as it did we me a few days ago, when I was trying to debug it with you
[22:52] <BUGabundo> he is running jaunty, not karmic like me
[22:52] <tedg> BUGabundo: It's probably that his keyboard map is not sending the hotkeys to X.
[22:52] <BUGabundo> any idea why --verbose is not working ted ?
[22:53] <tedg> BUGabundo: Typically HAL needs to be set up for that hardware in some way.
[22:53] <BUGabundo> tedg: diff prob: his screen dims while he is typing
[22:54] <BUGabundo> tedg: I've asked kimus to ping you!
[22:54] <cjwatson> slangasek: IIRC lp:~ubuntu-core-dev/grub/ubuntu got fixed so that it would be mergeable from bzr-svn again. Exactly how do I go about getting a bzr checkout of the Debian svn branch (what URL, any necessary bzr-svn options, ...)?
[22:54] <BUGabundo> also asking him to run apport on gpm
[22:55] <slangasek> cjwatson: bzr co svn://svn.debian.org/pkg-grub/grub/trunk/debian
[22:55] <kimus> BUGabundo: in
[22:55] <tedg> BUGabundo: Okay, I have to run now.  But the apport data is very good.
[22:55] <cjwatson> slangasek: thanks
[22:55] <BUGabundo> eheh
[22:55] <BUGabundo> just my timming
[23:03] <kimus> BUGabundo: https://bugs.launchpad.net/ubuntu/+source/gnome-power-manager/+bug/387529
[23:11] <directhex> hm, i wish we knew for sure whether the audio from UDS was saved anywhere. I'd love to get an archive copy of the debian/ubuntu relationship session
[23:35] <mneptok> woot! the Albuquerque airport has free wifi!
[23:35]  * mneptok does a distrubing happy dance
[23:38]  * slangasek covers his eyes
[23:39] <BUGabundo> ehehe
[23:47] <directhex> mneptok, a few airports do. yay for them!
[23:47] <directhex> mneptok, iirc tampa does
[23:47] <slangasek> PDX does.  PDX > your airport!
[23:49] <slangasek> james_w: hmm, is this branch spam your doing? :)
[23:53] <directhex> i had to pay, like, 8 quid for an hour of wifi in barcelona!
[23:54] <directhex> that reminds me, need to fill out that expenses form. no, i'm not going to try expensing wifi
[23:55] <james_w> slangasek: aye, 'tis me
[23:56] <directhex> when's alpha 3 due?
[23:58] <BUGabundo> !schedule
[23:58] <BUGabundo> not that... humm
[23:58] <BUGabundo> !release
[23:58] <BUGabundo> !karmic
[23:59] <BUGabundo> directhex: ubottu: A schedule of Karmic Koala (9.10) release milestones can be found here: https://wiki.ubuntu.com/KarmicReleaseSchedule
[23:59] <directhex> meh, over a month then. no hurry to bringing in the latest space-saving changes to mono-related things