[09:18] <lordievader> Good morning
[11:33] <popey_> I just tried to install ubuntu 18.04.2 on a microserver and the installer crashed, where should I report this, and what log file should I include?
[11:38] <OerHeks> apport-cli Subiquity # i guess, popey_  https://help.ubuntu.com/lts/serverguide/reporting-bugs.html
[11:38] <OerHeks> = server ubiquity
[11:39] <popey_> huh, you can ru apport-cli on the server iso?
[11:39] <popey_> ok, will try
[11:43] <popey_> nope, it's a snap so you can't apport-cli it
[11:44] <OerHeks> snap info <snap-name> you will see a contact field.
[11:44] <popey_> I know that much :)
[11:45] <popey_> (It doesnt)
[11:45] <popey_> I'll manually file it in launchpad
[11:45] <OerHeks> oh oke, then snapcraft.io might give a clue?
[11:49] <popey_> https://bugs.launchpad.net/subiquity/+bug/1839468
[11:50] <lotus|i5> maybe tomreyn has an idea ^
[11:51]  * popey_ switches to the traditional ISO
[12:15] <rbasak> popey_: did you flag that on the ISO tracker please? I forget how the connection works, but we need to make sure it is connected so the relevant QA people spot it.
[12:27] <rbasak> rafaeldtinoco: o/
[12:28] <rafaeldtinoco> rbasak: morning!
[12:28] <rbasak> For dbconfig-common, I'm preparing an Ubuntu upload identical to what is in Debian VCS.
[12:28] <rbasak> For cacti, where should I source the upload from?
[12:28] <rafaeldtinoco> rbasak: let me rebase the MR for you
[12:28] <rafaeldtinoco> (ubuntu ready)
[12:28] <rbasak> Thanks!
[12:30] <popey_> rbasak: no, because I'm using 18.04.2 not .3 the new one
[12:31] <rbasak> Oh.
[12:31] <rbasak> Sorry!
[12:31] <popey_> np :)
[12:31] <popey_> I went for the old installer, which worked
[12:31] <popey_> I suspect subiquity didn't like the existing partitions on the disks or something
[12:31] <rbasak> Thank you for the report!
[12:32] <rbasak> I assume Michael will see the bug.
[12:32] <rbasak> And send it up to curtin if needed
[12:33] <rbasak> Or perhaps I should add a curtin task.
[12:34]  * rbasak does so
[12:36] <rbasak> rafaeldtinoco: oh, one thought. cacti, by using the new dbconfig-common option, will need a versioned dependency presumably?
[12:36] <rafaeldtinoco> rbasak: hum.. true
[12:36] <rafaeldtinoco> i´ll set >=
[12:36] <rbasak> +1
[12:36] <rbasak> It will probably help with ordering as tests runs through excuses.
[12:37] <rbasak> Oh
[12:37] <rbasak> rafaeldtinoco: note I'm using 2.0.11ubuntu1 for dbconfig-common
[12:37] <rbasak> So >= 2.0.11ubuntu1 please
[12:37] <rafaeldtinoco> ah ok
[12:37] <rbasak> Or >= 2.0.11ubuntu1~ if you prefer
[12:37] <rbasak> (I don't care; backporting for this seems extremely unlikely)
[12:38] <rafaeldtinoco> rbasak: do we have to set -proposed in autopkgtests
[12:38] <rafaeldtinoco> when this occurs ?
[12:38] <rbasak> What do you mean?
[12:38] <rafaeldtinoco> for the migration
[12:38] <rafaeldtinoco> both are going to be in -proposed
[12:38] <rafaeldtinoco> and depend on each other
[12:38] <rbasak> FWIW >= 2.0.11ubuntu1~ would be more consistent so let's use that.
[12:38] <rbasak> We will probably need to mess with dep8 triggers I expect
[12:38] <rafaeldtinoco> (yep ~ is better)
[12:39] <rbasak> I'm not sure. We'll see :)
[12:39] <rafaeldtinoco> ok
[12:45] <rafaeldtinoco> rbasak: should I prepare a debdiff for u ?
[12:45] <rafaeldtinoco> cacti is not imported yet
[12:45] <rafaeldtinoco> i can push a git in ~rafaeldtinoco
[12:45] <rafaeldtinoco> if its better
[12:45] <rbasak> rafaeldtinoco: yes please. Maybe put a final debdiff into our staging git repo?
[12:46] <rbasak> I don't really mind
[12:46] <rafaeldtinoco> ok
[12:56] <jamespage> cpaelzer: hello
[12:57] <jamespage> cpaelzer: I've been working on a snapshot of the ovs 2.12 branch in preparation for its release in the next few weeks.
[12:57] <jamespage> s390x issue worked through - however I'm having an odd issue with the DPDK build on arm64
[12:57] <jamespage> https://launchpadlibrarian.net/436381942/buildlog_ubuntu-eoan-arm64.openvswitch_2.12.0~git20190807.38a85a041-0ubuntu1~ubuntu19.10.1~ppa201908071540_BUILDING.txt.gz
[12:58] <jamespage> any ideas? I suspect something dpdk ish but I've not dug deep yet
[12:59] <cpaelzer> yeah
[12:59] <cpaelzer> no clear idea
[12:59] <cpaelzer> let me read it for 2 min ...
[13:00] <cpaelzer> all sorts of rdma and mlx things fail on config
[13:00] <cpaelzer> maybe we build no mlx4/5 on arm?
[13:00] <cpaelzer> also suspicious: gcc: error: unrecognized command line option '-mssse3'
[13:00] <cpaelzer> that should be x86 only right
[13:01] <cpaelzer> non arm64 work as expected?
[13:02] <rafaeldtinoco> cpaelzer: mlx4 and 5 is needed for arm64
[13:02] <rafaeldtinoco> i was doing work on top of that @ linaro
[13:02] <rafaeldtinoco> #)
[13:02] <rafaeldtinoco> lustrefs is being ported to arm64 (server part, client is good)
[13:02] <rafaeldtinoco> mellanox was doing some efforts on arm64 also
[13:03] <cpaelzer> we build the mlx[45] PMDs on arm64 (just checked)
[13:05] <rafaeldtinoco> -Integer field ip4.src is not compatible with string constant.
[13:05] <rafaeldtinoco> -String field inport is not compatible with integer constant.
[13:05] <rafaeldtinoco> -Syntax error at `=' expecting relational operator.
[13:05] <cpaelzer> jamespage: it seems as if none of the dpdk config is in place to get the includes and the linkage right
[13:05] <rafaeldtinoco> this reminds me the iproute issue we had with ss recently
[13:05] <cpaelzer> ther is a pkgconfig file provided and OVS was using it last time I checked
[13:05] <cpaelzer> that would be the route I'd start looking at it (is the pkgconf available and still used on arm64)
[13:06] <rafaeldtinoco> AH OK
[13:06] <rafaeldtinoco> cpaelzer: jamespage: python3 on arm64
[13:06] <rafaeldtinoco> jamespage: which machine are you using
[13:06] <rafaeldtinoco> to compile this ?
[13:06] <cpaelzer> rafaeldtinoco: see above that is a builder on LP
[13:06] <rafaeldtinoco> i had problems (illegal instructions on python3)
[13:06] <rafaeldtinoco> inside KVM guests
[13:06] <rafaeldtinoco> and outside (host) it would work
[13:07] <jamespage> that's from a launchpad builder
[13:07] <rafaeldtinoco> this is python3 misbehaving inside kvm
[13:07] <rafaeldtinoco> i´ve faced that multiple times
[13:07] <rafaeldtinoco> i recompiled python3 in the host and installed pkg inside the guest
[13:07] <rafaeldtinoco> i guess this is a toolchain and/or kvm instr issue
[13:08] <rafaeldtinoco> i discovered that using LXC arm{hf,64} on top of x86 using qemu-user-static
[13:08] <rafaeldtinoco> and then i faced the same issue using kvm guests on armv8
[13:08] <rafaeldtinoco> :\
[13:10] <cpaelzer> but I don't see anything that smells like it in jamespage log - do you?
[13:10] <thiras> hello. Fresh install ubuntu. When I try to `apt install redis-server` it hangs at the settings section. The service doesn't start install fails. There is no systemd service file after installation
[13:10] <thiras> any idea what that could be?
[13:10] <rafaeldtinoco> cpaelzer: yep, but do have that in mind
[13:10] <rafaeldtinoco> it stole some time of mine back then
[13:10] <cpaelzer> hehe
[13:10] <rafaeldtinoco> +/<<PKGBUILDDIR>>/_dpdk/tests/testsuite.dir/at-groups/442/test-source: line 22: 31813 Illegal instruction     (core dumped) ovs-ofctl --strict parse-oxm OpenFlow12 < oxm.txt
[13:11] <rafaeldtinoco> this is the first error
[13:11] <rafaeldtinoco> is this test using python somehow ?
[13:11] <cpaelzer> oh
[13:11] <cpaelzer> haven't seen that one in the log
[13:11] <cpaelzer> good eyes (and searches)
[13:11] <cpaelzer> but I think that still continued, I have seen the fails at configure time
[13:11] <cpaelzer> maybe that all passed and I should have looked further ...
[13:11] <rafaeldtinoco> its a bunch of illegal instructions
[13:12] <rafaeldtinoco> and a bunch of them come from python based tests
[13:12] <rafaeldtinoco> thats why i brought that to attention
[13:12] <jamespage> it only appears to happen in the dpdk build, not the vanilla one
[13:12] <rafaeldtinoco> 1344: real - C                                        FAILED (ovsdb-types.at:5)
[13:12] <rafaeldtinoco> cpaelzer: ^
[13:12] <rafaeldtinoco> first real error to fail
[13:12] <rafaeldtinoco> anyway, have fun
[13:13] <rafaeldtinoco> just trying to help #)
[13:13] <jamespage> confirmed - the vanilla build tests all passed fine
[13:14] <cpaelzer> rafaeldtinoco: agreed there are plenty of illegal instruction dumps
[13:14] <rafaeldtinoco> hum
[13:14] <rafaeldtinoco> looks like the issue i faced :\
[13:14] <rafaeldtinoco> i had some illegal instructions inside kvm/qemu
[13:15] <rafaeldtinoco> specially with python3 (i guess they were type related ?)
[13:15] <cpaelzer> and after the test fail it dumps the full config.log which contians all the errors that derailed me
[13:17] <jamespage> cpaelzer: yes its not pretty and a bit distracting!
[13:17] <rafaeldtinoco> unfortunately if its virtualization related
[13:17] <rafaeldtinoco> and this is kvm (and not tcg)
[13:17] <rafaeldtinoco> it would be a microcode issue :o)
[13:17] <rafaeldtinoco> like failing to implement aarch32/64 in virtual mode
[13:17] <rafaeldtinoco> i suspected that back then
[13:18] <rafaeldtinoco> not sure watch launchpad has
[13:18] <cpaelzer> the failing programs seem to be binaries thou - I've seen ovs-vsctl and such
[13:18] <rafaeldtinoco> and if its qemu or kvm accelerated
[13:18] <cpaelzer> unless it is the wrapping test script, that could very well be python
[13:18] <rafaeldtinoco> if its python (hopefully it is)
[13:18] <rafaeldtinoco> i re-generated the same package
[13:18] <rafaeldtinoco> in a diff HW/setup
[13:18] <rafaeldtinoco> and i was able to make it work BUT
[13:18] <rafaeldtinoco> my python would fail the installation post-inst
[13:18] <rafaeldtinoco> super fast
[13:19] <rafaeldtinoco> ^ could also be related to toolchain
[13:19] <jamespage> all under git+ssh://git.launchpad.net/~ubuntu-server-dev/ubuntu/+source/openvswitch
[13:19] <jamespage> master branch
[13:19] <jamespage> (git-buildpackage repo)
[13:19] <rafaeldtinoco> cpaelzer: i can get you access to armv8 here
[13:19] <rafaeldtinoco> if you need
[13:19] <rafaeldtinoco> armhf and arm64 kvm guests
[13:19] <rafaeldtinoco> let me know
[13:20] <cpaelzer> oh I have an idea rafaeldtinoco and jamespage
[13:20] <cpaelzer> I have discussed and battled and lost upstream, but this might be one consequence
[13:20] <cpaelzer> trying a TL;DR
[13:21] <cpaelzer> dpdk really likes processor optimizations
[13:21] <cpaelzer> distributions really like their software to work everywhere
[13:21] <cpaelzer> the DPDK build system makes their -march sometimes bleed into e.g. the pkgconfig they export
[13:21] <rafaeldtinoco> hum
[13:21] <cpaelzer> it is possible that we generate code that is too new for the virt env that we have
[13:21] <rafaeldtinoco> yep
[13:21] <cpaelzer> -march=armv8-a+crc+crypto
[13:22] <rafaeldtinoco> if the instruction is bad virtualized
[13:22] <rafaeldtinoco> or not even implemented in aarch32/64 virt microcode
[13:22] <rafaeldtinoco> (since armv8 does not require aarch32 for kvm, for example)
[13:22] <rafaeldtinoco> its an ¨extension¨ to the microcode
[13:22] <rafaeldtinoco> so, yes, makes sense
[13:22] <cpaelzer> jamespage: if you could override that march lowering it until you hit it working
[13:22] <cpaelzer> then let me know what arch was the hightest that worked
[13:22] <cpaelzer> then I could patch DPDK to use this lower level
[13:22] <rafaeldtinoco> +1
[13:22] <cpaelzer> I have a call with the co-maintainer in a few minutes, I'll pre-discuss that
[13:23] <cpaelzer> for now just assuming that this is the reason
[13:23] <cpaelzer> but I'd need your checking if possible to know what would work (maybe we jsut check an old build)
[13:24] <cpaelzer> hmm
[13:24] <cpaelzer> no the old 2.11 build had -march=armv8-a+crc+crypto as well
[13:24] <cpaelzer> that is the same is it?
[13:25] <cpaelzer> unless newer GCC makes the same march use newer thigs failing in VMs
[13:25] <rafaeldtinoco> yep
[13:25] <rafaeldtinoco> depending on which toolchain you´re using
[13:25] <cpaelzer> jamespage: how about building the same in Disco for a try?
[13:25] <jamespage> I can try that
[13:41] <rafaeldtinoco> rbasak: fighting with a patch and its ¨fuzz¨iness
[13:41] <rafaeldtinoco> will get you the diff soon :)
[13:41] <rafaeldtinoco> quilt refresh won´t fix the fuzz :\
[13:41] <rafaeldtinoco> will re-do it
[14:19] <jamespage> cpaelzer, rafaeldtinoco no cigar
[14:19] <jamespage> https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/3534/+build/17389545
[14:20] <rafaeldtinoco> cpaelzer: ^ if you want armv8 kvm guests let me know =)
[14:21] <rafaeldtinoco> or i can check this later if you´d like
[14:30] <rbasak> rafaeldtinoco: I think your issue is because in commit 9e2dc74 you modified docs-source/General-Installing-Instructions.md directly instead of via a quilt patch
[14:30] <rbasak> The component tarball is a red herring - the same issue would have happened without a component tarball being used I think.
[14:30] <rbasak> You can use "dpkg-source --commit" to have it create the quilt patch for you
[14:31] <rbasak> And then adjust the quilt patch, commit that, and drop your commit that changed the file directly
[14:31] <rafaeldtinoco> rbasak: quilt generates fuzz
[14:31] <rafaeldtinoco> even with dpkg-source --commit
[14:31] <rafaeldtinoco> it does not accept.. this merge was the last attempt
[14:32] <rbasak> It didn't for me
[14:32] <rafaeldtinoco> try debuild -S after quilt
[14:32] <rafaeldtinoco> no issue ?
[14:32] <rbasak> I use dpkg-buildpackage -us -uc -S -nc -d -I -sd -I
[14:32] <rafaeldtinoco> :O
[14:32] <rbasak> To avoid the lintian run and the need to install build dependencies
[14:32] <rafaeldtinoco> oh
[14:32] <rafaeldtinoco> alright then =)
[14:32] <rafaeldtinoco> let me re-push using quilt
[14:33] <rbasak> But debuild just calls dpkg-buildpackage in the end
[14:33] <rafaeldtinoco> yep
[14:33] <rbasak> So I don't think it should be any different
[14:33] <rafaeldtinoco> perfect! tks for checking it!
[15:15] <rafaeldtinoco> rbasak: https://code.launchpad.net/~rafaeldtinoco/+git/cacti is updated
[15:25] <rbasak> rafaeldtinoco: looks good from a quick glance - not reviewed in detail yet.
[15:26] <rbasak> rafaeldtinoco: but (Closes #XXXX) in debian/changelog needs to be (Closes: #XXX) to be picked up in the changes file, or was that intentional?
[15:43] <rafaeldtinoco> rbasak: ~ Depends: dbconfig-common (>= 2.0.12~),
[15:43] <rafaeldtinoco> im setting it for debian at least
[15:43] <rafaeldtinoco> so next merge its there for us
[15:45] <DammitJim> what does extended security maintenance mean?
 I just read that Ubuntu 18.04LTS will be supported for like 10 years, but only with regards to extended security maintenance
[15:46] <rafaeldtinoco> DammitJim: packages will be only updated in regards to CVEs
[15:46] <rafaeldtinoco> and not bug fixes directly
[15:46] <DammitJim> ah ok, so only security patchess
[15:46] <DammitJim> driven by CVEs
[15:47] <DammitJim> forget about bug fixes
[15:48] <rafaeldtinoco> yep, I think SRUs are not considered, so -security gets the updates
[15:54] <DammitJim> do I have to have a special support license to be supported?
[15:56] <rbasak> rafaeldtinoco: +1
[15:56] <rbasak> DammitJim: yes - ESM is a Canonical product
[17:12] <sam_newbie> Hi guys, have a question regarding install ubuntu from pxe server. host/client is on same machine, same network, i'm trying to create multiple os choice pxe server, so far other CentOS working fine from client. ubuntu client getting ip from dhcp server, the installation screen comes up but with error... https://pasteboard.co/IrLJnUD.png
[17:13] <sam_newbie> selinux*firewall disabled on pxe server
[17:17] <sam_newbie> this is my preseed https://paste.ubuntu.com/p/k9wjFGKWVW/
[19:00] <rbasak> ahasenack, rafaeldtinoco: looks like cacti and dbconfig-common are good (on their own) in proposed
[19:00] <rbasak> Pending dbconfig-common armhf but I'm assuming that'll be fine.
[19:00] <rafaeldtinoco> yep, i was checking that now
[19:00] <ahasenack> shipit!
[19:00] <rafaeldtinoco> its impressive the amount of tests
[19:00] <rbasak> So I have triggered what I think are the correct retests for mysql-8.0
[19:00] <rbasak> mysql-8.0 with the new dbconfig-common that we uploaded for all archs
[19:00] <rbasak> And mysql-8.0 with the new dbconfig-common with the new cacti that we uploaded for all archs
[19:01] <rafaeldtinoco> alright
[19:01] <rafaeldtinoco> so failures would be *new* if they happen
[19:01] <rafaeldtinoco> hopefully there wont be any
[19:01] <rbasak> Hopefully they'll all go green then when done
[19:01] <rafaeldtinoco> cool, before eod i´ll check one more time
[19:01] <rafaeldtinoco> just to make sure there is nothing we could save time
[19:01] <rbasak> Nothing will migrate yet though - we need to do the mass rebuild uploads and the FTBFS fixes we have prepared
[19:01] <rbasak> And I know we have some remaining.
[19:02] <rafaeldtinoco> k
[19:02] <rbasak> Hopefully we'll be able to start churning them out tomorrow.
[19:02] <rafaeldtinoco> sounds good