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: 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 +0000
Modify: 2020-10-25 16:25:42.815894988 +0000
Change: 2020-10-25 16:25:42.892896366 +0000
Birth: 2020-10-25 16:25:42.814894971 +0000
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.000000000 +0100
Modify: 2020-12-30 20:53:12.000000000 +0100
Change: 2020-12-30 20:53:12.000000000 +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.
