[00:49] <waltman> /dev/random also blocks, which makes it a really bad choice for benchmarking.
[09:46] <teddy-dbear> Morning peoples, critters and everything else
[13:35] <ChinnoDog> Here is my new crude CPU benchmark: dd if=/dev/urandom bs=1M count=1024 | sha256sum
[13:36] <ChinnoDog> It has the benefit of being able to use the dd output stats for measurement. I get 82.6MB/s
[13:44] <waltman> I'm still confused about what it is you think you're measuring. That pipeline uses 3 cpus.
[13:45] <waltman> dd + sha256sum + one to run the RNG code
[13:54] <ChinnoDog> One to run the rng code? I assumed dd usage would be insignificant since it is only copying bits in memory.
[13:54] <ChinnoDog> I guess generating random numbers could be expensive. hmm
[13:58] <ChinnoDog> I measured it. It is expensive.
[14:00] <ChinnoDog> I would need to make it run single threaded to get the number I wanted. However, both systems I am comparing have 2+ CPUs so I think it is ok for now.
[14:07] <waltman> Surely there are existing benchmarks to measure whatever it is you're interested in.
[14:07] <ChinnoDog> I couldn't find any convenient CPU benchmark tools in the default RHEL repositories which is all I have to work with.
[14:08] <waltman> Once you write a pipeline you're using multiple CPUs.
[14:09] <ChinnoDog> There must be a way to constrain all child processes from my command to a single CPU.
[14:10] <ChinnoDog> I could wrap it in a "sh -c" if I had to.
[14:11] <waltman> I really doubt it.
[14:37] <ChinnoDog> That sounds like a challenge.
[14:38] <waltman> It's kind of the point to take advantage of multiple CPUs for this.
[14:39] <waltman> If you want to be sure things are constrained to a single CPU, you're far better writing an actual program than trying to rely on shell tricks, especially since you don't seem to understand them well.
[15:51] <ChinnoDog> I understand them and I knew that there would be some parallelization, I just thought that they would be insignificant relative to the sha2 algorithm
[15:52] <ChinnoDog> I mean sha256. The RNG does take about 1/4 of the time of the sha256 calculation time though so I would expect if done right the command will take 25% longer when single threaded.
[15:53] <waltman> You fundamentally can't test just single-threaded CPU performance in a pipeline. Find a program.
[15:54] <waltman> Pipelines run on multiple CPUs. If you're accessing /dev/urandom, that's causing the kernel to run the random number generator and it's going to affect your results.
[15:55] <waltman> Also as you've discovered it's easy to guess wrong about what's going to take the time.
[15:56] <waltman> https://linuxconfig.org/how-to-benchmark-your-linux-system
[16:10] <ChinnoDog> I made it run on one core. taskset -a -c 0 sh -c "dd if=/dev/urandom bs=1M count=1024 | sha256sum"
[16:10] <ChinnoDog> Although I'm not letting the scheduler select the core I think the number it produces is accurate since the scheduler will just send the other processes to other cores.
[16:11] <ChinnoDog> Incidentally, it actually runs /faster/ when it is confined to one core.
[16:13] <ChinnoDog> I verified by running it with a large count for DD and verifying with top that the CPU time for dd + sha256sum <= 100%
[16:53] <waltman> What exactly is it you're trying to do?
[16:54] <waltman> Even if you confine that to a single CPU, you've still got process switching involved.
[17:24] <ChinnoDog>  That is ok! My intent was to come up with a way to compare CPU performance on different systems. That is all. I don't need an exact measure since I only need to know if there was something wrong with one of the systems.
[20:36] <ChinnoDog> I used the earlier multi-threaded version to confirm that the performance of the server in question was similar to my laptop so it did not have a CPU issue. It is suffering from the usual cause of slowness.  I ran a command that was restricted to one CPU and received a measurement of how fast it ran. Is that not what a benchmark is?
[20:41] <ChinnoDog> It took nothing into account except the raw performance of a couple common CPU intensive algorithms so it isn't great for comparing diverse hardware but that wasn't part of the design criteria.
[20:45] <waltman> You've got too many variables. You've got several algorithms running different processes so you've also got task switching to consider. Not to mention you're reinventing the wheel.
[20:45] <waltman> Any, I've given up on trying to convince you. Have fun.


[00:48]  * RAOF grumbles at yet another autopkgtest that now fails on s390x because machine-isolation has been enabled.
[00:48] <xnox> muahahahahhaha
[00:48] <xnox> RAOF, stop denying the truth! you envy big iron =)
[00:49] <RAOF> xnox: Look, Canonical is absolutely welcome to buy me a Talos II workstation and I will care all the things about power8.
[00:50] <RAOF> xnox: But you're not going to get me excited about big iron :P
[00:51] <RAOF> (Or perhaps I'd be caring about Power9, which maybe shows you how much I currently follow that :gri
[00:51] <RAOF> 😸
[01:12] <infinity> RAOF: IBM keeps promising me x86-competitive build-your-own POWER options.  When that actually happens, my next home server will be P9, I imagine.
[01:12] <infinity> Well, that also depends on it not requiring the rotor from an Apache helicopter to keep it cool.
[01:13] <RAOF> Heh.
[01:13] <RAOF> Well, the Talos II has been in “Pre-orders accepted!” state for… maybe a year now?
[01:13] <infinity> I have faith.
[01:13] <infinity> Ish.
[01:13] <RAOF> “When that actually happens” is an excellent qualifier :)
[01:14] <infinity> The original plan was to sell bad yield CPUs with disabled cores at cut rate prices.
[01:14] <infinity> But two things happened: their yields improved, and demand for P8 was significantly higher than they expected.
[01:14] <infinity> So, good news for IBM, bad news for enthusiasts.
[01:17] <RAOF> Eh. I'll just end up with 16+ cores of Ryzen in my next system.
[01:17] <RAOF> That'll do.
[01:17] <infinity> RAOF: Oh yes, I'm quite happy with all things Ryzen.
[01:18] <infinity> RAOF: But I still want POWER just cause.
[01:18] <infinity> RAOF: I may be old, but there's still a giddy hobbyist nerd hiding in here somewhere.
[01:18] <RAOF> Heh.
[05:09] -queuebot:#ubuntu-release- New source: ukui-window-switch (bionic-proposed/primary) [1.1.1-0ubuntu1]
[05:38] -queuebot:#ubuntu-release- New binary: cross-toolchain-base-ports [amd64] (bionic-proposed/universe) [19ubuntu2] (ubuntu-desktop)
[06:35] -queuebot:#ubuntu-release- Unapproved: plymouth (artful-proposed/main) [0.9.2-3ubuntu17 => 0.9.2-3ubuntu18] (core)
[06:41] <tsimonq2> FTR: bug 1757320.
[06:41] <ubot5`> bug 1757320 in youker-assistant (Ubuntu) "Remove Qt 4 from the archive" [Medium,Confirmed] https://launchpad.net/bugs/1757320
[06:42] <tsimonq2> I'll allow time for the dust to settle (people who are subscribed to the packages to react to it, confirm/deny it) but I plan on sending an email to ubuntu-release this week.
[06:53] -queuebot:#ubuntu-release- New sync: golang-github-coreos-bbolt (bionic-proposed/primary) [1.3.1-coreos.5-1]
[07:35] -queuebot:#ubuntu-release- New: accepted cross-toolchain-base-ports [amd64] (bionic-proposed) [19ubuntu2]
[07:35] -queuebot:#ubuntu-release- New: accepted deepin-terminal [sync] (bionic-proposed) [2.9.2-1]
[07:35] -queuebot:#ubuntu-release- New: accepted mongodb [amd64] (bionic-proposed) [1:3.4.7-1ubuntu3]
[07:35] -queuebot:#ubuntu-release- New: accepted mongodb [s390x] (bionic-proposed) [1:3.4.7-1ubuntu3]
[07:35] -queuebot:#ubuntu-release- New: accepted deepin-screenshot [sync] (bionic-proposed) [4.0.11-1]
[07:35] -queuebot:#ubuntu-release- New: accepted mongodb [arm64] (bionic-proposed) [1:3.4.7-1ubuntu3]
[07:35] -queuebot:#ubuntu-release- New: accepted golang-github-coreos-bbolt [sync] (bionic-proposed) [1.3.1-coreos.5-1]
[07:35] -queuebot:#ubuntu-release- New: accepted ubuntukylin-wallpapers [amd64] (bionic-proposed) [18.04.0]
[07:37] -queuebot:#ubuntu-release- New binary: deepin-screenshot [s390x] (bionic-proposed/none) [4.0.11-1] (no packageset)
[07:37] -queuebot:#ubuntu-release- New binary: golang-github-coreos-bbolt [amd64] (bionic-proposed/none) [1.3.1-coreos.5-1] (no packageset)
[07:39] -queuebot:#ubuntu-release- New binary: deepin-screenshot [amd64] (bionic-proposed/none) [4.0.11-1] (no packageset)
[07:39] -queuebot:#ubuntu-release- New binary: deepin-screenshot [i386] (bionic-proposed/none) [4.0.11-1] (no packageset)
[07:40] -queuebot:#ubuntu-release- New binary: deepin-screenshot [arm64] (bionic-proposed/none) [4.0.11-1] (no packageset)
[07:41] -queuebot:#ubuntu-release- New binary: deepin-screenshot [armhf] (bionic-proposed/none) [4.0.11-1] (no packageset)
[07:42] -queuebot:#ubuntu-release- New binary: deepin-terminal [ppc64el] (bionic-proposed/none) [2.9.2-1] (no packageset)
[07:43] -queuebot:#ubuntu-release- New binary: deepin-terminal [amd64] (bionic-proposed/none) [2.9.2-1] (no packageset)
[07:43] -queuebot:#ubuntu-release- New binary: deepin-terminal [s390x] (bionic-proposed/none) [2.9.2-1] (no packageset)
[07:46] -queuebot:#ubuntu-release- New binary: deepin-terminal [i386] (bionic-proposed/none) [2.9.2-1] (no packageset)
[07:54] -queuebot:#ubuntu-release- New binary: deepin-terminal [arm64] (bionic-proposed/none) [2.9.2-1] (no packageset)
[07:55] -queuebot:#ubuntu-release- New binary: deepin-terminal [armhf] (bionic-proposed/none) [2.9.2-1] (no packageset)
[08:26] -queuebot:#ubuntu-release- New: accepted deepin-screenshot [amd64] (bionic-proposed) [4.0.11-1]
[08:26] -queuebot:#ubuntu-release- New: accepted deepin-screenshot [armhf] (bionic-proposed) [4.0.11-1]
[08:26] -queuebot:#ubuntu-release- New: accepted deepin-screenshot [s390x] (bionic-proposed) [4.0.11-1]
[08:26] -queuebot:#ubuntu-release- New: accepted deepin-terminal [arm64] (bionic-proposed) [2.9.2-1]
[08:26] -queuebot:#ubuntu-release- New: accepted deepin-terminal [i386] (bionic-proposed) [2.9.2-1]
[08:26] -queuebot:#ubuntu-release- New: accepted deepin-terminal [s390x] (bionic-proposed) [2.9.2-1]
[08:26] -queuebot:#ubuntu-release- New: accepted deepin-screenshot [arm64] (bionic-proposed) [4.0.11-1]
[08:26] -queuebot:#ubuntu-release- New: accepted deepin-terminal [amd64] (bionic-proposed) [2.9.2-1]
[08:26] -queuebot:#ubuntu-release- New: accepted deepin-terminal [ppc64el] (bionic-proposed) [2.9.2-1]
[08:26] -queuebot:#ubuntu-release- New: accepted deepin-screenshot [i386] (bionic-proposed) [4.0.11-1]
[08:26] -queuebot:#ubuntu-release- New: accepted golang-github-coreos-bbolt [amd64] (bionic-proposed) [1.3.1-coreos.5-1]
[08:26] -queuebot:#ubuntu-release- New: accepted deepin-terminal [armhf] (bionic-proposed) [2.9.2-1]
[08:38] <LocutusOfBorg> hello guys, appport regressed in release (probably this is an ifra regression, not a release one?)... can autopkgtests be ignored?
[08:40] <LocutusOfBorg> apport-valgrind creates a user specified sandbox and cache ... WARNING: /lib/x86_64-linux-gnu/libc.so.6 is needed, but cannot be mapped to a package
[08:40] <LocutusOfBorg> ERROR: Cannot find package which ships ExecutablePath /bin/true
[08:40] <LocutusOfBorg> this is a strange error TBH
[08:47] <mwhudson> LocutusOfBorg: i remember unhelpfully slangasek saying something about that but no other details
[08:48] <mwhudson> oh wait no there's not been a new glibc recently :)
[09:06] <LocutusOfBorg> does anybody know where I can push changes I did to src:casper package? I fail to see how https://code.launchpad.net/~ubuntu-core-dev/casper/trunk can point to the right code
[09:14] <acheronuk> LocutusOfBorg: I asked in here the other day where the current VCS was, as was told the VCS 'was the archive'
[09:16] <LocutusOfBorg> nice!
[11:10] -queuebot:#ubuntu-release- Unapproved: dovecot (artful-proposed/main) [1:2.2.27-3ubuntu1.3 => 1:2.2.27-3ubuntu1.4] (ubuntu-server)
[11:25] <sil2100> rbasak: hey! Would you mind if I take a look at the systemd SRU in xenial and artful - releasing it if it's all good?
[11:25] <sil2100> rbasak: didn't want to get in the way
[11:45] <rbasak> sil2100: sure, thanks
[12:39] <jbicha> please remove sambamba from bionic-proposed. 0.6.7-1 fails to build on i386 and we can just rebuild 0.6.6-1 instead to finish the ldc transition
[12:40] <jbicha> LocutusOfBorg: unless you were working on fixing 0.6.7?
[13:21] -queuebot:#ubuntu-release- Unapproved: accepted avahi [source] (trusty-proposed) [0.6.31-4ubuntu1.2]
[13:22] -queuebot:#ubuntu-release- Unapproved: accepted avahi [source] (xenial-proposed) [0.6.32~rc+dfsg-1ubuntu2.1]
[13:25] -queuebot:#ubuntu-release- Unapproved: accepted avahi [source] (artful-proposed) [0.6.32-1ubuntu1.1]
[13:27] <LocutusOfBorg> jbicha, https://github.com/biod/sambamba/issues/344
[13:27] <LocutusOfBorg> BTW, I would prefer to remove it on i386, or demote to proposed for some hours
[13:27] <jbicha> demote what to proposed?
[13:27] <LocutusOfBorg> I already disabled the assert in my ppa and the build went successfully, but since upstream is working on it, better wait
[13:27] <LocutusOfBorg> sambamba
[13:28] <LocutusOfBorg> btw tilix is sad because of apport regression in release
[13:29] <jbicha> we could just wait a few days on sambamba/ldc transition then since upstream might have a fix soon
[13:34] <LocutusOfBorg> but since the version is regressed in release (only in i386), I could even disable the assert and upload
[13:34] <LocutusOfBorg> and then sync when the new version 0.6.8 is out
[13:36] <LocutusOfBorg> uploaded, i386 makes little sense nowadays
[13:36] <LocutusOfBorg> and the fix will come in a matter of hours (BTW this is segfaulting since years on i386 and nobody complained lol)
[13:50] -queuebot:#ubuntu-release- Unapproved: rejected pulseaudio [source] (xenial-proposed) [1:8.0-0ubuntu3.9]
[13:54] -queuebot:#ubuntu-release- Unapproved: rejected libnative-platform-java [source] (artful-proposed) [0.11-5ubuntu1]
[14:02] -queuebot:#ubuntu-release- Unapproved: accepted akregator [source] (artful-proposed) [4:17.04.3-0ubuntu1.1]
[14:11] <LocutusOfBorg> apw, please ignore apport autopkgtests? so we can see ldc migrate?
[14:21] <juliank> Laney, slangasek python-apt based autopkgtests currently fail on armhf because it sets APT::Default-Release somewhere in apt.conf[.d]. While we should eventually fix the tests, I don't know how many are affected (only update-manager and ubuntu-release-upgrader I know about). Can we get this changed so it does not set APT::Default-Release, but pins bionic to 990 using a preferences file?
[14:23] <juliank> Then we can get ubuntu-release-upgrader migrate to release pocket again :)
[14:54] <slangasek> LocutusOfBorg: I don't see any way that apport's tests regressing would be an infrastructure change; please check with bdmurray
[14:56] <slangasek> juliank: I don't see any references to Default-Release in our cloud setup.  Does this come from lxd defaults?
[14:56] <juliank> slangasek: I have no idea, but it seems to be set only on armfh
[14:58] <slangasek> juliank: armhf is the only arch where our runners are in containers
[15:00] <juliank> It's certainly not in my autopkgtest-build-lxd container
[15:00] <juliank> but that's all I know, the rest is a mystery to me :)
[15:01] <LocutusOfBorg> slangasek, but ignoring, is it a possibility? we will see some stuff migrate, and this is a "regreesed in release" situation
[15:02] <juliank> Last time tests worked fine on armhf was 2018-03-18 12:57:05 UTC
[15:02] <juliank> that is about two days ago
[15:02] -queuebot:#ubuntu-release- Unapproved: accepted plymouth [source] (artful-proposed) [0.9.2-3ubuntu18]
[15:02] <juliank> um, 3 days ago
[15:03] <juliank> (well, with the old ubuntu-release-upgrader)
[15:13] <slangasek> LocutusOfBorg: true, that is my rule, if it's regressed in release it should not be allowed to block.  Can I ask you to file a bug against the apport package about it, and I'll add the hint?
[15:16] <LocutusOfBorg> sure!
[15:17] <Laney> When we find out why this broke, we should see if we can make proposed-migration not miss the regression next time
[15:17] <slangasek> quite
[15:21] <Laney> slangasek: can you see if you can make the autopkgtest@lxd unit go away on autopkgtest-cloud-worker/3 please? :(
[15:22] <Laney> I'm too incompetent to know how to do that
[15:22] <slangasek> looking
[15:22] <Laney> it's causing an error message to be mailed to me by the maintenance job
[15:22] <slangasek> haha
[15:22] <slangasek> if only other people could receive these mails
[15:22] <Laney> that
[15:22] <LocutusOfBorg> interesting, I'm finding the regression in some glibc stuff
[15:22] <LocutusOfBorg> will update the bug
[15:28] <slangasek> Laney: it only went away when I ran sudo rm<EMAIL_ADDRESS>&& sudo systemctl daemon-reload (and maybe the first part of that command was not relevant)
[15:28] <LocutusOfBorg> ok I'm pretty sure lxc regressed it
[15:28] <slangasek> Laney: but also that leaves<EMAIL_ADDRESS>behind as 'not-found' and I don't know why :P
[15:31] <LocutusOfBorg> slangasek, https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1757470
[15:31] <ubot5`> Ubuntu bug 1757470 in lxc (Ubuntu) "apport autopkgtests broken (valgrind error) LXC regression?" [Undecided,New]
[15:32] <Laney> slangasek: autopkgtest-cloud/tools/cleanup-lxd produces empty output now, so I'm happy, thanks
[15:32] <slangasek> ok
[15:33] <slangasek> Laney: I'm unhappy that I still have a dangling unit, but if the scripts are clean, I won't fret overmuch ;)
[15:34] <LocutusOfBorg> lxc migrated the exact day the test started failing, other differences are gcc-8 minor update and something similar, but lxc seems my best bet
[15:35] <LocutusOfBorg> lets see the stuff migrate <3
[15:40] <slangasek> LocutusOfBorg: lxc in bionic?  that isn't used on the infrastructure
[16:09] <LocutusOfBorg> slangasek, I did a diff on artifacts.tar.gz
[16:12] <LocutusOfBorg> why is it shown there then?
[16:14] <slangasek> LocutusOfBorg: it's part of the base image. But the lxc version *in* the runner image is not part of the "infrastructure" of the runners, and I don't see anything in the apport package that implies it uses lxc
[16:17] <LocutusOfBorg> oh got it
[16:18] <LocutusOfBorg> sooooo, other differences are really not helping
[16:18] <slangasek> sure, but please reassign the bug to the apport package
[16:18] <slangasek> because that's where "ownership" of the issue needs to lie
[16:20] <LocutusOfBorg> sure
[16:20] <LocutusOfBorg> I see some seeds changed, can them be a problem? e.g. ubuntu-minimal and some ubuntu-* packages
[16:20] <LocutusOfBorg> maybe they were indirectly needed
[16:23] <LocutusOfBorg> is looking at both testbed-packages the right thing to do?
[16:24] <LocutusOfBorg> or upstream-system-packages is the best place?
[16:24] <slangasek> could be any of the above
[16:31] <LocutusOfBorg> I'll let somebody else understand the problem, I'm really not much involved in such package
[16:44] <slangasek> I'm working through the ruby re-promotions
[16:45] <slangasek> (so hopefully nobody collides with me and causes package deletions :P)
[16:48] -queuebot:#ubuntu-release- Unapproved: rejected grub2 [source] (xenial-proposed) [2.02~beta2-36ubuntu3.18]
[16:56] <nacc> slangasek: thank you (re: ruby)
[17:11] <slangasek> nacc: promotions done
[17:14] <nacc> slangasek: great; dpb1 --^
[17:38] -queuebot:#ubuntu-release- Unapproved: accepted grub2 [source] (xenial-proposed) [2.02~beta2-36ubuntu3.18]
[18:03] -queuebot:#ubuntu-release- Unapproved: grub2 (xenial-proposed/main) [2.02~beta2-36ubuntu3.18 => 2.02~beta2-36ubuntu3.18] (core)
[18:10] -queuebot:#ubuntu-release- New binary: libgepub [ppc64el] (bionic-proposed/universe) [0.6.0-1] (ubuntugnome)
[18:10] -queuebot:#ubuntu-release- New binary: retro-gtk [i386] (bionic-proposed/universe) [0.14.0-1] (no packageset)
[18:10] -queuebot:#ubuntu-release- New binary: retro-gtk [s390x] (bionic-proposed/universe) [0.14.0-1] (no packageset)
[18:10] -queuebot:#ubuntu-release- New binary: libgepub [s390x] (bionic-proposed/universe) [0.6.0-1] (ubuntugnome)
[18:11] -queuebot:#ubuntu-release- New binary: retro-gtk [ppc64el] (bionic-proposed/universe) [0.14.0-1] (no packageset)
[18:11] -queuebot:#ubuntu-release- New binary: gnome-terminal [ppc64el] (bionic-proposed/main) [3.28.0-1ubuntu1] (desktop-core)
[18:11] -queuebot:#ubuntu-release- New binary: gnome-terminal [s390x] (bionic-proposed/main) [3.28.0-1ubuntu1] (desktop-core)
[18:12] -queuebot:#ubuntu-release- New binary: libgepub [amd64] (bionic-proposed/universe) [0.6.0-1] (ubuntugnome)
[18:12] -queuebot:#ubuntu-release- New binary: retro-gtk [amd64] (bionic-proposed/universe) [0.14.0-1] (no packageset)
[18:14] -queuebot:#ubuntu-release- New binary: gnome-terminal [amd64] (bionic-proposed/main) [3.28.0-1ubuntu1] (desktop-core)
[18:15] -queuebot:#ubuntu-release- New binary: retro-gtk [arm64] (bionic-proposed/universe) [0.14.0-1] (no packageset)
[18:16] -queuebot:#ubuntu-release- New binary: libgepub [arm64] (bionic-proposed/universe) [0.6.0-1] (ubuntugnome)
[18:16] -queuebot:#ubuntu-release- New binary: libgepub [i386] (bionic-proposed/universe) [0.6.0-1] (ubuntugnome)
[18:17] -queuebot:#ubuntu-release- New binary: gnome-terminal [armhf] (bionic-proposed/main) [3.28.0-1ubuntu1] (desktop-core)
[18:18] -queuebot:#ubuntu-release- New binary: gnome-terminal [arm64] (bionic-proposed/main) [3.28.0-1ubuntu1] (desktop-core)
[18:19] -queuebot:#ubuntu-release- New binary: retro-gtk [armhf] (bionic-proposed/universe) [0.14.0-1] (no packageset)
[18:21] -queuebot:#ubuntu-release- New binary: gnome-terminal [i386] (bionic-proposed/main) [3.28.0-1ubuntu1] (desktop-core)
[18:21] -queuebot:#ubuntu-release- New binary: libgepub [armhf] (bionic-proposed/universe) [0.6.0-1] (ubuntugnome)
[18:25] -queuebot:#ubuntu-release- Unapproved: hdparm (artful-proposed/main) [9.51+ds-1 => 9.51+ds-1ubuntu0.1] (core)
[18:26] -queuebot:#ubuntu-release- Unapproved: hdparm (xenial-proposed/main) [9.48+ds-1 => 9.48+ds-1ubuntu0.1] (core)
[18:33] -queuebot:#ubuntu-release- Unapproved: grub2 (xenial-proposed/main) [2.02~beta2-36ubuntu3.18 => 2.02~beta2-36ubuntu3.18] (core)
[18:36] <coreycb> hello, can an archive admin please remove heat-api-cloudwatch binary package as well as the source package python-django-openstack-auth  and its corresponding binaries? note that horizon now provides the python-django-openstack-auth binary.
[19:13] <slangasek> coreycb: heat-api-cloudwatch will get reaped after the new version of heat currently in -proposed migrates, and not before; you appear to have some autopkgtest regressions that you need to sort out http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#heat
[19:14] <coreycb> slangasek: i have a new upload that sorts them out. forgot to drop heat-api-cloudwatch tests on the prior upload.
[19:15] <slangasek> coreycb: python-django-openstack-auth , I would like a bug report filed against the package please (and please ping with the bug # when you have it)
[19:16] <coreycb> slangasek: got it :) https://bugs.launchpad.net/ubuntu/+source/python-django-openstack-auth/+bug/1757141
[19:16] <slangasek> ok :)
[19:16] <coreycb> slangasek: thanks
[19:16] <slangasek> that one is actually tricky because removing python-django-openstack-auth from bionic will immediately make horizon uninstallable
[19:16] <slangasek> I think I'll force horizon first
[19:18] <Trevinho> sil2100: hey, when you've a sec can you please check this SRU https://bileto.ubuntu.com/#/ticket/3190 ?
[19:18] <coreycb> slangasek: we want to keep the horizon binary. i'm probably missing something with how you do it on your end.
[19:20] <ahasenack> hi, sssd has a component mismatch (http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#sssd), the MIR was approved: https://bugs.launchpad.net/ubuntu/+source/http-parser/+bug/1638957
[19:20] <slangasek> coreycb: so, if I act on the removal request for python-django-openstack-auth, python-django-horizon immediately becomes uninstallable in bionic release, and then *hopefully*, becomes installable again with the next proposed-migration run.  Instead, I'm using a hint to force horizon to migrate, which will make only python-openstack-auth uninstallable, which we don't care about; and then I'll
[19:20] <ahasenack> could someone please take a look at that?
[19:20] <slangasek> remove python-django-openstack-auth when the dust settles
[19:20] <slangasek> coreycb: more explanation than you care about, but hopefully satisfies you that I'm not accidentally nuking any horizon binaries
[19:21] <slangasek> ahasenack: doing
[19:21] <slangasek> ahasenack: done
[19:21] <ahasenack> thanks a lot
[19:23] <coreycb> slangasek: alright, thanks for the explanation!
[19:40] <sil2100> Trevinho: hey! I'll check it tomorrow for sure, since that's the usual day when I do SRU work
[20:14] -queuebot:#ubuntu-release- Unapproved: accepted grub2 [amd64] (xenial-proposed) [2.02~beta2-36ubuntu3.18]
[20:14] -queuebot:#ubuntu-release- Unapproved: accepted grub2 [arm64] (xenial-proposed) [2.02~beta2-36ubuntu3.18]
[20:20] -queuebot:#ubuntu-release- New binary: gcc-7-cross-ports [i386] (bionic-proposed/universe) [14ubuntu1] (ubuntu-desktop)
[20:35] -queuebot:#ubuntu-release- New binary: gcc-7-cross-ports [amd64] (bionic-proposed/universe) [14ubuntu1] (ubuntu-desktop)
[21:23] <sergiusens> slangasek: any idea about this "E:The value 'bionic' is invalid for APT::Default-Release as such a release is not available in the sources". Getting it on and autopkgtest for armhf on bionic raised by apt_pkg on<EMAIL_ADDRESS>[21:23] <sergiusens> also, really glad to see that the timeouts seem to be resolved!
[21:30] <sergiusens> the same thing, tested from an upstream PR (base of the debsource) worked fine<EMAIL_ADDRESS>[21:48] <slangasek> sergiusens: this sounds like the same issue juliank raised earlier; but I don't know where that Default-Release setting comes from
[21:54] -queuebot:#ubuntu-release- Unapproved: lshw (artful-proposed/main) [02.18-0.1ubuntu4 => 02.18-0.1ubuntu4.1] (core)
[21:55] -queuebot:#ubuntu-release- Unapproved: lshw (xenial-proposed/main) [02.17-1.1ubuntu3.4 => 02.17-1.1ubuntu3.5] (core)
[22:01] <juliank> slangasek: can you do the magic to enter the autopkgtest after a test failure?
[22:02] <slangasek> juliank: yeah, just have to swap in the context.  Do you have a quick-to-fail one that you want me to try?
[22:04] <juliank> slangasek: update-manager is about ~7min
[22:59] <sergiusens> slangasek: this is not consistent as almost all our tests instrument this logic so more should have failed
[23:14] <slangasek> # cat /etc/apt/apt.conf.d/autopkgtest-default-release
[23:14] <slangasek> APT::Default-Release "bionic";
[23:16] <slangasek> seems to be present since July 2017 in upstream autopkgtest git, so must be a side effect of a config change
[23:36] -queuebot:#ubuntu-release- New: accepted gnome-terminal [amd64] (bionic-proposed) [3.28.0-1ubuntu1]
[23:36] -queuebot:#ubuntu-release- New: accepted gnome-terminal [armhf] (bionic-proposed) [3.28.0-1ubuntu1]
[23:36] -queuebot:#ubuntu-release- New: accepted gnome-terminal [ppc64el] (bionic-proposed) [3.28.0-1ubuntu1]
[23:36] -queuebot:#ubuntu-release- New: accepted gnome-terminal [arm64] (bionic-proposed) [3.28.0-1ubuntu1]
[23:36] -queuebot:#ubuntu-release- New: accepted gnome-terminal [i386] (bionic-proposed) [3.28.0-1ubuntu1]
[23:37] -queuebot:#ubuntu-release- New: accepted gnome-terminal [s390x] (bionic-proposed) [3.28.0-1ubuntu1]
[23:37] -queuebot:#ubuntu-release- New: accepted libgepub [arm64] (bionic-proposed) [0.6.0-1]
[23:37] -queuebot:#ubuntu-release- New: accepted libgepub [i386] (bionic-proposed) [0.6.0-1]
[23:37] -queuebot:#ubuntu-release- New: accepted libgepub [s390x] (bionic-proposed) [0.6.0-1]
[23:37] -queuebot:#ubuntu-release- New: accepted libgepub [amd64] (bionic-proposed) [0.6.0-1]
[23:37] -queuebot:#ubuntu-release- New: accepted libgepub [ppc64el] (bionic-proposed) [0.6.0-1]
[23:37] -queuebot:#ubuntu-release- New: accepted libgepub [armhf] (bionic-proposed) [0.6.0-1]
[23:38] -queuebot:#ubuntu-release- New: accepted retro-gtk [amd64] (bionic-proposed) [0.14.0-1]
[23:38] -queuebot:#ubuntu-release- New: accepted retro-gtk [armhf] (bionic-proposed) [0.14.0-1]
[23:38] -queuebot:#ubuntu-release- New: accepted retro-gtk [ppc64el] (bionic-proposed) [0.14.0-1]
[23:38] -queuebot:#ubuntu-release- New: accepted retro-gtk [arm64] (bionic-proposed) [0.14.0-1]
[23:38] -queuebot:#ubuntu-release- New: accepted retro-gtk [s390x] (bionic-proposed) [0.14.0-1]
[23:38] -queuebot:#ubuntu-release- New: accepted retro-gtk [i386] (bionic-proposed) [0.14.0-1]
[23:43] <slangasek> juliank: ok - this is an old commit but only recently merged upstream, and not merged into the tree on the kvm master.
[23:43] <slangasek> juliank: so it came in as part of the redeploy of the lxd infra.  I'll sort out a revert
[23:46] <slangasek> Laney: ^^ we are currently pointing directly at the autoimported upstream autopkgtest repo, which has now broken us.  I'm going to work through pointing instead at https://code.launchpad.net/~ubuntu-release/autopkgtest/+git/development
[23:50] <sergiusens> slangasek: so do I also wait for your signal to retrigger?
[23:52] <slangasek> sergiusens: or you can tell me what to retrigger once fixed
[23:54] <sergiusens> slangasek: 2.40+18.04 	snapcraft/2.40+18.04
[23:54] <sergiusens> http://autopkgtest.ubuntu.com/packages/s/snapcraft/bionic/armhf