[02:20] <jlamb> still having a problem... with a second NIC on my server
[02:21] <jlamb> I added emp0s8:`n addresses: [192.168.1.1/24] to my 01-netcfg.yaml file
[02:21] <jlamb> and ran sudo netplan apply
[02:22] <jlamb> and sudo ip link set enp0s8 up
[02:22] <jlamb> but, ip addr still doesn't show the ip4 address for emp0s8
[07:06] <lordievader> Good morning
[08:08] <cpaelzer> late hi everybody
[11:45] <ahasenack> cpaelzer: hi, iproute2 sru has been accepted, now we need to click on the reds in the excuses page
[11:45] <ahasenack> :/
[11:46] <ahasenack> let me check that they are the same errors we saw before in bionic
[11:48] <ahasenack> who is chrony's maintainer?
[11:48] <ahasenack> he/she is bound to have seen these frequent dep8 test failures
[12:06] <EraserPencil> Hi! Anyone has a guide to how I could achieve Dropbox style server without using owncloud or nextcloud?
[12:17] <cpaelzer> ahasenack: ping me once you checked which ones seem flaky tests ok?
[12:59] <ahasenack> cpaelzer: systemd dep8 errors in s390: http://autopkgtest.ubuntu.com/packages/s/systemd/artful/s390x
[12:59] <ahasenack> mine is at the top (iproute), but others have failed in the same way
[13:00] <ahasenack> FileNotFoundError: [Errno 2] No such file or directory: '/boot/grub/grub.cfg' is the error
[13:00] <ahasenack> any idea about that?
[13:01] <ahasenack> it seems the systemd-fsckd test was skipped in the one lonely success
[13:01] <ahasenack> "systemd-fsckd        SKIP Test requires machine-level isolation but testbed does not provide that"
[13:01] <cpaelzer> ahasenack: ther eis no grub on s390x
[13:01] <cpaelzer> and never will be
[13:01] <cpaelzer> like 640k will be enough forever
[13:02] <ahasenack> there seem to be two "threads" writing to stdout in the failed test
[13:02] <ahasenack> I see lines like
[13:02] <ahasenack> (Reading database ... 95%
[13:02] <ahasenack> with "Setting up util-linux (2.30.1-0ubuntu4.1) ..." in between
[13:03] <ahasenack> let's see why that test isn't being skipped
[13:03] <cpaelzer> ahasenack: I re-triggered the others, but the two s390x issues need to be resolved or skipped
[13:04] <cpaelzer> well firejail might ahve been a race with another upload with some luck
[13:04] <cpaelzer> or other out of date-ness
[13:04] <ahasenack> firejail failed like that before
[13:04] <ahasenack> but let me get to that in due time
[13:05] <cpaelzer> ahasenack: once the others re-ran you can check then
[13:05] <cpaelzer> ahasenack: if no others are left ask for overrides in #ubuntu-release
[13:07] <cpaelzer> FYI ahasenackthese will eventually go into http://bazaar.launchpad.net/~ubuntu-sru/britney/hints-ubuntu-artful/changes
[13:09] <ahasenack> cpaelzer: the s390 tests were always in a vm, right
[13:10] <ahasenack> xnox: around?
[13:11] <cpaelzer> ahasenack: no
[13:11] <cpaelzer> ahasenack: they were in a container up until recently
[13:11] <cpaelzer> ahasenack: which might be why they now are considered regressiosn
[13:11] <ahasenack> ah, that explains it
[13:11] <ahasenack> I didn't know you could do containers in s390
[13:11] <cpaelzer> ahasenack: that is what I fixed a few of last week
[13:11] <cpaelzer> just as well as everywhere
[13:12] <ahasenack> so now that it's a vm, the machine-isolation constraint works and the test is run
[13:12] <ahasenack> but it uses grub, and that fails
[13:12] <ahasenack> so I need to skip that test in s390
[13:12] <ahasenack> sounds reasonable?
[13:13]  * ahasenack looks for the dep8 spec
[13:18] <ahasenack> "Such specific HW need seems rare and there is no e.g. autopkgtest feature to limit Architectures."
[13:19] <ahasenack> probably need to add the skip to the test itself then, have it return a fake success
[13:28] <ahasenack> cpaelzer: I'm looking at your dpdk dep8 https://bugs.launchpad.net/bugs/1551158 fix
[13:28] <ahasenack> you added debian/tests/check-dpdk-supported-arch.sh and you source that in the tests
[13:28] <ahasenack> but you also added arch-specific bits to the depends line
[13:28] <ahasenack> Depends: dpdk [amd64 i386] <--
[13:28] <rbasak> ahasenack: any ETA on the my MySQL merge review please?
[13:29] <cpaelzer> ahasenack: yes and yes
[13:29] <ahasenack> rbasak: gonna start after I solve these iproute2 migration issues
[13:29] <cpaelzer> ahasenack: the arch qualifier will ensure it doesn't run at all
[13:29] <cpaelzer> as it doesn't qualify
[13:29] <ahasenack> cpaelzer: is the latter necessary? Without the former, the arch qualifier would just lead to a failed test?
[13:29] <rbasak> ahasenack: no problem thanks!
[13:29] <cpaelzer> the checker is mostly if even on an arch there are needs like cpu features
[13:30] <cpaelzer> ahasenack: it is a double cahnce for error
[13:30] <cpaelzer> ahasenack: without arch qualifier it will try to install and might fail
[13:30] <cpaelzer> ahasenack: so you have to mark where you expect THE INSTALL to work
[13:30] <cpaelzer> ahasenack: of the package
[13:31] <ahasenack> cpaelzer: the dpdk package does not exist in these other arches?
[13:31] <cpaelzer> ahasenack: only afterwards the script will run and you can sort out and skip tests
[13:31] <cpaelzer> yes
[13:31] <ahasenack> ok, so you also had an install failure that you are fixing here
[13:31] <cpaelzer> yes
[13:32] <ahasenack> ok,thx
[13:32] <cpaelzer> and check-dpdk-supported-arch.sh then does any in depth checks
[13:32] <cpaelzer> like cpu features
[13:32] <cpaelzer> or experimental arches like for a while ppc64el had the packages but was not meant to work
[13:32] <cpaelzer> well that sounds bad
[13:32] <cpaelzer> it worked
[13:33] <cpaelzer> but was meant to be experimental/tech-preview
[13:34] <cpaelzer> ahasenack: the story even went further, until s390x had KVM execution the isolation-machine blocked it
[13:34] <ahasenack> right
[13:34] <ahasenack> that's my case
[13:34] <ahasenack> it started failing about 3w ago, with several packages
[13:35] <ahasenack> I mean, other packages that triggered the systemd dep8 test suite
[13:35] <cpaelzer> yep
[13:35] <ahasenack> I'm filing a bug and putting up an mp for it
[13:35] <ahasenack> I wonder how the bionic upload passed (of iproute2)
[13:36] <cpaelzer> ahasenack: for the case to complete the story the final change then was https://gerrit.fd.io/r/gitweb?p=deb_dpdk.git;a=commitdiff;h=b179808726394c63b97747b31ca603392c182168
[13:36] <cpaelzer> because since KVM exec it ran into said package-install-issue
[13:36] <cpaelzer> as we didn't have the arch qualifier on that yedt
[13:36] <ahasenack> can't you negate an arch there?
[13:37] <cpaelzer> I don't know
[13:37] <cpaelzer> sry
[13:37] <ahasenack> ok
[13:44] <ahasenack> cpaelzer: hm, "zipl" is an s390 thing, no?
[13:45]  * ahasenack looks around for didrocks
[13:46] <cpaelzer> ahasenack: yes
[13:46] <cpaelzer> ahasenack: zipl is the lilo of s390x
[13:46] <ahasenack> I think this test was meant to work on s390
[13:46] <ahasenack> I might be out of my depth here then
[13:46] <ahasenack>     if platform.processor() == 's390x':
[13:46] <ahasenack>         enable_plymouth_zipl(enable)
[13:46] <ahasenack>     else:
[13:46] <ahasenack>         enable_plymouth_grub(enable)
[13:46] <cpaelzer> yeah, there is some intention here
[13:47]  * ahasenack hops on an s390 to check what platform.processor() returns
[13:47] <ahasenack> it's correct
[13:48] <cpaelzer> it is
[13:48] <ahasenack> ok, I need to actually run this test there then
[13:52] <ahasenack> cpaelzer: am I supposed to be able to run autopkgtest-buildvm-ubuntu-cloud on s1lp5? Or do I need to use nested vm?
[13:52] <ahasenack> ubuntu@s1lp5:~/andreas$ autopkgtest-buildvm-ubuntu-cloud -r artful -o adt-images
[13:52] <ahasenack> ERROR: no permission to write /dev/kvm
[13:59] <cpaelzer> ahasenack: I thik lp4 is the one we share
[14:00] <cpaelzer> ahasenack: but long story short no
[14:00] <cpaelzer> ahasenack: the tests won't work
[14:00] <cpaelzer> there is a lot of console magic in autopkgtest which doesn't apply
[14:01] <cpaelzer> ahasenack: create a VM with uvtool, then run the test in that VM (without the autopkgtest around it)
[14:01] <cpaelzer> only go the last steps to try inside if you really really need it
[14:04] <ahasenack> it must be platform.processor() returning something else over there
[14:04] <cpaelzer> yep
[14:04] <cpaelzer> maybe it fails in a VM?
[14:04] <ahasenack> the test clearly ran     plymouth_enabled = 'splash' in open('/boot/grub/grub.cfg').read(), which is only in enable_plymouth_grub()
[14:04] <ahasenack> yeah, let's start ismple. Bring up the vm and run that platform.processor()
[14:05] <cpaelzer> doing that atm
[14:05] <ahasenack> cpaelzer: hm, there is no uvt-kvm in that s1lp5 host, should I switch to that lp4 one you mentioned? You gave me access to lp5 once upon a time, maybe before lp4 was ready for us?
[14:06] <cpaelzer> lp5 is mostly mine for the more sinister experiments
[14:06] <ahasenack> there used to be uvt-kvm, since I ran it before there
[14:06] <ahasenack> ah, ok
[14:06] <cpaelzer> lp4 is meant to be the somewhat stable shared host
[14:06] <ahasenack> better remove me from lp5 then :)
[14:07] <cpaelzer> it is s390x on a KVM guest as well
[14:08] <cpaelzer> trying to run the full test
[14:08] <ahasenack> "s1lp4 purpose: jenkins node" :)
[14:08] <ahasenack> s1lp3 seems to be the one to use
[14:09] <cpaelzer> I wrote it in the wiki
[14:09] <cpaelzer> yep s1lp3
[14:20] <ahasenack> ah, found it
[14:22] <ahasenack> it's a fix that went into bionic
[14:22] <ahasenack>     New changelog entries:
[14:22] <ahasenack>       * systemd-fsckd: Fix ADT tests to work on s390x too.
[14:22] <ahasenack> somehow I missed that changelog entry
[14:23] <ahasenack> cpaelzer: it's a bug in artful's package, fixed in bionic. We probably don't sru dep8 fixes, or do we?
[14:29] <cpaelzer> ahasenack: we soemtimes do sometimes not
[14:29] <cpaelzer> depends on the case
[14:30] <cpaelzer> but systemd uploads are grouped by xnox anyway
[14:30] <cpaelzer> you know he collects a bunch and groups them for tests
[14:30] <cpaelzer> so he might have a plan or nack already
[14:30] <cpaelzer> I guess you are safe to ask for an override on the current version thou
[14:30] <cpaelzer> ahasenack: ^^
[14:31] <ahasenack> thanks, I'm asking in #ubuntu-release
[14:31] <cpaelzer> if you want you can explain so in a bug, release team members like to reference something with more context
[14:31] <cpaelzer> as it is just a lin in the britney hints
[14:33] <ahasenack> cpaelzer: I have a bug, can you accept the artful nomination? https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1736955
[14:36] <rbasak> ahasenack: I don't think we'd usually SRU a test fix on its own, but bundling one with an SRU is absolutely fine.
[14:37] <ahasenack> sounds reasonable
[14:37] <cpaelzer> approved
[14:37] <cpaelzer> it is correct to have that bug task
[14:37] <cpaelzer> and you can refer to it for the override
[14:38] <ahasenack> cpaelzer: thx
[15:51] <ahasenack> cpaelzer: one more task, zesty is also affected: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1736955
[15:51] <ahasenack> xenial and trusty are fine (no systemd dep8 tests being run in their migrations)
[16:04] <pmatulis> for the no_proxy environment variable, i often see addresses and hostnames. the docs say categorically that hostnames should be used. also, i often see both address and name for the local system: 127.0.0.1, localhost. is this necessary?
[16:07] <ahasenack> pmatulis: surprisingly I've seen many cases where an app would send a request to localhost via the proxy
[16:07] <ahasenack> I don't know why that's not the default
[16:19] <joelio> no_proxy has always seemed partially implemented to me
[17:05] <boxrick> I have the following lines in my preseed postinstall script to upgrade and configure ansible to the latest version.
[17:05] <boxrick> https://gist.github.com/boxrick/ae85da1eedd485930a37a3dfd6e08329
[17:05] <boxrick> But I wish for this to happen in the preseed itself and not the post install
[17:05] <boxrick> 3Any ideas?
[17:06] <pmatulis> ahasenack, thanks
[18:34] <m15k> Does this make any sense? https://gist.github.com/asbachb/9fceeb1d0a00114eec31c6af82ca9805
[18:40] <m15k> Is 2001:470:4242:1042::1/64 the same as 2001:470:4242:1042::1/56 ?
[18:40] <ahasenack> m15k: yes, ifup/down will only work with interfaces defined in /etc/network/interfaces
[18:41] <m15k> ahasenack: Any idea howto remove the interface?
[18:41] <ahasenack> m15k: what ubuntu is this?
[18:41] <m15k> 16.04
[18:42] <ahasenack> m15k: does "lxc network list" list that interface?
[18:43] <m15k> ahasenack: yes. but "lxc network delete lxcbr0" results in "error: not found"
[18:43] <ahasenack> is managed "no" for it?
[18:43] <m15k> yes it's no
[18:45] <ahasenack> that interface was created when you first installed lxc (not lxd: then it would have been lxdbr0). Are you sure you want to remove it? Do you use lxc or lxd?
[18:45] <m15k> Yes I am sure. I think I created it manully via brctl
[18:46] <ahasenack> does /etc/default/lxd or /etc/default/lxc (or a name like that) reference it still?
[18:47] <m15k> ahasenack: I think that's it. lxc-net bridge was enabled and referenced to lxcbr0
[18:48] <ahasenack> you can probably change its details in that /etc/default/ file
[18:48] <m15k> ahasenack: thanks. that was the right hint! :)
[18:49] <ahasenack> cool
[18:53] <m15k> ahasenack: Are you familiar with lxd?
[18:53] <ahasenack> m15k: somewhat
[18:54] <ahasenack> I use it a lot
[18:54] <m15k> I wonder what "Would you like LXD to NAT IPv6 traffic on your bridge?" actually means
[18:55] <boxrick> Hello! I am currently using the following line in preseed on Xenial 16.04 LTS d-i base-installer/kernel/altmeta string hwe-16.04
[18:55] <boxrick> So I have have the more up to date kernel
[18:55] <m15k> I know what NATting is, but I'm a little bit unsure what's the difference in ipv6 context.
[18:55] <boxrick> However this causes all sorts of inconsistencies within my preseed postinstall chroot environment where I need correct libraries
[18:56] <boxrick> Is there any way to install *just* the new kernel rather than do the thing it seems to where it installs the old one then updates it later?
[19:00] <ahasenack> m15k: well, it depends if you have global addresses in your lxds or not
[19:01] <ahasenack> if you don't, and you want to use ipv6 to reach the internet from that container, then you will probably need ipv6 nat, but also a global ipv6 on your host
[19:01] <m15k> ahasenack: So when I've a public ipv6 subnet I should disable NAT?
[19:01] <ahasenack> if your containers get a slice of that and have global addresses, probably yes
[19:01] <ahasenack> I have never natted ipv6, tbh
[19:01] <ahasenack> I just get one /64
[19:02] <m15k> ahasenack: You assign a public ipv6 to your containers?
[19:02] <ahasenack> no
[19:02] <ahasenack> I don't use ipv6 in them
[19:03] <m15k> I currently try that. Because of that I play a little bit around with these bridges.
[21:39] <m15k> When I type "resolvconf -u" there are dns servers in /etc/resolv.conf that are not configured in "/etc/resolvconf/resolv.conf.d" any ideas how they get into the generation?
[21:39] <genii> Probably by dhcp
[21:58] <rbasak> powersj: congrats!
[21:58] <powersj> rbasak: thank you :)
[22:15] <dpb1> oh, it happened?
[22:15] <dpb1> nice
[22:54] <Neo1> who know my server can access server sysadmin?
[22:55] <Neo1> does sysadmin of server can access my server?
[22:55] <Neo1> I mean files on my server
[22:57] <dpb1> root can generally access anything that is not encrypted.
[22:58] <sarnold> and if the data is ever decrypted on the server, root can access that too.