| === _salem is now known as salem_ | ||
| === salem_ is now known as _salem | ||
| === _salem is now known as salem_ | ||
| === salem_ is now known as _salem | ||
| psusi | wasn't there a tag to assign to bugs related to the dmraid -> mdadm transition for intel fakeraids? | 01:50 |
|---|---|---|
| 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 | 05:55 |
| === hikiko-lpt is now known as hikiko | ||
| dholbach | good morning | 07:50 |
| === ara is now known as Guest38632 | ||
| 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:48 |
| Odd_Bloke | infinity: wgrant: You may also be interested in ^. | 08:49 |
| 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:17 |
| 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:18 |
| Laney | you get it from lpubuntu-archive-tools | 09:19 |
| 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:20 |
| dholbach | :) | 09:22 |
| dholbach | Mirv, done | 09:22 |
| Mirv | dholbach: thanks! Saviq ^ all done now | 09:24 |
| === nudtrobert1 is now known as nudtrobert | ||
| 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:40 |
| rbasak | Opinions on forcing it and dropping pinba-engine-mysql from those architectures? | 09:41 |
| rbasak | (the Debian maintainer forwarded it) | 09:41 |
| 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:45 |
| cjwatson | Odd_Bloke: thanks, looking | 09:46 |
| 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:47 |
| cjwatson | rbasak: thanks, nuked from xenial | 09:49 |
| cjwatson | (on 32-bit arches) | 09:49 |
| rbasak | cjwatson: thank you! | 09:55 |
| cjwatson | Odd_Bloke: uploaded | 09:59 |
| cjwatson | thanks for the long patch! | 09:59 |
| Odd_Bloke | cjwatson: 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/ inside | 10:41 |
| roaksoax_ | pitti: however, I not only want to build MAAS, but I also want to build another package *before* maas | 10:41 |
| roaksoax_ | pitti: i.e: http://pastebin.ubuntu.com/13123203/ | 10:43 |
| roaksoax_ | pitti: or is there another way to insert dependencies? | 10:54 |
| Shock | hi | 11:10 |
| 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? | 11:12 |
| === _salem is now known as salem_ | ||
| === hikiko__ is now known as hikiko | ||
| Odd_Bloke | cjwatson: Would you expect powerpc cloud images to have UEFI and a PReP partition a la ppc64el? | 12:14 |
| Odd_Bloke | cjwatson: FFS, s/UEFI/GPT/. | 12:15 |
| Odd_Bloke | Some day I will stop conflating those two things. | 12:15 |
| Odd_Bloke | cjwatson: Or would a single-partition MBR (a la amd64/i386 -disk1 images) be what you would expect? | 12:16 |
| 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:40 |
| cjwatson | Err, GPT not UEFI. Now you've got me doing it. :-P | 12:41 |
| Odd_Bloke | :D | 12:49 |
| 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. | 12:50 |
| pitti | roaksoax_: in principle you can run another test (including build) before the maas argument, yes | 13:06 |
| 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 | 13: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 |
| cjwatson | ogra_: thanks, not concerned right now (at a conference) if it isn't persistent | 13:33 |
| ogra_ | k | 13:33 |
| roaksoax_ | pitti: ok, great! Thanks! | 13:48 |
| roaksoax_ | pitti: so basically, doing something like this: http://paste.ubuntu.com/13124111/ | 13:51 |
| Odd_Bloke | cjwatson: https://launchpad.net/~cloud-images-release-managers/+livefs/ubuntu/xenial/cpc/+build/42512 \o/ | 14:08 |
| elbrus | is Martin Pitt around? | 14:11 |
| seb128 | elbrus, he's pitti on IRC | 14:12 |
| Odd_Bloke | pitti: ^ | 14:12 |
| cjwatson | Odd_Bloke: whee | 14:12 |
| cjwatson | Odd_Bloke: do you have a way to test that this actually does something useful? :-) | 14:13 |
| Odd_Bloke | cjwatson: Not really; I was sort of hoping you did. :p | 14:14 |
| cjwatson | infinity: ^- can you help out? | 14:17 |
| elbrus | pitti: /me is looking at auto-pkg-test failures for dbconfig-common | 14:19 |
| elbrus | last time you send me a patch. | 14:19 |
| elbrus | I 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 Ubuntu | 14:23 | |
| 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:24 |
| 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:31 |
| 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:32 |
| elbrus | ok, let me look at that after my current project than. | 14:34 |
| pitti | elbrus: hey | 14:40 |
| 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:41 |
| 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:42 |
| 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:43 |
| 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:44 |
| 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:45 |
| 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:46 |
| 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:47 |
| 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:48 |
| 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:49 |
| 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:50 |
| 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:51 |
| 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:52 |
| 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:53 |
| 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:54 |
| elbrus | pitti: I mean in the "Test-Command" line | 14:55 |
| pitti | elbrus: it does, it's a normal shell string | 14:55 |
| 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:56 |
| 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 | 14:57 |
| 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:16 |
| chiluk | yeah we should probably care, but I just moved to sbuild for coreutils | 15:17 |
| chiluk | mterry++ for test building! | 15:17 |
| 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:18 | |
| 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:19 |
| 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:20 |
| 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:21 |
| 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:22 |
| 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:28 |
| Odd_Bloke | infinity: Yep. | 15:29 |
| 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:30 |
| infinity | Odd_Bloke: GPT should work fine. I just have to remember how to boot a cloud image. :P | 15:31 |
| 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:32 |
| 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:33 |
| ogra_ | cloudy chicken ? | 15:34 |
| 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:43 |
| infinity | Odd_Bloke: No dice. Drops me to a grub CLI. | 15:45 |
| Odd_Bloke | infinity: Sadface. Is there a way I can reproduce the boot problem? | 15:46 |
| infinity | Odd_Bloke: Do you have access to the power test network in 1SS? (can you connect to 10.245.64.15?) | 15:48 |
| 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:50 |
| Odd_Bloke | infinity: Ack; RT opened. | 15:55 |
| elbrus | pitti: $ dput ssh-upload ~/tmp/packages/dbconfig-common_1.8.56_source.changes # done | 15:57 |
| 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:03 |
| bdmurray | seb128: I'll have a look. | 16:06 |
| seb128 | bdmurray, thanks | 16:06 |
| bdmurray | seb128: It has a bunch of ?? () in the retraced Stacktrace | 16:07 |
| seb128 | bdmurray, same for https://errors.ubuntu.com/problem/38f94b04b1728eb78d82f272f0a7ec8d53ec8bab and https://errors.ubuntu.com/problem/bb3d8512e950429cd93b4fdea436327758d988bb ? | 16:08 |
| bdmurray | seb128: yeah | 16:11 |
| seb128 | bdmurray, do you know if any debug symbol is missing or something? | 16:12 |
| bdmurray | seb128: a couple mention libibus-1.0-5, libuuid1, libgirepository-1.0-1. | 16:13 |
| seb128 | those shouldn't matter for the top of the stacktrace... | 16:14 |
| bdmurray | seb128: right | 16:14 |
| 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:25 |
| 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:27 |
| 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:28 |
| 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:29 |
| slangasek | if there are no known problems w/ neon on these boxes, I'll continue digging - thanks | 16:30 |
| 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: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 anyway | 16:33 |
| 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:34 |
| 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:35 |
| 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:36 |
| * ogra_ is all for switching ... | 16:37 | |
| 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:38 |
| doko_ | slangasek, I don't know about any | 16:43 |
| dscastro | hello, i have random crashes on my apache, i managed to get the stack http://www.fpaste.org/287684/44682637/ | 16:46 |
| infinity | dscastro: https://bugs.launchpad.net/ubuntu/+source/php5/+filebug | 16:51 |
| 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:13 |
| mterry | chiluk, failed on test-lock? | 17:19 |
| chiluk | yeah that doesn't make any sense to me. | 17:19 |
| 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:21 |
| mterry | chiluk, I don't think it was that test that got changed | 17:22 |
| chiluk | maybe it was a fluke build failure? | 17:22 |
| 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:23 |
| 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:24 |
| seb128 | doko, what's the right component to report the fact that gdb doesn't work when python-scripts is loaded? | 17:25 |
| cyphermox | caribou: great. | 17:26 |
| doko | seb128, gdb | 17:30 |
| seb128 | doko, thanks | 17:30 |
| 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:34 |
| infinity | chiluk: It could also just be a cosmic rays oops. I'll retry it. | 17:35 |
| chiluk | thanks infinty | 17:36 |
| infinity | chiluk: Worked on a retry. | 17:45 |
| 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:03 |
| pitti | utlemming: my images got broken as I purged cloud-init and rebooted, then the network names changed | 18:04 |
| ogra_ | pitti, livecd-rootfs revision 1219 | 18:09 |
| 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:10 |
| 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:12 |
| 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:13 |
| 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:14 |
| 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:15 |
| 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:16 |
| 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:17 |
| jtaylor | I wonder if doko would accept a patch to python to keep the object not removed, I doubt it has performance relevance | 18:18 |
| 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:19 |
| jtaylor | let me have a look, reproducable how? | 18:20 |
| 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:21 |
| jtaylor | hm that looks more like a bug in gdb | 18:22 |
| 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:23 |
| * jtaylor needs to create a chroot first | 18:24 | |
| fossterer | Ok,Thanks for responding, ogra_! | 18:25 |
| fossterer | I'll try with 'do-release-upgrade' | 18:25 |
| jtaylor | seb128: which binary did you use? | 18:29 |
| jtaylor | i386 kernel too? | 18:29 |
| 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:30 |
| seb128 | jtaylor, does the same with "vim" | 18:31 |
| seb128 | (attaching an instance open elsewhere) | 18:32 |
| jtaylor | I only have an amd64 kernel available maybe I won't see it | 18:32 |
| 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:34 |
| 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:35 |
| 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:38 |
| 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:43 |
| seb128 | jtaylor, can you comment on the bug saying that? | 18:55 |
| jtaylor | I posted a patch there | 18:56 |
| seb128 | thanks | 18:56 |
| jtaylor | might be the wrong spot, just guessing :) | 18:56 |
| 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:57 |
| jtaylor | dobey: apt-get upgrade should do it | 18:58 |
| 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 | 18:59 |
| dobey | oh, no bzr imports for xenial? | 19:02 |
| dobey | jtaylor: how much longer til it shows up it in -updates? | 19:03 |
| dobey | meh i'll just copy the xenial version to my ppa :) | 19:06 |
| jtaylor | you can also just create the symlink yourself | 19:08 |
| chiluk | thanks infinity | 19:43 |
| dobey | jtaylor: ugh. well lxc-create failed because "lxcguest" is not available but referred to by another package, now :( | 19:45 |
| 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:46 |
| 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! | 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!