[06:58] nice work foka mwhudson ! [06:58] wrt x-sys, I think ignoring tests results might be the best thing to do for now [07:09] it has something to do with the new openMountByID test [07:09] + mi, err := os.Open("/proc/self/mountinfo") [07:09] I don't think its a good idea to try to open such devices inside a chroot... [07:17] LocutusOfBorg: if that doesn't work, the chroot illusion sucks [07:25] s1aden, it works to be honest [07:25] the test is trying to read some device inside it === s1aden is now known as sladen [07:33] [09:33:16] 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] Debian bug 935935 in src:golang-golang-x-sys "golang-golang-x-sys: test failure in chroots" [Important,Open] [07:33] foka, mwhudson ^^ [07:33] I did some debugging and opened a bug report... [07:33] (and thanks for fixing smux! [07:40] LocutusOfBorg: You're very welcome! :) And thanks for looking into golang-golang-x-sys. [07:40] I hope I didn't mess too much with the package, I'm not a golang speaking guy! [07:41] with your help we might get all the golang stack migrate :D [07:43] 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] LocutusOfBorg: I'm glad xtaci fixed smux so quickly! [07:58] done thanks! [07:59] so, last blocking golang issues: [07:59] http://autopkgtest.ubuntu.com/packages/g/golang-google-api/eoan/arm64 <-- [07:59] golang-go.crypto autokpkgtest failures [08:00] golang-golang-x-tools autopkgtest failures [08:00] http://autopkgtest.ubuntu.com/packages/g/golang-github-jbenet-go-context/eoan/armhf [08:00] 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] doko: yeah I just saw that [08:01] doko: what do the different 'levels' in the generated report mean? [08:01] less priority issues: golang-github-rs-zerolog autopkgtest failures on 32 bit, golang-gopkg-ldap.v3 FTBFS [08:01] golang-golang-x-tools autopkgtest failures [08:01] jamespage: nothing ;p just make sure that you remove leaf packages first [08:02] sahid, coreycb ^^ [08:02] doko - I'm assuming this is an objective for eoan then? [08:03] jamespage: no, that should be for 20.04, so that we can remove the python symlink and the python package [08:03] we may have to keep python2 and using the python2 shebang [08:06] doko: can we get nova-lxd rm'ed from eoan please - I raised a bug a while back to cover that [08:16] 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] 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:29] Launchpad bug 1786201 in intel-ipsec-mb (Ubuntu Eoan) "MIR for intel-ipsec-mb" [Medium,New] [08:42] jamespage: interesting [08:42] jamespage: how can dpdk not pull it in but OVS does [08:45] cpaelzer: just looking atm [08:45] cpaelzer: 2.11.1 generates the mismatch [08:45] LocutusOfBorg: i guess i'll look at google-api on arm64 tomorrow unless foka beats me to it [08:46] just seeing of the 2.12 snapshots I'm producing are doing the same thing [08:46] jamespage: https://paste.ubuntu.com/p/cdCf9CqpSX/ [08:47] these are the only packages needing it (two PMDs) [08:47] they are considered not for prime-time yet which is why they are only universe [08:47] LocutusOfBorg: have you looked at the crypto or tools failures? [08:48] essentially dpdk (is in main) pulls in a list of "better support/mature" PMDs and those are in main [08:48] crypto is some ssh thing iirc [08:48] jamespage: I'd not really see why OVS would directly create/depend on a list of PMDs [08:48] need to read build log of OVS in proposed [08:49] cpaelzer: one sec - this might have been a transient issue [08:49] tools is just "FAIL golang.org/x/tools/go/internal/gcimporter 22.980s" which is nice [08:49] cpaelzer: I had a build on the 7th august that showed this, and then one on the 8th that did not [08:49] odd [08:49] oO [08:49] I'm still parsing the buildlog [08:50] cpaelzer: those where in PPA's [08:50] but the 2.11.1 in the main archive has the same issue [08:50] whicih don't differ between main/universe [08:50] IIRC there all is main [08:51] cpaelzer: I mean't 'the ubuntu archive' rather than 'a PPA' [08:51] ok [08:52] 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] 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] can I see your 2.12 where this happens? [08:52] might be some sort of linking issue [08:53] yeah it could overlink [08:53] 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] cpaelzer: don't want you to spend cycles if not required :) [08:53] 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] ok jamespage, but overlinking could be a thing [08:54] it happened in the past with DPDK [08:54] so let me know [08:54] I'm closing the MIR for now [08:55] thanks for the ping still jamespage, worth to be aware of [09:02] jamespage: with 19.08 thre are some ipsec things http://paste.ubuntu.com/p/GRp2kC4sh4/ [09:02] but as you see all experimental (not for consumption) and we don#t have 19.08 in eoan [09:04] mwhudson, I fixed other stuff, but crypto... [09:04] Attempt to write login records by non-root user (aborting) [09:05] LOL [09:05] looks like the test is trying to ssh and fails because of ENOPERM? [09:05] 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] syncthing has lots of flaky tests... retrying amd64 worked, I'm hitting the i386 retry button hard once again [09:16] bryce: this symfony thing you asked turns out into a nice digital indiana jones trip [09:26] cpaelzer, you know what is funny? there is a new symfony release [09:42] we seem to ahve enough trouble with the old one LocutusOfBorg :-) [09:42] but most of what I found while anylazing the issues are outdated packages that seem fixable or removable [09:42] I'll later send a summary to bryce / vorlon who discussed this yesterday [09:44] LocutusOfBorg: unless you mean the 4.x that is stuck in proposed [09:44] that is the one that started the discussion [09:45] what is missing for symfony in proposed, is that some packages breaks the 4.x version [09:45] so they have to be kicked-out or updated [09:45] yep and that is what I was analyzing [09:46] the details of it [09:46] 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] I won't upload now, but if stuff migrates... [10:04] 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] or did you have some other upload/fix that makes this go well now? [10:11] not the same way? [10:12] cpaelzer, without all-proposed, php72 is picked up [10:40] 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] thanks jamespage, reading te log ... [11:09] jamespage: my assumption would be that OVS added support for librte-ipsec [11:09] it is odd that it doesn't show up and only the follow on dependency does [11:10] which then is libipsec-mb0 [11:10] cpaelzer: that was my assumption but I can't find anything in the codebase to indicate that is the case [11:10] unless there is something implicit in the ipsec support for the dpdk context [11:11] jamespage: overlinking [11:11] look in the log for the usual "package could avoid a useless dependency if" [11:12] it seems like all of DPDKs helper libs creeped in [11:12] that looks much like the libdpdk-dev dependencies [11:13] hmm, IÄ'm on something ... [11:14] jamespage: there is a -Wl,--no-as-needed in the libtool commandline [11:14] all after that seem to be what was overlinked [11:15] hmm yeah [11:15] that is from the pkgconfig of dpdk [11:20] jamespage: https://bugs.launchpad.net/ubuntu/+source/dpdk/+bug/1841759 [11:20] Launchpad bug 1841759 in dpdk (Ubuntu) "over-linking due to dpdk pkg-config" [Undecided,Triaged] [11:24] Does anyone else get irritated by indentexpr being set by default in vim packaging nowadays? [11:24] For me it's almost always wrong and I'm forever unsetting it :-/ [11:44] jamespage: I have a test fix building and will submit it upstream if it succeeds [11:44] I already ahve an ack for the approach by the Debian co-maintainer [11:45] rbasak: I guess I'm not new enough [11:46] 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] rbasak: upstream doc still lists it as default "" [11:49] rbasak: and it isn't set for me (in eoan conainer) [11:50] I get " indentexpr= " by :set indentexpr? [11:50] other options report their value nicely [11:50] rbasak: could that be a drop in config from any extra packages on top of what my eoan container has? [11:51] I think it gets set automatically depending on what is being edited [11:51] I couldn't pin down the exact place in the default init scripts [11:52] "vim -u NONE" works around by doing nothing, but then I don't get the other goodness [11:52] Example: if I edit a shell script, it uses an tab-based indent level of 8, which is almost always wrong [11:52] rbasak: what do I need to edit to get the behavior? [11:52] cpaelzer: try a bash script maybe? [11:53] I have opened a shell script and now get [11:53] indentexpr=GetShIndent() [11:53] 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] It's really irritating [11:53] rbasak: but in Bionic I have the same [11:53] set when opening a shell file [11:54] Maybe it's been doing it longer than I think then [11:54] Or perhaps GetShIndent() has changed? [11:54] yep [11:54] the option I get in Bionic and eoan [11:54] but in eoan it is a 8char tab [11:54] well bionic is probably modified by me, let me try a container there as well [11:55] rbasak: ok bionic does the same [11:55] it was just my local config that saved it [11:55] has the same option set and does a long 8 char wide tab [11:59] So perhaps I'm too late to drive any change in Ubuntu [11:59] Thank you for looking [12:03] 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] 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 === ricab is now known as ricab|lunch [12:33] jamespage: I have a fixed build to avoid the dependency issue in a PPA, waiting for upstream response on it now [12:33] 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] cpaelzer: ok testing === ricab|lunch is now known as ricab [13:39] 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] 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] Laney: could you copy it out/pastebinit for me somewhere? [14:59] (since I have no access to snakefruit) [16:30] Laney: nvm my earlier request! [21:35] foka: did you get to look at the golang-google-api tests on arm64 yet? [21:35] LocutusOfBorg, foka: any ideas on golang-go.crypto? [21:35] if not i'll start poking at that one [21:39] 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] foka: could just be noisy neighbour effects making the tests slow [21:40] foka: in which case i think it would be reasonable to badtest it [21:41] As for golang-go.crypto, I notice the regression, but haven't got time to look at it yet. [21:42] hmm the package _builds_ fine [21:42] why would it then fail in autopkgtest [21:42] 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] 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] oh i bet some test is skipped because on the buildds because e.g. openssh-client isn't installed... [21:43] mwhudson: Good thinking about openssh-client; that's probably it! :-) [21:43] yes [21:43] --- SKIP: TestInvalidTerminalMode (0.01s) [21:43] test_unix_test.go:188: skipping test: exec: "sshd": executable file not found in $PATH [21:44] what have i done wrong in life to have such good instincts about this sort of thing... [21:48] blackboxsw: yes, it's fine to reuse the same SRU process bug [21:48] ok thanks, I thought you had mentioned that before. wanted to double check [21:50] foka: yeah if i add openssh-server and openssh-client to build-depends the build fails too [21:50] gives me something to debug [21:52] Awesome! 👍 [21:53] fails in sid as well as debian fwiw [21:53] as well as eoan === tacocat is now known as Guest11990 === tacocat` is now known as tacocat [22:00] 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] i suppose it's time to look at what this test is actually doing [22:10] this is a very strange test [22:10] it's essentially testing that the host sshd behaves in a particular way [22:10] and in a way that's not mandated by the RFC, to boot [22:11] "and the server MAY ignore any modes it does not know about." [22:17] er it passes on bionic though [22:33] hm i suspect this is an unintended behaviour change in openssh vwiw [22:33] *fwiw [22:54] 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] mwhudson: Neat! Thank you so much! [23:25] foka: uploaded to debian [23:25] that's my go package fiddling done until tomorrow i think ... [23:38] mwhudson: You are wonderful! Thank you very much!