[02:27] <mwhudson> uh someone remind me how autopkgtest works
[02:27] <mwhudson> specifically the pinning bit
[03:26] <mwhudson> ah ha fun times, --apt-pocket=proposed=src:glibc does not let you install libc6:i386 from proposed
[04:10] <mwhudson> juliank, vorlon: one for one of you? https://code.launchpad.net/~mwhudson/autopkgtest/+git/development/+merge/416502
[09:52] <juliank> mwhudson: merged and deployed
[10:51] <mwhudson> juliank: thanks, i'll retry those failures
[11:09] <schopin> Anyone knows of a way to tell the autopkgtest runner to NOT use zstd when building its satdep deb?
[11:09] <schopin> juliank perhaps? ^
[11:14] <slyon> schopin: this seems to be hard-coded these days (http://launchpadlibrarian.net/574324062/autopkgtest_5.16ubuntu1_5.16ubuntu2.diff.gz) As a temporary workaround, you could probably manipulate that python file locally
[11:19] <juliank> schopin: where do you still see issues? impish and jammy were fixed to force xz?
[11:21] <schopin> As it turns out I was still the 5.17 from Debian (dogfooding my own patches). I'll drop back to the 5.16ubuntu2
[11:23] <schopin> I had thought to do debsums to see if I had any custom patches, but not to check the package itself -_-
[12:09] <ahasenack> good morning
[12:32] <didrocks> hey ahasenack, in case you haven’t noticed: https://launchpad.net/ubuntu/+source/adsys/0.8.1 (CC mwhudson)
[12:33] <ahasenack> I saw the update, it built! \o/
[12:33] <ahasenack> not yet in the excuses page
[12:33] <didrocks> yeah! Was happy to see in particular that the racy test on local file update seems to be fixed as well by the sync() call
[12:33] <mirespace> hi ahasenack
[12:33] <didrocks> still too fresh for this :)
[12:34] <ahasenack> hi mirespace
[12:34] <ahasenack> didrocks: a sub or superset of the dep8 tests runs at build?
[12:35] <didrocks> ahasenack: exactly the same tests are running. Unfortunately, the only tests that can only run on CI and not during build or autopkgtests are the integration ones, as they are pulling a docker image from github
[12:35] <didrocks> (which contains all system services like systemd, polkit…)
[12:38] <ahasenack> I also miss some CI for other packages, a layer up of what DEP8 can do
[12:38] <ahasenack> do you have your own, or do you use some shared ubuntu/canonical infra for it?
[12:39] <didrocks> it’s hosted on github, so it’s all github actions
[12:40] <didrocks> we do have quite some automations (https://github.com/ubuntu/adsys/tree/main/.github/workflows): Tests, code linting, auto update of i18n template, README, documentation and generations of admx/adml
[12:41] <ahasenack> ok, it's an upstream project
[12:41] <ahasenack> not a random package I suddenly decided to maintain in gitbug
[12:41] <ahasenack> github
[12:41] <ahasenack> heh, funny typo
[12:41] <didrocks> indeed :)
[12:42] <ahasenack> debian's salsa is closer to what I thought
[12:43] <ahasenack> in terms of packages in CI
[12:43] <didrocks> yeah, I think they have CI workers similarly to hosted gitlab?
[12:43] <ahasenack> anyway
[12:43] <ahasenack> they have CI, of random quality (package dependent)
[12:43] <didrocks> I guess…
[12:44] <ahasenack> https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#adsys showed up
[12:45] <ahasenack> ppc passed already
[12:45] <ahasenack> armhf failed
[12:45] <ahasenack> https://autopkgtest.ubuntu.com/packages/a/adsys/jammy/armhf
[12:45] <ahasenack> "Setup: Can't show stderr from smbd command: read |0: file already closedok  	github.com/ubuntu/adsys/internal/ad	41.539s" ?
[12:46] <ahasenack> and elsewhere
[12:46] <ahasenack>     --- FAIL: TestInit/Configuration_changed (0.04s)
[12:46] <ahasenack> armhf is run in a 32bit lxd container inside arm64
[12:48] <didrocks> humf
[12:49] <didrocks> configuration changed worked 6 times on 6 on an armhf builder, but yeah, the container may screw up inotify?
[12:51] <didrocks> yes, it’s the only test failing…
[12:51] <didrocks> the test is:
[12:51] <didrocks> write a config file, read it, subscribe to changes, write an update to the config file, sync(), wait for a callback telling that inotify triggers, read it
[12:52] <didrocks> but so apart from the lxd container puzzling it, I wonder if the only way would be to skip the test on that arch :/
[12:52] <didrocks> ahasenack: any other ideas?
[12:57] <ahasenack> is the builder the same env as the dep8 runner?
[12:57] <ahasenack> can we tell?
[12:58] <ahasenack> kernel could be different
[12:58] <didrocks> yeah, I bet…
[12:58] <ahasenack> I think the lxd trick is the same, unless we have native armhf builders
[12:58] <ahasenack> juliank knows perhaps?
[12:58] <ahasenack> (gratuitious ping)
[12:59] <didrocks> I was surprised to see it successfully passing on that arch 6 times over 6 reliably, so quite confident that calling sync() in the test was the right thing
[13:00] <ahasenack> well, trigger it one more time? Unless you have already
[13:00] <ahasenack> s390x passed
[13:00] <ahasenack> oh, arm64 failed too
[13:01] <ahasenack> same test
[13:01] <ahasenack> so forget lxd issues
[13:01] <ahasenack> amd64 passed
[13:02] <ahasenack> so it's arm64 and armhf that are failing,
[13:02] <didrocks> I would like avoiding putting random sleep() :/
[13:02] <didrocks> could be it inotify being broken on this kernel for arm64?
[13:03] <didrocks> or maybe we have more than one callback for the first "write to disk event"
[13:03] <didrocks> and so consider second callback before receving inotify when updating it
[13:04] <ahasenack> arm64 is easier to test manually
[13:04] <didrocks> is there any hardware I can connect to?
[13:04] <ahasenack> Found linux image: /boot/vmlinuz-5.15.0-18-generic is this the running kernel perhaps?
[13:04] <ahasenack> yeah, there are bare metal boxes in canonical
[13:05] <ahasenack> let me see if I still have access to one
[13:05] <didrocks> thx!
[13:07] <ahasenack> pinged you in mm
[14:30] <ahasenack> didrocks: arm64 passed the 2nd time
[14:30] <ahasenack> I think it's all greens now
[14:37] <rbasak> ddstreet: note that there's a TB meeting tonight (2000 UTC). So if you want the TB to consider DMB eligibility, now is the time to raise it.
[14:38] <ddstreet> I wasn't aware DMB eligibility required approval by the TB
[14:41] <rbasak> I don't know if you've seen my reply to you on the ML yet, but I hope that explains it.
[14:43] <rbasak> Steve was quite clear about it in the TB meeting the other week.
[16:13] <juliank> ahasenack: I think it deletes containers and starts new ones for new tests, as it does VMs for archs other than armhf
[23:48] <mwhudson> how often does the nbs report get regenerated?
[23:50]  * bdmurray looks
[23:55] <bdmurray> mwhudson: I think it runs all the time as a part of the archive-reports
[23:56] <mwhudson> bdmurray: ah ha
[23:56] <mwhudson> bdmurray: i think i thought i refreshed it but hadn't, or something