| === JanC_ is now known as JanC | ||
| === gusnan_ is now known as gusnan | ||
| pitti | @pilot in | 09:10 |
|---|---|---|
| === udevbot changed the topic of #ubuntu-devel to: Yakkety Yak (16.10) Released | Archive: open | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-yakkety | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | Patch Pilots: pitti | ||
| === _salem is now known as salem_ | ||
| tsimonq2 | pitti: You're still patch pilot? :) | 12:10 |
| pitti | yes | 12:10 |
| tsimonq2 | pitti: There's a diff here that should go to yakkety-proposed and start the SRU procedure: bug 1636655 | 12:11 |
| ubottu | bug 1636655 in ark (Ubuntu) "[SRU] Ark no longer opens rar files in 16.10" [Undecided,Fix released] https://launchpad.net/bugs/1636655 | 12:11 |
| tsimonq2 | juliank thought it was logical enough to upload to Zesty. ;) | 12:12 |
| tsimonq2 | (not that it isn't) | 12:12 |
| tsimonq2 | pitti: Any chance you could look at that when you get a minute? :) | 12:13 |
| pitti | tsimonq2: sure! will do | 12:14 |
| tsimonq2 | Thanks a lot pitti. :) | 12:15 |
| pitti | tsimonq2: uploaded and accepted into -proposed | 12:18 |
| tsimonq2 | pitti: Awesome! Thanks a lot. :) | 12:19 |
| pitti | no prob! | 12:19 |
| tsimonq2 | pitti: So then it starts the SRU procedure? | 12:20 |
| tsimonq2 | I'm not seeing what else needs to happen for that... | 12:20 |
| pitti | tsimonq2: yes, now needs to build, and someone must verify it | 12:20 |
| tsimonq2 | Ok. :) | 12:20 |
| tsimonq2 | Oh cool, ok, I see you commented. | 12:20 |
| tsimonq2 | All published successfully! | 12:25 |
| juliank | pkern: the bash trusty SRU failed to build on arm64 :/ | 13:23 |
| juliank | But weirdly not in a changed part ... | 13:23 |
| juliank | ../.././builtins/../.././builtins/help.def:130:7: error: format not a string literal and no format arguments [-Werror=format-security] | 13:24 |
| juliank | The patch changed lib/readline/misc.c | 13:24 |
| juliank | I mean, the warning is certainly right - the line is: | 13:27 |
| juliank | printf (ngettext ("Shell commands matching keyword `", "Shell commands matching keywords `", (list->next ? 2 : 1))); | 13:27 |
| juliank | But why does this only fail on arm64? | 13:27 |
| juliank | and why only now, and not in 1.5? | 13:27 |
| juliank | Fix should be easy (unless I missed something): | 13:28 |
| juliank | printf ("%s", ngettext ("Shell commands matching keyword `", "Shell commands matching keywords `", (list->next ? 2 : 1))); | 13:28 |
| juliank | Worse: It only fails for the statically linked build | 13:31 |
| pitti | @pilot out | 13:50 |
| === udevbot changed the topic of #ubuntu-devel to: Yakkety Yak (16.10) Released | Archive: open | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-yakkety | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | Patch Pilots: | ||
| === fionnan_ is now known as fionnan | ||
| ScottK | Assuming you all are going to Qt 5.7.1 this cycle, you can leave qscintilla2 FTBFS in proposed for now and give it back when you do that transition. | 14:18 |
| infinity | pitti: Oh, did armhf autopkgtest move to aarch64 nodes? | 14:25 |
| pitti | infinity: yes, some months ago at last | 14:25 |
| infinity | pitti: Can we boot them the same way we boot our buildds? :) | 14:26 |
| pitti | infinity: tests run in lxd containers with disabled apparmor; is there anything further to it? | 14:26 |
| infinity | pitti: compat_uts_machine=armv7l on the commandline. | 14:26 |
| pitti | infinity: I suppose buildds use armhf schroots on arm64? | 14:26 |
| infinity | pitti: So they pretend a bit harder to be v7. | 14:26 |
| pitti | infinity: that's for the armhf container guest, or does that need to go into the host config? | 14:27 |
| infinity | pitti: 'linux32 uname -m' on a buildd returns armv7l, on autopkgtest, it returns armv8l. | 14:27 |
| pitti | where "host" == "nova instance" really | 14:27 |
| infinity | pitti: Kernel commandline. | 14:27 |
| infinity | pitti: So, host. Obviously. | 14:27 |
| pitti | infinity: and that won't break actual arm64 instances? | 14:28 |
| infinity | Just changes the 32-bit personality. | 14:28 |
| infinity | So, no. | 14:28 |
| pitti | infinity: I figure this is for some glibc test or so? | 14:28 |
| infinity | Nope. glibc doesn't care. | 14:28 |
| infinity | It's for every other person who thinks that testing for uname -m is smart. | 14:28 |
| infinity | And it's not smart. | 14:28 |
| infinity | But making our machines pretend to be armv7l kernels is easier than fixing all the stupid code. | 14:29 |
| pitti | infinity: ok, I'll write an RT, CCing you | 14:30 |
| infinity | (This is the same reason why linux32 uname -m on x86_64 still reports i686, and always will, despite P4 and up being "i786", and i7 possibly being "i886"... | 14:30 |
| infinity | ) | 14:30 |
| infinity | Sadly, I lost the upstream argument about why it should be armv7l forever, but at least we have a simple downstream bodge. | 14:30 |
| infinity | pitti: Err, oh. When I say "host", I mean your VM. | 14:31 |
| infinity | pitti: Confused about layering there. | 14:32 |
| pitti | infinity: right, and I don't have control over that, it's nova instances | 14:32 |
| infinity | pitti: The kvm host host doesn't matter, obviously. | 14:32 |
| pitti | hence an RT | 14:32 |
| infinity | Ahh. Curious why yours and the buildds weren't configured the same out of the gate. | 14:32 |
| pitti | RT sent | 14:33 |
| pitti | infinity: hm, now that I sent it I realized I coudl probalby just add that to their grub config | 14:33 |
| infinity | Yes. | 14:34 |
| infinity | pitti: I'm not smart enough to map this URL back to where the test was triggered to retrigger it: | 14:38 |
| infinity | https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial-snappy-dev-snapcraft-daily/xenial/armhf/s/snapcraft/20161118_041037_8a45b@/log.gz | 14:38 |
| infinity | pitti: But those "lol armv8l, what's that?" failure should go away with that cmdline option. | 14:38 |
| pitti | infinity: you can't, it's from a snapcraft github pull request | 14:38 |
| infinity | pitti: I can't, or nobody can? | 14:39 |
| pitti | you can't | 14:39 |
| pitti | mvo, sergiusens, or I CAN | 14:39 |
| pitti | "can" | 14:39 |
| pitti | (shift failure, although the emphasis wasn't completely wrong either :) ) | 14:39 |
| infinity | Shiny. Can you, if you can get your VMs rebooted with the right magic? | 14:39 |
| pitti | already at it | 14:40 |
| infinity | FWIW, I've also taken up a parallel conversation on "why using uname -m to guess at userspace ABI is wrong", since this is Canonical code. | 14:40 |
| infinity | But still a good testcase, given that we know this problem is far-reaching beyond places I can be bothered to fix. | 14:41 |
| pitti | ubuntu@lxd-armhf8:~$ linux32 uname -m | 14:41 |
| pitti | armv7l | 14:41 |
| pitti | ubuntu@lxd-armhf8:~$ uname -m | 14:41 |
| pitti | aarch64 | 14:41 |
| pitti | better | 14:42 |
| infinity | \o/ | 14:42 |
| pitti | ok, now roll this out to the other 7 | 14:43 |
| pitti | infinity: this is from https://github.com/snapcore/snapcraft/pull/917 | 14:50 |
| infinity | pitti: Which tells me nothing about autopkgtest results there. I guess there's still some integration work required? :) | 14:51 |
| pitti | infinity: no, just since you asked where this can be retried | 14:52 |
| * pitti currently figures that out | 14:52 | |
| pitti | infinity: ok, I think I got it; it's back to "running" and on http://autopkgtest.ubuntu.com/running#pkg-snapcraft (need to scroll down a bit) | 14:54 |
| pitti | sergiusens: ^ FYI | 14:54 |
| sergiusens | pitti I am trying to figure out what you are talking about :-) | 14:55 |
| pitti | sergiusens: the failure in https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial-snappy-dev-snapcraft-daily/xenial/armhf/s/snapcraft/20161118_041037_8a45b%40/log.gz | 14:55 |
| pitti | sergiusens: I just fixed our armhf test envs to say "armv7l" for uname -m | 14:56 |
| pitti | sergiusens: and kicked that test | 14:56 |
| sergiusens | pitti oh, thanks; we can always improve our logic here too | 14:56 |
| infinity | sergiusens: Right, so I had an email back and forth with Leo about it, but worth repeating here that "trying to determing userspace ABI using uname is wrong". | 15:04 |
| infinity | sergiusens: But pitti's above fix will make those tests pass at least. :P | 15:05 |
| infinity | sergiusens: That said, while I will stand by the "uname isn't userspace ABI" mantra, it's decidedly harder to determine userspace ABI when you don't know for sure what your host system is. I'm not sure what these tests are targeting (ie: all distros, just Ubuntu, etc) | 15:06 |
| infinity | sergiusens: For dpkg systems, "dpkg --print-architecture" is more likely to be the answer you're looking for. | 15:06 |
| pitti | isn't there some gcc command that prints the GNU triplet? would that help? | 15:07 |
| infinity | sergiusens: But that starts falling over when you don't know what sort of system your base actually is, then people do crazy things like try to find the linker for /bin/mv and determine ABI from that, etc. :P | 15:07 |
| infinity | pitti: Also valid if you have a compiler installed, and you trusty it's targeting the host, yes. | 15:08 |
| infinity | Lots of "ifs". | 15:08 |
| infinity | s/trusty/trust/ ... That release has ruined me forever. | 15:08 |
| sergiusens | infinity we migrated away from dpkg --print-architecture as we will be going to other distros | 15:08 |
| sergiusens | infinity we will need to go the crazy route | 15:08 |
| infinity | sergiusens: Might be worth tearing apart the problem to first principles and ask why you're trying to determine the userspace ABI. | 15:09 |
| bswartz | pitti: does debian seriously not have a proper bug database? they use an email list to track bugs? | 15:09 |
| infinity | sergiusens: And how you're using that value. | 15:09 |
| infinity | bswartz: It's a proper database, it's just mail-driven. | 15:09 |
| infinity | If "proper database" means "can submit via a web form", then no, they don't. | 15:10 |
| pitti | bswartz: well, it's "a" bug database; I wouldn't call it "proper", but it's here: https://bugs.debian.org/cgi-bin/pkgreport.cgi?repeatmerged=no&src=xfce4-clipman-plugin | 15:10 |
| pitti | bswartz: yes, all modifications happen over email, browsing is r/o | 15:10 |
| bswartz | okay I see it does have a web frontend for viewing bugs | 15:10 |
| pitti | the word you are looking for is "arcane" :) | 15:10 |
| bswartz | ty | 15:11 |
| sergiusens | infinity we want something similar to dpkg-architecture | 15:11 |
| pitti | the big advantage is that it's so hard to use that bug reports are usually high quality | 15:11 |
| infinity | sergiusens: Right, I'm trying to first principle this to "why are you asking, and what are you doing with it", though. | 15:11 |
| infinity | sergiusens: So I can see if maybe there's a not entirely crazy way to achieve your goal on all GNUish systems. | 15:12 |
| infinity | sergiusens: Note that this will get more complicated than you think, depending on your goal. ;) | 15:12 |
| sergiusens | infinity I know it is; reason for us falling into these issues | 15:13 |
| infinity | (ie: if it's about build targets, how do I define that I want to build *for* i386 on my x86_64 system with i386 libs installed? Is that a supported usecase, or do you demand I do it in a clean i386-only chroot?) | 15:13 |
| infinity | sergiusens: And don't be afraid to impose restrictions on the users where fixing the corner cases is Really Really Hard, IMO. :P | 15:14 |
| sergiusens | infinity we construct gnu arch triplets, have a primitive form of cross building (specifically for kernels), translate debian arch names to all those and figure out the arch we are on. All this using something as simple as python's platform.machine() which triggers this problem | 15:17 |
| sergiusens | and yes 32bit in 64bit userspace has been requested but I am trying not to go down that path | 15:17 |
| infinity | sergiusens: So, the 32-on-64 recommendation for now is a 32bit chroot, and linux32 to fake the uname. | 15:18 |
| infinity | sergiusens: Which will, indeed, fail for armhf-on-aarch64 anywhere other than our buildds and (as of a few minutes ago) our autopkgtest infra, unless you recognize armv8l. | 15:19 |
| infinity | Which suffers from the minor issue that armv8l isn't actually entirely compaible with armv7l (it is in our infra, but only because we made it be). | 15:19 |
| sergiusens | infinity if we can support that some how similar to dpkg --print-architecture it would be good. I was mentioning people wanting to build an "amd64" package including "i386" binaries | 15:19 |
| pitti | sergiusens, infinity: it failed again, but this time it's not my fault.. I believe: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial-snappy-dev-snapcraft-daily/xenial/armhf/s/snapcraft/20161118_150313_8a45b@/log.gz | 15:19 |
| infinity | Ahh, people who want to do that are silly. | 15:20 |
| sergiusens | infinity I already have this issue on some systems with 64bit kernels and 32bit userspaces so I do want to solve it | 15:20 |
| infinity | pitti: Yeahp, that looks much better. Closes the issue Leo asked me about and I escalated to you. :) | 15:20 |
| infinity | sergiusens: So, if a compiler is always there, and you trust it's sane, gcc -dumpmachine is pretty much what you're after for guessing "native" compilation. | 15:22 |
| pitti | so, ${CC:-gcc} -dumpmachine ? | 15:23 |
| sergiusens | infinity I can make it be there; I'll get a bug task up to fix this; thanks! | 15:23 |
| pitti | or actually ${CC:-cc}, because llvm and friends? | 15:24 |
| infinity | clang doesn't exist, it's all in your head. | 15:24 |
| pitti | rly? my head runs with llvm? /me logs off now and washes it out with a pint of beer then | 15:25 |
| infinity | And, unhelpfully, clang on Debian uses different triplets than gcc. | 15:25 |
| infinity | Yay. | 15:25 |
| sergiusens | pitti good way to start the weekend | 15:26 |
| infinity | (xenial-amd64)root@nosferatu:~# gcc -dumpmachine | 15:26 |
| infinity | x86_64-linux-gnu | 15:26 |
| infinity | (xenial-amd64)root@nosferatu:~# clang -dumpmachine | 15:26 |
| infinity | x86_64-pc-linux-gnu | 15:26 |
| === sil2100_ is now known as sil2100 | ||
| philroche | rbasak: I see you are a member of Ubuntu Development Team. Would you have any time to review https://code.launchpad.net/~philroche/ubuntu/+source/gce-compute-image-packages/+git/gce-compute-image-packages/+merge/311153 ? | 17:01 |
| === pavlushka is now known as SweetVenom | ||
| === SweetVenom is now known as pavlushka | ||
| smoser | slangasek, ping. | 17:28 |
| smoser | for bug 1611074 | 17:28 |
| ubottu | bug 1611074 in cloud-init (Ubuntu) "Reformatting of ephemeral drive fails on resize of Azure VM" [High,Confirmed] https://launchpad.net/bugs/1611074 | 17:28 |
| smoser | i plan to upload ro zesty and xenial today with the contents of https://code.launchpad.net/~smoser/cloud-init/+git/cloud-init/+merge/311205 | 17:28 |
| smoser | to replace the existing -proposed for xenial | 17:28 |
| smoser | so i'd like your review of that. | 17:29 |
| slangasek | smoser: I don't have time right now to review; if you upload now and get my review in the queue, maybe it saves a step? | 17:39 |
| smoser | well, i have a few minor thigns that i still have to fix, so i was hoping youd look at what is there, but thats ok. i understand. | 17:39 |
| slangasek | smoser: ok. I'll look ASAP | 17:44 |
| slangasek | just don't know yet when P is :) | 17:44 |
| smoser | slangasek, i really appreciate your help. thanks. | 17:46 |
| teward | pitti: thanks for handling that sync request by the way | 18:27 |
| slangasek | smoser: changes to cloudinit/config/cc_mounts.py look good; I'm nervous about the extent of the changes to cloudinit/sources/DataSourceAzure.py if this is meant to be quick turnaround; have not had a chance yet to review those changes | 19:03 |
| === pavlushka is now known as PocketBot-lushka | ||
| === PocketBot-lushka is now known as pavlushka | ||
| === salem_ is now known as _salem | ||
| smoser | slangasek, i think ultimately the new code is more supportable, and we will be testing it explicitly. | 19:16 |
| smoser | its *all* related to this path | 19:16 |
| nacc | LocutusOfBorg: was there a reason to mark LP: #1624632 as incomplete rather than fix released? given that it's synced now? | 19:25 |
| ubottu | Launchpad bug 1624632 in tomcat8 (Ubuntu) "Sync tomcat8 8.0.36-3 (main) from Debian unstable (main)" [Wishlist,Incomplete] https://launchpad.net/bugs/1624632 | 19:25 |
| hjd | Hi all, could someone please schedule mina2 to be built in zesty? It originally failed to build when it was synced (possibly due to dependencies not synced or built yet?), but it builds successfully now on my local zesty vm. | 19:53 |
| jbicha | hjd: done https://launchpad.net/ubuntu/+source/mina2/2.0.16-1/ | 20:34 |
| hjd | jbicha: :) | 20:36 |
| === _salem is now known as salem_ | ||
| smoser | slangasek, if you could read https://git.launchpad.net/cloud-init/commit/?id=6942c948422205502071f725fde0cc9cba329131 | 20:46 |
| === salem_ is now known as _salem | ||
| slangasek | smoser: tmpf=$(mktemp "${TMPDIR:-/tmp/cloud-init-upgrade.XXXXXX}") - I think you want tmpf=$(mktemp "${TMPDIR:-/tmp}/cloud-init-upgrade.XXXXXX") ? | 21:16 |
| smoser | yes | 21:17 |
| smoser | wow. | 21:17 |
| slangasek | smoser: mktemp also has a '-p' option you can use, then you could just do 'mktemp -p cloud-init-upgrade.XXXXXX' for same effect | 21:17 |
| smoser | i'm surprised i typed that | 21:17 |
| smoser | good job | 21:17 |
| smoser | how old is mktemp -p ? | 21:18 |
| slangasek | dunno | 21:18 |
| slangasek | have just checked and see it in trusty | 21:18 |
| smoser | checking precise... just curious really. cause that is much nicer | 21:18 |
| slangasek | do you need it to be in precise? ok | 21:18 |
| smoser | i dont | 21:18 |
| smoser | mostly i'm just curious | 21:18 |
| smoser | we'll take your suggestion | 21:18 |
| slangasek | smoser: your awk substitution also lacks the =cloud-init.service part of the x.systemd-requires | 21:19 |
| slangasek | or x-systemd.requires | 21:20 |
| slangasek | whichever is correct ;) | 21:20 |
| smoser | -p DIR use DIR as a prefix; implies -t [deprecated] | 21:20 |
| smoser | and -t says deprecated currenlty | 21:21 |
| smoser | wierd | 21:21 |
| slangasek | heh | 21:21 |
| smoser | not sure what to make of that | 21:21 |
| slangasek | oh; -p requires a DIR argument | 21:22 |
| slangasek | so maybe none of that is all that useful, or maybe you have to use the '--tmpdir' syntax | 21:22 |
| smoser | slangasek, ok. i fixed those two things (good catch) | 21:25 |
| smoser | with http://paste.ubuntu.com/23497537/ | 21:25 |
| smoser | gonna just not use the -p because it confuses me right now :) | 21:25 |
| slangasek | smoser: ok, looks good. The last thing, by using a tmpfile in /tmp + cp, you'll lose things like selinux labels AIUI (and possibly even posix perms, if someone has something weird on /etc/fstab). I believe you'll get a more correct result with just cat $tmpf > /etc/fstab | 21:26 |
| slangasek | cp is not atomic anyway so you're not at a disadvantage there by using cat | 21:26 |
| smoser | so you think cat ? | 21:27 |
| smoser | i wondered on that too | 21:27 |
| slangasek | yeah | 21:27 |
| smoser | i thought cp might fail better | 21:27 |
| smoser | but cat is fine. i will fix. | 21:28 |
| smoser | i guess the safest thign to do would be to mktemp /etc/.$0.XXXXXX | 21:29 |
| smoser | and then mv | 21:29 |
| smoser | but i think its fine | 21:29 |
| smoser | oh. but mv might stick perms too | 21:29 |
| smoser | so cat i think | 21:29 |
| smoser | thank uyou | 21:29 |
| slangasek | smoser: n/p | 21:30 |
| smoser | i'm gonna upload now. | 21:31 |
| smoser | slangasek, it is in queue now. | 21:58 |
| LocutusOfBorg | nacc, the reason is "wrong button" it is fix released now, thanks :) | 22:08 |
| nacc | LocutusOfBorg: :) np, just wanted to check in! | 22:12 |
| slangasek | smoser: none of this new code in DataSourceAzure should ever run if we haven't already detected that we're on azure, correct? i.e. we're not going to have a 120s timeout waiting for a disk that will never arrive, in other clouds? | 22:18 |
| slangasek | smoser: I ask because the previous incarnation of the code had no timeout for disk discovery, it just checked if they were present. Possibly the new activate logic does this but I haven't traced the code enough to confirm that this is true | 22:46 |
| nacc | smoser: slangasek: rbasak: jgrimm: barry: here is an example updated import (well just the last version) of php7.0 with both patches-applied and patches-unapplied available: | 22:48 |
| nacc | patches-applied: https://git.launchpad.net/~usd-import-team/ubuntu/+source/php7.0/log/?h=applied/ubuntu/zesty | 22:48 |
| nacc | unapplied: https://git.launchpad.net/~usd-import-team/ubuntu/+source/php7.0/log/?h=ubuntu/zesty | 22:48 |
| nacc | you can see in the latter, as well, that it merged my upload tagged object into the history | 22:48 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!