[00:01] <mwhudson> agggghhh why does cargo 0.44.1 ftbfs on s390x
[00:19] <wgrant> mwhudson: Ugh, how?
[00:19] <wgrant> That seems like really weird breakage.
[00:20] <mwhudson> wgrant: https://launchpad.net/~mwhudson/+archive/ubuntu/rust-stuff/+build/19366472 i don't really get it
[00:20] <mwhudson> wgrant: it could be a rustc problem maybe
[00:21] <mwhudson> oh wait yes, rustc is segfaulting
[00:21] <wgrant> Does look likely :(
[00:21] <wgrant> Yep
[00:21] <mwhudson> maybe lto?
[00:21] <wgrant> Is this with the new rustc that upgrades from LLVM 9 to 10?
[00:21] <wgrant> Or is it still back on 9?
[00:21] <wgrant> I forget when that switch happened.
[00:22] <mwhudson> (merge-1.43)mwhudson@anduril:~/src/pkg/rustc$ git diff merge-1.42 merge-1.43 -- src/llvm-project/ | wc -l
[00:22] <mwhudson> 24
[00:22] <mwhudson> so i don't think it's that then
[01:56]  * mwhudson gets his canonistack on
[02:12] <mwhudson> blargh hope this instance has enough disk for this
[02:13] <sarnold> the whole point of a supercomputer is disk io, right? :)
[02:22] <mwhudson> no
[02:22] <mwhudson> as in, it does not have enough disk
[02:22] <sarnold> aww :(
[02:27] <mwhudson> haha what https://pastebin.canonical.com/p/pnNx7Rsfyr/
[02:29] <sarnold> zounds
[02:31] <sarnold> 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] <mwhudson> sarnold: it is possible to do that, yes
[02:32] <mwhudson> unhashed_password: or something
[02:33] <sarnold> 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] <sarnold> mwhudson: how many people are going to hate me if I file a bug report on this? :)
[02:33] <mwhudson> sarnold: where did you see that?
[02:34] <sarnold> mwhudson: https://cloudinit.readthedocs.io/en/latest/topics/modules.html#set-passwords
[02:34] <mwhudson> oh i see it
[02:34] <mwhudson> that's not the usual way of setting paswords
[02:34] <mwhudson> i think?
[02:35] <mwhudson> yeah pretty sure not
[02:35] <sarnold> the comments in this suggest it's not https://cloudinit.readthedocs.io/en/latest/topics/examples.html
[02:36] <mwhudson> sarnold: i don't know how much people would hate you if you filed a bug about that :)
[02:49] <sarnold> mwhudson: jfyi, https://bugs.launchpad.net/ubuntu/+source/juju-core/+bug/1881225 -- thanks
[02:51] <mwhudson> 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] <sarnold> mwhudson: yeah it's entirely possible the outcome is "yeah, don't do that, retrieve secrets another way"
[02:59] <mwhudson> hnnngh this build is going to succeed on this builder i think
[02:59] <mwhudson> hm or maybe it's hanging in a different test
[03:00] <mwhudson> wgrant: how much RAM do the builders have again?
[03:00] <mwhudson> wonder if it's reacting badly to oom
[03:00] <wgrant> mwhudson: 4 vCPU, 8GiB
[03:00] <wgrant> At present
[03:00] <mwhudson> hmm same as this bos01 instance i think
[03:00] <mwhudson> ah well this is only 1 cpu
[03:01] <mwhudson> so i guess peak memory usage on a 4 cpu builder would be higher
[03:02] <mwhudson> and it definitely seems to be hung ;(
[03:22] <mwhudson> nope that builds too
[03:23] <mwhudson> oh using rustc 1.42 though
[03:25] <mwhudson> is ports out of date??
[03:27] <mwhudson> ah no, rustc 1.43 is in NEW
[03:31] <Unit193> !info rustc groovy
[03:52] <mwhudson> ugh https://paste.ubuntu.com/p/Ckykd9Mvz7/
[03:52] <mwhudson> 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] <tinwood> 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] <tjaalton> tinwood: right, use the dailies
[06:28] <tinwood> tjaalton, thanks for confirmation!
[09:43] <LocutusOfBorg> jamespage, hello, any reason for this change?
[09:43] <LocutusOfBorg> +openstack-pkg-tools (107ubuntu6) focal; urgency=medium
[09:43] <LocutusOfBorg> +
[09:43] <LocutusOfBorg> +  * build-tools/pkgos-dh_auto_test: Don't use subunit when executing
[09:43] <LocutusOfBorg> +    tests with stestr.
[09:43] <LocutusOfBorg> I'm upstreaming to debian the python->python3 move on debian-openstack channel, but they ask me the reason for this
[11:06] <LocutusOfBorg> rbalint, https://salsa.debian.org/debian/flatbuffers/-/merge_requests/3 can you please rebase, merge and upload?
[11:07] <LocutusOfBorg> flatbuffers is fixed since some time
[11:08] <LocutusOfBorg> and I uploaded the RC bug fixes right now
[11:10]  * LocutusOfBorg does it
[11:58] <LocutusOfBorg> tkamppeter, hello ghostscript merge please? I would like to understand the reason for openimageio ftbfs
[12:04] <LocutusOfBorg> I have a merge ready btw
[12:26] <LocutusOfBorg> uploading sorry for stealing it :)
[12:40] <rbasak> 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] <LocutusOfBorg> (openimageio builds fine now yay!)
[13:28] <rbasak> ahasenack, sergiodj: reimport requests submitted for clamav, python-oauth, python-oauthlib, cifs-utils and apache2.
[13:29] <sergiodj> rbasak: thanks
[13:29] <ahasenack> rbasak: just to remember, these would have their hashes changed then, right?
[13:29] <rbasak> ahasenack: correct
[13:30] <ahasenack> ok
[13:33] <tkamppeter> 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] <tkamppeter> LocutusOfBorg, what is this  openimageio ftbfs?
[13:38] <LocutusOfBorg> tkamppeter, I uploaded the new ghostscript, keeping the gcc workaround for now
[13:39] <tkamppeter> OK, thanks.
[13:39] <LocutusOfBorg> it turned out openimageio was FTBFS because of openimagesomething else I don't recall
[13:39] <LocutusOfBorg> something like yaml-cpp sadness due to it being syncd and making c++ symbols sad
[14:04] <xnox> vorlon:  can we tell which arch:all packages are seeded into i386 and needed, and which ones are not?
[14:18] <rbasak> 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] <rafaeldtinoco> rbasak: regular user might tend easier to execute df -a
[14:18] <rafaeldtinoco> lets say
[14:18] <rafaeldtinoco> and see it all
[14:19] <rafaeldtinoco> (like the user that replied just now about their need on tmpfs)
[14:19] <rafaeldtinoco> that is what came to my mind
[14:20] <rbasak> Oh, I see
[14:20] <rbasak> That makes sense - good point
[14:36] <sforshee> 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] <sforshee> is there something I can do to get the test to run?
[14:38] <Laney> sforshee: Can't be done via request.cgi atm :(
[14:38] <Laney> get apw or someone to run it using run-autopkgtest
[14:39] <sforshee> Laney: ack, thanks!
[14:39] <sforshee> apw: ^
[15:03] <vorlon> xnox: which ones are seeded, you can look at the germinate output?
[15:03] <vorlon> or the packageset
[16:22] <xnox> 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] <xnox> vorlon:  wait, it's there. this thing xmds2
[16:28] <xnox> is it published in i386, and does it hold up removal of openmpi on i386?
[17:07] <vorlon> xnox: what removal are you talking about? I have no context for this
[17:08] <vorlon> xnox: what removal are you talking about? I have no context for this
[17:08] <vorlon> sorry
[21:12] <sarnold> how does ddebs.ubuntu.com get the dbgsym packages? https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1881314
[21:12] <sarnold> https://launchpad.net/ubuntu/+source/openssl
[21:12] <sarnold> http://ddebs.ubuntu.com/pool/main/o/openssl/
[21:13] <sarnold> 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] <cjwatson> sarnold: lp:ddeb-retriever
[21:14] <cjwatson> I'll look
[21:14] <cjwatson> Hm yes, bother
[21:14] <cjwatson> 16342   May 19 /bin/sh -c ~/ddeb-retriever/ddeb-retriever --verbose >>/srv/ddebs.ubuntu.com/logs/ddeb-retriever.log 2>
[21:14] <cjwatson> 16343   May 19  \_ /usr/bin/python3 /srv/ddebs.ubuntu.com//ddeb-retriever/ddeb-retriever --verbose
[21:15] <cjwatson> Killed, it should catch up in a bit
[21:15] <cjwatson> There was a network outage that day
[21:17] <cjwatson> (updated the bug too)
[21:18] <sarnold> cjwatson: excellent, thanks! I haven't seen this one yet :)
[21:20] <cjwatson> 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:23] <sarnold> cjwatson: thanks! :)
[21:59] <xnox> 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] <cjwatson> 2020-05-29 22:12:48,822 INFO    Installing 111/21396: osgearth-dbgsym 2.10.2+dfsg-2build4 in groovy s390x
[22:13] <cjwatson> so it's about that far along (high startup time before it gets into that progress "bar").  We'll see
[22:16] <sarnold> oh wow
[22:16] <sarnold> is it this bit here?
[22:16] <sarnold> # pub.distro_arch_series and das.distroseries is expensive.
[22:17] <cjwatson> no
[22:17] <cjwatson> it just takes quite a long time to iterate over ten days' worth of all publications in Ubuntu
[22:17] <cjwatson> since that's how far backlogged it was
[22:18] <sarnold> ooooof :)
[22:18] <sarnold> I'm surprised no one spotted this earlier, if it was ten days out of date :/
[22:18] <cjwatson> quite
[22:19] <cjwatson> it needs some kind of alerts, but it's an oldish system
[22:19] <sarnold> admittedly ddebs isn't the easiest thing to use..
[22:21] <cjwatson> Anyway, rough extrapolation suggests it should catch up in ~10h