[00:04] <slangasek> doko: did you give back cmake on arm64 again?
[00:05] <slangasek> because it seems to be failing repeatedly, and being given back
[00:05] <slangasek> (before I ever get to look at the build log)
[00:06] <doko> slangasek, it was on the same buildd. will stop giving it back
[00:07] <slangasek> doko: so there's a buildd-specific problem?
[00:08] <doko> slangasek, I don't know, but usually I retry arm64 builds before I report issues
[00:08] <slangasek> doko: heh, ok
[00:09] <doko> so yes, maybe I should record arm64 ftbfs before I give these back
[00:09] <slangasek> doko: and I see uploads for openjdk-7 dropping out of main, thanks :)
[00:10] <doko> yeah, 6 already removed, 7 in universe, and hopefully removed as well
[00:10] <nacc> slangasek: building and then will test a new version of mythtv with dpkg-maintscript-helper additions, and then will be done for the day (so your inbox can rest easy :)
[00:15] <slangasek> nacc: heh; I just sponsored the php-horde-crypt change, but I also just noticed that php-horde-crypt 2.7.0-1ubuntu1 passes its tests again together with php-horde-http 2.1.5-3ubuntu2
[00:16] <nacc> slangasek: ah ok ... so maybe timing again; I don't think it should do any harm, and it will mean if we do have a network blip, it will skip & not fail, i think
[00:18] <slangasek> nacc: none of these are network blips, it's the deliberate network filtering policy on the autopkgtest runners
[00:19] <nacc> slangasek: oh i see, horde-http being a the newere version fixed the issue properly, got it
[00:19] <slangasek> nacc: yeah, seems so
[00:21] <teward> stupid obvious question, but, does landscape-client in Xenial not work the way it should with Landscape?  I only ask because in trying to set up an actual Xenial server, following my workflow of configuring it to Landscape, it chokes during server ISO setup...
[00:39] <slangasek> nacc: hmmm which arch was having the weird kernel timeout related bugs from one of the php test suites?
[00:41] <doko> infinity, please have a look at https://bugs.launchpad.net/ubuntu/+source/qtbase-opensource-src/+bug/1560528
[00:43] <doko> slangasek, failed again, this time on a different buildd: https://launchpad.net/ubuntu/+source/cmake/3.5.0-1ubuntu3
[00:43] <slangasek> doko: yep; trying to figure out if this is related to another bug we saw with a php package's testsuite on one of the armen architectures
[00:44] <slangasek> doko: that was php-imagick on armhf; but I guess that's also running on a 64-bit kernel, so could be the same issue
[00:44] <slangasek> https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/armhf/p/php-imagick/20160323_112011@/log.gz
[00:45] <slangasek> hmmmm completely different kernel version, though
[00:46] <slangasek> (3.13.0-45 vs. 4.2.0-30)
[02:14] <nacc> slangasek: i think it was armhf w/ imagick?
[02:17] <nacc> slangasek: also, i tihnk php-horde's failed amd64 test, php-horde-data's i386 failed test are transient; php-horde-mapi may need to be manually kicked now that seclib is in
[02:18] <nacc> slangasek: and oddly horde http failed again ... will investigate in the am
[02:40] <stgraber> roaksoax: package renames AND copyright updates, you really like to make my life difficult...
[02:40] <stgraber> I'm sure the diff would actually be readable without all that stuff...
[02:48] <sarnold> where does the '3819' come from in the ulimit -a output? it's also in e.g. systemctl show fwupd  or systemctl show sshd
[02:48] <sarnold> the usual grep -rl 3819 /etc /usr /lib  didn't do the trick
[02:48] <slangasek> nacc: php-horde-mapi retriggered
[02:50] <slangasek> sarnold: "3819"? for what limit?
[02:50] <sarnold> slangasek: both pending signals and max user processes
[02:51] <slangasek> sarnold: those numbers are calculated dynamically based on available system RAM IIRC
[02:52] <sarnold> interesting
[02:52] <sarnold> # for u in $(systemctl list-unit-files  | awk '{print $1}') ; do systemctl show  $u | grep 3819 ; done | wc -l
[02:52] <sarnold> 800
[02:52] <sarnold> hehe
[03:09] <slangasek> nacc: php-horde-http failed again because it was still picking up the old -exception-, didn't wait long enough
[03:10] <slangasek> nacc: oh, rather, php-horde-exception is still blocked by php-horde-mapi, so *definitely* didn't wait long enough
[04:22] <slangasek> nacc: php-horde-http still fails, and this time I don't know why because it was using the new php-horde-exception
[05:29] <pitti> Good morning
[05:30] <stgraber> good morning pitti
[05:32] <stgraber> pitti: the lxc adt failure on ppc64el is an actual regression, I just sent a branch upstream to fix it and cherry-picked the fix already. It's in the queue now if you have a minute to review.
[05:34] <pitti> stgraber: accepted, thanks
[05:35] <pitti> stgraber: wow, was the mirror default dropped accidentally, or was this somehow able to get along without ports.u.c. all this time?
[05:35] <stgraber> pitti: thanks, going to go get some sleep now :)
[05:35] <stgraber> pitti: the Debian maintainer sent a branch to set a default MIRROR so that debootstrap would be happy in Debian
[05:35] <stgraber> pitti: but he apparently didn't know that we don't have all arches on archive.ubuntu.com :)
[05:36] <pitti> stgraber: squid3> btw, you know debian/pkgname.maintscript ?
[05:36] <stgraber> pitti: (and I apparently suck at review and didn't notice it)
[05:36] <stgraber> pitti: I sure do and squid3 is a mess. I just uploaded it because I accepted a buggy one earlier and felt bad :)
[05:36] <pitti> heh, thanks
[05:37] <stgraber> also squid3 is cdbs... not that it matters much in this case, but it makes it just that much more painful to deal with
[05:54] <pitti> coreycb: can you please look at http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#swift ? your swift upload has been trapped by the regression for 3 weeks
[05:57] <pitti> yofel: FYI, baloo-kf5 segfaults during its tests on 32 bit (i386 and armhf); so it's been stuck in -proposed for 3 weeks already
[06:07] <alkisg> bdrung, bdrung_work, good morning, about xul-ext-adblock-plus, I see that you uploaded version 2.7.2+dfsg-1~ubuntu16.04.1~ppa1 a while ago, did you managed to get it to work with the extension signing etc?
[06:07] <alkisg> I managed to get the presigned .xpi to work with this command:
[06:07] <alkisg> # wget https://update.adblockplus.org/latest/adblockplusfirefox.xpi -O /usr/lib/firefox/browser/extensions/{d10d0bf8-f5b5-c8b4-a8b2-2b9879e08c5d}.xpi
[06:08] <alkisg> If there are no alternatives, maybe xul-ext-adblock-plus could just package the signed blob?
[06:09] <alkisg> Or is there some way that I'm unaware of, to get the 2.7.2+dfsg-1~ubuntu16.04.1~ppa1 to work for all users?
[06:10] <Unit193> https://sources.debian.net/src/firefox/45.0.1-1/debian/patches/prefs/Don-t-auto-disable-extensions-in-system-directories.patch/ :P
[06:14] <alkisg> Unit193, bdrung has already proposed a patch there: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1532484
[06:15] <alkisg> ....but chrisccoulson replied,  "This isn't something that we're going to be changing in Ubuntu", dunno why
[06:17] <Unit193> alkisg: Heh, was mostly kidding there, sorry that wasn't more clear.
[06:28] <mwhudson> can i get an Opinion
[06:29] <infinity> mwhudson: Grilled cheese sandwiches are best if you don't add anything other than the cheese.
[06:30] <Unit193> infinity: I like bread with mine.
[06:30] <RAOF> We have a new candidate for History's Greatest Monster: infinity!
[06:30] <mwhudson> i've been asked to sponsor a merge from debian, and it disables a feature in debian by not having the libxxx-dev package in build-depends
[06:30] <infinity> Not uncommon.
[06:30] <mwhudson> which seems a little smelly, it's fine for the buildds i guess but it means a developer building the package on her system might get different functionality
[06:31] <infinity> Generally to keep things out of main (or to avoid filing an MIR :P)
[06:31] <mwhudson> i guess the lesson here is "autoconf sucks"?
[06:31] <mwhudson> infinity: i think this is actually not the case here :-)
[06:31] <Unit193> mwhudson: Look at irssi.
[06:31] <infinity> mwhudson: Correctly, it should drop the build-dep *and* use --disable-feature, but people rarely bother with the latter.
[06:31] <mwhudson> infinity: it's to avoid an ffe i think :)
[06:32] <mwhudson> (it's tgt, there's stuff from you on the bug)
[06:32] <mwhudson> Unit193: do i have to? :-)
[06:32] <infinity> Is there?
[06:32] <Unit193> mwhudson: No.
[06:32] <mwhudson> infinity: ok, noted
[06:32] <infinity> I'm asked to comment on bugs often.
[06:32] <infinity> Refresh my memory?
[06:32] <mwhudson> infinity: https://launchpad.net/bugs/1555700
[06:32] <infinity> Was this the libaio thing?
[06:32] <mwhudson> infinity: you didn't comment, but irc logs were pasted
[06:33] <mwhudson> unless they were excellent forgeries of logs :-p
[06:33] <mwhudson> yeah, the aio thing
[06:35] <infinity> mwhudson: Anyhow, yeah, dropping the build-dep is a common way to achieve that.  Strictly speaking, you're right, and one would also either use Build-Conflicts or (more sanely) pass --disable-thing to configure, but Debian and Ubuntu have moved to a "there's no way we can conflict with everything correctly and specifying every single configure option is a pain" stance, combined with "oh, look, source uploads and clean build chroots", so...
[06:35] <infinity> mwhudson: Basically, yes, "the user's build might differ" sucks a bit, but also who cares.
[06:35] <mwhudson> infinity: ack
[06:39] <Unit193> d/control needs an easier way to have added build-deps in derivs, or 'build-recommends' to replace the silly dephere | something in main thing. :/
[06:40] <mwhudson> there must be some punctuation that doesn't have meaning to dpkg left, right?
[06:41] <infinity> We could build everything in ubuntu in an ubuntu build-profile, and you could use "Build-Depends: foo, bar <!ubuntu>, baz"
[06:41] <infinity> But really, the effort there would be convincing Debian maintainers to take your patch.
[06:42] <alkisg> In LTSP we've implemented directives like X-Ubuntu-Depends: etc to use the same packaging in both Debian and Ubuntu
[06:44] <Unit193> infinity: What if I'm the Debian maintainer?  ;)  Problem being, something Ubuntu isn't OK with either.
[06:45] <infinity> Unit193: Sure, if you're the Debian maintainer, it's a bit easier, but if you're the Debian maintainer, you also don't have a hard time tracking your own merges, I suspect. ;)
[06:45] <infinity> The real issue with Debian deltas are all the "lost" merges from drive-by bugfixes.
[06:45] <Unit193> infinity: Can't upload to Debian or Ubuntu, so moot on the sponsors queue.  And indeed. :/
[06:47] <Unit193> infinity: BTW, I'm right in thinking Ubuntu has the same stance as Debian on GPL/OpenSSL linkage?
[06:47] <infinity> Unit193: Yes.
[06:48] <Unit193> Figured, dang.
[06:48] <infinity> It's usually not hard to get upstream to agree to a license exception.
[06:48] <infinity> Especially if they wrote their application to use openssl. :P
[06:49] <Unit193> They did and would like it, but they won't as they can't contact all contributors.
[06:51] <infinity> Personally, I'm of the opinion that if the work is 100% original code and was obviously a derived work from day 1 (ie: it always linked to OpenSSL), the exception is implied, but that's not a particularly sane legal argument.  And falls down hard as soon as the project pulls in any GPL code from elsewhere, or if the openssl-using bits were written later, or...
[06:53] <Unit193> So I just end up building it too.  LibreSSL to save the day? /s
[06:54] <infinity> Unit193: LibreSSL would have the same issue, it's an OpenSSL fork.
[06:54] <Unit193> Anywho, I'll stop bugging you unless you feel 'uploady'.
[06:55] <infinity> I'm feeling more sleepy than uploady.
[06:56] <Unit193> 3am here.
[07:08] <mwhudson> oh hell why does trying to build things in my trusty schroot unmount my home directory :(
[07:09] <dholbach> good morning
[07:14] <infinity> mwhudson: Unmount it in your host, you mean, or fail to mount it in the schroot?
[07:14] <mwhudson> infinity: in my host
[07:14] <infinity> mwhudson: !
[07:14] <infinity> mwhudson: That's special.
[07:14] <mwhudson> infinity: adt-run did it once too!
[07:15] <mwhudson> but yes
[07:15]  * infinity resists the urge to get involved and sleeps instead.
[07:15] <mwhudson> i have the # Mount a large scratch space for the build, so we don't use up
[07:15] <mwhudson> # space on an LVM snapshot of the chroot itself.
[07:15] <mwhudson>  stuff in the schroot profile
[07:16] <mwhudson> which given i don't use lvm is probably a touch pointless
[07:16] <mwhudson> infinity: go to bed
[07:16] <infinity> mwhudson: If you use ephemeral chroots with a tmpfs for the overlay (like I do), then the scratch is useful.
[07:17] <mwhudson> i don't think i do that
[07:17] <mwhudson> union-type=overlayfs
[07:17] <mwhudson> anyway, go to bed :)
[07:17] <infinity> mwhudson: I use union-type=overlays combined with:
[07:17] <infinity> schroot         4.9G     0  4.9G   0% /var/lib/schroot/union/overlay
[07:18] <infinity> mwhudson: Which makes build-deps install basically instantly.
[07:18] <mwhudson> hm
[07:18] <infinity> But then I build in a scratch, cause disk speed at build time is less important.
[07:18] <infinity> # Mount a large scratch space for the build, so we don't use up
[07:18] <infinity> # space on an LVM snapshot of the chroot itself.
[07:18] <infinity> /var/lib/sbuild/build	/build	none	rw,bind		0	0
[07:18] <infinity> /home			/home	none	rw,bind		0	0
[07:18] <mwhudson> infinity: do you have encypted home dir?
[07:18] <infinity> Nein.
[07:18] <infinity> Full disk.
[07:19] <mwhudson> luks or something?
[07:19] <infinity> Or something, yes.
[07:20] <infinity> (oh, and lest that "schroot" confuse you, it's just this:)
[07:20] <infinity> schroot  /var/lib/schroot/union/overlay  tmpfs  defaults,size=25%  0 0
[07:21] <infinity> Basically, gets you best of both worlds.  tmpfs for build-dep installation (especially when also backed by a proxy of some sort) means that step happens in seconds, then the build happens on a real ext4 filesystem in the scratch dir and can take all the space it wants (and not suffer weird bugs due to being on overlayfs)
[07:22] <mwhudson> yeah i have squid-deb-proxy installed and omg i'm so glad i did that
[07:22] <infinity> home mounted for sbuild profiles is entirely optional, but I'm lazy and reuse the same "custom" profile for sbuild and schroot.
[07:50] <bdrung_work> alkisg, no update on the signing issue.
[07:50] <mwhudson> well that was all very exciting
[07:50] <mwhudson> there is a bug about this, apparently fixed in xenial
[07:51] <mwhudson> (i'm still on wily)
[07:51] <mwhudson> grabbing the schroot packaged from xenial didn't fix the problem though
[07:51] <alkisg> bdrung_work: are you interested in packaging the signed .xpi? Or should I do that in some PPA of my own, until some other method is found?
[07:52] <mwhudson> https://bugs.launchpad.net/ubuntu/+source/schroot/+bug/1430557
[07:52] <alkisg> chrisccoulson, is it possible to get a reason why bdrung_work's patch for signed extensions can't be accepted?
[07:53] <bdrung_work> alkisg, i am against packaging signed xpi file as they are not the preferred form for modifications
[07:53] <alkisg> bdrung_work, ok, thanks, I'll override the xul-adblock-plus package from my ppa
[07:55] <bdrung_work> alkisg, as alternative, you can still disable the signed xpi check in about:config
[07:55] <alkisg> bdrung_work: I tried with lockPref and it's not working for all users that way
[07:55] <alkisg> For single users, it does work
[07:55] <alkisg> *per user
[07:56] <alkisg> I don't want to have to tell to all the 5-10 year old students how to go to about:config...
[07:56] <bdrung_work> valid point
[07:56] <alkisg> I also asked chrisccoulson for a reason behind his refusal in your bug report, but no reply there either
[07:56] <alkisg> Debian did accept a similar patch...
[07:58] <jamespage> morning all
[08:01] <Unit193> alkisg: And you can't just override it in something like  /usr/lib/firefox/browser/defaults/preferences/unit193.js  ?
[08:03] <alkisg> Unit193: for some reason, the usual method for overriding it doesn't work... I tried: lockPref("xpinstall.signatures.required",false);
[08:03] <alkisg> It did disable it in about:config, yet it was not actually working
[08:04] <alkisg> Maybe the firefox devs are thinking that this is a very significant to allow it to be overriden by the sysadmin, they want it per user? dunno.
[08:04] <alkisg> *a very significant setting
[08:07] <Unit193> Actually meant like Debian did, but again not tested that I just ship signed. :P
[08:07] <alkisg> Debian patches firefox (iceweasel) afaik
[08:08] <alkisg> bdrung also proposed a patch for firefox, but it's not getting accepted...
[08:08] <alkisg> OK thank you guys, I'll package the adblock plus blob in a PPA
[08:10] <Unit193> (It's actually just 'firefox' now.)
[08:13] <alkisg> Ah, nice!
[09:49] <Saviq> pitti, hey, did you recover over Easter?
[09:52] <Saviq> pitti, have a question about britney - we've removed the only test from qtmir and qtmir-gles (because it was a "does-it-build" test, not suitable for britney, especially in the new trigger-based britney)
[09:52] <Saviq> now britney will complain that this is a regression because there's no tests at all
[09:53] <Skuggen> infinity: Patched mysql-5.7 to work around the dbconfig issue. Seems to work fine, so once rbasak is back tomorrow we can do another upload, I think
[09:53] <Skuggen> elbrus: ^
[09:55] <pitti> Saviq: I did recover, thanks! I hope you had some nice holidays too
[09:56] <Saviq> pitti, actually now looking at http://autopkgtest.ubuntu.com/packages/q/qtmir/ maybe it's ok with it after all...
[09:57] <pitti> Saviq: qtmir does not have a Testsuite: any more, so why would britney try to run a test for it?
[09:57] <pitti> Saviq: do you have the excuses URL of that silo?
[09:58] <Saviq> pitti, seems to be running here https://requests.ci-train.ubuntu.com/static/britney/vivid/landing-066/excuses.html
[09:58] <pitti> Saviq: oh, is that the silo that drops the test?
[09:59] <Saviq> pitti, no, the test is dropped in trunk already
[09:59] <pitti> Saviq: it's "always failed", so it won't block anything
[09:59] <Saviq> https://bazaar.launchpad.net/~mir-team/qtmir/trunk/revision/461
[10:00] <pitti> Saviq: and gsettings-qt should run against the qtmir in the archive/overlay, not in the silo
[10:00] <Saviq> pitti, ok let's see how it fares, I think it was less happy on xenial, but there's no excuses for that yet
[10:00] <pitti> but if that still has the tests, they will just run the old one, and if it's the new package without tests it wouldn't be triggered any more
[10:00] <Saviq> pitti, ok, I'll let you know if I have trouble after all, thanks
[10:00] <pitti> Saviq: ack, thanks
[10:53] <Saviq> pitti, yeah, it's unhappy on xenial for some reason https://requests.ci-train.ubuntu.com/static/britney/xenial/landing-066/excuses.html
[10:54] <Saviq> pitti, what's also weird is that it's not running tests for unity8 for some reason
[10:54] <Saviq> and don't ask me what's "-ginkgocadx"
[12:10] <pitti> Saviq: ah, qtmir in landing-066 xenial still has Xs-Testsuite: autopkgtest
[12:10] <pitti> Saviq: so apparently this somehow came back
[12:10] <pitti> or wasn't removed properly
[12:15] <doko> mwhudson, docker.io ftbfs on s390x
[12:24] <Saviq> pitti, oh.... debian/control... forgot to remove in there indeed, will have a follow-up MP
[12:24] <Saviq> pitti, any idea why unity8 tests don't run there? it's in the silo...
[12:26] <Saviq> huh... it doesn't have Xs-Testsuite: autopkgtest ¿?
[12:27] <pitti> Saviq: unity8 lost its Testsuite: header
[12:27] <Saviq> waaat
[12:27] <pitti> (XS- prefix is obsolete, btw)
[12:27] <Saviq> wonder if it ever had it...
[12:27] <pitti> and normally it is being added automatically
[12:27] <pitti> if there's a d/t/control
[12:28] <pitti> nope, no debian/tests/ in unity8
[12:28] <Saviq> but it's there... https://bazaar.launchpad.net/~unity-team/unity8/trunk/files/head:/debian/tests/
[12:31] <Saviq> pitti, why do you say it has no d/t/control?
[12:31] <Saviq> https://launchpadlibrarian.net/250392626/unity8_8.12+16.04.20160330-0ubuntu1.diff.gz lists it (granted, no XS-Testsuite: autopkgtest - since it was added automagically as you say)
[12:31] <pitti> Saviq: erk, sorry, was mis-looking at qtmir
[12:31] <Saviq> maybe it's not auto-added any more and we need it explicit now?
[12:31] <pitti> http://ppa.launchpad.net/ci-train-ppa-service/landing-066/ubuntu/dists/xenial/main/source/Sources.xz does not have the header, though
[12:32] <pitti> or maybe it's only added for v3 sources, not sure how dpkg handles that
[12:32] <Saviq> ok, so we need that header explicit now, /me will add (and drop from qtmir)
[12:32] <pitti> but xenial's unity8 has a Testsuite: header, the PPA doesn't
[12:32] <Saviq> that explains things, thanks pitti
[12:33] <pitti> Saviq: oooh!
[12:33] <pitti> Saviq: there's no relevant diff in the source
[12:34] <pitti> Saviq: but robru recently changed to building sources not in a schroot
[12:34] <Saviq> probably
[12:34] <pitti> and I bet he's using the old trusty dpkg-dev to build the sources, that doesn't add Testsuite: yet
[12:34] <pitti> before we'd have used xenial's dpkg-dev to build sources
[12:34] <Saviq> yup
[12:35] <pitti> that explains why the header isn't auto-added any more
[12:38] <xavigarcia> pitti: Hi there!
[12:38] <pitti> hello xavigarcia
[12:38] <xavigarcia> pitti: I'd like to ask you a question about upower
[12:38] <xavigarcia> pitti: I'd need to change the configuration ONLY for the phone... to use percentages and poweroff the phone
[12:39] <pitti> xavigarcia: that's a matter of presentation
[12:39] <xavigarcia> pitti: do you know if there's any other way to overwrite the config file other than using dpkg-divert?
[12:39] <pitti> upower tells you percentages and absolute limits
[12:39] <pitti> and it does not "power off" the phone
[12:40] <pitti> oh, for critical action you mean
[12:40] <pitti> sorry, I thought you meant the hold reboot/shutdown API
[12:40] <xavigarcia> pitti: I did some tests last week, and it did it... yeah... it's for the critical action
[12:40] <pitti> xavigarcia: it's a conf file, so you can just change the values
[12:41] <xavigarcia> pitti: this is the MR I wanted to land: https://code.launchpad.net/~xavi-garcia-mena/ubuntu/vivid/upower/percentages-power-off/+merge/289935
[12:41]  * ogra_ would do it from a livecd-rootfs hook script (as i said in the other channel)
[12:41] <pitti> does HybridSleep really work on a phone?
[12:41] <pitti> and hibernate?
[12:42] <pitti> I would have thought we disable that, and let it fall back to power off
[12:42] <xavigarcia> pitti: I neede to change it to PowerOff
[12:42] <xavigarcia> pitti: that's the main change in the config
[12:42] <ogra_> hibernate doesnt (not enough swap)
[12:44] <ogra_> according to the comment that should automatuically fall back to PowerOff without you doing anything
[12:45] <pitti> so I'd think that it's easiest to keep such config changes central in the image build scripts (livecd-rootfs), otherwise just change the file and put that into the overlay
[12:45] <ogra_> yeah
[12:46] <xavigarcia> pitti ogra_: that was my initial intention
[12:46] <xavigarcia> pitti, ogra_: that's why I already had the MR, but Pat was asking to do that in a separated package
[12:48] <xavigarcia> pitti, ogra_: but as upower is already managing the config file I don't see any other way to do that than using dpkg-divert
[12:48] <ogra_> xavigarcia, just use sed
[12:48] <pitti> no, don't divert a conffile, this is going to blow up
[12:49] <xavigarcia> ogra_, pitti: well, that's another option, but not the best, as the config file is still maintained by upower :/
[12:49] <ogra_> thats fine on the phone, really
[12:49] <xavigarcia> ogra_, pitti: I think I will retry the overlay again
[12:49] <ogra_> we dont support apt upgrades
[12:49] <pitti> well, you never dist-upgrade that anyway
[12:50] <xavigarcia> ogra_, pitti: oh, ok... thanks for the reminder!
[12:50] <ogra_> sed -i 's/^UsePercentageForPolicy=.*/^UsePercentageForPolicy=true/' /path/to/UPower.conf
[12:50] <ogra_> just put something like that in a livecd-rootfs hook script
[12:51] <xavigarcia> ogra_ we could maybe add that to the ubuntu-phone-session package...
[12:51] <xavigarcia> sorry, ubuntu-touch-session
[12:51] <ogra_> nah, just do it at build time
[12:52] <ogra_> no need to run that every session startup and to slow down the start
[12:52] <xavigarcia> ogra_ but in fact...if we apply it at build time... what would be the difference to adding it to the config file?
[12:52] <ogra_> bzr branch lp:livecd-rootfs ...
[12:53] <ogra_> add your snippet under: live-build/ubuntu-touch/hooks/
[12:53] <ogra_> and creat an MP from that
[12:53] <ogra_> the difference is that it will also apply if you switch to a new upower version without you having to hack the package
[12:54] <xavigarcia> ogra_: I see.... thanks for the pointers!
[13:13] <xavigarcia> ogra_: Could you please take a look to the following MP? https://code.launchpad.net/~xavi-garcia-mena/livecd-rootfs/bug-1317860-upower-poweroff-phone-only/+merge/290454
[13:13] <xavigarcia> ogra_: I've assigned it to you... the config change was already reviewed last week in the following MP: https://code.launchpad.net/~xavi-garcia-mena/ubuntu/vivid/upower/percentages-power-off/+merge/289935
[13:14] <xavigarcia> ogra_: it was rejected after Pat asking to do it in a different way... but it was previously approved
[13:18] <ogra_> xavigarcia, commanted ... please give it to sil2100 to merge it in the overlay livecd-rootfs though
[13:18] <ogra_> *commented even
[13:19] <xavigarcia> ogra_: cool... thanks!
[13:19] <ogra_> i'm happy to merge it in xenial once it landed in teh overlay (for consistency)
[13:19] <xavigarcia> sil2100: ^
[13:20] <xavigarcia> sil2100: please see ogra's messages and my MP link
[13:29] <pitti> Saviq: FYI, I just deployed the fix for bug 1544917
[13:35] <Saviq> pitti, ack, thanks :)
[13:52] <sil2100> o/
[13:54] <sil2100> xavigarcia: on it
[13:55] <xavigarcia> sil2100: great, thanks!
[14:10] <caribou> slangasek: just saw LP: #1563027 after doing the work on this this morning
[14:42] <slangasek> caribou: well, it's all yours :)
[14:42] <caribou> slangasek: just wondering if I should just revert the value or wait to hear from the DM first
[14:44] <slangasek> caribou: IMHO there's no need to revert, this is pretty much the only change in -proposed and it can just sit there until resolved
[14:44] <caribou> slangasek: thought so; I'll wait to hear about the DM then
[14:53] <rharper> slangasek: I'm testing wily squid3 upgrade to xenial with the existing proposed package;  I'm trying to confirm if a wily -> xenial upgrade also trips the same logic from debian and if the /etc/init.d/squid3 service file exists (where it didn't for trusty -> xenial upgrade);
[15:04] <nacc> ha! as brief as it might be, excuses is nearly php clean right now :)
[15:05] <nacc> slangasek: thanks for all your help, as usual!
[15:05] <teward> is the ubuntu-server metapackage new in Xenial?
[15:05] <nacc> slangasek: just sent another sync request which will clear out the remaining one that should be fixed
[15:05] <teward> I... just answered my question
[15:05] <nacc> teward: looks like it acc'g to rmadison
[15:06] <teward> nacc: i have a question as to why lxc is installed as part of it by default
[15:06] <teward> :/
[15:06] <nacc> teward: it's on the server seed
[15:10] <ogra_> is it ?
[15:10]  * ogra_ thought it was added to -standard
[15:10] <nacc> lxc (from lxc) is seeded in:
[15:10] <nacc>   ubuntu-server: daily
[15:11] <ogra_> i wonder why (given we (will) have it in desktop by default as well)
[15:11] <ogra_> standard would seem more logical
[15:12] <slangasek> standard is inherited by all flavors; this is an Ubuntu Server+Desktop product decision
[15:13]  * teward scratches his head
[15:13] <doko> openjdk-7 demoted
[15:14] <ogra_> slangasek, ah, but that means not all ubuntu features will work in all flavours
[15:14] <teward> ogra_: i'm going to stop the !crosspost that i appear to be doing, and going to stick to here specifically, did I miss an email chain where this was discussed?
[15:15]  * teward might have, receiving too many emails a day
[15:15] <ogra_> not sure if there were mails
[15:15] <ogra_> theer were definitely several announcements that it will come in 16.04 throughout the development cycle
[15:15] <ogra_> and at UOS
[15:16] <teward> mmm, well i've been so engrossed in nginx lately and my own studies I guess the mails slipped by me
[15:16] <slangasek> ogra_: if you expect this to land in standard, you'd better start a discussion with the flavor teams via ubuntu-devel
[15:16] <teward> it seems odd, though, that container support would be needed - but I think this needs to be discussed more, because if it's included on every server, and they never use it, why should it be in the ubuntu-server seed *shrugs*
[15:17] <teward> my own opinion though :)
[15:17] <teward> and by 'they' i mean any user of the server installer and server flavor of Ubuntu
[15:17] <ogra_> slangasek, i dont expect it anywhere ... it was just my assumption that we call it a default ubuntu feature nowadays (iirc it is also the base of supporting snappy packages which i imagine flavours would like)
[15:17] <teward> oh that explains it :)
[15:17]  * teward facedesks
[15:18] <ogra_> but i trust the persons that made the decision that they thought about it ;)
[15:18] <ogra_> teward, why is that ...
[15:18] <teward> ogra_: well, afaict it's not in -standard, only -server.  the head-scratching left behind makes me think that if it should be in -standard but isn't, then there's something missing
[15:18] <teward> ogra_: because i'm old fashioned :)
[15:18]  * ogra_ will surelöy prefer to run servers as snappy packages over debs at any time
[15:19]  * teward comes from the world of old-fashioned "Start with absolutely basic, add what's necessary"
[15:19] <ogra_> yeah
[15:19] <teward> ogra_: indeed, but once I saw you state that it's the base of snappy packages, that answered the question
[15:19] <teward> as i said, "oh that explains it :)"
[15:19] <ogra_> right
[15:19]  * teward isn't well versed in Snappy yet
[15:27] <slangasek> rharper: so, followed up to the squid3 bug with more explanation.  I think you overlooked that trusty was upstart-only, there was no init script shipped in the package in trusty; /this/ is why the upgrade path behaves differently between trusty and wily
[15:28] <rharper> slangasek: ok;  I'm trying to figure out if this is something we introduced or are just incompatible with the postinst from debian;  it sounds like we need to do something different since debian didn't deal with upstart service scripts?
[15:29] <slangasek> rharper: you need to do what I outlined in the bug
[15:29] <rharper> slangasek: perfect, thanks
[15:44] <nacc> slangasek: question on mythtv: currently, there are no conffile listed for mythweb; is that expected?
[15:47] <teward> ogra_: I think we need to have lxc defaults changed
[15:48] <teward> ogra_: lxcbr0 on a default install is given 10.0.3.1, but this conflicts in my own network - I have many maps in the 10.* IP space around, and I bet there will be IP range conflicts like this in other deployments
[15:48] <teward> (default install of Server)
[15:48] <ogra_> teward, file a bug :)
[15:49] <teward> would if LP would respond to me trying to reaoch it
[15:49] <ogra_> (i'm not in any way an lxc guy ... better talk to stgraber )
[15:49] <cyphermox> teward: there might be conflicts in any possible range one might pick
[15:49]  * teward blames Comcast
[15:50] <teward> cyphermox: true, but then this brings up other questions: if it's likely to cause IP conflicts and routing conflicts, why is it in the standard images again?
[15:50] <teward> i know ogra stated Snappy, but it brings up more questions then
[15:50] <slangasek> nacc: I have no idea; what do you see in mythweb that you think should be a conffile
[15:50] <slangasek> ?
[15:50] <teward> s/then/than answers/
[15:50] <nacc> slangasek: the one you wanted me to move, /etc/php5/apache2/conf.d/20-mythweb.ini
[15:51] <cyphermox> that isn't my call. I'm just saying that no matter what app, no matter what IP range you'll pick, you'll always run the risk of conflicts since it's all an arbitrary thing in a finite pool of resources
[15:52] <slangasek> nacc: guess I should look ;)
[15:52] <nacc> slangasek: for reference, LP: #1562184
[15:52] <teward> guess i'll bring up my concerns at the server team meeting then
[15:52] <teward> 'cause that's where it's incorporated by default
[15:53] <stgraber> twlxcbr0 is disappearing in a few days
[15:53] <nacc> teward: --^
[15:53] <stgraber> we're just waiting for juju to be done switching to lxdbr0 and then we can have lxd stop pulling lxcbr0 into the cloud and server images
[15:53] <teward> ah
[15:54] <teward> stgraber: okay, that makes sense, because the ISO i tested last week with regards to the keyboard layout selection thing not working didn't have this. the iso I have from yesterday's batch (20160329) had it, and it actually broke net routing when the thing first came up (same subnet ranges due to overlap, so routing blew up)
[15:55] <teward> I have a workaround temporarily in my installation, but eh
[15:55] <stgraber> hmm, lxcbr0 has been around by default in all images since wily (for server and cloud), so if you didn't have it before, that was a bug :)
[15:55] <teward> stgraber: i never tested wily :P
[15:55]  * teward shrugs
[15:56] <slangasek> nacc: $ dpkg-deb -R ubuntu/pool/multiverse/m/mythtv/mythweb_0.28.0+fixes.20160325.2520617-0ubuntu2_all.deb mythweb
[15:56] <slangasek> $ cat mythweb/DEBIAN/conffiles
[15:56] <slangasek> /etc/default/mythweb
[15:56] <slangasek> /etc/php5/apache2/conf.d/20-mythweb.ini
[15:56] <slangasek> $
[15:56] <teward> in any case, i'm not a fan of routing blowign up in my face on a default setup
[15:56] <teward> fortunately it's a VM that I can recreate, assign to different subnets, etc. but
[15:56] <slangasek> nacc: so, that looks like a conffile to me; not sure where you were looking, but DEBIAN/conffiles is authoritative (and with a modern package, is autopopulated by debhelper based on "is this file in /etc Y/N?")
[15:57] <nacc> slangasek: weird, apt doesn't show it; but does in my rebuilt one (which was buggy, fixing still) that included dpkg-maintscript-helper
[15:58] <slangasek> nacc: I'm not aware of any option to apt to show conffiles
[15:58] <nacc> slangasek: it does by default, or did for my package
[15:58] <nacc> which is why i was confused :)
[15:58] <slangasek> when running what command?
[15:58] <nacc> apt-cache show ...
[15:59] <slangasek> nacc: ok, not sure why that ever showed you conffiles, I've never known it to do so and it doesn't here :)
[15:59] <nacc> slangasek: for refrence, http://paste.ubuntu.com/15560435/
[16:00] <nacc> i wonder if it's something that dpkg-maintscript-helper does
[16:01] <cyphermox> slangasek: when the package is installed?
[16:01] <nacc> cyphermox: yeah, i had the older version installed, though, and it doesn't show any
[16:02] <nacc> cyphermox: testing the upgrade path
[16:02] <nacc> hence my confusion :)
[16:02] <cyphermox> (that's my guess, I see conffiles for n-m, but only for the specific version installed, not others in cache)
[16:04] <nacc> slangasek: cyphermox: well, either way, it's fine, i think i see what i did wrong with my change. But was curious
[16:11] <rharper> slangasek: looking at 'removing etc/init.d/squid3 on upgrade';   IIUC, the new package scripts that get called are newpkg.preinst and newpkg.postinst;  the preinst script is called with 'upgrade' but postinst is called with 'configure' ; should I attempt to remove the old service script in preinst then (when $1 is upgrade)? or just test for existence in postinst and remove there during configure?   the ideal spot seem
[16:11] <rharper> s to be (previous version of squid's postrm upgrade call; which could remove old files) but that doesn't seem right since the current package doesn't do that;
[16:29] <robru> pitti: yes, train is trusty. let me know if you need me to backport dpkg-dev or something.
[16:30] <infinity> rharper: Or, use dpkg-maintscript-helper?
[16:34] <slangasek> rharper: you should call dpkg-maintscript-helper with the appropriate args, unconditionally
[16:35] <slangasek> cyphermox: my test case for this was 'apt-cache show base-files', which certainly should be installed ;)
[16:35] <cyphermox> hrm, fun ;)
[16:36] <cyphermox> ah, maybe there's something there
[16:36] <cyphermox> n-m show Status: install ok installed
[16:36] <cyphermox> base-files doesn't
[16:37] <cyphermox> that said, I don't think that's the cause of my upgrade bugs ;)
[16:37] <slangasek> cyphermox: right, which means somehow your apt-cache show is merging contents from /var/lib/dpkg/status (which is also where the Conffiles are), maybe that's what you're seeing for a package that's installed but is *not* available at that version in the cache?
[16:38] <cyphermox> I see three versions of n-m in cache, one of which is the one installed
[16:39] <nacc> it might be explainable, but IMO violates the principle of least surprise :)
[16:39] <nacc> as the version in /var/lib/dpkg/status, here (of base-files) is the one installed
[16:39] <nacc> and /var/lib/dpkg/status does list hte conffiles entries
[16:40] <nacc> while apt-cache show does not
[16:40] <nacc> dunno how it decides :/
[16:40] <slangasek> cyphermox: well, yes it's in the cache but I'm guessing 'apt-cache policy' shows it as locally installed and not available from any source
[16:41] <cyphermox> ah, maybe yeah
[17:48] <slangasek> nacc: I notice a few of the tasks on LP: #1544352 are stuck as fix committed; at least one of these, jquery-goodies, seems to be a case of the upload going missing.  Can you double-check these and set them back to a non-fix-committed state for me if I need to reupload?
[17:49] <nacc> slangasek: will do
[17:51] <slangasek> nacc: and sorry, on mythweb I guess I should have explained more about dpkg-maintscript-helper.  While this is the maintainer script interface, you should never put this in the maintscripts directly (because DRY); this ought to be in debian/mythweb.maintscript instead, which debhelper (via dh_installdeb(1)) will pick up and include
[17:51] <slangasek> nacc: do you want to redo, or should I go ahead and fix it up on my side?  the latter is probably faster overall
[17:51] <nacc> slangasek: ah interesting; i was just going off `man dpkg-maintscript-helper` and a few other exampels in the archive already
[17:52] <nacc> slangasek: should we modify that manpage? as it explicitly says to do what i did :)
[17:52] <slangasek> nacc: yeah, the 'SEE ALSO' at the bottom of that manpage is unfairly subtle
[17:52] <nacc> heh
[17:52] <slangasek> and yes, +1 for better documentation
[17:52] <nacc> slangasek: if you can fix it up, that's fine with me -- the change is logically the same to me
[17:52] <slangasek> I'm sure your maintainer script snippets are technically correct, they're just unmaintainable ;P
[17:53] <nacc> right
[17:54] <slangasek> nacc: btw, mythtv is stuck in -proposed for un-php reasons (mysql-5.7).  maybe that's something that could use a bit of help?
[17:54] <nacc> slangasek: i think it's a known thing that rbasak is working on
[17:54] <nacc> but let me check
[17:54] <slangasek> ok
[17:55] <nacc> yeah it's the mysql 5.7 transition stuff, which is blocked right now while they verify the upgrade path
[17:56] <slangasek> nacc: ah, also your patch is against the xenial version of mythtv, not the xenial-proposed... will fix
[17:57] <nacc> slangasek: argh, sorry! i think it should be pretty similar
[18:04] <rharper> infinity: slangasek: thanks!  should prior-version include the XubuntuY part of the previous versions or just the source version ?
[18:05] <infinity> rharper: The manpage has a whole section on how to select prior-version correctly.
[18:05] <rharper> hrm
[18:05]  * rharper rereads
[18:05] <infinity> COMMON PARAMETERS
[18:05] <infinity>        prior-version
[18:05] <infinity> (three paragraphs follow)
[18:07] <infinity> rharper: TLDR; you probably want it to be 3.5.12-1ubuntu4~
[18:08] <infinity> rharper: Except... Wait.  Which conffile are you removing?
[18:08] <rharper> infinity: I've read those now, 3 times;  it's not clear to me yet;
[18:08] <rharper> infinity: /etc/init.d/squid3
[18:08] <infinity> rharper: Cause stgraber already did that in the last upload.
[18:08] <infinity> http://launchpadlibrarian.net/250372995/squid3_3.5.12-1ubuntu2_3.5.12-1ubuntu3.diff.gz
[18:10] <rharper> infinity: ok, let me look at 1ubuntu3 then;  and see what else i need to do as slangasek help figure out for fixing upgrade paths
[18:12] <sladen> kirkland: kudos for the press coverage
[18:17] <ricotz> infinity, hi, would you have a moment to sync a package? https://bugs.launchpad.net/ubuntu/+source/plank/+bug/1563778
[18:20] <infinity> ricotz: Iz done.
[18:22] <ricotz> infinity, thank you!
[18:45] <elbrus> Skuggen: thanks (I don't think you are "working around the dbconfig issue", but rather "give the world some time to adjust to the new mysql behavior")
[19:54] <doko> slangasek, your mythtv upload has a .orig left. do you want to re-upload?
[19:54] <slangasek> doko: I certainly don't /want/ to ;)
[19:54] <doko> ok, I'll do it
[20:06] <mwhudson> doko: i know about docker.io/s390x, arguing with ibm about it
[20:06] <Skuggen> elbrus: Yeah, I agree that going straight from silently accepting the behavior to throwing errors is a bit sudden :)
[20:06] <elbrus> yup, I read your upstream bug report
[20:06] <slangasek> mwhudson: is xnox in the loop on said arguing? :)
[20:07] <Skuggen> At least for options like port where an empty value will work
[20:07] <mwhudson> slangasek: no, but i can add him i guess
[20:08] <mwhudson> arguing is sort of the wrong word
[20:08] <mwhudson> commiserating
[20:08] <mwhudson> (the whole situation is just painful)
[20:08] <slangasek> heh
[20:11] <mwhudson> here is the pain: https://go-review.googlesource.com/#/c/20949/2
[20:12] <slangasek> ahaha fun
[20:13]  * doko looks at updating lua ...
[20:20] <slangasek> doko: because... ?
[20:25] <infinity> slangasek: I can haz verbal +1 on merging lintian so it stops whining about my packages living in the future?
[20:25] <slangasek> infinity: is that about Standards-Version?
[20:25] <infinity> slangasek: Standards-Version and uscan/watch version, in my case.
[20:26] <doko> infinity, slangasek: so which of the NEW packages would be still appropriate? trying to look at the go uploads from December
[20:26] <slangasek> infinity: weak verbal +1, would still want a queue review, though I guess lintian isn't release-critical
[20:26] <infinity> slangasek: Will stage in my staging PPA to make sure the testsuite doesn't completely blow up like it does on every single merge. :P
[20:27] <slangasek> doko: per standing policy, any of them are "appropriate", some of them are higher priority than others.  I have dibs on tpm2-* though
[20:27] <infinity> doko: The go ones are totally appropriate, if they pass review.
[20:32] <infinity> slangasek: Ooo.  How long until archive reorg? :)
[20:32] <infinity> slangasek: lintian could be a sync if it was done. :P
[20:33]  * infinity will merge it with a lower-than-debian version so we can sync over when we get there.
[20:48] <xnox> mwhudson, is that what makes docker.io FTBFS in xenial now? =)
[20:48] <mwhudson> xnox: yes
[20:49] <xnox> mwhudson, enjoy! i'm glad i don't support packages in universe. And slangasek will back me up on that =)
[20:49]  * xnox goes back to hacking curtin, MAAS and all things nice
[20:49] <infinity> doko: If you have a moment https://bugs.launchpad.net/ubuntu/+source/libdata-alias-perl/+bug/1564082
[20:50] <cjwatson> infinity: by not-very-much-coincidence I was just starting work on the LP changes to allow tweaking the ogre model
[20:50] <infinity> cjwatson: I assume we're all agreed on what that model is.
[20:51] <cjwatson> AIUI it should allow supported to b-d on unsupported but free must still only b-d on free.
[20:51] <infinity> cjwatson: Bingo.  I figured we'd both reach that obvious conclusion without external influence anyway.
[20:52] <cjwatson> so {main, universe} -> main universe, {restricted, multiverse} -> main restricted universe multiverse
[20:52] <cjwatson> and it'll be a flag on distroseries so that we can quickly flip the behaviour back if it breaks
[20:52] <infinity> xnox: Oh.  I should have told you that I already tried -fno-pie -no-pie on s390x and it didn't help.
[20:52] <cjwatson> (do analyse as much as possible beforehand though ...)
[20:53] <infinity> xnox: (for glib2.0)
[20:54] <xnox> infinity, yeah, it doesn't look like pie issue. pie things don't hang usually, just misbehave in wtf ways.
[20:54] <xnox> unless it's ftw ways, then you know it's an endian issue =)
[20:54] <infinity> xnox: PS, try not to use the archive as test-build infra. :P
[20:55] <infinity> Oh.
[20:55] <xnox> infinity, i have enough test-build infra =) but yeah, retry build was unnecessary
[20:55] <infinity> I can't read.
[20:55] <infinity> That was doko doing that.
[20:55] <xnox> infinity, unless we get a notes field and/or "disable retry button"
[20:55] <infinity> doko: I already tried -fno-pie -no-pie for glib2.0, that's not the issue, sadly.
[20:55] <doko> infinity, done
[20:55] <xnox> people will keep stabbing things
[20:56] <pitti> robru: the "auto-add Testsuite: field" does seem to cause some trouble indeed; I guess backport vs. fixing packages is between you and sil2100, but if it's not too hard to run this on xenial that might be easier
[20:56] <infinity> doko: And thanks on the MIR.
[20:56] <doko> xnox, infinity: I'm tempted to not run the tests on s390x, they succeed on a local machine
[20:57] <doko> but having the glib2.0 for the test rebuild would be nice
[20:57] <infinity> doko: They do?  They sure didn't work for me when I was testing...
[20:57] <infinity> doko: Is your local machine up to date?
[20:57] <xnox> doko, what's your libc and kernel?
[20:57] <doko> infinity, at least with -no-pie
[20:57] <xnox> is that devac02?
[20:57] <mwhudson> xnox: yeah, i'll get this sorted one way or another
[20:57] <doko> yes
[20:57] <robru> pitti: i do intend to update to xenial shortly after its release as we currently rely on many backports and I'd like to get rid of that. Can you file a bug explaining the issue in more detail?
[20:57] <mwhudson> xnox: my main concern is getting the same thing into xenial as will go into 1.6
[20:57] <xnox> doko, devac02 may have be running a hacked up kernel from apw
[20:57] <mwhudson> er 1.7 i mean
[20:58] <mwhudson> although even then we can cope
[20:58] <robru> pitti: not sure how urgent this is, if you can wait until after xenial is released or if we should fix it sooner.
[20:58] <infinity> xnox: If it works on that machine with an up-to-date glibc, that would be a good datapoint.
[20:58] <infinity> xnox: Then we can go kernel bisecting.
[20:59] <xnox> 2.23-0ubuntu2
[20:59] <xnox> 4.4.0-16-generic
[20:59]  * infinity raises his brow.
[21:00] <infinity> Is that the archive's -16, or something else?
[21:00] <infinity> cat /proc/version_signature
[21:00] <xnox> Ubuntu 4.4.0-16.32-generic 4.4.6
[21:00] <infinity> orly.
[21:01] <xnox> hm... i wonder what libc is inside the doko's chroot though
[21:01] <infinity> Okay, let me update a buildd to that and smack the retry button.
[21:01] <infinity> Oh, check his chroot first. :P
[21:01] <doko> xnox, all current from proposed
[21:01] <infinity> Okay, lemme doctor up a buildd with the new kernel.
[21:01] <xnox> also 2.23-0ubuntu2
[21:02] <xnox> infinity, yeah that's a thought
[21:03] <pitti> robru: done, bug 1564084
[21:03] <pitti> Saviq: ^
[21:03] <robru> pitti: thanks
[21:05] <infinity> xnox: Alright, building with new kernel.
[21:08] <infinity> xnox: OTOH, I see nothing in the -16 upload that would relate to this.
[21:09] <infinity> xnox: Can I get some SSH love to the machine where it works?
[21:09] <doko> tumbleweed, https://bugs.launchpad.net/ubuntu/+source/pypy/+bug/1564088
[21:16] <nacc> Pharaoh_Atem: can you sync up with ondrej and remi and find out what is to be done with php-horde-mongo? php-mongo is deprecated with php7, i afaict
[21:20] <tumbleweed> doko: I'm still deciding about another patch (slow test builds are slow)
[21:22] <mwhudson> the way packages disappear from the +source page while they're in the process of migrating from -proposed to -release is pretty odd
[21:28] <infinity> mwhudson: Hit the publishing history, it'll show it's pending publication.
[21:28] <infinity> mwhudson: But yes, that "pending" should be on the previous page, many of us agree.
[21:29] <mwhudson> infinity: yeah i've discovered that trick
[21:29] <mwhudson> however i've already done my time in the launchpad slave pits, not going to try to fix this one :)
[21:29] <infinity> Heh.
[21:31] <sarnold> better luck with the next new core-dev :)
[21:32] <infinity> sarnold: Better a core-dev unwilling to look at LP bugs than one who enjoys LP bugs so much that he defects.
[21:32] <infinity> cjwatson: Traitor.
[21:32] <sarnold> lol
[21:35] <doko> mwhudson, you didn't yet hear about the archive slave pits ...
[21:35] <mwhudson> doko: i am learning every day!
[21:38] <slangasek> xnox: ahhh I see, so you fix build failures on s390x in universe when it suits you, and then when it regresses and you don't want to deal with it, it's mwhudson's problem ;)
[21:39] <mwhudson> docker broke because of a golang upload i did, i think you'll have a hard time blaming this one on xnox
[21:40] <nacc> Pharaoh_Atem: i think i need to use a pkg-php-tools-override and specify php-mongodb as the php7 compliant version
[21:51] <nacc> Pharaoh_Atem: actuall, nm, it's not clear that's going to work, as php-mongodb is quite a bit different
[21:57] <nacc> slangasek: so depending on the above --^ (and i've also filed a ticket with upstream horde), php-horde-mongo is going to be uninstallable for a bit
[22:02] <simon_g> hi
[22:03] <simon_g> i'm not sure if it's a proper channel, but I got a rather surprising error while compilling kernel on the newest (beta) ubuntu
[22:06] <nacc> simon_g: depends, what kind of error? compiling the ubuntu kernel? or mainline?
[22:07] <simon_g> hi, nacc. http://wklej.org/id/2193203/ here is a link, kernel was a standard one from the kernel.org, with no extra patches or in fact any modifications that i'd think of (apart from compiling ext2/3/4 as a part of kernel, not as a module)
[22:08] <simon_g> i did sudo make-dpkg clean && fakeroot make-kpkg --initrd kernel_image -j10
[22:09] <simon_g> it was a while since I was doing stuff on linux, but as far as i remember (and as far as the stuff i've found over the internet say) that was a valid way of compiling kernel (with .deb packages)
[22:10] <simon_g> i'll try it with the 4.5 kernel now
[22:10] <sarnold> simon_g: apt-get install libssl-dev
[22:11] <Pharaoh_Atem> nacc: php-mongodb is dead, afaik
[22:11] <Pharaoh_Atem> afaik, it was replaced with the new php-mongo
[22:11] <Saviq> pitti, thanks, about our previous conversation - I've now got gsettings-qt, qtmir and qtmir-gles stuck in proposed because of the leftover Xs-Testsuite header http://people.canonical.com/~ubuntu-archive/proposed-migration/xenial/update_excuses.html#gsettings-qt - how'd you say we deal with that?
[22:11] <Pharaoh_Atem> nacc: but I'll talk to Remi about the horde package, for sure
[22:12] <Saviq> pitti, already have an MP up for it https://code.launchpad.net/~saviq/qtmir/drop-testsuite-header/+merge/290468 but that won't unblock gsettings-qt anyway since it's trying to run the previous qtmir tests
[22:12] <nacc> Pharaoh_Atem: other way around
[22:13] <simon_g> sarnold, yeap, that's what i thought i needed. but why the heck should i need it?
[22:13] <Pharaoh_Atem> nacc: oh, was it?
[22:13]  * Pharaoh_Atem gets them mixed up all the time :/
[22:13] <nacc> Pharaoh_Atem: yeah, 16.04 has no php-mongo, has php-mongodb
[22:13] <simon_g> even on the 4.5 with standard settings (nothing has been changed) i still get that error
[22:13] <sarnold> simon_g: you may be able to turn off something in the kernel configuration file to no longer build those tools
[22:20] <simon_g> thanks, sarnold, it's compiling.
[22:21] <sarnold> \o/
[22:27] <cjwatson> infinity: :-P
[22:27] <infinity> cjwatson: :)
[22:29] <mwhudson> infinity: so dh_golang is just looking at build-depends to generate built-using
[22:30] <mwhudson> so i think it would be appropriate to do some special casing to report the golang-X.Y-go version too
[22:30] <mwhudson> just not 100% sure how to do that
[22:33] <infinity> mwhudson: Oh, really?  It's that brain-dead?
[22:34] <infinity> mwhudson: So, yeah, I'd special-case "golang-go" to readlink /usr/bin/go | dpkg -S | reverse-lookup.
[22:34] <infinity> Well, I guess it must already be doing the reverse lookup bit, unless it's REALLY brain-dead.
[22:35] <infinity> Since Built-Using is meant to reference sources, not binaries.
[22:35] <mwhudson> infinity: https://anonscm.debian.org/cgit/collab-maint/dh-golang.git/tree/script/dh_golang#n88
[22:35] <infinity> So, just readlink | dpkg -S -> existing bits.
[22:35] <mwhudson> is there Dpkg::foo for dpkg -S or should i just shell out?
[22:36] <infinity> libdpkg-perl likely has the right bits in it somewhere.  I don't use it much.
[22:37] <infinity> mwhudson: Actually, maybe not.  libdpkg-perl is more about manipulating packages, not the package database.
[22:37] <infinity> mwhudson: So forking is probably the right way.
[22:39] <mwhudson> ok
[22:48] <mwhudson> infinity: http://paste.ubuntu.com/15563663/ seems to do the job, any ideas for proper testing?
[22:51] <mwhudson> infinity: http://paste.ubuntu.com/15563673/
[22:55] <infinity> mwhudson: Surely, that belongs in the if{}
[22:56] <infinity> mwhudson: (In case someone builds a package with dh-golang that doesn't actually use golang because derpy derp)
[22:56] <infinity> mwhudson: Also should only trip is "golang-go" is in the build-deps, I'd think.
[22:56] <infinity> s/is/if/
[23:05] <mwhudson> infinity: dh-golang invokes go xxx a bunch of times, if there's nothing there things are going to go bad
[23:05] <mwhudson> but hmm
[23:06] <mwhudson> maybe if golang-defaults turns up in the list of source packages
[23:12] <infinity> mwhudson: It does?
[23:13] <infinity> mwhudson: It only depends on perl, so that's surprising.
[23:14] <infinity> mwhudson: Wow, it really does.  So, in that case, dh-golang is broken for your new world order anyway. :/
[23:14] <infinity> mwhudson: Since it won't understand a package that build-deps on golang-1.6 and calls the compiler directly.
[23:15] <infinity> mwhudson: But the quick fix for now while we assume the world all uses defaults would be to just keep what you have but move it back into the if block, IMO.
[23:15] <mwhudson> infinity: http://paste.ubuntu.com/15563799/ ?
[23:16] <infinity> mwhudson: And conditionalise it on that dpkg-query actually returning true.
[23:16] <mwhudson> infinity: for that sort of thing, i've just been putting /usr/lib/go-1.6/bin on $PATH in rules
[23:16] <mwhudson> which is possibly a bit dumb
[23:17] <infinity> mwhudson: Ahh, I like that iteration better (not your rules file, but dh-golang fix).
[23:17] <mwhudson> i guess that's not strictly strictly correct, you could build-depend on golang-src in which case there might not be a /usr/bin/go at all
[23:18] <mwhudson> but there's only so much stupidity it's worth tolerating
[23:18] <infinity> mwhudson: The PATH hack could concievably be the "right" way to do it in the Go world, but you should maybe codify that.  Or even get dh-golang to help somehow.
[23:18] <infinity> mwhudson: Well, conditionalize the dpkg-query.
[23:19] <infinity> mwhudson: If they build-dep on golang-src and there's no /usr/bin/go, then that search will fail.
[23:19] <infinity> mwhudson: And perhaps eat stderr on that.  dpkg-query is noisy when it hates you. :P
[23:20] <mwhudson> infinity: what's perl for telling if the command succeeded?
[23:21] <mwhudson> i think if i 2>/dev/null i'll endup appending just " " so it kinda almost "works" in that case
[23:22] <mwhudson> oh $?
[23:24] <infinity> mwhudson: http://paste.ubuntu.com/15563848/
[23:24] <infinity> mwhudson: That's how I'd do it, likely.
[23:25] <infinity> (base)adconrad@nosferatu:~/golang/dh-golang-1.12$ perl foo.pl
[23:25] <infinity> foo bar baz coreutils
[23:26] <infinity> Huh, though I'm getting an extra \n out of that.
[23:27] <nacc> slangasek: fyi, the php-horde-spellchecker failure seems odd: "E: Failed to fetch http://ftpmaster.internal/ubuntu/pool/main/g/groff/groff-base_1.22.3-7_amd64.deb  Temporary failure resolving 'ftpmaster.internal'"
[23:28] <mwhudson> infinity: http://paste.ubuntu.com/15563863/
[23:28] <mwhudson> infinity: extra newlines matter <= 0 in this context i think :)
[23:31] <nacc> slangasek: it built successfully for me with and without -proposed, so I think it might have been a trasnient issue
[23:32] <infinity> mwhudson: Possibly not, but easily fixed with a chomp too.
[23:32] <infinity> http://paste.ubuntu.com/15563889/
[23:32] <mwhudson> infinity: is a string that is just "\n" truthy in perl?
[23:33] <infinity> mwhudson: Strings should never be evaluated for truthiness.
[23:33] <infinity> mwhudson: Perl has different operators for strings and values.
[23:33] <mwhudson> isn't that what the if statement is doing? or is perl being even odder than i expect?
[23:33] <infinity> mwhudson: eq/ne/etc are literal string comparisons.
[23:33] <infinity> Wait, which if?
[23:34] <cjwatson> truthiness of strings is dangerous to use in perl because "0" is false, for instance
[23:34] <cjwatson> as it happens "\n" is true in a boolean context, but ...
[23:34] <mwhudson> oh `` returns undef if the command fails
[23:34] <infinity> My "if" is testing if the `` exited cleanly and, thus, set the variable.
[23:34] <infinity> The later if is doing a string comparison with ''
[23:34] <tsimonq2> bug 1547395 is the cause of the FTBFS for libquvi, what needs to happen now? Desktop team ack? Just curious...
[23:34] <mwhudson> yeah ok
[23:35] <cjwatson> infinity: your if in http://paste.ubuntu.com/15563889/ is testing string truthiness though
[23:35] <cjwatson> or at least may be
[23:35] <infinity> cjwatson: Shouldn't be.
[23:36] <infinity> cjwatson: Oh.  I see.  Yeah, it's not in the failure case, but might be in the success case.
[23:36] <cjwatson> Right.
[23:36] <infinity> My perl is rusty.
[23:36] <cjwatson> I'd do "my $golang_go_dep = `...`; if ($? == 0) { ... }"
[23:36] <infinity> Luckily, a package name will probably always be "true", but ick.  Remind me how to express that properly?
[23:36] <infinity> Fair enough.
[23:36] <infinity> mwhudson: ^-- Listen to the irishman.
[23:37] <mwhudson> blarghl i had that version at one point :)
[23:37] <infinity> mwhudson: Plus chomp, cause chomp is never wrong.
[23:37] <infinity> First thing I learned about string manip in perl. :P
[23:37] <cjwatson> or if you want to be fancy then I think it's possible to glue autodie into backtick handling
[23:37] <mwhudson> i have no desire to be fancy at all
[23:37] <infinity> Fanciness is overrated.
[23:38] <mwhudson> beyond what is necessary when in perl-mode
[23:38] <cjwatson> but that probably has rather more effects on the program as a whole
[23:38] <mwhudson> i don't think it would be appropriate here
[23:38]  * mwhudson rebuilds lxd for the 20th time
[23:39] <infinity> cjwatson: Wait.  Are you sure I'm testing the string?
[23:39] <mwhudson> http://paste.ubuntu.com/15563916/
[23:39] <infinity> cjwatson: Replacing the `` with `echo 0` and `echo 1` seem to both succeed and add to the list.
[23:39] <cjwatson> try s/echo/printf/g
[23:39] <cjwatson> "0" is false, "0\n" is true
[23:39] <infinity> cjwatson: Shouldn't the () around the expression be testing the return of the assignment rather than the content?
[23:39] <cjwatson> thanks Larry
[23:40] <infinity> Hahaha.
[23:40] <infinity> Hah.
[23:40] <infinity> Hah hah hah.
[23:40] <infinity> cjwatson: I concede.  And also, HAH.
[23:40] <mwhudson> oh right, it's the shell's `` that strips a trailing newline if present
[23:40] <cjwatson> the return value of an assignment expression is the assigned thing
[23:40] <cjwatson> basically
[23:41] <cjwatson> if I were writing perl stuff from scratch these days I'd probably start with Modern::Perl and autodie
[23:41] <infinity> cjwatson: So there's no way to express the shell shortcut of "if assign = expr", you have to go longhand with the return?  Oh well.
[23:41] <cjwatson> and using largely python-style exception handling
[23:41] <cjwatson> infinity: well, you can, it's just that the assigned thing in this case isn't very boolean-friendly
[23:42] <cjwatson> you could say "if (length(my $foo = ...))"
[23:42] <infinity> mwhudson: That looks plausibly correct, given above.
[23:42] <mwhudson> it also seems to work
[23:42] <cjwatson> (iirc)
[23:43] <infinity> cjwatson: Right, fair.  length() would be a cheat in cases where success also implies I set something non-null.  Which works here.
[23:43] <cjwatson> you can also write it as "chomp(my $golang_go_dep = ...)" I think
[23:43] <infinity> cjwatson: I guess I'm looking for the shell shorthand where I'm not actually testing the assignment at all, but the rv of the ``
[23:43] <infinity> cjwatson: Which is probably more of a bug in POSIX sh than a lack of feature in Perl.
[23:43] <cjwatson> infinity: well, but you are here, it's just that the test on the rv has different semantics
[23:43] <cjwatson> it's still a test on the rv though
[23:44] <infinity> cjwatson: Yeah, you could chomp on either line, but chomping where he did keeps line length down. ;)
[23:44] <mwhudson> chomp returns the number of characters chomped i think?
[23:44] <infinity> Oh, it does.
[23:44] <infinity> Yeah.
[23:44] <infinity> Keep the chomp where it is.
[23:44] <infinity> It's lovely.
[23:44] <infinity> And chompy.
[23:44] <infinity> On nom.
[23:44] <infinity> mwhudson: Ship it before we bikeshed more.
[23:44] <infinity> I need a shower.
[23:44] <mwhudson> anyway i need lunch
[23:45] <infinity> And to run out.
[23:45] <mwhudson> yeah ok
[23:45] <infinity> Every time I do something Perly, I feel guilty about all the Perl I've forgotten.
[23:45] <infinity> Has the same experience futzing with sbuild a few days ago.
[23:45] <infinity> s/Has/Had/
[23:46] <mwhudson> infinity: [ubuntu/xenial-proposed] dh-golang 1.12ubuntu1 (Waiting for approval)
[23:47] <infinity> mwhudson: Danke.
[23:47] <infinity> mwhudson: Are you uploady for that in Debian too?  Should be fixed there as well if you've done the defaults thing.
[23:47] <mwhudson> infinity: no, and that hasn't happened yet
[23:47] <mwhudson> hopefully soon
[23:47] <mwhudson> i've sent a mail to debian-newmaint and then a whole lot of nothing has happen afaict
[23:48] <infinity> mwhudson: Also, that diff had another diff inside.
[23:48] <infinity> mwhudson: debdiff before upload. ;)
[23:48] <mwhudson> oh right, native package
[23:49] <mwhudson> infinity: you'll reject?
[23:49] <infinity> mwhudson: Already have.
[23:49] <infinity> You should have angry email.
[23:49] <mwhudson> nope
[23:49] <infinity> Well, you will some day. :P
[23:49] <mwhudson> but i assume it'll arrive in due course
[23:49] <sarnold> funny that the "AOL guy" didn't go with "You've got angry email"
[23:49] <infinity> Anyhow, it's rejected.
[23:51] <mwhudson> uploaded again
[23:52] <tsimonq2> cyphermox: you around? (sorry for the naked ping)
[23:53] <tsimonq2> ahh, looks like he's AFK
[23:53] <infinity> mwhudson: Ta.
[23:54] <mwhudson> infinity: ah got the rejection mail now, i like your explanation
[23:54] <infinity> mwhudson: Given that we kinda want to start tracking built-using properly, we might want to do no-change rebuilds of all golang things once this lands, but we can worry about that another time.
[23:55] <infinity> mwhudson: I might wait for the inevitable next lxd upload first, see how things look, then perhaps rebuild the world.
[23:55] <mwhudson> ok
[23:56] <mwhudson> well rebuild all things with binaries that are in main, at least :-)
[23:56] <mwhudson> anyway, really need lunch now
[23:56] <mwhudson> biab
[23:59] <nacc> slangasek: aiui, phpmyadmin is ok to leave as-is, as all the php5 dependencies are from alternatives?