=== _salem is now known as salem_
=== salem_ is now known as _salem
=== _salem is now known as salem_
=== salem_ is now known as _salem
psusiwasn't there a tag to assign to bugs related to the dmraid -> mdadm transition for intel fakeraids?01:50
kryptoi 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
kryptoin centos its in /etc/sysconfig/libvirt but not sure what to add in /etc/default/libvirt05:55
=== hikiko-lpt is now known as hikiko
dholbachgood morning07:50
=== ara is now known as Guest38632
Odd_Blokecjwatson: 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
ubottuLaunchpad bug 1513754 in livecd-rootfs (Ubuntu) "Move cloud image building further on to buildds" [Undecided,New]08:48
Odd_Blokeinfinity: wgrant: You may also be interested in ^.08:49
Mirvdholbach: 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
dholbachMirv, I don't think I have access to whatever requires ./copy-package to be run09:17
MirvI copied the PPA ones + all others for xenial which were universe, but that one package is in main09:17
dholbachI'm not an archive admin09:17
Mirvdholbach: you don't need to be09:17
Mirvdholbach: 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
Mirvthe command only complains if one tries to copy to real xenial instead of proposed09:18
Laneyyou get it from lpubuntu-archive-tools09:19
dholbachok, I'll take a look09:20
dholbachjust a sec09:20
Mirvthanks. I only selected you since you said good morning here so I thought you'd be around :)09:20
dholbachMirv, done09:22
Mirvdholbach: thanks! Saviq ^ all done now09:24
=== nudtrobert1 is now known as nudtrobert
rbasakpinba-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 resolution09:40
rbasakOpinions on forcing it and dropping pinba-engine-mysql from those architectures?09:41
rbasak(the Debian maintainer forwarded it)09:41
cjwatsonrbasak: well, we shouldn't force it in proposed-migration, but yeah, I'm somewhat inclined to remove it from the affected architectures.  let me look09:45
cjwatsonI know I synced it, doko had previously reverted it, had been meaning to look anyway09:45
cjwatsonrbasak: could you remind me of a reference to the upstream bug?09:45
cjwatsonOdd_Bloke: thanks, looking09:46
rbasakcjwatson: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=793511 and https://github.com/tony2001/pinba_engine/issues/4009:47
ubottuDebian bug 793511 in src:pinba-engine-mysql "pinba-engine-mysql: FTBFS (32-bit): cannot convert 'uint64_t*' to 'Word_t*" [Serious,Open]09:47
cjwatsonrbasak: thanks, nuked from xenial09:49
cjwatson(on 32-bit arches)09:49
rbasakcjwatson: thank you!09:55
cjwatsonOdd_Bloke: uploaded09:59
cjwatsonthanks for the long patch!09:59
Odd_Blokecjwatson: Thanks!10:32
roaksoax_pitti: howdy! is there a way to tell adt to build different packages when passing --unbuilt-tree ?10:40
roaksoax_pitti: right now we are saying "--unbuilt-tree=$PATH/maas" and 'maas' is the source, that contrais debian/ inside10:41
roaksoax_pitti: however, I not only want to build MAAS, but I also want to build another package *before* maas10:41
roaksoax_pitti: i.e: http://pastebin.ubuntu.com/13123203/10:43
roaksoax_pitti: or is there another way to insert dependencies?10:54
ShockI 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?11:12
=== _salem is now known as salem_
=== hikiko__ is now known as hikiko
Odd_Blokecjwatson: Would you expect powerpc cloud images to have UEFI and a PReP partition a la ppc64el?12:14
Odd_Blokecjwatson: FFS, s/UEFI/GPT/.12:15
Odd_BlokeSome day I will stop conflating those two things.12:15
Odd_Blokecjwatson: Or would a single-partition MBR (a la amd64/i386 -disk1 images) be what you would expect?12:16
cjwatsonOdd_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
cjwatsonOdd_Bloke: infinity might have a clearer idea.12:40
cjwatsonOdd_Bloke: It's possible that UEFI might work, but it will probably depend on the firmware ...12:40
cjwatsonMaybe it's safe to assume a new enough slof.12:40
cjwatsonErr, GPT not UEFI.  Now you've got me doing it. :-P12:41
Odd_BlokeOK, 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.12:50
pittiroaksoax_: in principle you can run another test (including build) before the maas argument, yes13:06
pittiroaksoax_: 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 test13:07
=== rcj` is now known as rcj
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
cjwatsonogra_: thanks, not concerned right now (at a conference) if it isn't persistent13:33
roaksoax_pitti: ok, great! Thanks!13:48
roaksoax_pitti: so basically, doing something like this: http://paste.ubuntu.com/13124111/13:51
Odd_Blokecjwatson: https://launchpad.net/~cloud-images-release-managers/+livefs/ubuntu/xenial/cpc/+build/42512 \o/14:08
elbrusis Martin Pitt around?14:11
seb128elbrus, he's pitti on IRC14:12
Odd_Blokepitti: ^14:12
cjwatsonOdd_Bloke: whee14:12
cjwatsonOdd_Bloke: do you have a way to test that this actually does something useful? :-)14:13
Odd_Blokecjwatson: Not really; I was sort of hoping you did. :p14:14
cjwatsoninfinity: ^- can you help out?14:17
elbruspitti: /me is looking at auto-pkg-test failures for dbconfig-common14:19
elbruslast time you send me a patch.14:19
elbrusI was wondering if the failure is related to $TMP(which I removed from the command)14:20
=== francisco is now known as Guest24983
* 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 Ubuntu14:23
cjwatsonelbrus: 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:24
elbruscjwatson: 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
cjwatsonqemu> !14:31
elbrusit is mentioned (but not explained how)14:31
cjwatsonyou might find that the slew of options autopkgtests passes to qemu all by itself means you don't have to spend much time on that14:32
cjwatsonmaybe you just weren't using the right options ... qemu has lots14:32
elbrusok, let me look at that after my current project than.14:34
pittielbrus: hey14:40
pittielbrus: man adt-virt-qemu explains how to build a suitable VM for sid14:41
pittielbrus: https://people.debian.org/~mpitt/autopkgtest/README.running-tests.html (or in /usr/share/doc/autopkgtest/) explains teh available runners14:41
elbruspitti: did you already look at dbconfig-common by any chance?14:41
pittielbrus: lxc is fine, as long as you don't have a test which needs to twiddle kernel-y things (dbconfig shold be fine)14:41
pittithat should even get along fine with a simple schroot14:42
pittielbrus: no, not yet, sorry14:42
elbrusno, I mean I should look at it myself instead of you14:42
pittiindeed, recent regression14:42
elbrus(Debian mentality here ;))14:42
pittielbrus: that'd be great (I don't have much time right now, sprint and all)14:43
pittimkdir: cannot create directory ‘/share’: Permission denied14:43
pittiASSERT:expected:<1.8 1.10 1.10.1 1.10.2 1.11 1.12> but was:<>14:43
pittithat's hopefully not too difficult to reproduce/understand for you?14:43
elbrusdo you think it could be related to TMP not being set by me anymore?14:43
pittilooks like this is new in 1.8.5514:43
pittielbrus: sure, if that mkdir does something like mkdir $TMP/share14:44
mterrychiluk, ever find another sponsor?  I can look at coreutils now14:44
chilukrtg took a quick look, but he got scared away.. so mterry that would be fantastic.14:44
elbrusthe regression doesn't make sense for anything in the "normal" code and the regression test runs fine for me...14:44
elbrusso I believe it must be the env that is different14:45
mterrychiluk, so this patch was different, did you have to backport more commits, or just make some minor adjustments or what?14:45
chilukrtg 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 again14:45
pittielbrus: we've never set $TMP explicitly in the tests14:45
chilukmterry I had to backport another 6 or so prereq patches.14:45
chilukthe patches to the mountlist function are fairly similar..14:46
chilukdf needed a bunch more work.14:46
mterrychiluk, ick yeah.  I'm on board with one patch.  Not like they will be removed one by one later14:46
elbruspitty: now, but my old testcase had it in the command, but I thought it wasn't really needed14:46
chilukright.. it would make it easier to review in whole later.14:47
elbrusapparently it is for the auto-pkg-test framework14:47
mterrychiluk, not that trusty is a moving target really  :)14:47
chilukmterry .. may i suggest patching the sources, and then comparing the result with upstream at the last patch..14:47
mterrychiluk, good idea  :)14:47
mterrynice that we're in sync with upstream then14:48
chiluki.e. compare the df.c patch with http://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=commit;h=3babaf83875ceac896c8dd3a64248e955dfecef914:48
chilukand compare mountlist.c at http://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=commit;h=3babaf83875ceac896c8dd3a64248e955dfecef914:49
chilukmterry ^^14:49
elbruspitti: I should have said TMPDIR...14:49
pittielbrus: ah; adt-run did set that some years ago, but this was dropped a long time ago, not in the last month14:50
chilukmterry I originally wanted to find all the cherry-picks, but that quickly became not as useful because of all the patch overwriting14:50
elbruspitti: what SHOULD I use as TMPDIR14:50
elbruswhen I need one?14:50
pittielbrus: I don't know; what's not good enough about /tmp?14:50
elbrusdon't know, why is it not set then?14:50
pittielbrus: I don't know why you need a $TMPDIR, so that's hard to answer14:50
elbrusa place to store temporary stuff ;)14:51
pitti-Test-Command: TMPDIR=/tmp test/runtests.sh14:51
pitti+Test-Command: test/runtests.sh14:51
pittiso if you explicitly use $TMPDIR without a fallback, but don't set it any more, there's the problem :)14:51
pittielbrus: mkdir(1), mkstemp() etc. all default to /tmp14:52
elbruswell, fallback is the empty string14:52
pittiright, but then mkdir $TMPDIR/share will be /share14:52
pittiyou probably either want something like14:52
pittimyworkdir=$(mktemp -d)14:52
pittior perhaps use ${TMPDIR:-/tmp}14:52
elbrusok, I will fix the test framework to do a proper fallback with mktmp14:52
chilukmterry then I'll poke pitti or arges to approve the SRU after your review.14:53
pittior just hardcode /tmp/workdir/14:53
elbrusyeah, I like  ${TMPDIR:-/tmp}14:53
pittielbrus: ^ this is bad style for production code (susceptible to symlink attacks and DoS), but probably tolerable for test code14:53
pittielbrus: oh, perhaps you meant $ADTTMP14:53
pittielbrus: you can use that, it's created/cleaned for every test, and it's owned by you14:53
elbruscould I do that TMPDIR=$ADTMP in the command line?14:54
pittielbrus: sure14:54
elbrusor does the command line not resolve variables?14:54
elbruspitti: I mean in the "Test-Command" line14:55
pittielbrus: it does, it's a normal shell string14:55
mterrychiluk, where is lib/mountlist.c in coreutils trunk?14:56
pittielbrus: you used that before, after all14:56
chilukmterry that's part of the gnulib trung14:56
elbrusnope: I just set it, not use an other variable in it14:56
chilukmterry debian takes both the gnulib and coreutils projects and merges them into the coreutils package14:56
elbrusbut ok, I will just update the test-command line then14:56
mterrychiluk, ah right...  humph14:57
pittielbrus: it'd be the first test that uses $ADTTMP in the Test-Command:, but it ought to work and is certainly meant to14:57
chilukmterry  http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=commit;h=c6148bca89e9465fd6ba3a10d273ec4cb58c2dbe14:57
pittielbrus: thanks!14:57
mterrychiluk, 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
chilukpbuilder doesn't build coreutils well.15:16
chilukmterry use sbuild.15:16
chilukI hit the same issue.15:16
chilukyeah we should probably care, but I just moved to sbuild for coreutils15:17
chilukmterry++ for test building!15:17
mterrychiluk, yeah except I'm just going to trust your build rather than moving to sbuild  ;)15:18
chilukmterry now I'm scared...15:18
* chiluk goes to build it one more time for shits and giggles.15:18
elbruspitti: 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:19
elbrusnow everytime I need to search where again these results are stored (no I don't bookmark a lot)15:20
pittielbrus: we certainly could; just didn't happen so far15:20
elbrusI believe it is worth it15:20
elbrusother question, how long does a package stay in the proposed slot if auto-pkg-test doesn't fail?15:21
elbrusI mean, if it is there, can I assume the test failed?15:21
pittielbrus: we don't have time based migration; as soon as it's built, installable, and tests succeed it lands15:22
cjwatsonLP doesn't currently have good support for linking to artifacts outside LP15:22
pittielbrus: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#dbconfig-common15:22
cjwatsonwe'd like to have that so that LP itself doesn't have to grow so much, but we don't really yet15:22
pittielbrus: you see there's no excuse for "too young", we don't do that15:22
cjwatsonWilliam did some work recently on generalising cross-references, with an eye towards supporting this better in the future15:22
elbruscjwatson, pitti: ack15:22
infinitycjwatson, Odd_Bloke: I can give that a try in a VM and see what it does.15:28
chilukmterry yes built fine, with pristine sources for me.15:28
Odd_Blokeinfinity: Yes please!15:28
mterrychiluk, nice15:28
mterrychiluk, commented on bug, uploaded to trusy15:28
infinityOdd_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
chilukyeah it's a pbuilder sbuild issue somehow.15:28
Odd_Blokeinfinity: Yep.15:29
Odd_Blokeinfinity: 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_Blokeinfinity: If we need to do something different (e.g. MBR rather than GPT), that's doable. :)15:30
infinityOdd_Bloke: GPT should work fine.  I just have to remember how to boot a cloud image. :P15:31
Odd_Blokeinfinity: If I'm testing stuff in a published image, I do it in a cloud because they remember how to do that for me. :p15:32
infinityOdd_Bloke: Yeah, well, chickens and eggs.  I'm just testing with raw qemu to see if it does a thing.15:33
Odd_BlokeIt will not work on a chicken.15:33
ogra_cloudy chicken ?15:34
seb128bdmurray, hey, the nautilus retracing in 15.10 seem to fail, do you know why? e.g https://errors.ubuntu.com/problem/d3c6ff4abc2efa01df5d1b7e2c89932a61eabe2715:43
infinityOdd_Bloke: No dice.  Drops me to a grub CLI.15:45
Odd_Blokeinfinity: Sadface.  Is there a way I can reproduce the boot problem?15:46
infinityOdd_Bloke: Do you have access to the power test network in 1SS? (can you connect to
Odd_Blokeinfinity: Doesn't look like it.15:50
infinityOdd_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:50
Odd_Blokeinfinity: Ack; RT opened.15:55
elbruspitti: $ dput ssh-upload ~/tmp/packages/dbconfig-common_1.8.56_source.changes # done15:57
pittielbrus: \o/ cheers16:03
pittielbrus: oh, do source uploads for arch:all now work for Debian?16:03
elbruslet's see if it works (didn't test that)16:03
elbrusonly restriction is you can't do it with packages that go throu NEW (but that is also true for arch:any)16:03
bdmurrayseb128: I'll have a look.16:06
seb128bdmurray, thanks16:06
bdmurrayseb128: It has a bunch of ?? () in the retraced Stacktrace16:07
seb128bdmurray, same for https://errors.ubuntu.com/problem/38f94b04b1728eb78d82f272f0a7ec8d53ec8bab and https://errors.ubuntu.com/problem/bb3d8512e950429cd93b4fdea436327758d988bb ?16:08
bdmurrayseb128: yeah16:11
seb128bdmurray, do you know if any debug symbol is missing or something?16:12
bdmurrayseb128: a couple mention libibus-1.0-5, libuuid1, libgirepository-1.0-1.16:13
seb128those shouldn't matter for the top of the stacktrace...16:14
bdmurrayseb128: right16:14
slangasekdoko_, 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 available16:25
dannfslangasek: 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 buggy16:27
slangaseker, rather - the test would fail if built on a machine without neon, but the code itself would runtime-detect16:27
infinityslangasek: The highbanks are NEON-capable and should be fine.16:27
slangasekdannf: cady is exynos5.  I don't know about the builders16:27
dannfbuilders are highbank16:27
slangasekok, so why does this NEON test explicitly pass in Debian and fail in Ubuntu16:28
dannfor midway - one of the calxedas16:28
infinityslangasek: Debian's builders might not be NEON-capable, you might be debugging it backwards.16:28
slangasekinfinity: no, the Debian build log shows the NEON test running and passing16:28
* ogra_ was about to say that16:28
slangasekwhich AFAICS it wouldn't be able to pass if Debian's builders were non-NEON; if I'm reading right it would give invalid instruction16:28
infinityIt wouldn't just skip the test and claim a pass?16:29
slangasekinfinity: by my read, no; #if HAVE_NEON (which the log shows is true), call the neon function16:29
slangasekif there are no known problems w/ neon on these boxes, I'll continue digging - thanks16:30
infinityCertainly none that I've run into.16:32
infinityWe build and test a lot of NEON code.16:32
infinityAnd the highbanks are pretty much just stock A9s, nothing sketchy going on with the core design.16:32
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 anyway16:33
infinityogra_: 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:34
infinityAuto-vectorization with NEON still sucks, so the toolchain shouldn't ever change.16:35
ogra_ah, k16:35
ogra_yeah, i meant the toolchain/compiler opts16:35
infinityNo one cares about Tegra1, AFAIK, the only other interesting target is some older Armadas.16:35
infinityI think the newer Armadas have NEON.16:35
ogra_right, both of them is what i'd consider dead by now :)16:36
infinityBut I meant to draft a mail about it and gather some data and opinions before changing our position.16:36
* ogra_ is all for switching ... 16:37
dannfdoko_: 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=78575616:38
ubottuDebian bug 785756 in src:libffi "libffi: bug on arm64 when passing small struct on stack" [Normal,Fixed]16:38
doko_slangasek, I don't know about any16:43
dscastrohello, i have random crashes on my apache, i managed to get the stack http://www.fpaste.org/287684/44682637/16:46
infinitydscastro: https://bugs.launchpad.net/ubuntu/+source/php5/+filebug16:51
chilukmterry https://launchpadlibrarian.net/224248565/buildlog_ubuntu-vivid-ppc64el.coreutils_8.23-3ubuntu1.1_BUILDING.txt.gz   do you know if this is valid?17:13
mterrychiluk, failed on test-lock?17:19
chilukyeah that doesn't make any sense to me.17:19
chilukI'm really quite confused because it builds for every other arch including wily17:21
chilukmterry did you happen to turn that test off for the wily upload?17:21
chilukI just wonder if there was a coincidence..17:21
mterrychiluk, I don't think it was that test that got changed17:22
chilukmaybe it was a fluke build failure?17:22
chilukI wonder if infinity has any clue why it might be failing on ppc64el17:23
chilukinfinity: https://launchpadlibrarian.net/224248565/buildlog_ubuntu-vivid-ppc64el.coreutils_8.23-3ubuntu1.1_BUILDING.txt.gz17:23
chilukinfinity it's only failing on ppc64el, and mostly the same code works in wily...17:23
chilukI don't think my patch affected that test at all.17:23
cariboucyphermox: LP: #1491894 has the debdiff for the review we've made yesterday17:24
ubottuLaunchpad bug 1491894 in grub2 (Ubuntu Trusty) "lucid to precise to trusty upgrade may leave system unbootable" [High,In progress] https://launchpad.net/bugs/149189417:24
seb128doko, what's the right component to report the fact that gdb doesn't work when python-scripts is loaded?17:25
cyphermoxcaribou: great.17:26
dokoseb128, gdb17:30
seb128doko, thanks17:30
infinitychiluk: 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:34
infinitychiluk: It could also just be a cosmic rays oops.  I'll retry it.17:35
chilukthanks infinty17:36
infinitychiluk: Worked on a retry.17:45
pittiutlemming: how does the net.ifnames=0 get into a cloud-image boot? I don't see it in the cloud-init package18:03
pittiutlemming: my images got broken as I purged cloud-init and rebooted, then the network names changed18:04
ogra_pitti, livecd-rootfs revision 121918:09
pittiah, so it's the image build process18: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/grub18:10
pittiso I wonder how it's not there any more after a reboot18:12
seb128doko, k, so the gdb issue might be 32bits specific18:12
seb128  File "/usr/share/gdb/python/gdb/FrameDecorator.py", line 97, in function18:12
seb128    if not isinstance(self._base, gdb.Frame)18:12
seb128OverflowError: Python int too large to convert to C long18:12
ogra_pitti, well, do you see it in /etc/default/grub ?18:13
seb128doko, unsure why it's starting in xenial/with the python default change18:13
seb128barry, ^ you might know?18:13
pittiogra_: ah, I have a /etc/default/grub.d/, and that doesn't have this change18:14
fosstererHi! 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
barryseb128: yes, that's a 32bit thing.  i had the same problem in system-image way back when18:14
ogra_fossterer, sudo do-release-upgrade -d18:14
pittiso this hack ripples through everything using cloud images now18:14
ogra_that should get you onto the development release (if update-manager already knows about it)18:14
seb128barry, do you know what changed between wily and xenial that it starts being an issue now only?18:15
fosstererogra_: 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 hacks18:15
barryseb128: sorry, is that in gdb?18:15
seb128barry, yes18:16
seb128barry,  File "/usr/share/gdb/python/gdb/FrameDecorator.py", line 97, in function18:16
seb128     if not isinstance(self._base, gdb.Frame)18:16
jtaylorah problem in gdb/python in xenial is that the frameobject is optimized out now18:17
jtaylorvery annoying18:17
jtaylormight be related18:17
seb128barry, gdb didn't change though, it just got a non change rebuild with the new python default18:17
jtaylorI wonder if doko would accept a patch to python to keep the object not removed, I doubt it has performance relevance18:18
seb128jtaylor, what do you mean optimized out? is there a report about that?18:19
seb128jtaylor, also gdb didn't change so why/how did that change?18:19
barryseb128: yeah, my question too :)18:19
jtaylorlet me have a look, reproducable how?18:20
seb128reported bug #151392218:21
ubottubug 1513922 in gdb (Ubuntu) "[xenial] backtrace gives python error" [Undecided,New] https://launchpad.net/bugs/151392218:21
seb128jtaylor, use i386, "gdb <binary>", run, ctrl-C, bt18:21
jtaylorhm that looks more like a bug in gdb18:22
jtaylor0xffffffff is a bit strange address18:23
seb128yeah, i'm just wondering why it was working in wily18:23
jtaylorisn't that range reserved for kernel?18:23
* jtaylor needs to create a chroot first18:24
fosstererOk,Thanks for responding, ogra_!18:25
fosstererI'll try with 'do-release-upgrade'18:25
jtaylorseb128: which binary did you use?18:29
jtaylori386 kernel too?18:29
seb128yes for the kernel18:30
seb128binary I tried different ones18:30
seb128initially nautilus18:30
seb128but it does the same on e.g gnome-calculator18:30
seb128jtaylor, does the same with "vim"18:31
seb128(attaching an instance open elsewhere)18:32
jtaylorI only have an amd64 kernel available maybe I won't see it18:32
jtaylorweird that you get such a number, I think the userspace max address should be 0xbfffffff on 32 bit18:34
slangasekdoko, infinity, dannf: fwiw the ffmpeg build failure is reproducible on armhf with the previous version of ffmpeg on xenial, so looks like a toolchain regression18:35
pittiogra_: thanks for pointing out18:38
pittiutlemming: 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
ubottubug 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/151034518:38
jtaylorseb128: fwiw I think the bug is in py-framefilter.c:1103 which is missing an overflow check18:43
jtaylorbut I'm clueless where the number comes from, probably need to fix gdb first to see that :)18:43
seb128jtaylor, can you comment on the bug saying that?18:55
jtaylorI posted a patch there18:56
jtaylormight be the wrong spot, just guessing :)18:56
dobeyis there a debootstrap update for trusty, that supports xenial?18:57
dobeyE: No such script: /usr/share/debootstrap/scripts/xenial18:57
dobeyi get that when trying to lxc-create a xenial container18:57
jtaylordobey: apt-get upgrade should do it18:58
dobeyjtaylor: was it just released today? i install updates every morning, as i have some daily PPAs18:59
jtaylordobey: oh you need -proposed18:59
dobeyoh, no bzr imports for xenial?19:02
dobeyjtaylor: how much longer til it shows up it in -updates?19:03
dobeymeh i'll just copy the xenial version to my ppa :)19:06
jtayloryou can also just create the symlink yourself19:08
chilukthanks infinity19:43
dobeyjtaylor: ugh. well lxc-create failed because "lxcguest" is not available but referred to by another package, now :(19:45
dobeyguess i'll have to create a vivid image and then dist-upgrade it to xenial :-/19:46
chilukmterry, infinity says the respin fixed the ppc64 vivid build.19:46
mterrychiluk, oh nice19:46
chilukmterry how's the review going?  any questions?19:46
mterrychiluk, didn't I mention uploading to trusty?19:47
mterrychiluk, I commented in bug too19:47
mterrychiluk, just waiting on sru approval to go through to proposed19:47
chilukalrighty thanks!19:47
=== salem_ is now known as _salem
=== tlyu_ is now known as tlyu
=== tlyu_ is now known as tlyu

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!