[00:19] tumbleweed: ty [00:28] np [00:48] does anyone have the faintest idea what's going on with python-meshplex? [00:52] mwhudson: upstream calls that an i386 bug, but maybe it's just a !amd64 bug? [00:52] tumbleweed: oh huh [00:52] tumbleweed: got a link? [00:52] (not that that implies any deeper understanding of the bug) [00:52] https://github.com/nschloe/meshplex/issues/78 [00:53] thanks [00:53] although, that seems to be passing in ci.debian.net now [00:53] I wonder if he patched it out [00:53] hmm [00:54] no, the version in ubuntu is the same i think [00:54] yeah [00:55] maybe a dependency that's skewed? [00:55] it's usually numpy :) [00:57] oh wait https://autopkgtest.ubuntu.com/packages/p/python-meshplex/hirsute/amd64 [00:57] uh no [00:57] yeah, that combination worked for amd64 [00:58] but not the other arches [00:59] i would say scientific software has the worst failures but i just looked at the postorius failure with python 3.9 so i won't [01:00] it's usually not the most actively maintained upstream [01:01] write phd, throw software over the wall, run [01:01] ugh postorius doesn't even run tests with python 3.8 upstream [01:57] $ .tox/py39-django20/bin/python -V [01:57] Python 3.8.5 [01:57] i don't understand how this works :( [06:15] thank you LocutusOfBorg [06:16] I thought we might as well at the same consider moving to 3.59, which I found you did later on - thanks === Guest23201 is now known as _hc === sem2peie- is now known as sem2peie [10:32] mwhudson: in debian, postorius tests succeed in unstable, but fail in testing. filed a bug about that. maybe some dependency not available? [10:33] mwhudson: re: tox: usually bad autopkg test downloading everything and not using the packages at all === sem2peie- is now known as sem2peie [11:02] seb128: ok, switching here not to spam -release with too many messages [11:02] k [11:03] seb128: so right now ubuntu-canary is done as a SUBPROJECT for ubuntu, which isn't quite the best solution - since subprojects aren't considered as separate 'entities' in the cdimage world, meaning: [11:04] When you build an ubuntu image, and then an ubuntu-canary image, they will both end up as ubuntu projects just with new publisher entries, so you'll have say 20201130 with regular ubuntu and then 20201130.1 with canary [11:04] Which is a bit dirty and confusing [11:05] ah [11:05] :( [11:05] Right now canary results in an empty dir when built as cdimage is missing a few changes to actually know what files to pull from the scratch directory to publish - but before we fix this, I was opting for reconsidering how we build canary images, since right now it would feel a bit confusing to me? [11:06] Like, people would look for dailies and not know what's up [11:06] what was subproject mean for? [11:06] it feels like the publishing side should handle that better [11:06] if subproject exists it should be handle in a way that gives a different result/name than not using subproject... [11:06] or what's the point? [11:07] That is a good question! I also misunderstood what subprojects are during the touch times, but actually SUBPROJECT is a way to customize a single project or when you use a different image type, like you have one subproject for daily.live one for daily and one for daily.preinstalled etc. [11:08] Anyway, subprojects are badly designed IMO :| [11:08] Right now I see two quick options for canary, that should be rather quickly achievable: [11:09] 1) Simply doing what we did for touch, just create a separate project for it [11:09] This should be relatively simple to do [11:09] 1) is a bit tedious, lot of editing to add another | next to each ubuntu one [11:10] but keep going, let's see what the other option is ;-) [11:11] 2) This one is probably a bit more hacky, but uh, maybe a SUBARCH! This is not what a subarch is for, but it's not the first time we do something like that - subarches actually work closer to how subprojects should in my opinion [11:12] hm, for 1) I could take a look if we could add this new project as a dummy project, basically an alias for ubuntu and the canary subproject, but I'd have to look if it's doable [11:12] Then we'd not have to change anything besides the cdimage code [11:13] We basically do something similar already for ubuntu-server, since actually our preinstalled ubuntu-server images build from the ubuntu-cpc project ;) [11:14] It's terrible, I know, I'd prefer to just having subprojects work a bit more as I'd expect them to, but I think this logic is too deep down in the machinery that modifying it would be very risky [11:16] sil2100, k, thanks for the context. I need to give that some thinking on what we want to do [11:16] also that image is just next gen ubuntu image, not a different product [11:20] Yeah, this is why I like the subarch approach, though it's not what a subarch is [11:21] But at least it's always generated with the cdimage run... [11:21] And if we go the separate project road, it would be only temporary [11:21] sil2100, but we have https://www.cdimage.ubuntu.com/ubuntu/daily-preinstalled/ ... is that not coming from the desktop-preinstalled subproject? [11:22] and if so how come that is working of publication using a subproject? [11:24] It's daily-preinstalled not daily-live, so it gets its own counter anyway [11:24] seb128: this is what I mentioned earlier, it all works because it's a different image type [11:25] daily.prelinstalled instead of daily.live [11:25] Laney, sorry I fail to parse that [11:25] I guess I don't understand cdimage things enough to understand what that means [11:25] case $PROJECT in [11:25] ubuntu|ubuntu-dvd) [11:25] case ${SUBPROJECT:-} in [11:25] canary) [11:26] desktop-preinstalled) [11:26] I don't understand how the subproject are different [11:26] they seems to be under similar structures? [11:26] I guess in theory we *could* maybe use the daily image-type (instead of daily-live) and use that in the subproject instead, but I don't know how many parts are hard coded for that [11:26] The crontab line looks like: [11:26] for-project ubuntu cron.daily-live --live; SUBPROJECT=desktop-preinstalled for-project ubuntu cron.daily-preinstalled --live [11:26] seb128: yeah, but the difference is that we build the desktop preinstalled image as daily-preinstalled ubuntu SUBPROJECT=desktop-preinstalled [11:27] While canary is daily-live ubuntu SUBPROJECT=canary, where regular ubuntu images are also daily-live [11:27] so PROJECT=ubuntu and SUBPROJECT=desktop-preinstalled [11:27] Since there's more than just PROJECT, ARCH, SUBPROJECT and SUBARCH - there's also image-type [11:27] hum [11:28] lol [11:28] so we could do cron.daily-canara with PROJECT=ubuntu and SUBPROJECT=canary? [11:28] this is quite complicated isn't it [11:28] cron.canary [11:29] seb128: I guess we could, but I have no idea how many things would need adding! We could re-use the existing unused 'daily' image type too [11:30] that feels more complex than it should be... [11:30] why can't we make $rightcode just append +${SUBPROJECT} to the artifact names [11:30] ? [11:30] seb128: I'd actually prefer adding a new temporary PROJECT for canary (and try to work-around for it to re-use the ubuntu parts as much as possible) [11:31] it's tedious and error prone though :/ [11:31] seb128: well, that's how I'd think it should work, but someone long ago designed it differently and now we're using this 'different' mechanism [11:31] having to find all the places where there is a "if ubuntu" and add a |canary [11:31] easy to miss one [11:32] also code is ugly when it's name|othername|... [11:32] Well, as said, I'd like to take a look if we could work around that, by just switching the project - making ubuntu-canary an alias for ubuntu + the subproject [11:32] It *should* be possible, as mentioned we do something vaguely similar for ubuntu-server [11:32] k [11:32] I can try have a look but I don't know my way around enough for that [11:33] the SUBARCH thing seems easier but less clean :/ [11:33] Yeah, let me dive into this a bit today before the sprint load [11:33] k [11:33] And let's sync up tomorrow/Wednesday again to get this done properly finally [11:34] let me know, I'm happy to take tasks to look at the changes, I just feel like I don't know my way around enough to be efficient [11:34] that sounds great, thanks sil2100! [11:35] The image building infrastructure is a bit outdated, we'd like to (and will eventually) redesign and refresh it, but it's a big task and we're a bit short on peeps! [11:35] sil2100, and meanwhile can you just tell me in I maybe have access to the location where the build from today is or could you copy it to a more public place? I just want to check that it matches the content I got from my local build setup [11:35] then I can keep iterating locally [11:36] sil2100: You can do it on the cdimage side too, (1) use a fresh build-id for this build, (2) publish to a different top level directory [11:36] Let me export those for you somewhere [11:36] until we sort out the project subproject vs subarch vs hacktype thing [11:36] sil2100, thx [11:36] Laney: yeah, I was pushing it to a different directory for j_ibel in the past ;) [11:37] that's where it should be anyway === sem2peie- is now known as sem2peie [11:40] seb128: ok, so it's still syncing, but I pushed it here: http://cdimage.ubuntu.com/ubuntu-canary/ [11:40] (with a datestamp of today) [11:42] sil2100, thanks! [11:43] yw! [12:17] seb128: I see you triggered apparmor for evince - https://autopkgtest.ubuntu.com/packages/a/apparmor/hirsute/ppc64el - FYI you'll need to trigger vs 3.0.0-0ubuntu4 to get it working [12:50] cpaelzer, ah, thanks [15:33] juliank: FYI qemu fix working and on the way throu proposed migration - mail with workarounds sent to help further affected people until the new version is released [15:33] +1 [15:46] tseliot: 4.3.0-1build1ubuntu0.21.04 is a strange version, should be: 4.3.0-1ubuntu1 [15:48] doko, I think there was a no change rebuild in between. I can re-upload it as 4.3.0-1ubuntu1 if you prefer [15:49] no, just for future uploads [15:50] and yes, -1ubuntu1 is a higher version than -1build1 [16:34] coreycb: do we still need dnspython 1.6, or can we sync to 2.0? [16:38] doko: upstream openstack is still locked in at 1.16.0 but I can dig deeper [16:39] xnox: why do we need the usrmerge package? Our implementation hasn't depended on this before now [16:42] doko: looks like we need to stay <= 2.0.0 until this is fixed https://github.com/eventlet/eventlet/issues/619 [16:44] coreycb: do you have any insight on this? succeeds on all archs except amd64.. https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-hirsute/hirsute/amd64/d/dnspython/20201126_124443_023e1@/log.gz [16:49] coreycb: also the glance timeout: https://autopkgtest.ubuntu.com/packages/g/glance/hirsute/amd64 [16:55] vorlon: to upgrade pre-disco installs to mergedusr. Such that in 22.10 i can flip builders and build all .debs with mergedusr too. [16:55] vorlon: we should complete the transition for upgrades too, versus just the new installs. [16:56] vorlon: on systems that have been installed with merged usr this should not have any effect. [16:56] xnox: ok so this is the package that handles making symlinks on upgrade? [16:56] vorlon: yes. [16:56] ok [16:56] vorlon: but need to check that it doesn't screw up buildd tarballs. [16:56] vorlon: i'm never sure which seed is installed everywhere, but not in the buildd chroots. [16:57] cause through to 22.04 and including 22.04 our buildd tarballs must stay split-usr. [16:58] oh? [16:58] doko: I'm not sure but icey or I will take a look at those [16:58] pondering if usrmerge/autoconvert should be set to false in buildd tarballs. [16:58] vorlon: i don't want to switch building things with merged-usr & handle upgrades at the same time. [16:58] ah [16:58] vorlon: or maybe it doesn't matter much, and should be done at the same time? [16:58] * xnox tries small steps [17:00] xnox: it seems safe to me to do it in the same cycle [17:01] vorlon: ok. let's try that then. [17:03] vorlon: which packages become Essential: "yes" ? [17:03] i guess i did it now by doing it into required. [17:04] if i wanted to achieve what i wanted originally, i should have put it into minimal; not required. oh well. off we go then. [17:04] xnox: no packages become Essential: yes [17:04] echo $(apt show tar | grep Essential) Essential: yes [17:05] essential packages exist. no new packages become essential :) [17:05] is that on the fly calculation by apt?! [17:05] no, that's declared in debian/control [17:05] ok, interesting. [17:06] minimal; mir; change debootstrap; then move to required i think is the right way to do it. [17:16] I want to upgrade to merged us [17:16] I want to upgrade to merged usr [17:16] juliank: sudo apt install usrmerge [17:16] I have upgraded to merged usr [17:16] Now I need to find out why I have a dir /1:5.1+dfsg-4ubuntu1 [17:16] with block-{curl,iscsi,rbd,ssh}.so [17:16] lolz [17:16] juliank: some broken qemu-nbd install or some such? [17:16] qemu-utils has plugins. [17:16] hmm [17:16] like those [17:16] cpaelzer: ^ [17:16] there was email from christian about broken qemu-gui i think, no? [17:16] cpaelzer: Was this you breaking too? [17:16] drwxr-xr-x 1 root root 102 Nov 30 11:50 1:5.1+dfsg-4ubuntu1 [17:16] it installed this morning [17:16] 11:50 is the qemu-system-gui upgrade failure [17:16] or it's removal [17:16] who knows [17:16] $ find /foo/usr/share/ -type f [17:16] /foo/usr/share/doc/node-supports-color/changelog.Debian.gz [17:16] /foo/usr/share/doc/node-supports-color/copyright [17:16] /foo/usr/share/doc/node-supports-color/readme.md [17:16] /foo/usr/share/nodejs/supports-color/browser.js [17:16] /foo/usr/share/nodejs/supports-color/index.js [17:16] /foo/usr/share/nodejs/supports-color/package.json [17:17] system messy [17:18] maybe someone hacked my system [17:18] :D [17:18] Also /cryptroot dir, I don't know why that exists [17:19] maybe you did dpkg-deb -x *.deb foo/ [17:19] and forgot you were root and in / ? [17:19] or like exitted a chroot [17:19] possible [17:19] :D [17:19] drwxr-xr-x 1 root root 0 Jul 23 2019 cryptroot [17:19] do I need that?! [17:19] let's just delete it [17:20] I still feel like I should move /home to /var/home [17:20] and /etc to /var/etc [17:20] have / be a tmpfs [17:21] and then mount / and /var [17:21] and then ofc, mount /usr read-only (and /) [17:22] oh yeah, /srv would move to /var/srv too [17:22] and I guess snap needs to be /var/snap [17:33] anyone know how to get the system to tell me if a device is being powered down for powersaving? [17:34] I just rebooted and now my mouse seems to power off as soon as I stop moving it, takes a couple of seconds to wake up, infuriating [17:34] yup [17:34] Laney: install powertop, go to correct tab [17:35] "Tunables" [17:35] ooh powertop [17:35] I see the same thing, fwiw [17:35] I have not investigated why [17:35] I have not rebooted in 9 days [17:35] it started happening yesterday IIRC [17:35] well previously I hadn't since 2020-09-30, so there's quite a big delta :D [17:35] 9 days is better [17:36] same kernel for me fwiw [17:36] I'm actually on mainline 5.9.8-050908-generic [17:37] * juliank is wating for https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1896091 bug fix [17:37] Launchpad bug 1896091 in linux (Ubuntu) "[i915] Noise-like lines of graphics corruption when moving windows in Xorg sessions" [High,Triaged] [17:39] right turning off autosuspend seems to stop this from happening [17:40] did I lose some udev rule? [17:40] I want to know too [17:40] when I plug the receiver thing into my laptop, running groovy, that same device is "Bad" for autosuspend [17:40] it's "Good" on hirsute [17:40] ack [17:41] I have tlp installed, but I did not set up any blacklist in there [17:41] but this used to work [17:41] lemme see a bit more [17:41] # Note: input devices (usbhid) are excluded automatically [17:41] So I'm not sure what is setting usb autosuspend if it's not tlp === sem2peie- is now known as sem2peie === ijohnson is now known as ijohnson|lunch [18:19] juliank: Try moving 60-libfprint-2.rules away please === ijohnson|lunch is now known as ijohnson [18:47] anybody wanna review Bug 1901344 [18:47] bug 1901344 in cinnamon-screensaver (Ubuntu) "[SRU] Spotify album icon shows optimal CD disk instead of album/cover image" [Low,Confirmed] https://launchpad.net/bugs/1901344 [19:17] coreycb: the glance test now passes with some more oslo triggers. help on dnspython would be still appreciated [19:17] doko: great, ok [20:35] doko: i was just trying to run the upstream tests with python3.9 and tox, nothing packaging related [21:08] doko: dnspython seems ok so far running it locally: https://paste.ubuntu.com/p/FgXmscmr53/ [21:08] maybe that's not picking up python 3.9 (?) [21:10] it's py3.9 "Testing with python3.9"