[00:01] agggghhh why does cargo 0.44.1 ftbfs on s390x [00:19] mwhudson: Ugh, how? [00:19] That seems like really weird breakage. [00:20] wgrant: https://launchpad.net/~mwhudson/+archive/ubuntu/rust-stuff/+build/19366472 i don't really get it [00:20] wgrant: it could be a rustc problem maybe [00:21] oh wait yes, rustc is segfaulting [00:21] Does look likely :( [00:21] Yep [00:21] maybe lto? [00:21] Is this with the new rustc that upgrades from LLVM 9 to 10? [00:21] Or is it still back on 9? [00:21] I forget when that switch happened. [00:22] (merge-1.43)mwhudson@anduril:~/src/pkg/rustc$ git diff merge-1.42 merge-1.43 -- src/llvm-project/ | wc -l [00:22] 24 [00:22] so i don't think it's that then [01:56] * mwhudson gets his canonistack on [02:12] blargh hope this instance has enough disk for this [02:13] the whole point of a supercomputer is disk io, right? :) [02:22] no [02:22] as in, it does not have enough disk [02:22] aww :( [02:27] haha what https://pastebin.canonical.com/p/pnNx7Rsfyr/ [02:29] zounds [02:31] mwhudson: is there a way to specify plaintext passwords in user-data config snippets? private keys? the set-passwords module looks a bit like it requires hashed passwords, but I'd hate to misread it.. [02:31] sarnold: it is possible to do that, yes [02:32] unhashed_password: or something [02:33] oh bother "a regex (r'\$(1|2a|2y|5|6)(\$.+){2}') is used to determine if a password value should be treated as a hash." [02:33] mwhudson: how many people are going to hate me if I file a bug report on this? :) [02:33] sarnold: where did you see that? [02:34] mwhudson: https://cloudinit.readthedocs.io/en/latest/topics/modules.html#set-passwords [02:34] oh i see it [02:34] that's not the usual way of setting paswords [02:34] i think? [02:35] yeah pretty sure not [02:35] the comments in this suggest it's not https://cloudinit.readthedocs.io/en/latest/topics/examples.html [02:36] sarnold: i don't know how much people would hate you if you filed a bug about that :) [02:49] mwhudson: jfyi, https://bugs.launchpad.net/ubuntu/+source/juju-core/+bug/1881225 -- thanks [02:49] Launchpad bug 1881225 in juju-core (Ubuntu) "do these error messages leak secrets?" [Undecided,New] [02:51] sarnold: i would be pretty amazed if juju ever supplied user data that contained passwords but it is worth asking the question i guess [02:52] mwhudson: yeah it's entirely possible the outcome is "yeah, don't do that, retrieve secrets another way" [02:59] hnnngh this build is going to succeed on this builder i think [02:59] hm or maybe it's hanging in a different test [03:00] wgrant: how much RAM do the builders have again? [03:00] wonder if it's reacting badly to oom [03:00] mwhudson: 4 vCPU, 8GiB [03:00] At present [03:00] hmm same as this bos01 instance i think [03:00] ah well this is only 1 cpu [03:01] so i guess peak memory usage on a 4 cpu builder would be higher [03:02] and it definitely seems to be hung ;( [03:22] nope that builds too [03:23] oh using rustc 1.42 though [03:25] is ports out of date?? [03:27] ah no, rustc 1.43 is in NEW [03:31] !info rustc groovy [03:31] rustc (source: rustc): Rust systems programming language. In component universe, is extra. Version 1.41.0+dfsg1+llvm-0ubuntu2 (groovy), package size 1693 kB, installed size 5069 kB [03:52] ugh https://paste.ubuntu.com/p/Ckykd9Mvz7/ [03:52] core::intrinsics::copy_nonoverlapping (src=0x1 <- yeah that doesn't look right [04:04] * mwhudson files https://github.com/rust-lang/rust/issues/72723 and runs away [06:12] Hi. Is there going to be an alpha for Goovy? Or has that concept been dropped? (I noticed there wasn't one for foccal either, looking back). [06:27] tinwood: right, use the dailies [06:28] tjaalton, thanks for confirmation! [09:43] jamespage, hello, any reason for this change? [09:43] +openstack-pkg-tools (107ubuntu6) focal; urgency=medium [09:43] + [09:43] + * build-tools/pkgos-dh_auto_test: Don't use subunit when executing [09:43] + tests with stestr. [09:43] I'm upstreaming to debian the python->python3 move on debian-openstack channel, but they ask me the reason for this [11:06] rbalint, https://salsa.debian.org/debian/flatbuffers/-/merge_requests/3 can you please rebase, merge and upload? [11:07] flatbuffers is fixed since some time [11:08] and I uploaded the RC bug fixes right now [11:10] * LocutusOfBorg does it [11:58] tkamppeter, hello ghostscript merge please? I would like to understand the reason for openimageio ftbfs [12:04] I have a merge ready btw [12:26] uploading sorry for stealing it :) [12:40] cpaelzer: the dpdk reimport finished without errors. It didn't adopt upload/17.11.5-0_ubuntu18.04.1 though (one out of four upload tags that were there). I suspect the empty directory issue. Does this seem normal to you? [13:21] (openimageio builds fine now yay!) [13:28] ahasenack, sergiodj: reimport requests submitted for clamav, python-oauth, python-oauthlib, cifs-utils and apache2. [13:29] rbasak: thanks [13:29] rbasak: just to remember, these would have their hashes changed then, right? [13:29] ahasenack: correct [13:30] ok [13:33] LocutusOfBorg, I did not upload any Ghostscript after Focal release yet. the only reason why we do not sync Ghostscript with Debian as we build all packages with -O3 and one architecture (I think ppc64) does not build Ghostscript. It is a gcc bug and no regression-free solution got found yet. [13:33] LocutusOfBorg, what is this openimageio ftbfs? [13:38] tkamppeter, I uploaded the new ghostscript, keeping the gcc workaround for now [13:39] OK, thanks. [13:39] it turned out openimageio was FTBFS because of openimagesomething else I don't recall [13:39] something like yaml-cpp sadness due to it being syncd and making c++ symbols sad [14:04] vorlon: can we tell which arch:all packages are seeded into i386 and needed, and which ones are not? [14:18] rafaeldtinoco: what use case do you have in mind that would need an argument to ignore the environment variable? Couldn't you just invoke the command with the variable unset? [14:18] rbasak: regular user might tend easier to execute df -a [14:18] lets say [14:18] and see it all [14:19] (like the user that replied just now about their need on tmpfs) [14:19] that is what came to my mind [14:20] Oh, I see [14:20] That makes sense - good point [14:36] Laney: I'm trying to run autopkgtests against a kernel package in a ppa but I'm getting this message - "You submitted an invalid request: Package linux-5.7 does not have any test results" [14:36] is there something I can do to get the test to run? [14:38] sforshee: Can't be done via request.cgi atm :( [14:38] get apw or someone to run it using run-autopkgtest [14:39] Laney: ack, thanks! [14:39] apw: ^ [15:03] xnox: which ones are seeded, you can look at the germinate output? [15:03] or the packageset === jdstrand_ is now known as jdstrand [16:22] vorlon: right, it's just i fear that an arch:all package might be holding up openmpi on i386, specifcally this odd arch:all thing i don't see anymore! [16:28] vorlon: wait, it's there. this thing xmds2 [16:28] is it published in i386, and does it hold up removal of openmpi on i386? === ijohnson is now known as ijohnson|lunch [17:07] xnox: what removal are you talking about? I have no context for this [17:08] xnox: what removal are you talking about? I have no context for this [17:08] sorry === ijohnson|lunch is now known as ijohnson [21:12] how does ddebs.ubuntu.com get the dbgsym packages? https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1881314 [21:12] Launchpad bug 1881314 in openssl (Ubuntu) "libssl1.1-dbgsym 1.1.1-1ubuntu2.1~18.04.6 missing from ddebs.ubuntu.com for 18.04" [Undecided,New] [21:12] https://launchpad.net/ubuntu/+source/openssl [21:12] http://ddebs.ubuntu.com/pool/main/o/openssl/ [21:13] it does indeed look like 1.1.1-1ubuntu2.1~18.04.6 debug packages haven't been copied into the ddebs yet [21:14] sarnold: lp:ddeb-retriever [21:14] I'll look [21:14] Hm yes, bother [21:14] 16342 May 19 /bin/sh -c ~/ddeb-retriever/ddeb-retriever --verbose >>/srv/ddebs.ubuntu.com/logs/ddeb-retriever.log 2> [21:14] 16343 May 19 \_ /usr/bin/python3 /srv/ddebs.ubuntu.com//ddeb-retriever/ddeb-retriever --verbose [21:15] Killed, it should catch up in a bit [21:15] There was a network outage that day [21:17] (updated the bug too) [21:18] cjwatson: excellent, thanks! I haven't seen this one yet :) [21:20] I guess my attempt to add timeouts there wasn't totally effective. Fixing https://bugs.launchpad.net/launchpad/+bug/1856774 and making ddeb-retriever use that is almost certainly the way forward - as well as fixing a privacy edge case, it would reduce the number of network requests that need to be made there [21:20] Launchpad bug 1856774 in Launchpad itself "Export source_package_name and source_package_version on BPPH" [High,Triaged] [21:23] cjwatson: thanks! :) [21:59] ddstreet: rbalint: Laney: do you know how to "retrigger systemd-github-autopkgtests? i.e. how do i retrigger https://github.com/systemd/systemd/pull/15905 ? [22:12] 2020-05-29 22:12:48,822 INFO Installing 111/21396: osgearth-dbgsym 2.10.2+dfsg-2build4 in groovy s390x [22:13] so it's about that far along (high startup time before it gets into that progress "bar"). We'll see [22:16] oh wow [22:16] is it this bit here? [22:16] # pub.distro_arch_series and das.distroseries is expensive. [22:17] no [22:17] it just takes quite a long time to iterate over ten days' worth of all publications in Ubuntu [22:17] since that's how far backlogged it was [22:18] ooooof :) [22:18] I'm surprised no one spotted this earlier, if it was ten days out of date :/ [22:18] quite [22:19] it needs some kind of alerts, but it's an oldish system [22:19] admittedly ddebs isn't the easiest thing to use.. [22:21] Anyway, rough extrapolation suggests it should catch up in ~10h