[00:17] <cjwatson> After mass give-back on ppc64el: 240 failed, 300 dep-wait (from 275/322).  Not bad
=== doko__ is now known as doko
[12:57] <zul> hi can i get an ubuntu-archive admin ack for FFE for python-hurry.filesize (#1365652), python-xstatic-angular-cookies (#1365647),
[12:57] <zul> python-xstatic-jquery-ui (#1365645), python-xstatic-angular-mock (#1365641),
[12:57] <zul> python-xstatic-jquery.quicksearch (#1365639) python-xstatic-bootstrap-datepicker (#1365632) they are straight syncs from debian which is needed for horizon
=== Ursinha is now known as Ursinha-afk
[16:45] <rbasak> Can someone process percona-* in Utopic NEW please? We've had them in there since feature freeze.
=== Ursinha-afk is now known as Ursinha
=== Ursinha is now known as Ursinha-afk
[17:08] <gaughen> slangasek, cjwatson, infinity would  you pretty please help with rbasak's request above?  infinity feel free to tell him rbasak that he needs to submit his core application in order for you to push them through ;-)
[17:08] <cjwatson> just about to go for dinner here
[17:09] <rbasak> It's not today-urgent, but has been languishing for a while. Percona (upstream) are keen to see it land.
=== Ursinha-afk is now known as Ursinha
[17:10] <rbasak> (they worked very hard with us to make feature freeze)
[17:10] <slangasek> having a look
[17:30] <slangasek> Pre-Depends: multiarch-support, ${misc:Pre-Depends}
[17:30] <slangasek> rbasak: ^^ multiarch-support should not be hard-coded here
[17:35] <slangasek> percona-server-client-5.6, what a package name :)
[17:35] <slangasek> rbasak: why is percona-server-common-5.6 a package at all?  It appears to be empty and just depends on mysql-common
[17:39] <rbasak> jamespage, georgelorch: ^^
[17:39]  * rbasak hasn't actually touched this package at all.
[17:50] <slangasek> jamespage, georgelorch: debian/rules on percona-server-5.6 is a real mess; do you know that dh_install is never called, and therefore debian/libperconaserverclient18.1.install and debian/percona-server-test-5.6.install are never looked at?  (Instead, the package is using dh_movefiles, which has been deprecated upstream for at least 5 years)
[17:54] <jamespage> georgelorch, are you OK to respond to slangasek's feedback please?
[17:54] <jamespage> slangasek, sorry - at a sprint this week - will try to respond as much as I can
=== Ursinha is now known as Ursinha-afk
[18:09] <rcj> Did libapt-pkg-dev=1.0.1ubuntu2.2 for trusty get stuck in proposed?  libapt-pkg4.12=1.0.1ubuntu2.2 was released and an install of libapt-pkg-dev on trusty breaks
[18:13] <rcj> stgraber, infinity ^
[18:16] <rcj> To install libapt-pkg-dev I first have to downgrade apt on the Trusty daily image.
[18:16] <rcj> Which is breaking deploy of juju-gui with trusty daily images.
[18:29] <slangasek> georgelorch: debian/percona-server-client-5.6.{dirs,docs} are empty and should not exist; debian/percona-server-client-5.6.lintian-overrides is overriding things which are outstanding problems with the package, please don't do this - lintian-overrides should only be used to suppress wrong warnings from lintian
[18:29] <slangasek> georgelorch: likewise, debian/percona-server-common-5.6.lintian-overrides is overriding a real issue (namely, that the package appears to serve no purpose and should not exist, in favor of depending directly on mysql-common)
[18:31] <slangasek> georgelorch: debian/percona-server-server-5.6.lintian-overrides: is lintian really reporting "possible bashisms" in a script that has #!/bin/bash?  that should be fixed in lintian
[18:50] <georgelorch> jamespage, slangasek, yes I can address these issues. Re: percona-server-common, there was some history there that either predated my involvement or I've long since forgotten why it was added. IIRC the Maria DB package has the same thing so could also be a possibility that it has same issue. So do these need to be addressed immediately or can they wait for another product release as we have some upstream updates coming
[18:50] <georgelorch>  soon?
[18:50] <slangasek> georgelorch: percona-server-common, the right point to address binary packages that should not exist is at archive accept time
[18:52] <georgelorch> ok slangasek, I will take care of these and submit another build for rbasak to upload.
=== Ursinha-afk is now known as Ursinha
[19:02] <slangasek> georgelorch: this one is also a no-go: percona-server-server-5.6: statically-linked-binary ./usr/sbin/mysqld
[19:03] <slangasek> binaries mustn't be statically linked against libraries from other packages
[19:03] <slangasek> (which at a minimum includes libc)
[19:07] <georgelorch> slangasek, IIRC that is not something that can be easily fixed as it requires changes to upstream Percona Server build process and also exists in other packages (MariaDB 5.5)
[19:08] <georgelorch> specifically it is the static link of libmysqlclient (libperconaserverclient)
[19:09]  * georgelorch is trying to remember details of things that were decided months ago
[19:11] <slangasek> $ file /tmp/mariadb/usr/sbin/mysqld
[19:11] <slangasek> /tmp/mariadb/usr/sbin/mysqld: ELF 32-bit LSB shared object, Intel 80386, version 1 (GNU/Linux), dynamically linked (uses shared libs), for GNU/Linux 2.6.24, BuildID[sha1]=0x7212f597c46b0b2952a61215a252f745a070ce6b, stripped
[19:11] <slangasek> georgelorch: ^^ that's mariadb; it is not statically linked
[19:12] <slangasek> perhaps it's also not statically linked in percona-server-server-5.6 either - I'm only looking at the lintian overrides, not the output of a build
[19:12] <georgelorch> slangasek, ahh, they must have fixed it since last I looked at this error
[19:12] <slangasek> but it is always wrong to override such lintian errors
[19:14] <georgelorch> slangasek, jamespage put it to me like this, if it is an upstream product/build issue, then an override is appropriate until it can be fixed by upstream. If it is an override due to lazy packaging, well, then, it needs to be fixed.  We do have bugs filed against Percona Server for all overrides.
[19:14] <georgelorch> btw slangasek, I do appreciate very much the feedback
[19:18] <slangasek> georgelorch: well, I disagree quite strongly with that; being an upstream build/product issue does not excuse hiding said issue
[19:21] <georgelorch> slangasek, as I understand it, the intention is not to hide the issue, but to allow the package to pass through various automation when there are known issues with upstream. if you are telling me that all of these must be addressed before it can be accepted, well then I guess I need to go back to the drawing board w/ jamespage and rbasak to try and get things fixed accordingly.
[19:22] <slangasek> georgelorch: I don't know what automation that would refer to, but any automation that encourages maintainers to suppress legitimate lintian errors with overrides is broken
[19:23] <slangasek> a lintian override should be used only when the maintainer determines that the lintian error is a false positive
[19:23] <slangasek> it should not be used to suppress useful information about the status of the package with respect to archive policy
[19:24] <georgelorch> ahh slangasek, that is certainly a bit different than what I have come to understand, thanks for the clarification
[19:35] <georgelorch> slangasek, just to be clear, the fact that the issues exist is obviously something we need to address, but your primary objection is to the overrides correct? Meaning that the package _could_ be accepted with some of the existing issues (upstream) as long as they weren't hidden by the lintian-overrides. Or, are you saying that all issues need addressing, packages must pass lintian 100% and no overrides at all before yo
[19:35] <georgelorch> u will accept the packages?
[19:36] <slangasek> georgelorch: I'm saying that the messages need to not be suppressed with lintian overrides. Whether fixing the issues would be a blocker for inclusion in the archive would be taken on a case-by-case basis; I would probably consider the static linking one a blocker to be fixed, but it sounds like it's already been fixed
[19:37] <georgelorch> ack slangasek, thanks for the clarification again...the static linking IIRC would be the most difficult to fix but you may be correct in that it has been fixed and we simply never removed the override
[20:00] <jdstrand> infinity: hi! would you mind looking at the FFe for bug #1362199?
[20:00] <ubot93> bug 1362199 in apparmor-easyprof-ubuntu (Ubuntu) "[FFe] apparmor abstract, anonymous and netlink socket mediation" [Critical,In progress] https://launchpad.net/bugs/1362199
[20:00] <jdstrand> infinity: for now, just need to approve the userspace bits. they are well-tested on generic and touch kernels
[20:01] <jdstrand> infinity: (the kernel bits will come later this week)
[20:02] <jdstrand> infinity: this feature is required for touch, but benefits server in particular
[20:06] <infinity> jdstrand: Hrm.  apparmor FFes seem to be becoming a pattern.  Should I get someone from the security team to explain to you why last-minute changes are harder to support than mature code? ;)
[20:06] <jdstrand> infinity: this is much less last minite than the last one :)
[20:06] <infinity> jdstrand: :)
[20:06] <infinity> jdstrand: Will give it a read in a bit.
[20:06] <jdstrand> infinity: but, this is the last 'we can't ship without this feature' apparmor feature for touch
[20:07] <jdstrand> infinity: thanks
[20:23] <Saviq> hey, can someone please have a look at http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#unity8
[20:24] <Saviq> it says the two adt runs regressed due to unsatisfiable dependencies, but doesn't say which?
[21:00] <kgunn> asac: in case you check in who would be good to see about unity8 being stuck ^
[21:00] <kgunn> someone in US timezone maybe...or an aussie
[21:07] <infinity> Saviq: Looking.
[21:07] <Saviq> infinity, thanks
[21:17] <asac> kgunn: yeah you found the right channel here. in ci-eng slangasek and folks can also help. robru should also know who to talk to in such cases etc.
[21:21] <kgunn> ta
[21:23] <mattgriffin> gaughen, slangasek thanks for the packaging feedback for my colleague georgelorch
[21:35] <cjwatson> rcj: "rmadison libapt-pkg4.12" disagrees that 1.0.1ubuntu2.2 was released; it is only in trusty-proposed
=== SpamapS_ is now known as SpamapS
[22:17] <infinity> Saviq: Still around?
[22:18] <infinity> Saviq: I wonder if this might not be adt freaking out about something on stderr during dependency installation.
[22:18] <infinity> Setting up usermetricsservice:amd64 (1.1.1+14.10.20140908-0ubuntu1) ...
[22:18] <infinity> method return sender=org.freedesktop.DBus -> dest=:1.7 reply_serial=2
[22:18] <infinity> ^-- That looks suspiciously weird.
[22:18] <infinity>    uint32 1
[22:28] <Saviq> infinity, that didn't change though, was there in previous successful runs, too
[22:31] <infinity> Saviq: I don't see that output on a previous successful run.
[22:31] <Saviq> infinity, https://jenkins.qa.ubuntu.com/view/Utopic/view/AutoPkgTest/job/utopic-adt-qtcreator-plugin-ubuntu/236/ARCH=amd64,label=adt/console
[22:32] <infinity> Oh, or I'm blind.
[22:34] <Saviq> infinity, it's no question that that looks suspicious, as that means it's calling dbus in post-install, which is probably not the best thing to do, but doesn't seem to be the reason
[22:34] <infinity> Right, looking harder.
[22:43] <infinity> Aaand, can't reproduce.
[22:43] <infinity> This might need someone with more familiarity with the adt infra to debug (like pitti or jibel)
[22:47] <jdstrand> infinity: fyi, I'm going to step away for a bit, but will be back later. if you have questions, feel free to leave them in backscroll or ask tyhicks/sbeattie about the userspace and jjohansen about the kernel
[22:48] <jdstrand> infinity: (I am of course referring to the apparmor FFe)
[22:48] <infinity> jdstrand: Yeah, I was JUST about to ask about the wording here.
[22:48] <infinity> "When used with a compatible kernel, 'unix' and 'network netlink' rules are supported. When used without a compatible apparmor userspace (eg, on a trusty system with an utopic backport kernel), abstract, anonymous and fine-grained netlink socket mediation is not enforced (ie, you can use this userspace with an old kernel without any issues)."
[22:48] <jdstrand> ok, I can wait on stepping away if you are looking at it
[22:49] <infinity> jdstrand: That implies new kernel and old userspace are fine, but the last bracketed thing says the opposite.
[22:49] <infinity> jdstrand: Obviously, both are desired, but it's a bit muddy about that. :P
[22:50] <jdstrand> infinity: it is meant to convery that a new userspace and kernel is fine, a new userspace and old kernel is fine, and an old userspace and new kernel is fine
[22:50] <jdstrand> convey*
[22:50] <jdstrand> that is how we roll
[22:50] <jdstrand> :)
[22:51] <infinity> jdstrand: Right.  As long as all three combinations are well-tested, I'm cool with this in theory.
[22:51] <jdstrand> seriosuly though-- if I get the ack, I need to land the userspace with an old kernel. that is well tested. we are aware of lts kernels so a new kernel will work with an old userspace, and of course we want the new kernel to work with the new userspace. we are finalizing the kernel bits, tbut the userspace is ready
[22:53] <jdstrand> all combinations are tested. the first is ready to land now. we have more testing on the latter two, and will of course have that done when we do the pull request
[22:53] <infinity> jdstrand: Commented on the bug.
[23:00] <jdstrand> infinity: ok, I commented. I forgot the Breaks bit this time. thanks for the reminder
[23:03]  * jdstrand fixes