[06:39] <ari-tczew> mitya57: hi, could you check package d-feet - there's new upstream release available in Debian, can we sync it?
[06:41] <Mirv> would any core-dev review/ack/nack the debian/* part of the following changes from Unity team related to multi-arch? https://ci-train.ubuntu.com/job/ubuntu-landing-012-2-publish/lastSuccessfulBuild/artifact/packaging_changes_compiz_1%3A0.9.12.0+15.04.20141210.2-0ubuntu1.diff
[06:47] <pitti> Good morning
[07:48] <dholbach> good morning
[08:03] <LocutusOfBorg1> hi dholbach :)
[08:03] <dholbach> hi LocutusOfBorg1
[08:03] <LocutusOfBorg1> bothering you in the first morning
[08:03] <LocutusOfBorg1> 1292118
[08:04] <LocutusOfBorg1> I got testing done ;)
[08:05] <dholbach> thanks
[08:07] <Laibsch> Laney: Hello, are you there? I was wondering if there was anything I should be doing re PPU now. Rolf
[08:10] <dholbach> LocutusOfBorg1, https://launchpad.net/ubuntu/precise/+queue?queue_state=1&queue_text=
[08:11] <dholbach> I think the other bug tasks can be closed, right?
[08:16] <LocutusOfBorg1> sorry I don't get what should be closed...
[08:16] <LocutusOfBorg1> (thanks for the upload BTW)
[08:20] <dholbach> LocutusOfBorg1, it was a but in virtualbox in ubuntu after all, right?
[08:20] <dholbach> so nothing which needs addressing upstream or it linux
[08:20] <dholbach> if that's the case I'd close the other bug tasks
[08:51] <LocutusOfBorg1> dholbach, makes sense, nope it is a cherry-pick from the new release
[08:51] <LocutusOfBorg1> trusty isn't affected at all
[08:52] <LocutusOfBorg1> 4.1.14 has already the patch IIRC
[08:52] <dholbach> right
[08:57] <LocutusOfBorg1> dholbach, introduced somewhere around 4.2.16 http://anonscm.debian.org/cgit/pkg-virtualbox/virtualbox.git/tree/src/VBox/HostDrivers/Support/linux/SUPDrv-linux.c?id=upstream/4.2.16-dfsg
[08:58] <LocutusOfBorg1> confirmed, between 4.2.8 and 4.2.16
[09:04] <Laney> Laibsch: oh yes, that needs someone on the TB to action but stgraber was busy last week
[09:05] <Laney> pitti: morning, fancy running some edit-acl for me & Laibsch? :)
[09:06] <pitti> hey Laney; sure
[09:06] <Laney> he needs PPU for https://lists.ubuntu.com/archives/devel-permissions/2014-November/000764.html adding
[09:12] <Laney> pitti: should be something like `edit-acl -p r0lf -S vivid -s bugz -s ffgtk -s fslint -s gjots2 -s isdnutils -s kasumi -s libcapi20-3 -s n2n -s pastebinit -s polipo -s roger-router -s scanbd -s scim -s scim-anthy -s scim-tables -s wondershape add'
[09:12] <Laney> can't test, obviously
[09:12] <pitti> Laney: yeah, I'm in the middle of it
[09:12] <Laney> ah
[09:13] <pitti> Laney: oh, only for vivid, not all releases?
[09:13] <pitti> "I've done many SRUs" sounds like he'd want stables, too?
[09:13] <Laney> I guess so :)
[09:14] <Laney> you could wrap it in a for release in $(ubuntu-distro-info --supported)
[09:14] <Laney> I don't think it matters if a package actually exists in that release or not
[09:15] <pitti> Laney, Laibsch: done: http://paste.ubuntu.com/9558596/
[09:16] <Laney> merci
[09:16] <Laibsch> thanks a lot
[09:17] <Laibsch> I think I have one sync from experimental.  I'll prepare it and request for review this time to make sure I understand the process
[09:18] <Laibsch> Is there much of a difference technically when uploading to Ubuntu vs Debian?  I guess, I'll also be using dput?
[09:22] <Laney> Laibsch: https://wiki.ubuntu.com/MOTU/New might be helpful
[09:23] <Laibsch> yes, I was looking for something like that
[09:23] <Laney> In Ubuntu we upload without binaries
[09:23] <Laibsch> thanks for helping me to find it quicker
[09:23] <Laibsch> aha, no binaries, noted
[09:23] <Laibsch> will an upload get rejected if there is a binary?
[09:23] <Laibsch> or will it simply be discarded?
[09:26] <Laney> Don't remember, probably rejection - try with a PPA if you want
[09:26] <cjwatson> It will be rejected, yes
[09:27] <cjwatson> Debian's moving towards source-only uploads too - in many cases you at least *can* now upload that way
[09:29] <Laibsch> in Ubuntu there is no protection even in case of a freeze, right?  In Debian, the package would simply not migrate to testing.
[09:29] <Laibsch> so more responsibility
[09:31] <pitti> Laney: we have the same now -- stuff is held in -proposed during freezes
[09:31] <pitti> see http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html
[09:35] <cjwatson> unstable is to testing as vivid-proposed is to vivid, very roughly
[09:36] <cjwatson> though the details of the rules are different - most notably, we have no migration delay
[09:38] <Laney> We don't have a freeze for Feature Freeze either, you have to look out for that yourself
[09:39] <Laibsch> Ah, that is good.
[09:40] <Laibsch> one more safety net
[09:40] <Laibsch> Are there any checks to see that version 1.2.3-4 (a Debian release obviously) is actually what I claim it to be?
[09:41] <cjwatson> usually verbatim syncs are performed by copying publication records around in Launchpad, rather than you uploading it independently
[09:41] <Laibsch> I'm not looking for loop-holes (well, I am but only to understand where I need to pay attention and where I can rely on safety nets being in place)
[09:41] <Laibsch> OK, can I do that in LP now?
[09:42] <Laibsch> or only core devs
[09:42] <cjwatson> anyone who can upload can also copy
[09:42] <cjwatson> syncpackage(1) will do it for you
[09:42] <Laibsch> I see, thanks
[09:42] <cjwatson> it's technically possible to reupload the same version, and it's not checked directly, although it might eventually cause flags to be raised further down the line
[09:42]  * Laibsch back to the wiki page
[09:42] <cjwatson> but there's normally no good reason to
[09:43] <cjwatson> (except for urgent syncs from incoming; but we have a part-complete plan for making that a lot quicker, will hopefully finish it in the new year)
[09:50] <Laibsch> my question was not about reuploading the same version, but to upload something as 1.2.3-4 where people would think that to be the same as the package in Debian while I had made (intention or unintentional) changes
[09:52] <Laibsch> I can make an upload to quastaging with "syncpackage -l qastaging -d experimental scanbd" to see if this works the way I want it to?
[09:57] <cjwatson> Laibsch: such a thing is technically possible, it's not checked directly, though I think we would be pretty unimpressed if we found anyone doing it.  Assuming you aren't looking for loopholes, though, the best way to avoid this is to rely solely on syncpackage or similar when intending to copy packages from Debian
[09:58] <cjwatson> Laibsch: I don't think copy jobs run against qastaging will be processed
[09:58] <Laibsch> yes, like I said, I am not looking for loopholes, just things that would make you guys unimpressed
[09:58] <Laibsch> I'd like to avoid that ;-)
[09:59] <cjwatson> Laibsch: just doing "syncpackage -d experimental scanbd" should be fine; it'll prompt you for what version you're copying, and assuming you vouch for that then it will either work or fail, it's not going to randomly do something else
[09:59] <Laibsch> that sounds really good
[10:02] <Laibsch> qastaging fails: http://paste.debian.net/137238/
[10:02] <Laibsch> but production seems to do the right thing
[10:04] <Laney> https://launchpad.net/ubuntu/+source/scanbd/1.4.1-1 it is working
[10:17] <cjwatson> Laibsch: Yeah, gina probably isn't running there
[10:17] <cjwatson> (the thing that imports Debian Packages/Sources files)
[10:21] <Laibsch> awesome!
[10:21] <Laibsch> thanks
[10:22] <cjwatson> basically qastaging isn't in general set up for QA of Ubuntu archive stuff
[10:38] <Laibsch> does LP provide me with a set of the packages I have now upload rights to?  I'd like to be able to refer to it in the future when in doubt and most importantly it would be nice to have a view of bug tickets restricted to those packages. Does LP provide that for me with a simple click?
[10:39] <Laibsch> https://bugs.launchpad.net/~r0lf/+packagebugs comes kind of close
[10:40] <Laibsch> well, not really
[10:50] <cjwatson> Laibsch: not in the web UI, but lp:ubuntu-archive-tools has edit-acl, which has a query function: edit-acl -p r0lf query
[10:51] <cjwatson> Laibsch: for a bug view, your best bet is to subscribe to bugs for each of the relevant packages, and then you can use https://bugs.launchpad.net/~/+packagebugs
[10:51] <Laibsch> Ah, the one you used.  I automatically assumed that was something only for the super-powers.  Thanks.  I will refer to that and feed an API script with its output to get my bug list, I guess.
[10:53] <cjwatson> Laibsch: which you can do from https://bugs.launchpad.net/ubuntu/+source/ffgtk "Subscribe to bug mail" etc., or it's easy to script by something like http://paste.ubuntu.com/9559306/
[10:53] <cjwatson> (hm, the list of packages should probably be positional arguments in that script; anyway)
[10:54] <cjwatson> so http://paste.ubuntu.com/9559315/ I guess
[12:46] <Mirv> (repeat from the morning) would any core-dev review/ack/nack the debian/* part of the following changes from Unity team related to multi-arch? https://ci-train.ubuntu.com/job/ubuntu-landing-012-2-publish/lastSuccessfulBuild/artifact/packaging_changes_compiz_1%3A0.9.12.0+15.04.20141210.2-0ubuntu1.diff
[12:47] <pitti> Mirv: weird repetitions in the changelog ?
[12:48] <Mirv> pitti: CI Train is sometimes hard to keep behaving when multiple merges happen
[12:49] <pitti> Mirv: looks ok to me, although I don't understand the fuss around it -- why bother making paths in compiz M-A compatible and adding "M-A: no"?
[12:53] <Mirv> pitti: ok. the MP is https://code.launchpad.net/~bregma/compiz/lp-1395105/+merge/243031 stating "where possible". they started with making everything m-a, and then backed up for those that had /usr/bin content
[12:54] <Mirv> I can file a bug if there are any suggestions for future work
[12:54] <pitti> Mirv: right, at least for the libs and python
[12:54] <pitti> Mirv: nah, don't worry; let users file bugs if they actually need it :)
[12:54] <pitti> Mirv: so, +1
[12:55]  * Mirv hugs pitti
[12:55]  * Mirv tells bregma to hug pitti too
[12:55] <pitti> no worries, it was just a small review :)
[13:12]  * bregma hugs pitti in a manly fashion
[13:22]  * Riddell hugs pitti in a gender neutral fashion without back slaps
[13:23] <pitti> bregma: you mean with clinking beer cans and a heartily poke into the ribs? :-)
[15:54] <pitti> hallyn: hey, how are you?
[15:54] <pitti> hallyn: OOI, what is the reason why we can't enable cgmanager in Debian by default?
[15:54] <pitti> hallyn: I see that it certainly shouldn't run all the time, but could we do something like D-BUS or socket activation?
[16:07] <hallyn> pitti: bc systemd doens't want us to
[16:07] <pitti> hallyn: oh, so it does conflict to systemd? (I misunderstood that then)
[16:07] <pitti> there's certainly a high chance that they do
[16:07] <pitti> well, at least since recently when systemd started to put processes into all cgroup controllers
[16:08] <pitti> before that, systemd only touched teh "systemd" controller, so they shouldn't have interfered
[16:08] <pitti> hallyn: but we don't do that ^ (LXC user container support) on Debian -- so if they already collide on Debian, they will collide even harder in Ubuntu now
[16:09] <pitti> hallyn: so in that case I guess we close the cgmanager task, and fix that in UAL?
[16:10] <hallyn> pitti: no, they don't "conflict".  they work fine together.  Systemd however wants by default to control all the cgroups themsevles
[16:10] <pitti> hallyn: well, but that's only true with the ubuntu patch to handle all controllers, not just the private systemd one?
[16:10]  * pitti confused
[16:11] <hallyn> so systemd would claim they "conflict" in that systemd can't make educated ecisions if someone else is making changes
[16:47] <bdmurray> roaksoax_: was the verification of the curtin SRU done both on trusty and utopic? e.g. bug 1378910 the bug only says verification-done.
[17:19] <mapreri> pitti: <3
[17:19] <pitti> mapreri: thanks for your work on the merges
[17:21] <mapreri> pitti: I'd like to do more, but this year I started the uni, and I'm lagging a bit, quite overwhelmed by other things.... (e.g. mainly school and debian) :)
[18:08] <shadeslayer> anyone know where I can get the apt-get exit codes?
[18:42] <bdmurray> tkamppeter: what happened to system-config-printer version 1.4.3+20140219-0ubuntu2.3?
[18:43] <bdmurray> tkamppeter: ah, I figure it out
[18:51] <bdmurray> tkamppeter: however I'm a bit confused by this comment https://bugs.launchpad.net/ubuntu/+source/system-config-printer/+bug/1398444/comments/5. The upload to trusty-proposed doesn't reference bug 1400232 or bug 1401835 in the changelog.
[20:29] <hallyn> does anyone here have a ppc64el trusty machine handy to verify bug 1374554 ?
[20:46] <infinity> hallyn: Given it's a 1-line patch, if the patch was identical on U and T, and tested okay on U, I'd be inclined to just call it good in both places.
[20:47] <infinity> hallyn: qemu on T isn't entirely ppc64el ready anyway, AFAIK, so proper testing would fall flat pretty quickly after that bug.
[20:50] <hallyn> infinity: ok, thx.  (working on verifying the other bug in -proposed right now so we can clear that logjam)
[20:51] <infinity> hallyn: Just double-check the patch really is identical on both before handwaving the T verification. :P
[20:51] <hallyn> ok
[20:52] <infinity> hallyn: Though, actually, it shouldn't need a ppc64el host to test, if you can convince libvirt to start a ppc64 guest on your x86 machine.
[20:53] <infinity> hallyn: Fully emulated qemu-system-ppc64 works great on x86 (a bit slow, but works).
[20:53] <mitya57> shadeslayer, apt-get(8) says that "apt-get returns zero on normal operation, decimal 100 on error."
[21:00] <hallyn> infinity: oh, i thought the bug required kvm (since it requires access to ppc64-specific sys info)
[21:03] <infinity> hallyn: The 1-liner is just giving access to /usr/share/slof, which is the loadable firmware, nothing to do with the host arch.
[21:04] <infinity> hallyn: Oh, I see, there's also a line for reading the host's devicetree.
[21:04] <hallyn> yeah i don't know what happened with the changelog there
[21:04] <hallyn> it's missing gtwo lines from utopic-proposed's
[21:04] <infinity> hallyn: Yeah, just verify blind by comparison of diffs to utopic, IMO.
[21:23] <Laney> stgraber: does dnsmasq write a log file when something updates the server it's fowarding to?
[21:24] <Laney> I'm getting queries being refused
[21:24] <stgraber> no
[21:24] <Laney> while on a VPN
[21:25] <stgraber> well, maybe to syslog but if it does, it's not going to be very obvious (dnsmasq logging is pretty terrible)
[21:30] <Laney> ah, syslog does have some stuff
[21:30] <Laney> looks like it's trying to use split dns
[21:32] <stgraber> right, NM will usually do split DNS, sending all the subnets and domains advertised by the VPN over to the DNS server it pushes
[21:32] <Laney> the ones the VPN server pushed are resolvable, the rest are refused
[22:02] <Riddell> Vivid Alpha 1 out
[22:02] <Riddell> archive is unfrozen
[22:06] <hallyn> xnox: hey - reminder, would you mind sponsoring http://mentors.debian.net/debian/pool/main/n/netcf/netcf_0.2.6-1.dsc ?
[22:09] <JackFrost> xnox: And can you "review" https://code.launchpad.net/~unit193/ubiquity/xfwm4-panel/+merge/244437 ?
[22:23] <infinity> Riddell: Adding to the end of the topic really confuses the bot. ;)