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