[06:02] <lordievader> Good morning
[06:07] <MrMojit0> Morning
[10:53] <rbasak> cpaelzer: what exactly _is_ slof?
[10:55] <cpaelzer> rbasak: slim line open firmware
[10:56] <cpaelzer> rbasak: all but the bits that are for the s390x roms are in src:slof which builds bin:qemu-slof
[10:57] <cpaelzer> it is goging more than a year now for Debian to decide if/where to put the s390x bit
[10:57] <cpaelzer> so far we didn't need them, but the features in said SRU re-use pieces of that
[10:57] <rbasak> I see. So roms/SLOF in the SRU is exclusively s390x?
[10:57] <cpaelzer> normally qemu (as upstream delivers) is comprised of qmeu itself and many subprojets for bios
[10:57] <cpaelzer> due to DFSG a lot is stripped and repackages in Debian/Ubuntu
[10:58] <cpaelzer> if you'd pick an upstream qemu tarball, then roms/SLOF would be for much more
[10:58] <cpaelzer> but this much more is part of src:slof package
[10:58] <cpaelzer> as we use it in qemu until Debian has settled on s390x we use it only for s390x rom building
[10:59] <cpaelzer> and while we were waiting Debian started a movement to pull more back into src:qemu
[10:59] <cpaelzer> so over time we might end up building them out of src:qemu, but that is unconfirmed future-brabble
[10:59] <xnox> well, qemu targall ships pre-compiled binary, and sources to build it.
[11:00] <cpaelzer> xnox: yep, and historically both were removed
[11:00] <xnox> this avoids users to need all the cross-compilers, or access to native arch to build slof for e.g. power or e.g. s390x
[11:00] <xnox> and sources are DFSG free, and used to be split into a separate package.
[11:01] <cpaelzer> exactly
[11:01] <xnox> there is no licensing issue; just debian not rebuilding the binary firmware, but we always have.
[11:05] <cpaelzer> rbasak: there is no need but if you want contect is debian bug 874347 832897 684909
[11:05] <cpaelzer> the latter being the most promising having xnox 's changes how he added qemu-system-s390x
[11:05] <cpaelzer> I did a ping last december, but nothing happened yet
[11:06] <cpaelzer> interestingly point #1 of xnox list "It drops stripping roms/SLOF" is implemented, but unrelated to this bug
[11:06] <cpaelzer> since 2.12 it is no more stripped
[11:06] <cpaelzer> qmeu has 17 git submodules btw
[11:07] <cpaelzer> rbasak: anyway I guess xnox and I answered more than you needed - are you good for now?
[11:09] <rbasak> I'm trying to mostly understand from the code base rather than asking questions. I'll probably have more shortly, thanks.
[11:40] <erle-> I have a website with html files in a dir delivered by apache2
[11:41] <erle-> I want to add a reverse proxy for a single path, redrecting to a different HTTP serve rin my local network
[11:41] <erle-> can I just add that to the same <VHost> block?
[11:41] <erle-> I did it, but it only gets 404
[11:42] <erle-> curl from the host works
[11:42] <erle-> it is a different message than a local folder that is not existing
[11:42] <erle-> apache restart etc works, the config file is correct, modules proxy and proxy_http are loaded
[11:44] <plm> Hi all
[11:45] <erle-> tl;dr: / should just be local html root, but /x should be proxied
[14:02] <ahasenack> cyphermox: the ppc64el tests you have been doing with the server image, was that on real hardware or a vm?
[14:03] <ahasenack> I'm asking because of the multipath cases you hit
[14:03] <ahasenack> I did the tests in a simple vm on power8
[14:03] <ahasenack> but no multipath setup
[14:10] <cyphermox> VM
[14:10] <cyphermox> I don't have hardware to steal to do the testing on
[14:11] <cyphermox> but for most things, VMs are sufficient
[14:11] <cyphermox> that said, the bugs were more multipath related than because it's ppc64el
[14:13] <ahasenack> cyphermox: how did you enable multipath on a vm?
[14:17] <cyphermox> it's something you can do in qemu, I have some scripts up, hold on
[14:17] <cpaelzer> ahasenack: cyphermox: I have ran the multipath cases
[14:17] <cpaelzer> did not re-trigger the bug that was seen
[14:21] <cyphermox> ahasenack: lp:~cyphermox/+junk/vm
[14:21] <cyphermox> it works on ppc64el, probably works on amd64 too.
[14:22] <ahasenack> thx
[14:22] <cyphermox> it's a collection of scripts I used to use to spin up VMs for some scenarios that were impractical to do in libvirt
[14:23] <cyphermox> for the most part, now I just use libvirt instead, there multipath is a bit painful but you can still do it
[14:23] <ahasenack> yeah, I wanted to check which devices were involved
[14:23] <cyphermox> any device would do
[14:23] <ahasenack> I triaged a multipath bug many months ago and had no idea how to setup a vm with anything like it
[14:23] <cyphermox> the trick is to set serial on the drives
[14:23] <ahasenack> serial number?
[14:23] <cyphermox> yup
[14:23] <ahasenack> ah, I've been hit by that particularity before
[14:23] <cyphermox> if two drives have the same serial, they are multipath.
[14:23] <ahasenack> no serial number messes up the /dev/disk/by-* links
[14:24] <cyphermox> bah
[14:24] <ahasenack> same serial, nice trick
[14:24] <cyphermox> that seems to work okay, I generally don't set serial at all
[14:59] <ahasenack> cyphermox: https://bugs.launchpad.net/ubuntu/+source/partman-auto/+bug/1798436 looks fixed in today's .2 image
[14:59] <ahasenack> is that expected, or just a happy accident?
[15:23] <cyphermox> I don't know
[15:23] <cyphermox> I noticed it was working too
[15:23] <cyphermox> I went to look at partman-auto
[15:26] <ahasenack> cyphermox: I'll close it then
[15:28] <cyphermox> ta
[17:25] <kinghat> ran update and upgrade on my server and now i get this when running update: http://paste.debian.net/hidden/22c3db9e/
[17:27] <kinghat> this is the entirety of the update: http://paste.debian.net/hidden/8e933ba2/
[17:29] <kinghat> oh. looks like amd repo or something like that?
[17:31] <kinghat> im actually just going to run `do-release-upgrade` before i fix that.
[17:38] <shubjero> kinghat: yeah the key for that repo appears to be invalid/expired
[17:39] <tomreyn> the missing apt signing key is that of repo.radeon.com, not the local apt repo
[17:40] <kinghat> not sure what happened to it. unless it changed or something? everything was running fine when i shut the server off a few months ago.
[17:46] <shubjero> kinghat: maybe try wget -qO - http://repo.radeon.com/rocm/apt/debian/rocm.gpg.key | sudo apt-key add -
[17:47] <kinghat> im still waiting for it to upgrade release to 18.04.1
[17:48] <tomreyn> installing an apt signing key acquired through an insecure transport without manual verification would be a bad idea.
[17:51] <tomreyn> Unfortunately they failed to publish the gpg key fingerprint at https://rocm.github.io/ROCmInstall.html#ubuntu-support---installing-from-a-debian-repository - but at least a sha1sum is there. but then this is only provided via github.io's HTTPS either, no way to verify it through a trusted channel, so it's got to be trust on first use.