[03:38] <sarnold> Unit193: heh, yeah, non-stale mirrors is great reason :)
[03:51] <Unit193> Or rather, when they're outdated it's more noticable.
[05:43] <hloeung> rbasak: would you be kind enough to sponsor the patch in https://bugs.launchpad.net/ubuntu/+source/check-mk/+bug/1372284 ?
[05:43] <hloeung> rbasak: I've tested in two separate instances of nagios we IS have (Both Xenial and Trusty)
[05:43] <hloeung> rbasak: oh make that three, two Xenial and one Trusty
[10:59] <doko> apw, ogasawara: linux autopkg test failures are triggered by binutils and gcc-6. please could you have a look if these are real?
[10:59] <apw> doko, yep
[11:12] <javier4> Hi all. I'm trying to cross-compile a package for ubuntu touch after I applied some edits to the source and modified the debian overlay according to them. I setup the schroot following the first part of this page https://wiki.ubuntu.com/Touch/CrossCompile
[11:13] <javier4> This is what I get
[11:13] <javier4> http://pastebin.com/dbHxbM7c
[11:13]  * javier4 The warning should be unharmful, because I pass the -d flag. I can't see any error.
[11:41] <javier4> just noticed that this is the only content of my /var/lib/schroot
[11:41] <javier4> https://www.irccloud.com/pastebin/trLCYdXh/
[11:42]  * javier4 doesn't it lack something?
[12:10] <apw> javier4, isn't that saying you don't have a chroot you requested ?
[12:14] <javier4> apw, I just noticed some minutes ago that the porcedure I used to setup my schroot is not persistent. I issued again the mk-sbuild command and now it seems the chroot has been created. See if it works now...
[12:38] <apw> doko, the linux/amd64 failure reported on gcc-6 is a known HOST induced test suite failure and can be ignored.  the failures on binutils differ and warrent a retry (already clicked)
 Hi everyone
 There is a terrible bug in Mozilla FireFox working on Lubuntu 32-bi
 When I click in a hyperlink contente an email (like mailto:name@domain.excetera) mozilla oper a tab with the name of email in the searchboard FOREVER
 if you try to close Mozilla he reopen and open tab that you can close because open every second!
 4 or 5 for second!
 I'm using on Lubuntu (maybe 14.04 32bit)
 maybe because I haven't an email account associated with the email client program of the software
 but when I associate the problem present another time
 I'm so sorry for my bad english xD
[13:46] <fossfreedom_> musician_pro: suggest file a bug report with the above to the relevant team - in a lxterminal: ubuntu-bug firefox
[13:53] <tjaalton> doko: mesa still wants llvm 4.0 in main, but others are not ready for it atm. could both be in main for now? clamav for instance could be "fixed" by disabling llvm support again
[14:03] <juliank> Do we want one shared SRU bug for both apt 1.2.20 and 1.3.5 (where 1.2.20 is a subset of 1.3.5 changes), or one for each?
[14:21] <juliank> Let's do two, it gets confusing otherwise
[14:55] <javier4> To crosscompile my package I need dbus header inside my system, so I installed libdbus-1-dev into my chroot
[14:56] <javier4> (vivid-amd64-armhf)root@UbuBox:/# find /usr -name *dbus.h
[14:56] <javier4> /usr/include/dbus-1.0/dbus/dbus.h
[14:57] <javier4> my build still fail, and if I look for the file from outside of the chroot, I can't find it
[14:57] <javier4> root@UbuBox:/var/lib/schroot/chroots/vivid-amd64-armhf# find . -name *dbus.h
[14:57] <javier4> root@UbuBox:/var/lib/schroot/chroots/vivid-amd64-armhf#
[15:00]  * javier4 Is my setup volatile? The changes I made once chrooted get forgotten when I leave the chroot?
[15:20] <javier4> ok. Just learnt about chroot namepspaces.
[15:21] <apw> doko, that binutils ADT failure looks real for armhf at least
[15:22] <doko> apw: strange. there are no armhf related changes compared to the last version ...
[16:14] <doko> apw: honestly I have difficulties to understand an error message like "error: not found"
[16:15] <apw> doko, i know ... it is tricky to know where the heck that is even coming from
[16:15] <apw> doko, but it has not gone away on a re-test and that is a basic kernel compile which is failing, on source which is built in the -proposed pocket with the previous tool-chain
[16:16] <apw> doko, so in the first instance i am looking at binutils/gcc there
[17:51] <nacc> mdeslaur: fyi, re: LP: #1668017, i just put 7.0.16 in a PPA for them to test
[17:52] <mdeslaur> ugh
[17:53] <nacc> mdeslaur: yeah :/
[18:08] <sbeattie> nacc: vaguely related, any idea why the adt tests for mariadb-10.0 would be running for mariadb-10.1? It seems to be why mariadb10.1 hasn't left -proposed: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#mariadb-10.1
[18:09] <sarnold> nice find
[18:11] <nacc> sbeattie: mariadb-common
[18:11] <nacc> sbeattie: iiuc, if mariadb-10.1 were to go in, it would be preferred by mariadb-common, which might break assumptions of 10.0 installations?
[18:11] <nacc> sbeattie: looking at the autopkgtest failures, that's why it triggered, if i had to guess
[18:12] <nacc> sbeattie: it's the only package from -proposed being installed, at least :)
[18:12] <sbeattie> ah okay. but is there any reason to keep mariadb-10.0 in zesty?
[18:13] <nacc> sbeattie: there are a handful of reverse-dependencies that may need to be verified?
[18:13] <nacc> sbeattie: and it's after FF :)
[18:13] <nacc> sbeattie: not sure if 10.1 is no features or not
[18:13] <sarnold> if it were uploaded before ff it probably could be waved through
[18:13] <nacc> taht's true
[18:13] <nacc> sorry, still context switching :)
[18:13] <sarnold> normally packages being held up by autopkgtests or mirs count on when they were uploaded..
[18:14] <nacc> sarnold: ack, you're right
[18:14] <sbeattie> nacc: me either. I'm just trying to figure out how to resolve the zesty portions of bug 1657594
[18:14] <sarnold> (which is good, I'd have a lot more angry co-workers if their mirs had to be done before ff :)
[18:15] <nacc> why did they use a new source pacakge for waht is presumably a stable update?
[18:15] <sbeattie> as our zesty package is now a rev behind the x/y packages; the issues have been addressed in mariadb-10.1, which has synced from debian but is sitting in -proposed,
[18:15] <nacc> i guess that's normal
[18:15] <nacc> but also does imply there are some changes
[18:15] <sbeattie> nacc: I've no idea, the constant renaming of sources like that makes it so fun to track.
[18:16]  * sarnold glares at gcc
[18:16] <nacc> sbeattie: yeah, ok, so it hink the reverse-dependencies are still satisfied
[18:16] <nacc> sbeattie: as the 10.1 package produces the same binary packages (afaict)
[18:17] <nacc> sbeattie: as well as some additional ones
[18:18] <nacc> sbeattie: so i think we need to transition 10.0 to 10.1 if you want it through, which I believe will end up needing an AA to delete src:10.0; possibly after ignoring the autopkgtest regressions for 10.1 on 10.0
[18:18] <nacc> infinity: --^ is that right?
[18:18] <nacc> I don't think we want to delete src:mariadb-10.0 before we migrate its replacement in, though
[18:21] <infinity> nacc: If the new source produces all the same binaries, yeah, we'll want to remove the orphaned old source once things migrate.
[18:22] <infinity> nacc: What is the old source's name?
[18:22] <nacc> infinity: mariadb-10.0 (and new is mariadb-10.1)
[18:22] <infinity> Check.
[18:23] <nacc> infinity: the issue is, i think, mariadb-10.1 is triggering mariadb-10.0 to run its autopkgtest with mariadb-10.1 from proposed
[18:23] <infinity> That's not really an issue.
[18:23] <nacc> infinity: which installs mariadb-10.1 for the dependencies of the tests from mariadb-10.0 via the shared genericc pacakges (mariadb-server, etc) and the tests fail
[18:25] <infinity> That's perhaps more of an issue. :P
[18:25] <infinity> But we can likely ignore that.
[18:25] <infinity> So, it doesn't produce *all* the same binary packages.
[18:25] <infinity> Since some are exact-versioned.
[18:26] <nacc> infinity: ah you're right, so mariadb-{client,server}-10.1 vs. 10.0, etc
[18:26] <infinity> Who thought this was a good idea?
[18:26] <infinity> Oh well.
[18:27] <nacc> infinity: yeah it seems like a bit of a mess :)
[18:27] <infinity> nacc: The tests should probably make sure they're testing the right package.  So, depend on the exact version, not the meta.
[18:27] <infinity> (No point fixing for 10.0 of course, but 10.1 could do better so the next one doesn't also break it)
[18:28] <nacc> infinity: ack, i'll pull that down now
[18:32] <nacc> infinity: in my checking so far, nthing in z/z-p depends on the versioned packages, they all go via the meta packages, so I don't think anything will break, once src:mariadb-10.1 is in z-release by removing src:mariadb-10.0 (and already installed users should get the new version of the meta package and the new versioned satisfier)
[18:32] <Laney> nacc: It looks to me like it's via mariadb-test - the 'upstream' test - that the breakage happens, because this one is unversioned
[18:34] <Laney> https://tracker.debian.org/news/748959
[18:35] <nacc> Laney: good find
[18:36] <infinity> Not that attempting to test the old mariadb is wrong (in fact, it's quite right here, when we rev the underlying libs, but claim ABI compat), but it's rather wrong to ask for a test of the old binary and get a test of the new binary with the old tests. :P
[18:38] <nacc> Laney: yeah i think what you said is right
[18:38] <nacc> Laney: mariadb-test should be versioned for exaclty this reason, afaict
[18:39] <nacc> Laney: it can be dropped from the name, but I don't thnk it makes snse to take the 'latest' mariadb-test, you want the one from the same as this source package, right?
[18:39] <infinity> It stands to reason that you want your tests to match what you're testing, indeed.
[18:39] <Laney> nacc: I'd think that you're wanting to test the 'current' mariadb (the one from the triggered package), with the new libs from the triggering package (that's what infinity just said), so ya.
[18:40] <Laney> You got it, and now I can leave for the evening happy. :P
[18:40] <Laney> o/
[19:00] <rbasak> !dmb-ping
[19:18] <nacc> infinity: so does it makes sense to get mariadb-10.1 migrated (by fixing mariadb-10.0 as well), even though we'd end up deleting mariadb-10.0?
[22:10] <nacc> mdeslaur: fyi, looks to be aregression uptream, fixed (will be) in 7.0.17; i'm uploading to my PPA to test, and will push to -updates everywhere and you can copy up to -security
[22:23] <valorie> hi folks, I joined to find out if there are reports about freezing since the recent kernel update in Zesty. I'm experiencing this twice a day or so, and I've not been able to rule out applications or even Plasma (running Kubuntu)
[22:23] <valorie> but I hear that cyphermox is investigating a kernel bug
[22:24] <cyphermox> heh, not really investigating it as throwing guesses at what it might be
[22:25] <sarnold> valorie: I've heard rumours the kernel in -proposed may help
[22:25] <cyphermox> I have issues mostly with firefox freezing for no particular reason, and unity not showing me my virt-manager menus
[22:25] <valorie> I've been trying to quit FF whenever possible
[22:26] <valorie> however, after a freeze, even if I was not running FF, up it pops
[22:26] <cyphermox> ok
[22:26] <valorie> does it have a daemon that auto-starts it?
[22:26] <valorie> it is not in my very short list of auto-starting applications or scripts
[22:27] <cyphermox> nothing should be starting a browser.
[22:27] <cyphermox> unless you go click a link in something else
[22:27] <valorie> evil, evil FF
[22:27] <valorie> no, I use Chrome every day
[22:27] <valorie> but one site only works in FF
[22:27] <valorie> bleah
[22:28] <valorie> otherwise I would kill it with fire
[22:28] <cyphermox> if firefox was not running and it got started, I would go look at the process tree to see what its parent is
[22:28] <valorie> unfortunately, I don't know how to do that, but I'll try to learn
[22:28] <valorie> this is really awful
[22:29] <valorie> so it does not seem to be kernel-related?
[22:29] <valorie> sarnold: you have heard reports as well?
[22:29] <valorie> do you have a BR#?
[22:31] <sarnold> sorry valorie, no bug numbers :/
[22:32] <valorie> ok, I'll hang out here and keep my ears open
[22:32] <valorie> better it show up now than in the RC
[22:34] <nacc> can you express d/t/control dependencies on specific versions using d/control substitutions? I'm assuming not and that you have to do some sort of build-time munging?
[23:10] <nacc> slangasek: --^ ?
[23:10] <nacc> slangasek: except build-time is 'too late' as i think autopkgtest just extracts the source and looks in d/t/control?
[23:10] <slangasek> nacc: debian/tests/control is read from within the source package, so no, you can't
[23:10] <slangasek> yes, that
[23:11] <nacc> slangasek: so for mariadb-10.0 and mariadb-10.1, where I want to update the d/t/control 'upstream' test dependency from 'mariadb-test' to 'mariadb-test (= {same binary version as this upload}); do I hve any options?
[23:20] <slangasek> nacc: I would expect a test dep on '@' to enforce this already
[23:20] <nacc> slangasek: ok, i was wondering if i could do that -- but is @ versioned?
[23:20] <slangasek> if it's a binary from /this/ source package, that should already dtrt
[23:21] <nacc> slangasek: as it's a meta-binary produced by both source pacakges that's the issue
[23:21] <slangasek> nacc: it should certainly be enforced on the autopkgtest infra
[23:22] <nacc> slangasek: ok -- i think that will be fine, but is 'more' of a dependency than is actually needed. But that's ok (it will just slow the test down by adding more deps).
[23:22] <nacc> slangasek: and as far as I can tell, there's no way to tell @ to only provide one binary from /this/ source package, right?
[23:22] <slangasek> correct
[23:23] <slangasek> otoh, even if you did just spell out the package name, instead of using '@', autopkgtest should still enforce it with its pins
[23:23] <nacc> slangasek: ok, thanks
[23:23] <nacc> the problem is that in -proposed there's a newer mariadb-test
[23:23] <nacc> and it pulls in the 0.10.1 dependencies
[23:23] <nacc> which breaks 0.10.0's tests :/
[23:23] <slangasek> example?
[23:24] <nacc> https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-zesty/zesty/amd64/m/mariadb-10.0/20170128_080150_f9895@/log.gz
[23:24] <nacc> the 'upstream' test section
[23:24] <slangasek> nacc: so that's the run of the test that's triggered by the upload of mariadb-10.1 itself
[23:24] <nacc> it uses mariadb-test from z-p, even thoug it's testing a source package that also generates mariadb-test from z
[23:25] <nacc> and the script in the z version only is compatible with mariadb in z
[23:25] <slangasek> right
[23:25] <slangasek> so it's actually a bad test
[23:25] <nacc> slangasek: yes, it feels bad :)
[23:25] <slangasek> you can't have two source packages in a release both producing a binary of the same name
[23:25] <slangasek> the mariadb-10.0 source package will now fail to upload
[23:26] <slangasek> unless you make a sourceful change
[23:26] <nacc> slangasek: our goal is to delete mariadb-10.0
[23:26] <slangasek> ok, in that case
[23:26] <nacc> slangasek: and transition to mariadb-10.1
[23:26] <slangasek> why worry about whether the test is failing? :)
[23:26] <nacc> slangasek: because mariadb-10.1 won't transition
[23:26] <nacc> slangasek: and as infinity pointed out earlier, it's ok for now, we understand this, but 10.1 has the same problem and will block 10.2
[23:26] <nacc> slangasek: it feels like it should be solveable
[23:27] <slangasek> nacc: but it shouldn't be "let's do a bunch of extra work to make a test wrongly triggered by mariadb-10.1 to pass", it should be "hey release team, ignore this meaningless result"
[23:27] <slangasek> you're still in the situation that the test is being triggered by a package that shouldn't trigger it
[23:27] <slangasek> it's triggered *only* because you're taking over the name of the binary package
[23:28] <nacc> slangasek: i believe it triggers because they both produce the meta packages (all of them, -test, -server, -client)
[23:28] <slangasek> so you could either a) version the name of the binary package, so this no longer happens; or b) ask the release team to override
[23:28] <nacc> slangasek: ok, a) was specifically dropped in Debian, thanks to Laney's research
[23:28] <nacc> https://tracker.debian.org/news/748959
[23:28] <nacc> i'm not entirely sure i agree with the logic given the situation, but i'm not the expert
[23:29] <nacc> slangasek: and then, i guess in this particular case, can you override the 10.0 tests triggered by 10.1 so we can migrate it? :)
[23:29] <slangasek> nacc: well, that is the change that triggers this breakage, so I wonder why Laney thought it was appropriate?
[23:29] <nacc> slangasek: i can file a bug if you'd rather, of course
[23:31] <nacc> slangasek: i'm going to contact the debian maintainer(s) as they are seeing the same thing, afaict, e.g. https://ci.debian.net/data/packages/unstable/amd64/m/mariadb-10.0/20170227_005237.autopkgtest.log.gz
[23:31] <nacc> slangasek: and it feels like they should revert the change in their package
[23:31] <nacc> *packagin
[23:31] <slangasek> nacc: I think Debian should revert this misguided change, and I've overridden the failure now for zesty
[23:32] <nacc> slangasek: agreed
[23:32] <nacc> slangasek: and thanks!
[23:32] <nacc> sbeattie: --^
[23:37] <sbeattie> slangasek: thanks
[23:41] <nacc> slangasek: e-mail sent, thanks for helping walk me through it