[00:23] <nacc> doko: fyi, i'm going to try and get phpunit migrated, as i think that's going to let me retrigger a bunch of others easier
[04:15] <doko> nacc_: yes, removed from the archive for now
[04:26] <nacc_> doko: ok, thanks
=== maclin1 is now known as maclin
=== LocutusO- is now known as LocutusOfBorg
[08:48] <cpaelzer> wgrant: Laney: do you happen to know if there is some recycling on the builders going on atm?
[08:48] <cpaelzer> I know officially we are still "limited"
[08:48] <cpaelzer> but I see all arm boxes either building or in cleanup (since hours)
[08:49] <cpaelzer> and ppc64el is all disabled except 3 in cleaning
[08:49] <cpaelzer> so am I right to assume that this is some sort of maintenance going on again?
[09:09] <wgrant> cpaelzer: Not maintenance, just breakage. Looking.
[09:14] <cpaelzer> ok
[10:00] <juliank> jibel: I have no luck reproducing https://launchpad.net/bugs/1744722 in my zesty container, maybe I'm missing something. I managed to reproduce this in my test case, but that's it. The autopkgtests are also screwed up and always test the source package, rather than the installed version. Deleted DistUpgrade/ from source tree now and re-running it
[10:00] <ubottu> Launchpad bug 1744722 in ubuntu-release-upgrader (Ubuntu Artful) "Unknown bad source brings up during 'zesty' to 'artful' upgrade and It break the process" [Critical,Fix committed]
[10:03] <juliank> Verified it with some crazy stuff
[10:06] <juliank> rbalint: We gotta fix the u-r-u autopkgtests to run against the system-installed version rather than the source tree. A simple solution would be to just mv everything somewhere, run the tests and mv back (or just delete the files)
[10:06] <juliank> terrible. workarounds. required.
=== PHLin_ is now known as PHLin
[10:45] <jibel> juliank, i'll do the verification. IIRC you have to update the package cache beforehand
[10:46] <juliank> jibel: Well, I did verify it now by running the autopkgtest I wrote against the old and new version. But if you want to verify some more, I won't stop you
[10:58] <seb128> doko, hey, do you know if there is any reason https://bugs.launchpad.net/ubuntu/+source/chrome-gnome-shell/+bug/1695565 isn't getting reviewed (it has been sitting there since june) or if we can do anything to help getting it looked at?
[10:58] <ubottu> Launchpad bug 1695565 in chrome-gnome-shell (Ubuntu) "[MIR] chrome-gnome-shell" [Undecided,Confirmed]
[11:07] <rbalint> juliank: yes :-( (re: workarounds)
=== crogers_ is now known as crogers
=== ret2libc_ is now known as ret2libc__
[12:23] <seb128> doko, oh, also do you know what's the status of the libblockdev MIR, that's blocking the udisks update which other things are depwaiting on
[13:25] <caribou> gcc-7
[13:25] <caribou> oops, sorry
[13:25] <caribou> and hello btw
[13:34]  * crogers thinks of suggesting "curvaceous caribou" for 18.10
[13:37] <Skuggen> cantankerous
[13:38]  * crogers thinks they need to be positive adjectives to be considered.
[13:40] <Skuggen> Ah :)
[13:41] <crogers> Well, doesn't stop people from suggesting "Drowsy Donkey", though.
[13:42] <crogers> Bionic Beaver is going to get an LTS style extended bit of innuendo treatment.
[15:34] <GunnarHj> sil2100: How frequent do you plan to build new (delta) langpacks for bionics until final release?
[15:43] <cpaelzer> since builders had some trouble today
[15:43] <cpaelzer> and I'm puzzled about an armhf only "Bus error (core dumped)"
[15:43] <cpaelzer> in https://launchpadlibrarian.net/355994048/buildlog_ubuntu-bionic-armhf.asyncpg_0.13.0-1ubuntu2_BUILDING.txt.gz
[15:44] <cpaelzer> please tell me that the builders are still sort of broken and this might be a symptom that goes away when rebuilding at a later time
[15:44] <cpaelzer> wgrant: ^^ ?
[16:00] <xnox> cpaelzer, that sounds a lot more like unaligned access, which is enforced better on the arm64 kernel.
[16:00] <xnox> one should not do unaligned memory access.
[16:01] <cpaelzer> thanks xnox
[16:01] <cpaelzer> I should be able to run a armhf lxd on arm64 host right?
[16:02] <xnox> cpaelzer, totally can!
[16:02] <persia> cpaelzer: You'll want to ensure that you crester the container with the correct personality flags, but it should work for most arm64 processors (there exist exceptions, but not in the more common hardware).
[16:02] <xnox> cpaelzer, i do all the time, via the MAAS instance
[16:02] <cpaelzer> xnox: how does MAAS help you with that?
[16:03] <xnox> cpaelzer, deploying a fresh arm64 box for me to (ab)use =)
[16:03] <cpaelzer> ok that I have already
[16:03] <cpaelzer> xnox: persia: any lxd launch command / profiles I could copy ?
[16:05] <xnox> you shouldn't need anything special. there is launchpad container setup stuff you could do, but i don't think that is necessory a simple $ lxc launch ubuntu-daily:bionic should be enough
[16:05] <cpaelzer> I might miss the point but where in that do I "make it armhf" ?
[16:06] <xnox> ah
[16:06] <xnox> lxc launch ubuntu-daily:bionic/armhf
[16:06] <xnox> cpaelzer, ^
[16:06] <xnox> or you can do $ mk-sbuild --arch armhf bionic
[16:06] <xnox> for sbuild experience.
[16:07] <cpaelzer> so essentially the same as i386 on amd64 then
[16:07] <cpaelzer> thanks trying that
[16:09] <persia> Yep.  Precisely the same as i386 on amd64.
[16:14] <cpaelzer> didn't want to work that easy http://paste.ubuntu.com/26530622/
[16:14] <cpaelzer> stgraber: xnox: persia: ^^
[16:15] <cpaelzer> in case this is one of the exceptions persia listed  "Cavium ThunderX CN88XX"
[16:18] <persia> cpaelzer: You did hit the "failed to set personality" issue.  I don't know enough about lxd to help debug much, but my past experience with that error message indicated a need for a change to either util-linux or the kernel, to ensure the desired personality worked.  I don't have a comprehensive list of which specific processors support and don't support the armv7l personality.
[16:25] <cpaelzer> ok - thanks persia
[16:25] <cpaelzer> I think it needs stgraber ^^ if he is not in a plane atm
[17:05] <xnox> cpaelzer, odd
[17:05] <xnox> cpaelzer, mk-sbuild --arch armhf bionic it is, i guess.
[17:14] <stgraber> cpaelzer: what arm64 host is that?
[17:14] <stgraber> cpaelzer: not all arm64 machines support armhf
[17:14] <cpaelzer> Cavium ThunderX CN88XX
[17:14] <cpaelzer> stgraber: where could/should I check?
[17:15] <stgraber> hmm, cavium should be fine I believe
[17:17] <ahasenack> xnox: hi, your btrfs-progs upload to bionic caught my eye
[17:17] <ahasenack> xnox: because I updated libzstd in bionic, and btrfs-progs got a build-dep on libzstd-dev. But libzstd is in universe
[17:18] <ahasenack> should zstd be disabled, or were you planing on filing a mir for it?
[17:18] <persia> xnox: Do I remember correctly that mk-sbuild first tries personality, and falls back to qemu-static if that doesn't work?
[17:19] <stgraber> root@1ss-arm64:~# uname -m
[17:19] <stgraber> aarch64
[17:19] <stgraber> root@1ss-arm64:~# setarch linux32 -- uname -m
[17:19] <stgraber> armv8l
[17:19] <stgraber> ^ arm64 that can supports 32bit
[17:19] <stgraber> root@c2400:~# uname -m
[17:19] <stgraber> aarch64
[17:19] <stgraber> root@c2400:~# setarch linux32 -- uname -m
[17:19] <stgraber> aarch64
[17:19] <stgraber> ^ arm64 that doesn't
[17:20] <cpaelzer> stgraber: setarch: failed to set personality to linux32: Invalid argument
[17:20] <cpaelzer> arm64 that want's to block me :-)
[17:20] <cpaelzer> sbuild fails to exec through binfmt as well
[17:21] <stgraber> cpaelzer: ok, so not a LXD issue, but either a hardware one (no 32bit support) or something odd with the kernel
[17:22] <cpaelzer> yes unfortunately
[17:30] <xnox> ahasenack, i will be filing MIR, yes, pending.
[17:30] <ahasenack> oh, ok
[17:31] <persia> stgraber: Can all arm64 that supoport armv8l also support armv7l?  I never understood if that was just a kernel trap or something in the hardware microarchitecture.
[17:38] <stgraber> persia: I believe that part to be right, if you get armv8l you can run armv7l, at least that's been the case on all hardware I've seen
=== Elimin8r is now known as Elimin8er
[17:44] <persia> stgraber: It has also been my experience.  Thanks for the confirmation.  Someday I hope I'll understand whether it is true or just always seems true :)
[17:56] <xnox> tsimonq2, mitya57 - will you please upload qt with openssl1.1 patches?
[17:59] <tsimonq2> xnox: I have to look again but I thought the patch caused an FTBFSe
[17:59] <tsimonq2> s/Se/S/
[18:00] <xnox> tsimonq2, right, we are shipping both openssl1.0 and openssl1.1, so maybe we should only worry about that ftbfs in CC release.
[18:00] <xnox> tsimonq2, do you have pointers somewhere? maybe I could take a look to fix it up?
[18:03] <tsimonq2> xnox: Sorry, that was a good couple of weeks ago and I'm on mobile atm
[18:04] <tsimonq2> I'll take a look a bit later
[18:04] <xnox> tsimonq2, ack, chat later =)
=== TJ_Remix is now known as TJ-
[21:40] <mwhudson> there are two instructions that have been removed in armv8 vs armv7 (swp and swpb)
[21:41] <mwhudson> i assume they are extremely obscure
[23:49] <sil2100> GunnarHj: hey! So the langpack updates are planned to happen every week, last week they didn't happen because I forgot to re-enable them after creating the base ones
[23:49] <sil2100> GunnarHj: but this week they should build normally