[00:18] -queuebot:#ubuntu-release- Unapproved: accepted nvidia-graphics-drivers-390 [source] (bionic-proposed) [390.77-0ubuntu0.18.04.1] [03:47] has anyone (jbicha?) looked at the ruby-gnome regression with pango1.0? [03:48] it's just a rounding thing but i wonder why it's broken now... [04:39] why isn't that a desktop package? ;p [05:02] doko: because plymouth depends on it [05:02] (so it's shared desktop/foundations) [05:13] ouch [07:38] -queuebot:#ubuntu-release- Unapproved: accepted nvidia-prime [source] (bionic-proposed) [0.8.8.1] [07:45] -queuebot:#ubuntu-release- Unapproved: rejected snapd [source] (bionic-proposed) [2.35+18.04] [07:48] -queuebot:#ubuntu-release- Unapproved: accepted nvidia-settings [source] (bionic-proposed) [390.77-0ubuntu0.18.04.1] [08:21] doko, slangasek: i think the test has regressed because pango is now compiled with -std=c99 :( [08:21] c99?! this is so last century. [08:22] i think i rip that out, when i see it. [08:22] heh [08:22] given the default is >>c99, the default should be used. [08:22] k&r forever [08:22] oh [08:22] maybe that's not why it changed then [08:23] the only acceptable places to use c99 is when one compiles tests to check api things work with both default and acient compilers. [08:35] xnox: what is the default now? -std=c11 or something? [08:40] oh ho ho this is std=c18 vs std=gnu18 [08:41] it's also a 1ulp difference on i386 so really i should stop caring [09:59] mwhudson: xnox: the autopkgtest for ruby-gnome has a patch in debian/patches, but it's not applied [09:59] You can see the test log says assert_equal() fails [09:59] but I unpacked the source package [09:59] it uses assert_arrays_nearly_equal [10:00] Ah, I see what's going on [10:00] juliank: um [10:00] you are talking about the patch I just added? [10:00] mwhudson: I just noticed you just uploaded that [10:00] haha [10:00] I was wondering: Why is this patch not applied? [10:01] because sadly building, publication and running autopkgtests are not instantaneous [10:01] It was not listed on the launchpad page when I ran pull-lp-source [10:01] So odd timing [10:30] on the move to release perhaps [10:30] it was just uploaded and moving to proposed [10:35] ahh [11:02] -queuebot:#ubuntu-release- Unapproved: grub2-signed (trusty-proposed/main) [1.34.17 => 1.34.18] (core) [11:05] -queuebot:#ubuntu-release- Unapproved: rejected grub2-signed [source] (trusty-proposed) [1.34.18] [11:05] -queuebot:#ubuntu-release- Unapproved: grub2-signed (xenial-proposed/main) [1.66.18 => 1.66.19] (core) [11:06] -queuebot:#ubuntu-release- Unapproved: grub2-signed (trusty-proposed/main) [1.34.17 => 1.34.18] (core) [11:06] -queuebot:#ubuntu-release- Unapproved: accepted libglvnd [source] (bionic-proposed) [1.0.0-2ubuntu2.2] [11:09] -queuebot:#ubuntu-release- New binary: libglvnd [ppc64el] (bionic-proposed/main) [1.0.0-2ubuntu2.2] (core) [11:09] -queuebot:#ubuntu-release- New binary: libglvnd [s390x] (bionic-proposed/main) [1.0.0-2ubuntu2.2] (core) [11:10] -queuebot:#ubuntu-release- New binary: libglvnd [i386] (bionic-proposed/main) [1.0.0-2ubuntu2.2] (core) [11:12] -queuebot:#ubuntu-release- New binary: libglvnd [amd64] (bionic-proposed/main) [1.0.0-2ubuntu2.2] (core) [11:14] -queuebot:#ubuntu-release- New binary: libglvnd [arm64] (bionic-proposed/main) [1.0.0-2ubuntu2.2] (core) [11:20] -queuebot:#ubuntu-release- New binary: libglvnd [armhf] (bionic-proposed/main) [1.0.0-2ubuntu2.2] (core) [11:24] would someone please 'force-badtest dijitso/2018.1.0-4/armhf' ? dijitso/2017.2.0.0-2 in release only has a simple import test, see https://salsa.debian.org/science-team/fenics/dijitso/commit/594408adf17616034303cb8c1c581e2da82c67c8 [11:42] mwhudson: see https://gitlab.gnome.org/GNOME/pango/issues/287 [11:42] GNOME issue 287 in pango "ruby-gnome2 i386 test failure with pango built with meson" [Bugzilla, Opened] [12:13] -queuebot:#ubuntu-release- Unapproved: rejected qpdf [sync] (bionic-proposed) [8.1.0-1] [12:16] sil2100: "time appropriate greetings", can I bug you with snapcraft 2.43.1 (+18.04) waiting for approval for xenial- and bionic-proposed? [12:30] sergiusens: sure! On it in a moment [12:30] -queuebot:#ubuntu-release- Unapproved: accepted snapd-glib [source] (bionic-proposed) [1.43-0ubuntu0.18.04.1] [12:37] mwhudson: thanks for the hint, see https://gitlab.gnome.org/GNOME/pango/merge_requests/19 [12:37] GNOME issue (Merge request) 19 in pango "build: Don't force C99 for meson build" [Opened] [12:41] thanks sil2100 [12:54] eh, LP timeouts [13:18] Can someone please reject gnome-flashback upload in bionic SRU queue? I want to add one more fix to it. [13:35] sil2100, Hi. Could the debian-installer package pending SRU for trusty get a rebuild on amd64, please? It should pass on trusty-proposed now. [13:36] -queuebot:#ubuntu-release- Unapproved: accepted snapcraft [source] (xenial-proposed) [2.43.1] [13:38] mfo: hey! Ah, so grub2-signed migrated? Let me take a look [13:38] sil2100, the shim-signed and grub2-common problems that it hit before are now resolved, i gave it a try yesterday on a PPA with trusty-proposed enabled. :) [13:42] -queuebot:#ubuntu-release- Unapproved: accepted snapcraft [source] (bionic-proposed) [2.43.1+18.04] [13:49] apw: ping linux autopkg test failure on s390x [13:56] for some reason horizon is failing without a log (it builds ok locally): https://launchpad.net/ubuntu/+source/horizon/3:14.0.0-0ubuntu2/+build/15315380 [13:56] any thoughts? [13:57] doko, ack [13:59] doko, apw - well, when ADT_TRIGGER is gcc, i guess the most interesting part is the rebuild test which is PASS, rather than all of the ubuntu-regression-suite [13:59] xnox, yeah those test are all a mess [13:59] doko, apw - and previously we had the ubuntu-regression-suite ingored in britney hints, because for some reason $ git clone https://git.launchpad.net would clone empty repository [14:00] doko, apw - i've tried to debug that, but it appears to be specific to /large/ scalingstack instances as configured for the autopkgtest tenant. [14:00] xnox, lovely [14:00] sil2100, I see d-i is currently building. Thanks. o/ [14:00] doko, apw - i have failed to trace why git clone is done via https:// instead of git:// protocol [14:01] xnox, iirc because you can (and we do) provide proxies for https: and git: is blocked [14:01] apw, if you can trace and maybe force try to make the autopkgtest use git:// protocol with launchapd? maybe we would get better git-protocolish error messages [14:01] apw, ok, in that case, can you inject more envrionment variables such that the s390x runs give us debug info? [14:01] let me find the things that w grant asked for [14:03] apw, could you export "GIT_CURL_VERBOSE=1 GIT_TRACE=1" when doing git clone? and possibly redirect stderr into stdout, if stderr is not allowed by the test. [14:03] Laney: gcc-7 and gcc-8 now have autopkg tests. why arent't these run? [14:04] xnox, i'll point sforshee at this ^ [14:04] apw, and i wonder if proxy really is needed for git.launchpad.net over https. I kind of wish git.launchpad.net would be in no_proxy [14:04] apw, thank you. This is from https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1789774 [14:04] Ubuntu bug 1789774 in linux (Ubuntu) "linux s390x cosmic autopkgtests fail to clone from git.launchpad.net?!" [Undecided,Incomplete] [14:04] apw, i've tried to trigger this with bileto / silo; but i got trumped, and bileto poops itself when there is a kernel in proposed, because it can't handle abi package names. [14:05] doko: britney's logs might say something [14:09] apw, xnox: will have a look [14:09] doko: if src.startswith('gcc-'): [14:09] if re.match('gcc-\d$', src): [14:09] for test in ['binutils', 'fglrx-installer', 'libreoffice', 'linux']: [14:10] so the normal logic is overridden for gcc, guess we could add their own tests there [14:11] xnox: Ew. https is better than the git protocol [14:11] cjwatson, hm, ok. just need to figure out what is broken with bos02 on s390x with large tenants in the autopkgtest tenant then [14:12] (better in terms of both security and performance - git:// is the old dumb protocol IIRC) [14:12] cjwatson, but the error condition that "stderr: you appear to have cloned an empty repository" is not a nice one, with error code 0 [14:12] i wish there was a flag to clone "--fail-on-empty" or something [14:12] when clearly the repository to be cloned is not empty. [14:13] I guess you could do a test after the clone [14:15] * xnox is out of date with "protocols" "index revisions" "responses changes" in git stuff.... there have been changes, but i'm not at all aware which one is fastest/best/latest. [14:16] but i wondered if cloning over git:// would expose or tell something different, from that broken environment. [14:16] mm, trying those trace environment variables first is probably more useful [14:17] ack [14:17] sforshee, ^ [14:18] apw: actually some of the tests we're running do clone stuff over git:// [14:18] stress-ng for instance [14:18] that was that i noticed too. [14:19] sforshee, we are so consistent ... sigh [14:19] i mean maybe for the https:// ones you sometimes parameterize it to use a private branch; then you do need https:// with authentication.... or ssh.... [14:19] i am supprised git: would not be the 'best' all the time, given it seemed to have feature flags both ways [14:20] sforshee, apw - when i tried to trace the repos where this all lives i did see things (still) on kernel.ubuntu.com and on launchpad, and like things that are declared as git:// in a yaml/metafile but then during s390x run it was autoconverted into https:// urls somehow. [14:20] * xnox somehow thought that git: is the fastest one too for large packs.... [14:21] sforshee, but the s390x failures are both stem from the fact that there are two repos that fail to clone from https: from launchpad. [14:22] sforshee, the current git tree itself (ie. /cosmic) and qa-regression-testing repo [14:27] xnox: I pushed changes to use those exports when cloning those two repos. Let me know when you've got what you need so I can revert those changes. [14:35] doko: pushed a commit to proposed-migration to run those tests, will try to make it request those in a second [14:56] doko: looks like you got your tests now [15:18] sil2100: hey! I saw that apport phase update has just been stopped. The pointed regression isn't a real one: https://errors.ubuntu.com/problem/d89b8d57a5c75209facd4b434677423793c317a9 (cannot allocate memory), and seeing the number of issues (4 in 4 days), it shouldn't be related, but only system with low memory (as this can happen with apport when collecting memory), mind releasing the update phasing [15:18] process? [15:27] didrocks: hey! hm, I might be a bit too busy right now, I'd have to look at it tomorrow - bdmurray maybe you could take a look as part of your SRU shift? ^ [15:27] sounds good :) [15:27] I've made a note. [15:32] xnox: I sort of wonder if https://twistedmatrix.com/trac/ticket/9526 might be related to these git woes, but maybe only because I happened to hear about both problems on the same day [15:34] cjwatson, it's a bit twisted for my brain =) [15:34] though if it is that, it's been broken on git.l.n for ~4 months so it would be weird for me to hear about problem and solution on the same day [15:37] and in any case I just tried cloning a big repo over slow ADSL and it's been going for longer than 75 seconds with no sign of stopping [15:37] so as you were [15:55] there is latency between lp and bos02 maybe [15:56] but i would not expect it to be s390x specific.... [15:57] -queuebot:#ubuntu-release- Unapproved: accepted libvirt [source] (bionic-proposed) [4.0.0-1ubuntu8.5] [16:45] -queuebot:#ubuntu-release- New: accepted python-osc-placement [sync] (cosmic-proposed) [1.3.0-1] [16:50] -queuebot:#ubuntu-release- New binary: python-osc-placement [amd64] (cosmic-proposed/universe) [1.3.0-1] (no packageset) [17:52] -queuebot:#ubuntu-release- New sync: darkmint-gtk-theme (cosmic-proposed/primary) [2.0.0-1] [17:52] -queuebot:#ubuntu-release- New sync: numix-icon-theme-circle (cosmic-proposed/primary) [18-04-04-1] [17:57] would someone please 'force-badtest dijitso/2018.1.0-4/armhf' ? dijitso/2017.2.0.0-2 in release only has a simple import test, see https://salsa.debian.org/science-team/fenics/dijitso/commit/594408adf17616034303cb8c1c581e2da82c67c8 [18:59] Laney: welcome back! did you happen to see my question about the state of autopkgtest@bos02-arm64-5.service and whether further debugging is warranted? [18:59] ginggs: why does it only fail on armhf? filed a bug? [19:01] tumbleweed: openmpi is currently a bit broken on i386 and armhf, there are 3 RC bugs against openmpi [19:02] ginggs: have you also verified that running the new dijitso tests against the old dijito package on armhf fails the same way? [19:02] slangasek: no, i have not [19:03] k, that's what I'd be looking for here as a standard of evidence [19:03] it looks like britney's doing its job in this case [19:03] slangasek: ack [19:03] I don't see much evidence of spurious faliures in the past [19:04] well, ginggs rightly points out that it's a new test; but that doesn't tell us definitively whether it's a new bu [19:04] g [19:04] tumbleweed: that's because it was only an import test [19:07] ah, right there were different autopkgtests before [19:10] yeah [19:10] I mean, in my ideal scenario p-m would not consider this a regression since it's a new test [19:10] but since we're doing it all manually anyway I'm being pickier [19:10] -queuebot:#ubuntu-release- New binary: julia [ppc64el] (cosmic-proposed/universe) [1.0.0-0ubuntu1] (no packageset) [19:29] -queuebot:#ubuntu-release- New binary: julia [arm64] (cosmic-proposed/universe) [1.0.0-0ubuntu1] (no packageset) [19:41] -queuebot:#ubuntu-release- Unapproved: accepted shim [sync] (bionic-proposed) [15+1533136590.3beb971-0ubuntu1] [19:46] slangasek: http://autopkgtest.ubuntu.com/running#pkg-dijitso <- old version of dijitso with new tests enabled, hangs in the same place [19:47] the OpenFabrics (openib) warning is not relevant here [19:50] -queuebot:#ubuntu-release- Unapproved: nginx (bionic-proposed/main) [1.14.0-0ubuntu1 => 1.14.0-0ubuntu1.1] (ubuntu-server) [19:51] cpaelzer: There certainly are a lot of these open-vm-tools crashes about the package in bionic-updates. [20:12] -queuebot:#ubuntu-release- Unapproved: accepted gnome-flashback [source] (bionic-proposed) [3.28.0-1ubuntu1.1] [20:13] jbicha: ah nice [20:13] jbicha: i hacked the ruby-gnome2 testsuite in the meantime [20:14] -queuebot:#ubuntu-release- Unapproved: accepted widelands [source] (bionic-proposed) [1:19+repack-4ubuntu0.18.04.1] [20:20] ginggs: thanks, hinting [20:20] mwhudson: do you want to hack it back? I'm syncing pango1.0 1.42.4-3 from Debian in a few hours [20:30] -queuebot:#ubuntu-release- Unapproved: rejected shim-signed [source] (bionic-proposed) [1.37~18.04.1] [20:34] -queuebot:#ubuntu-release- Unapproved: accepted gnome-games-app [source] (bionic-proposed) [3.28.0-1ubuntu1] [20:36] -queuebot:#ubuntu-release- Unapproved: shim-signed (bionic-proposed/main) [1.34.9.2 => 1.37~18.04.1] (core) [20:41] -queuebot:#ubuntu-release- Unapproved: accepted sshuttle [source] (bionic-proposed) [0.78.3-1ubuntu1] [20:47] -queuebot:#ubuntu-release- Unapproved: accepted sshuttle [source] (xenial-proposed) [0.76-1ubuntu1] [20:49] -queuebot:#ubuntu-release- Unapproved: rejected unattended-upgrades [source] (bionic-proposed) [1.1ubuntu1.18.04.6] [20:59] -queuebot:#ubuntu-release- Unapproved: accepted openvpn [source] (bionic-proposed) [2.4.4-2ubuntu1.1] [21:03] mwhudson: oh, now I'm concerned that my test was faulty since my autopkgtest was against your hacked version :| [21:04] https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-cosmic-jbicha-arch/cosmic/i386/r/ruby-gnome2/20180906_123646_35121@/log.gz [21:05] if you have time, could you check the unhacked version against 1.42.4-3? [21:16] jbicha: where is 1.42.4-3? [21:16] but yes, it's easy enough for me to test that [21:17] jbicha: i did enough testing yesterday to convince myself that if you remove -std=c99 from the command line the test will pass [21:21] oh it's in unstable [21:27] jbicha: so i build pango1.0 1.42.4-3, installed it and ran the old ruby-gnome2 autopkgtests and they passed [21:27] jbicha: so you/i/someone could sync pango1.0 and remove my patch i guess [21:27] *remove my patch from ruby-gnome2 [21:32] mwhudson: yes, I'll sync. Why don't you go ahead and remove the patch now please? [21:33] (so that the automated tests will run against the right ruby-gnome2 for us :) ) [21:47] -queuebot:#ubuntu-release- Unapproved: accepted vlc [source] (bionic-proposed) [3.0.4-1ubuntu0.1] [21:59] bdmurray: thanks for the heads, up I'v updated https://bugs.launchpad.net/ubuntu/+source/nautilus/+bug/1713581 [21:59] Ubuntu bug 1713581 in nautilus (Ubuntu Bionic) "nautilus crashed with SIGSEGV in g_type_check_instance_is_fundamentally_a()" [High,Triaged] [22:03] Trevinho: using the crash in the Error Tracker is a fine way to do the verification too [22:03] bdmurray: ok, thanks that's what I've been using when hard to do a proper verification [22:03] like to define a correct test-case [22:04] like the only way I know how to reproduce this is hack nautilus not to load files quickly :-D [22:08] jbicha: um does the order really matter? [22:12] ideally, we wouldn't let pango-built-with-meson in to cosmic until it passes its autopkgtests :) [22:16] well it's in cosmic release now [22:17] if i upload ruby-gnome2 it will fail its tests until the new pango is synced [22:17] i feel like this is a lot of talk for a 1ULP difference on an architecture we should stop building for :) [22:18] oh I see [22:21] -queuebot:#ubuntu-release- Unapproved: accepted shim-signed [source] (bionic-proposed) [1.37~18.04.1] [22:55] -queuebot:#ubuntu-release- New binary: nova-lxd [amd64] (cosmic-proposed/main) [18.0.0~rc2-0ubuntu2] (ubuntu-server) [23:45] -queuebot:#ubuntu-release- New: accepted python-osc-placement [amd64] (cosmic-proposed) [1.3.0-1]