[04:56] <pitti> Good morning
[04:56] <Unit193> Howja.
[04:56] <pitti> hey Unit193!
[06:56] <pitti> shadeslayer, Riddell: so what's the deal with kde-sc-dev-latest? all KDEish autopkgtests fail now as tests want to install that package, but it's not available
[06:57] <pitti> e. g. https://jenkins.qa.ubuntu.com/job/vivid-adt-ksystemlog/25/ARCH=amd64,label=adt/console
[06:57] <pitti> and 24 others
[07:52] <dholbach> good morning
[08:05] <LocutusOfBorg1> hi developerz!
[08:23] <pitti> xnox: hmm, is upstart-monitor supposed to work? I'm running it to see the update-notifier events (:sys:block-device-changed), but I don't get any event
[08:23] <pitti> and apparently update-notifier's job also doesn't trigger
[08:23] <pitti> xnox: oh wait, my fault -- running VM under systemd, sorry
[08:23] <pitti> xnox: typical "find the solution after you ask", sorry
[09:07] <pitti> xnox: hm, it doesn't work under upstart either; neither in default mode nor with -d system-socket
[09:07] <pitti> and the update-notifier job still isn't started
[09:13] <pitti> ah, with sudo I do get the events
[09:13] <pitti> block-device-changed KERNEL='sr0' ID_FS_TYPE='iso9660'
[09:13] <pitti> that's what update-notifier-cds.conf matches on, but it never actually fires
[09:14] <pitti> presumably because upstart-monitor as user also doesn't see those? is there some kind of ACL?
[09:14] <pitti> jodh: ^ is the session upstart supposed  to see events like the above?
[09:15] <alkisg_web> pitti, hi, would you mind if I pinged you about your opinion in https://bugs.launchpad.net/ubuntu/+source/udisks2/+bug/453605/comments/13 ?
[09:15] <jodh> pitti: at the session level, they should be prefixed with ':sys:'.
[09:15]  * alkisg_web proposed to just drop dmask=0077 there, not to make it configurable...
[09:15] <pitti> jodh: right, that's how I understood it; but they never seem to actually arrive
[09:16] <pitti> jodh: i. e. if I see them in "sudo upstart-monitor", but not in "upstart-monitor" or "upstart-monitor -d session-socket", it smells like there's something wrong?
[09:16] <pitti> jodh: likewise, /usr/share/upstart/sessions/update-notifier-cds.conf never fires, i. e. it's not seeing these events either
[09:17] <pitti> alkisg_web: at first sight this seems sensible; I need to look into this more closely, I'll keep the tab open
[09:17] <alkisg_web> pitti, thanks a lot
[09:19] <jodh> pitti: sounds like a problem with the upstart-event-bridge. I believe xnox made changes to a number of the bridges recently so he might want to check the behaviour.
[09:20] <pitti> jodh: ack, I'll wait for him then
[09:20] <pitti> jodh: thanks
[09:20] <pitti> xnox: on that note:
[09:21] <pitti> /usr/share/upstart/sessions/update-notifier-cds.conf
[09:21] <pitti> err
[09:21] <pitti> MOUNTPOINT=$(udisks --show-info $DEVNAME | grep 'mount paths' | awk -F: {'print $2'} | sed -e 's/^ *//')
[09:21] <pitti> how much more shell/grepping commands can you put into one line... :-)
[09:22] <alkisg_web> Haha
[09:22] <jamespage> morning all
[09:22] <pitti> hey jamespage
[09:23] <jamespage> any archive admins around with a spare hour? I have three new neutron-* source packages in the NEW queue for vivid which are refactorings of drivers from the main neutron codebase
[09:23] <jamespage> I'd like to get them into vivid so we can complete testing of the openstack kilo-1 milestone :-)
[09:39] <pitti> jamespage: I'll have a look
[09:39] <jamespage> pitti, thankyou - much appreciated!
[09:40] <pitti> mmmh, lintian clean
[09:40] <pitti> ♥
[09:42] <pitti> jamespage: btw, please stop using http://dep.debian.net/deps/dep5 as Format: field in d/copyright -- use http://dep.debian.net/deps/dep5/#format-field (it's an official standard now)
[09:43] <pitti> jamespage: I mean, use what's written ther ( http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/), not literally the above :)
[09:43] <jamespage> pitti, erg - sorry - that's probably just a copy paste error - I'll fix that up on next upload (doing some work on enabling the test suites atm)
[09:43] <pitti> thanks
[09:45] <pitti> jamespage: can you please also add Depends: ${python:Depends}?
[09:45] <pitti> jamespage: reviewing neutron-fwaas ATM (might be similar in the other three)
[09:45] <jamespage> pitti, ack
[09:47] <pitti> jamespage: ok, if you show me a commit with the missing dep (which is quite serious), I'll accept this
[09:48] <pitti> rest looks good; moving to vpnaas
[09:50] <pitti> jamespage: vpaas is similar; except that neutron-vpn-agent has ${python:Depends} which is almost surely a no-op there (and should be on python-neutron-vpnaas)
[09:53] <jamespage> pitti, http://paste.ubuntu.com/9793034/
[09:53] <jamespage> pitti, that was for fwaas
[09:53] <pitti> jamespage: ack, thanks; accepted fwaas
[09:55] <pitti> jamespage: ok, no other issues found in vpnaas, exact same two as above
[09:55] <jamespage> pitti, ok fixing in the same way
[09:59] <pitti> jamespage: lbaas> same old, ok otherwise
[10:00] <jamespage> pitti, ack - I have the same fix ready to go for both of those
[10:01] <pitti> jamespage: ack, source-NEWed
[10:01] <jamespage> pitti, is there a nice way to pull the source package from the NEW queue?
[10:01] <jamespage> dget whinges alot
[10:01] <pitti> jamespage: not that I'm aware of, I just usually grab all three files
[10:01] <pitti> jamespage: yeah, each component has a different librarian ID :/
[10:01] <jamespage> pitti, thanks for the review - very much appreciated - I owe you one (or three)
[10:01] <pitti> jamespage: no worries :)
[10:02] <jamespage> pitti, did the strongswan systemd compat get fixed?
[10:02] <pitti> jamespage: let me know when you uploaded the fixes, then I'll binNEW them
[10:02]  * jamespage looks
[10:02] <pitti> jamespage: trying to remember if I uploaded that, hang on
[10:02] <pitti> it's an utterly messy package, but I thought I did
[10:02] <pitti> jamespage: yes, https://launchpad.net/ubuntu/+source/strongswan/5.1.2-0ubuntu5
[10:02] <pitti> I'm now "touched it last", but I'm really not going to merge it
[10:03] <pitti> nobody has bothered to merge it in ages :(
[10:03] <pitti> and I don't nearly know enough about this to test a merge properly
[10:04] <jamespage> pitti, urgh - I hate that
[10:04] <jamespage> jpds has been its custodian in ubuntu - maybe he might like todo that merge :-)
[10:08] <jamespage> pitti, ok - all three of those updates uploaded and built
[10:13] <pitti> jamespage: ah, now that's a presentable Depends: now :)
[10:14] <pitti> jamespage: all done
[10:15] <jamespage> pitti, thanks!
[10:15] <jpds> jamespage: The whole package has a revamp coming up, and there's nothing to "merge" from Debian.
[10:16] <pitti> well, we have an enormous diff which looks quite noisy; essentially, we maintain it ourselves
[10:16] <pitti> i. e. we have to do things like the systemd migration or other packaging updates ourselves
[10:16] <pitti> and we are behind on the upstream version too
[10:16] <jpds> pitti: Hence the revamp.
[10:16] <pitti> I don't mind much, I just don't want to be held accountable for doing the next merge :)
[10:16] <pitti> (as TIL)
[10:16] <jpds> pitti: I talked to the Debian guys and they weren't interested in enabling half of the things strongSwan offers.
[10:17] <pitti> jpds: if nobody expects us to merge, that's fine then :)
[11:22]  * xnox loves ppc64el "wrong value for kill (job_pid, SIGKILL), expected -1 got -1"
[11:22] <xnox> hits retry button
[11:23] <LocutusOfBorg1> LOL
[11:29] <pitti> xnox: hm, I was  about to test your new upstart silo, but I don't see it any more?
[11:30] <pitti> xnox: oh, I figure that was https://launchpad.net/ubuntu/+source/upstart/1.13.2-0ubuntu6 and it's in already; nice!
[11:30] <xnox> pitti: didrocks tested it and we landed it. uploaded ubuntu7 now with correct session udev bridge job.
[11:30]  * pitti hugs xnox and diddledan
[11:30] <pitti> ... and didrocks too
[11:31] <pitti> no cookies for me for laziness and tab completion damage
[11:31] <xnox> pitti: however we want to implement globbing as well, such that one can wantedby android-container@foo.bar=val*.target (where "*" is actually systemd-escape'ed value \x3d or some such)
[11:32] <xnox> pitti: and then the bridge will iterate through all jobs, and store globs, and upon glob match of event it will start: android-container@foo.bar=val*.target AND android-container@foo.bar=valfull_value_that_was_there.target
[11:32] <pitti> xnox: so is https://code.launchpad.net/~xnox/upstart/no-classes/+merge/245948 "merged" now?
[11:32] <xnox> pitti: yes.
[11:33] <xnox> pitti: well superseeded by systemd-local-bridge branch and merged into different target - lp:ubuntu/upstart
[11:33] <pitti> oh, it's not merged into trunk, but the ubuntu package
[11:33] <xnox> pitti: jodh didn't want systemd silliness in lp:upstart
[11:33] <pitti> *nod*, fair enough
[13:44] <shadeslayer> pitti: errr .. hmm
[14:16] <ricotz> xnox, hi, i guess ubuntu-dev-tools is missing a dependency on python-ubuntutools
[14:16] <xnox> ricotz: possibly
[14:17] <ricotz> meaning it broke here since python-ubuntutools isnt installed ;)
[14:19] <xnox> uploaded
[14:20] <ricotz> thanks
[14:38] <teward> dobey: thanks for responding to http://askubuntu.com/questions/575775/is-it-possible-to-retire-packages-that-dont-stand-up-to-modern-usability-standa - i had initially popped into -release to have that answered, and they stated also that packages don't get removed unless it's legally compelled as such...
[14:40] <dobey> packages only get removed from stable releases if legally compelled to do so. they can be removed from the in-developement archive for lesser reasons, but one guy saying "this is hard to use" is not a good reason
[14:40] <dobey> especially for stuff that's just synced from debian and is in universe
[14:41] <teward> dobey: indeed.
[14:41] <cjwatson> Right, I said "for old releases" in #-release.
[14:41] <teward> dobey: i saw a special-case, bitcoin, once - think it was a "too volatile to be updated" and such
[14:41] <teward> but that was special-case
[14:41] <cjwatson> teward: Please could you edit your misquoting comment that says "they don't remove any packages, unless compelled to for legal reasons"?
[14:41] <dobey> teward: i think that was updated to be an empty package
[14:42] <teward> cjwatson: i would have to delete the comment entirely - you would have to restate.
[14:42] <cjwatson> I'm not going to get involved, but I want you not to be misquoting me.
[14:42] <teward> cjwatson: granted i have 2% power on my laptop
[14:42] <dobey> which is certainly doable if it makes sense to do
[14:42] <teward> so it's deleted
[14:42] <cjwatson> (I mean I'm not going to get involved on askubuntu)
[14:42] <cjwatson> thanks
[14:42] <teward> cjwatson: i know what you meant, it's deleted, problem solved, lets move on.
[14:42] <teward> back in a bit, gotta find a power outlet
[14:42] <teward> ... and coffee
[14:59] <teward> so, the DMB made a suggestion when I got my PPU rights for nginx that there be an Ubuntu specific index.html for the nginx package, which would be installed based on $DEB_VENDOR - my question is, would such a test be automatic or need to be scripted into the install file(s)?
[14:59] <teward> (part of the always-learning-the-system experience is asking questions when one is unsure, hopefully you don't mind the question)
[15:00] <rbasak> teward: good question :)
[15:00] <rbasak> teward: AFAIK, it needs to be scripted in debian/rules
[15:01] <rbasak> Though maybe someone will come along and tell me about a debhelper feature that is better than that :)
[15:01] <rbasak> Apache has a similar need, and the Debian maintainer did offer to do something similar. I was happy to maintain it as a delta though.
[15:01] <rbasak> (so I don't have that for Apache currently)
[15:01] <teward> mhm
[15:01] <teward> rbasak: the issue with nginx is that they ship a Debian-specific index.html
[15:02] <teward> pointing back to BTS and Debian bug reporting methods
[15:02] <rbasak> Yeah, same with Apache.
[15:02] <teward> rather than ours - hence the DMB recommendation
[15:02] <teward> (the latest merge, just went and hacked away at the shipped index.hml)
[15:02] <teward> index.html*
[15:02] <rbasak> teward: https://bugs.launchpad.net/ubuntu/+source/apache2/+bug/1288690
[15:03] <teward> ooo i should probably check trusty and utopic for this bug... if it exists, make it for nginx
[15:03] <teward> rbasak: darn it, you're adding to my bugs lists!  >.<
[15:03] <teward> (just kidding)
[15:07] <teward> rbasak: thank goodness only vivid is affected by this
[15:08] <teward> and the PPAs, but i'm lazy with updating those considering i spent almost a month hammering out code issues >.<
[15:37] <rbasak> ScottK: can I have an opinion from you on bug 1412830 please? sa-update or SRU?
[15:37] <ScottK> Looking
[15:38] <ScottK> rbasak: sa-update is disabled by default, so I think an SRU is appropriate.
[15:38] <rbasak> ScottK: OK, thanks. I'll arrange it.
[15:39] <ScottK> (Note: the Debian SA maintainer is considering changing that default for a future release)
[15:39] <ScottK> great
[15:42] <shadeslayer> mvo: any news wrt the synaptic SRU?
[16:52] <pitti> slangasek, stgraber, kees: TB meeting in 9 mins; mdeslaur and infinity sent their apologies; I'm still in a hangout, but I'll watch with half an eye
[16:52]  * slangasek nods
[16:52] <slangasek> who's the chair today?
[16:55] <Riddell> pitti: kde-sc-dev-latest back in the archive now
[16:56] <pitti> Riddell: ah, was it removed? that explains why they suddenly started failng without there being an upload for it
[16:57] <Riddell> pitti: yes sorry, I removed meta-kde but I've put it back now with only kde-sc-dev-latest
[16:57] <Riddell> (which we don't use but we need it to stop a muckle diff from debian)
[16:58] <pitti> Riddell: ack, thanks! I'll wait  until it's published and then retry all the tests
[17:15] <cjwatson> (hopefully will be more like seconds, but just in case anything goes wrong)
[17:52] <teward> repots of my question just in case someone knows another method other than scripting in debian/rules... teward> so, the DMB made a suggestion when I got my PPU rights for nginx that there be an Ubuntu specific index.html for the nginx package, which would be installed based on $DEB_VENDOR - my question is, would such a test be automatic or need to be scripted into the install file(s)?  (I admit I don't know everything, but I wish to learn
[17:52] <teward> best practices)
[17:52] <teward> grah, evil irc truncation!  *shakes fist*
[18:25] <mvo> shadeslayer: I have uploaded it, its wating in the utopic-proposed queue
[18:25] <shadeslayer> yay
[18:25] <shadeslayer> mvo: thx :)
[18:25] <mvo> thank you for preparing the diff!
[18:31] <shadeslayer> :)