[00:53] <themill> cjwatson: it is indeed the backports for launchpad that I was thinking about there ;)
[00:54] <cjwatson> themill: In that case 2.7/3.5 are our current minima
[00:55] <themill> and it sounds like 2.7 is needed for the time being there too
[00:55] <themill> I assume launchpad hasn't rewritten itself in python 3 yet ;)
[00:55] <cjwatson> themill: Yeah.  I mean if you were to ditch 2.7 I'd understand and you wouldn't be the first, but it would probably entail some more transitional work on our end
[00:55] <cjwatson> themill: As I say, we're working on it but it's a fairly giant job
[00:56] <cjwatson> You would probably not be amazed by how many yaks can show up to suddenly need shaving when you're trying to port a million-line codebase
[00:56] <themill> :)
[00:57] <themill> Are there new things that you'd like to have appear in python-debian at this stage for the migration, or is sticking with what you've got for the time being reasonable?
[00:57] <cjwatson> We have no immediate needs there that I know of
[00:59] <themill> I suspect that I'm going to struggle to run the test suite against python2.7 reasonably soon and so even if we don't start ripping out the "if six.PY2" code, we'll end up accidentally breaking things soon enough
[00:59] <themill> There presumably is a way of running things in gitlab-ci against two different docker images, but I'm yet to find it
[01:00] <cjwatson> (I made a bit more progress on the port this weekend.  A particular pile of test failures turn out to be fixed in zope.security 5.1.0.  Upgrading Zope dependencies is usually best done by upgrading to new commits from github:zopefoundation/zopetoolkit, since that way at least the whole set has been tested together.  So I try that, and so far I've had to fix failures due to zope.interface now ...
[01:00] <cjwatson> ... disallowing assignment to __module__ on interfaces, a semantic change somewhere in transaction affecting after-commit hooks, and there's some other weird problem that may require finishing the work to move away from system-site-packages.  This is not an atypical experience.)
[01:00] <cjwatson> Right, if you drop it and we turn out to need some new feature then we'll probably just have to backport it for now.
[01:00] <cjwatson> I don't think that'll be a huge deal.
[01:01] <themill> I'm keen to make it easy for you to contribute things though, particularly since as you port and refactor you'll probably spot things :)
[01:07] <cjwatson> I think python-debian is probably one of the least of my worries TBH - we might indeed spot the odd thing, but Launchpad's use of it isn't all that exotic really.
[01:07] <cjwatson> Most of the problems there are likely to be just tedious bytes/text stuff on our end.
[01:08] <themill> yes, I know the dance
[01:09] <themill> I have a local branch in which I've sprinkled a lot more type annotations through python-debian and that has helped shake out some byte/str mistakes
[01:10] <cjwatson> I don't currently recall how many python-debian-related tests manage to run in https://git.launchpad.net/~cjwatson/launchpad/log/?h=py3
[01:13] <themill> I was looking at some other polyglot code bases recently and contemplating that the next thing to do is to migrate from six to Python 3 code... ;(
[01:13] <cjwatson> Anyway.  Hopefully a fair bit more progress over the next few months, now that we're over the "make it possible to start up the test suite at all" hump.
[01:14] <cjwatson> (To get that far you need most of the codebase and more significantly most of your dependencies to be at least minimally syntactically compatible, which is more effort than you might think in a big codebase.)
=== krytarik is now known as kryten
[06:20] <jphilips> hi all. a tester tried to install gtk-recordmydesktop, but it is set as a conflict to recordmydesktop, likely as python-gtk2 isnt in the repo. is there any intention to resolve this issue for 20.04 so there is a GUI version of the app.
[06:20] <jphilips> https://bugs.launchpad.net/ubuntu/+source/gtk-recordmydesktop/+bug/1872406
[06:20] <ubottu> Launchpad bug 1872406 in gtk-recordmydesktop (Ubuntu) "package not available in 20.04" [Undecided,New]
[06:23] <kryten> https://launchpad.net/ubuntu/+source/gtk-recordmydesktop/+publishinghistory - as per here, deleted from Focal because of Debian #943983.
[06:23] <ubottu> Debian bug 943983 in ftp.debian.org "RM: gtk-recordmydesktop -- RoQA; dead upstream, unmaintained, depends on legacy libs" [Normal,Open] http://bugs.debian.org/943983
[06:28] <jphilips> thanks kryten
[09:54] <frechdachs69> is the 20.04 netboot installation going to support the new autoinstall mechanism, too?
[10:34] <AsciiWolf> https://bugs.launchpad.net/ubuntu/+source/gnome-shell/+bug/1872434 - looks like one bad looking gnome-shell regression made it into Focal :/
[10:34] <ubottu> Launchpad bug 1872434 in gnome-shell (Ubuntu) "Utilities folder labeled as "X-GNOME-Utilities.directory" on Ubuntu 20.04" [Undecided,New]
[10:42] <AsciiWolf> kenvandine, hi, I have tried the new snapd build (2.44.3+20.04) that is in proposed, but classic Ubuntu packages still do not show in Snap Store, only snaps
[10:42] <AsciiWolf> kenvandine, see: https://imgur.com/5hibN56
[10:46] <AsciiWolf> kenvandine, (I have latest Snap Store from latest/stable/ubuntu-20.04)
[11:52] <kanashiro> thanks Unit193
[13:14] <kenvandine> AsciiWolf: what does "snap version" say?
[14:12] <ahasenack> tjaalton: hi, I'm trying to come up with a test case for apache tlsv1.3 POST pha with tls1.3 (so many acronyms!): https://pastebin.ubuntu.com/p/hVZJQMZ7PW/
[14:12] <ahasenack> tjaalton: I'm not sure I'm triggering all the right bits, as this message isn't logged:
[14:12] <ahasenack>                 ap_log_rerror(APLOG_MARK, APLOG_ERR, 0, r, APLOGNO(10228)
[14:12] <ahasenack>                               "could not buffer message body to allow "
[14:12] <ahasenack>                               "TLS Post-Handshake Authentication to proceed");
[14:13] <ahasenack> I thought I could be needing a bigger body to post, but I tried with an attachment of 10Mb and surprisingly it then works even without the patch
[14:14] <ahasenack> ah,
[14:14] <ahasenack> ./modules/ssl/ssl_private.h:#define DEFAULT_RENEG_BUFFER_SIZE (128 * 1024)
[14:14] <ahasenack> still
[14:26] <frechdachs69> is the 20.04 netboot installation going to support the new autoinstall mechanism, too?
[14:33] <ahasenack> aha, got it
[14:34] <santa_> hello everyone
[14:35] <santa_> rbalint: if I can steal you a few minutes I would like to tell you about an issue with the systemd packaging and virtualbox
[14:35] <ahasenack> frechdachs69: hi, I think so, did you check https://discourse.ubuntu.com/t/please-test-autoinstalls-for-20-04/15250/1 ?
[14:35] <ahasenack> "I’d be especially interested in tests on real hardware (possibly in conjunction with netboot)"
[14:36] <santa_> rbalint: after this change https://salsa.debian.org/systemd-team/systemd/-/merge_requests/61/diffs?commit_id=d6483013d5779d4d465a1e174e44a754b941d0e6 it's impossible to install virtualbox-guest-utils inside a virtualbox VM, this way it's no longer possible to use some virtualbox features such as shared folders
[14:38] <santa_> rbalint: so what would be the solution for this. should virtualbox-guest-utils provide the virtual package 'time-daemon'?
=== ijohnson is now known as ijohnson|lunch
=== ijohnson|lunch is now known as ijohnson
[19:08] <ganso> vorlon: Hello! I've been working on a bug in nfs-utils and found the fix in the code upstream, I'm working on doing a SRU for it right now, but I noticed running "rmadison nfs-utils" that all packages since bionic are using 1.3.4 code base. I saw that debian has this same version pinned so I realized this is likely the reason ubuntu's version is also pinned, but I'm wondering what is the specific reason for debian to not update the version, if any. If
[19:08] <ganso> there is a special bug, or a major breaking change >1.3.4, etc. Do you know the reason it hasn't been updated past 1.3.4?
[19:20] <mwhudson> good morning
[19:29] <ahasenack> ganso: you would have to ask the debian team or maintainer about that
[19:30] <ahasenack> ganso: what is the latest upstream version? Maybe upstream changed owner, and debian isn't following the new owner?
[19:30] <ahasenack> I've seen that happen before
[19:31] <ganso> ahasenack: vorlon is one of the maintainers, src: https://packages.debian.org/source/sid/nfs-utils
[19:32] <ganso> ahasenack: latest upstream version is 2.4.3
[19:32] <ahasenack> check if the homepage in d/control points to the same place where you saw this 2.4.3 being available
[19:34] <cjwatson> ahasenack: This is easily checkable - go to https://tracker.debian.org/pkg/nfs-utils, right at the top it says "A new upstream version is available: 2.4.3", so the metadata clearly points in the right direction
[19:34] <ahasenack> indeed
[19:34] <cjwatson> https://bugs.debian.org/917706 and https://bugs.debian.org/952446 already exist
[19:34] <ubottu> Debian bug 917706 in src:nfs-utils "nfs-utils: New upstream release available" [Wishlist,Open]
[19:34] <ubottu> Debian bug 952446 in src:nfs-utils "nfs-utils: Please update to latest nfs-utils" [Wishlist,Open]
[19:35] <cjwatson> (I know nothing about it; I would assume it's difficult for some reason ...)
[19:36] <ganso> yup, I saw those entries, however there is no response and I am wondering if there is a specific issue that prevents it from being updated
=== gusnan_ is now known as gusnan
=== gusnan is now known as Guest33985
=== Guest33985 is now known as gusnan
[21:32] <AsciiWolf> kenvandine, sorry, I was away... the snap version command returns this: https://pastebin.com/gVY4TAJM
=== housecat is now known as dax
[21:47] <kenvandine> AsciiWolf: can you please pastebin /var/lib/snapd/apparmor/profiles/snap.snap-store.ubuntu-software
[22:19] <RikMills> LP: #1872551
[22:19] <ubottu> Launchpad bug 1872551 in software-properties (Ubuntu) "kubuntu-driver-manager: nvidia driver version switch fails" [Undecided,New] https://launchpad.net/bugs/1872551
[22:20] <RikMills> SoftwarePropertiesQt.py", line 895, in on_driver_changes_apply
[22:20] <RikMills>     for dep in get_dependencies(self.apt_cache, pkg.shortname, 'nvidia'):
[22:20] <RikMills> NameError: name 'get_dependencies' is not defined
[22:20] <RikMills> juliank: that is something in python-apt?
[23:05] <chiluk> what's the name of the installer that isn't ubiquity (?debian-installer?).. Also is there a way to specify to use debian-installer instead of ubiquity when using the desktop image?  I'm basically needing to do a dual boot 18.04+20.04 with encrypted roots and homes on a smallish drive.  So Im' having to be creative with partitioning and the 18.04 ubiquity leaves a bit to be desired *(20.04 ubiquity is vastly improved)
[23:08] <sarnold> subiquity?
[23:08] <sarnold> there is a debian-installer, but I'm not sure if we've made discs with it for 20.04 or not
[23:09] <RAOF> Is the netinst image still d-i?
[23:10] <sarnold> oh good question
[23:11] <chiluk> yeah I'm using the netinst on 18.04, but I thought I remember seeing a kernel command line arg that could be passed to force the desktop image to use d-i
[23:11] <sarnold> chiluk: there's also using debootstrap to install a skeleton of a system into a directory; you're a long way from a working system with that starting point, but if you've already got 20.04 booting and working okay, it might be tolerable to get the rest of the way
[23:12] <chiluk> you are a glutton for punishment..
[23:12] <sarnold> why yes, that is how I installed my current laptop..
[23:12] <chiluk> I think I'll stick with the netinst if no one knows the correct kernel command-line-fu to launch in text/di mode
[23:13] <chiluk> this really only applies to 18.04 as 20.04 worked like a champ last I checked.
[23:40] <chiluk> anyhow thanks folks...
[23:40] <sarnold> see ya chiluk :)
[23:44] <chiluk> good to see you too sarnold!
[23:45] <sarnold> chiluk: yeah, nice to see your name around again :)
[23:45] <chiluk> I'll put messing with the ubuntu installer encryption options on my "if I ever have time I might want to mess with this list"
[23:45] <sarnold> heh, my version of that list is sooo long..
[23:45] <chiluk> tell me bout it.