Re: [gentoo-dev] rfc: handling the "uucp" group
> On Thu, 8 Feb 2018, R0b0t1 wrote: > It makes the most sense to me to give a uucp user dialout or tty > permission, instead of adding myself to the uucp group, a name which > references programs most people won't have installed and won't know > about. The tty group has an entirely different purpose, namely to allow programs such as write(1) and wall(1) access other users' terminals. So conflating it with dialout or uucp would be wrong. Ulrich pgpuyECm2h9td.pgp Description: PGP signature
Re: [gentoo-dev] newsitem: baselayout 2.5 changes
On Thu, Feb 8, 2018 at 6:25 PM, Michael Orlitzky wrote: > On 02/08/2018 06:12 PM, William Hubbs wrote: >> >> There is no bug here. The problem, as I said before in this thread, is >> that what goes in *sbin is arbitrary, and as Rich said, if you are >> relying on the path to prevent a non-root user from running something >> that only root should run, you are doing it wrong. All the user has to >> do is type a full path to a command and it will be run. > > The FHS says /usr/sbin is for "binaries used exclusively by the system > administrator." It's not arbitrary, and the test for what doesn't belong > there is obvious: if a regular user needs something in /usr/sbin, then > we put it in the wrong place. Adding /usr/sbin to PATH will hide the > fact that we put it in the wrong place, but it will still be in the > wrong place. > Sounds like a good reason to refer bugs upstream, and hide them from users in the meantime, like basically every other distro does. -- Rich
Re: [gentoo-dev] newsitem: baselayout 2.5 changes
On 02/08/2018 06:12 PM, William Hubbs wrote: > > There is no bug here. The problem, as I said before in this thread, is > that what goes in *sbin is arbitrary, and as Rich said, if you are > relying on the path to prevent a non-root user from running something > that only root should run, you are doing it wrong. All the user has to > do is type a full path to a command and it will be run. The FHS says /usr/sbin is for "binaries used exclusively by the system administrator." It's not arbitrary, and the test for what doesn't belong there is obvious: if a regular user needs something in /usr/sbin, then we put it in the wrong place. Adding /usr/sbin to PATH will hide the fact that we put it in the wrong place, but it will still be in the wrong place.
Re: [gentoo-dev] newsitem: baselayout 2.5 changes
On Thu, Feb 08, 2018 at 05:49:52PM -0500, Michael Orlitzky wrote: > On 02/08/2018 05:33 PM, Rich Freeman wrote: > > > > There are actually quite a few binaries in /sbin and /usr/sbin which > > can be useful for non-root users. Sure, we could go through there > > carefully and move stuff to /bin but honestly doing what everybody > > else does and just sticking /sbin in the default path makes more > > sense. > > Yeah hiding the bug is easier than fixing it, but has the downside that > the bug doesn't get fixed. There is no bug here. The problem, as I said before in this thread, is that what goes in *sbin is arbitrary, and as Rich said, if you are relying on the path to prevent a non-root user from running something that only root should run, you are doing it wrong. All the user has to do is type a full path to a command and it will be run. William signature.asc Description: Digital signature
Re: [gentoo-dev] rfc: handling the "uucp" group
On Thu, Feb 8, 2018 at 2:32 PM, Ulrich Mueller wrote: >> On Thu, 8 Feb 2018, William Hubbs wrote: > >> First, baselayout has had the "dialout" group since 2015, so the >> longterm fix imo is to possibly use that instead of the uucp group. >> What would it take to make that happen, or are we stuck with the >> uucp group forever? > > There was an old discussion on this in bug 108249 [1]. The decision > back in 2005 was to use the "uucp" group (because apparently that was > what both Debian and Fedora did at the time), but IIRC it was pretty > much arbitrary. > > So I don't see a reason why we couldn't use "dialout" instead. > UUCP doesn't have any intrinsic relationship with modems, though it probably finds (found) most use over modems. Was "dialout" or "tty" changed to "uucp" for some reason? If possible please use dialout, as very few modems are teletypes. It makes the most sense to me to give a uucp user dialout or tty permission, instead of adding myself to the uucp group, a name which references programs most people won't have installed and won't know about. Cheers, R0b0t1
Re: [gentoo-dev] newsitem: baselayout 2.5 changes
On 02/08/2018 05:33 PM, Rich Freeman wrote: > > There are actually quite a few binaries in /sbin and /usr/sbin which > can be useful for non-root users. Sure, we could go through there > carefully and move stuff to /bin but honestly doing what everybody > else does and just sticking /sbin in the default path makes more > sense. Yeah hiding the bug is easier than fixing it, but has the downside that the bug doesn't get fixed.
Re: [gentoo-dev] newsitem: baselayout 2.5 changes
On 08/02/18 22:33, William Hubbs wrote: > All, > > here is a link to an old, but brief discussion about this. > > https://archives.gentoo.org/gentoo-dev/message/2fc1f62c7cf225787fe52f4dace7368c > > I think we have talked about this several other times, but not done > anything about it. > > On Thu, Feb 08, 2018 at 10:17:59PM +, M. J. Everitt wrote: >> >> On 08/02/18 22:13, William Hubbs wrote: >>> On Thu, Feb 08, 2018 at 03:55:02PM -0500, Mike Gilbert wrote: However, there are plenty of examples of commands that normal users may run from sbin. Moving these commands often causes problems for packages that either hard code absolute paths, or detect paths at build time. I think it would be less disruptive to add sbin to PATH than it would be to try and "fix" all the packages that install commands in the wrong place. >>> There are no reasons to remove the *sbin directories from PATH; I know >>> of no other distros that do this. >>> >>> William >>> >> Pardon my ignorance, but does that mean you are essentially relying on >> file system features/permissions and security settings to enforce >> correct use of system tools?! Or is this just to make sudo/etc commands >> 'more convenient' ?! > The basic problem is that what goes in *bin vs *sbin is quite arbitrary > and the best way to fix it is to make all of the *bin and *sbin > directories accessible to all users. > > You can't rely on a path to separate system-only programs from > programs that users might want to run, and some programs can be run by > users to look around but not change things. > > Here is one non-gentoo source discussing this. > > http://lists.busybox.net/pipermail/busybox/2010-December/074114.html > > Even if we don't adopt the usr merge in Gentoo Linux as default, removing > *sbin > from the path doesn't make sense. > > William > Thank you William, and also rich for your explanations! I do see where you're coming from now. Michael. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] newsitem: baselayout 2.5 changes
All, here is a link to an old, but brief discussion about this. https://archives.gentoo.org/gentoo-dev/message/2fc1f62c7cf225787fe52f4dace7368c I think we have talked about this several other times, but not done anything about it. On Thu, Feb 08, 2018 at 10:17:59PM +, M. J. Everitt wrote: > > > On 08/02/18 22:13, William Hubbs wrote: > > On Thu, Feb 08, 2018 at 03:55:02PM -0500, Mike Gilbert wrote: > >> However, there are plenty of examples of commands that normal users > >> may run from sbin. Moving these commands often causes problems for > >> packages that either hard code absolute paths, or detect paths at > >> build time. I think it would be less disruptive to add sbin to PATH > >> than it would be to try and "fix" all the packages that install > >> commands in the wrong place. > > There are no reasons to remove the *sbin directories from PATH; I know > > of no other distros that do this. > > > > William > > > Pardon my ignorance, but does that mean you are essentially relying on > file system features/permissions and security settings to enforce > correct use of system tools?! Or is this just to make sudo/etc commands > 'more convenient' ?! The basic problem is that what goes in *bin vs *sbin is quite arbitrary and the best way to fix it is to make all of the *bin and *sbin directories accessible to all users. You can't rely on a path to separate system-only programs from programs that users might want to run, and some programs can be run by users to look around but not change things. Here is one non-gentoo source discussing this. http://lists.busybox.net/pipermail/busybox/2010-December/074114.html Even if we don't adopt the usr merge in Gentoo Linux as default, removing *sbin from the path doesn't make sense. William > > MJE > signature.asc Description: Digital signature
Re: [gentoo-dev] newsitem: baselayout 2.5 changes
On Thu, Feb 8, 2018 at 5:17 PM, M. J. Everitt wrote: > > > On 08/02/18 22:13, William Hubbs wrote: >> On Thu, Feb 08, 2018 at 03:55:02PM -0500, Mike Gilbert wrote: >>> However, there are plenty of examples of commands that normal users >>> may run from sbin. Moving these commands often causes problems for >>> packages that either hard code absolute paths, or detect paths at >>> build time. I think it would be less disruptive to add sbin to PATH >>> than it would be to try and "fix" all the packages that install >>> commands in the wrong place. >> There are no reasons to remove the *sbin directories from PATH; I know >> of no other distros that do this. >> >> William >> > Pardon my ignorance, but does that mean you are essentially relying on > file system features/permissions and security settings to enforce > correct use of system tools?! Or is this just to make sudo/etc commands > 'more convenient' ?! If you're depending on binaries not being in the PATH for security, you're doing it wrong. If you're depending on filesystem features/permissions (other than the SUID bit or POSIX capability settings) for security when it comes to performing privileged operations, you're also doing it wrong. There are actually quite a few binaries in /sbin and /usr/sbin which can be useful for non-root users. Sure, we could go through there carefully and move stuff to /bin but honestly doing what everybody else does and just sticking /sbin in the default path makes more sense. If you're typing p to find a command then adding an extra ~20 commands to the ~850 that are listed on my system isn't going to break the bank. -- Rich
Re: [gentoo-dev] newsitem: baselayout 2.5 changes
On 02/08/2018 05:13 PM, William Hubbs wrote: > > There are no reasons to remove the *sbin directories from PATH; I know > of no other distros that do this. The first reason that comes to mind is that when I type something like p to remind me of a command name, I don't need to see 50 programs that I'm not allowed to run in the list.
Re: [gentoo-dev] newsitem: baselayout 2.5 changes
On 08/02/18 22:13, William Hubbs wrote: > On Thu, Feb 08, 2018 at 03:55:02PM -0500, Mike Gilbert wrote: >> However, there are plenty of examples of commands that normal users >> may run from sbin. Moving these commands often causes problems for >> packages that either hard code absolute paths, or detect paths at >> build time. I think it would be less disruptive to add sbin to PATH >> than it would be to try and "fix" all the packages that install >> commands in the wrong place. > There are no reasons to remove the *sbin directories from PATH; I know > of no other distros that do this. > > William > Pardon my ignorance, but does that mean you are essentially relying on file system features/permissions and security settings to enforce correct use of system tools?! Or is this just to make sudo/etc commands 'more convenient' ?! MJE signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] newsitem: baselayout 2.5 changes
On Thu, Feb 08, 2018 at 03:55:02PM -0500, Mike Gilbert wrote: > On Thu, Feb 8, 2018 at 3:41 PM, Ulrich Mueller wrote: > >> On Thu, 8 Feb 2018, Mike Gilbert wrote: > > > >> Eliminating ROOTPATH seems like a significant change. Was this > >> officially discussed somewhere that I missed? > > > >> I actually support the change, but other people should be given the > >> chance to complain about it on the record. It has been a long time, but I believe I brought it up at some point in the past. I'll look for a link in a few and reply with it if I find it. > > It contradicts the FHS, which says that /sbin contains "root-only > > commands" and that "ordinary users should not have to place any of the > > sbin directories in their path." [1] > > That would be fine if we actually followed the recommendation > mentioned in the first half of that footnote. > > "Deciding what things go into "sbin" directories is simple: if a > normal (not a system administrator) user will ever run it directly, > then it must be placed in one of the "bin" directories." > > However, there are plenty of examples of commands that normal users > may run from sbin. Moving these commands often causes problems for > packages that either hard code absolute paths, or detect paths at > build time. I think it would be less disruptive to add sbin to PATH > than it would be to try and "fix" all the packages that install > commands in the wrong place. There are no reasons to remove the *sbin directories from PATH; I know of no other distros that do this. William signature.asc Description: Digital signature
Re: [gentoo-dev] newsitem: baselayout 2.5 changes
On Thu, Feb 8, 2018 at 3:41 PM, Ulrich Mueller wrote: >> On Thu, 8 Feb 2018, Mike Gilbert wrote: > >> Eliminating ROOTPATH seems like a significant change. Was this >> officially discussed somewhere that I missed? > >> I actually support the change, but other people should be given the >> chance to complain about it on the record. > > It contradicts the FHS, which says that /sbin contains "root-only > commands" and that "ordinary users should not have to place any of the > sbin directories in their path." [1] That would be fine if we actually followed the recommendation mentioned in the first half of that footnote. "Deciding what things go into "sbin" directories is simple: if a normal (not a system administrator) user will ever run it directly, then it must be placed in one of the "bin" directories." However, there are plenty of examples of commands that normal users may run from sbin. Moving these commands often causes problems for packages that either hard code absolute paths, or detect paths at build time. I think it would be less disruptive to add sbin to PATH than it would be to try and "fix" all the packages that install commands in the wrong place.
Re: [gentoo-dev] newsitem: baselayout 2.5 changes
> On Thu, 8 Feb 2018, Mike Gilbert wrote: > Eliminating ROOTPATH seems like a significant change. Was this > officially discussed somewhere that I missed? > I actually support the change, but other people should be given the > chance to complain about it on the record. It contradicts the FHS, which says that /sbin contains "root-only commands" and that "ordinary users should not have to place any of the sbin directories in their path." [1] Ulrich [1] http://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch03s16.html#ftn.idm236092603392 pgpZnTybpmk99.pgp Description: PGP signature
Re: [gentoo-dev] rfc: handling the "uucp" group
> On Thu, 8 Feb 2018, William Hubbs wrote: > First, baselayout has had the "dialout" group since 2015, so the > longterm fix imo is to possibly use that instead of the uucp group. > What would it take to make that happen, or are we stuck with the > uucp group forever? There was an old discussion on this in bug 108249 [1]. The decision back in 2005 was to use the "uucp" group (because apparently that was what both Debian and Fedora did at the time), but IIRC it was pretty much arbitrary. So I don't see a reason why we couldn't use "dialout" instead. Ulrich [1] https://bugs.gentoo.org/108249 pgpNEdSItxCzw.pgp Description: PGP signature
Re: [gentoo-dev] Last Rites: Dead X11 packages
On Thu, 8 Feb 2018 13:02:28 -0500 Brian Evans wrote: > On 2/8/2018 12:14 PM, James Le Cuirot wrote: > > On Thu, 8 Feb 2018 18:05:55 +0100 > > Michael Lienhardt wrote: > >> Thanks for the information and sorry for the noise. > >> I wasn't fully aware of the meaning of the --dynamics-deps and > >> --changed-deps option. I am still not entirely convinced that > >> changing a package after it is committed to the repository cannot do > >> harm: even as a user, I would like to know when and why a package's > >> dependencies changed. But I don't maintain packages so my opinion is > >> not very relevant, and the gentoo guidelines indeed allow to change > >> the dependencies inline. > > > > It's not like this stuff is totally invisible as it is noted in the git > > log. We just don't want to tie up several minutes of CPU time for the > > majority of users for no tangible benefit. > > > > The benefit is that portage won't yell at you for having a masked > package installed and no obvious way to clean it up. True, I had forgotten to consider the mask message. -- James Le Cuirot (chewi) Gentoo Linux Developer pgpjiaWSnQdvq.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] rfc: handling the "uucp" group
On Thu, Feb 8, 2018 at 2:03 PM, William Hubbs wrote: > Hi all, > > I have noticed that in the latest versions of udev we are patching the > default upstream rules to accomodate our "uucp" group. > > I don't think it is a good idea to patch default rules, so, I want to > bring up possible fixes. > > First, baselayout has had the "dialout" group since 2015, so the > longterm fix imo is to possibly use that instead of the uucp group. What > would it take to make that happen, or are we stuck with the uucp group > forever? I think a news item targeting current eudev/udev/systemd users announcing the change would suffice. Basically, the change means that modem/serial devices will be owned by the "dialout" group instead of "uucp", so people will need to update their group membership settings if they rely on that. > Also, I think if we are stuck with the uucp group we should write a rule > of our own instead of patching the default rules. If we keep the uucp group, I would prefer to continue patching the udev rule. This makes it very simple to notice if/when upstream makes changes to it. Whatever you do, please keep the systemd and eudev teams in the loop -- this affects more than just sys-fs/udev.
Re: [gentoo-dev] newsitem: baselayout 2.5 changes
On Thu, Feb 8, 2018 at 2:52 PM, William Hubbs wrote: > All, > > here is a proposed newsitem for baselayout 2.5. > > Let me know what you think, including whether these are newsitem-worthy > or not. Eliminating ROOTPATH seems like a significant change. Was this officially discussed somewhere that I missed? I actually support the change, but other people should be given the chance to complain about it on the record.
Re: [gentoo-dev] SAT-based dependency solver: request for test cases
On 02/06/2018 11:52 AM, Michael Lienhardt wrote: > > To help, you can send us the tar generated by this bash script: > https://raw.githubusercontent.com/HyVar/gentoo_to_mspl/master/benchmarks/get_installation.sh > > This bash script extracts your world file, the USE flags and keywords > configuration of your system and the list of installed packages you > have (it should not take more than few seconds). > With this, we will see if our solver is able to recreate your system > and how much time it takes. > > You can send everything to my professional email: mlien...@di.unito.it > Just send an email to that with an uunencoded tar.xz file from one of the tinderbox images [1] I do run. I can adapt the scripts to send the result file of each of the currently 7 running images daily. [1] https://zwiebeltoralf.de/tinderbox.html -- Toralf PGP 23217DA7 9B888F45 signature.asc Description: OpenPGP digital signature
[gentoo-dev] newsitem: baselayout 2.5 changes
All, here is a proposed newsitem for baselayout 2.5. Let me know what you think, including whether these are newsitem-worthy or not. Thanks, William Title: baselayout 2.5 updates Author: William Hubbs Posted: 2018-02-xx Revision: 1 News-Item-Format: 2.0 Display-If-Installed: signature.asc Description: Digital signature
[gentoo-dev] rfc: handling the "uucp" group
Hi all, I have noticed that in the latest versions of udev we are patching the default upstream rules to accomodate our "uucp" group. I don't think it is a good idea to patch default rules, so, I want to bring up possible fixes. First, baselayout has had the "dialout" group since 2015, so the longterm fix imo is to possibly use that instead of the uucp group. What would it take to make that happen, or are we stuck with the uucp group forever? Also, I think if we are stuck with the uucp group we should write a rule of our own instead of patching the default rules. Thoughts? William signature.asc Description: Digital signature
Re: [gentoo-dev] Last Rites: Dead X11 packages
On 2/8/2018 12:14 PM, James Le Cuirot wrote: > On Thu, 8 Feb 2018 18:05:55 +0100 > Michael Lienhardt wrote: >> Thanks for the information and sorry for the noise. >> I wasn't fully aware of the meaning of the --dynamics-deps and >> --changed-deps option. I am still not entirely convinced that >> changing a package after it is committed to the repository cannot do >> harm: even as a user, I would like to know when and why a package's >> dependencies changed. But I don't maintain packages so my opinion is >> not very relevant, and the gentoo guidelines indeed allow to change >> the dependencies inline. > > It's not like this stuff is totally invisible as it is noted in the git > log. We just don't want to tie up several minutes of CPU time for the > majority of users for no tangible benefit. > The benefit is that portage won't yell at you for having a masked package installed and no obvious way to clean it up. Brian signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH] glep-0074: Remove single filesystem limitation
W dniu czw, 08.02.2018 o godzinie 17∶25 +, użytkownik M. J. Everitt napisał: > On 08/02/18 17:09, Michał Górny wrote: > > Remove the limitation that all files covered by the Manifest must reside > > on a single filesystem. This breaks valid uses of overlayfs without > > providing any real advantage. > > > > The removal is justified further in the updated rationale section. > > --- > > glep-0074.rst | 66 > > +++ > > 1 file changed, 39 insertions(+), 27 deletions(-) > > > > RST: https://dev.gentoo.org/~mgorny/tmp/glep-0074.rst > > HTML: https://dev.gentoo.org/~mgorny/tmp/glep-0074.html > > > > diff --git a/glep-0074.rst b/glep-0074.rst > > index 3835247..2f8deb2 100644 > > --- a/glep-0074.rst > > +++ b/glep-0074.rst > > @@ -6,10 +6,10 @@ Author: Michał Górny , > > Ulrich Müller > > Type: Standards Track > > Status: Final > > -Version: 1 > > +Version: 1.1 > > Created: 2017-10-21 > > -Last-Modified: 2017-12-16 > > -Post-History: 2017-10-26, 2017-11-16 > > +Last-Modified: 2018-02-08 > > +Post-History: 2017-10-26, 2017-11-16, 2018-02-08 > > Content-Type: text/x-rst > > Requires: 59, 61 > > Replaces: 44, 58, 60 > > @@ -126,13 +126,6 @@ a different file type. If the tree contain files of > > other types > > that are not otherwise ignored, they need to be covered by an explicit > > ``IGNORE``. > > > > -All the local (non-``DIST``) files covered by a Manifest tree must > > -reside on the same filesystem. It is an error to specify entries > > -applying to files on another filesystem. If files or directories that > > -are not otherwise ignored reside on a different filesystem, or symbolic > > -links point to targets on a different filesystem, they must > > -be explicitly excluded via ``IGNORE``. > > - > > > > Path and filename encoding > > -- > > @@ -325,22 +318,18 @@ Algorithm for finding parent Manifests > > In order to find the top-level Manifest from the current directory > > the following algorithm can be used: > > > > -1. Store the current directory as *original* and the device ID > > - of the containing filesystem (``st_dev``) as *startdev*, > > - > > -2. If the device ID of the containing filesystem (``st_dev``) > > - of the current directory is different than *startdev*, stop. > > +1. Store the current directory as *original*, > > > > -3. If the current directory contains a ``Manifest`` file: > > +2. If the current directory contains a ``Manifest`` file: > > > > a. If an ``IGNORE`` entry in the ``Manifest`` file covers > >the *original* directory (or one of the parent directories), stop. > > > > b. Otherwise, store the current directory as *last_found*. > > > > -4. If the current directory is the root system directory (``/``), stop. > > +3. If the current directory is the root system directory (``/``), stop. > > > > -5. Otherwise, enter the parent directory and jump to step 2. > > +4. Otherwise, enter the parent directory and jump to step 2. > > > > Once the algorithm stops, *last_found* will contain the relevant > > top-level Manifest. If *last_found* is null, then the directory tree > > > > > > Observation: does RST not support auto-numbering like other formats? It > would make renumbering lists like this much easier (and from programming > experience, less error-prone). If not, #FEATUREREQ ... :] The whole purpose of WYWIWYG is to write *proper* text and not some magical syntax that magically gets transformed to auto-numbered list. Except when the format doesn't get it right. Also, this comment is entirely off-topic and not useful to the thread at all. Please cease those pointless off-topics. -- Best regards, Michał Górny
Re: [gentoo-dev] Last Rites: Dead X11 packages
On Thu, Feb 8, 2018 at 5:37 AM, Brian Evans wrote: > On 2/7/2018 9:54 PM, Matt Turner wrote: >> # Matt Turner (06 Feb 2018) >> # Dead and unused >> # Masked for removal in 30 days. Bug #646838 >> x11-libs/libXCalibrate >> x11-libs/libXfontcache >> x11-misc/xtscal >> x11-proto/fontcacheproto >> x11-proto/xcalibrateproto >> x11-proto/xf86rushproto > > >> From e590965cdeb0c921194740da0481c85afaa1ebae Mon Sep 17 00:00:00 2001 >> From: Matt Turner >> Date: Tue, 6 Feb 2018 14:02:59 -0800 >> Subject: x11-base/xorg-server: Remove dead x11-proto/xf86rushproto dependency >> >> rushproto hasn't been required since upstream commit 8ec79e05feac (in >> 2005!), and even then it wasn't actually needed! >> >> Package-Manager: Portage-2.3.19, Repoman-2.3.6 >> --- >> x11-base/xorg-server/xorg-server-1.19.5.ebuild | 3 +-- >> x11-base/xorg-server/xorg-server-1.19.6.ebuild | 3 +-- >> x11-base/xorg-server/xorg-server-.ebuild | 3 +-- >> 3 files changed, 3 insertions(+), 6 deletions(-) >> > > Please don't edit dependencies in-line like this. > > This warranted a revbump as users will be asking how to remove > x11-proto/xf86rushproto. It won't come up for depclean because of > xorg-server not being scheduled for rebuild automatically until the next > time it is upgraded or --changed-deps option is used (uncommon). Ah, sorry. I did not consider that. Is there anything I should do to clean it up now? git mv to -r1?
Re: [gentoo-dev] [PATCH] glep-0074: Remove single filesystem limitation
On 08/02/18 17:09, Michał Górny wrote: > Remove the limitation that all files covered by the Manifest must reside > on a single filesystem. This breaks valid uses of overlayfs without > providing any real advantage. > > The removal is justified further in the updated rationale section. > --- > glep-0074.rst | 66 > +++ > 1 file changed, 39 insertions(+), 27 deletions(-) > > RST: https://dev.gentoo.org/~mgorny/tmp/glep-0074.rst > HTML: https://dev.gentoo.org/~mgorny/tmp/glep-0074.html > > diff --git a/glep-0074.rst b/glep-0074.rst > index 3835247..2f8deb2 100644 > --- a/glep-0074.rst > +++ b/glep-0074.rst > @@ -6,10 +6,10 @@ Author: Michał Górny , > Ulrich Müller > Type: Standards Track > Status: Final > -Version: 1 > +Version: 1.1 > Created: 2017-10-21 > -Last-Modified: 2017-12-16 > -Post-History: 2017-10-26, 2017-11-16 > +Last-Modified: 2018-02-08 > +Post-History: 2017-10-26, 2017-11-16, 2018-02-08 > Content-Type: text/x-rst > Requires: 59, 61 > Replaces: 44, 58, 60 > @@ -126,13 +126,6 @@ a different file type. If the tree contain files of > other types > that are not otherwise ignored, they need to be covered by an explicit > ``IGNORE``. > > -All the local (non-``DIST``) files covered by a Manifest tree must > -reside on the same filesystem. It is an error to specify entries > -applying to files on another filesystem. If files or directories that > -are not otherwise ignored reside on a different filesystem, or symbolic > -links point to targets on a different filesystem, they must > -be explicitly excluded via ``IGNORE``. > - > > Path and filename encoding > -- > @@ -325,22 +318,18 @@ Algorithm for finding parent Manifests > In order to find the top-level Manifest from the current directory > the following algorithm can be used: > > -1. Store the current directory as *original* and the device ID > - of the containing filesystem (``st_dev``) as *startdev*, > - > -2. If the device ID of the containing filesystem (``st_dev``) > - of the current directory is different than *startdev*, stop. > +1. Store the current directory as *original*, > > -3. If the current directory contains a ``Manifest`` file: > +2. If the current directory contains a ``Manifest`` file: > > a. If an ``IGNORE`` entry in the ``Manifest`` file covers >the *original* directory (or one of the parent directories), stop. > > b. Otherwise, store the current directory as *last_found*. > > -4. If the current directory is the root system directory (``/``), stop. > +3. If the current directory is the root system directory (``/``), stop. > > -5. Otherwise, enter the parent directory and jump to step 2. > +4. Otherwise, enter the parent directory and jump to step 2. > > Once the algorithm stops, *last_found* will contain the relevant > top-level Manifest. If *last_found* is null, then the directory tree > Observation: does RST not support auto-numbering like other formats? It would make renumbering lists like this much easier (and from programming experience, less error-prone). If not, #FEATUREREQ ... :] signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Last Rites: Dead X11 packages
On Thu, 8 Feb 2018 18:05:55 +0100 Michael Lienhardt wrote: > Il 08/02/2018 16:04, James Le Cuirot ha scritto: > >>> Citing Kenneth Hoste at FOSDEM this year: modifying a package > >>> without changing its version is a bad idea. > >>> His presentation was very good (video included): > >>> https://fosdem.org/2 > >>> 018/schedule/event/how_to_make_package_managers_cry/ > >> > >> This isn't so clear cut simple. We build from source at user > >> systems. Think of the effect for something like webkit-gtk, > >> chromium, libreoffice, etc. > > > > Exactly and while this package isn't as big as those, it could be > > argued that xorg-server is bumped frequently enough that the > > lingering dependency would have been flushed out soon enough > > anyway. It's not like it's doing any harm. > > > > I also think that FOSDEM talk was making a different point, aimed at > > upstreams in order to help packagers rather than packagers > > themselves. > > Thanks for the information and sorry for the noise. > I wasn't fully aware of the meaning of the --dynamics-deps and > --changed-deps option. I am still not entirely convinced that > changing a package after it is committed to the repository cannot do > harm: even as a user, I would like to know when and why a package's > dependencies changed. But I don't maintain packages so my opinion is > not very relevant, and the gentoo guidelines indeed allow to change > the dependencies inline. It's not like this stuff is totally invisible as it is noted in the git log. We just don't want to tie up several minutes of CPU time for the majority of users for no tangible benefit. -- James Le Cuirot (chewi) Gentoo Linux Developer
[gentoo-dev] [PATCH] glep-0074: Remove single filesystem limitation
Remove the limitation that all files covered by the Manifest must reside on a single filesystem. This breaks valid uses of overlayfs without providing any real advantage. The removal is justified further in the updated rationale section. --- glep-0074.rst | 66 +++ 1 file changed, 39 insertions(+), 27 deletions(-) RST: https://dev.gentoo.org/~mgorny/tmp/glep-0074.rst HTML: https://dev.gentoo.org/~mgorny/tmp/glep-0074.html diff --git a/glep-0074.rst b/glep-0074.rst index 3835247..2f8deb2 100644 --- a/glep-0074.rst +++ b/glep-0074.rst @@ -6,10 +6,10 @@ Author: Michał Górny , Ulrich Müller Type: Standards Track Status: Final -Version: 1 +Version: 1.1 Created: 2017-10-21 -Last-Modified: 2017-12-16 -Post-History: 2017-10-26, 2017-11-16 +Last-Modified: 2018-02-08 +Post-History: 2017-10-26, 2017-11-16, 2018-02-08 Content-Type: text/x-rst Requires: 59, 61 Replaces: 44, 58, 60 @@ -126,13 +126,6 @@ a different file type. If the tree contain files of other types that are not otherwise ignored, they need to be covered by an explicit ``IGNORE``. -All the local (non-``DIST``) files covered by a Manifest tree must -reside on the same filesystem. It is an error to specify entries -applying to files on another filesystem. If files or directories that -are not otherwise ignored reside on a different filesystem, or symbolic -links point to targets on a different filesystem, they must -be explicitly excluded via ``IGNORE``. - Path and filename encoding -- @@ -325,22 +318,18 @@ Algorithm for finding parent Manifests In order to find the top-level Manifest from the current directory the following algorithm can be used: -1. Store the current directory as *original* and the device ID - of the containing filesystem (``st_dev``) as *startdev*, - -2. If the device ID of the containing filesystem (``st_dev``) - of the current directory is different than *startdev*, stop. +1. Store the current directory as *original*, -3. If the current directory contains a ``Manifest`` file: +2. If the current directory contains a ``Manifest`` file: a. If an ``IGNORE`` entry in the ``Manifest`` file covers the *original* directory (or one of the parent directories), stop. b. Otherwise, store the current directory as *last_found*. -4. If the current directory is the root system directory (``/``), stop. +3. If the current directory is the root system directory (``/``), stop. -5. Otherwise, enter the parent directory and jump to step 2. +4. Otherwise, enter the parent directory and jump to step 2. Once the algorithm stops, *last_found* will contain the relevant top-level Manifest. If *last_found* is null, then the directory tree @@ -594,16 +583,39 @@ additional files in it, skipping some of the categories from syncing. This configuration can extend beyond the limits of this GLEP, e.g. by allowing wildcards or regular expressions. -The algorithm is restricted to work on a single filesystem. This is -mostly relevant when scanning for top-level Manifest -- we do not want -to cross filesystem boundaries then. However, to ensure consistent -bidirectional behavior we need to also ban them when operating downwards -the tree. -The directories and files on different filesystems need to be ignored -explicitly as implicitly skipping them would cause confusion. -In particular, tools might then claim that a file does not exist when -it clearly does because it was skipped due to filesystem boundaries. +Cross-filesystem Manifests +-- + +The first version of this specification had an additional requirement +that all files covered by the Manifest tree must reside on a single +filesystem. This requirement has been removed in version 1.1 for +the reasons outlined in this section. + +The original rationale stated that this restriction aims to prevent +crossing filesystem boundaries in the top-level Manifest lookup +algorithm. While that seemed a good idea at the time, there is no real +reason to prevent that and this particular method worked correctly only +if the files were placed in a dedicated filesystem. + +Worse than that, the original rationale did not anticipate the use +of overlayfs which combines multiple filesystems while preserving their +original metadata, including device and inode numbers. As a result, +if the repository was checked out to an overlayfs, it was quite possible +that different files had different device numbers, and the Manifest +checks failed due to crossing filesystem boundaries. + +Given no clear solution to that and no good reason to reject use +of overlayfs, the restriction was lifted. + +The only potential drawback of this is that the implementation may now +follow maliciously placed symbolic links pointing outside the tree. +If a regular file was replaced by such a symlink, the user could +be tricked into reporting the verification failure with the report +contain
Re: [gentoo-dev] Last Rites: Dead X11 packages
Il 08/02/2018 16:04, James Le Cuirot ha scritto: Citing Kenneth Hoste at FOSDEM this year: modifying a package without changing its version is a bad idea. His presentation was very good (video included): https://fosdem.org/2 018/schedule/event/how_to_make_package_managers_cry/ This isn't so clear cut simple. We build from source at user systems. Think of the effect for something like webkit-gtk, chromium, libreoffice, etc. Exactly and while this package isn't as big as those, it could be argued that xorg-server is bumped frequently enough that the lingering dependency would have been flushed out soon enough anyway. It's not like it's doing any harm. I also think that FOSDEM talk was making a different point, aimed at upstreams in order to help packagers rather than packagers themselves. Thanks for the information and sorry for the noise. I wasn't fully aware of the meaning of the --dynamics-deps and --changed-deps option. I am still not entirely convinced that changing a package after it is committed to the repository cannot do harm: even as a user, I would like to know when and why a package's dependencies changed. But I don't maintain packages so my opinion is not very relevant, and the gentoo guidelines indeed allow to change the dependencies inline. Michael
Re: [gentoo-dev] Last Rites: Dead X11 packages
On Thu, 08 Feb 2018 16:51:52 +0200 Mart Raudsepp wrote: > On Thu, 2018-02-08 at 14:57 +0100, Michael Lienhardt wrote: > > > > From e590965cdeb0c921194740da0481c85afaa1ebae Mon Sep 17 > > > > 00:00:00 2001 > > > > From: Matt Turner > > > > Date: Tue, 6 Feb 2018 14:02:59 -0800 > > > > Subject: x11-base/xorg-server: Remove dead x11- > > > > proto/xf86rushproto dependency > > > > > > > > rushproto hasn't been required since upstream commit > > > > 8ec79e05feac (in > > > > 2005!), and even then it wasn't actually needed! > > > > > > > > Package-Manager: Portage-2.3.19, Repoman-2.3.6 > > > > --- > > > > x11-base/xorg-server/xorg-server-1.19.5.ebuild | 3 +-- > > > > x11-base/xorg-server/xorg-server-1.19.6.ebuild | 3 +-- > > > > x11-base/xorg-server/xorg-server-.ebuild | 3 +-- > > > > 3 files changed, 3 insertions(+), 6 deletions(-) > > > > > > > > > > Please don't edit dependencies in-line like this. > > > > > > This warranted a revbump as users will be asking how to remove > > > x11-proto/xf86rushproto. It won't come up for depclean because of > > > xorg-server not being scheduled for rebuild automatically until > > > the next > > > time it is upgraded or --changed-deps option is used (uncommon). > > > > > > Brian > > > > Citing Kenneth Hoste at FOSDEM this year: modifying a package > > without changing its version is a bad idea. > > His presentation was very good (video included): > > https://fosdem.org/2 > > 018/schedule/event/how_to_make_package_managers_cry/ > > This isn't so clear cut simple. We build from source at user systems. > Think of the effect for something like webkit-gtk, chromium, > libreoffice, etc. Exactly and while this package isn't as big as those, it could be argued that xorg-server is bumped frequently enough that the lingering dependency would have been flushed out soon enough anyway. It's not like it's doing any harm. I also think that FOSDEM talk was making a different point, aimed at upstreams in order to help packagers rather than packagers themselves. -- James Le Cuirot (chewi) Gentoo Linux Developer
Re: [gentoo-dev] Last Rites: Dead X11 packages
On Thu, 2018-02-08 at 14:57 +0100, Michael Lienhardt wrote: > > > From e590965cdeb0c921194740da0481c85afaa1ebae Mon Sep 17 > > > 00:00:00 2001 > > > From: Matt Turner > > > Date: Tue, 6 Feb 2018 14:02:59 -0800 > > > Subject: x11-base/xorg-server: Remove dead x11- > > > proto/xf86rushproto dependency > > > > > > rushproto hasn't been required since upstream commit 8ec79e05feac > > > (in > > > 2005!), and even then it wasn't actually needed! > > > > > > Package-Manager: Portage-2.3.19, Repoman-2.3.6 > > > --- > > > x11-base/xorg-server/xorg-server-1.19.5.ebuild | 3 +-- > > > x11-base/xorg-server/xorg-server-1.19.6.ebuild | 3 +-- > > > x11-base/xorg-server/xorg-server-.ebuild | 3 +-- > > > 3 files changed, 3 insertions(+), 6 deletions(-) > > > > > > > Please don't edit dependencies in-line like this. > > > > This warranted a revbump as users will be asking how to remove > > x11-proto/xf86rushproto. It won't come up for depclean because of > > xorg-server not being scheduled for rebuild automatically until the > > next > > time it is upgraded or --changed-deps option is used (uncommon). > > > > Brian > > Citing Kenneth Hoste at FOSDEM this year: modifying a package without > changing its version is a bad idea. > His presentation was very good (video included): https://fosdem.org/2 > 018/schedule/event/how_to_make_package_managers_cry/ > This isn't so clear cut simple. We build from source at user systems. Think of the effect for something like webkit-gtk, chromium, libreoffice, etc. The problem here is the planned changing of --dynamic-deps to no as default.
Re: [gentoo-dev] Last Rites: Dead X11 packages
From e590965cdeb0c921194740da0481c85afaa1ebae Mon Sep 17 00:00:00 2001 From: Matt Turner Date: Tue, 6 Feb 2018 14:02:59 -0800 Subject: x11-base/xorg-server: Remove dead x11-proto/xf86rushproto dependency rushproto hasn't been required since upstream commit 8ec79e05feac (in 2005!), and even then it wasn't actually needed! Package-Manager: Portage-2.3.19, Repoman-2.3.6 --- x11-base/xorg-server/xorg-server-1.19.5.ebuild | 3 +-- x11-base/xorg-server/xorg-server-1.19.6.ebuild | 3 +-- x11-base/xorg-server/xorg-server-.ebuild | 3 +-- 3 files changed, 3 insertions(+), 6 deletions(-) Please don't edit dependencies in-line like this. This warranted a revbump as users will be asking how to remove x11-proto/xf86rushproto. It won't come up for depclean because of xorg-server not being scheduled for rebuild automatically until the next time it is upgraded or --changed-deps option is used (uncommon). Brian Citing Kenneth Hoste at FOSDEM this year: modifying a package without changing its version is a bad idea. His presentation was very good (video included): https://fosdem.org/2018/schedule/event/how_to_make_package_managers_cry/ Michael
Re: [gentoo-dev] Last Rites: Dead X11 packages
On 2/7/2018 9:54 PM, Matt Turner wrote: > # Matt Turner (06 Feb 2018) > # Dead and unused > # Masked for removal in 30 days. Bug #646838 > x11-libs/libXCalibrate > x11-libs/libXfontcache > x11-misc/xtscal > x11-proto/fontcacheproto > x11-proto/xcalibrateproto > x11-proto/xf86rushproto > From e590965cdeb0c921194740da0481c85afaa1ebae Mon Sep 17 00:00:00 2001 > From: Matt Turner > Date: Tue, 6 Feb 2018 14:02:59 -0800 > Subject: x11-base/xorg-server: Remove dead x11-proto/xf86rushproto dependency > > rushproto hasn't been required since upstream commit 8ec79e05feac (in > 2005!), and even then it wasn't actually needed! > > Package-Manager: Portage-2.3.19, Repoman-2.3.6 > --- > x11-base/xorg-server/xorg-server-1.19.5.ebuild | 3 +-- > x11-base/xorg-server/xorg-server-1.19.6.ebuild | 3 +-- > x11-base/xorg-server/xorg-server-.ebuild | 3 +-- > 3 files changed, 3 insertions(+), 6 deletions(-) > Please don't edit dependencies in-line like this. This warranted a revbump as users will be asking how to remove x11-proto/xf86rushproto. It won't come up for depclean because of xorg-server not being scheduled for rebuild automatically until the next time it is upgraded or --changed-deps option is used (uncommon). Brian signature.asc Description: OpenPGP digital signature
