[07:53] <marinelli> morning everyone
[07:55] <marinelli> I noticed, after installing sudo (1.9.5p2-2ubuntu1) from hirsute-proposed that the uid/gid of all the files in the package are owned by buildd:buildd
[07:58] <marinelli> ...and it's not the only one. it seems that, since a bit, all the packages in the hirsute-proposed archive contains files owned by buildd:buildd (2001:2501)
[07:58] <marinelli> is it an expected result?
[07:59] <marinelli> I think not
[09:18] <ed_> hello, please can someone retry the build of rust-pleaser, it failed yesterday on arm64
[10:06] <cjwatson> ed_: done
[10:12] <ed_> thanks again cjwatson!
[10:29] <Laibsch> I understand this is #ubuntu-devel but I believe this is still the best place for the following question.
[10:29] <Laibsch> Bionic uses python2 by default, only focal switched to python3.  Yet, it is possible to use python3 as default on bionic.  Of course, one will run into issues here and there.  Quite often, they are easy enough to fix as in bug 1913408 or bug 1831306.
[10:30] <Laibsch> I very much care about the LTS user experience.  I don't think people ought to be forced to focal just yet if they want python3 as default.  And the issues are easy enough to fix by changing the shebang.  I see this similar to bashisms and changing the shebang from /bin/sh to /bin/bash to properly reflect the underlying assumptions.
[10:30] <Laibsch> Is this something that devs here would consider SRU-worthy?  Example of a debdiff: https://launchpadlibrarian.net/516149323/LP1831306.debdiff
[10:30] <xnox> Laibsch: no, there are no packages in bionic that make /usr/bin/python point at python3.
[10:31] <Laibsch> xnox: I understand, I just think that supporting this use case would be beneficial with no downside.
[10:31] <xnox> Laibsch:  we only completed transition to python2 shebang between bionic and focal and it was a lot of stuff.
[10:32] <xnox> Laibsch:  and any py2 self build packages will get the 'python' shebang in bionic, whereas in focal they get 'python2' shebang.
[10:32] <xnox> Laibsch:  it's a never ending whack-a-mole.
[10:32] <xnox> if anything backport to python3 is the way forward.
[10:32] <Laibsch> backporting what exactly?
[10:42] <cjwatson> It seems dangerous to encourage people to repoint /usr/bin/python to python3 on bionic when (a) that would involve manually touching stuff in /usr, and (b) there was no systematic effort in advance of the bionic release to make that work.  Some individual changes might be easy enough to fix in SRUs, but I think the overall goal is somewhat unwise.
[10:42] <cjwatson> (And I say this as somebody doing quite a bit of Python application development on pre-focal releases)
[10:44] <doko> agreed. the only safe way for that would be to get rid off *any* dependency in the archive on python and python-dev. plus anything in the archive that uses the unversioned shebang. and that's a lot of work
[10:44] <xnox> Laibsch:  in later releases squid-deb-proxy has been ported to python3.
[10:44] <xnox> Laibsch:  that's a change that is available in later releases, but falls out of scope for sru.
[10:45] <cjwatson> If I were still involved in approving SRUs then I probably wouldn't reject changes that switched to #! python2 if they came along with other fixes, but not sure if I'd think it worth the effort if they were on their own
[11:05] <Laibsch> Thanks, guys for the discussion.  I agree about the "not encouraging" part, there'd still be no guarantees.  FWIW, I am running python as python3 quite successfully for a while now, switched via the alternatives mechanism.
[11:05] <Laibsch> xnox: Ah, now I get it.  Well, that would be an awful lot of work and prone to introduce regressions.  Whereas changing the shebang to /usr/bin/python2 would simply reflect reality.  Thus, I considered it preferable.
[11:05] <Laibsch> cjwatson: I was proposing to do the work (whenever I run into those issues).  This is one of the examples of why I would love to have SRU privs so that it wouldn't involve a burden on others.
[11:05] <Laibsch> I've prepared several patches for squid-deb-proxy for example and they usually linger for years even if the package in the LTS is often completely unusable and the fix is minor and simple.  bug 1875110, bug 1733694 and bug 1505670 are the examples I found now that are still open.
[11:16] <rbasak> Laibsch: none of those are ready for sponsorshop. Someone needs to convert those into something suitable for upload.
[11:18] <rbasak> Laibsch: for users wanting to get Python 3 when they type "python", maybe a shell alias would be more suitable? Then users' wishes for shell default behaviour won't be conflated with script shebang expectations.
[11:22] <Laibsch> rbasak: I didn't mean to insinuate they were ready for sponsorship and SRU.  My bad.  I was simply showing that squid-deb-proxy has many other things worthy to SRU as cjwatson had indicated his consideration for changing the shebang as one-offs if accompanied by other fixes.
[11:23] <rbasak> Ah, OK
[11:23] <cjwatson> (but do note the "if I were still involved in approving SRUs", which I'm not)
[11:25] <rbasak> I'm not sure it's a good idea to start down the road of doing these in SRUs
[11:25] <Laibsch> rbasak: for most of those (and other) patches, I've been waiting for doko's comment as my python foo used to be not good enough and furthermore, I did not want to interfere with somebody else's package.
[11:25] <rbasak> I don't think I'd accept an SRU that includes such a change, without consensus having been reached first by Ubuntu developers more widely.
[11:26] <Laibsch> I switched to python3 a while ago when getting more seriously involved with the python language. I just wanted to make sure I wasn't going to pick up python2-isms along the line.  Maybe my attempt to make python3 the default on bionic has a better solution.  That's just the history.
[11:26] <Laibsch> rbasak: exactly. that's why I came here and it seems the consensus is "no".
[11:27] <rbasak> Laibsch: maybe just activate a venv by default for users or something?
[11:29] <Laibsch> rbasak: Thank you for trying to find other solutions.  I think people like me are still fairly rare and in the end focal has been out for almost a year.  I was simply trying to make Ubuntu more polished, but it seems other devs consider it undesirable.  I'll stick to my PPA.
[11:30] <Laibsch> I do still believe that in general LTS lack some love after release and I consider it a worthy goal.
[11:31] <rbasak> The trade-off is that we can't break users who expect things not to change.
[11:31] <rbasak> That's the point of an LTS, after all. People who want change can use the latest release.
[11:32] <rbasak> Of course the problem comes when users want some things to change but not others. But they all want different sets of things to change and to stay still.
[11:35]  * juliank explained that all week(s?) ago
[11:35] <Laibsch> That's the general trade-off in SRU.  But that's why I thought this was such an obvious thing to do because a) it would improve the situation for a (probably small) subset of users while leaving everything more or less exactly the same for everybody else (#!/usr/bin/pyton and #!/usr/bin/python2 are essentially equivalent in a default bionic install).
[11:37] <juliank> (1) /usr/bin/python in focal is /usr/bin/python2, changing that is not supported, it will break shit
[11:37] <juliank> (2) we allow you to pick that in later versions with python-is-python{2,3} - considerable effort has gone into planning that transition
[11:38] <juliank> um, s/focal/bionic/ I suppose
[11:39] <juliank> Laibsch: Please stop filing bugs about this, we're not going to backport the transition to bionic, everything is working correctly.
[11:40] <rbasak> Laibsch: basically, https://xkcd.com/1172/. Even if you ensure that everything will be done right in the archive if people are using Ubuntu "properly", some users will still end up being broken somehow.
[11:41] <rbasak> People prefer the LTS because we try not to break their workflows regardless of whether they're doing things "correctly" or not.
[11:42] <rbasak> It's also a ton of review work to make sure that things won't break, and I'd prefer to spend that effort looking forward, not backward.
[11:42] <rbasak> Users who care enough can just upgrade to 20.04.
[11:42] <rbasak> 18.04 is for people who don't want to change and don't want new things.
[11:43] <rbasak> Eventually it won't matter anyway, and everyone will have Python 3 "by default" (I hate that term; it's really ambiguous).
[11:45] <juliank> Also saying "we have backported python-is-python3" to bionic means that now every third party is potentially broken because they expect python to point at python2 as it has for the past 3 years, and not suddenly python3 to be a valid option.
[11:46] <rbasak> For example, a user might have installed Python from upstream source in a way that didn't install /usr/bin/python2. Their system is broken, but maybe their workflow works because the stuff that they care about happens to be using /usr/bin/python. Switching the shebang of something they use to python2 would break them.
[11:47] <juliank> It's also the wrong question to ask "what could go wrong?"
[11:47] <juliank> the right question to ask is "does it change anything on a supported system?" and the answer is "no, python always points to python2, both are in the same package."
[11:47] <rbasak> Also, just because we can't think of a specific issue that could go wrong doesn't mean that it doesn't exist. See all the previous regressions we've had to deal with :)
[11:49] <cjwatson> I do think we'd probably serve users of Python 3 on bionic best by advising them to use virtualenvs for most things - mainly because they may very well also want more recent library versions
[11:49] <cjwatson> A pretty large number of serious Python users swear by virtualenvs anyway, so it wouldn't be swimming against the tide
[11:50] <juliank> These things are high risk though
[11:50] <juliank> a wild maze of untrusted dependencies :D
[11:50] <rbasak> Maybe we don't care about such users. But I don't think I could justify breaking them by saying "oh we were trying to make it so that /usr/bin/python could be Python 3 for users who wanted to add that feature to Bionic; sucks to be you". Because those users would rightfully say that we're breaking expectations about LTS stability there.
[11:51] <rbasak> OTOH, breaking a user by saying "we were trying to fix bug A" or "we were fixing security issue B" is much more acceptable even if A and B aren't use cases for that user.
[11:52] <juliank> this is feature work, plain and simple
[11:53] <rbasak> Along these lines, imagine if users were regressed and we wrote up a post mortem. Would it appear reasonable? For this feature change, I don't think it would.
[13:19] <rbasak> Quick poll please. How do Ubuntu developers get from a source tree to an upload? dpkg-source? dpkg-buildpackage? debuild? sbuild? Something else?
[13:19] <Laney> debuild or gbp buildpackage or bzr bd depending on what the package is using
[13:29] <rbasak> Thanks! Anyone else please?
[13:41] <slyon> debuild
[13:48] <RikMills> rbasak: for KDE things, a custom gbp implementation from https://launchpad.net/ka/
[13:48] <apw> rbasak, dpkg-buildpackage -nc -S (typically)
[13:48] <RikMills> otherwise, mostly debuild
[13:56] <xnox> rbasak:  debuild -S -d -nc -vCORRECT + dput _source.changes
[13:56] <xnox> sometimes -sa too if needed
[14:06] <cjwatson> debuild -S, adding -nc if I'm confident the tree is clean
[14:08] <cpaelzer> Laney: hi you said on 1915126 that you could reproduce it, I was trying last week and it didn't for me
[14:08] <cpaelzer> Laney: I retried today and it worked fine again
[14:08] <cpaelzer> Laney: I wanted to check what options differ between our calls
[14:08] <cpaelzer> atm I used this
[14:08] <cpaelzer> autopkgtest --no-built-binaries --apt-upgrade --testname=systemd-fsckd --setup-commands setup-testbed --shell systemd_247.3-1ubuntu2.dsc -- ssh -s nova -- --flavor m1.small --image ubuntu/ubuntu-hirsute-daily-amd64-server-20201126-disk1.img --keyname paelzer_canonistack-bos01
[14:09] <cpaelzer> From your log output I see that you ran all tests.
[14:09] <cpaelzer> might I ask what else differs in your case ?
[14:46] <cjwatson> I'm reflashing LP's riscv64 builders; mostly to clean up some junk that had accumulated on their filesystems, but this also has the effect of upgrading from Linux 5.4 to 5.8
[14:58] <cjwatson> doko (maybe): Am I right in thinking that https://launchpad.net/~ubuntu-security-proposed/+archive/ubuntu/ppa/+build/20946067 and https://launchpad.net/~ubuntu-security-proposed/+archive/ubuntu/ppa/+build/20946074 are probably stuck and should be cancelled?
[15:01] <doko> ohh fun, yes, of course. cancelled
[15:02] <cjwatson> Thanks
[15:03] <cjwatson> Still one remaining job on the 061..090 half of riscv64, but it looks maybe legit - https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/4447/+build/21033216
[15:03] <Laney> cpaelzer: The entire commandline should be at the top of my log
[15:03] <Laney> Nothing else that differs
[15:03] <cjwatson> Last successful build in the primary archive took 18 hours or so
[15:04] <cpaelzer> sil2100: you updated https://bugs.launchpad.net/ubuntu/+source/needrestart/+bug/1907422 - but things are still in incomplete status
[15:04] <cpaelzer> sil2100: once you think all pre-reqs froa MIR evaluation are complete please set it back to "new" state on the tasks
[15:04] <cpaelzer> otherwise it won't be seen on the MIR team meetings where we assign those
[15:09] <Laney> cpaelzer: I run it like I did because that is basically how it is run in reality, so I suggest people trying to fix it start there and don't change other options
[15:12] <cpaelzer> Laney: you didn't post how you started it and trying to behave more like the real thing is exactly why I asked you
[15:13] <cpaelzer> maybe you have the commands you used in the tarball that you attached and therefore think I'd know ... let me check
[15:14] <Laney> cpaelzer: It's always in autopkgtest logs, yeah, sorry I guess I assumed people reading would know that
[15:14] <cpaelzer> ok found it
[15:14] <cpaelzer> thanks Laney
[15:14] <cpaelzer> and I'm not the bad guy on this, just trying to help as my package is indirectly blocked by this :-)
[15:15] <Laney> faulty assumption!
[15:17] <cpaelzer> oh I am the bad guy ?
[15:17] <cpaelzer> then sorry I didn't realize
[15:17] <cpaelzer> *sniff*
[15:19] <Laney> hopefully nobody is the bad guy :p
[15:19] <cpaelzer> oh ok, /me reset expectation and interpetation of this conversation then :-)
[15:23] <marinelli> hi everyone, I asked for a thing about uid:gid in hirsute-proposed packages
[15:23] <marinelli> ...but I was disconnected from the channel :)
[15:24] <RikMills> a thing?
[15:25] <RikMills> anyway, that issue is known and a fix in progress
[15:25] <marinelli> ah, ok
[15:25] <marinelli> just to know if you noticed it
[15:25] <marinelli> perfect
[15:25] <RikMills> just a tad
[15:25] <marinelli> ...and thanks
[15:26] <RikMills> LP: #1915250
[15:27] <RikMills> though more than shared libs to be fair
[15:28] <marinelli> yes more than that
[15:31] <marinelli> for example, if I just look for files without owner or group (eg: using find and the query \( -nouser -or -nogroup \)) in /usr/, and then I look for the packages from which those files belong, I found different (source) packages like ssh, psmisc, apport, xz-utils, and so on
[15:33] <marinelli> anyway... I think it's not helpful to report all the packages, it would be simply faster to iterate with dpkg/grep all over the packages storage
[15:35] <marinelli> thanks
[15:35] <cjwatson> marinelli: I believe that's the plan, yes
[15:39] <sil2100> cpaelzer: still working on it
[15:40] <sil2100> cpaelzer: this is why it's 'Incomplete' still, why did you start looking at it already? ;)
[15:41] <sil2100> I'm still digging, will set it to New once it's ready indeed
[15:42] <sil2100> Thanks o/
[15:59] <cpaelzer> sil2100: I didn't start looing :-)
[15:59] <cpaelzer> sil2100: but recently we had a few cases were people were not aware they'd need to set it back to new to enter our queue
[15:59] <cpaelzer> so I thought I help with a ping
[16:33] <sil2100> cpaelzer: thanks for reaching out then! I read the new MIR page since I saw there were changes - I really like how formatted it is right now btw.!
[16:34] <cpaelzer> thanks, and further feedback for changes is always welcome
[16:34] <sil2100> I don't remember it being so thorough in the past
[16:34] <cpaelzer> it wasn't :-)
[16:40] <Laney> that state diagram has go to be one of the more pleasing things on the wiki
[17:04] <ItzSwirlz> rbasak: The cinnamon verification for focal and groovy is done, awaiting for screensaver to be sponsored
[17:23] <rbasak> ItzSwirlz: FWIW, it's already sponsored but is awaiting SRU review (by someone other than me)
[17:24] <rbasak> I checked earlier that I hadn't forgotten to upload it ;)
[17:54] <cjwatson> Full set of riscv64 builders back just in time for a flood of builds to hit them ;-)
[18:22] <xnox> wonderful timing =)
[21:10] <ItzSwirlz> oh, lol
[21:16] <xnox> vorlon:  https://bugs.launchpad.net/ubuntu/+source/sl-modem/+bug/1915878 thought on this?
[21:16] <xnox> vorlon:  not sure if we still need the userspace package; the kernel driver; ubuntu-drivers integration
[21:16] <xnox> vorlon: ideally drop all three, dropping ubuntu-drivers will make ubuntu-drivers not depend on alsa-utils
[21:16] <xnox> which is nice for server
[22:39] <Odd_Bloke> vorlon: Realised you likely didn't get a notification for my reply on https://bugs.launchpad.net/cloud-init/+bug/1915077 so (not at all urgent) ping.
[23:38] <JawnSmith> Is any core dev available to restart the systemd autopkgtests that are blocking acl from migrating? The new systemd in -proposed should resolve the failures
[23:57] <bdmurray> I'm doing this