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