| mwhudson | uh someone remind me how autopkgtest works | 02:27 |
|---|---|---|
| mwhudson | specifically the pinning bit | 02:27 |
| mwhudson | ah ha fun times, --apt-pocket=proposed=src:glibc does not let you install libc6:i386 from proposed | 03:26 |
| mwhudson | juliank, vorlon: one for one of you? https://code.launchpad.net/~mwhudson/autopkgtest/+git/development/+merge/416502 | 04:10 |
| === michagogo is now known as micha_ | ||
| juliank | mwhudson: merged and deployed | 09:52 |
| mwhudson | juliank: thanks, i'll retry those failures | 10:51 |
| 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:09 |
| 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:14 |
| juliank | schopin: where do you still see issues? impish and jammy were fixed to force xz? | 11:19 |
| 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:21 |
| schopin | I had thought to do debsums to see if I had any custom patches, but not to check the package itself -_- | 11:23 |
| ahasenack | good morning | 12:09 |
| didrocks | hey ahasenack, in case you haven’t noticed: https://launchpad.net/ubuntu/+source/adsys/0.8.1 (CC mwhudson) | 12:32 |
| 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:33 |
| ahasenack | hi mirespace | 12:34 |
| ahasenack | didrocks: a sub or superset of the dep8 tests runs at build? | 12:34 |
| 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:35 |
| 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:38 |
| didrocks | it’s hosted on github, so it’s all github actions | 12:39 |
| 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:40 |
| 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:41 |
| ahasenack | debian's salsa is closer to what I thought | 12:42 |
| 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:43 |
| ahasenack | https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#adsys showed up | 12:44 |
| 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/ad41.539s" ? | 12:45 |
| 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:46 |
| didrocks | humf | 12:48 |
| didrocks | configuration changed worked 6 times on 6 on an armhf builder, but yeah, the container may screw up inotify? | 12:49 |
| 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:51 |
| 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:52 |
| ahasenack | is the builder the same env as the dep8 runner? | 12:57 |
| ahasenack | can we tell? | 12:57 |
| 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:58 |
| 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 | 12:59 |
| ahasenack | well, trigger it one more time? Unless you have already | 13:00 |
| ahasenack | s390x passed | 13:00 |
| ahasenack | oh, arm64 failed too | 13:00 |
| ahasenack | same test | 13:01 |
| ahasenack | so forget lxd issues | 13:01 |
| ahasenack | amd64 passed | 13:01 |
| 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:02 |
| 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:03 |
| 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:04 |
| ahasenack | let me see if I still have access to one | 13:05 |
| didrocks | thx! | 13:05 |
| ahasenack | pinged you in mm | 13:07 |
| ahasenack | didrocks: arm64 passed the 2nd time | 14:30 |
| ahasenack | I think it's all greens now | 14:30 |
| 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:37 |
| ddstreet | I wasn't aware DMB eligibility required approval by the TB | 14:38 |
| rbasak | I don't know if you've seen my reply to you on the ML yet, but I hope that explains it. | 14:41 |
| rbasak | Steve was quite clear about it in the TB meeting the other week. | 14:43 |
| juliank | ahasenack: I think it deletes containers and starts new ones for new tests, as it does VMs for archs other than armhf | 16:13 |
| === chiluk_ is now known as chiluk | ||
| mwhudson | how often does the nbs report get regenerated? | 23:48 |
| * bdmurray looks | 23:50 | |
| bdmurray | mwhudson: I think it runs all the time as a part of the archive-reports | 23:55 |
| mwhudson | bdmurray: ah ha | 23:56 |
| mwhudson | bdmurray: i think i thought i refreshed it but hadn't, or something | 23:56 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!