[04:13]  * hallyn gets comfy with pam-configs
[05:23] <pitti> Good morning
[05:30] <Unit193> Howdy.
[06:53] <dholbach> good morning
[07:20] <pragomer> hello. why does this simple udev-rule not work when I plug my usbstick on: http://pastebin.com/r24CuJk1
[07:37] <pitti> pragomer: is it actually sdc1? check with "udevadm monitor -e --udev" when you plug in the stick
[07:37] <pitti> pragomer: and after it's plugged, "sudo udevadm test /block/sdc1"
[07:37] <pragomer> yes it is always sdc because a and b are ssd harddisks
[07:39] <pragomer> what should your 2nd syntax return?
[07:42] <pitti> pragomer: it should show you that your rule is being executed
[07:42] <pitti> .. or not, presumably
[07:42] <pragomer> yes it is executed
[07:45] <pragomer> so should this very simplified rule normally work ?   http://pastebin.com/r24CuJk1
[07:46] <pragomer> work with "sdc1" ? or is this a wrong syntax?
[07:46] <pitti> pragomer: yes, it should work
[07:46] <pitti> (although that's of course nothing you'd ever put in production)
[07:47] <pragomer> no.. not in production... its for finding the error in the rule I really want to create
[07:47] <pitti> pragomer: so do you have a /tmp/folder1?
[07:47] <pragomer> so.. you have an idea why this does not work?  changing the rule does not need a reboot, or?
[07:48] <pragomer> no, no subfolder "folder1"... there is just the system-immanent folder /tmp
[07:48] <pitti> pragomer: you just said that it is being run in udevadm test, so should be fine
[07:48] <pitti> pgraner: you can try with sudo udevadm control --reload
[07:49] <pitti> pgraner: sorry, tab error
[07:49] <pragomer> at the end there is "read rules file: /lib/udev/rules.d/99-myownrule.rules"
[07:49] <pragomer> but it outputs an error
[07:49] <pragomer> unable to open device '/sys/block/sdc1'   unload module index
[07:50] <pragomer> at the very end
[07:50] <pitti> pragomer: do you actually have a /sys/block/sdc1? and a /dev/sdc1?
[07:52] <pragomer> mm... I have , of course,  /dev/sdc and /dev/sdc1    but under /sys/block I have just sdc
[07:52] <pragomer> not sdc1
[07:52] <pragomer> dont know the meaing of /sys/block
[07:53] <pitti> how very weird
[07:53] <pitti> pragomer: /sys/ has the devices that the kernel sees
[07:53] <pragomer> ah ok
[07:54] <pitti> pgraner: please pull out the stick, run "dmesg -w", plug it in, and pastebin the output
[07:54] <pitti> (the new output)
[07:55] <pragomer> dmesg: Ungültige Option -- w
[07:55] <pragomer> (german for not valid option)
[07:55] <pragomer> is -w correct?
[08:04] <pragomer> pitti: dmesg -w is not a valid command?
[08:34] <cjwatson> barry: Sorry, I didn't manage to answer last night after all ... all other things being equal apt will prefer earlier entries in sources.list; I haven't checked about sources.list.d but I assume it comes after sources.list.  It's never occurred to me to need to force a PPA to win despite version clashes; if I wanted to do so I think I'd use apt preferences to pin the PPA above the primary archive (and debug carefully with "apt-cache ...
[08:34] <cjwatson> ... policy" because I usually get pinning wrong first time)
[09:38] <Faux> I'm keen to see nginx 1.9 synced from Testing into Wily.  I understand that it's not as there's "customisation" on the ubuntu package (it has a 1.6.2-5ubuntu3 version number).  Where can I find out more about what this means, and what's the best non-coding way to get this unblocked, i.e. is there a type of bug I can raise, or mail a mailing list, or..?
[09:40] <cjwatson> teward: ^-
[09:51] <rbasak> Faux: you might want to read https://lists.ubuntu.com/archives/ubuntu-server/2015-June/007072.html - whether we're going to be going to 1.9 is still an open question right now.
[09:55] <Faux> Ah, right, that's the kind of thing I was looking for.  Cheers.
[10:33] <pitti> cjwatson, jibel, infinity: I'm trying to understand britney's autopkgtest integration; for testing that locally, merely running "./britney.py  -c britney.conf --dry-run" fails because data/SERIES/Sources does not exist -- what creates that?
[10:33] <pitti> on snakefruit it looks like the concatenation of Packages_/Sources.gz of all components
[10:35] <pitti> I suppose this comes from something like chdist, but I don't see how (chdist in particular isn't called anywhere)
[10:40] <cjwatson> pitti: That's created by the britney1 scripts
[10:40] <cjwatson> lp:~ubuntu-release/britney/britney1
[10:40] <pitti> cjwatson: ah, ok; so for local testing of britney2-ubuntu, I'll just copy them from /var/lib/apt/lists, I figure?
[10:40] <cjwatson> lp:~ubuntu-release/britney/britney1-ubuntu, sorry
[10:40] <cjwatson> That used to contain the actual code, but then that all got rewritten separately, and now britney1 is basically just wrapper stuff
[10:41] <cjwatson> pitti: That would be fine, yes
[10:41] <pitti> cjwatson: ok, thanks!
[10:43] <pitti> cjwatson: ok, got that; now it fails on IOError: [Errno 2] No such file or directory: 'data/wily-proposed/Blocks'
[10:44] <cjwatson> See britney1-ubuntu :-)
[10:44] <pitti> ok
[10:44] <cjwatson> It fishes that out of Launchpad.  There are one or two other such files I think
[10:44] <cjwatson> For Dates you probably just want to copy that off snakefruit
[10:46] <pitti> ah, seems an empty file does just fine; now I'm at the point where it tries to call autopkgtest, which is where I want to be at :)
[10:46] <pitti> cjwatson: thanks!
[10:46] <cjwatson> YW
[10:48] <pitti> ah, that's what the test suite does too (create empty Blocks, Dates, Hints)
[12:00] <GunnarHj> darkxst: Hi Tim!
[12:00] <GunnarHj> darkxst: You realize that those g-c-c changes have not been tested, right?
[12:02] <darkxst> GunnarHj, no, but I will push them to the ppa tomorrow
[12:02] <darkxst> its still blocked on g-o-a anyway
[12:03] <GunnarHj> darkxst: That's what I mean - I couldn't build it for that reason.
[12:03] <darkxst> g-o-a is in the ppa
[12:04] <darkxst> though guess I am the only one with ppa enable sbuild
[12:05] <darkxst> but if you upload to a ppa that depends on gnome3-staging it should work
[12:06] <GunnarHj> darkxst: Is it? Missed that. Anyway, think it's better that you build in the PPA as a next step. Please let me know if there is a problem with 'my' part.
[12:07] <darkxst> actually g-o-a is in proposed, so that shouldnt have cause a build failure anyway? anyway yes I will test build it before uploading to the ppa
[12:08] <darkxst> not tonight though
[12:10] <GunnarHj> darkxst: g-o-a i uploaded to -proposed but not built there - waiting for libwebkit2gtk-4.0-dev
[12:11] <darkxst> GunnarHj, ah yes right, thats why I copied it to gnome3-staging
[12:15] <darkxst> GunnarHj, anyway don't worry, I will deal with it in the morning
[12:16] <GunnarHj> darkxst: Great, then I can sleep well tonight. ;) Thanks!
[12:17] <darkxst> GunnarHj,I need sleep now, been a long day ;(
[12:17] <GunnarHj> darkxst: Realize that. Sleep well.
[13:31] <barry> cjwatson: thanks.  hadn't thought about pinning.  i bet it's usually not a problem, but in my case, since i'm copying packages from the primary archive, versions in the ppa can conflict, and it can matter when the ppa version has additional build artifacts (e.g. py35 .so's)
[13:32] <barry> cjwatson: it *seems* like the ppa is doing the right thing, although i have no idea how :)
[14:06] <cjwatson> barry: Ah, I didn't quite grasp that you were talking about builds within the PPA.
[14:07] <cjwatson> barry: Launchpad writes out a custom sources.list for every build, and the context archive (i.e. the PPA in this case) is always placed first.
[14:09] <barry> cjwatson: that makes perfect sense, thanks!  for "normal" ppas it probably doesn't matter and i can repro this behavior locally with a --chroot-setup-commands
[14:10] <arges> hallyn: working on next libvirt upload for trusty. Merging fixes. So far I have: 1425619 (re enable migration patch), 1455608, and 1464175. Do you know of any others I should merge in there?
[14:13] <hallyn> 1342083 and 1386465 ?
[14:14] <hallyn> arges: are those all the ones which were in zul's pkg?
[14:15] <arges> hallyn: sorry, this is an SRU upload for trusty
[14:15] <arges> hallyn: i have the merge open in another tab... but getting this done first
[14:18] <hallyn> arges: oh!  one sec,
[14:18] <arges> ok
[14:18] <hallyn> how did you do 1455608 ?
[14:19] <hallyn> di dyo update the sysv script or take the whole init script update?
[14:19] <arges> hallyn: i took the changes for both upstart and libvirt-bin.init
[14:20] <hallyn> arges: list looks good - thanks!
[14:21] <arges> np
[14:38] <xnox> barry: apt-pinning etc. work but when all things are equal, the order of sources.list matters with first one winning.
[14:40] <barry> xnox: yep, and although it's not documented, sources.list.d entries come after that.  i'm guessing that the order within s.l.d entries is either alphabetical or random.  so the only way to guarantee an order is to rewrite sources.list, which is easy enough
[14:41] <xnox> barry: i bet it's readdir order
[15:50] <mitya57> sil2100, hi, I have filed a couple of appmenu-qt5 MPs for you, please review them if you can
[15:51] <mitya57> all that code will be removed in Qt 5.5, but I want these fixes a bit earlier :)
[15:51] <mitya57> I'm also going to backport it to sni-qt
[15:55] <sil2100> mitya57: oooh! Thanks, I still didn't find time to pick up some of my branches, maybe it's finally time to do that
[15:57] <mitya57> these branches are to match the spec more closely
[15:58] <sil2100> mitya57: excellent, I guarantee that those will be reviewed by tomorrow, I finally need to assign a day for desktop duties
[15:58] <sil2100> And I guess it's time
[15:58] <mitya57> sil2100: No need to hurry, but thanks anyway!
[15:59] <sil2100> mitya57: thanks for the branches!
[17:14] <seb128> stgraber, hey, I retried a desktop-next build from the iso tracker yesterday, that failed due to livecd-rootfs issues, but it seems that the tracker is stucked on "rebuilding" now and that new rebuild tries are not working?
[17:19] <ogra_> seb128, i think you need to explicitly stop them on the tracker
[17:19] <ogra_> (iirc ... its a while ago that i had to use that)
[17:19] <seb128> ogra_, I guess I could try that, waiting for stgraber to confirm in case he wants to look at the current state first
[17:20] <ogra_> iirc LP doesnt give feedback for failed builds (at least not to the tracker)
[19:15] <seb128> ogra_, cancelling doesn't work
[21:31] <barry> xnox: can you push lazr.restfulclient 0.13.4 to pypi?