Re: [gentoo-user] update fails, but I don't see why [PROGRESS]
On 12/30/20 1:05 AM, Michael wrote: On Tuesday, 29 December 2020 22:55:03 GMT Neil Bothwick wrote: On Tue, 29 Dec 2020 23:16:11 +0100, n952162 wrote: So, I tried to do an emerge on @system. I got another slot conflict! This time for mako, which I'd seen go by sometimes as a "package of interest". It's only transgression: PYTHON_TARGET containing python3_7. Note that both the "scheduled for merge" depender and the "installed" depender both required the same version of mako, 1.1.1-r1. The only difference is the fact that one requirements specification has python3-7, the other python3-8. The same pkg, the same binaries. Something is wrong here. Why is it not good enough to specify python3? PYTHON_TARGET determines for which version(s) of Python a package installs its modules. The modules may be identical, but 3.7 and 3.8 have different search paths, e.g. /usr/lib/python3.7/site-packages vs. /usr/lib/python3.8/site-packages. It is possible you have some old python_targets settings in package.use, that's where I would check first. As discussed recently, removing any manually configured python targets and letting portage work its magic, rather than fighting against it, is usually a sound way to get out of such a muddle. I sync'ed portage a few hours ago today. Neither mako, nor setuptools require anything other than python3_8 on this system: $ eix -l setuptools [I] dev-python/setuptools Available versions: 46.4.0-r3 ^t [test PYTHON_TARGETS="pypy3 python2_7 python3_6 python3_7 python3_8 python3_9"] ["|| ( python_targets_pypy3 python_targets_python2_7 python_targets_python3_6 python_targets_python3_7 python_targets_python3_8 python_targets_python3_9 )"] 50.3.0^t [test PYTHON_TARGETS="pypy3 python3_6 python3_7 python3_8 python3_9"]["|| ( python_targets_pypy3 python_targets_python3_6 python_targets_python3_7 python_targets_python3_8 python_targets_python3_9 )"] ~51.0.0^t [test PYTHON_TARGETS="pypy3 python3_6 python3_7 python3_8 python3_9"]["|| ( python_targets_pypy3 python_targets_python3_6 python_targets_python3_7 python_targets_python3_8 python_targets_python3_9 )"] ~51.1.0^t [test PYTHON_TARGETS="pypy3 python3_6 python3_7 python3_8 python3_9"]["|| ( python_targets_pypy3 python_targets_python3_6 python_targets_python3_7 python_targets_python3_8 python_targets_python3_9 )"] Installed versions: 50.3.0^t(12:47:38 05/12/20)(-test PYTHON_TARGETS="python3_8 -pypy3 -python3_6 -python3_7 -python3_9") Homepage:https://github.com/pypa/setuptools https://pypi.org/ project/setuptools/ Description: Collection of extensions to Distutils $ eix -l mako [I] dev-python/mako Available versions: 1.1.3-r1 ^t [doc test PYTHON_TARGETS="pypy3 python3_6 python3_7 python3_8 python3_9"]["|| ( python_targets_pypy3 python_targets_python3_6 python_targets_python3_7 python_targets_python3_8 python_targets_python3_9 )"] Installed versions: 1.1.3-r1^t(13:09:34 05/12/20)(-doc -test PYTHON_TARGETS="python3_8 -pypy3 -python3_6 -python3_7 -python3_9") Homepage:https://www.makotemplates.org/ https://pypi.org/ project/Mako/ Description: A Python templating language ... Well, yes, the current version, indeed requires python3_8. The version that was installed on my system, however, to be updated, listed python3_7 in the PYTHON_TARGETS section. That was the only difference between the two packages in the collision. It apparently disqualified the update with a slot conflict.
Re: [gentoo-user] update fails, but I don't see why [PROGRESS]
On 12/30/20 1:05 AM, Michael wrote: On Tuesday, 29 December 2020 22:55:03 GMT Neil Bothwick wrote: On Tue, 29 Dec 2020 23:16:11 +0100, n952162 wrote: So, I tried to do an emerge on @system. I got another slot conflict! This time for mako, which I'd seen go by sometimes as a "package of interest". It's only transgression: PYTHON_TARGET containing python3_7. Note that both the "scheduled for merge" depender and the "installed" depender both required the same version of mako, 1.1.1-r1. The only difference is the fact that one requirements specification has python3-7, the other python3-8. The same pkg, the same binaries. Something is wrong here. Why is it not good enough to specify python3? PYTHON_TARGET determines for which version(s) of Python a package installs its modules. The modules may be identical, but 3.7 and 3.8 have different search paths, e.g. /usr/lib/python3.7/site-packages vs. /usr/lib/python3.8/site-packages. It is possible you have some old python_targets settings in package.use, that's where I would check first. As discussed recently, removing any manually configured python targets and letting portage work its magic, rather than fighting against it, is usually a sound way to get out of such a muddle. I don't understand what manually configured python targets are. There are, in general, no python specifiers on my system in /etc/portage/package.use or make.conf. Do you mean somewhere else?
Re: [gentoo-user] update fails, but I don't see why [PROGRESS]
On 12/30/20 1:21 AM, Dale wrote: Michael wrote: I expect in a few weeks the tree will settle on python3_9, so all this rinse and repeat exercise with all the python updates should hopefully go quiet. :-) It may not be a bad idea for the OP to sync again and see if that helps. It's rare but in the past I've caught the tree in a state where things were not quite right. Someone is making changes but not all the needed changes made it at the same time. Sometimes even a few minutes can make a difference. I've re-synced in the past and it can help get past some roadblocks. It's not a sure thing but it may be worth a try. Dale :-) :-) I've synced copiously. I last synced on 27.12. After doing the emerge @system on the stripped out system of 103 packages last night, a new sync and emerge @system this morning yielded an update of 34 packages.
[gentoo-user] Re: ncurses; I think I wrecked my fresh install
On 2020-12-29, Walter Dnes wrote: > On Tue, Dec 29, 2020 at 05:11:36PM +0200, Andreas K. Huettel wrote >> Hi Walter, >> >> > "-pch -roaming -sendmail -spell -tcpd -udev -udisks -unicode -upower >> > -xinerama" >> >> mostly out of curiosity, why do you want to disable unicode support >> here? >> >> This feels odd to me since utf8 has effectively become the standard >> encoding over the past years. > > I don't know if this has improved over the years, but my initial > experience with unicode was rather negative. The fact that text > files were twice as large wasn't a major problem in itself. The > real showstopper was that importing text files into spreadsheets > and text-editors and word processors failed miseraby. You must be talking about some sort of weird "wide" encoding (is there such a thing as UTF-16?). I've never seen a file like that. Everybody and everything uses UTF-8 these days and has for years. UTF-8 is a superset of ASCII, and doesn't increase size of the file unless non-ascii characters are used. Converting an ASCII file to UTF-8 encoding is a noop. An ASCII file _is_ UTF-8. > I looked at a unicode text file with a binary viewer. It turns out > that a simple text string like "1234" was actually... > > "1" binary-zero "2" binary-zero "3" binary-zero "4" binary zero, etc. > > This padding explains why the file was twice as large, and also why > "a simple textfile import" failed miserably. I've never seen a file like that. All the Unicode I run into is UTF-8, and a UTF-8 file with the string "1234" is the same exact 4 bytes as an ASCII file with the string "1234". > On top of that Cyrillic letters like "m", "i", "c", and "o" are > considered different from their English equivalants. Security experts > showed proof-of-cocept attacks where clicking on "microsoft.com" can > take you to a hostile domain (queue the jokes). I don't speak or read > or write any languages which have thousands of unique characters. > Seeing Chinese spam "as it was intended to be seen", is not a priority > for me.
Re: [gentoo-user] update fails, but I don't see why [PROGRESS]
Michael wrote: > > I expect in a few weeks the tree will settle on python3_9, so all this rinse > and repeat exercise with all the python updates should hopefully go quiet. :-) It may not be a bad idea for the OP to sync again and see if that helps. It's rare but in the past I've caught the tree in a state where things were not quite right. Someone is making changes but not all the needed changes made it at the same time. Sometimes even a few minutes can make a difference. I've re-synced in the past and it can help get past some roadblocks. It's not a sure thing but it may be worth a try. Dale :-) :-)
Re: [gentoo-user] update fails, but I don't see why [PROGRESS]
On Tuesday, 29 December 2020 22:55:03 GMT Neil Bothwick wrote: > On Tue, 29 Dec 2020 23:16:11 +0100, n952162 wrote: > > > So, I tried to do an emerge on @system. I got another slot conflict! > > > This time for mako, which I'd seen go by sometimes as a "package of > > > interest". It's only transgression: PYTHON_TARGET containing > > > python3_7. > > > > Note that both the "scheduled for merge" depender and the "installed" > > depender both required the same version of mako, 1.1.1-r1. The only > > difference is the fact that one requirements specification has > > python3-7, the other python3-8. The same pkg, the same binaries. > > Something is wrong here. Why is it not good enough to specify python3? > > PYTHON_TARGET determines for which version(s) of Python a package > installs its modules. The modules may be identical, but 3.7 and 3.8 have > different search paths, e.g. /usr/lib/python3.7/site-packages vs. > /usr/lib/python3.8/site-packages. > > It is possible you have some old python_targets settings in package.use, > that's where I would check first. As discussed recently, removing any manually configured python targets and letting portage work its magic, rather than fighting against it, is usually a sound way to get out of such a muddle. I sync'ed portage a few hours ago today. Neither mako, nor setuptools require anything other than python3_8 on this system: $ eix -l setuptools [I] dev-python/setuptools Available versions: 46.4.0-r3 ^t[test PYTHON_TARGETS="pypy3 python2_7 python3_6 python3_7 python3_8 python3_9"] ["|| ( python_targets_pypy3 python_targets_python2_7 python_targets_python3_6 python_targets_python3_7 python_targets_python3_8 python_targets_python3_9 )"] 50.3.0^t[test PYTHON_TARGETS="pypy3 python3_6 python3_7 python3_8 python3_9"] ["|| ( python_targets_pypy3 python_targets_python3_6 python_targets_python3_7 python_targets_python3_8 python_targets_python3_9 )"] ~51.0.0^t[test PYTHON_TARGETS="pypy3 python3_6 python3_7 python3_8 python3_9"] ["|| ( python_targets_pypy3 python_targets_python3_6 python_targets_python3_7 python_targets_python3_8 python_targets_python3_9 )"] ~51.1.0^t[test PYTHON_TARGETS="pypy3 python3_6 python3_7 python3_8 python3_9"] ["|| ( python_targets_pypy3 python_targets_python3_6 python_targets_python3_7 python_targets_python3_8 python_targets_python3_9 )"] Installed versions: 50.3.0^t(12:47:38 05/12/20)(-test PYTHON_TARGETS="python3_8 -pypy3 -python3_6 -python3_7 -python3_9") Homepage:https://github.com/pypa/setuptools https://pypi.org/ project/setuptools/ Description: Collection of extensions to Distutils $ eix -l mako [I] dev-python/mako Available versions: 1.1.3-r1 ^t[doc test PYTHON_TARGETS="pypy3 python3_6 python3_7 python3_8 python3_9"] ["|| ( python_targets_pypy3 python_targets_python3_6 python_targets_python3_7 python_targets_python3_8 python_targets_python3_9 )"] Installed versions: 1.1.3-r1^t(13:09:34 05/12/20)(-doc -test PYTHON_TARGETS="python3_8 -pypy3 -python3_6 -python3_7 -python3_9") Homepage:https://www.makotemplates.org/ https://pypi.org/ project/Mako/ Description: A Python templating language I expect in a few weeks the tree will settle on python3_9, so all this rinse and repeat exercise with all the python updates should hopefully go quiet. :-) signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] ncurses; I think I wrecked my fresh install
On Tue, Dec 29, 2020 at 05:11:36PM +0200, Andreas K. Huettel wrote > Hi Walter, > > > "-pch -roaming -sendmail -spell -tcpd -udev -udisks -unicode -upower > > -xinerama" > > mostly out of curiosity, why do you want to disable unicode support > here? > > This feels odd to me since utf8 has effectively become the standard > encoding over the past years. I don't know if this has improved over the years, but my initial experience with unicode was rather negative. The fact that text files were twice as large wasn't a major problem in itself. The real showstopper was that importing text files into spreadsheets and text-editors and word processors failed miseraby. I looked at a unicode text file with a binary viewer. It turns out that a simple text string like "1234" was actually... "1" binary-zero "2" binary-zero "3" binary-zero "4" binary zero, etc. This padding explains why the file was twice as large, and also why "a simple textfile import" failed miserably. On top of that Cyrillic letters like "m", "i", "c", and "o" are considered different from their English equivalants. Security experts showed proof-of-cocept attacks where clicking on "microsoft.com" can take you to a hostile domain (queue the jokes). I don't speak or read or write any languages which have thousands of unique characters. Seeing Chinese spam "as it was intended to be seen", is not a priority for me. -- Walter Dnes I don't run "desktop environments"; I run useful applications
Re: [gentoo-user] update fails, but I don't see why [PROGRESS]
On Tue, 29 Dec 2020 23:16:11 +0100, n952162 wrote: > > So, I tried to do an emerge on @system. I got another slot conflict! > > This time for mako, which I'd seen go by sometimes as a "package of > > interest". It's only transgression: PYTHON_TARGET containing > > python3_7. > Note that both the "scheduled for merge" depender and the "installed" > depender both required the same version of mako, 1.1.1-r1. The only > difference is the fact that one requirements specification has > python3-7, the other python3-8. The same pkg, the same binaries. > Something is wrong here. Why is it not good enough to specify python3? PYTHON_TARGET determines for which version(s) of Python a package installs its modules. The modules may be identical, but 3.7 and 3.8 have different search paths, e.g. /usr/lib/python3.7/site-packages vs. /usr/lib/python3.8/site-packages. It is possible you have some old python_targets settings in package.use, that's where I would check first. -- Neil Bothwick Growing old is mandatory; growing up is optional!! pgpxiyNnvqiKr.pgp Description: OpenPGP digital signature
Re: [gentoo-user] update fails, but I don't see why [PROGRESS]
n952162 wrote: > On 12/29/20 11:07 PM, n952162 wrote: >> >> >> So, I tried to do an emerge on @system. I got another slot conflict! >> This time for mako, which I'd seen go by sometimes as a "package of >> interest". It's only transgression: PYTHON_TARGET containing python3_7. >> >> > > Note that both the "scheduled for merge" depender and the "installed" > depender both required the same version of mako, 1.1.1-r1. The only > difference is the fact that one requirements specification has > python3-7, the other python3-8. The same pkg, the same binaries. > Something is wrong here. Why is it not good enough to specify python3? > > > > All I can say is there is a reason for it. It seems there is significant changes between 3.7, 3.8 and 3.9 that causes compatibility issues, which is why each is slotted I guess. There is a comment on this bug that may explain it better. https://bugs.gentoo.org/762406#c1 It should go to the comment but if it doesn't, it's the first actual comment by Michał Górny. There's also a thread on -dev about this but it is short and likely won't explain much. Dale :-) :-)
Re: [gentoo-user] update fails, but I don't see why [PROGRESS]
On 12/29/20 11:07 PM, n952162 wrote: So, I tried to do an emerge on @system. I got another slot conflict! This time for mako, which I'd seen go by sometimes as a "package of interest". It's only transgression: PYTHON_TARGET containing python3_7. Note that both the "scheduled for merge" depender and the "installed" depender both required the same version of mako, 1.1.1-r1. The only difference is the fact that one requirements specification has python3-7, the other python3-8. The same pkg, the same binaries. Something is wrong here. Why is it not good enough to specify python3?
Re: [gentoo-user] update fails, but I don't see why [PROGRESS]
On 12/3/20 9:33 PM, n952162 wrote: I'm trying to update the gentoo system that I last updated 6 weeks ago, but it seems not to work. Can somebody explain to me why? I tried and tried to figure out how I could determine what the fatal slot conflict would be. No matter how I mixed things, setuptools came up fighting about these things: - certifi - setuptools - jinja - markupsafe - libxml2 All the requirements were essentially equivalent, the only problem is that all had PYTHON_TARGETS with PYTHON3_8, while setuptools also had 3_6 and 3_7. I was not able to learn how to force PYTHON_TARGETS, also not by modifying the ebuild. Out of desperation or carelessness, I did a --depclean on the contents of the world file. 179 packages were removed, including sudo and my window manager. 106 packages were left. At least, I could still execute emerge. So, I tried to do an emerge on @system. I got another slot conflict! This time for mako, which I'd seen go by sometimes as a "package of interest". It's only transgression: PYTHON_TARGET containing python3_7. BUT! Finally, I could emerge mako. Along with it are coming 50 other packages! I presume that tomorrow, I'll be able to do a full @system and @world update and then re-install my old world file.
[gentoo-user] Re: ncurses; I think I wrecked my fresh install
On 2020-12-29, Andreas K. Huettel wrote: > Hi Walter, > >> "-pch -roaming -sendmail -spell -tcpd -udev -udisks -unicode -upower >> -xinerama" > > mostly out of curiosity, why do you want to disable unicode support here? > > This feels odd to me since utf8 has effectively become the standard encoding > over the past years. I switched to a "unicode enabled" install many years ago, and I'm about as much the "cranky old Unix guy" as you can get: I think that mutt in an xterm qualifies as "GUI email client". -- Grant
Re: [gentoo-user] Wayland side-effect?
On Monday, 28 December 2020 00:10:54 GMT Michael wrote: > On Sunday, 27 December 2020 21:01:09 GMT antlists wrote: > > On 27/12/2020 18:51, Michael wrote: > > > Restarting the desktop using Xorg does NOT fix this problem. Otherwise, > > > both Plasma on Wayland and Xorg work fine - except the clipboard does > > > not > > > work on Wayland (middle click won't paste selected text on another > > > window). > > > > This sounds to me like a side-effect of Wayland security. I don't really > > know anything about it, but I get the impression that talking between > > windows is an unsolved security problem. > > > > Of course, it could be it's a solved problem, but you've hit a glitch... > > > > Cheers, > > Wol > > Yes, the clipboard issue is due to the isolation between application windows > for security reasons. It should also stop keyloggers having a go at my > typing. Annoying nonetheless, I hadn't realised how much I use the middle- > click clipboard feature! Selecting text with the mouse, then using right- > click Copy (or Ctrl+c) and right-click Paste (Ctrl+v) works, as a long > winded alternative. > > I wonder if the message preview pane problem in Kmail is also caused by the > same wayland window isolation? Hmm ... The workaround for the black message preview pane is to resize the root Kmail window. When redrawn the message preview pane shows its contents. Resizing has to take place in a single operation and left alone for a few seconds. If multiple resizing actions take place then invariably Kmail becomes unresponsive and crashes. QtWayland complains about something or other not implemented, so I assume some coding in Kmail needs to be polished to make it work more smoothly in Wayland. signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] ncurses; I think I wrecked my fresh install
Hi Walter, > "-pch -roaming -sendmail -spell -tcpd -udev -udisks -unicode -upower > -xinerama" mostly out of curiosity, why do you want to disable unicode support here? This feels odd to me since utf8 has effectively become the standard encoding over the past years. Cheers, Andreas -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, qa, toolchain, base-system, perl, libreoffice)
[gentoo-user] postfix error: SMTPUTF8 is required, but was not offered by host
Postfix is compiled with: "eai" flag I tried adding to main.cf: smtputf8_enable = yes I still get some mail return with error: SMTPUTF8 is required, but was not offered by host
