=== _salem is now known as salem_
=== salem_ is now known as _salem
=== _salem is now known as salem_
=== salem_ is now known as _salem
[01:50] <psusi> wasn't there a tag to assign to bugs related to the dmraid -> mdadm transition for intel fakeraids?
[05:55] <krypto> i have follwing cgroups defined in cgconfig.conf and cgrules.conf http://paste.ubuntu.com/13122187/ but i dont know how to tell libvirt use that instead of creating seperate "machine" group.Can some one please help me with this?
[05:55] <krypto> in centos its in /etc/sysconfig/libvirt but not sure what to add in /etc/default/libvirt
=== hikiko-lpt is now known as hikiko
[07:50] <dholbach> good morning
=== ara is now known as Guest38632
[08:48] <Odd_Bloke> cjwatson: The diff on https://bugs.launchpad.net/ubuntu/+source/livecd-rootfs/+bug/1513754 are the changes we need to move more building on to Launchpad.
[08:48] <ubottu> Launchpad bug 1513754 in livecd-rootfs (Ubuntu) "Move cloud image building further on to buildds" [Undecided,New]
[08:49] <Odd_Bloke> infinity: wgrant: You may also be interested in ^.
[09:17] <Mirv> dholbach: hey, if around could you do ./copy-package --from=~ci-train-ppa-service/ubuntu/landing-021 --from-suite=xenial --to=ubuntu --to-suite=xenial-proposed -b unity-api ? we're working around a mistaken commit in a branch by manual copying, and publishing a QA approved silo (https://requests.ci-train.ubuntu.com/#/ticket/564)
[09:17] <dholbach> Mirv, I don't think I have access to whatever requires ./copy-package to be run
[09:17] <Mirv> I copied the PPA ones + all others for xenial which were universe, but that one package is in main
[09:17] <dholbach> I'm not an archive admin
[09:17] <Mirv> dholbach: you don't need to be
[09:18] <Mirv> dholbach: you can copy any package you'd have upload rights to, like I did for those universe packages (https://lists.canonical.com/archives/xenial-changes/2015-November/thread.html)
[09:18] <Mirv> the command only complains if one tries to copy to real xenial instead of proposed
[09:19] <Laney> you get it from lpubuntu-archive-tools
[09:20] <dholbach> ok, I'll take a look
[09:20] <dholbach> just a sec
[09:20] <Mirv> thanks. I only selected you since you said good morning here so I thought you'd be around :)
[09:22] <dholbach> :)
[09:22] <dholbach> Mirv, done
[09:24] <Mirv> dholbach: thanks! Saviq ^ all done now
=== nudtrobert1 is now known as nudtrobert
[09:40] <rbasak> pinba-engine-mysql FTBFS on some architectures is blocking mysql-5.6 from proposed migration. The issue is forwarded upstream but currently doesn't have a resolution
[09:41] <rbasak> Opinions on forcing it and dropping pinba-engine-mysql from those architectures?
[09:41] <rbasak> (the Debian maintainer forwarded it)
[09:45] <cjwatson> rbasak: well, we shouldn't force it in proposed-migration, but yeah, I'm somewhat inclined to remove it from the affected architectures.  let me look
[09:45] <cjwatson> I know I synced it, doko had previously reverted it, had been meaning to look anyway
[09:45] <cjwatson> rbasak: could you remind me of a reference to the upstream bug?
[09:46] <cjwatson> Odd_Bloke: thanks, looking
[09:47] <rbasak> cjwatson: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=793511 and https://github.com/tony2001/pinba_engine/issues/40
[09:47] <ubottu> Debian bug 793511 in src:pinba-engine-mysql "pinba-engine-mysql: FTBFS (32-bit): cannot convert 'uint64_t*' to 'Word_t*" [Serious,Open]
[09:49] <cjwatson> rbasak: thanks, nuked from xenial
[09:49] <cjwatson> (on 32-bit arches)
[09:55] <rbasak> cjwatson: thank you!
[09:59] <cjwatson> Odd_Bloke: uploaded
[09:59] <cjwatson> thanks for the long patch!
[10:32] <Odd_Bloke> cjwatson: Thanks!
[10:40] <roaksoax_> pitti: howdy! is there a way to tell adt to build different packages when passing --unbuilt-tree ?
[10:41] <roaksoax_> pitti: right now we are saying "--unbuilt-tree=$PATH/maas" and 'maas' is the source, that contrais debian/ inside
[10:41] <roaksoax_> pitti: however, I not only want to build MAAS, but I also want to build another package *before* maas
[10:43] <roaksoax_> pitti: i.e: http://pastebin.ubuntu.com/13123203/
[10:54] <roaksoax_> pitti: or is there another way to insert dependencies?
[11:10] <Shock> hi
[11:12] <Shock> I found a bug regarding the adding of routes related to multiple IPs on the same interface, but I'm not sure if I should report it for network-manager or linux. can you help me?
=== _salem is now known as salem_
=== hikiko__ is now known as hikiko
[12:14] <Odd_Bloke> cjwatson: Would you expect powerpc cloud images to have UEFI and a PReP partition a la ppc64el?
[12:15] <Odd_Bloke> cjwatson: FFS, s/UEFI/GPT/.
[12:15] <Odd_Bloke> Some day I will stop conflating those two things.
[12:16] <Odd_Bloke> cjwatson: Or would a single-partition MBR (a la amd64/i386 -disk1 images) be what you would expect?
[12:40] <cjwatson> Odd_Bloke: I'm not sure about the exact firmware details, but I suspect what would work best would be MBR with a PReP partition, so part-way between the two options you gave.
[12:40] <cjwatson> Odd_Bloke: infinity might have a clearer idea.
[12:40] <cjwatson> Odd_Bloke: It's possible that UEFI might work, but it will probably depend on the firmware ...
[12:40] <cjwatson> Maybe it's safe to assume a new enough slof.
[12:41] <cjwatson> Err, GPT not UEFI.  Now you've got me doing it. :-P
[12:49] <Odd_Bloke> :D
[12:50] <Odd_Bloke> OK, I'll try using the ppc64el codepath (because that's easy).  And then if we decide that we can't do that, I can look at doing something else.
[13:06] <pitti> roaksoax_: in principle you can run another test (including build) before the maas argument, yes
[13:07] <pitti> roaksoax_: or if you don't want to run the tests for those, just give adt-run the extra locally built .debs *before* the --unbuilt-tree, then these debs will be taken into consideration for the maas test
=== rcj` is now known as rcj
[13:33] <ogra_> cjwatson, i just had a "temporary failure in name resolution" for ftpmaster during a PPA build (retry worked fine but i thought you might want to know )
[13:33] <cjwatson> ogra_: thanks, not concerned right now (at a conference) if it isn't persistent
[13:33] <ogra_> k
[13:48] <roaksoax_> pitti: ok, great! Thanks!
[13:51] <roaksoax_> pitti: so basically, doing something like this: http://paste.ubuntu.com/13124111/
[14:08] <Odd_Bloke> cjwatson: https://launchpad.net/~cloud-images-release-managers/+livefs/ubuntu/xenial/cpc/+build/42512 \o/
[14:11] <elbrus> is Martin Pitt around?
[14:12] <seb128> elbrus, he's pitti on IRC
[14:12] <Odd_Bloke> pitti: ^
[14:12] <cjwatson> Odd_Bloke: whee
[14:13] <cjwatson> Odd_Bloke: do you have a way to test that this actually does something useful? :-)
[14:14] <Odd_Bloke> cjwatson: Not really; I was sort of hoping you did. :p
[14:17] <cjwatson> infinity: ^- can you help out?
[14:19] <elbrus> pitti: /me is looking at auto-pkg-test failures for dbconfig-common
[14:19] <elbrus> last time you send me a patch.
[14:20] <elbrus> I was wondering if the failure is related to $TMP(which I removed from the command)
=== francisco is now known as Guest24983
[14:23]  * elbrus wonders how much work it is to set up an environment where I can properly test my auto-pkg-tests such that they don't need to fail for Debian and Ubuntu
[14:24] <cjwatson> elbrus: http://packaging.ubuntu.com/html/auto-pkg-test.html#executing-the-test isn't too bad last I checked; I expect it isn't *too* much harder for Debian ...
[14:31] <elbrus> cjwatson: last time I looked I couldn't get qemu stuff working on my computer, so I don't want to spend much time in that direction. lxc works great here however, so if that can trivially be hooked up...
[14:31] <cjwatson> qemu> !
[14:31] <elbrus> it is mentioned (but not explained how)
[14:32] <cjwatson> you might find that the slew of options autopkgtests passes to qemu all by itself means you don't have to spend much time on that
[14:32] <cjwatson> maybe you just weren't using the right options ... qemu has lots
[14:34] <elbrus> ok, let me look at that after my current project than.
[14:40] <pitti> elbrus: hey
[14:41] <pitti> elbrus: man adt-virt-qemu explains how to build a suitable VM for sid
[14:41] <pitti> elbrus: https://people.debian.org/~mpitt/autopkgtest/README.running-tests.html (or in /usr/share/doc/autopkgtest/) explains teh available runners
[14:41] <elbrus> pitti: did you already look at dbconfig-common by any chance?
[14:41] <pitti> elbrus: lxc is fine, as long as you don't have a test which needs to twiddle kernel-y things (dbconfig shold be fine)
[14:42] <pitti> that should even get along fine with a simple schroot
[14:42] <pitti> elbrus: no, not yet, sorry
[14:42] <elbrus> no, I mean I should look at it myself instead of you
[14:42] <pitti> http://autopkgtest.ubuntu.com/packages/d/dbconfig-common/
[14:42] <pitti> indeed, recent regression
[14:42] <elbrus> (Debian mentality here ;))
[14:43] <pitti> elbrus: that'd be great (I don't have much time right now, sprint and all)
[14:43] <pitti> mkdir: cannot create directory ‘/share’: Permission denied
[14:43] <pitti> ASSERT:expected:<1.8 1.10 1.10.1 1.10.2 1.11 1.12> but was:<>
[14:43] <pitti> that's hopefully not too difficult to reproduce/understand for you?
[14:43] <elbrus> do you think it could be related to TMP not being set by me anymore?
[14:43] <pitti> looks like this is new in 1.8.55
[14:44] <pitti> elbrus: sure, if that mkdir does something like mkdir $TMP/share
[14:44] <mterry> chiluk, ever find another sponsor?  I can look at coreutils now
[14:44] <chiluk> rtg took a quick look, but he got scared away.. so mterry that would be fantastic.
[14:44] <elbrus> the regression doesn't make sense for anything in the "normal" code and the regression test runs fine for me...
[14:45] <elbrus> so I believe it must be the env that is different
[14:45] <mterry> chiluk, so this patch was different, did you have to backport more commits, or just make some minor adjustments or what?
[14:45] <chiluk> rtg wanted me to split out each individual commit into it's own patch, but I think that would be more trouble than it's worth since almost all of those patches rewrite the filter_list function over and over again
[14:45] <pitti> elbrus: we've never set $TMP explicitly in the tests
[14:45] <chiluk> mterry I had to backport another 6 or so prereq patches.
[14:46] <chiluk> the patches to the mountlist function are fairly similar..
[14:46] <chiluk> df needed a bunch more work.
[14:46] <mterry> chiluk, ick yeah.  I'm on board with one patch.  Not like they will be removed one by one later
[14:46] <elbrus> pitty: now, but my old testcase had it in the command, but I thought it wasn't really needed
[14:47] <chiluk> right.. it would make it easier to review in whole later.
[14:47] <elbrus> apparently it is for the auto-pkg-test framework
[14:47] <mterry> chiluk, not that trusty is a moving target really  :)
[14:47] <chiluk> mterry .. may i suggest patching the sources, and then comparing the result with upstream at the last patch..
[14:47] <mterry> chiluk, good idea  :)
[14:48] <mterry> nice that we're in sync with upstream then
[14:48] <chiluk> i.e. compare the df.c patch with http://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=commit;h=3babaf83875ceac896c8dd3a64248e955dfecef9
[14:49] <chiluk> and compare mountlist.c at http://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=commit;h=3babaf83875ceac896c8dd3a64248e955dfecef9
[14:49] <chiluk> mterry ^^
[14:49] <elbrus> pitti: I should have said TMPDIR...
[14:50] <pitti> elbrus: ah; adt-run did set that some years ago, but this was dropped a long time ago, not in the last month
[14:50] <chiluk> mterry I originally wanted to find all the cherry-picks, but that quickly became not as useful because of all the patch overwriting
[14:50] <elbrus> pitti: what SHOULD I use as TMPDIR
[14:50] <elbrus> when I need one?
[14:50] <pitti> elbrus: I don't know; what's not good enough about /tmp?
[14:50] <elbrus> don't know, why is it not set then?
[14:50] <pitti> elbrus: I don't know why you need a $TMPDIR, so that's hard to answer
[14:51] <elbrus> a place to store temporary stuff ;)
[14:51] <pitti> -Test-Command: TMPDIR=/tmp test/runtests.sh
[14:51] <pitti> +Test-Command: test/runtests.sh
[14:51] <pitti> ah
[14:51] <pitti> so if you explicitly use $TMPDIR without a fallback, but don't set it any more, there's the problem :)
[14:51] <elbrus> indeed
[14:52] <pitti> elbrus: mkdir(1), mkstemp() etc. all default to /tmp
[14:52] <elbrus> well, fallback is the empty string
[14:52] <pitti> right, but then mkdir $TMPDIR/share will be /share
[14:52] <pitti> you probably either want something like
[14:52] <pitti> myworkdir=$(mktemp -d)
[14:52] <pitti> or perhaps use ${TMPDIR:-/tmp}
[14:52] <elbrus> ok, I will fix the test framework to do a proper fallback with mktmp
[14:53] <chiluk> mterry then I'll poke pitti or arges to approve the SRU after your review.
[14:53] <pitti> or just hardcode /tmp/workdir/
[14:53] <elbrus> yeah, I like  ${TMPDIR:-/tmp}
[14:53] <pitti> elbrus: ^ this is bad style for production code (susceptible to symlink attacks and DoS), but probably tolerable for test code
[14:53] <pitti> elbrus: oh, perhaps you meant $ADTTMP
[14:53] <elbrus> indeed
[14:53] <pitti> elbrus: you can use that, it's created/cleaned for every test, and it's owned by you
[14:54] <elbrus> could I do that TMPDIR=$ADTMP in the command line?
[14:54] <pitti> elbrus: sure
[14:54] <elbrus> or does the command line not resolve variables?
[14:55] <elbrus> pitti: I mean in the "Test-Command" line
[14:55] <pitti> elbrus: it does, it's a normal shell string
[14:56] <mterry> chiluk, where is lib/mountlist.c in coreutils trunk?
[14:56] <pitti> elbrus: you used that before, after all
[14:56] <chiluk> mterry that's part of the gnulib trung
[14:56] <elbrus> nope: I just set it, not use an other variable in it
[14:56] <chiluk> mterry debian takes both the gnulib and coreutils projects and merges them into the coreutils package
[14:56] <elbrus> but ok, I will just update the test-command line then
[14:57] <mterry> chiluk, ah right...  humph
[14:57] <pitti> elbrus: it'd be the first test that uses $ADTTMP in the Test-Command:, but it ought to work and is certainly meant to
[14:57] <chiluk> mterry  http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=commit;h=c6148bca89e9465fd6ba3a10d273ec4cb58c2dbe
[14:57] <pitti> elbrus: thanks!
[14:57] <elbrus> np
[15:16] <mterry> chiluk, so I'm on board with the patch itself.  But building it in a pbuilder failed on some tests.  Trying to figure out why, but have you seen anything similar?
[15:16] <chiluk> pbuilder doesn't build coreutils well.
[15:16] <chiluk> mterry use sbuild.
[15:16] <chiluk> I hit the same issue.
[15:16] <mterry> humph
[15:17] <chiluk> yeah we should probably care, but I just moved to sbuild for coreutils
[15:17] <chiluk> mterry++ for test building!
[15:18] <mterry> chiluk, yeah except I'm just going to trust your build rather than moving to sbuild  ;)
[15:18] <chiluk> mterry now I'm scared...
[15:18]  * chiluk goes to build it one more time for shits and giggles.
[15:19] <elbrus> pitti: just a thought, could the results of auto-pkg-test not be made more visible, e.g. in the launchpad page of the source of a package?
[15:20] <elbrus> now everytime I need to search where again these results are stored (no I don't bookmark a lot)
[15:20] <pitti> elbrus: we certainly could; just didn't happen so far
[15:20] <elbrus> I believe it is worth it
[15:21] <elbrus> other question, how long does a package stay in the proposed slot if auto-pkg-test doesn't fail?
[15:21] <elbrus> I mean, if it is there, can I assume the test failed?
[15:22] <pitti> elbrus: we don't have time based migration; as soon as it's built, installable, and tests succeed it lands
[15:22] <cjwatson> LP doesn't currently have good support for linking to artifacts outside LP
[15:22] <pitti> elbrus: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#dbconfig-common
[15:22] <cjwatson> we'd like to have that so that LP itself doesn't have to grow so much, but we don't really yet
[15:22] <pitti> elbrus: you see there's no excuse for "too young", we don't do that
[15:22] <cjwatson> William did some work recently on generalising cross-references, with an eye towards supporting this better in the future
[15:22] <elbrus> cjwatson, pitti: ack
[15:28] <infinity> cjwatson, Odd_Bloke: I can give that a try in a VM and see what it does.
[15:28] <chiluk> mterry yes built fine, with pristine sources for me.
[15:28] <Odd_Bloke> infinity: Yes please!
[15:28] <mterry> chiluk, nice
[15:28] <mterry> chiluk, commented on bug, uploaded to trusy
[15:28] <infinity> Odd_Bloke: I assume it's a "proper" cloud image with cloud init and such and will do Bad Things without a fake data source or whatever?
[15:28] <chiluk> yeah it's a pbuilder sbuild issue somehow.
[15:29] <Odd_Bloke> infinity: Yep.
[15:30] <Odd_Bloke> infinity: The disk is created using the same codepath as ppc64el; cjwatson thought that disk format might be an option, and it was easy to create so that's what I did.
[15:30] <Odd_Bloke> infinity: If we need to do something different (e.g. MBR rather than GPT), that's doable. :)
[15:31] <infinity> Odd_Bloke: GPT should work fine.  I just have to remember how to boot a cloud image. :P
[15:32] <Odd_Bloke> infinity: If I'm testing stuff in a published image, I do it in a cloud because they remember how to do that for me. :p
[15:33] <infinity> Odd_Bloke: Yeah, well, chickens and eggs.  I'm just testing with raw qemu to see if it does a thing.
[15:33] <Odd_Bloke> It will not work on a chicken.
[15:34] <ogra_> cloudy chicken ?
[15:43] <seb128> bdmurray, hey, the nautilus retracing in 15.10 seem to fail, do you know why? e.g https://errors.ubuntu.com/problem/d3c6ff4abc2efa01df5d1b7e2c89932a61eabe27
[15:45] <infinity> Odd_Bloke: No dice.  Drops me to a grub CLI.
[15:46] <Odd_Bloke> infinity: Sadface.  Is there a way I can reproduce the boot problem?
[15:48] <infinity> Odd_Bloke: Do you have access to the power test network in 1SS? (can you connect to 10.245.64.15?)
[15:50] <Odd_Bloke> infinity: Doesn't look like it.
[15:50] <infinity> Odd_Bloke: Might want to ask IS nicely if you can get VPN/firewall access to it.  Then I can give you root on a host to fiddle.
[15:55] <Odd_Bloke> infinity: Ack; RT opened.
[15:57] <elbrus> pitti: $ dput ssh-upload ~/tmp/packages/dbconfig-common_1.8.56_source.changes # done
[16:03] <pitti> elbrus: \o/ cheers
[16:03] <pitti> elbrus: oh, do source uploads for arch:all now work for Debian?
[16:03] <elbrus> let's see if it works (didn't test that)
[16:03] <elbrus> yes
[16:03] <elbrus> only restriction is you can't do it with packages that go throu NEW (but that is also true for arch:any)
[16:06] <bdmurray> seb128: I'll have a look.
[16:06] <seb128> bdmurray, thanks
[16:07] <bdmurray> seb128: It has a bunch of ?? () in the retraced Stacktrace
[16:08] <seb128> bdmurray, same for https://errors.ubuntu.com/problem/38f94b04b1728eb78d82f272f0a7ec8d53ec8bab and https://errors.ubuntu.com/problem/bb3d8512e950429cd93b4fdea436327758d988bb ?
[16:11] <bdmurray> seb128: yeah
[16:12] <seb128> bdmurray, do you know if any debug symbol is missing or something?
[16:13] <bdmurray> seb128: a couple mention libibus-1.0-5, libuuid1, libgirepository-1.0-1.
[16:14] <seb128> those shouldn't matter for the top of the stacktrace...
[16:14] <bdmurray> seb128: right
[16:25] <slangasek> doko_, infinity, dannf: is there any known breakage with the neon implementation on our armhf autobuilders and/or cady?  ffmpeg FTBFS with a neon test failure which doesn't fail in Debian unstable; ffmpeg itself is supposed to dynamically detect whether neon is present, and appears to be doing that correctly based on /proc/cpuinfo, so the test would be skipped if neon were not available
[16:27] <dannf> slangasek: not known breakage; is this exynos5? I know we did a lot of performance testing back in the day w/ neon enabled and didn't have any problems. so, neon is there, but perhaps it is buggy
[16:27] <slangasek> er, rather - the test would fail if built on a machine without neon, but the code itself would runtime-detect
[16:27] <infinity> slangasek: The highbanks are NEON-capable and should be fine.
[16:27] <slangasek> dannf: cady is exynos5.  I don't know about the builders
[16:27] <dannf> builders are highbank
[16:28] <slangasek> ok, so why does this NEON test explicitly pass in Debian and fail in Ubuntu
[16:28] <dannf> or midway - one of the calxedas
[16:28] <infinity> slangasek: Debian's builders might not be NEON-capable, you might be debugging it backwards.
[16:28] <ogra_> yeah
[16:28] <slangasek> infinity: no, the Debian build log shows the NEON test running and passing
[16:28]  * ogra_ was about to say that
[16:28] <slangasek> which AFAICS it wouldn't be able to pass if Debian's builders were non-NEON; if I'm reading right it would give invalid instruction
[16:29] <infinity> It wouldn't just skip the test and claim a pass?
[16:29] <slangasek> infinity: by my read, no; #if HAVE_NEON (which the log shows is true), call the neon function
[16:29] <infinity> Hrm.
[16:29] <slangasek> anyway
[16:30] <slangasek> if there are no known problems w/ neon on these boxes, I'll continue digging - thanks
[16:32] <infinity> Certainly none that I've run into.
[16:32] <infinity> We build and test a lot of NEON code.
[16:32] <infinity> And the highbanks are pretty much just stock A9s, nothing sketchy going on with the core design.
[16:33] <ogra_> are there actually still non-NEON v7 arches that we support ?
[16:33] <ogra_> probably it is time to re-visit the defaults of this anyway
[16:34] <infinity> ogra_: Well, "the defaults" don't need to change even if we revisit (which, yes, I wanted to do for 16.04), just the "disable NEON where it's on by default upstream" thing could change.
[16:35] <infinity> Auto-vectorization with NEON still sucks, so the toolchain shouldn't ever change.
[16:35] <ogra_> ah, k
[16:35] <ogra_> yeah, i meant the toolchain/compiler opts
[16:35] <infinity> No one cares about Tegra1, AFAIK, the only other interesting target is some older Armadas.
[16:35] <infinity> I think the newer Armadas have NEON.
[16:36] <ogra_> right, both of them is what i'd consider dead by now :)
[16:36] <infinity> But I meant to draft a mail about it and gather some data and opinions before changing our position.
[16:37]  * ogra_ is all for switching ... 
[16:38] <dannf> doko_: do you know if this was ever submitted upstream? looks like i might have a need to sru it back to trusty - https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=785756
[16:38] <ubottu> Debian bug 785756 in src:libffi "libffi: bug on arm64 when passing small struct on stack" [Normal,Fixed]
[16:43] <doko_> slangasek, I don't know about any
[16:46] <dscastro> hello, i have random crashes on my apache, i managed to get the stack http://www.fpaste.org/287684/44682637/
[16:51] <infinity> dscastro: https://bugs.launchpad.net/ubuntu/+source/php5/+filebug
[17:13] <chiluk> mterry https://launchpadlibrarian.net/224248565/buildlog_ubuntu-vivid-ppc64el.coreutils_8.23-3ubuntu1.1_BUILDING.txt.gz   do you know if this is valid?
[17:19] <mterry> chiluk, failed on test-lock?
[17:19] <chiluk> yeah that doesn't make any sense to me.
[17:21] <chiluk> I'm really quite confused because it builds for every other arch including wily
[17:21] <chiluk> mterry did you happen to turn that test off for the wily upload?
[17:21] <chiluk> I just wonder if there was a coincidence..
[17:22] <mterry> chiluk, I don't think it was that test that got changed
[17:22] <chiluk> maybe it was a fluke build failure?
[17:23] <chiluk> I wonder if infinity has any clue why it might be failing on ppc64el
[17:23] <chiluk> infinity: https://launchpadlibrarian.net/224248565/buildlog_ubuntu-vivid-ppc64el.coreutils_8.23-3ubuntu1.1_BUILDING.txt.gz
[17:23] <chiluk> infinity it's only failing on ppc64el, and mostly the same code works in wily...
[17:23] <chiluk> I don't think my patch affected that test at all.
[17:24] <caribou> cyphermox: LP: #1491894 has the debdiff for the review we've made yesterday
[17:24] <ubottu> Launchpad bug 1491894 in grub2 (Ubuntu Trusty) "lucid to precise to trusty upgrade may leave system unbootable" [High,In progress] https://launchpad.net/bugs/1491894
[17:25] <seb128> doko, what's the right component to report the fact that gdb doesn't work when python-scripts is loaded?
[17:26] <cyphermox> caribou: great.
[17:30] <doko> seb128, gdb
[17:30] <seb128> doko, thanks
[17:34] <infinity> chiluk: Dunno off the top of my head, but a hint for you is that ppc64el is the only arch that builds -O3 by default, the rest are -O2.
[17:35] <infinity> chiluk: It could also just be a cosmic rays oops.  I'll retry it.
[17:36] <chiluk> thanks infinty
[17:45] <infinity> chiluk: Worked on a retry.
[18:03] <pitti> utlemming: how does the net.ifnames=0 get into a cloud-image boot? I don't see it in the cloud-init package
[18:04] <pitti> utlemming: my images got broken as I purged cloud-init and rebooted, then the network names changed
[18:09] <ogra_> pitti, livecd-rootfs revision 1219
[18:10] <pitti> ah, so it's the image build process
[18:10] <ogra_> -GRUB_CMDLINE_LINUX_DEFAULT="console=tty1 console=ttyS0"
[18:10] <ogra_> +GRUB_CMDLINE_LINUX_DEFAULT="console=tty1 console=ttyS0 net.ifnames=0"
[18:10] <ogra_> seems it mangles /etc/default/grub
[18:12] <pitti> so I wonder how it's not there any more after a reboot
[18:12] <seb128> doko, k, so the gdb issue might be 32bits specific
[18:12] <seb128>   File "/usr/share/gdb/python/gdb/FrameDecorator.py", line 97, in function
[18:12] <seb128>     if not isinstance(self._base, gdb.Frame)
[18:12] <seb128> OverflowError: Python int too large to convert to C long
[18:13] <ogra_> pitti, well, do you see it in /etc/default/grub ?
[18:13] <seb128> doko, unsure why it's starting in xenial/with the python default change
[18:13] <seb128> barry, ^ you might know?
[18:14] <pitti> ogra_: ah, I have a /etc/default/grub.d/, and that doesn't have this change
[18:14] <ogra_> aha
[18:14] <fossterer> Hi! I've been using 15.10 daily builds so far. Now that 16.04 daily-builds are getting ready, is there a way for me to move to 16.04?
[18:14] <barry> seb128: yes, that's a 32bit thing.  i had the same problem in system-image way back when
[18:14] <pitti> meh
[18:14] <ogra_> fossterer, sudo do-release-upgrade -d
[18:14] <pitti> so this hack ripples through everything using cloud images now
[18:14] <ogra_> that should get you onto the development release (if update-manager already knows about it)
[18:15] <seb128> barry, do you know what changed between wily and xenial that it starts being an issue now only?
[18:15] <fossterer> ogra_: Can you use it to upgrade an installed 'daily-build' ?
[18:15] <ogra_> pitti, yeah, sadly using the "hooks" subdir for hack in livecd-roofs has become a common practice :(
[18:15] <ogra_> *for hacks
[18:15] <barry> seb128: sorry, is that in gdb?
[18:16] <seb128> barry, yes
[18:16] <seb128> barry,  File "/usr/share/gdb/python/gdb/FrameDecorator.py", line 97, in function
[18:16] <seb128>      if not isinstance(self._base, gdb.Frame)
[18:17] <jtaylor> ah problem in gdb/python in xenial is that the frameobject is optimized out now
[18:17] <jtaylor> very annoying
[18:17] <jtaylor> might be related
[18:17] <seb128> barry, gdb didn't change though, it just got a non change rebuild with the new python default
[18:18] <jtaylor> I wonder if doko would accept a patch to python to keep the object not removed, I doubt it has performance relevance
[18:19] <seb128> jtaylor, what do you mean optimized out? is there a report about that?
[18:19] <seb128> jtaylor, also gdb didn't change so why/how did that change?
[18:19] <barry> seb128: yeah, my question too :)
[18:20] <jtaylor> let me have a look, reproducable how?
[18:21] <seb128> reported bug #1513922
[18:21] <ubottu> bug 1513922 in gdb (Ubuntu) "[xenial] backtrace gives python error" [Undecided,New] https://launchpad.net/bugs/1513922
[18:21] <seb128> jtaylor, use i386, "gdb <binary>", run, ctrl-C, bt
[18:22] <jtaylor> hm that looks more like a bug in gdb
[18:23] <jtaylor> 0xffffffff is a bit strange address
[18:23] <seb128> yeah, i'm just wondering why it was working in wily
[18:23] <jtaylor> isn't that range reserved for kernel?
[18:24]  * jtaylor needs to create a chroot first
[18:25] <fossterer> Ok,Thanks for responding, ogra_!
[18:25] <fossterer> I'll try with 'do-release-upgrade'
[18:29] <jtaylor> seb128: which binary did you use?
[18:29] <jtaylor> i386 kernel too?
[18:30] <seb128> yes for the kernel
[18:30] <seb128> binary I tried different ones
[18:30] <seb128> initially nautilus
[18:30] <seb128> but it does the same on e.g gnome-calculator
[18:31] <seb128> jtaylor, does the same with "vim"
[18:32] <seb128> (attaching an instance open elsewhere)
[18:32] <jtaylor> I only have an amd64 kernel available maybe I won't see it
[18:34] <jtaylor> weird that you get such a number, I think the userspace max address should be 0xbfffffff on 32 bit
[18:34] <seb128> yeah
[18:35] <slangasek> doko, infinity, dannf: fwiw the ffmpeg build failure is reproducible on armhf with the previous version of ffmpeg on xenial, so looks like a toolchain regression
[18:38] <pitti> ogra_: thanks for pointing out
[18:38] <ogra_> :)
[18:38] <pitti> utlemming: I now added a counter-hack in autopkgtest, but meh not pretty; I added a task to bug 1510345, can we clean this up for xenial?
[18:38] <ubottu> bug 1510345 in cloud-init (Ubuntu Xenial) "[SRU] Cloud Images do not bring up networking w/ certain virtual NICs due to device naming rules" [Undecided,Triaged] https://launchpad.net/bugs/1510345
[18:43] <jtaylor> seb128: fwiw I think the bug is in py-framefilter.c:1103 which is missing an overflow check
[18:43] <jtaylor> but I'm clueless where the number comes from, probably need to fix gdb first to see that :)
[18:55] <seb128> jtaylor, can you comment on the bug saying that?
[18:56] <jtaylor> I posted a patch there
[18:56] <seb128> thanks
[18:56] <jtaylor> might be the wrong spot, just guessing :)
[18:57] <dobey> is there a debootstrap update for trusty, that supports xenial?
[18:57] <dobey> ie
[18:57] <dobey> E: No such script: /usr/share/debootstrap/scripts/xenial
[18:57] <dobey> i get that when trying to lxc-create a xenial container
[18:58] <jtaylor> dobey: apt-get upgrade should do it
[18:59] <dobey> jtaylor: was it just released today? i install updates every morning, as i have some daily PPAs
[18:59] <jtaylor> dobey: oh you need -proposed
[19:02] <dobey> oh, no bzr imports for xenial?
[19:03] <dobey> jtaylor: how much longer til it shows up it in -updates?
[19:06] <dobey> meh i'll just copy the xenial version to my ppa :)
[19:08] <jtaylor> you can also just create the symlink yourself
[19:43] <chiluk> thanks infinity
[19:45] <dobey> jtaylor: ugh. well lxc-create failed because "lxcguest" is not available but referred to by another package, now :(
[19:46] <dobey> guess i'll have to create a vivid image and then dist-upgrade it to xenial :-/
[19:46] <chiluk> mterry, infinity says the respin fixed the ppc64 vivid build.
[19:46] <mterry> chiluk, oh nice
[19:46] <chiluk> mterry how's the review going?  any questions?
[19:47] <mterry> chiluk, didn't I mention uploading to trusty?
[19:47] <mterry> chiluk, I commented in bug too
[19:47] <mterry> chiluk, just waiting on sru approval to go through to proposed
[19:47] <chiluk> alrighty thanks!
=== salem_ is now known as _salem
=== tlyu_ is now known as tlyu
=== tlyu_ is now known as tlyu