[06:43] <bicepjai> trying to do complete task05 in http://eudyptula-challenge.org/, got stuck and any help would be appreciated ! my razor keyboard creates 3 devices hiddraw[1-3], i want my hello module to load on my keyboard hotplug; i have tried changing usbhid quirks, udev rules to load my hello module on my keyboard vendor:product id; none of them works ! any thoughts ?
[07:16] <apw_> bicepjai, well you want to look at the udev events using udevadm monitor, and make sure your modalias matches that device
[07:17] <apw_> modinfo on your module should show you
[14:07] <apw_> rtg, ok pushed a couple of fixes for that tools thing to utopic, looks to work in my test env at least
[14:07] <rtg> apw_, ack
[14:08] <rtg> apw_, so, prolly need an upload today ?
[14:08] <apw_> we should jsut remember to check all the "other arches" tools pacakges the next itme we build it properly, as cross does not contain anything in those packages :)
[14:08] <apw_> rtg, it wasn't clear to me how urgent the issue is in the bootstrap archiev
[14:08] <rtg> dunno, slangasek ? ^^
[14:09] <apw_> if it isn't uber urgent i could upload it to the bootstrap PPA and confirm the binaries there
[14:10] <rtg> apw_, we can get also by without an ABI bump this time (if that'll grease the skids)
[14:11] <apw_> rtg, i am waiting on another test, when that is done, i'll be happy to suffer an upload, if its not an abi bumper we might fancy doing it sooner
[14:11] <rtg> apw_, lemme do the bow tying and a quick build test
[14:32] <rtg> apw_, amd64 test build on Utopic master-next looks good, so you can go ahead and drop this into your bootstrap PPA
[14:32] <apw_> rtg, ack will do
[14:33] <rtg> apw_, havebn't tagged it yet
[15:07] <sr105> henrix: Thanks for your help yesterday. It solved my issue.
[15:07] <sr105> ogra_: ^ smae
[15:07] <sr105> same
[15:08] <ogra_> :)
[15:17] <slangasek> rtg, apw_: I care about the tools issue for making the cross-toolchain packages in utopic buildable again; dunno what the bootstrap archive is that you're referring to, I think that's not relevant to me?
[15:18] <rtg> slangasek, its a way of testing those build stages in the linux package, i.e., stage1
[15:18] <rtg> which is, I think, the problem you ran into (stage1 was erroneously building some tools)
[15:18] <slangasek> ok, so I suppose you want to test that, but those tests don't address my use case
[15:18] <slangasek> because when you're testing you're using the full build-depends
[15:18] <rtg> slangasek, prolly not directly. 
[15:20] <henrix> sr105: awesome, i'm glad it help!
[15:20] <rtg> slangasek, I'll get an upload going later today if apw's tests work. then you can retry your cross builds
[15:20] <apw_> slangasek, right my archive isn't relevant for you, it is for regressions testing on normal cases only
[15:21] <apw_> slangasek, to test yours i uninstalled dh-systemd in my build chroot after a build and re-ran it with -Pbootstrap to simulate what you are doing
[15:21]  * slangasek nods
[15:21] <slangasek> (-P!  Why did we need a commandline argument for this, when we already had the env var setting...)
[15:22] <apw> i have also fixed the thing to handle the new pluralised -P env variable
[15:22] <apw> perhaps for tools integration with things like sbuild
[15:23] <apw> slangasek, spoke with cjw about the build-deps but it seems we don't have buildd support for the control <> thing yet
[15:24] <slangasek> correct
[15:27] <apw> slangasek, does your bootstrap env just suck up new sources, or can we slip a special in to check this works for you
[15:31] <slangasek> apw: the *-cross-toolchain-base packages build-depend on linux-source
[15:33] <apw> slangasek, hmmm i think we must be talking at cross purposes, as bootstrap stage only produces linux-libc-dev
[15:33] <slangasek> apw: yes, and when used in a cross environment, we use it for generating a cross linux-libc-dev
[15:33] <slangasek> (because we can't build-depend on a foreign-arch linux-libc-dev)
[15:34] <apw> slangasek, oh i see, gah :)
[15:46] <rtg> apw, my test build looks fine, so I guess I'll upload. you ready for that ?
[15:46] <apw> rtg, any test builds in bootstrap will be "some time" ... so ...
[15:47] <rtg> apw, ok, I'm just gonna assume they are OK, cause any failures there won't affect the main build process
[15:47] <apw> rtg, ack
[15:50] <apw> rtg, if you haven't already, this isn't right, for cloud tools
[15:51] <rtg> apw, gak! what ?
[15:51] <apw> there is a sublty here, due to all being done in i386, asses
[15:51]  * apw pokes
[15:52] <apw> and that is the bit which breaks them, crapola
[15:52] <rtg> apw, guess I'll go delete the tag
[15:53] <apw> i hate indep
[15:53] <rtg> apw, feel free to 
[15:53] <rtg> squash your fix
[15:53] <apw> will do
[16:31] <apw> rtg, ok fix squashed and pushed, but i am betting abi failurs ?
[16:31] <rtg> apw, I'll rebuild then
[16:33] <rtg> apw, why would anything you've done cause an ABI change ? it all looks like packaging to me.
[16:33] <apw> rtg, right, that, which is why i mentioned it
[16:35] <rtg> apw, still confused about why your change might impact ABI, but whatever....
[16:35] <apw> rtg, it oughtn't which is confusing
[16:35] <apw> perhaps i screwed some pooch, i am rerunning my test build before i declare it wrong
[16:36] <apw> rtg, perhaps you should test build it again as it is, and then call me stupid otherwise
[16:36] <rtg> apw, in progress
[16:45] <apw> rtg, ok i got another abi failure, but that makes no sense as the diff to your master-next shows only changes in -tools, which isn't even part of the abi check
[16:46] <rtg> huh, well gloin will be done in 50 minutes or so
[16:58]  * apw looks baffled
[17:05] <apw> rtg, where did you get the abi info from, as the previous version is still in (new)
[17:09] <rtg> apw, git mv I think.
[17:10] <rtg> apw, and all of my builds failed for abi-check. dang. I'll fix it up.
[17:10] <apw> rtg, the previous abi was -14 though, this is -15
[17:10] <apw> ok so at least that makes sense ... i was getting very confused
[17:10] <rtg> apw, dunno, otp. I''ll get to it in a bit
[19:48] <marvin24> mlankhorst: xserver (1.15.1-0ubuntu2.1) got broken on lts for non pci platforms like arm
[19:48] <marvin24> the change log points to some revived patch for hw detection
[19:49] <marvin24> server just segfaults
[19:57] <marvin24> https://bugs.launchpad.net/ubuntu/+source/xorg-server-lts-saucy/+bug/1322212
[20:14] <mlankhorst> marvin24: yeah !arm is less supported, what are you running?
[20:14] <mlankhorst> erm !x86
[20:18] <mlankhorst> pci-less is slightly broken, but as long as they don't use the platform description it will work correctly, afaict omap works, which is the only driver that used the string description
[20:24] <marvin24> mlankhorst: this is on tegra
[20:25] <marvin24> I think 1.16 fixes it
[20:25] <marvin24> (not tested)
[20:26] <marvin24> driver is opentegra (or modesetting)
[20:28] <marvin24> I know it is not supported, but it would be sad if it stays broken
[20:55] <mlankhorst> marvin24: fix opentegra then :P
[20:55] <mlankhorst> I think modesetting works
[23:35] <kirkland> bjf: around?