[00:19] <mwhudson> tumbleweed: ty
[00:28] <tumbleweed> np
[00:48] <mwhudson> does anyone have the faintest idea what's going on with python-meshplex?
[00:52] <tumbleweed> mwhudson: upstream calls that an i386 bug, but maybe it's just a !amd64 bug?
[00:52] <mwhudson> tumbleweed: oh huh
[00:52] <mwhudson> tumbleweed: got a link?
[00:52] <tumbleweed> (not that that implies any deeper understanding of the bug)
[00:52] <tumbleweed> https://github.com/nschloe/meshplex/issues/78
[00:53] <mwhudson> thanks
[00:53] <tumbleweed> although, that seems to be passing in ci.debian.net now
[00:53] <tumbleweed> I wonder if he patched it out
[00:53] <mwhudson> hmm
[00:54] <mwhudson> no, the version in ubuntu is the same i think
[00:54] <tumbleweed> yeah
[00:55] <tumbleweed> maybe a dependency that's skewed?
[00:55] <mwhudson> it's usually numpy :)
[00:57] <mwhudson> oh wait https://autopkgtest.ubuntu.com/packages/p/python-meshplex/hirsute/amd64
[00:57] <mwhudson> uh no
[00:57] <tumbleweed> yeah, that combination worked for amd64
[00:58] <mwhudson> but not the other arches
[00:59] <mwhudson> 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] <tumbleweed> it's usually not the most actively maintained upstream
[01:01] <tumbleweed> write phd, throw software over the wall, run
[01:01] <mwhudson> ugh postorius doesn't even run tests with python 3.8 upstream
[01:57] <mwhudson> $ .tox/py39-django20/bin/python -V
[01:57] <mwhudson> Python 3.8.5
[01:57] <mwhudson> i don't understand how this works :(
[06:15] <cpaelzer> thank you LocutusOfBorg
[06:16] <cpaelzer> I thought we might as well at the same consider moving to 3.59, which I found you did later on - thanks
[10:32] <doko> mwhudson: in debian, postorius tests succeed in unstable, but fail in testing. filed a bug about that. maybe some dependency not available?
[10:33] <doko> mwhudson: re: tox: usually bad autopkg test downloading everything and not using the packages at all
[11:02] <sil2100> seb128: ok, switching here not to spam -release with too many messages
[11:02] <seb128> k
[11:03] <sil2100> 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] <sil2100> 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] <sil2100> Which is a bit dirty and confusing
[11:05] <seb128> ah
[11:05] <seb128> :(
[11:05] <sil2100> 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] <sil2100> Like, people would look for dailies and not know what's up
[11:06] <seb128> what was subproject mean for?
[11:06] <seb128> it feels like the publishing side should handle that better
[11:06] <seb128> if subproject exists it should be handle in a way that gives a different result/name than not using subproject...
[11:06] <seb128> or what's the point?
[11:07] <sil2100> 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] <sil2100> Anyway, subprojects are badly designed IMO :|
[11:08] <sil2100> Right now I see two quick options for canary, that should be rather quickly achievable:
[11:09] <sil2100> 1) Simply doing what we did for touch, just create a separate project for it
[11:09] <sil2100> This should be relatively simple to do
[11:09] <seb128> 1) is a bit tedious, lot of editing to add another |<newname> next to each ubuntu one
[11:10] <seb128> but keep going, let's see what the other option is ;-)
[11:11] <sil2100> 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] <sil2100> 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] <sil2100> Then we'd not have to change anything besides the cdimage code
[11:13] <sil2100> We basically do something similar already for ubuntu-server, since actually our preinstalled ubuntu-server images build from the ubuntu-cpc project ;)
[11:14] <sil2100> 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] <seb128> sil2100, k, thanks for the context. I need to give that some thinking on what we want to do
[11:16] <seb128> also that image is just next gen ubuntu image, not a different product
[11:20] <sil2100> Yeah, this is why I like the subarch approach, though it's not what a subarch is
[11:21] <sil2100> But at least it's always generated with the cdimage run...
[11:21] <sil2100> And if we go the separate project road, it would be only temporary
[11:21] <seb128> sil2100, but we have https://www.cdimage.ubuntu.com/ubuntu/daily-preinstalled/ ... is that not coming from the desktop-preinstalled subproject?
[11:22] <seb128> and if so how come that is working of publication using a subproject?
[11:24] <Laney> It's daily-preinstalled not daily-live, so it gets its own counter anyway
[11:24] <sil2100> seb128: this is what I mentioned earlier, it all works because it's a different image type
[11:25] <sil2100> daily.prelinstalled instead of daily.live
[11:25] <seb128> Laney, sorry I fail to parse that
[11:25] <seb128> I guess I don't understand cdimage things enough to understand what that means
[11:25] <seb128> case $PROJECT in
[11:25] <seb128> 	ubuntu|ubuntu-dvd)
[11:25] <seb128> 		case ${SUBPROJECT:-} in
[11:25] <seb128> 			canary)
[11:26] <seb128> 			desktop-preinstalled)
[11:26] <seb128> I don't understand how the subproject are different
[11:26] <seb128> they seems to be under similar structures?
[11:26] <sil2100> 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] <Laney> The crontab line looks like:
[11:26] <Laney> for-project ubuntu cron.daily-live --live; SUBPROJECT=desktop-preinstalled for-project ubuntu cron.daily-preinstalled --live
[11:26] <sil2100> seb128: yeah, but the difference is that we build the desktop preinstalled image as daily-preinstalled ubuntu SUBPROJECT=desktop-preinstalled
[11:27] <sil2100> While canary is daily-live ubuntu SUBPROJECT=canary, where regular ubuntu images are also daily-live
[11:27] <seb128> so PROJECT=ubuntu and SUBPROJECT=desktop-preinstalled
[11:27] <sil2100> Since there's more than just PROJECT, ARCH, SUBPROJECT and SUBARCH - there's also image-type
[11:27] <seb128> hum
[11:28] <Laney> lol
[11:28] <seb128> so we could do cron.daily-canara with PROJECT=ubuntu and SUBPROJECT=canary?
[11:28] <Laney> this is quite complicated isn't it
[11:28] <seb128> cron.canary
[11:29] <sil2100> 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] <seb128> that feels more complex than it should be...
[11:30] <seb128> why can't we make $rightcode just append +${SUBPROJECT} to the artifact names
[11:30] <seb128> ?
[11:30] <sil2100> 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] <seb128> it's tedious and error prone though :/
[11:31] <sil2100> 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] <seb128> having to find all the places where there is a "if ubuntu" and add a |canary
[11:31] <seb128> easy to miss one
[11:32] <seb128> also code is ugly when it's name|othername|...
[11:32] <sil2100> 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] <sil2100> It *should* be possible, as mentioned we do something vaguely similar for ubuntu-server
[11:32] <seb128> k
[11:32] <seb128> I can try have a look but I don't know my way around enough for that
[11:33] <seb128> the SUBARCH thing seems easier but less clean :/
[11:33] <sil2100> Yeah, let me dive into this a bit today before the sprint load
[11:33] <seb128> k
[11:33] <sil2100> And let's sync up tomorrow/Wednesday again to get this done properly finally
[11:34] <seb128> 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] <seb128> that sounds great, thanks sil2100!
[11:35] <sil2100> 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] <seb128> 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] <seb128> then I can keep iterating locally
[11:36] <Laney> 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] <sil2100> Let me export those for you somewhere
[11:36] <seb128> until we sort out the project subproject vs subarch vs hacktype thing
[11:36] <seb128> sil2100, thx
[11:36] <sil2100> Laney: yeah, I was pushing it to a different directory for j_ibel in the past ;)
[11:37] <Laney> that's where it should be anyway
[11:40] <sil2100> seb128: ok, so it's still syncing, but I pushed it here: http://cdimage.ubuntu.com/ubuntu-canary/
[11:40] <sil2100> (with a datestamp of today)
[11:42] <seb128> sil2100, thanks!
[11:43] <sil2100> yw!
[12:17] <cpaelzer> 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] <seb128> cpaelzer, ah, thanks
[15:33] <cpaelzer> 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] <juliank> +1
[15:46] <doko> tseliot: 4.3.0-1build1ubuntu0.21.04 is a strange version, should be: 4.3.0-1ubuntu1
[15:48] <tseliot> 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] <doko> no, just for future uploads
[15:50] <doko> and yes, -1ubuntu1 is a higher version than -1build1
[16:34] <doko> coreycb: do we still need dnspython 1.6, or can we sync to 2.0?
[16:38] <coreycb> doko: upstream openstack is still locked in at 1.16.0 but I can dig deeper
[16:39] <vorlon> xnox: why do we need the usrmerge package?  Our implementation hasn't depended on this before now
[16:42] <coreycb> doko: looks like we need to stay <= 2.0.0 until this is fixed https://github.com/eventlet/eventlet/issues/619
[16:44] <doko> 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] <doko> coreycb: also the glance timeout: https://autopkgtest.ubuntu.com/packages/g/glance/hirsute/amd64
[16:55] <xnox> 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] <xnox> vorlon:  we should complete the transition for upgrades too, versus just the new installs.
[16:56] <xnox> vorlon:  on systems that have been installed with merged usr this should not have any effect.
[16:56] <vorlon> xnox: ok so this is the package that handles making symlinks on upgrade?
[16:56] <xnox> vorlon: yes.
[16:56] <vorlon> ok
[16:56] <xnox> vorlon:  but need to check that it doesn't screw up buildd tarballs.
[16:56] <xnox> vorlon: i'm never sure which seed is installed everywhere, but not in the buildd chroots.
[16:57] <xnox> cause through to 22.04 and including 22.04 our buildd tarballs must stay split-usr.
[16:58] <vorlon> oh?
[16:58] <coreycb> doko: I'm not sure but icey or I will take a look at those
[16:58] <xnox> pondering if usrmerge/autoconvert should be set to false in buildd tarballs.
[16:58] <xnox> vorlon:  i don't want to switch building things with merged-usr & handle upgrades at the same time.
[16:58] <vorlon> ah
[16:58] <xnox> vorlon:  or maybe it doesn't matter much, and should be done at the same time?
[16:58]  * xnox tries small steps
[17:00] <vorlon> xnox: it seems safe to me to do it in the same cycle
[17:01] <xnox> vorlon:  ok. let's try that then.
[17:03] <xnox> vorlon:  which packages become Essential: "yes" ?
[17:03] <xnox> i guess i did it now by doing it into required.
[17:04] <xnox> 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] <vorlon> xnox: no packages become Essential: yes
[17:04] <xnox> echo $(apt show tar | grep Essential) Essential: yes
[17:05] <vorlon> essential packages exist. no new packages become essential :)
[17:05] <xnox> is that on the fly calculation by apt?!
[17:05] <vorlon> no, that's declared in debian/control
[17:05] <xnox> ok, interesting.
[17:06] <xnox> minimal; mir; change debootstrap; then move to required i think is the right way to do it.
[17:16] <juliank> I want to upgrade to merged us
[17:16] <juliank> I want to upgrade to merged usr
[17:16] <xnox> juliank:  sudo apt install usrmerge
[17:16] <juliank> I have upgraded to merged usr
[17:16] <juliank> Now I need to find out why I have a dir /1:5.1+dfsg-4ubuntu1
[17:16] <juliank> with block-{curl,iscsi,rbd,ssh}.so
[17:16] <xnox> lolz
[17:16] <xnox> juliank:  some broken qemu-nbd install or some such?
[17:16] <xnox> qemu-utils has plugins.
[17:16] <juliank> hmm
[17:16] <xnox> like those
[17:16] <juliank> cpaelzer: ^
[17:16] <xnox> there was email from christian about broken qemu-gui i think, no?
[17:16] <juliank> cpaelzer: Was this you breaking too?
[17:16] <juliank> drwxr-xr-x   1 root root  102 Nov 30 11:50 1:5.1+dfsg-4ubuntu1
[17:16] <juliank> it installed this morning
[17:16] <juliank> 11:50 is the qemu-system-gui upgrade failure
[17:16] <juliank> or it's removal
[17:16] <juliank> who knows
[17:16] <juliank> $ find /foo/usr/share/ -type f
[17:16] <juliank> /foo/usr/share/doc/node-supports-color/changelog.Debian.gz
[17:16] <juliank> /foo/usr/share/doc/node-supports-color/copyright
[17:16] <juliank> /foo/usr/share/doc/node-supports-color/readme.md
[17:16] <juliank> /foo/usr/share/nodejs/supports-color/browser.js
[17:16] <juliank> /foo/usr/share/nodejs/supports-color/index.js
[17:16] <juliank> /foo/usr/share/nodejs/supports-color/package.json
[17:17] <juliank> system messy
[17:18] <juliank> maybe someone hacked my system
[17:18] <juliank> :D
[17:18] <juliank> Also /cryptroot dir, I don't know why that exists
[17:19] <xnox> maybe you did dpkg-deb -x *.deb foo/
[17:19] <xnox> and forgot you were root and in / ?
[17:19] <xnox> or like exitted a chroot
[17:19] <juliank> possible
[17:19] <juliank> :D
[17:19] <juliank> drwxr-xr-x   1 root root    0 Jul 23  2019 cryptroot
[17:19] <juliank> do I need that?!
[17:19] <juliank> let's just delete it
[17:20] <juliank> I still feel like I should move /home to /var/home
[17:20] <juliank> and /etc to /var/etc
[17:20] <juliank> have / be a tmpfs
[17:21] <juliank> and then mount / and /var
[17:21] <juliank> and then ofc, mount /usr read-only (and /)
[17:22] <juliank> oh yeah, /srv would move to /var/srv too
[17:22] <juliank> and I guess snap needs to be /var/snap
[17:33] <Laney> anyone know how to get the system to tell me if a device is being powered down for powersaving?
[17:34] <Laney> 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] <juliank> yup
[17:34] <juliank> Laney: install powertop, go to correct tab
[17:35] <juliank> "Tunables"
[17:35] <Laney> ooh powertop
[17:35] <juliank> I see the same thing, fwiw
[17:35] <juliank> I have not investigated why
[17:35] <juliank> I have not rebooted in 9 days
[17:35] <juliank> it started happening yesterday IIRC
[17:35] <Laney> well previously I hadn't since 2020-09-30, so there's quite a big delta :D
[17:35] <Laney> 9 days is better
[17:36] <Laney> same kernel for me fwiw
[17:36] <juliank> 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:39] <Laney> right turning off autosuspend seems to stop this from happening
[17:40] <Laney> did I lose some udev rule?
[17:40] <juliank> I want to know too
[17:40] <Laney> when I plug the receiver thing into my laptop, running groovy, that same device is "Bad" for autosuspend
[17:40] <Laney> it's "Good" on hirsute
[17:40] <juliank> ack
[17:41] <juliank> I have tlp installed, but I did not set up any blacklist in there
[17:41] <juliank> but this used to work
[17:41] <Laney> lemme see a bit more
[17:41] <juliank> # Note: input devices (usbhid) are excluded automatically
[17:41] <juliank> So I'm not sure what is setting usb autosuspend if it's not tlp
[18:19] <Laney> juliank: Try moving 60-libfprint-2.rules away please
[18:47] <ItzSwirlz> anybody wanna review Bug 1901344
[19:17] <doko> coreycb: the glance test now passes with some more oslo triggers. help on dnspython would be still appreciated
[19:17] <coreycb> doko: great, ok
[20:35] <mwhudson> doko: i was just trying to run the upstream tests with python3.9 and tox, nothing packaging related
[21:08] <coreycb> doko: dnspython seems ok so far running it locally: https://paste.ubuntu.com/p/FgXmscmr53/
[21:08] <coreycb> maybe that's not picking up python 3.9 (?)
[21:10] <coreycb> it's py3.9 "Testing with python3.9"