| 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:57 |
| 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:58 |
| mwhudson | xnox: cool! | 01:59 |
| xnox | mwhudson: the top 4 bugs on https://bugs.launchpad.net/ubuntu/+source/plymouth/+bugs?orderby=-id&start=0 | 01:59 |
| 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 | 05:31 |
| 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:53 |
| 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:54 |
| 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:55 |
| 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:56 |
| 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:57 |
| rbasak | This is just speaking from experience in working in our ecosystem. I can't speak for casper/pam-auth-update/debconf. | 06:58 |
| 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 | 06:59 |
| 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:00 |
| 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:01 |
| 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:02 |
| 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:08 |
| rbasak | Thanks! | 07:09 |
| alkisg | Thank you too, as always :) | 07:09 |
| 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:13 |
| 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:14 |
| 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:15 |
| 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:16 | |
| 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 :-) | 07:17 |
| === pieq_ is now known as pieq | ||
| 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:58 |
| xnox | mvo is not in the channel. Can't remember who else touched cnf-extractor, maybe Laney? | 10:59 |
| Laney | well I do have access to the thing | 11:02 |
| Laney | but it's probably more of an mvo question | 11:02 |
| 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:17 |
| 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:18 |
| xnox | Thank you! this is very useful. | 11:19 |
| xnox | Yeah, i need to drop headers & add headers, i guess SRU it is. | 11:19 |
| 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 | 12:53 |
| rafaeldtinoco | ahasenack: /me checks | 13:17 |
| cpaelzer | damn you beat me by a minute rafaeldtinoco :-) | 13:19 |
| rafaeldtinoco | hihi | 13:20 |
| cpaelzer | ok 2 | 13:20 |
| rafaeldtinoco | ahasenack: +1 | 13:21 |
| ahasenack | thx | 13:21 |
| ahasenack | well, you both can look | 13:21 |
| ahasenack | I don't mind | 13:21 |
| 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:22 |
| cpaelzer | ahasenack: I haven't looked at it since rafaeldtinoco did | 13:30 |
| cpaelzer | if you want me to I can ... | 13:30 |
| ahasenack | thanks, synced | 13:47 |
| 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:38 |
| coreycb | anyway that is what openstack ussuri currently has for upper-constraints | 14:39 |
| 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:32 |
| 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:34 |
| mpt | I don’t see a list of them at <https://launchpad.net/ubuntu/xenial> either | 15:39 |
| 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. | 15:42 |
| 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:04 |
| 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:06 |
| 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:11 |
| 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:13 |
| 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:15 |
| pyusr | (stuff outside the apt echo system) | 18:16 |
| cjwatson | OK, I'm out of here, have told you everything I can | 18:16 |
| smoser | pyusr: python2or3 | 18:46 |
| smoser | https://gist.github.com/smoser/8904199bb8f00a90dd04 | 18:46 |
| pyusr | that script exists in ubuntu 20.4? | 18:47 |
| 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:48 |
| 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:49 |
| 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:50 |
| pyusr | again, check that, one of the biggest packages | 18:51 |
| 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:52 |
| pyusr | tons of people CI broke over night | 18:53 |
| rbasak | pyusr: you'll be able to install the python-pointing-to-python2 package | 19:01 |
| 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:02 |
| 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:03 |
| 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:04 |
| pyusr | windows 10 opens the windows store with python installation when you type python in command promopet | 19:05 |
| pyusr | rbasak: I think ther eis, the OS should provide /usr/bin/python2or3 | 19:15 |
| pyusr | and scripts should rely on it if they support both | 19:16 |
| rbasak | pyusr: great - I suggest you follow the upstream process of getting PEP 394 amended with that suggestion. | 19:17 |
| pyusr | PEP does not enforce OS but Python itself | 19:18 |
| 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:31 |
| pyusr | how does one go about offering that ? | 19:33 |
| tumbleweed | It's hard to imagine /usr/bin/env changing, to help Python users | 19:36 |
| 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:37 |
| 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:38 |
| 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:39 |
| 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:40 |
| 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:41 |
| rbasak | That's why I said you should focus on getting consensus upstream. | 19:42 |
| 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:43 |
| 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:44 |
| 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:45 |
| 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:46 |
| 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:47 |
| 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:49 |
| 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 | 19:50 |
| pyusr | also, shouldn't nvidia-drivers for ubuntu (16.04) check that HWE is neabled ? | 20:23 |
| pyusr | instead of borkign the system | 20:23 |
| vorlon | objection, assumes facts not in evidence | 20:28 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!