=== Guest8 is now known as ethanhsieh === ethanhsieh is now known as ethanhsiehtest === ethanhsiehtest is now known as ethanhsieh === ethanhsieh42 is now known as ethanhsieh [08:46] doko, https://launchpadlibrarian.net/715376454/buildlog_ubuntu-noble-ppc64el.libunivalue_1.1.1+20191112-2_BUILDING.txt.gz looks like libunivalue needs some more optional symbols === pushkarnk1 is now known as pushkarnk [09:11] @pilot in === ChanServ changed the topic of #ubuntu-devel to: Archive: open | Devel of Ubuntu (not support) | Build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of Focal-Mantic | Patch Pilots: schopin [13:06] @ahasenack I have seen the discussion and am currently trying to get the test suite to work. I already added a hello world test for the cgi handler. I have also seen that doku uploaded my WIP version. I will ask for a sonsor of an updated version once I get the test suite running and passing. [13:12] dviererbe: sounds great [13:12] dviererbe: would you like to perhaps create an upstream PR, linked to the upstream bug you created? [13:12] then it's also easier to comment [13:13] I will do that, just a minute... [13:13] thx [13:22] ahasenack: you can the PR here https://github.com/grisha/mod_python/pull/131 [13:22] -ubottu:#ubuntu-devel- Pull 131 in grisha/mod_python "Refactor patch for Python 3.12" [Open] [13:23] awesome [13:26] I also added you as a contributer to the repo, so you can push commits (if you want) [13:26] oh, you are upstream? [13:26] ah, to your fork [13:26] works too :) [13:27] yes [13:27] Could you help me figuring out how to get the test suite working? I get [13:27] Bad value for mod_python.version.HTTPD : [13:27] Bad value for mod_python.version.TESTHOME : [13:27] Bad value for mod_python.version.TEST_MOD_PYTHON_SO : [13:27] Please check your mod_python/version.py file [13:27] The proble is there is no mod_python/version.py file [13:29] is this run at build time? [13:29] pkg build time, I mean [13:29] and maybe make the PR against the fork, not against that patch, otherwise the diff looks small [13:30] as it only shows the find_spec/spec_from_file_location change [13:33] I did not see the tests in the build log, but my limited understanding of dh_make tells me that the tests should be run during build time [13:33] I'll check [13:33] I also reset the base for the fork [13:35] I see it in the log now "Cannot import mod_python.version. " [13:36] but still, I should be able to run it as an dep8 test [13:38] I see it [13:38] maybe it's complaining that the file doesn't exist, that's why the variables it's showing just before are empty [13:40] setup.py.in has a def generate_version_py() to generate it [13:40] :q [13:46] qa-help: can you help me understand what's going on with the test retries on jupyter-notebook ? When we explicitly trigger as jupyter-notebook/6.4.12-2.2ubuntu1 it's selecting jupyter-notebook/6.4.12-2.2 anyhow [13:47] good question, I've no idea right now [13:47] dbungert: saw that too, asked internally (in a slightly different way) [13:47] dbungert: before it was because 2.2ubuntu1 was FTBFS, but now it's correct [13:48] right, I wonder if that old FTBFS info is cached or something and it refuses to use that version yet [13:49] and even with a trigger it's selecting the old version? [13:49] yes [13:49] I don't remember if I saw that attempt [13:49] ok [13:50] multiple test retries have been attempted on https://autopkgtest.ubuntu.com/packages/j/jupyter-notebook/noble/amd64, some explicitly with ubuntu1, and the few I have spot checked are all using 6.4.12-2.2 [13:51] andersson1234: maybe you can help here ^ ? [13:51] armhf used the correct version sometimes: https://autopkgtest.ubuntu.com/packages/j/jupyter-notebook/noble/armhf [13:51] still failed, what's up this time... [13:55] the NotebookUnixSocketTests failure was fixed with python3-requests-unixsocket === mfo_ is now known as mfo [14:04] dviererbe: so two things [14:04] dviererbe: a) right after package build, lib/python/mod_python/version.py exists and has correct content [14:04] dviererbe: b) somehow, that is stripped when the file is copied into the package. That copy has empty values [14:04] that is weird [14:04] dviererbe: c) (ok, 3 things) the test uses the version.py file from the installed package, not from the build directory. So it finds the empty values, and complains [14:08] and I didn't find yet what actually populates that file with values. The function in setup.py only generates a blank one, with only the module version populated, but not the rest [14:09] bryyce: hey, when I use ppa wait, it clears my terminal and I find it inconvenient; is that a known thing and is there a way to disable this behavior? [14:10] ahasenack: I do not think that setup.py is called during build time, because distutils is also removed with python 3.12 and would fail the build [14:10] it is called, according to deb build logs [14:30] bryyce: I tried various things; "| cat -v" helped but the output is slightly ugly, "| ansifilter" can help too but is not installed everywhere, "| col -b" worked and the output was less ugly than cat -v but still had traces of control chars; the best solution so far as been to set the TERM env var: TERM=dumb [14:30] dviererbe: I don't think these bundled tests are ok, at first glance. For once, they require write access to the python lib [14:30] # the rest of this test requires write perms to site-packages/mod_python [14:30] if os.access(version_path, os.W_OK): [14:31] although that might just be skipped [14:31] :q [14:31] ops [14:31] I'm jsut checking now what actually populates version.py [14:31] ahasenack: I am currently trying to get these tests to run as roo. I don't think that write permissions are an issue [14:32] *root [14:32] for dep8 then [14:36] doko: will we eventually remove bin:python3-distutils 3.11.5? [14:39] @pilot out === ChanServ changed the topic of #ubuntu-devel to: Archive: open | Devel of Ubuntu (not support) | Build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of Focal-Mantic | Patch Pilots: N/A [14:43] dbungert: got a pass with this trigger https://autopkgtest.ubuntu.com/packages/jupyter-notebook/noble/armhf [14:43] I'll repeat it for the other architectures [14:43] outstanding [14:43] hmpf, would be useful it the link was ready to paste, but I have to construct it again [14:44] ahasenack: I am not sure how we can replace distutils. The recommended migration is setuptools and setuptools was removed with lunar See LP: #1998970 [14:44] -ubottu:#ubuntu-devel- Launchpad bug 1998970 in rawkit (Ubuntu) "Remove pypy from lunar" [Undecided, Fix Released] https://launchpad.net/bugs/1998970 [14:46] dviererbe: I was thinking about a dep8 test like the smoke one, but for cgi. the bundled test suite might be too much effort for now [14:46] that version.py file being populated seems to be a distutils thing too [14:46] Well i already have a working hello world test [14:46] for the cgi handler [14:46] add a print of the environment to it, I'm curious if we are leaking something [14:47] I'll shelve this build-time-test pursuit for now [15:01] ahasenack: printing sys.modules gives me this https://paste.ubuntu.com/p/Pg4QPvRsRV/plain/ === popey0 is now known as popey [16:47] adrien, yes use `ppa wait --log`. Sorry that wasn't more discoverable, it's the last item in `ppa wait --help`. Where did you first look to see how to disable that? I can see about adding better docs at that spot. [16:48] oh, I was assuming --log would want to write to a file [16:48] and I most probably skipped reading the description in full [16:49] but also, besides the screen clearing, isn't printing the ongoing status to console the default behavior anyway? [16:49] likely you should be able to set 'wait_logging' to false in your config file to change that behavior permanently locally [16:50] also, I expected that piping the output to another program would disable that behavior [16:50] I need to leave to prepare dinner unfortunately but I'll be back a bit later [16:50] yes it used to be, but other users found _that_ to be inconvenient and at the time I didn't know if anyone would prefer the current behavior (but I left this config option just in case) [16:52] :D [16:52] users are convenient [16:52] <3 users [16:53] I'm not sure on use cases for saving log output to a file but that's doable via `ppa wait --log | tee ...` so that's as far as my thinking got there [16:54] adrien, I'm glad you asked about this though, I was curious if the non-clearing function was useful for some people [16:54] I'm not saying I would use such an option, rather than it exists in that form in other apps and was expecting something similar here [16:55] tbh, I don't see how clearing is useful to some :) [16:55] clearly, the people who think or do differently than I do are monsters [16:55] haha [16:56] well the argument was that one would leave it running in a terminal to visually note changes [16:56] but also, I'm wondering if I get the same behavior: I end up with an empty screen which I can't scroll up [16:57] yeah that's a "feature" of the clear screen system call [16:58] I might try some output reworking; there's something I'd like to try (but I have to leave now :) ) [16:59] adrien cool, I look forward to hearing more [18:18] ahasenack: yes, when 3.11 is removed from python3-defaults as supported [18:18] we might have a new influx of bugs with import failures then [18:18] right now, some are still "working" because distutils is there, from 3.11 [18:19] but that isn't importable from python 3.12 anyway, so shouldn't be many [18:27] if we really need, we could do something like a python3-zombie-distutils, but I would like to avoid that [18:52] dbungert: your jupyter-notebook issues should be sorted now e.g. feel fre to kick off a test again [18:53] bdmurray: thanks. Are tests that are already queued OK? [18:53] yes [19:28] bdmurray: test run c6bf2236-3559-4bfb-b936-32b20551a907 was queued after this conversation, but is still using the wrong version of jupyter-notebook in spite of triggers. [19:34] dbungert: I don't know how to search for a uuid yet what arch release package? [19:34] https://autopkgtest.ubuntu.com/packages/j/jupyter-notebook/noble/arm64 [19:35] top entry [19:37] dbungert: I don't see jupyter-notebook in those triggers [19:37] thank you [19:37] that's an unexpected response [19:38] I will requeue with a fixed trigger [19:38] getting warmer ;-) [19:39] I was wrong and Brian was wright [19:39] right [20:01] so besides jupyter, [20:01] remaining issues seem to be ansible, one libapache2-mod-python (ppc64el, runners were odd there, new runs are queued) [20:01] and I see one update-motd armhf-only red [20:02] my "favorite" arch [20:02] "fcntl() invalid argument" [20:02] huh [20:05] yes, I looked at that already, same "huh" [20:05] ansible/armhf is also an armhf-only issue [20:07] it's hard to replicate the armhf environment that LP uses [20:07] I have this in my notes: https://git.launchpad.net/autopkgtest-cloud/tree/charms/focal/autopkgtest-cloud-worker/autopkgtest-cloud/tools/armhf-lxd.userdata#n76 [20:07] on how autopkgtests launch armhf containers [20:08] bdmurray: do you know what the host is for the armhf autopkgtest containers? focal? jammy? running kernel? [20:09] ahasenack: focal [20:12] running kernel is visible near the top of the test log [20:12] I'll try with my mantic pi4 first (using an armhf container launched like in the git url above) [20:13] if that doesn't show the error, then I'll try a bare metal arm64 running focal deployed with maas, but that will take much longer [20:13] lxc launch ubuntu-daily:noble/armhf pi4:n-armhf-lp -c raw.lxc="apparmor.profile=unconfined" -c raw.lxc="seccomp.profile=" -c security.nesting=true [20:13] trying that first [20:15] FYI, you can run focal on the pi4 (if you want something as close as possible to the autopkgtest setup) [20:17] Let me know if there is anything I can do to help [20:21] waveform: yep, but this is a "production" pi4 :) [20:21] don't want to boot it on another OS right now [20:22] actually, let me in parallel find that nice arm64 system that can spawn a armhf container [20:22] or, oh, maybe canonistack is working well enough [20:29] hm, no go for canonistack [20:29] | 88479cf3-ff4b-4eac-91be-e87c8f5dfd20 | n-arm64 | ERROR | - | NOSTATE [20:46] it passed locally, with the mantic kernel [20:59] we could debian/tests/wait-for-apt-update-to-finish || : [20:59] that script is just to wait for an apt lock in case there is an apt running [20:59] it's to help with making the test more resilient, ironically [21:00] the actual test is calling update-motd after that [21:00] that being said, [21:00] it's only failing on python 3.12 [21:00] migration-reference/0 works (with py3.11) [21:00] and that is a python script [21:00] ok, let's check what changed in 3.11 -> 3.12 in what that script does [21:09] * ahasenack has a hunch [21:12] despite the multiple reruns and triggers, all tests from https://autopkgtest.ubuntu.com/packages/update-motd/noble/armhf were against python 3.11, not python 3.12 [21:12] so it looks like it was that issue that just got fixed [21:21] ah, no, 3.11 is the update-motd version, not python [21:21] hunch busted [21:31] ok, at least I can reproduce it [21:32] works with python 3.11, fails with 3.12: https://pastebin.ubuntu.com/p/Ccr7SB4sRN/ [21:32] I'll file a bug to get this recorded, since it's eod [21:32] ah, there is one, excellent [21:41] doko: about update-motd, I added some interesting info to https://bugs.launchpad.net/ubuntu/+source/update-motd/+bug/2054369 [21:41] -ubottu:#ubuntu-devel- Launchpad bug 2054369 in update-motd (Ubuntu) "update-motd fails autopkg test on armhf in noble, blocking python3-defaults" [Undecided, Confirmed] [21:41] but I'm eod now, can continue tomorrow [21:41] I have an instance up on canonistack where this is happening, if somebody wants to take a look while I'm gone [21:42] I'm trying to udnerstand where the magic struct.pack('hhllhh', fcntl.F_WRLCK, 0, 0, 0, 0, 0) comes from [21:42] ahasenack: that strace output is pretty yikes [21:42] something is being packed incorrectly [21:51] kanashiro: please forward the swig issue to debian [21:52] I'll forward all the patches I am adding to debian [23:06] ahasenack, just had a bit of a google around and ran across the fcntl module tests in python (https://github.com/python/cpython/blob/main/Lib/test/test_fcntl.py) -- of particular interest is get_lockdata from line 53 [23:07] following that down we can see that on linux it'll use the struct 'hh'+start_len+'hh'; start_len is ll on platforms without os.O_LARGEFILE, but qq on platforms with (which would suggest the struct in use is too short on armhf?) [23:08] (assuming armhf has os.O_LARGEFILE -- I'll try and check that in a bit) [23:16] yes, armhf has os.O_LARGEFILE so it'll be using a struct that's too short [23:35] waveform: why does the call pass in python 3.11 I wonder? [23:36] dumb luck would be my guess; the fcntl call will be reading too much from the struct and it just *happens* to run across a load of garbage at the end in 3.12 while it didn't in 3.11 [23:37] but yeah, changing ll to qq passes with python 3.12 [23:37] this all sounds like a VERY CONVOLUTED way to check a lockfile :D [23:37] yes ... I'm wondering if it can just be replaced with a call to flock instead ... [23:38] the test is also ... a bit weird. It's setting NONBLOCK on the fd, then does an explicit blocking wait for the lock ... [23:38] (not to mention it's testing for -1 on the fcntl return, which is also wrong -- if fcntl fails it just raises OSError; not that that makes any difference, the script will still bail with rc 1) [23:39] still, it all kinda screams "re-write me nicely" [23:40] hm, on my amd64 mantic laptop, python 3.11, [23:40] $ python3 -c "import os; print(os.O_LARGEFILE)" [23:40] 0 [23:40] on armhf (host arm64), [23:40] # python3.11 -c "import os;print(os.O_LARGEFILE)" [23:40] 131072 [23:40] same with py 3.12 there [23:40] yeah, but it's just testing for the *existence* of O_LARGEFILE, not for its value [23:41] oh, true [23:41] so it should be qq always? [23:41] in our cases [23:41] on the platforms we care about, apparently yes [23:42] apparently this check was added because of freedombox [23:42] which was now removed d/t/control [23:43] https://git.launchpad.net/ubuntu/+source/update-motd/commit/?id=c060dd002473f5700d8db3916bd8da122ec94fc3 [23:43] -ubottu:#ubuntu-devel- Commit c060dd0 in ubuntu/+source/update-motd "3.6-0ubuntu9 (patches unapplied) import/3.6-0ubuntu9" [23:44] and freedombox was removed: https://git.launchpad.net/ubuntu/+source/update-motd/commit/?id=1fb924d7cb573df5202a16d93ebcae1e20d62e2a [23:44] -ubottu:#ubuntu-devel- Commit 1fb924d in ubuntu/+source/update-motd "3.11 (patches unapplied) HEAD import/3.11 ubuntu/noble-proposed ubuntu/noble-devel ubuntu/noble ubuntu/devel" [23:44] (why was it a test dep for update-motd anyway??) [23:44] weird [23:45] yeah, everything about this is bizarre ... I'm just looking at the fcntl.flock/lockf code in CPython and I'm *fairly* sure all this could just be replaced with one of those calls [23:45] (assuming we even want to keep the test) [23:46] I'll setup a run without it [23:46] or, for something safer(?), switch to qq [23:46] that would be the minimal safe change [23:53] oh, freaking native packages