Discussion:
Upgrading mlocate: /var/lib/mlocate/ Permissions Warning.
(too old to reply)
Ralph Corderoy
2018-06-10 09:51:49 UTC
Permalink
Raw Message
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=packages/mlocate#n58
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
Tinu Weber
2018-06-10 11:00:33 UTC
Permalink
Raw Message
Post by Ralph Corderoy
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=packages/mlocate#n58
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)...
Post by Ralph Corderoy
$ 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
Ralph Corderoy
2018-06-10 11:50:04 UTC
Permalink
Raw Message
Hi Tinu,
Post by Tinu Weber
Post by Ralph Corderoy
https://git.archlinux.org/svntogit/packages.git/tree/trunk/PKGBUILD?h=packages/mlocate#n58
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?
Post by Tinu Weber
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.
Post by Tinu Weber
I assume this is because the previous version of mlocate (0.26-6) set
$ 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.
Post by Tinu Weber
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.
Post by Tinu Weber
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
Eli Schwartz via arch-general
2018-06-10 13:00:10 UTC
Permalink
Raw Message
Post by Ralph Corderoy
And I think that was correct since the package's `Makefile.am' has
dbdir = $(localstatedir)/mlocate
...
$(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?
Post by Ralph Corderoy
Post by Tinu Weber
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
Tinu Weber
2018-06-10 13:11:20 UTC
Permalink
Raw Message
Post by Ralph Corderoy
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 -
Post by Ralph Corderoy
And I think that was correct since the package's `Makefile.am' has
dbdir = $(localstatedir)/mlocate
...
$(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.
Post by Ralph Corderoy
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...
Post by Ralph Corderoy
Thus my wondering if the package is faulty for having 755.
Yeah, probably that is not intended.
Post by Ralph Corderoy
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
Eli Schwartz via arch-general
2018-06-10 13:20:38 UTC
Permalink
Raw Message
Post by Tinu Weber
Post by Ralph Corderoy
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 -
Post by Ralph Corderoy
And I think that was correct since the package's `Makefile.am' has
dbdir = $(localstatedir)/mlocate
...
$(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_76_13_03

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`.
Post by Tinu Weber
==> 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...
Post by Tinu Weber
Post by Ralph Corderoy
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. :)
Post by Tinu Weber
Post by Ralph Corderoy
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
Tinu Weber
2018-06-10 13:53:23 UTC
Permalink
Raw Message
Post by Eli Schwartz via arch-general
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.
Post by Eli Schwartz via arch-general
Post by Tinu Weber
==> 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).
Post by Eli Schwartz via arch-general
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
Eli Schwartz via arch-general
2018-06-10 14:18:21 UTC
Permalink
Raw Message
Post by Tinu Weber
Post by Eli Schwartz via arch-general
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.
Post by Eli Schwartz via arch-general
Post by Tinu Weber
==> 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).
Post by Eli Schwartz via arch-general
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
Tinu Weber
2018-06-10 15:24:48 UTC
Permalink
Raw Message
Post by Eli Schwartz via arch-general
Post by Tinu Weber
Post by Eli Schwartz via arch-general
Post by Tinu Weber
==> 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).
Post by Eli Schwartz via arch-general
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)
Post by Eli Schwartz via arch-general
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.
Post by Eli Schwartz via arch-general
...
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.

Loading...