Re: dnf system-upgrade f36->f37: mlocate / plocate conflict
On Sun, Dec 25, 2022 at 01:26:07PM -0600, Richard Shaw wrote: > On my laptop when I tried to do a dnf system-upgrade from f36->37 I ended > up getting a conflict with mlocate and plocate. > > Since I remember the thread I just did a "dnf swap" which solved the issue > but it could be confusing to users not aware. > > Was this supposed to happen automagically? Back in https://bugzilla.redhat.com/show_bug.cgi?id=2052433 we decided to add Obsoletes only for F<=36. The plan was to retire mlocate in F37. But that never happened. I updated the Obsoletes in F37 and rawhide to cover F37 and F38 and started a build now. I think we should do the retirement of mlocate in rawhide now. There doesn't seem to be a good reason to keep it around. Zbyszek ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
dnf system-upgrade f36->f37: mlocate / plocate conflict
On my laptop when I tried to do a dnf system-upgrade from f36->37 I ended up getting a conflict with mlocate and plocate. Since I remember the thread I just did a "dnf swap" which solved the issue but it could be confusing to users not aware. Was this supposed to happen automagically? Thanks, Richard ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F36 Change: Plocate as the default locate implementation (Self-Contained Change proposal)
On 21. 01. 22 17:03, Zdenek Pytela wrote:
Hey folks,
I've just noticed that `ausearch -m AVC,USER_AVC -ts recent` lists a lot of:
type=AVC msg=audit(1642770831.616:31668): avc: denied { read } for
pid=866275 comm="locate" name="plocate.db" dev="dm-0" ino=5268062
scontext=system_u:system_r:setroubleshootd_t:s0
tcontext=system_u:object_r:var_lib_t:s0 tclass=file permissive=0
Is this a bug, or some kind of error in configuration?
plocate uses /var/lib/plocate as its data directory, so it needs to have
assigned the correct label in selinux-policy. I've already submitted a PR for
the change.
https://github.com/fedora-selinux/selinux-policy/pull/1018
<https://github.com/fedora-selinux/selinux-policy/pull/1018>
Thanks!
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
Re: F36 Change: Plocate as the default locate implementation (Self-Contained Change proposal)
On Fri, Jan 21, 2022 at 2:24 PM Miro Hrončok wrote:
> On 23. 11. 21 18:18, Ben Cotton wrote:
> >
> https://fedoraproject.org/wiki/Changes/Plocate_as_the_default_locate_implementation
> >
> > == Summary ==
> > The venerable `mlocate` program is replaced by `plocate` — a
> > compatible reimplementation that is faster and uses less disk space.
> >
> >
> > == Owner ==
> > * Name: [[User:Zbyszek| Zbigniew Jędrzejewski-Szmek]]
> > * Email: zbyszek at in.waw.pl
> > * Name: [[User:Msekleta| Michal Sekletár]]
> > * Email: msekleta at redhat.com
> > ...
>
> Hey folks,
>
> I've just noticed that `ausearch -m AVC,USER_AVC -ts recent` lists a lot
> of:
>
> type=AVC msg=audit(1642770831.616:31668): avc: denied { read } for
> pid=866275 comm="locate" name="plocate.db" dev="dm-0" ino=5268062
> scontext=system_u:system_r:setroubleshootd_t:s0
> tcontext=system_u:object_r:var_lib_t:s0 tclass=file permissive=0
>
> Is this a bug, or some kind of error in configuration?
>
plocate uses /var/lib/plocate as its data directory, so it needs to have
assigned the correct label in selinux-policy. I've already submitted a PR
for the change.
https://github.com/fedora-selinux/selinux-policy/pull/1018
>
> --
> Miro Hrončok
> --
> Phone: +420777974800
> IRC: mhroncok
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure
>
--
Zdenek Pytela
Security SELinux team
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
Re: F36 Change: Plocate as the default locate implementation (Self-Contained Change proposal)
On 23. 11. 21 18:18, Ben Cotton wrote:
https://fedoraproject.org/wiki/Changes/Plocate_as_the_default_locate_implementation
== Summary ==
The venerable `mlocate` program is replaced by `plocate` — a
compatible reimplementation that is faster and uses less disk space.
== Owner ==
* Name: [[User:Zbyszek| Zbigniew Jędrzejewski-Szmek]]
* Email: zbyszek at in.waw.pl
* Name: [[User:Msekleta| Michal Sekletár]]
* Email: msekleta at redhat.com
...
Hey folks,
I've just noticed that `ausearch -m AVC,USER_AVC -ts recent` lists a lot of:
type=AVC msg=audit(1642770831.616:31668): avc: denied { read } for
pid=866275 comm="locate" name="plocate.db" dev="dm-0" ino=5268062
scontext=system_u:system_r:setroubleshootd_t:s0
tcontext=system_u:object_r:var_lib_t:s0 tclass=file permissive=0
Is this a bug, or some kind of error in configuration?
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
Re: F36 Change: Plocate as the default locate implementation (Self-Contained Change proposal)
`plocate` does not have an option which `mlocate` [1] has: > -A, --all >Print only names which match all non-option arguments, not >those matching one or more non-option arguments. The same could be achieved using extended regular expressions i.e. `--regex`, but it's cumbersome. Say I want to find out all documents about Fedora IoT security. Compare: mlocate -i -A fedora iot security with: plocate -i --regex 'fedora.*iot.*security|fedora.*security.*iot|iot.*fedora.*security|iot.*security.*fedora|security.*fedora.*iot|security.*iot.*fedora' This is needed because the order of the words is not fixed; results could include for example `Security/Fedora IoT.pdf` or `Fedora/IoT/Security.pdf`. Speaking of security, `systemd-analyze security plocate-updatedb.service` suggests a couple of improvements which could be made, e.g. LockPersonality or ProtectClock. [1]: https://man7.org/linux/man-pages/man1/locate.1.html ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F36 Change: Plocate as the default locate implementation (Self-Contained Change proposal)
On Wed, Dec 01, 2021 at 03:00:34PM -0500, Garry T. Williams wrote: > On Wednesday, December 1, 2021 9:10:33 AM EST Jonathan Wakely wrote: > > Also, the plocate-updatedb service was not started after installing > > it, so I can't use locate until the DB is created. Is that expected? > > Does it wait until the timer runs it? > > I believe that is normal. Earlier releases of mlocate were never > enabled to run -- I always had to enable (the timer) and start them. Define "normal". I set up the *p*locate scripts to start the service immediately. Obviously this only works on a live system, with systemd installed and active. My assumption is that if you're installing plocate on a running system, you probably want to use it, and this way after approx. 30—60 seconds you can. Zbyszek ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F36 Change: Plocate as the default locate implementation (Self-Contained Change proposal)
On Wed, Dec 01, 2021 at 08:55:44PM +, Zbigniew Jędrzejewski-Szmek wrote: > On Wed, Dec 01, 2021 at 02:13:07PM -0500, Chris Murphy wrote: > > On Tue, Nov 23, 2021 at 4:54 PM Zbigniew Jędrzejewski-Szmek > > wrote: > > > > > > On Tue, Nov 23, 2021 at 01:52:43PM -0500, Chris Murphy wrote: > > > > On Tue, Nov 23, 2021 at 12:19 PM Ben Cotton wrote: > > > > > > > > > == How To Test == > > > > > # Install `plocate` (`sudo dnf install plocate --allowerasing`) > > > > > # Wait for `plocate-updatedb.service` to finish (`sudo systemctl start > > > > > plocate-updatedb.service`) > > > > > # Use `plocate pattern` or `plocate -r ` to search for files. > > > > > > > > Works for me. Also fixes this old bug where mlocate pruned bind mount > > > > locations, which resulted in /home on Btrfs not being indexed. > > > > https://bugzilla.redhat.com/show_bug.cgi?id=906591 > > > > > > > > Note for laptop users, plocate-updatedb.service contains > > > > ConditionACPower=true, so if you're getting errors locating files, it > > > > might be because the initial database isn't being created because no > > > > AC power. > > > > > > Ack. (I assume that most people have the laptop on AC at least some > > > of the time, so the db will get updated sooner or later. In the worst > > > case, if the laptop is only charged while off or suspended, it would be > > > necessary to remove the conditional. But I think that's a rare case, and > > > the default is good.) > > > > > > > > == User Experience == > > > > > Users should not notice the difference. Installing `plocate` > > > > > automatically removes `mlocate`. The new implementation is generally > > > > > compatible with the old one in all common cases, and provides some > > > > > additional options. > > > > > > > > I'm definitely noticing a difference. I'm not sure it was ever correct > > > > that updatedb.conf was pruning bind mounts on Fedora. It's not the > > > > mlocate default, but it is what Fedora has been using for years > > > > (defacto default on Fedora). > > > > > > That's a known-fixed bug. I didn't mention it because, well, it was > > > considered a bug in mlocate. ¯\_(ツ)_/¯ > > > > It's not a fixed bug. > > Sorry, I meant that it's fixed in plocate, which simply does exhibit > this behaviour. Ah, OK, this has been cleared up in another part of the thread ;) Zbyszek ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F36 Change: Plocate as the default locate implementation (Self-Contained Change proposal)
On Wed, Dec 01, 2021 at 02:13:07PM -0500, Chris Murphy wrote: > On Tue, Nov 23, 2021 at 4:54 PM Zbigniew Jędrzejewski-Szmek > wrote: > > > > On Tue, Nov 23, 2021 at 01:52:43PM -0500, Chris Murphy wrote: > > > On Tue, Nov 23, 2021 at 12:19 PM Ben Cotton wrote: > > > > > > > == How To Test == > > > > # Install `plocate` (`sudo dnf install plocate --allowerasing`) > > > > # Wait for `plocate-updatedb.service` to finish (`sudo systemctl start > > > > plocate-updatedb.service`) > > > > # Use `plocate pattern` or `plocate -r ` to search for files. > > > > > > Works for me. Also fixes this old bug where mlocate pruned bind mount > > > locations, which resulted in /home on Btrfs not being indexed. > > > https://bugzilla.redhat.com/show_bug.cgi?id=906591 > > > > > > Note for laptop users, plocate-updatedb.service contains > > > ConditionACPower=true, so if you're getting errors locating files, it > > > might be because the initial database isn't being created because no > > > AC power. > > > > Ack. (I assume that most people have the laptop on AC at least some > > of the time, so the db will get updated sooner or later. In the worst > > case, if the laptop is only charged while off or suspended, it would be > > necessary to remove the conditional. But I think that's a rare case, and > > the default is good.) > > > > > > == User Experience == > > > > Users should not notice the difference. Installing `plocate` > > > > automatically removes `mlocate`. The new implementation is generally > > > > compatible with the old one in all common cases, and provides some > > > > additional options. > > > > > > I'm definitely noticing a difference. I'm not sure it was ever correct > > > that updatedb.conf was pruning bind mounts on Fedora. It's not the > > > mlocate default, but it is what Fedora has been using for years > > > (defacto default on Fedora). > > > > That's a known-fixed bug. I didn't mention it because, well, it was > > considered a bug in mlocate. ¯\_(ツ)_/¯ > > It's not a fixed bug. Sorry, I meant that it's fixed in plocate, which simply does exhibit this behaviour. Zbyszek ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F36 Change: Plocate as the default locate implementation (Self-Contained Change proposal)
On Wednesday, December 1, 2021 9:10:33 AM EST Jonathan Wakely wrote: > Also, the plocate-updatedb service was not started after installing > it, so I can't use locate until the DB is created. Is that expected? > Does it wait until the timer runs it? I believe that is normal. Earlier releases of mlocate were never enabled to run -- I always had to enable (the timer) and start them. -- Garry T. Williams ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F36 Change: Plocate as the default locate implementation (Self-Contained Change proposal)
On Wed, Nov 24, 2021 at 3:25 AM Zbigniew Jędrzejewski-Szmek wrote: > > On Tue, Nov 23, 2021 at 05:52:26PM -0500, Garry T. Williams wrote: > > On Tuesday, November 23, 2021 4:53:12 PM EST Zbigniew Jędrzejewski-Szmek > > wrote: > > > On Tue, Nov 23, 2021 at 01:52:43PM -0500, Chris Murphy wrote: > > > > I'm definitely noticing a difference. I'm not sure it was ever correct > > > > that updatedb.conf was pruning bind mounts on Fedora. It's not the > > > > mlocate default, but it is what Fedora has been using for years > > > > (defacto default on Fedora). > > > > > > That's a known-fixed bug. > > > > Not fixed as far as I know[*]. > > known-fixed-in-plocate ;) OK super. (I should have read the whole thread...) -- Chris Murphy ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F36 Change: Plocate as the default locate implementation (Self-Contained Change proposal)
On Tue, Nov 23, 2021 at 4:54 PM Zbigniew Jędrzejewski-Szmek wrote: > > On Tue, Nov 23, 2021 at 01:52:43PM -0500, Chris Murphy wrote: > > On Tue, Nov 23, 2021 at 12:19 PM Ben Cotton wrote: > > > > > == How To Test == > > > # Install `plocate` (`sudo dnf install plocate --allowerasing`) > > > # Wait for `plocate-updatedb.service` to finish (`sudo systemctl start > > > plocate-updatedb.service`) > > > # Use `plocate pattern` or `plocate -r ` to search for files. > > > > Works for me. Also fixes this old bug where mlocate pruned bind mount > > locations, which resulted in /home on Btrfs not being indexed. > > https://bugzilla.redhat.com/show_bug.cgi?id=906591 > > > > Note for laptop users, plocate-updatedb.service contains > > ConditionACPower=true, so if you're getting errors locating files, it > > might be because the initial database isn't being created because no > > AC power. > > Ack. (I assume that most people have the laptop on AC at least some > of the time, so the db will get updated sooner or later. In the worst > case, if the laptop is only charged while off or suspended, it would be > necessary to remove the conditional. But I think that's a rare case, and > the default is good.) > > > > == User Experience == > > > Users should not notice the difference. Installing `plocate` > > > automatically removes `mlocate`. The new implementation is generally > > > compatible with the old one in all common cases, and provides some > > > additional options. > > > > I'm definitely noticing a difference. I'm not sure it was ever correct > > that updatedb.conf was pruning bind mounts on Fedora. It's not the > > mlocate default, but it is what Fedora has been using for years > > (defacto default on Fedora). > > That's a known-fixed bug. I didn't mention it because, well, it was > considered a bug in mlocate. ¯\_(ツ)_/¯ It's not a fixed bug. It's an intentional departure from the default, and it's still a problem in fresh Fedora installations today. i.e. the mlocate default in updatedb.conf #PRUNE_BIND_MOUNTS = "yes" But in Fedora it ships uncommented, so /home is not indexed on default installs because Btrfs "home" subvolume mounted at /home is a bind mount behind the scenes. Recently Silverblue fixed this, as it makes considerable use of bind mounts, by (re)commenting the pruning of bind mounts. -- Chris Murphy ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F36 Change: Plocate as the default locate implementation (Self-Contained Change proposal)
On Wed, Dec 01, 2021 at 02:10:33PM +, Jonathan Wakely wrote:
> I have just installed plocate to try it on F34, and got:
>
> warning: /etc/updatedb.conf saved as /etc/updatedb.conf.rpmsave
>
> I reviewed the changes, and the new file is empty. Users will notice
> the difference. Is that expected? Is it because I'm still on F34?
I think rpm is saving the file because if was declared as
%config(noreplace) by mlocate. So when you install plocate, mlocate gets
uninstalled, and rpm moves the file out of the way.
plocate just declares %ghost %{_sysconfdir}/updatedb.conf, because there
is no need for the file. If I understand correctly, rpm created an
empty file for you. I don't know why it would do that.
Anyway, if the the %ghost is not appropriate, or it should be some
more complex incantation, suggests are welcome.
> Also, the plocate-updatedb service was not started after installing
> it, so I can't use locate until the DB is created. Is that expected?
> Does it wait until the timer runs it?
Do you have fedora-release-common-34-39 installed? The service should
run once immediately after the installation.
Zbyszek
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
Re: F36 Change: Plocate as the default locate implementation (Self-Contained Change proposal)
On Tue, 23 Nov 2021 at 17:20, Ben Cotton wrote: > == Upgrade/compatibility impact == > The upgrade should be mostly invisible. It is possible that somebody > might be relying on some very specific `mlocate` behaviour or parsing > the `mlocate` database directly, but no such cases are currently > known. > > == How To Test == > # Install `plocate` (`sudo dnf install plocate --allowerasing`) > # Wait for `plocate-updatedb.service` to finish (`sudo systemctl start > plocate-updatedb.service`) > # Use `plocate pattern` or `plocate -r ` to search for files. > > == User Experience == > Users should not notice the difference. Installing `plocate` > automatically removes `mlocate`. The new implementation is generally > compatible with the old one in all common cases, and provides some > additional options. I have just installed plocate to try it on F34, and got: warning: /etc/updatedb.conf saved as /etc/updatedb.conf.rpmsave I reviewed the changes, and the new file is empty. Users will notice the difference. Is that expected? Is it because I'm still on F34? Also, the plocate-updatedb service was not started after installing it, so I can't use locate until the DB is created. Is that expected? Does it wait until the timer runs it? ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F36 Change: Plocate as the default locate implementation (Self-Contained Change proposal)
On Tue, Nov 23, 2021 at 12:18:56PM -0500, Ben Cotton wrote: > https://fedoraproject.org/wiki/Changes/Plocate_as_the_default_locate_implementation > > == Summary == > The venerable `mlocate` program is replaced by `plocate` — a > compatible reimplementation that is faster and uses less disk space. > > > == Owner == > * Name: [[User:Zbyszek| Zbigniew Jędrzejewski-Szmek]] > * Email: zbyszek at in.waw.pl > * Name: [[User:Msekleta| Michal Sekletár]] > * Email: msekleta at redhat.com > Thanks for doing this! One long-standing issue (that's becoming more relevant now that Workstation and desktop spins switched to Btrfs in F33, and Cloud in F35) with our mlocate is that it's configured to skip bind mounts by default: https://bugzilla.redhat.com/show_bug.cgi?id=906591 which affects both Btrfs-based installs and rpm-ostree ones, because `/home` is on a Btrfs subvolume, and on a bind mount on Silverblue even predating Btrfs being default, and both look like bind mounts. This was overridden for Silverblue and other rpm-ostree based spins: https://github.com/fedora-silverblue/issue-tracker/issues/76#issuecomment-705507196 but using a RPM scriptlet, and I'm glad with plocate we can just use the default settings rather than having to hack in yet another exception for Btrfs systems. Users likely expect `/home` to be indexed if they bother using `locate`. Best regards, -- Michel Alexandre Salim profile: https://keyoxide.org/mic...@michel-slm.name signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F36 Change: Plocate as the default locate implementation (Self-Contained Change proposal)
On Wed, Nov 24, 2021 at 07:14:47PM +0900, Dominique Martinet wrote: > Zbigniew Jędrzejewski-Szmek wrote on Wed, Nov 24, 2021 at 09:23:37AM +: > > > The consequence of that is it takes much longer to complete because the > > > clock is down: what previously normally took ~55s real for ~27s of CPU > > > time now takes 7m10 for 85s of CPU time -- but honestly I don't care how > > > long this takes if it's not noticeable, this is perfect. Thanks again! > > > > That's a really long time… 55/27 s seems fairly standard, e.g. I get 43/22 s > > with a 256 GB SATA disk. But 440/85 s is quite a bit worse. > > I really don't think it matters: this is a background job. It matters in the sense that the total energy consumption will be higher. I don't think we should try to work around hardware issues at the level of individual programs trying to influence decisions. This can never work, except as a local hack for some issue. > > > I would have suggested also adding Nice=5 or something but I don't think > > > it's required with this. > > > > I think that with IOSchedulingClass=idle, niceness doesn't matter anymore. > > Hmm, I'm not sure what makes you think that. Brainfart, I was thinking about CPUSchedulingPolicy=. I think it would make sense to set CPUSchedulingPolicy=batch. Zbyszek ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F36 Change: Plocate as the default locate implementation (Self-Contained Change proposal)
Zbigniew Jędrzejewski-Szmek wrote on Wed, Nov 24, 2021 at 09:23:37AM +: > > The consequence of that is it takes much longer to complete because the > > clock is down: what previously normally took ~55s real for ~27s of CPU > > time now takes 7m10 for 85s of CPU time -- but honestly I don't care how > > long this takes if it's not noticeable, this is perfect. Thanks again! > > That's a really long time… 55/27 s seems fairly standard, e.g. I get 43/22 s > with a 256 GB SATA disk. But 440/85 s is quite a bit worse. I really don't think it matters: this is a background job. If I want to refresh the locate database for a one-time thing, e.g. because I just updated a lot of files and look for something new, I'd run `sudo updatedb` not `sudo systemctl start plocate-updatedb`... > > Steinar would you consider adding this to the upstream service file? > > I don't think this qualifies as a good default. I would consider it a > hack to fix a local hardware problem. Fans in a laptop simply must not > be loud enough to be annoying. Well, there's annoying and annoying - I'm sure it could be better but I can accept hearing laptop fans if it means I can build a kernel slightly faster (because getting more heat out means thermal throttle doesn't need to hold back as much); but I don't want to hear the fan at random times when I'm not doing anything, even if it's not a horrible sound. Even for a fanless system, the fan itself won't be annoying, but say you want to compile something just as plocate has heated up the CPU and you'll get much lower performance for what you actually wanted to do at this time -- so it makes sense for real background stuff to stay close to idle. (I'm not sure how stuff like intel/amd's "turbo" mode works, but I believe it won't work if your cpu is hot, and I'd take this even for my servers or other non-noisy systems) > > (Zbigniew, does systemd just ignore the setting on systems where cpu > > accounting has not been enabled? iirc some distros still have it off and > > upstream might want to provide defaults that work everywhere) > > > > I would have suggested also adding Nice=5 or something but I don't think > > it's required with this. > > I think that with IOSchedulingClass=idle, niceness doesn't matter anymore. Hmm, I'm not sure what makes you think that. From what I can tell, if nice has been set, the ioprio will derive a value from it automatically (ionice = (nice + 20) / 5 for best effort, and also ioprio set to idle if set to SCHED_IDLE -- see include/linux/ioprio.h in the kernel) I however don't see anything that would hint that the other way around is true, it really seems to be specific to the IO scheduler to me. I don't see anything in block/ioprio.c that would also affect task scheduling. I'll grant you that if no IO can be done, the process will be stuck waiting for IO and not consume a lot of CPU, but that's not really the same as being niced. -- Dominique ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F36 Change: Plocate as the default locate implementation (Self-Contained Change proposal)
On Wed, Nov 24, 2021 at 06:10:18PM +0900, Dominique Martinet wrote: > > Please try with the following file: > > > > # /etc/systemd/system/plocate-updatedb.service.d/limits.conf > > [Service] > > CPUAccounting=yes > > CPUQuota=20% > > > > (then 'sudo systemctl daemon-reload && sudo systemctl restart > > plocate-updatedb'). > > I think this could work. > > That's a nice one. > > For my particular laptop, with governor=performance I'm cutting it too > close to fan being audible (and firefox etc also regularily kicks it > in), so I'm not surprised even with CPUQuota=20% it's enough to be > audible, albeit at a lower level than full throttle (something like +5° > instead of +10-15 from where core temp usually stands, that makes a > difference to fan RPM) > > With governor=powersave though it's really worlds appart, no CPUQuota > immediately scales up to close to the max and heats just like > performance would but with this I barely see any difference from not > doing anything, cpufreq stays < 1GHz and heat stays way down. > > The consequence of that is it takes much longer to complete because the > clock is down: what previously normally took ~55s real for ~27s of CPU > time now takes 7m10 for 85s of CPU time -- but honestly I don't care how > long this takes if it's not noticeable, this is perfect. Thanks again! That's a really long time… 55/27 s seems fairly standard, e.g. I get 43/22 s with a 256 GB SATA disk. But 440/85 s is quite a bit worse. > Steinar would you consider adding this to the upstream service file? I don't think this qualifies as a good default. I would consider it a hack to fix a local hardware problem. Fans in a laptop simply must not be loud enough to be annoying. > (Zbigniew, does systemd just ignore the setting on systems where cpu > accounting has not been enabled? iirc some distros still have it off and > upstream might want to provide defaults that work everywhere) > > I would have suggested also adding Nice=5 or something but I don't think > it's required with this. I think that with IOSchedulingClass=idle, niceness doesn't matter anymore. Zbyszek ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F36 Change: Plocate as the default locate implementation (Self-Contained Change proposal)
Zbigniew Jędrzejewski-Szmek wrote on Wed, Nov 24, 2021 at 07:58:47AM +: > My understanding is that in order to minimize the overall energy consumption, > the scheduler will try to maximize the cpu frequency and minimize the total > time of computation… So a cpu scheduler will not help much here, as they > will all schedule 100% of the cpu. AFAIK, there is no scheduler that > allows saying "schedule this so that so that the fans don't go on". > From the amount of complaints about loud fans, I think it would be a > popular feature. (There is something similar with "lap protection", where > heating is avoided if the laptop is detected as not-on-a-surface). Right, from a total power consumption point of view this probably makes sense, but it's not necessarily what people are after. > Please try with the following file: > > # /etc/systemd/system/plocate-updatedb.service.d/limits.conf > [Service] > CPUAccounting=yes > CPUQuota=20% > > (then 'sudo systemctl daemon-reload && sudo systemctl restart > plocate-updatedb'). > I think this could work. That's a nice one. For my particular laptop, with governor=performance I'm cutting it too close to fan being audible (and firefox etc also regularily kicks it in), so I'm not surprised even with CPUQuota=20% it's enough to be audible, albeit at a lower level than full throttle (something like +5° instead of +10-15 from where core temp usually stands, that makes a difference to fan RPM) With governor=powersave though it's really worlds appart, no CPUQuota immediately scales up to close to the max and heats just like performance would but with this I barely see any difference from not doing anything, cpufreq stays < 1GHz and heat stays way down. The consequence of that is it takes much longer to complete because the clock is down: what previously normally took ~55s real for ~27s of CPU time now takes 7m10 for 85s of CPU time -- but honestly I don't care how long this takes if it's not noticeable, this is perfect. Thanks again! Steinar would you consider adding this to the upstream service file? (Zbigniew, does systemd just ignore the setting on systems where cpu accounting has not been enabled? iirc some distros still have it off and upstream might want to provide defaults that work everywhere) I would have suggested also adding Nice=5 or something but I don't think it's required with this. Cheers, -- Dominique ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F36 Change: Plocate as the default locate implementation (Self-Contained Change proposal)
On Tue, Nov 23, 2021 at 05:52:26PM -0500, Garry T. Williams wrote: > On Tuesday, November 23, 2021 4:53:12 PM EST Zbigniew Jędrzejewski-Szmek > wrote: > > On Tue, Nov 23, 2021 at 01:52:43PM -0500, Chris Murphy wrote: > > > I'm definitely noticing a difference. I'm not sure it was ever correct > > > that updatedb.conf was pruning bind mounts on Fedora. It's not the > > > mlocate default, but it is what Fedora has been using for years > > > (defacto default on Fedora). > > > > That's a known-fixed bug. > > Not fixed as far as I know[*]. known-fixed-in-plocate ;) This was explicitly discussed somewhere: the gist is that plocate has better handling of duplicates, so it doesn't need to filter out bind mounts. But I can't find that discussion. If I do, I'll add it to the change page. > I've been patching my > /etc/updatedb.conf ever since I installed with btrfs. (The second > time I installed with btrfs, f33, that is. Not years ago. :-)) > > This change does render the bug moot, though. Nice. Zbyszek ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F36 Change: Plocate as the default locate implementation (Self-Contained Change proposal)
On Wed, Nov 24, 2021 at 07:28:25AM +0900, Dominique Martinet wrote: > Ben Cotton wrote on Tue, Nov 23, 2021 at 12:18:56PM -0500: > > == Summary == > > The venerable `mlocate` program is replaced by `plocate` — a > > compatible reimplementation that is faster and uses less disk space. > > Thanks for doing this! The positive responses make me very happy ;) > For what it's worth, I've been running plocate locally since it was > brought up to the list earlier this year(?), and while it's much faster > I have one small complain: the indexing phase is way too power-hungry. > > This is not actually a complain about power draw (there's the onACpower > conditional as rightfully pointed out), but about kicking in the fans > a few times a week (because of the randomized delay, it happens when I'm > at desk regularily) when I'm at desk. My understanding is that in order to minimize the overall energy consumption, the scheduler will try to maximize the cpu frequency and minimize the total time of computation… So a cpu scheduler will not help much here, as they will all schedule 100% of the cpu. AFAIK, there is no scheduler that allows saying "schedule this so that so that the fans don't go on". From the amount of complaints about loud fans, I think it would be a popular feature. (There is something similar with "lap protection", where heating is avoided if the laptop is detected as not-on-a-surface). Please try with the following file: # /etc/systemd/system/plocate-updatedb.service.d/limits.conf [Service] CPUAccounting=yes CPUQuota=20% (then 'sudo systemctl daemon-reload && sudo systemctl restart plocate-updatedb'). I think this could work. Zbyszek ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F36 Change: Plocate as the default locate implementation (Self-Contained Change proposal)
(replying to myself as I got a message on irc from the author) Dominique Martinet wrote on Wed, Nov 24, 2021 at 07:28:25AM +0900: > I see now that it has IOSchedulingClass=IDLE but nothing equivalent > about CPU, but I don't think that'll help: if the computer is mostly > idle it'll still use all the cores (and increase cpufreq automatically) > for long enough to heat up and make the fans kick in. I seem to have misremembered this part: it is single core. (doesn't change much as far as cpufreq/heat is concerned though) Also, it had been a while but it has actually gotten much better after I added /.snapshots and similar paths to PRUNEPATHS, so this isn't as much of a problem as I remembered, but could still be a problem for large filesystems > I don't think there is a laptop friendly scheduler that says if this > task is niced then keep the cpufreq at its minimum, is there? > I've been manually fiddling with my cpufreqs' scaling_max_freq just low > enough to not trigger the fans but it sounds like overengineering to > me... Still interested if anyone knows how to do this! -- Dominique ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F36 Change: Plocate as the default locate implementation (Self-Contained Change proposal)
On Tuesday, November 23, 2021 4:53:12 PM EST Zbigniew Jędrzejewski-Szmek wrote: > On Tue, Nov 23, 2021 at 01:52:43PM -0500, Chris Murphy wrote: > > I'm definitely noticing a difference. I'm not sure it was ever correct > > that updatedb.conf was pruning bind mounts on Fedora. It's not the > > mlocate default, but it is what Fedora has been using for years > > (defacto default on Fedora). > > That's a known-fixed bug. Not fixed as far as I know[*]. I've been patching my /etc/updatedb.conf ever since I installed with btrfs. (The second time I installed with btrfs, f33, that is. Not years ago. :-)) This change does render the bug moot, though. Nice. _ [*] The bug claims a fix for Silverblue, but not Fedora Workstation or KDE. -- Garry T. Williams ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F36 Change: Plocate as the default locate implementation (Self-Contained Change proposal)
Ben Cotton wrote on Tue, Nov 23, 2021 at 12:18:56PM -0500: > == Summary == > The venerable `mlocate` program is replaced by `plocate` — a > compatible reimplementation that is faster and uses less disk space. Thanks for doing this! For what it's worth, I've been running plocate locally since it was brought up to the list earlier this year(?), and while it's much faster I have one small complain: the indexing phase is way too power-hungry. This is not actually a complain about power draw (there's the onACpower conditional as rightfully pointed out), but about kicking in the fans a few times a week (because of the randomized delay, it happens when I'm at desk regularily) when I'm at desk. I see now that it has IOSchedulingClass=IDLE but nothing equivalent about CPU, but I don't think that'll help: if the computer is mostly idle it'll still use all the cores (and increase cpufreq automatically) for long enough to heat up and make the fans kick in. I don't think there is a laptop friendly scheduler that says if this task is niced then keep the cpufreq at its minimum, is there? I've been manually fiddling with my cpufreqs' scaling_max_freq just low enough to not trigger the fans but it sounds like overengineering to me... (feel free to ignore me, I'm overall very happy about this change) -- Dominique ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F36 Change: Plocate as the default locate implementation (Self-Contained Change proposal)
On Tue, Nov 23, 2021 at 08:13:02PM +0100, Miroslav Suchý wrote: > Dne 23. 11. 21 v 18:18 Ben Cotton napsal(a): > >== User Experience == > >Users should not notice the difference. Installing `plocate` > >automatically removes `mlocate`. The new implementation is generally > >compatible with the old one in all common cases, and provides some > >additional options. > > Any reason why `plocate` does not own `/etc/updatedb.conf` and does > not provide the config with a sane defaults? The file isn't needed, the defaults are OK. I'll add '%ghost /etc/updatedb.conf'. > Additionally, providing a man page for `locate` as alias to `plocate` will be > nice. I'll put that on the list too. Zbyszek ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F36 Change: Plocate as the default locate implementation (Self-Contained Change proposal)
On Tue, Nov 23, 2021 at 01:52:43PM -0500, Chris Murphy wrote: > On Tue, Nov 23, 2021 at 12:19 PM Ben Cotton wrote: > > > == How To Test == > > # Install `plocate` (`sudo dnf install plocate --allowerasing`) > > # Wait for `plocate-updatedb.service` to finish (`sudo systemctl start > > plocate-updatedb.service`) > > # Use `plocate pattern` or `plocate -r ` to search for files. > > Works for me. Also fixes this old bug where mlocate pruned bind mount > locations, which resulted in /home on Btrfs not being indexed. > https://bugzilla.redhat.com/show_bug.cgi?id=906591 > > Note for laptop users, plocate-updatedb.service contains > ConditionACPower=true, so if you're getting errors locating files, it > might be because the initial database isn't being created because no > AC power. Ack. (I assume that most people have the laptop on AC at least some of the time, so the db will get updated sooner or later. In the worst case, if the laptop is only charged while off or suspended, it would be necessary to remove the conditional. But I think that's a rare case, and the default is good.) > > == User Experience == > > Users should not notice the difference. Installing `plocate` > > automatically removes `mlocate`. The new implementation is generally > > compatible with the old one in all common cases, and provides some > > additional options. > > I'm definitely noticing a difference. I'm not sure it was ever correct > that updatedb.conf was pruning bind mounts on Fedora. It's not the > mlocate default, but it is what Fedora has been using for years > (defacto default on Fedora). That's a known-fixed bug. I didn't mention it because, well, it was considered a bug in mlocate. ¯\_(ツ)_/¯ Zbyszek ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F36 Change: Plocate as the default locate implementation (Self-Contained Change proposal)
Dne 23. 11. 21 v 18:18 Ben Cotton napsal(a): == User Experience == Users should not notice the difference. Installing `plocate` automatically removes `mlocate`. The new implementation is generally compatible with the old one in all common cases, and provides some additional options. Any reason why `plocate` does not own `/etc/updatedb.conf` and does not provide the config with a sane defaults? Additionally, providing a man page for `locate` as alias to `plocate` will be nice. Miroslav ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F36 Change: Plocate as the default locate implementation (Self-Contained Change proposal)
On Tue, Nov 23, 2021 at 12:19 PM Ben Cotton wrote: > == How To Test == > # Install `plocate` (`sudo dnf install plocate --allowerasing`) > # Wait for `plocate-updatedb.service` to finish (`sudo systemctl start > plocate-updatedb.service`) > # Use `plocate pattern` or `plocate -r ` to search for files. Works for me. Also fixes this old bug where mlocate pruned bind mount locations, which resulted in /home on Btrfs not being indexed. https://bugzilla.redhat.com/show_bug.cgi?id=906591 Note for laptop users, plocate-updatedb.service contains ConditionACPower=true, so if you're getting errors locating files, it might be because the initial database isn't being created because no AC power. > == User Experience == > Users should not notice the difference. Installing `plocate` > automatically removes `mlocate`. The new implementation is generally > compatible with the old one in all common cases, and provides some > additional options. I'm definitely noticing a difference. I'm not sure it was ever correct that updatedb.conf was pruning bind mounts on Fedora. It's not the mlocate default, but it is what Fedora has been using for years (defacto default on Fedora). -- Chris Murphy ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
F36 Change: Plocate as the default locate implementation (Self-Contained Change proposal)
https://fedoraproject.org/wiki/Changes/Plocate_as_the_default_locate_implementation == Summary == The venerable `mlocate` program is replaced by `plocate` — a compatible reimplementation that is faster and uses less disk space. == Owner == * Name: [[User:Zbyszek| Zbigniew Jędrzejewski-Szmek]] * Email: zbyszek at in.waw.pl * Name: [[User:Msekleta| Michal Sekletár]] * Email: msekleta at redhat.com == Detailed Description == Plocate is a newer implementation of `locate`/`mlocate` that using `liburing` and `libzstd` for speed. The database it creates on disk is also smaller. Debian recently switched to `plocate` as the default implementation (https://lwn.net/Articles/846405/). It doesn't seem useful to maintain multiple locate implementations. Thus the new package Conflicts with the old one, so they cannot be installed in parallel. The plan is: # F35: `plocate` is made available for testing # F36: `mlocate` is replaced by `plocate` in comps # F37 or F38: `mlocate` will be retired (or given away, if somebody wants to pick it up) == Benefit to Fedora == We save some cpu cycles and disk sectors by using a more modern implementation of a common tool. == Scope == * Proposal owners: ** package `mlocate` (Review bug: https://bugzilla.redhat.com/show_bug.cgi?id=1931141, DONE) ** submit a pull request to comps with `s/mlocate/plocate/` * Other developers: install plocate locally and test if it works as expected on F35 and other versions * Release engineering: n/a * Policies and guidelines: n/a * Trademark approval: n/a * Alignment with Objectives: none == Upgrade/compatibility impact == The upgrade should be mostly invisible. It is possible that somebody might be relying on some very specific `mlocate` behaviour or parsing the `mlocate` database directly, but no such cases are currently known. == How To Test == # Install `plocate` (`sudo dnf install plocate --allowerasing`) # Wait for `plocate-updatedb.service` to finish (`sudo systemctl start plocate-updatedb.service`) # Use `plocate pattern` or `plocate -r ` to search for files. == User Experience == Users should not notice the difference. Installing `plocate` automatically removes `mlocate`. The new implementation is generally compatible with the old one in all common cases, and provides some additional options. == Dependencies == None. == Contingency Plan == * Contingency mechanism: (What to do? Who will do it?) N/A (not a System Wide Change) * Contingency deadline: N/A (not a System Wide Change) * Blocks release? N/A (not a System Wide Change) == Documentation == N/A (not a System Wide Change) == Release Notes == `plocate` is now used as the default provider of `/usr/bin/locate` instead of `mlocate`. -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
review swap: plocate
https://bugzilla.redhat.com/show_bug.cgi?id=1931141 I'd be happy to do some reviews in return. Zbyszek ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: plocate?
On Wed, May 12, 2021 at 12:22:46PM +0200, Michal Sekletar wrote: > On Tue, May 4, 2021 at 1:25 PM Zbigniew Jędrzejewski-Szmek < > zbys...@in.waw.pl> wrote: > > > > > I agree. Plocate/mlocate is useful technology, but it's not important > > enough to justify maintaining two or three different implementations. > > If we can make plocate cover all bases, and it's faster, I'd just make > > it *the* implementation. Let's get the agreement of mlocate maintainer > > first though. Michal, wdyt? > > > > > Hi everyone, > > I agree that we should transition to the newer (faster and well maintained) > implementation and in the long run we should have only one locate > implementation in the distribution. However, I think we should have some > transition period (e.g. two Fedora release cycles), during which both > packages will be present. Introducing alternatives scaffolding seems like > an overkill for something that is going away in a year, hence plain > Conflits: tag would be enough. As for maintenance, I think that having an > older (mlocate) package available for a year or so while we iron out > potential compat issues or bugs shouldn't add too much work. > > Zbigniew, please take plocate through the review process and once it is > included in the distro I am willing to take up (co)maintenance of the > package. I updated the .spec file in the review request https://bugzilla.redhat.com/show_bug.cgi?id=1931141, but I can't review my own work ;) Zbyszek ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: plocate?
On Tue, May 4, 2021 at 1:25 PM Zbigniew Jędrzejewski-Szmek < zbys...@in.waw.pl> wrote: > > I agree. Plocate/mlocate is useful technology, but it's not important > enough to justify maintaining two or three different implementations. > If we can make plocate cover all bases, and it's faster, I'd just make > it *the* implementation. Let's get the agreement of mlocate maintainer > first though. Michal, wdyt? > > Hi everyone, I agree that we should transition to the newer (faster and well maintained) implementation and in the long run we should have only one locate implementation in the distribution. However, I think we should have some transition period (e.g. two Fedora release cycles), during which both packages will be present. Introducing alternatives scaffolding seems like an overkill for something that is going away in a year, hence plain Conflits: tag would be enough. As for maintenance, I think that having an older (mlocate) package available for a year or so while we iron out potential compat issues or bugs shouldn't add too much work. Zbigniew, please take plocate through the review process and once it is included in the distro I am willing to take up (co)maintenance of the package. Cheers, Michal ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: plocate?
On Sun, May 02, 2021 at 03:07:47PM -0600, Chris Murphy wrote: > On Thu, Apr 29, 2021 at 8:21 PM Dominique Martinet > wrote: > > > > (added mlocate maintainer msekleta in Ccs; hopefully that's a still > > valid address) > > > > Zbigniew Jędrzejewski-Szmek wrote on Sat, Feb 20, 2021 at 02:06:00PM +: > > > Debian is apparently switching to plocate as the the default > > > locate/mlocate provider [0], a bit faster and more disk-efficient. > > > Would it make sense to do the same in Fedora? > > > > > > I prepared a package [1, 2]. The code seems nice and clean enough. > > > I'd be happy to take it through review, but I'm not particular keen > > > on long-term maintenance… > > > > Having just tried I think it'd make sense, the difference is striking. > > Small db update is a bit slower but that's a background activity, and > > search really feels instant (tens of ms) compared to a handful of > > seconds. > > > > > > I think that'll require a bit more work though, and we can start by just > > having the package available it doesn't have to be the default right > > away (I remembered that there was a discussion but not where it had > > ended, so was surprised to find no package in main repos!) > > Unless there's a significant impediment to making it the default in > Fedora 35, I think we should just move forward. I agree. Plocate/mlocate is useful technology, but it's not important enough to justify maintaining two or three different implementations. If we can make plocate cover all bases, and it's faster, I'd just make it *the* implementation. Let's get the agreement of mlocate maintainer first though. Michal, wdyt? > updatedb does not index /home when /home is a bind mount (75 comments) > https://bugzilla.redhat.com/show_bug.cgi?id=906591 > > Summary: Upstream sets PRUNE_BIND_MOUNTS to "no". For some reason > Fedora has it set to "yes". Because both rpm-ostree and Btrfs make use > of bind mounts, updatedb doesn't index /home at all. Silverblue setups > comment the PRUNE_BIND_MOUNTS = "yes" line out, so the problem doesn't > happen on Silverblue. But it still is a problem on default desktops, > and I still don't know why we don't just do either what upstream or > Silverblue are doing. > > So I'm kinda curious if plocate will have issues related to bind > mounts or if it does things differently. Zbyszek ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: plocate?
On Thu, Apr 29, 2021 at 8:21 PM Dominique Martinet wrote: > > (added mlocate maintainer msekleta in Ccs; hopefully that's a still > valid address) > > Zbigniew Jędrzejewski-Szmek wrote on Sat, Feb 20, 2021 at 02:06:00PM +: > > Debian is apparently switching to plocate as the the default > > locate/mlocate provider [0], a bit faster and more disk-efficient. > > Would it make sense to do the same in Fedora? > > > > I prepared a package [1, 2]. The code seems nice and clean enough. > > I'd be happy to take it through review, but I'm not particular keen > > on long-term maintenance… > > Having just tried I think it'd make sense, the difference is striking. > Small db update is a bit slower but that's a background activity, and > search really feels instant (tens of ms) compared to a handful of > seconds. > > > I think that'll require a bit more work though, and we can start by just > having the package available it doesn't have to be the default right > away (I remembered that there was a discussion but not where it had > ended, so was surprised to find no package in main repos!) Unless there's a significant impediment to making it the default in Fedora 35, I think we should just move forward. updatedb does not index /home when /home is a bind mount (75 comments) https://bugzilla.redhat.com/show_bug.cgi?id=906591 Summary: Upstream sets PRUNE_BIND_MOUNTS to "no". For some reason Fedora has it set to "yes". Because both rpm-ostree and Btrfs make use of bind mounts, updatedb doesn't index /home at all. Silverblue setups comment the PRUNE_BIND_MOUNTS = "yes" line out, so the problem doesn't happen on Silverblue. But it still is a problem on default desktops, and I still don't know why we don't just do either what upstream or Silverblue are doing. So I'm kinda curious if plocate will have issues related to bind mounts or if it does things differently. -- Chris Murphy ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: plocate?
(added mlocate maintainer msekleta in Ccs; hopefully that's a still valid address) Zbigniew Jędrzejewski-Szmek wrote on Sat, Feb 20, 2021 at 02:06:00PM +: > Debian is apparently switching to plocate as the the default > locate/mlocate provider [0], a bit faster and more disk-efficient. > Would it make sense to do the same in Fedora? > > I prepared a package [1, 2]. The code seems nice and clean enough. > I'd be happy to take it through review, but I'm not particular keen > on long-term maintenance… Having just tried I think it'd make sense, the difference is striking. Small db update is a bit slower but that's a background activity, and search really feels instant (tens of ms) compared to a handful of seconds. I think that'll require a bit more work though, and we can start by just having the package available it doesn't have to be the default right away (I remembered that there was a discussion but not where it had ended, so was surprised to find no package in main repos!) In particular I think we'll need to first rework mlocate to use alternatives for locate/updatedb, so plocate can use the same names while keeping both packages parallely installable. I guess it'd also be fine if the packages would just plain Conflict and overwrite each other but it's important the commands stay the same (In that case we can probably also get away by not including plocate-build in the package, the command converts mlocate db to plocate format and is probably not going to see any use) (I'm willing to help with the one-time transition to alternatives if that's the way forward, or the initial package integration, but I don't think it'd be reasonable to take plocate myself given my free time lately... Anyway, let's discuss where we want to go first) -- Dominique ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: plocate?
Zbigniew Jędrzejewski-Szmek wrote:
> Debian is apparently switching to plocate as the the default
> locate/mlocate provider [0], a bit faster and more disk-efficient.
> Would it make sense to do the same in Fedora?
I think it makes sense (why default to the older, slower implementation?),
but just like Debian, I think we should not install locate by default to
begin with.
See Josh Triplett's arguments which I can only fully second:
https://lwn.net/ml/debian-devel/YB+FvRPtuJmroUTT@localhost/
> I prepared a package [1, 2]. The code seems nice and clean enough.
> I'd be happy to take it through review, but I'm not particular keen
> on long-term maintenance…
If you want it to be the default, it should install %{_bindir}/updatedb, not
%{_bindir}/plocate-updatedb, and it should Obsolete mlocate, just like
mlocate Obsoletes slocate.
Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
Re: plocate?
Zbigniew Jędrzejewski-Szmek wrote: > [0] https://lwn.net/Articles/846405/ For those who actually want to be able to read that article, a search engine found me this: https://lwn.net/SubscriberLink/846405/7a173db2f6aedfd8/ Kevin Kofler ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
رد: plocate?
It looks good to maintain. https://bugzilla.redhat.com/show_bug.cgi?id=1931141 Mosaab من: Zbigniew Jędrzejewski-Szmek تم الإرسال: 08/رجب/1442 05:06 م إلى: Development discussions related to Fedora الموضوع: plocate? Debian is apparently switching to plocate as the the default locate/mlocate provider [0], a bit faster and more disk-efficient. Would it make sense to do the same in Fedora? I prepared a package [1, 2]. The code seems nice and clean enough. I'd be happy to take it through review, but I'm not particular keen on long-term maintenance… [0] https://lwn.net/Articles/846405/ [1] http://in.waw.pl/~zbyszek/fedora/plocate.spec [2] https://copr.fedorainfracloud.org/coprs/zbyszek/plocate Zbyszek ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
plocate?
Debian is apparently switching to plocate as the the default locate/mlocate provider [0], a bit faster and more disk-efficient. Would it make sense to do the same in Fedora? I prepared a package [1, 2]. The code seems nice and clean enough. I'd be happy to take it through review, but I'm not particular keen on long-term maintenance… [0] https://lwn.net/Articles/846405/ [1] http://in.waw.pl/~zbyszek/fedora/plocate.spec [2] https://copr.fedorainfracloud.org/coprs/zbyszek/plocate Zbyszek ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
