[06:58] <LocutusOfBorg> nice work foka mwhudson !
[06:58] <LocutusOfBorg> wrt x-sys, I think ignoring tests results might be the best thing to do for now
[07:09] <LocutusOfBorg> it has something to do with the new openMountByID test
[07:09] <LocutusOfBorg> +       mi, err := os.Open("/proc/self/mountinfo")
[07:09] <LocutusOfBorg> I don't think its a good idea to try to open such devices inside a chroot...
[07:17] <s1aden> LocutusOfBorg: if that doesn't work, the chroot illusion sucks
[07:25] <LocutusOfBorg> s1aden, it works to be honest
[07:25] <LocutusOfBorg> the test is trying to read some device inside it
[07:33] <LocutusOfBorg> [09:33:16] <BTS> Opened #935935 in src:golang-golang-x-sys by Gianfranco Costamagna (locutusofborg) «golang-golang-x-sys: test failure in chroots». https://bugs.debian.org/935935
[07:33] <LocutusOfBorg> foka, mwhudson ^^
[07:33] <LocutusOfBorg> I did some debugging and opened a bug report...
[07:33] <LocutusOfBorg> (and thanks for fixing smux!
[07:40] <foka> LocutusOfBorg: You're very welcome!  :)  And thanks for looking into golang-golang-x-sys.
[07:40] <LocutusOfBorg> I hope I didn't mess too much with the package, I'm not a golang speaking guy!
[07:41] <LocutusOfBorg> with your help we might get all the golang stack migrate :D
[07:43] <foka> LocutusOfBorg: When you have time, could you please pull in syncthing/1.1.4~ds1-3 too?  That upload by toddy should solve syncthing's autopkgtest with golang-1.12
[07:44] <foka> LocutusOfBorg: I'm glad xtaci fixed smux so quickly!
[07:58] <LocutusOfBorg> done thanks!
[07:59] <LocutusOfBorg> so, last blocking golang issues:
[07:59] <LocutusOfBorg> http://autopkgtest.ubuntu.com/packages/g/golang-google-api/eoan/arm64 <--
[07:59] <LocutusOfBorg> golang-go.crypto autokpkgtest failures
[08:00] <LocutusOfBorg> golang-golang-x-tools autopkgtest failures
[08:00] <LocutusOfBorg> http://autopkgtest.ubuntu.com/packages/g/golang-github-jbenet-go-context/eoan/armhf
[08:00] <doko> jamespage: please see the python2 removal thread on u-d. looks like at least some openstack packages need proper merging from debian, or dropping python2 on its own
[08:00] <jamespage> doko: yeah I just saw that
[08:01] <jamespage> doko: what do the different 'levels' in the generated report mean?
[08:01] <LocutusOfBorg> less priority issues: golang-github-rs-zerolog autopkgtest failures on 32 bit, golang-gopkg-ldap.v3 FTBFS
[08:01] <LocutusOfBorg> golang-golang-x-tools autopkgtest failures
[08:01] <doko> jamespage: nothing ;p just make sure that you remove leaf packages first
[08:02] <jamespage> sahid, coreycb ^^
[08:02] <jamespage> doko - I'm assuming this is an objective for eoan then?
[08:03] <doko> jamespage: no, that should be for 20.04, so that we can remove the python symlink and the python package
[08:03] <doko> we may have to keep python2 and using the python2 shebang
[08:06] <jamespage> doko: can we get nova-lxd rm'ed from eoan please - I raised a bug a while back to cover that
[08:16] <jamespage> sahid, coreycb: do we have that outstanding issue with completely dropping py2 depends for the backports to the UCA? if so we should work to resolve that if possible
[08:29] <jamespage> cpaelzer, I've re-opened https://bugs.launchpad.net/ubuntu/+source/intel-ipsec-mb/+bug/1786201 as the latest 2.12 snapshots of OVS are pulling that in for x86_64
[08:42] <cpaelzer> jamespage: interesting
[08:42] <cpaelzer> jamespage: how can dpdk not pull it in but OVS does
[08:45] <jamespage> cpaelzer: just looking atm
[08:45] <jamespage> cpaelzer: 2.11.1 generates the mismatch
[08:45] <mwhudson> LocutusOfBorg: i guess i'll look at google-api on arm64 tomorrow unless foka beats me to it
[08:46] <jamespage> just seeing of the 2.12 snapshots I'm producing are doing the same thing
[08:46] <cpaelzer> jamespage: https://paste.ubuntu.com/p/cdCf9CqpSX/
[08:47] <cpaelzer> these are the only packages needing it (two PMDs)
[08:47] <cpaelzer> they are considered not for prime-time yet which is why they are only universe
[08:47] <mwhudson> LocutusOfBorg: have you looked at the crypto or tools failures?
[08:48] <cpaelzer> essentially dpdk (is in main) pulls in a list of "better support/mature" PMDs and those are in main
[08:48] <mwhudson> crypto is some ssh thing iirc
[08:48] <cpaelzer> jamespage: I'd not really see why OVS would directly create/depend on a list of PMDs
[08:48] <cpaelzer> need to read build log of OVS in proposed
[08:49] <jamespage> cpaelzer: one sec - this might have been a transient issue
[08:49] <mwhudson> tools is just "FAIL	golang.org/x/tools/go/internal/gcimporter	22.980s" which is nice
[08:49] <jamespage> cpaelzer: I had a build on the 7th august that showed this, and then one on the 8th that did not
[08:49] <jamespage> odd
[08:49] <cpaelzer> oO
[08:49] <cpaelzer> I'm still parsing the buildlog
[08:50] <jamespage> cpaelzer: those where in PPA's
[08:50] <jamespage> but the 2.11.1 in the main archive has the same issue
[08:50] <cpaelzer> whicih don't differ between main/universe
[08:50] <cpaelzer> IIRC there all is main
[08:51] <jamespage> cpaelzer: I mean't 'the ubuntu archive' rather than 'a PPA'
[08:51] <cpaelzer> ok
[08:52] <cpaelzer> jamespage: it pulls in on build libdpdk-dev which depends on all PMDs indirectly, and they are present at build but since they carry no symbols neede dthey don't end up as dependnecies
[08:52] <cpaelzer> at least on 2.11.1 at https://launchpadlibrarian.net/433294520/buildlog_ubuntu-eoan-amd64.openvswitch_2.11.1-0ubuntu1_BUILDING.txt.gz
[08:52] <cpaelzer> can I see your 2.12 where this happens?
[08:52] <jamespage> might be some sort of linking issue
[08:53] <cpaelzer> yeah it could overlink
[08:53] <jamespage> cpaelzer: leave it with me - I'm just testing fresh snapshots which will superceed everything to-date so this might just go away
[08:53] <jamespage> cpaelzer: don't want you to spend cycles if not required :)
[08:53] <cpaelzer> the way builds against dpdk are set up usually make all dpdk libs (a lot) available, but then should only link whats needed (with the ususal ubuntu as-needed)
[08:53] <cpaelzer> ok jamespage, but overlinking could be a thing
[08:54] <cpaelzer> it happened in the past with DPDK
[08:54] <cpaelzer> so let me know
[08:54] <cpaelzer> I'm closing the MIR for now
[08:55] <cpaelzer> thanks for the ping still jamespage, worth to be aware of
[09:02] <cpaelzer> jamespage: with 19.08 thre are some ipsec things http://paste.ubuntu.com/p/GRp2kC4sh4/
[09:02] <cpaelzer> but as you see all experimental (not for consumption) and we don#t have 19.08 in eoan
[09:04] <LocutusOfBorg> mwhudson, I fixed other stuff, but crypto...
[09:04] <LocutusOfBorg>         Attempt to write login records by non-root user (aborting)
[09:05] <LocutusOfBorg> LOL
[09:05] <LocutusOfBorg> looks like the test is trying to ssh and fails because of ENOPERM?
[09:05] <LocutusOfBorg> but there is a new x-sys package so, lets wait a couple of hours and retry once more all golang failed tests
[09:08] <LocutusOfBorg> syncthing has lots of flaky tests... retrying amd64 worked, I'm hitting the i386 retry button hard once again
[09:16] <cpaelzer> bryce: this symfony thing you asked turns out into a nice digital indiana jones trip
[09:26] <LocutusOfBorg> cpaelzer, you know what is funny? there is a new symfony release
[09:42] <cpaelzer> we seem to ahve enough trouble with the old one LocutusOfBorg :-)
[09:42] <cpaelzer> but most of what I found while anylazing the issues are outdated packages that seem fixable or removable
[09:42] <cpaelzer> I'll later send a summary to bryce / vorlon who discussed this yesterday
[09:44] <cpaelzer> LocutusOfBorg: unless you mean the 4.x that is stuck in proposed
[09:44] <cpaelzer> that is the one that started the discussion
[09:45] <LocutusOfBorg> what is missing for symfony in proposed, is that some packages breaks the 4.x version
[09:45] <LocutusOfBorg> so they have to be kicked-out or updated
[09:45] <cpaelzer> yep and that is what I was analyzing
[09:46] <cpaelzer> the details of it
[09:46] <LocutusOfBorg> oh and my symfony merge should be probably uploaded, the "php-7.2.patch" was an hack I did to create missing functions that are available on php-7.3
[09:46] <LocutusOfBorg> I won't upload now, but if stuff migrates...
[10:04] <cpaelzer> LocutusOfBorg: I see we both triggered it the same way, so in addition to that trigger it also is flaky ? http://autopkgtest.ubuntu.com/packages/s/symfony/eoan/amd64
[10:04] <cpaelzer> or did you have some other upload/fix that makes this go well now?
[10:11] <LocutusOfBorg> not the same way?
[10:12] <LocutusOfBorg> cpaelzer, without all-proposed, php72 is picked up
[10:40] <jamespage> cpaelzer: got it again - https://launchpadlibrarian.net/439281290/buildlog_ubuntu-eoan-amd64.openvswitch_2.12.0~git20190828.23acdc07f-0ubuntu1~ubuntu19.10.1~ppa201908281053_BUILDING.txt.gz
[11:08] <cpaelzer> thanks jamespage, reading te log ...
[11:09] <cpaelzer> jamespage: my assumption would be that OVS added support for librte-ipsec
[11:09] <cpaelzer> it is odd that it doesn't show up and only the follow on dependency does
[11:10] <cpaelzer> which then is libipsec-mb0
[11:10] <jamespage> cpaelzer: that was my assumption but I can't find anything in the codebase to indicate that is the case
[11:10] <jamespage> unless there is something implicit in the ipsec support for the dpdk context
[11:11] <cpaelzer> jamespage: overlinking
[11:11] <cpaelzer> look in the log for the usual "package could avoid a useless dependency if"
[11:12] <cpaelzer> it seems like all of DPDKs helper libs creeped in
[11:12] <cpaelzer> that looks much like the libdpdk-dev dependencies
[11:13] <cpaelzer> hmm, IÄ'm on something ...
[11:14] <cpaelzer> jamespage: there is a -Wl,--no-as-needed in the libtool commandline
[11:14] <cpaelzer> all after that seem to be what was overlinked
[11:15] <cpaelzer> hmm yeah
[11:15] <cpaelzer> that is from the pkgconfig of dpdk
[11:20] <cpaelzer> jamespage: https://bugs.launchpad.net/ubuntu/+source/dpdk/+bug/1841759
[11:24] <rbasak> Does anyone else get irritated by indentexpr being set by default in vim packaging nowadays?
[11:24] <rbasak> For me it's almost always wrong and I'm forever unsetting it :-/
[11:44] <cpaelzer> jamespage: I have a test fix building and will submit it upstream if it succeeds
[11:44] <cpaelzer> I already ahve an ack for the approach by the Debian co-maintainer
[11:45] <cpaelzer> rbasak: I guess I'm not new enough
[11:46] <cpaelzer> rbasak: what is it set to by default nowadays?
[11:46]  * cpaelzer is reminded of mouse=v in Debian which Ubuntu avoided to get (was also always wrong)
[11:47] <cpaelzer> rbasak: upstream doc still lists it as default ""
[11:49] <cpaelzer> rbasak: and it isn't set for me (in eoan conainer)
[11:50] <cpaelzer> I get "  indentexpr= " by :set indentexpr?
[11:50] <cpaelzer> other options report their value nicely
[11:50] <cpaelzer> rbasak: could that be a drop in config from any extra packages on top of what my eoan container has?
[11:51] <rbasak> I think it gets set automatically depending on what is being edited
[11:51] <rbasak> I couldn't pin down the exact place in the default init scripts
[11:52] <rbasak> "vim -u NONE" works around by doing nothing, but then I don't get the other goodness
[11:52] <rbasak> Example: if I edit a shell script, it uses an tab-based indent level of 8, which is almost always wrong
[11:52] <cpaelzer> rbasak: what do I need to edit to get the behavior?
[11:52] <rbasak> cpaelzer: try a bash script maybe?
[11:53] <cpaelzer> I have opened a shell script and now get
[11:53] <cpaelzer>   indentexpr=GetShIndent()
[11:53] <rbasak> What happens to me is that it auto-indents to eight, with tabs, and then backspace unindents the tab too far to fix it, etc.
[11:53] <rbasak> It's really irritating
[11:53] <cpaelzer> rbasak: but in Bionic I have the same
[11:53] <cpaelzer> set when opening a shell file
[11:54] <rbasak> Maybe it's been doing it longer than I think then
[11:54] <rbasak> Or perhaps GetShIndent() has changed?
[11:54] <cpaelzer> yep
[11:54] <cpaelzer> the option I get in Bionic and eoan
[11:54] <cpaelzer> but in eoan it is a 8char tab
[11:54] <cpaelzer> well bionic is probably modified by me, let me try a container there as well
[11:55] <cpaelzer> rbasak: ok bionic does the same
[11:55] <cpaelzer> it was just my local config that saved it
[11:55] <cpaelzer> has the same option set and does a long 8 char wide tab
[11:59] <rbasak> So perhaps I'm too late to drive any change in Ubuntu
[11:59] <rbasak> Thank you for looking
[12:03] <coreycb> jamespage: sahid: if we want to completely drop py2 this cycle then we'd need to remove those couple of remaining BDs that we're keeping for uca backports
[12:05] <coreycb> jamespage: sahid: i don't know if it's that high of a priority yet but we'll have to do it this cycle or next I'd think
[12:33] <cpaelzer> jamespage: I have a fixed build to avoid the dependency issue in a PPA, waiting for upstream response on it now
[12:33] <cpaelzer> jamespage: you can find all you need for now fromt he bug (e.g. if you want to PPA copy my build to yours)
[13:07] <jamespage> cpaelzer: ok testing
[13:39] <seb128> LocutusOfBorg, thx for that colord sync by I was about to do it, when an Ubuntu dev do a fake sync or an upload to Debian you can usually assume they are dealing with the update and that is no need to conflict/duplicate work (I'm mentioning it now because it's not the first time you do that)
[14:59] <sil2100> Laney: hey! Thanks for merging the ADT fixes - I have a small request though, I'd like to investigate the sru_regress_inform_state state file from the latest run
[14:59] <sil2100> Laney: could you copy it out/pastebinit for me somewhere?
[14:59] <sil2100> (since I have no access to snakefruit)
[16:30] <sil2100> Laney: nvm my earlier request!
[21:35] <mwhudson> foka: did you get to look at the golang-google-api tests on arm64 yet?
[21:35] <mwhudson> LocutusOfBorg, foka: any ideas on golang-go.crypto?
[21:35] <mwhudson> if not i'll start poking at that one
[21:39] <foka> mwhudson: golang-google-api, maybe I am doing it wrong, but I haven't been able to reproduce the test error on amdahl.debian.org.  My test methods were very simplistic, i.e. a simple "debuild -us -uc" run, and running something like "go test -p 4 -vet=off -count=1 google.golang.org/api/..."
[21:39] <mwhudson> foka: could just be noisy neighbour effects making the tests slow
[21:40] <mwhudson> foka: in which case i think it would be reasonable to badtest it
[21:41] <foka> As for golang-go.crypto, I notice the regression, but haven't got time to look at it yet.
[21:42] <mwhudson> hmm the package _builds_ fine
[21:42] <mwhudson> why would it then fail in autopkgtest
[21:42] <blackboxsw> vorlon: or other SRU vanguards: I think we may have talked about this condition on a previous cloud-init SRU.      We've started an SRU already, but found a bug in upstream for a new datasource that is included in the SRU. I'd like to fix that as part of this SRU.  but wanted to add a new debian/changelog stanza and continue to reference the same SRU process bug we have currently open. Since we have an SRU
[21:42] <blackboxsw> exception for cloud-init, (and have not yet fix-released #1841099. Can I add a 2nd stanza to cloud-init's debian/changelog referencing  example: https://pastebin.ubuntu.com/p/SJW8cDrHm4/
[21:42] <mwhudson> oh i bet some test is skipped because on the buildds because e.g. openssh-client isn't installed...
[21:43] <foka> mwhudson: Good thinking about openssh-client; that's probably it!  :-)
[21:43] <mwhudson> yes
[21:43] <mwhudson> --- SKIP: TestInvalidTerminalMode (0.01s)
[21:43] <mwhudson>     test_unix_test.go:188: skipping test: exec: "sshd": executable file not found in $PATH
[21:44] <mwhudson> what have i done wrong in life to have such good instincts about this sort of thing...
[21:48] <vorlon> blackboxsw: yes, it's fine to reuse the same SRU process bug
[21:48] <blackboxsw> ok thanks, I thought you had mentioned that before. wanted to double check
[21:50] <mwhudson> foka: yeah if i add openssh-server and openssh-client to build-depends the build fails too
[21:50] <mwhudson> gives me something to debug
[21:52] <foka> Awesome! 👍
[21:53] <mwhudson> fails in sid as well as debian fwiw
[21:53] <mwhudson> as well as eoan
[22:00] <foka> mwhudson: Yes, I just did a similar test build and failed on my Debian sid notebook too with openssh-{server,client} added to Build-Depends.  (My computer is a bit slow though, so it took a while to finish, hoho)
[22:00] <mwhudson> i suppose it's time to look at what this test is actually doing
[22:10] <mwhudson> this is a very strange test
[22:10] <mwhudson> it's essentially testing that the host sshd behaves in a particular way
[22:10] <mwhudson> and in a way that's not mandated by the RFC, to boot
[22:11] <mwhudson> "and the server MAY ignore any modes it does not know about."
[22:17] <mwhudson> er it passes on bionic though
[22:33] <mwhudson> hm i suspect this is an unintended behaviour change in openssh vwiw
[22:33] <mwhudson> *fwiw
[22:54] <mwhudson> foka: going to file an upstream bug to remove this test case and then upload a patch to debian removing it (and adding openssh-server to build-depends)
[22:56] <foka> mwhudson: Neat!  Thank you so much!
[23:25] <mwhudson> foka: uploaded to debian
[23:25] <mwhudson> that's my go package fiddling done until tomorrow i think ...
[23:38] <foka> mwhudson: You are wonderful!  Thank you very much!