Re: [gentoo-user] could there be a problem with acct-group/lp?
On 12/31/20 1:29 AM, Michael wrote: On Wednesday, 30 December 2020 23:33:47 GMT Jack wrote: On 2020.12.30 17:17, n952162 wrote: When I try to restore my pkgs, after the --depclean, the emerge fails. It seems like there's an error in the pre-inst script of acct-group/lp? That's need by cups: 1270~/adm/gentoo/emerged>sudo cat /var/tmp/portage/acct-group/lp-0-r1/temp/build.log * Package:acct-group/lp-0-r1 * Repository: gentoo * Maintainer: syst...@gentoo.org print...@gentoo.org * USE:abi_x86_64 amd64 elibc_glibc kernel_linux userland_GNU * FEATURES: network-sandbox preserve-libs sandbox userpriv usersandbox Unpacking source... Source unpacked in /var/tmp/portage/acct-group/lp-0-r1/work Preparing source in /var/tmp/portage/acct-group/lp-0-r1/work ... Source prepared. Configuring source in /var/tmp/portage/acct-group/lp-0-r1/work ... Source configured. Compiling source in /var/tmp/portage/acct-group/lp-0-r1/work ... Source compiled. Test phase [not enabled]: acct-group/lp-0-r1 Install acct-group/lp-0-r1 into /var/tmp/portage/acct-group/lp-0-r1/image Completed installing acct-group/lp-0-r1 into /var/tmp/portage/acct-group/lp-0-r1/image * Final size of build directory: 4 KiB * Final size of installed tree: 20 KiB * checking 1 files for package collisions Merging acct-group/lp-0-r1 to / error writing group entry: Invalid argument * Adding group 'lp' to your system ... error writing group entry: Invalid argument * - Groupid: 7 groupadd: group 'lp' already exists This seems to be the basic cause. However, I have no idea what that emerge should do if the group it wants to install does already exist. I can re-emerge this package with no problems. Is this a new install or reinstall? All the logic is in the eclass which does have the comment "Creates the group if it does not exist." What happens if you just run "emerge -1 acct-group/lp"? Have you done a successful "emerge -auDvN @system" ? There may well be something else required still missing, but not an explicit dependency because it is part of @system. Some other things to try after @system if the problem persists: Check the ownership and access rights of /etc/group: $ stat /etc/group File: /etc/group Size: 855Blocks: 8 IO Block: 4096 regular file Device: 80ah/2058d Inode: 1055521 Links: 1 Access: (0644/-rw-r--r--) Uid: (0/root) Gid: (0/root) Access: 2020-10-25 16:25:42.814894971 + Modify: 2020-10-25 16:25:42.815894988 + Change: 2020-10-25 16:25:42.892896366 + Birth: 2020-10-25 16:25:42.814894971 + Check the particular group ID: $ grep :7: /etc/group lp:x:7:lp Emerge cups which installs lp: emerge -1aDv net-print/cups Then try again as suggested: emerge -1aDv acct-group/lp $ ls -l /etc/group -rw-r--r-- 1 root root 907 Dec 30 20:53 /etc/group $ stat /etc/group File: `/etc/group' Size: 907 Blocks: 8 IO Block: 4096 regular file Device: 801h/2049d Inode: 950897 Links: 1 Access: (0644/-rw-r--r--) Uid: ( 0/ root) Gid: ( 0/ root) Access: 2020-12-30 20:53:13.0 +0100 Modify: 2020-12-30 20:53:12.0 +0100 Change: 2020-12-30 20:53:12.0 +0100 Birth: - $ grep :7: /etc/group lp:x:7:lp:me cups was already installed. I considered removing it, but several other things, like ghostscript (!) are dependent on it. I'm using --keep-going for now. I suspect a bug in acct-group/lp that will get cleared up. Why do you specify -1? That's the most common advice I get for avoiding slot-conflicts, but I can't imagine a system without cups.
Re: [gentoo-user] could there be a problem with acct-group/lp?
On 12/31/20 12:33 AM, Jack wrote: On 2020.12.30 17:17, n952162 wrote: When I try to restore my pkgs, after the --depclean, the emerge fails. It seems like there's an error in the pre-inst script of acct-group/lp? That's need by cups: 1270~/adm/gentoo/emerged>sudo cat /var/tmp/portage/acct-group/lp-0-r1/temp/build.log * Package: acct-group/lp-0-r1 * Repository: gentoo * Maintainer: syst...@gentoo.org print...@gentoo.org * USE: abi_x86_64 amd64 elibc_glibc kernel_linux userland_GNU * FEATURES: network-sandbox preserve-libs sandbox userpriv usersandbox >>> Unpacking source... >>> Source unpacked in /var/tmp/portage/acct-group/lp-0-r1/work >>> Preparing source in /var/tmp/portage/acct-group/lp-0-r1/work ... >>> Source prepared. >>> Configuring source in /var/tmp/portage/acct-group/lp-0-r1/work ... >>> Source configured. >>> Compiling source in /var/tmp/portage/acct-group/lp-0-r1/work ... >>> Source compiled. >>> Test phase [not enabled]: acct-group/lp-0-r1 >>> Install acct-group/lp-0-r1 into /var/tmp/portage/acct-group/lp-0-r1/image >>> Completed installing acct-group/lp-0-r1 into /var/tmp/portage/acct-group/lp-0-r1/image * Final size of build directory: 4 KiB * Final size of installed tree: 20 KiB * checking 1 files for package collisions >>> Merging acct-group/lp-0-r1 to / error writing group entry: Invalid argument * Adding group 'lp' to your system ... error writing group entry: Invalid argument * - Groupid: 7 groupadd: group 'lp' already exists This seems to be the basic cause. Perhaps. But there are two "invalid argument" error messages before the "already exists" msg. However, I have no idea what that emerge should do if the group it wants to install does already exist. I can re-emerge this package with no problems. That's interesting! Maybe re-emerge would behave differently from a de-install/emerge? In any case though, crashing if the group already exists would be a bug the developers should be interested in. Is this a new install or reinstall? All the logic is in the eclass which does have the comment "Creates the group if it does not exist." I was looking for that ... I didn't find groupadd in /var/db/pkg/acct-group/lp-0. Where should I look? What happens if you just run "emerge -1 acct-group/lp"? Same thing Have you done a successful "emerge -auDvN @system" ? Yes There may well be something else required still missing, but not an explicit dependency because it is part of @system. One thing I just re-discovered is --keep-going, which works, thank goodness, so I'll should have a working system (sometime tomorrow!), albeit, without cups.
Re: [gentoo-user] could there be a problem with acct-group/lp?
On Wednesday, 30 December 2020 23:33:47 GMT Jack wrote: > On 2020.12.30 17:17, n952162 wrote: > > When I try to restore my pkgs, after the --depclean, the emerge > > fails. > > It seems like there's an error in the pre-inst script of > > acct-group/lp? > > That's need by cups: > > > > 1270~/adm/gentoo/emerged>sudo cat > > /var/tmp/portage/acct-group/lp-0-r1/temp/build.log > > * Package:acct-group/lp-0-r1 > > * Repository: gentoo > > * Maintainer: syst...@gentoo.org print...@gentoo.org > > * USE:abi_x86_64 amd64 elibc_glibc kernel_linux userland_GNU > > * FEATURES: network-sandbox preserve-libs sandbox userpriv > > usersandbox > > > > >>> Unpacking source... > > >>> Source unpacked in /var/tmp/portage/acct-group/lp-0-r1/work > > >>> Preparing source in /var/tmp/portage/acct-group/lp-0-r1/work ... > > >>> Source prepared. > > >>> Configuring source in /var/tmp/portage/acct-group/lp-0-r1/work ... > > >>> Source configured. > > >>> Compiling source in /var/tmp/portage/acct-group/lp-0-r1/work ... > > >>> Source compiled. > > >>> Test phase [not enabled]: acct-group/lp-0-r1 > > >>> > > >>> Install acct-group/lp-0-r1 into > > > > /var/tmp/portage/acct-group/lp-0-r1/image > > > > >>> Completed installing acct-group/lp-0-r1 into > > > > /var/tmp/portage/acct-group/lp-0-r1/image > > > > * Final size of build directory: 4 KiB > > * Final size of installed tree: 20 KiB > > > > * checking 1 files for package collisions > > > > >>> Merging acct-group/lp-0-r1 to / > > > > error writing group entry: Invalid argument > > * Adding group 'lp' to your system ... > > error writing group entry: Invalid argument > > * - Groupid: 7 > > groupadd: group 'lp' already exists > > This seems to be the basic cause. However, I have no idea what that > emerge should do if the group it wants to install does already exist. > I can re-emerge this package with no problems. Is this a new install > or reinstall? All the logic is in the eclass which does have the > comment "Creates the group if it does not exist." > > What happens if you just run "emerge -1 acct-group/lp"? Have you done > a successful "emerge -auDvN @system" ? There may well be something > else required still missing, but not an explicit dependency because it > is part of @system. Some other things to try after @system if the problem persists: Check the ownership and access rights of /etc/group: $ stat /etc/group File: /etc/group Size: 855 Blocks: 8 IO Block: 4096 regular file Device: 80ah/2058d Inode: 1055521 Links: 1 Access: (0644/-rw-r--r--) Uid: (0/root) Gid: (0/root) Access: 2020-10-25 16:25:42.814894971 + Modify: 2020-10-25 16:25:42.815894988 + Change: 2020-10-25 16:25:42.892896366 + Birth: 2020-10-25 16:25:42.814894971 + Check the particular group ID: $ grep :7: /etc/group lp:x:7:lp Emerge cups which installs lp: emerge -1aDv net-print/cups Then try again as suggested: emerge -1aDv acct-group/lp signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] could there be a problem with acct-group/lp?
On 2020.12.30 17:17, n952162 wrote:
When I try to restore my pkgs, after the --depclean, the emerge
fails.
It seems like there's an error in the pre-inst script of
acct-group/lp?
That's need by cups:
1270~/adm/gentoo/emerged>sudo cat
/var/tmp/portage/acct-group/lp-0-r1/temp/build.log
* Package: acct-group/lp-0-r1
* Repository: gentoo
* Maintainer: syst...@gentoo.org print...@gentoo.org
* USE: abi_x86_64 amd64 elibc_glibc kernel_linux userland_GNU
* FEATURES: network-sandbox preserve-libs sandbox userpriv
usersandbox
>>> Unpacking source...
>>> Source unpacked in /var/tmp/portage/acct-group/lp-0-r1/work
>>> Preparing source in /var/tmp/portage/acct-group/lp-0-r1/work ...
>>> Source prepared.
>>> Configuring source in /var/tmp/portage/acct-group/lp-0-r1/work ...
>>> Source configured.
>>> Compiling source in /var/tmp/portage/acct-group/lp-0-r1/work ...
>>> Source compiled.
>>> Test phase [not enabled]: acct-group/lp-0-r1
>>> Install acct-group/lp-0-r1 into
/var/tmp/portage/acct-group/lp-0-r1/image
>>> Completed installing acct-group/lp-0-r1 into
/var/tmp/portage/acct-group/lp-0-r1/image
* Final size of build directory: 4 KiB
* Final size of installed tree: 20 KiB
* checking 1 files for package collisions
>>> Merging acct-group/lp-0-r1 to /
error writing group entry: Invalid argument
* Adding group 'lp' to your system ...
error writing group entry: Invalid argument
* - Groupid: 7
groupadd: group 'lp' already exists
This seems to be the basic cause. However, I have no idea what that
emerge should do if the group it wants to install does already exist.
I can re-emerge this package with no problems. Is this a new install
or reinstall? All the logic is in the eclass which does have the
comment "Creates the group if it does not exist."
What happens if you just run "emerge -1 acct-group/lp"? Have you done
a successful "emerge -auDvN @system" ? There may well be something
else required still missing, but not an explicit dependency because it
is part of @system.
* ERROR: acct-group/lp-0-r1::gentoo failed (preinst phase):
* (no error message)
*
* Call stack:
* ebuild.sh, line 125: Called pkg_preinst
* environment, line 1194: Called acct-group_pkg_preinst
* environment, line 360: Called enewgroup 'lp' '7'
* environment, line 735: Called die
* The specific snippet of code:
* groupadd -r ${opts} "${egroup}" || die
*
* If you need support, post the output of `emerge --info
'=acct-group/lp-0-r1::gentoo'`,
* the complete build log and the output of `emerge -pqv
'=acct-group/lp-0-r1::gentoo'`.
* The complete build log is located at
'/var/tmp/portage/acct-group/lp-0-r1/temp/build.log'.
* The ebuild environment file is located at
'/var/tmp/portage/acct-group/lp-0-r1/temp/environment'.
* Working directory: '/var/tmp/portage/acct-group/lp-0-r1/homedir'
* S: '/var/tmp/portage/acct-group/lp-0-r1/work'
!!! FAILED preinst: 1
Then there's this, from emerge --info:
Password:
Portage 3.0.9 (python 3.8.6-final-0, default/linux/amd64/17.1,
gcc-9.3.0, glibc-2.32-r3, 4.19.72-gentoo x86_64)
=
System Settings
=
System uname:
Linux-4.19.72-gentoo-x86_64-AMD_A9-9420_RADEON_R5,_5_COMPUTE_CORES_2C+3G-with-glibc2.2.5
KiB Mem: 7672120 total, 1147028 free
KiB Swap: 8388604 total, 8387316 free
Timestamp of repository gentoo: Wed, 30 Dec 2020 20:30:01 +
Head commit of repository gentoo:
19c597e94d94dff08de5c0d8a692f871b75c4130
sh bash 5.0_p18
ld GNU ld (Gentoo 2.34 p6) 2.34.0
app-shells/bash: 5.0_p18::gentoo
dev-lang/perl: 5.30.3::gentoo
dev-lang/python: 2.7.18-r4::gentoo, 3.6.12::gentoo,
3.7.9::gentoo, 3.8.6::gentoo, 3.9.0::gentoo
dev-util/cmake: 3.17.4-r1::gentoo
sys-apps/baselayout: 2.7::gentoo
sys-apps/openrc: 0.42.1::gentoo
sys-apps/sandbox: 2.20::gentoo
sys-devel/autoconf: 2.13-r1::gentoo, 2.69-r5::gentoo
sys-devel/automake: 1.16.2-r1::gentoo
sys-devel/binutils: 2.34-r2::gentoo
sys-devel/gcc: 9.3.0-r2::gentoo
sys-devel/gcc-config: 2.3.2-r1::gentoo
sys-devel/libtool: 2.4.6-r6::gentoo
sys-devel/make: 4.3::gentoo
sys-kernel/linux-headers: 5.4-r1::gentoo (virtual/os-headers)
sys-libs/glibc: 2.32-r3::gentoo
Repositories:
gentoo
location: /var/db/repos/gentoo
sync-type: rsync
sync-uri: rsync://rsync.gentoo.org/gentoo-portage
priority: -1000
sync-rsync-verify-jobs: 1
sync-rsync-verify-max-age: 24
sync-rsync-extra-opts:
sync-rsync-verify-metamanifest: yes
ACCEPT_KEYWORDS="amd64"
ACCEPT_LICENSE="@FREE"
CBUILD="x86_64-pc-linux-gnu"
CFLAGS="-O2 -pipe"
CHOST="x86_64-pc-linux-gnu"
CONFIG_PROTECT="/etc /usr/share/gnupg/qualified.txt"
CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d
/etc/fonts/fonts.conf /etc/gconf
[gentoo-user] could there be a problem with acct-group/lp?
When I try to restore my pkgs, after the --depclean, the emerge fails.
It seems like there's an error in the pre-inst script of acct-group/lp?
That's need by cups:
1270~/adm/gentoo/emerged>sudo cat
/var/tmp/portage/acct-group/lp-0-r1/temp/build.log
* Package: acct-group/lp-0-r1
* Repository: gentoo
* Maintainer: syst...@gentoo.org print...@gentoo.org
* USE: abi_x86_64 amd64 elibc_glibc kernel_linux userland_GNU
* FEATURES: network-sandbox preserve-libs sandbox userpriv usersandbox
>>> Unpacking source...
>>> Source unpacked in /var/tmp/portage/acct-group/lp-0-r1/work
>>> Preparing source in /var/tmp/portage/acct-group/lp-0-r1/work ...
>>> Source prepared.
>>> Configuring source in /var/tmp/portage/acct-group/lp-0-r1/work ...
>>> Source configured.
>>> Compiling source in /var/tmp/portage/acct-group/lp-0-r1/work ...
>>> Source compiled.
>>> Test phase [not enabled]: acct-group/lp-0-r1
>>> Install acct-group/lp-0-r1 into
/var/tmp/portage/acct-group/lp-0-r1/image
>>> Completed installing acct-group/lp-0-r1 into
/var/tmp/portage/acct-group/lp-0-r1/image
* Final size of build directory: 4 KiB
* Final size of installed tree: 20 KiB
* checking 1 files for package collisions
>>> Merging acct-group/lp-0-r1 to /
error writing group entry: Invalid argument
* Adding group 'lp' to your system ...
error writing group entry: Invalid argument
* - Groupid: 7
groupadd: group 'lp' already exists
* ERROR: acct-group/lp-0-r1::gentoo failed (preinst phase):
* (no error message)
*
* Call stack:
* ebuild.sh, line 125: Called pkg_preinst
* environment, line 1194: Called acct-group_pkg_preinst
* environment, line 360: Called enewgroup 'lp' '7'
* environment, line 735: Called die
* The specific snippet of code:
* groupadd -r ${opts} "${egroup}" || die
*
* If you need support, post the output of `emerge --info
'=acct-group/lp-0-r1::gentoo'`,
* the complete build log and the output of `emerge -pqv
'=acct-group/lp-0-r1::gentoo'`.
* The complete build log is located at
'/var/tmp/portage/acct-group/lp-0-r1/temp/build.log'.
* The ebuild environment file is located at
'/var/tmp/portage/acct-group/lp-0-r1/temp/environment'.
* Working directory: '/var/tmp/portage/acct-group/lp-0-r1/homedir'
* S: '/var/tmp/portage/acct-group/lp-0-r1/work'
!!! FAILED preinst: 1
Then there's this, from emerge --info:
Password:
Portage 3.0.9 (python 3.8.6-final-0, default/linux/amd64/17.1,
gcc-9.3.0, glibc-2.32-r3, 4.19.72-gentoo x86_64)
=
System Settings
=
System uname:
Linux-4.19.72-gentoo-x86_64-AMD_A9-9420_RADEON_R5,_5_COMPUTE_CORES_2C+3G-with-glibc2.2.5
KiB Mem: 7672120 total, 1147028 free
KiB Swap: 8388604 total, 8387316 free
Timestamp of repository gentoo: Wed, 30 Dec 2020 20:30:01 +
Head commit of repository gentoo: 19c597e94d94dff08de5c0d8a692f871b75c4130
sh bash 5.0_p18
ld GNU ld (Gentoo 2.34 p6) 2.34.0
app-shells/bash: 5.0_p18::gentoo
dev-lang/perl: 5.30.3::gentoo
dev-lang/python: 2.7.18-r4::gentoo, 3.6.12::gentoo,
3.7.9::gentoo, 3.8.6::gentoo, 3.9.0::gentoo
dev-util/cmake: 3.17.4-r1::gentoo
sys-apps/baselayout: 2.7::gentoo
sys-apps/openrc: 0.42.1::gentoo
sys-apps/sandbox: 2.20::gentoo
sys-devel/autoconf: 2.13-r1::gentoo, 2.69-r5::gentoo
sys-devel/automake: 1.16.2-r1::gentoo
sys-devel/binutils: 2.34-r2::gentoo
sys-devel/gcc: 9.3.0-r2::gentoo
sys-devel/gcc-config: 2.3.2-r1::gentoo
sys-devel/libtool: 2.4.6-r6::gentoo
sys-devel/make: 4.3::gentoo
sys-kernel/linux-headers: 5.4-r1::gentoo (virtual/os-headers)
sys-libs/glibc: 2.32-r3::gentoo
Repositories:
gentoo
location: /var/db/repos/gentoo
sync-type: rsync
sync-uri: rsync://rsync.gentoo.org/gentoo-portage
priority: -1000
sync-rsync-verify-jobs: 1
sync-rsync-verify-max-age: 24
sync-rsync-extra-opts:
sync-rsync-verify-metamanifest: yes
ACCEPT_KEYWORDS="amd64"
ACCEPT_LICENSE="@FREE"
CBUILD="x86_64-pc-linux-gnu"
CFLAGS="-O2 -pipe"
CHOST="x86_64-pc-linux-gnu"
CONFIG_PROTECT="/etc /usr/share/gnupg/qualified.txt"
CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d
/etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/revdep-rebuild
/etc/sandbox.d /etc/terminfo"
CXXFLAGS="-O2 -pipe"
DISTDIR="/var/cache/distfiles"
ENV_UNSET="CARGO_HOME DBUS_SESSION_BUS_ADDRESS DISPLAY GOBIN GOPATH
PERL5LIB PERL5OPT PERLPREFIX PERL_CORE PERL_MB_OPT PERL_MM_OPT
XAUTHORITY XDG_CACHE_HOME XDG_CONFIG_HOME XDG_DATA_HOME XDG_RUNTIME_DIR"
FCFLAGS="-O2 -pipe"
FEATURES="assume-digests binpkg-docompress binpkg-dostrip binpkg-logs
config-protect-if-modified distlocks ebuild-locks fixlafiles ipc-sandbox
merge-sync multilib-strict network-sandbox news parallel-fetch
pid-sandbox preserve-libs protect-owned qa-unresolved-soname-deps
[gentoo-user] x2goserver - very slow
The current x2goserver-4.1.0.2 is very, very slow. I am still runing older x2goserver-4.0.1.22 and the speed is OK but the current one 4.1.0.2 is very slow over local LAN regardless of the setting I use.
Re: [gentoo-user] x2go server - Connection failed. /usr/lib64/x2go/x2gocheckport: line 131: DBD::SQLite::db:
On 12/30/2020 02:10 PM, the...@sys-concept.com wrote: > I just installed x2goserver-4.1.0.2 (fuse sqlite -postgres) and I'm > getting an error trying to connect to the server: I've missed the find print: x2godbadmin --createdb
[gentoo-user] x2go server - Connection failed. /usr/lib64/x2go/x2gocheckport: line 131: DBD::SQLite::db:
I just installed x2goserver-4.1.0.2 (fuse sqlite -postgres) and I'm getting an error trying to connect to the server: Connection failed. /usr/lib64/x2go/x2gocheckport: line 131: DBD::SQLite::db: syntax error in expression (error token is "::SQLite::db") /usr/lib64/x2go/x2gocheckport: line 131: DBD::SQLite::db: syntax error in expression (error token is "::SQLite::db") /usr/lib64/x2go/x2gocheckport: line 131: DBD::SQLite::db: syntax error in expression (error token is "::SQLite::db") /usr/lib64/x2go/x2gocheckport: line 131: DBD::SQLite::db: syntax error in expression (error token is "::SQLite::db") /usr/lib64/x2go/x2gocheckport: line 131: DBD::SQLite::db: syntax error in expression (error token is "::SQLite::db") /usr/lib64/x2go/x2gocheckport: line 131: DBD::SQLite::db: syntax error in expression (error token is "::SQLite::db") /usr/lib64/x2go/x2gocheckport: line 131: DBD::SQLite::db: syntax error in expression (error token is "::SQLite::db") /usr/lib64/x2go/x2gocheckport: line 131: DBD::SQLite::db: syntax error in expression (error token is "::SQLite::db") /usr/lib64/x2go/x2gocheckport: line 131: DBD::SQLite::db: syntax error in expression (error token is "::SQLite::db") /usr/lib64/x2go/x2gocheckport: line 131: DBD::SQLite::db: syntax error in expression (error token is "::SQLite::db") Unable to find free display port or insert new session into database; parameters: port (50), hostname (syscon7) and session name (). The server starts without any errors but client can not connect to it.
Re: [gentoo-user] ncurses; I think I wrecked my fresh install
Am Mittwoch, 30. Dezember 2020, 20:01:32 EET schrieb antlists: > On 30/12/2020 17:30, Andreas K. Huettel wrote: > > That's true, though registrars are filtering for it now. Also, I just > > checked, e.g. firefox always builds with unicode support (it would have > > trouble with a lot of websites otherwise). > > > > (: ˙˙˙ǝpoɔᴉun sǝop oslɐ ʇuǝᴉlɔ lᴉɐɯ ɹnoʎ uǝɥʇ ¿sᴉɥʇ pɐǝɹ noʎ uɐɔ 'ʍʇq > > Except something's wrong because eg "d" renders correctly upside down, > but "t" clearly has the wrong baseline, and looking at the serifs "l" > isn't upside down at all. True. There is no "upside down" character set, this just relies on accidental / partial / best effort matches. -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, qa, toolchain, base-system, perl, libreoffice) signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] ncurses; I think I wrecked my fresh install
On 30/12/2020 17:30, Andreas K. Huettel wrote: That's true, though registrars are filtering for it now. Also, I just checked, e.g. firefox always builds with unicode support (it would have trouble with a lot of websites otherwise). (: ˙˙˙ǝpoɔᴉun sǝop oslɐ ʇuǝᴉlɔ lᴉɐɯ ɹnoʎ uǝɥʇ ¿sᴉɥʇ pɐǝɹ noʎ uɐɔ 'ʍʇq Except something's wrong because eg "d" renders correctly upside down, but "t" clearly has the wrong baseline, and looking at the serifs "l" isn't upside down at all. Cheers, Wol
Re: [gentoo-user] ncurses; I think I wrecked my fresh install
On 30/12/2020 16:35, Andreas K. Huettel wrote: 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. That's (as someone has already pointed out) UTF-16, which is the default for some Windows tools (but understood in Linux too). (Even UTF-32 exists where all characters are 4 byte wide, but I've never seen it in the wild.) UTF-8 is normally used on Linux (and ASCII chars look exactly the same there); even for "long characters" outside the ASCII range spreadsheets and word processors should not be a problem anymore. Following up on my previous answer, you need to separate in your mind UTF the character set, and UTF-x the representation. When UTF was introduced MS - in accordance with the thoughts of the time - thought the future was a 16-bit char, which can store 32 thousand characters. (Note that, BY DEFINITION, the high bit of a UTF character *must* be zero. Just like standard ASCII.) So MS and Windows uses UTF-16 as its encoding. Unix LATER went down the route of UTF-8 which - I think - can only encode 16 thousand characters in two bytes, but because most (western) text does encode successfully in one byte is actually a major saving in network operations such as email, web etc which is where Unix has traditionally been very strong. But UTF-16 works very well for MS, because they are primarily desktop, and UTF-16 means that there are very few multi-char characters. That reduces pressure on CPU, which is a desktop-limited resource. And lastly, very importantly, given that AT PRESENT all characters can be encoded in 31 bits, UTF-32 the representation is equivalent to UTF the character set. But should we need more than 2 billion characters, there is nothing stopping us rolling out characters encoded in two 32-bit chars, and UTF-64. Cheers, Wol
Re: [gentoo-user] ncurses; I think I wrecked my fresh install
> 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). That's true, though registrars are filtering for it now. Also, I just checked, e.g. firefox always builds with unicode support (it would have trouble with a lot of websites otherwise). (: ˙˙˙ǝpoɔᴉun sǝop oslɐ ʇuǝᴉlɔ lᴉɐɯ ɹnoʎ uǝɥʇ ¿sᴉɥʇ pɐǝɹ noʎ uɐɔ 'ʍʇq > 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. Not even Klingon?! -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, qa, toolchain, base-system, perl, libreoffice) signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] ncurses; I think I wrecked my fresh install
> 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. That's (as someone has already pointed out) UTF-16, which is the default for some Windows tools (but understood in Linux too). (Even UTF-32 exists where all characters are 4 byte wide, but I've never seen it in the wild.) UTF-8 is normally used on Linux (and ASCII chars look exactly the same there); even for "long characters" outside the ASCII range spreadsheets and word processors should not be a problem anymore. -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, qa, toolchain, base-system, perl, libreoffice) signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] update fails, but I don't see why [PROGRESS]
On 12/30/20 9:35 AM, Arve Barsnes wrote: On Wed, 30 Dec 2020 at 08:46, n952162 wrote: 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. I tried walking you through the massive output from portage on one of these conflicts last week, was it helpful? The point either way, was that the slot conflict is not setuptools itself, but further down the dependency chain, where some package is unable to update to python 3.8, and it's dragging its dependencies back with it. Regards, Arve I spent hours studying your analysis, and then I thought it was a simple transitive-closure problem. I wrote a script that would take an emerge log and turn it into vectors and do a TC on those, but it didn't work. For one thing, I got tangled up in the issue of whether the "scheduled for merge" or the "installed" section was relevant. Then I noticed that in most (but not all) cases, the problem centered around a single package that had multiple, slightly different (mostly in the PYTHON_TARGETS variable) specs. At first, I thought that there was always just one such conflict package, all the other having a single new depender, rather than multiple. But I think now, that was a red herring. In your analysis, I didn't see that you made a distinction between "scheduled for emerge" and "installed" dependers. When using all potential dependers, I just wasn't able to following any chain to a useful conclusion. Perhaps it's there and just requires more thought. Anyway, my blanket --depclean kind of put a stop to that direction.
Re: [gentoo-user] update fails, but I don't see why [PROGRESS]
On Wednesday, 30 December 2020 07:22:34 GMT n952162 wrote: > 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? I mean: '/etc/portage/package.use' and any files if it is a directory, or under any subdirectories therein. '/etc/portage/make.conf' Any files referred to in /etc/portage/env/ or /etc/portage/package.env if you have configured any package specific emerge parameters there yourself. Any python related entries in /var/lib/portage/world. Run 'eselect python list' as well as 'cleanup' & 'update' to make sure there are no old version symlinks hanging on. If there is some deep dependency indicated by the output of emerge still asking for an old(er) python version, which portage will not resolve itself, then quickpkg it, uninstall it and re-run emerge. The above ought to get a stable portage able to update itself into a clean state. signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Re: ncurses; I think I wrecked my fresh install
On 30/12/20 01:04, Grant Edwards wrote: > 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. There is utf-16 - MS's default version. They wrote their unicode support *before* utf-8 really was a thing. So we have the nix's settling on an 8-bit char, and MS settling on a 16-bit char BEFORE that. Unbaking that mess would be fun ... So that file is probably something to do with MS and ASCII-16 :-) Cheers, Wol
Re: [gentoo-user] update fails, but I don't see why [PROGRESS]
On Wed, 30 Dec 2020 at 08:46, n952162 wrote: > 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. I tried walking you through the massive output from portage on one of these conflicts last week, was it helpful? The point either way, was that the slot conflict is not setuptools itself, but further down the dependency chain, where some package is unable to update to python 3.8, and it's dragging its dependencies back with it. Regards, Arve
