[01:57] <xnox> mwhudson:  which one of the casper bugs?
[01:57] <mwhudson> xnox: i meant https://bugs.launchpad.net/ubuntu/+source/casper/+bug/1867065 but i've tried to reproduce now
[01:57] <ubottu> Launchpad bug 1867065 in casper (Ubuntu) "Installer hangs at boot on machine" [Critical,Confirmed]
[01:58] <mwhudson> xnox: i do think that checking md5sums by default maybe be a bad experience over usb2...
[01:58] <xnox> mwhudson:  it actually is this https://bugs.launchpad.net/ubuntu/+source/plymouth/+bug/1867130
[01:58] <ubottu> Launchpad bug 1867130 in plymouth (Ubuntu) "spinner theme doesn't support fckd progress messages" [High,Confirmed]
[01:58] <xnox> mwhudson:  it was beautiful with ubuntu-logo theme, but it is not with spinner, because regressions.
[01:58] <mwhudson> xnox: ah
[01:58] <xnox> mwhudson:  i have action to look at all other regressions too
[01:59] <mwhudson> xnox: cool!
[01:59] <xnox> mwhudson:  the top 4 bugs on https://bugs.launchpad.net/ubuntu/+source/plymouth/+bugs?orderby=-id&start=0
[05:31] <alkisg> Hi, running pam-auth-update regenerates /var/cache/debconf/templates.{dat,dat-old} with NO changes and this wastes 34 MB RAM in live boots like LTSP or casper
[05:31] <alkisg> This was reported in LP bug #43706, but it was never resolved properly, only worked-around
[05:31] <alkisg> Should I report a bug in debconf and/or pam, or is it by design and I should just apply a workaround in LTSP?
[05:31] <ubottu> Launchpad bug 43706 in casper (Ubuntu) "Excessive memory usage on live CD" [Low,Fix released] https://launchpad.net/bugs/43706
[06:53] <rbasak> alkisg: sounds to me that you're reporting something different from what was fixed in bug 43706.
[06:53] <ubottu> bug 43706 in casper (Ubuntu) "Excessive memory usage on live CD" [Low,Fix released] https://launchpad.net/bugs/43706
[06:53] <alkisg> rbasak: "we're also storing two copies of them (templates.dat and templates.dat-old). "
[06:54] <alkisg> That bug has 3 subissues, I'm talking about that one
[06:54] <rbasak> alkisg: the bug says that was fixed by removing dat-old?
[06:54] <rbasak> alkisg: I suggest that you start by filing a new bug that covers only one issue
[06:54] <rbasak> alkisg: but also, please suggest a patch!
[06:55] <alkisg> rbasak: right, while cjwatson was planning to see why the template was being written in the first place, that plan got aborted and a simple workaround "rm" was implemented, to save half the space (the copy, not the original .dat which also takes tmpfs space)
[06:56] <alkisg> rbasak: but is it considered a bug? If debconf is supposed to rewrite the database even when there are no changes, then... it's not a bug, it's a "feature", and I only need to do a similar workaround in ltsp
[06:56] <rbasak> It sounds like a valid unfortunate interaction in your use case
[06:57] <rbasak> In general, people are willing to consider changing design when these things happen
[06:57] <rbasak> Depending on the implications involved
[06:57] <rbasak> The only way to find out is to file a bug with an explanation and a concrete proposal to change it, and see what happens, IMHO.
[06:58] <rbasak> This is just speaking from experience in working in our ecosystem. I can't speak for casper/pam-auth-update/debconf.
[06:59] <alkisg> To phrase is at a small question/issue: "Running pam-auth-update regenerates /var/cache/debconf/templates.dat with no changed content. Should I report this as a bug, and where?"
[06:59] <alkisg> If this will be accepted as a valid issue, then sure I could spend a few days and try to pin point it
[07:00] <alkisg> But spending a few days to get "nah it's by design" isn't a good investment of time; so I was just looking for an initial yes/no answer from someone with more debconf knowledge than me
[07:00] <rbasak> I think it's a perfectly valid question.
[07:01] <rbasak> Without knowing the internals it sounds like a reasonable thing to be changed.
[07:01] <alkisg> Thank you, I'll start by reporting it to launchpad/debconf
[07:01] <rbasak> I wouldn't know if it's pam-auth-update or debconf without reminding myself of the debconf shell API again.
[07:02] <alkisg> From what I see, pam-auth-update just opens/closes debconf, it doesn't have much control over it
[07:02] <alkisg> So just by a tiny first look, I think it's debconf, not pam
[07:02] <rbasak> Then I agree that debconf would be a good place to start. It can always be changed.
[07:08] <alkisg> Reported LP bug #1867315
[07:08] <ubottu> Launchpad bug 1867315 in debconf (Ubuntu) "templates.dat is regenerated even without changes" [Undecided,New] https://launchpad.net/bugs/1867315
[07:09] <rbasak> Thanks!
[07:09] <alkisg> Thank you too, as always :)
[07:13] <rbasak> alkisg: looks like https://git.launchpad.net/ubuntu/+source/debconf/tree/Debconf/DbDriver/File.pm might be the right place to fix this maybe?
[07:14] <alkisg> rbasak: yes, editing that file bypasses the issue
[07:14] <alkisg> I think somehow the dirty flag is set while it shouldn't
[07:14] <rbasak> That looks like a valid bug then
[07:15] <alkisg> I'm not even sure if templates.dat should be "Readonly" by debconf or not... are postinst programs supposed to write there, or is it extracted by some external script...
[07:15] <alkisg> If I set it to Readonly, again problem solved, but I've no idea if it's a valid approach
[07:15] <alkisg> In /etc/debconf.conf
[07:16] <rbasak> New templates would get added as new packages are installed, I guess?
[07:16] <rbasak> So speaking system-wide, having it read-only would be wrong I think.
[07:16] <alkisg> Yes, but does debconf handle that as part of opening/closing it, or an external tool (like update-initramfs) is supposed to regenerate everything? Dunno
[07:16]  * rbasak isn't sure
[07:17] <alkisg> It feels weird if any program that calls debconf open templates in write mode
[07:17] <rbasak> Now you appear to have two bugs :-)
=== pieq_ is now known as pieq
[10:58] <xnox> cjwatson:  we have some broken XB-Cnf-* metadata on a few binary packages across a few releases, and the packages in question are expensive to SRU (python2.7 python-defaults python3.6 python3-defaults python3.7 python3.8) and some of them have no outstanding plans to SRU. Are there any archive publishing side that I could fix? I.e. something like priority-override, but arbitrary header override? Or for
[10:58] <xnox> example could I do some custom cases in the command-not-found-extractor?
[10:59] <xnox> mvo is not in the channel. Can't remember who else touched cnf-extractor, maybe Laney?
[11:02] <Laney> well I do have access to the thing
[11:02] <Laney> but it's probably more of an mvo question
[11:17] <cjwatson> xnox: If they're wrong in the release pocket, then we pretty much just have to deal with that anyway, since we aren't going to republish release pockets for reasons short of legal threats
[11:18] <cjwatson> xnox: The extractor supplies Commands-* files on the side, but I don't believe it does other fields (ICBW).  There's no arbitrary field override mechanism
[11:19] <xnox> Thank you! this is very useful.
[11:19] <xnox> Yeah, i need to drop headers & add headers, i guess SRU it is.
[12:53] <ahasenack> cpaelzer: rbasak rafaeldtinoco: ok to sync postfix.3.4.10-1? diff: https://paste.ubuntu.com/p/43Cw8dNth9/
[12:53] <ahasenack> upstream release notes: http://www.postfix.org/announcements/postfix-3.4.10.html
[13:17] <rafaeldtinoco> ahasenack: /me checks
[13:19] <cpaelzer> damn you beat me by a minute rafaeldtinoco :-)
[13:20] <rafaeldtinoco> hihi
[13:20] <cpaelzer> ok 2
[13:21] <rafaeldtinoco> ahasenack: +1
[13:21] <ahasenack> thx
[13:21] <ahasenack> well, you both can look
[13:21] <ahasenack> I don't mind
[13:22] <ahasenack> any concerns cpaelzer ?
[13:22] <ahasenack> other than the current breakage in focal I assume?
[13:22] <ahasenack> debian ci hasn't run it yet
[13:30] <cpaelzer> ahasenack: I haven't looked at it since rafaeldtinoco did
[13:30] <cpaelzer> if you want me to I can ...
[13:47] <ahasenack> thanks, synced
[14:38] <coreycb> jamespage: I'd like to bump pyroute2 from 0.5.7 to 0.5.9. there are a lot of updates in 0.5.9, and while it's not specifically an openstack dep it is mostly an openstack dep. hard to tell if it is just a bug-fix release.
[14:39] <coreycb> anyway that is what openstack ussuri currently has for upper-constraints
[15:32] <mpt> Anyone know where I could find a browsable list of all Universe packages in 16.10 LTS? <https://packages.ubuntu.com/xenial/> lists them by pocket and by Section, but not by repo
[15:34] <marcoagpinto> mpt: 16.10 isn't LTS
[15:34] <marcoagpinto> only 16.04
[15:34] <marcoagpinto> only .04 versions are LTS
[15:34] <mpt> Sorry, 16.04 LTS, you’re quite right
[15:39] <mpt> I don’t see a list of them at <https://launchpad.net/ubuntu/xenial> either
[15:42] <coreycb> hello release team, I've uploaded a new point release for python-pyroute2. it's mostly an openstack dependency (dhcpcanon and pathspider are not openstack) and gets us up to the desired upper-constraint version that neutron etc need.
[18:04] <pyusr> hmm... maybe python should define an /usr/bin/python2_or_3 so  scripts that do "#!/usr/bin/env python" like poetry, can work on systems that don't have python 2 by default (like new ubuntu versions) ?
[18:06] <cjwatson> pyusr: https://lists.ubuntu.com/archives/ubuntu-devel/2020-February/040918.html
[18:06] <pyusr> can anybody move along this SRU ? https://bugs.launchpad.net/ubuntu/+source/python-pip/+bug/1864766
[18:06] <ubottu> Launchpad bug 1864766 in python-pip (Ubuntu Xenial) "[SRU] pip in xenial is installing packages incompatible with Python 2.7 (and those are becoming common)" [Medium,In progress]
[18:11] <pyusr> nice, but I'm ont sure what happens, if today in focal I run something with "#!/usr/bin/env python" what will happen by default ?
[18:13] <cjwatson> my understanding is that focal deliberately doesn't have /usr/bin/python for a while in order to shake out issues
[18:13] <cjwatson> but this is only second-hand.  you can try it yourself
[18:15] <pyusr> don't have it, but I'm wondering what about thousands of scripts like this that will stop working: https://python-poetry.org/docs/
[18:15] <pyusr> tons of workflows will be broken
[18:16] <pyusr> (stuff outside the apt echo system)
[18:16] <cjwatson> OK, I'm out of here, have told you everything I can
[18:46] <smoser> pyusr: python2or3
[18:46] <smoser>  https://gist.github.com/smoser/8904199bb8f00a90dd04
[18:47] <pyusr> that script exists in ubuntu 20.4?
[18:48] <smoser> no. but it could.
[18:48] <smoser> but as you can see... referenced is 14.04
[18:48] <smoser> the right answer, imho, in 2020 is to not have /usr/bin/python
[18:48] <pyusr> and what about the thounsands of workflows outside of the apt ecosystem which will stop working?
[18:49] <smoser> and it seems honestly wrong to me, and just silly to have /usr/bin/python be python3
[18:49] <pyusr> I tried following this today, and ofcourse it borked... https://python-poetry.org/docs/
[18:49] <pyusr> everyscript that has #!/usr/bin/env python will stop working
[18:50] <smoser> well, imo those things asked to be interpreted by python2
[18:50] <pyusr> poetry as you can see in that page supports both 2 and 3
[18:50] <smoser> and trying to execute them through python3 is not right.
[18:50] <pyusr> you are wrong
[18:50] <pyusr> tons of stuff support both
[18:50] <pyusr> and #!/usr/bin/env isn't expressive enough for that
[18:51] <pyusr> again, check that, one of the biggest packages
[18:52] <smoser> pyusr the biggest argument i have for breaking 'python' is to avoid the same problem in 6 years with python4
[18:52] <smoser> the python community learned nothing from the same thing that happend to perl between perl4 and perl5
[18:52] <pyusr> yeah, so didn't ubuntu, it's already 2 month that ubuntu 16.04 (which is still LTS supported) doesn't work with virtualenv and python2 ... and nobody is in a hurry to fix it
[18:52] <smoser> but, anyway... somethign like python2or3 i think would be a nice way to say "this works in python2 or 3"
[18:53] <pyusr> tons of people CI broke over night
[19:01] <rbasak> pyusr: you'll be able to install the python-pointing-to-python2 package
[19:02] <rbasak> pyusr: oh, sorry, it'll be called python-is-python2-but-deprecated
[19:02] <rbasak> If you install that, your legacy scripts will work
[19:02] <pyusr> rbasak: will it inform me that when I try to run a script with #!/usr/bin/env python ?
[19:02] <rbasak> No.
[19:03] <rbasak> See https://www.python.org/dev/peps/pep-0394/ for more background on this
[19:03] <pyusr> so again, tons of workflow will be broken
[19:03] <rbasak> There's distro-wide consensus that python should eventually point to python3
[19:03] <rbasak> This is not an Ubuntu-only choice.
[19:03] <pyusr> yeah, but lots of noobs use ubuntu
[19:03] <pyusr> they will be confused
[19:04] <rbasak> People learning Python also get confused when "python" doesn't work or gives them some old version.
[19:04] <rbasak> Unfortunately there's no solution that will work for everyone.
[19:05] <pyusr> windows 10 opens the windows store with python installation when you type python in command promopet
[19:15] <pyusr> rbasak: I think ther eis, the OS should provide /usr/bin/python2or3
[19:16] <pyusr> and scripts should rely on it if they support both
[19:17] <rbasak> pyusr: great - I suggest you follow the upstream process of getting PEP 394 amended with that suggestion.
[19:18] <pyusr> PEP does not enforce OS but Python itself
[19:31] <pyusr> ok, better solution, "/usr/bin/env" in ubuntu should check if /usr/bin/python does not exist (and someone wants /usr/bin/env python) it should bring up a warning about what to do ?
[19:33] <pyusr> how does one go about offering that ?
[19:36] <tumbleweed> It's hard to imagine /usr/bin/env changing, to help Python users
[19:37] <pyusr> tumbleweed: there are gonna be tons of noobs that will start crying with 20.4 LTS
[19:37] <pyusr> why not improve their experience ?
[19:37] <tumbleweed> it's not /usr/bin/env's job to do that
[19:38] <pyusr> you understand that https://github.com/python-poetry/poetry/issues/2183 <-- this is a tip of the iceberg ?
[19:38] <pyusr> and thats a very popular package, think about all the abandond scripts people use daily that will stop working, and they will get a criptic message they will need to google ?
[19:39] <tumbleweed> yeah, the end of python 2 is a lot of pain for everyone
[19:39] <tumbleweed> I'm saying that this specific solution sounds like a non-starter
[19:40] <rbasak> The problem is that unless you put in a python2or3 command into every existing distro and release that people use, it's of little use.
[19:40] <pyusr> rbasak: I'm offering a different solution now
[19:40] <rbasak> I don't think it's appropriate to patch or redirect /usr/bin/env.
[19:40] <pyusr> the main issue is #!/usr/bin/env python gives a criptic error /usr/bin/env: 'python': No such file or directory
[19:41] <pyusr> it does not say "Python 2 is not installed on the system":
[19:41] <rbasak> And in any case it won't help scripts that don't /usr/bin/env.
[19:41] <rbasak> pyusr: in any case, I don't think somebody with no credentials and no prior track record is going to be able to appear on this channel and convince us to do anything this major.
[19:41] <pyusr> most scripts do, and those who don't maybe the error will be better "/usr/bin/python" no such file or directory
[19:42] <rbasak> That's why I said you should focus on getting consensus upstream.
[19:43] <pyusr> I don't even know how I can find someone to fix ubuntu 16.04 virtualenv to work...
[19:43] <rbasak> Or at least a mailing list
[19:43] <rbasak> pyusr: have you proposed a patch?
[19:43]  * rbasak needs to go
[19:43] <rbasak> I appreciate that you care
[19:43] <rbasak> But the way to get things done in this ecosystem is to present working solutions and build consensus to use them
[19:43] <pyusr> there is an SRU patch waiting for a month
[19:43] <rbasak> IRC doesn't really work for that.
[19:44] <rbasak> pyusr: link please?
[19:44] <pyusr> https://bugs.launchpad.net/ubuntu/+source/python-pip/+bug/1864766
[19:44] <ubottu> Launchpad bug 1864766 in python-pip (Ubuntu Xenial) "[SRU] pip in xenial is installing packages incompatible with Python 2.7 (and those are becoming common)" [Medium,In progress]
[19:44] <tumbleweed> pyusr: and I field that SRU, and rbasak has commented on it
[19:44] <rbasak> Ah
[19:44] <pyusr> tumbleweed: ahh, cool
[19:44] <rbasak> I reviewed that the other day, yes
[19:45] <rbasak> (well, I didn't, since I don't think I'm sufficiently qualified)
[19:45] <tumbleweed> :P
[19:45] <tumbleweed> yeah, was hoping to get doko's attention
[19:45] <rbasak> I pinged doko about that earlier ^
[19:45] <rbasak> :)
[19:45] <pyusr> rbasak: that bug is ongoing for 2 month already :(  It makes me wonder how has it not surfesed enough
[19:45] <pyusr> surfaced
[19:46] <rbasak> pyusr: right - only one person marked affected
[19:46] <rbasak> Trust me - when it affects a large number of people, the noise is noticeable :)
[19:46] <pyusr> I discovered the bug, told my friend about it, he linked me to his buildbots of pypy stoped working
[19:46] <pyusr> so he formated the machine to 18.04
[19:47] <pyusr> rbasak: maybe people stoped using system python with CI with stuff like pyenv, asdf
[19:47]  * rbasak does really need to go now
[19:47] <pyusr> laters
[19:47] <pyusr> tumbleweed: you don't think a better error msg on /usr/bin/env is a good idea ?
[19:49] <tumbleweed> I'd talk to the coreutils upstream - this is a common use for /usr/bin/env, and the error message could be improved to help users
[19:49] <tumbleweed> I don't think the best approach is to be Python-specific, though
[19:50] <pyusr> maybe like ubuntu has that autofigure out which package to recommend on error
[19:50] <pyusr> and link that into /usr/bin/env errors
[19:50] <tumbleweed> using /usr/bin/env to find a program on PATH is a total abuse of the purpose of it... but it's probably 90% of what it's used for, these days
[20:23] <pyusr> also, shouldn't nvidia-drivers for ubuntu (16.04) check that HWE is neabled ?
[20:23] <pyusr> instead of borkign the system
[20:28] <vorlon> objection, assumes facts not in evidence