[arch-general] Upgrading mlocate: /var/lib/mlocate/ Permissions Warning.
Hi, This morning's `pacman -Su' encountered (10/13) upgrading mlocate [######################] 100% warning: directory permissions differ on /var/lib/mlocate/ filesystem: 750 package: 755 (11/13) upgrading xkeyboard-config [######################] 100% when upgrading from version 0.26-6 to 0.26.git.20170220-1. Sure enough, afterwards drwxr-x--- 2 root locate 4096 Jun 10 00:01 /var/lib/mlocate -rw-r----- 1 root locate 16287372 Jun 10 00:01 /var/lib/mlocate/mlocate.db https://git.archlinux.org/svntogit/packages.git/tree/trunk/PKGBUILD?h=packag... seems to take care that /var/lib/locate is 750 on line 58, but that's `locate', not `mlocate', so perhaps `mlocate' needs a similar set up? $ zcat /var/lib/pacman/local/mlocate-0.26.git.20170220-1/mtree | > grep '^\./var/lib' ./var/lib time=1528233128.0 mode=755 type=dir ✓ ./var/lib/locate time=1528233128.0 mode=750 gid=21 type=dir ✗ ./var/lib/mlocate time=1528233128.0 mode=755 type=dir $ $ tar tvf /var/cache/pacman/pkg/mlocate-0.26.git.20170220-1-x86_64.pkg.tar.xz \ > --warning=no-unknown-keyword var/lib drwxr-xr-x root/root 0 2018-06-05 22:12 var/lib/ ✓ drwxr-x--- root/21 0 2018-06-05 22:12 var/lib/locate/ ✗ drwxr-xr-x root/root 0 2018-06-05 22:12 var/lib/mlocate/ $ -- Cheers, Ralph. https://plus.google.com/+RalphCorderoy
On Sun, Jun 10, 2018 at 10:51:49 +0100, Ralph Corderoy wrote:
This morning's `pacman -Su' encountered
(10/13) upgrading mlocate [######################] 100% warning: directory permissions differ on /var/lib/mlocate/ filesystem: 750 package: 755 (11/13) upgrading xkeyboard-config [######################] 100%
when upgrading from version 0.26-6 to 0.26.git.20170220-1. Sure enough, afterwards
drwxr-x--- 2 root locate 4096 Jun 10 00:01 /var/lib/mlocate -rw-r----- 1 root locate 16287372 Jun 10 00:01 /var/lib/mlocate/mlocate.db
https://git.archlinux.org/svntogit/packages.git/tree/trunk/PKGBUILD?h=packag... seems to take care that /var/lib/locate is 750 on line 58, but that's `locate', not `mlocate', so perhaps `mlocate' needs a similar set up?
I don't quite see the relation between locate an mlocate here (other than that they are provided by the same package and are listed next to each other in the mtree)...
$ zcat /var/lib/pacman/local/mlocate-0.26.git.20170220-1/mtree | > grep '^\./var/lib' ./var/lib time=1528233128.0 mode=755 type=dir ✓ ./var/lib/locate time=1528233128.0 mode=750 gid=21 type=dir ✗ ./var/lib/mlocate time=1528233128.0 mode=755 type=dir $ $ tar tvf /var/cache/pacman/pkg/mlocate-0.26.git.20170220-1-x86_64.pkg.tar.xz \ > --warning=no-unknown-keyword var/lib drwxr-xr-x root/root 0 2018-06-05 22:12 var/lib/ ✓ drwxr-x--- root/21 0 2018-06-05 22:12 var/lib/locate/ ✗ drwxr-xr-x root/root 0 2018-06-05 22:12 var/lib/mlocate/ $
The package wants /var/lib/mlocate to have 755, but the directory on your system has 750. I assume this is because the previous version of mlocate (0.26-6) set the permission that way: $ zcat .MTREE | tail -n4 → /set gid=21 mode=750 ./var/lib time=1491283536.206666666 mode=755 gid=0 type=dir ./var/lib/locate time=1491283536.206666666 type=dir → ./var/lib/mlocate time=1491283536.156666666 type=dir I assume pacman never touches permissions on existing directories, hence the warning. Best, Tinu
Hi Tinu,
https://git.archlinux.org/svntogit/packages.git/tree/trunk/PKGBUILD?h=packag... seems to take care that /var/lib/locate is 750 on line 58, but that's `locate', not `mlocate', so perhaps `mlocate' needs a similar set up?
I don't quite see the relation between locate an mlocate here (other than that they are provided by the same package and are listed next to each other in the mtree)...
Doesn't PKGBUILD explicitly ensuring `locate' is 750, `mlocate's filesystem value, suggest it should do similar for `mlocate' to avoid the mismatch?
The package wants /var/lib/mlocate to have 755, but the directory on your system has 750.
Yes, that's what I understood the warning to say.
I assume this is because the previous version of mlocate (0.26-6) set the permission that way:
$ zcat .MTREE | tail -n4 → /set gid=21 mode=750 ./var/lib time=1491283536.206666666 mode=755 gid=0 type=dir ./var/lib/locate time=1491283536.206666666 type=dir → ./var/lib/mlocate time=1491283536.156666666 type=dir
And I think that was correct since the package's `Makefile.am' has dbdir = $(localstatedir)/mlocate ... install-exec-local: $(MKDIR_P) "$(DESTDIR)$(dbdir)" -chgrp $(groupname) "$(DESTDIR)$(dbdir)" 2>/dev/null \ → && chmod g=rx,o= "$(DESTDIR)$(dbdir)" AFAICS that file hasn't changed between git's upstream/0.26 in the Debian repo and mlocate-0.26-14-gc98bf65 in the current one.
I assume pacman never touches permissions on existing directories,
I could understand if it doesn't automatically do that, but issue a warning instead, say.
hence the warning.
Thus my wondering if the package is faulty for having 755. If not, then presumably a PKGBUILD function gets added to convert existing installations? -- Cheers, Ralph. https://plus.google.com/+RalphCorderoy
On 06/10/2018 07:50 AM, Ralph Corderoy wrote:
And I think that was correct since the package's `Makefile.am' has
dbdir = $(localstatedir)/mlocate ... install-exec-local: $(MKDIR_P) "$(DESTDIR)$(dbdir)" -chgrp $(groupname) "$(DESTDIR)$(dbdir)" 2>/dev/null \ → && chmod g=rx,o= "$(DESTDIR)$(dbdir)"
AFAICS that file hasn't changed between git's upstream/0.26 in the Debian repo and mlocate-0.26-14-gc98bf65 in the current one.
I think that's incorrect, because those lines in the Makefile are never run. There's no group "mlocate" in a clean chroot, so this command errors and the whole install-exec-local hook gets skipped. Even more fun: some "genius" decided to send error messages to /dev/null, so it's not even immediately obvious why it errors, until you patch the Makefile.am and retry building. I suggest you report an upstream bug. At the very least this should be a ./configure option so distros can specify a UID/GID instead of some groupname that might not exist. ... However, I do not have mlocate installed and I cannot understand why, if I try building the old mlocate PKGBUILD (after hacking the source array because anonscm is dead, but they've got tarballs of the repositories; I don't understand why it ever used that site in the first place)... I get a built package that contains: drwxr-xr-x 0 root root 0 Jun 10 08:22 var/lib/mlocate/ Which is exactly what the current PKGBUILD contains. This is definitely a bug, since it should be owned by the mlocate group, but the bug is not the one you think it is. Please report a bug for the mlocate package. This is wrong and has always been wrong, and I'm not sure why this is the first time it was noticed. Did many people fix their directory ownership/permissions by hand or something, then forget to report a bug? Did you do so too?
I assume pacman never touches permissions on existing directories,
Correct, directories are not automatically removed and reinstalled and users might wish to modify the permissions for many reasons (which is not typically the case for files). -- Eli Schwartz Bug Wrangler and Trusted User
On Sun, Jun 10, 2018 at 12:50:04 +0100, Ralph Corderoy wrote:
Doesn't PKGBUILD explicitly ensuring `locate' is 750, `mlocate's filesystem value, suggest it should do similar for `mlocate' to avoid the mismatch?
No idea, but it's possible. Especially because -
And I think that was correct since the package's `Makefile.am' has
dbdir = $(localstatedir)/mlocate ... install-exec-local: $(MKDIR_P) "$(DESTDIR)$(dbdir)" -chgrp $(groupname) "$(DESTDIR)$(dbdir)" 2>/dev/null \ → && chmod g=rx,o= "$(DESTDIR)$(dbdir)"
What happens if you remove the leading dash from that line? I assume either `chrgrp` or `chmod` fails at some point... I tried building mlocate myself, but I run into this error with makepkg: ==> Making package: mlocate 0.26.git.20170220-1 (Sun 10 Jun 2018 15:03:17 CEST) ==> Checking runtime dependencies... ==> Checking buildtime dependencies... ==> Retrieving sources... ==> ERROR: /home/ayekat/devel/pkgbuilds/mlocate/trunk/mlocate is not a clone of https://pagure.io/mlocate.git Aborting... Same error with makechrootpkg. I can't find anything weird with the mlocate PKGBUILD though.
AFAICS that file hasn't changed between git's upstream/0.26 in the Debian repo and mlocate-0.26-14-gc98bf65 in the current one.
It's indeed odd...
Thus my wondering if the package is faulty for having 755.
Yeah, probably that is not intended.
If not, then presumably a PKGBUILD function gets added to convert existing installations?
I'm sorry, but I don't understand that sentence. Best, Tinu
On 06/10/2018 09:11 AM, Tinu Weber wrote:
On Sun, Jun 10, 2018 at 12:50:04 +0100, Ralph Corderoy wrote:
Doesn't PKGBUILD explicitly ensuring `locate' is 750, `mlocate's filesystem value, suggest it should do similar for `mlocate' to avoid the mismatch?
No idea, but it's possible. Especially because -
And I think that was correct since the package's `Makefile.am' has
dbdir = $(localstatedir)/mlocate ... install-exec-local: $(MKDIR_P) "$(DESTDIR)$(dbdir)" -chgrp $(groupname) "$(DESTDIR)$(dbdir)" 2>/dev/null \ → && chmod g=rx,o= "$(DESTDIR)$(dbdir)"
What happens if you remove the leading dash from that line? I assume either `chrgrp` or `chmod` fails at some point...
Makefile syntax is documented at http://pubs.opengroup.org/onlinepubs/9699919799/utilities/make.html#tag_20_7... This just suppresses the behavior of "if this command fails, immediately exit 1 instead of trying to do anything else". It's a fancy way of doing `|| true`.
I tried building mlocate myself, but I run into this error with makepkg:
==> Making package: mlocate 0.26.git.20170220-1 (Sun 10 Jun 2018 15:03:17 CEST) ==> Checking runtime dependencies... ==> Checking buildtime dependencies... ==> Retrieving sources... ==> ERROR: /home/ayekat/devel/pkgbuilds/mlocate/trunk/mlocate is not a clone of https://pagure.io/mlocate.git Aborting...
Same error with makechrootpkg. I can't find anything weird with the mlocate PKGBUILD though.
The obvious question would be... since makepkg (not makechrootpkg) told you that that directory is not a clone of that url, then what is it a clone of instead? I'm not sure how much clearer we could make that error message. If there's something makepkg is doing dreadfully wrong in that error message reporting, please tell us so we can fix it...
AFAICS that file hasn't changed between git's upstream/0.26 in the Debian repo and mlocate-0.26-14-gc98bf65 in the current one.
It's indeed odd...
It's not odd at all, unless you missed my post shortly before yours. :)
If not, then presumably a PKGBUILD function gets added to convert existing installations?
I'm sorry, but I don't understand that sentence.
I'm blindly assuming this was intended to be "a post-install script to fix it", but even then no, plus it wouldn't really get rid of the errors. -- Eli Schwartz Bug Wrangler and Trusted User
On Sun, Jun 10, 2018 at 09:20:38 -0400, Eli Schwartz via arch-general wrote:
It's a fancy way of doing `|| true`.
Yes, that I knew - I just thought that it would make Make stop at the error (message) rather than continuing (although I admit one could also just scroll back to see the error). I only noticed the 2>/dev/null nonsense (which makes my suggestion useless) after sending my mail and then seeing yours, where you mentioned that issue.
I tried building mlocate myself, but I run into this error with makepkg:
==> Making package: mlocate 0.26.git.20170220-1 (Sun 10 Jun 2018 15:03:17 CEST) ==> Checking runtime dependencies... ==> Checking buildtime dependencies... ==> Retrieving sources... ==> ERROR: /home/ayekat/devel/pkgbuilds/mlocate/trunk/mlocate is not a clone of https://pagure.io/mlocate.git Aborting...
Same error with makechrootpkg. I can't find anything weird with the mlocate PKGBUILD though.
The obvious question would be... since makepkg (not makechrootpkg) told you that that directory is not a clone of that url, then what is it a clone of instead?
It is not a git repo at all (or rather just https://git.archlinux.org/svntogit/packages.git).
I'm not sure how much clearer we could make that error message. If there's something makepkg is doing dreadfully wrong in that error message reporting, please tell us so we can fix it...
No, the error message is clear so far, but why would that even be an issue at that point? From what I've seen, for git sources, makepkg fetches them into a bare repository. But in the case of mlocate, it just creates `mlocate` and `mlocate/src` (empty directory), and then complains and errors out. I assume that it builds fine on your machine, though, so I will need to find out how my local setup differs from a more accepted Arch Linux setup. Best, Tinu
On 06/10/2018 09:53 AM, Tinu Weber wrote:
On Sun, Jun 10, 2018 at 09:20:38 -0400, Eli Schwartz via arch-general wrote:
It's a fancy way of doing `|| true`.
Yes, that I knew - I just thought that it would make Make stop at the error (message) rather than continuing (although I admit one could also just scroll back to see the error).
I only noticed the 2>/dev/null nonsense (which makes my suggestion useless) after sending my mail and then seeing yours, where you mentioned that issue.
I tried building mlocate myself, but I run into this error with makepkg:
==> Making package: mlocate 0.26.git.20170220-1 (Sun 10 Jun 2018 15:03:17 CEST) ==> Checking runtime dependencies... ==> Checking buildtime dependencies... ==> Retrieving sources... ==> ERROR: /home/ayekat/devel/pkgbuilds/mlocate/trunk/mlocate is not a clone of https://pagure.io/mlocate.git Aborting...
Same error with makechrootpkg. I can't find anything weird with the mlocate PKGBUILD though.
The obvious question would be... since makepkg (not makechrootpkg) told you that that directory is not a clone of that url, then what is it a clone of instead?
It is not a git repo at all (or rather just https://git.archlinux.org/svntogit/packages.git).
I'm not sure how much clearer we could make that error message. If there's something makepkg is doing dreadfully wrong in that error message reporting, please tell us so we can fix it...
No, the error message is clear so far, but why would that even be an issue at that point? From what I've seen, for git sources, makepkg fetches them into a bare repository. But in the case of mlocate, it just creates `mlocate` and `mlocate/src` (empty directory), and then complains and errors out.
What src directory??? Hm... oh, wait, this is probably https://bugs.archlinux.org/task/58865 I'm going to take a wild guess that some component of /home/ayekat/devel/pkgbuilds/mlocate/trunk/mlocate is a symlink. ... This does explain why it thinks you've got an invalid clone. It's considering that directory to be the already-cloned sources, *because* it's an existing directory which is not empty. This despite the fact that it's only non-empty due to a makepkg bug from 2012 which only recently got exposed. So instead of cloning the source, it is trying to pull the source, after checking git config --get remote.origin.url (which fails because it's not a repo, and therefore it's checking the parent repo which is actually an svntogit checkout). You could work around that by using $BUILDDIR, in which case it will create srcdir=$BUILDDIR/mlocate/src as intended (instead of srcdir=$PWD/mlocate/src which is not intended) -- Eli Schwartz Bug Wrangler and Trusted User
On Sun, Jun 10, 2018 at 10:18:21 -0400, Eli Schwartz via arch-general wrote:
On 06/10/2018 09:53 AM, Tinu Weber wrote:
On Sun, Jun 10, 2018 at 09:20:38 -0400, Eli Schwartz via arch-general wrote:
On 06/10/2018 09:11 AM, Tinu Weber wrote:
I tried building mlocate myself, but I run into this error with makepkg:
==> Making package: mlocate 0.26.git.20170220-1 (Sun 10 Jun 2018 15:03:17 CEST) ==> Checking runtime dependencies... ==> Checking buildtime dependencies... ==> Retrieving sources... ==> ERROR: /home/ayekat/devel/pkgbuilds/mlocate/trunk/mlocate is not a clone of https://pagure.io/mlocate.git Aborting...
Same error with makechrootpkg. I can't find anything weird with the mlocate PKGBUILD though.
The obvious question would be... since makepkg (not makechrootpkg) told you that that directory is not a clone of that url, then what is it a clone of instead?
It is not a git repo at all (or rather just https://git.archlinux.org/svntogit/packages.git).
I'm not sure how much clearer we could make that error message. If there's something makepkg is doing dreadfully wrong in that error message reporting, please tell us so we can fix it...
No, the error message is clear so far, but why would that even be an issue at that point? From what I've seen, for git sources, makepkg fetches them into a bare repository. But in the case of mlocate, it just creates `mlocate` and `mlocate/src` (empty directory), and then complains and errors out.
What src directory???
Ah, I'm sorry, it's: ~/devel/pkgbuilds/mlocate/trunk/mlocate/ ~/devel/pkgbuilds/mlocate/trunk/mlocate/src/ rather than: ~/devel/pkgbuilds/mlocate/trunk/mlocate/ ~/devel/pkgbuilds/mlocate/trunk/mlocate/branches/ ~/devel/pkgbuilds/mlocate/trunk/mlocate/config ~/devel/pkgbuilds/mlocate/trunk/mlocate/... (other bare repo things)
Hm... oh, wait, this is probably https://bugs.archlinux.org/task/58865
I'm going to take a wild guess that some component of /home/ayekat/devel/pkgbuilds/mlocate/trunk/mlocate is a symlink.
Oh, you're right, ~/devel/pkgbuilds is a symlink to ~/.local/var/lib/pacman/pkgbuilds. Building mlocate in the "real" path works (or at least, it errors out a lot later due to a failing test). I now also notice that this is actually the case for all other packages in ~/devel/pkgbuilds that clone a git repo.
...
This does explain why it thinks you've got an invalid clone. It's considering that directory to be the already-cloned sources, *because* it's an existing directory which is not empty. This despite the fact that it's only non-empty due to a makepkg bug from 2012 which only recently got exposed.
So instead of cloning the source, it is trying to pull the source, after checking git config --get remote.origin.url (which fails because it's not a repo, and therefore it's checking the parent repo which is actually an svntogit checkout).
You could work around that by using $BUILDDIR, in which case it will create srcdir=$BUILDDIR/mlocate/src as intended (instead of srcdir=$PWD/mlocate/src which is not intended)
BUILDDIR works if I give it another directory. But `BUILDDIR="$(pwd -P)" makepkg` still fails (but to be honest, that's more me just trying random things I don't really understand, based on https://lists.archlinux.org/pipermail/pacman-dev/2018-June/022579.html ^^). But either way, thanks a lot for the support! (also, sorry for sort of hijacking the thread) Best, Tinu P.S. To confirm the original assumption: after modifying Makefile.am accordingly, package() fails here: ... chgrp locate "/home/ayekat/.local/var/lib/pacman/pkgbuilds/mlocate/trunk/pkg/mlocate/var/lib/mlocate" \ && chmod g=rx,o= "/home/ayekat/.local/var/lib/pacman/pkgbuilds/mlocate/trunk/pkg/mlocate/var/lib/mlocate" chgrp: invalid group: ‘locate’ make[2]: *** [Makefile:1455: install-exec-local] Error 1 ... So I second Eli's suggestion to report this upstream as a bug.
participants (3)
-
Eli Schwartz
-
Ralph Corderoy
-
Tinu Weber