[00:10] <nullack> Ping RAOF
[00:10] <RAOF> nullack: You'll generally get a better response with a context-full ping :)
[00:10] <nullack> context-full?? Im new to irc
[00:11] <nullack> Anyway following on from the convo yesterday
[00:11] <nullack> Do you want to email your ideas or are you ok with me summarising it and mailing that?
[00:11] <RAOF> You're very welcome to summarise & mail.
[00:11] <nullack> Will do
[00:11] <RAOF> (Contextless ping - your ping didn't give me any idea as to what you wanted to talk about, so I couldn't reply)
[00:12] <nullack> right
[00:13] <nullack> Though I am sure any contact from me to you is so important that your compelled to respond on any event :) ha
[00:35] <bdmurray> crimsun: it's driver and codec to uniquely identify sound hardware?
[00:52] <hggdh> bdmurray, I use radeonhd
[00:55] <hggdh> nullack, sorry for the delay. I get nothing I can find. Ffox simply dies, in silence. Not even a crash report
[00:56] <nullack> hggdh no problem, most of the time thats what I get, other times irregularly I get the segfault log message.
[00:57] <hggdh> nullack, I also see a small window popping open. Nothing is displayed there. Usually, when I hit the close on this small window, ffox dies.
[00:58] <nullack> hggdh thats another bug :) its annoying - windows get created that do nothing until firefox is closed, its an upstream bug mate
[01:03] <hggdh> interesting that I saw this behaviour on ffox 3, and Epiphany, but not on Opera
[04:54] <persia> hgggd h: spaces won't save you :)
[07:57] <dholbach> good morning
[07:58] <philwyett> Morning dholbach
[07:58] <dholbach> hi philwyett
[09:51] <geser> gnomefreak: Hi, still problems with gnupg-agent?
[09:51] <gnomefreak> geser: not sure atm im having issues with 2 apps im working on
[09:52] <gnomefreak> geser: it hasnt been updated so i would say yes and i havent changed anything
[09:52] <gnomefreak> let me try something
[09:53] <geser> can you check where /etc/alternatives/pinentry points to?
[09:56] <gnomefreak> /usr/bin/pinentry-qt
[09:56] <gnomefreak> geser: there are a few of them
[09:56] <geser> and when I see it correctly you don't have pinentry-qt installed anymore
[09:57] <gnomefreak> they all point to -qt
[09:57] <gnomefreak> geser: right
[09:57] <geser> looks like some package forgot to update the symlinks
[09:58] <geser> what gives "update-alternatives --display pinentry"
[09:59] <gnomefreak> geser: http://pastebin.mozilla.org/530017
[10:01] <geser> hmm, interesting
[10:01] <geser> looks like the symlink for the manpage got updated but not the one for the programm itself
[10:01] <gnomefreak> looks right to me thats why i figured it was bug in gunpg-agent
[10:02] <gnomefreak> take that back i miss read the last line
[10:04] <geser> I assume if you "fix" the symlinks it will work again
[10:04] <geser> which pinentry variant do you want to use? -qt4 or -gtk2?
[10:04] <gnomefreak> can i just use ln -s or do i have to remove the symlink that it is now
[10:05] <gnomefreak> -gtk2
[10:05] <gnomefreak> hm update-alterntives should do thast
[10:05] <geser> sudo update-alternatives --auto pinentry
[10:06] <geser> perhaps also for pinentry-x11
[10:07] <gnomefreak> ok did both
[10:08] <gnomefreak> looks like that did it
[10:08] <geser> can you check if this signing works again?
[10:09] <gnomefreak> nope
[10:09] <gnomefreak> still fails to sign
[10:09] <gnomefreak> dpkg-buildpackage: warning: Failed to sign .dsc and .changes file
[10:09] <persia> gnomefreak: What error do you get now?
[10:09] <gnomefreak> bzr: ERROR: The build failed.
[10:09] <gnomefreak> same one
[10:09] <gnomefreak> never prompts for passphrase
[10:09] <persia> And signing a text file has the same issue still as well?
[10:10] <geser> gnomefreak: can you sign normal files or doesn't it work too?
[10:12] <gnomefreak> it works
[10:13] <gnomefreak> only asked me once for passphrase where as bzr-builddeb and dpkg-build* ask for it 2 times
[10:13] <gnomefreak> thats odd
[10:14]  * gnomefreak thought you can view the .asc
[10:15] <geser> gnomefreak: does debsign work on the .changes file (or the .dsc file)
[10:15] <geser> ?
[10:18] <gnomefreak> ummm ok that doesnt like me
[10:19] <gnomefreak> debsign: Only a .changes, .dsc or .commands file is allowed as argument!
[10:19] <gnomefreak> i was signing source.changes and i386.changes
[10:19] <gnomefreak> debsign k764D5E13 firegpg_0.5.1-0ubuntu1_source.changes
[10:20] <gnomefreak> oh
[10:20] <gnomefreak> it works
[10:20] <gnomefreak> but doesnt prompt for password
[10:21] <persia> That's because the password is cached by pinentry-gtk2
[10:21] <gnomefreak> it did it automaticly for some reason
[10:21] <gnomefreak> ah
[10:21] <geser> gnomefreak: that's because gnupg-agent cached it
[10:21] <persia> Now try to build a package again.  It ought work this time.
[10:22] <geser> so this is not a bug in gnupg2
[10:22] <geser> gnomefreak: what do you propose to do with the bug? close it?
[10:22] <gnomefreak> dpkg-buildpackage: warning: Failed to sign .dsc and .changes file
[10:22] <gnomefreak> bzr: ERROR: The build failed.
[10:23] <gnomefreak> geser: close it with it still failing?
[10:24] <persia> How are you building the packages again?   "bzr: ERROR: The build failed." make me think there's some special hook that may help explain the problem (and reassign to the right package)
[10:24] <gnomefreak> maybe change package to what caused the failure to update symlink as well as the failing to sign
[10:24] <gnomefreak> gnomefreak@Development:~/extensions-builds/work/firegpg.ubuntu$ bzr bd --merge --dont-purge --builder='dpkg-buildpackage -rfakeroot -S -sa -kA5C42601 -i.bzr' .
[10:24] <gnomefreak> fails with dpkg-buildpackage as well
[10:24] <gnomefreak> but atm i have it set up for bzr
[10:25] <persia> Bug debsign works?
[10:25] <persia> s/Bug/But/
[10:25] <gnomefreak> yes
[10:25] <gnomefreak> it says it did
[10:25] <gnomefreak> let me check
[10:25] <gnomefreak> looks like it
[10:26] <gnomefreak> if i remove gnupg-agent all works fine
[10:26] <persia> OK.  What happens if you use `dpkg-buildpackage -S -sa -kA5C42601`?  Dropping -rfakeroot
[10:26] <gnomefreak> thats why i put it on that package
[10:28] <gnomefreak> with bzr-builddeb still fails if you give me 20 or so minutes i can set it up to just use dpkg-buildpackage but as far as i know the ' ' in bzr uses dpkg
[10:29] <persia> Just type the command at the prompt.  It ought work or not.  No need to change your setup.
[10:29] <gnomefreak> dpkg-buildpackage: source only upload: Debian-native package
[10:29] <gnomefreak> dpkg-buildpackage: warning: Failed to sign .dsc and .changes file
[10:30] <gnomefreak> the native is caused by the tarball not being seen since its in build-area
[10:30] <geser> gnomefreak: the bug is not in gnupg2 itself, as you could successfully sign a file and a package.
[10:30] <persia> OK.  That rules out it being caused by fakeroot then.
[10:30] <persia> It's also not debsign, because that works.
[10:30] <gnomefreak> than why does removeing gnupg-agent make it work
[10:30] <persia> gnomefreak: Because then it doesn't even try to cache.
[10:31] <gnomefreak> ok
[10:31] <persia> The bug is that dpkg-buildpackage is masking something.
[10:31] <persia> (And oddly, not for most people, but just for you).
[10:31] <persia> With the changes from update-alternatives, at least you have a working gnupg-agent.
[10:34] <gnomefreak> anything else to try and rule out if it is my setup let me know ill be glad to test (going for smoke atm_
[10:38] <gnomefreak> almost forgot firegpg fails to sign as well with gnupg-agent installed
[10:38] <gnomefreak> ill try since i updated alternatives
[10:38] <gnomefreak> ok firegpg works now
[10:42] <gnomefreak> updated comments on bug about changing the symlinks everything but dpkg-buildpackage still fails
[10:43] <gnomefreak> s/fails/works
[10:44] <gnomefreak> not sure what package dpkg-buildpackage im thinking devscripts
[10:44] <geser> dpkg-buildpackage is in dpkg-dev (see dpkg -S dpkg-buildpackage)
[10:44] <gnomefreak> but would still be local afaik
[10:45] <geser> I guess it would be fixed very fast if it was a general problem :)
[10:46] <gnomefreak> afaik asac adn fta are not seeing this problem atleast i asked them a few days ago
[10:52] <gnomefreak> ok changed target package
[10:52] <geser> gnomefreak: do you have also signing problems with this package or others too?
[10:53] <gnomefreak> geser: you mean only building firegpg?
[10:53] <gnomefreak> it happens with any package i build
[10:53] <geser> hmm
[10:54] <gnomefreak> hardy system and chroot work, 2 intrepid chroots and intrepid system fails
[10:55] <gnomefreak> i have one clean chroot and one i use for testing
[10:57] <geser> the gnupg-agent is started in which system? hardy or intrepid?
[10:57] <gnomefreak> geser: both afaik
[10:58] <gnomefreak> i get same prompt
[10:58] <geser> gnomefreak: I've a similar setup: main system (currently already intrepid) and a chroot for package preparing
[10:58] <gnomefreak> leave comments on bug i have to get ready to leave im hoping to be back in ~6hours or less
[10:59] <gnomefreak> geser: and yours doesnt fail?
[10:59] <geser> my gnupg-agent is only started in my main system and the chroot uses it as I bind-mount /tmp (and /home) and also have the same ENV variables set there
[11:00] <gnomefreak> chroot has its own symlinks and its own setup so it should work in chroot
[11:00] <gnomefreak> chroot is text IIRC
[11:00] <gnomefreak> atleast one of them is
[11:00] <geser> so you have a seperate .gnupg dir (and config) unrelated to your main system?
[11:01] <geser> inside your chroots
[11:01] <gnomefreak> yep gnupg not in my chroot
[11:01] <gnomefreak> i share $HOME
[11:02] <gnomefreak> ill be back later
[11:02] <geser> ok
[11:03] <geser> we can continue this when you're back
[11:03] <asac> anyone sees the flash problems here?
[11:03] <asac> if so, please ensure to have nspluginwrapper at latest version and then --reinstall flashplugin-nonfree
[12:22] <ramvi> [CUSTOMIZING LIVECD] I experienced some problems upgrading something when customizing the livecd. It's fixed now, the bug reports are saved somewhere though and is the first thing that greets a new user. Where are the bug reports saved? How can I stop them from appearing?
[12:26] <ramvi> nevermind, found it: /var/crash/
[14:20] <sectech> bdmurray,  ping
[14:54] <thekorn_> exit
[14:55] <thekorn_> uff
[15:33] <bddebian> Boo
[16:08] <bdmurray> sectech: pong
[17:03] <dholbach> Ubuntu Developer Week Sessions start now: #ubuntu-classroom
[17:07] <bdmurray> sbeattie: so I've found a bug that is a regression what's next?
[17:09] <pwnguin> bdmurray: can you bisect?
[17:09] <bdmurray> pwnguin: I'm not quite certain what you mean
[17:10] <pwnguin> well step 1 is to report the bug. step 2 is to report that it's a regression
[17:11] <pwnguin> an optional step 3 would be to test the revision history to find where the bug was introduced
[17:11] <bdmurray> pwnguin: There already is a bug report and sbeattie is working on a new process for identifying regressions.
[17:11] <pwnguin> ah
[17:11] <pwnguin> i thought it was wierd to hear you ask how to handle regressions
[17:53] <sbeattie> bdmurray: is it a regression in intrepid, a release, or an update for a release?
[17:53] <bdmurray> sbeattie: it's a regression in intrepid
[17:53] <bdmurray> come to find out its kees's fault anyway
[17:54] <sbeattie> so tag it regression-potential (bleah, would like a better tag name)
[17:54] <bdmurray> regression-danger!
[17:54] <sbeattie> if it's serious, add the ubuntu-release-notes project as a task.
[17:55] <sbeattie> heh, yeah
[17:55] <bdmurray> kees is fixing it already
[17:56] <sbeattie> kewl. then just tagging it will be okay.
[17:56] <bdmurray> done!
[18:01] <kees> I've milestoned it for alpha-6, got the fixed package built -- just waiting for freeze to clear
[18:05] <bdmurray> yeah!
[18:08] <bdmurray> sbeattie: so since it won't get fixed to alpha-6 maybe it should be release noted
[18:09] <bdmurray> The package is in main, and part of a default install
[18:15] <sbeattie> bdmurray: in this case, you could add it to the known issues directly on https://wiki.ubuntu.com/IntrepidIbex/TechnicalOverviewhttps://wiki.ubuntu.com/IntrepidIbex/TechnicalOverview and indicate that it should be fixed in alpha 6.
[18:15] <bdmurray> I can blame kees on that page too?
[18:16] <sbeattie> But of course!
[18:16] <bdmurray> well, and give him props for fixing it
[18:20] <kees> yeah!  :P
[20:02] <Brother_Cam> como instalo ubuntu no Notebook
[20:02] <Brother_Cam> ele tem drives pra wireless?
[20:03] <Brother_Cam> ?
[20:03] <Ampelbein> Brother_Cam: Please ask in english ;-)
[20:03] <Brother_Cam> Ok
[20:03] <pedro_> Brother_Cam: maybe you can find more help at #ubuntu-br
[20:03] <pedro_> i think that's the brazilian channel
[20:03] <Brother_Cam> no ingles!!!
[20:05] <pedro_> Brother_Cam: visita el canal #ubuntu-br es probable que ahi encuentres mas ayuda ya que es el canal de Ubuntu Brasil, aca se habla en Ingles
[20:06] <Brother_Cam> gracias
[20:16] <fluteflute> Hello everyone
[20:17] <fluteflute> Recently I have been marking bugs fixed in Intrepid (not specific to Intrepid) as 'Fix Released'. Is this correct?
[20:36] <fabrice_sp> Hi. If trying to reproduce a bug, I see it's working correctly, should I close the LP, or ask to reporter his version?
[20:57] <Ampelbein> fabrice_sp: if you can't reproduce you should ask the reporter to have it reproduced and the specific version he's using. if he can't reproduce: invalid. If reproducable for the reporter and he's using an older version you could check the changelog if there is a mention of the fix, if not, gather all required information and forward upstream.
[20:57] <Ampelbein> fabrice_sp: and you could of course ask the reporter to test intrepid-live-cd
[20:59] <fabrice_sp> Ampelbein: ok. Actually, looking for a similar bug, I found a previous LP with the same problem, so I marked it as duplicated
[21:00] <Ampelbein> fabrice_sp: thats correct.
[21:01] <fabrice_sp> Ampelbein: thanks. I wasn't really sure it was correct to do that ;-)
[21:07] <fabrice_sp> Another question: what to do if a package doesn't appear in the package list of a bug? (python-matplotlib-doc)
[21:19] <Ampelbein> fabrice_sp: can you give a bug number?
[21:20] <fabrice_sp> #262173
[21:21] <Ampelbein> bug #262173
[21:22] <fabrice_sp> I put the 'main' package (matplotlib)
[21:28] <Ampelbein> fabrice_sp: yeah, thats correct. you can search on packages.ubuntu.com for the package and then check the corresponding source-package name
[21:30] <fabrice_sp> Ampelbein: ok. Thanks again ;-)
[21:30] <Ampelbein> np
[21:32] <Ampelbein> fabrice_sp: you could also contact the folks in #ubuntu-motu to have a look at the bug. matplotlib is in universe so they should know why and if this dependency should be changed.
[21:35] <fabrice_sp> Ampelbein: as this dependency comes from debian, I thinks it even has to be reported there (or I'll check to see if it has been reported)
[21:36] <Ampelbein> fabrice_sp: sure. but first i would contact motu to look over it. they can perhaps give you a tip on how to continue from here.
[21:36] <fabrice_sp> Ampelbein: Ok. I'll check with them
[22:09] <bdmurray> Would anyone mind looking at a report for me?  I wanted to make sure the output makes sense to someone else before advertising it.
[22:23] <hggdh> bdmurray, which one?
[22:24] <bdmurray> hggdh: http://people.ubuntu.com/~brian/reports/needs-packaging/needs-packaging-run-2008-9-4.txt
[22:26] <hggdh> bdmurray, you are reporting on hits on Ubuntu for needs-packaging, correct?
[22:26] <bdmurray> hggdh: yeah, so KBasic matched a debian upstream bug report for MS-QuickBasic which is wrong
[22:26] <bdmurray> If it were right you'd want to add an upstream link to the debian bug from the ubuntu bug
[22:27] <bdmurray> ooh look bug 264192 might be fix released
[22:28] <bdmurray> I want to make sure the output and course of actions make sense
[22:28] <bdmurray> I could put the likely course of action in the script I guess
[22:28] <hggdh> so what you need is actually a follow up on all hits, correct?
[22:29] <hggdh> might be a good idea to show the upstream bugs you find
[22:30] <bdmurray> What do you mean? I believe the upstream bugs are there
[22:30] <hggdh> they are, but showing the link would make sense, I think
[22:31] <bdmurray> Oh, you mean the link for the existing bug watch, not the potential one?
[22:31] <hggdh> yes
[22:31] <hggdh> then a quick look would help expedite
[22:31] <hggdh> otherwise we have no option but to open the bug and look at the upstream
[22:32] <bdmurray> The ones with existing watches should already be good
[22:32] <bdmurray> I don't think there is a need to look at them
[22:32] <hggdh> OK
[22:32]  * hggdh tends to be cautious
[22:33] <hggdh> I like the output otherwise. Bug 145530 is an example... probable hits upstream, then it is (hopefully) easier to find the correct one)
[22:34] <bdmurray> and some of the bug reports could use better titles probably like bug 229537
[22:35] <hggdh> well, this one is actually the name of the package ;-/
[22:35] <bdmurray> e-mail?
[22:35] <LaserJock> bdmurray: I like that list, good work
[22:35] <hggdh> email notify
[22:35] <hggdh> bdmurray, are you going to add a checkbutton?
[22:36] <bdmurray> hggdh: what do you mean?
[22:36] <hggdh> for every one looked at, and done, so that other will not need to worry (until next run)
[22:36] <LaserJock> bdmurray: do you think it'd be possible to have a "reviewed" button or something to get rid of known mistakes?
[22:37] <hggdh> LaserJock, you hit it smack on...
[22:37] <LaserJock> like I see ruby is on the list, which is obviously not one we want to keep
[22:37] <LaserJock> it'd probably add a lot more complexity to the script though
[22:37] <bdmurray> bug 180282
[22:38] <LaserJock> having to maintain a list of what not to show
[22:38] <bdmurray> right, I think what should happen in that case is 180282 could use a better "1st word"
[22:38] <LaserJock> why?
[22:38] <LaserJock> I mean, that's a perfectly good name for it
[22:38] <LaserJock> I'm not sure how we're going to convince people to name them very well
[22:39] <LaserJock> even nmap is bad
[22:39] <LaserJock> parser is bad
[22:39] <LaserJock> library is obviously bad ;-)
[22:39] <hggdh> well, it *is* a parser
[22:39] <bdmurray> libruby-nmap?
[22:40] <LaserJock> bdmurray: but people have to know naming conventions to do that
[22:40] <hggdh> libruby-nmap-parser
[22:40] <LaserJock> and I think the vast majority of needs-packaging filers aren't going to know
[22:40] <bdmurray> or we could add a "reviewed" tag to the bug that my script could ignore
[22:40] <hggdh> hum
[22:40] <bdmurray> right but the same people who are reviewing this list could also modify the bug title
[22:41] <bdmurray> so not necessarily the n-p filer
[22:41] <hggdh> np-reviewed?
[22:41] <hggdh> I worry on extremely generic tags, like 'reviewed'
[22:41] <bdmurray> hggdh: right, that makes sense
[22:41] <LaserJock> bdmurray: that's quite a bit of work though don't you think?
[22:42] <LaserJock> tweaking titles just so the script works better
[22:42] <bdmurray> And what would a "reviewed" button do?
[22:42] <LaserJock> it would drop that bug to a lower part in your list I guess
[22:42] <LaserJock> similar to what Harvest does
[22:43] <hggdh> the same as a 'reviewed' tag, similar to what I asked: allows for this specific entry to be bypassed
[22:43] <hggdh> by a, huh, reviewer
[22:43] <LaserJock> I guess maybe a question is if we want the list to be ideally empty or any "hits"
[22:43] <bdmurray> I think that information should be contained in the bug report rather than outside of it
[22:44] <hggdh> you could look for the tag, and report at the end (after the non-reviewed ones)
[22:44] <hggdh> so the data is in the bug
[22:44] <LaserJock> hggdh: I think it's more complicated then that though
[22:44] <LaserJock> what we actually want is those to go back to a "Nothing found." state
[22:45] <bdmurray> Bug xyz has tag abc so not used
[22:45] <bdmurray> s/used/searched/
[22:45] <hggdh> then we could just ignore NP bugs that are tagged reviewed
[22:46] <hggdh> yes
[22:46] <bdmurray> and if somebody fixed up the title they could remove the tag
[22:46] <LaserJock> hmm, yeah
[22:46] <LaserJock> so if somebody has triaged a NP bug but it's title just doesn't work well with the scrip you add the tag
[22:48] <LaserJock> I still don't know that taking only the first word is going to suffice
[22:48] <LaserJock> the title should generally be the title of the software, which often has multiple words
[22:48] <hggdh> I do not think it will, but it is a good first approach
[22:49] <hggdh> we will get potentially more hits, but it is better than missing a correct one
[22:49] <LaserJock> bdmurray: you're just using apt-cache searches?
[22:50] <bdmurray> LaserJock: rmadison and some wnpp pages at debian.org
[22:50] <LaserJock> hmm, yeah, rmadison isn't so great when it comes to package name searches
[22:51] <LaserJock> I wonder if there's something better than can be done
[23:38] <Cycom> I've got a bug that is marked as Fix Released because it's fixed in intrepid, but I want to see if I can get it Target to released to Hardy as well.  Bug https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-input-evdev/+bug/223278
[23:46] <Cycom> I can't do it myself.  Nominate for Release is a dead link, and I dunno how to fix it.
[23:47] <hggdh> Cycom, first issue is this bug does not seem to have ever been identified on Hardy
[23:48] <hggdh> last entry states it does not happen on Intrepid
[23:49] <Cycom> hggdh: I can assure you it does happen in hardy.  Also, I just had this discussion with one of the devs about how bugs get marked and such, and they suggested I see if this could be done.
[23:49] <Cycom> Hardy is supposed to be supported till 2011, and this bug would prevent day-to-day use with a mouse if that mouse required evdev.
[23:50] <hggdh> Cycom, I did not state you could not/should not do it. I just stated it was not looked at Hardy
[23:51] <Cycom> what do you mean? as in the bug is not set as a bug in hardy at all? just in that particular package?
[23:51] <hggdh> also -- and this is a Malone/Launchpad bug -- nominate for release is referring only to the last package (xorg evdev), which does not exist on Hardy
[23:51] <hggdh> Cycom, please read the last comment
[23:52] <hggdh> "
[23:52] <hggdh> The events come from the kernel, so it's probably a bug there. Anyway, cannot reproduce on Intrepid, so closing as fixed.
[23:52] <hggdh> "
[23:52] <hggdh> you can also just re-open the bug, and state what you need
[23:53] <Cycom> I did read the last comment.  Fixing it in Intrepid does not help the people relying on LTS.  And again, the course that I requested was suggested to me in #ubuntu-devel
[23:54] <Cycom> they mark bugs as fixed released if they are fixed in future releases, and then if the fix needs to be backported, the bug should be marked as targeted to the old release.
[23:55] <hggdh> yes indeed. As I stated earlier on, there seems to be a bug on Malone that makes us unable to nominate for release based on Linux (the kernel package)
[23:55] <bdmurray> hggdh: really?
[23:55] <hggdh> bdmurray, see bug 223278
[23:55] <hggdh> try to nominate Linux for Hardy
[23:56] <bdmurray> hggdh: what happens if you do it?
[23:56] <hggdh> you cannot
[23:56] <bdmurray> If I do it, it will just be approved
[23:56] <hggdh> Malone prohibits me
[23:57] <hggdh> dammit, now I can!
[23:57] <Cycom> huh...
[23:57] <bdmurray> It might be context related
[23:57] <Cycom> did you set it as also mark as fix in xserver-xorg-input-evdev?
[23:58] <Cycom> I was under the impression that it was not an evdev package bug based on the comments, so I didn't.