On 1/20/20 9:50 AM, David Seifert wrote:
>
> Rich has given reasons, ulm has, and mgorny suggested a solution.
>
Everyone's real intent on saying that there are problems without
actually typing what those problems are into the email box.
We're talking about a single keepdir file here.
Please
On 1/20/20 2:02 AM, Ulrich Mueller wrote:
>>>>>> On Mon, 20 Jan 2020, Michael Orlitzky wrote:
>
>> install-qa-check.d: allow acct-user home directories under /home.
>
> Nope. As you've been told, /home is site specific and can be setup in
> multiple ways th
On 1/19/20 10:40 PM, Rich Freeman wrote:
> On Sun, Jan 19, 2020 at 10:16 PM Michael Orlitzky wrote:
>>
>> This is retarded, stop wasting my time.
>>
>
> There is nothing retarded about shared /home directories. They're
> pretty common in the real world.
>
What
These exceptions were made for the sys-apps/nix and sys-apps/guix
packages that are no longer in the tree.
---
metadata/install-qa-check.d/08gentoo-paths | 2 --
1 file changed, 2 deletions(-)
diff --git a/metadata/install-qa-check.d/08gentoo-paths
b/metadata/install-qa-check.d/08gentoo-paths
In rare cases, a system user will need a real home directory to store
per-user configuration data and/or be accessed interactively by a
human being. In those cases, /home/${username} is an appropriate place
for the user's home directory. Using /home is allowed and encouraged
by the FHS, and there
It's late and I'm sure this is buggy, but just complaining about it
isn't getting me anywhere.
Michael Orlitzky (2):
install-qa-check.d: disallow "nix" and "gnu" as top-level paths.
install-qa-check.d: allow acct-user home directories under /home.
metadata/install-qa-ch
On 1/19/20 9:52 PM, Rich Freeman wrote:
>>
>> Fantasy scenarios again. I'm not going to debunk a system that you just
>> thought up and that has never existed. Why don't you find one person who
>> actually does this, and see if it bothers him if we create a home
>> directory under /home where it
On 1/19/20 8:20 PM, Rich Freeman wrote:
> It would be far simpler for the sysadmin to simply ensure that no
> unsynced user owns a file or appears in an ACL. That would be pretty
> trivial to achieve. Whatever is hosting /home could be designed to
> block such changes, or you could just scan for
On 1/19/20 4:00 PM, Michael Orlitzky wrote:
>
> If I was willing to introduce a QA warning, this thread would have been
> a lot shorter =P
>
Just kidding, the eclass is rigged to die in src_install if you delete
the home directory, and if you wait until pkg_preinst, the warnin
On 1/19/20 2:47 PM, Rich Freeman wrote:
>
> Obviously the UIDs associated with the shared /home need to be
> identical. Simplest solution is to sync anything > 1000 in
> /etc/passwd, and then not allow UIDs below 1000 in /home. A cron job
> could easily handle both, and of course regular users
On 1/19/20 2:32 PM, Alec Warner wrote:
>
> Earlier you wrote:
>
> * The daemon DOES NOT need a home directory for its user.
> * I DO NOT want to install anything to anyone's home directory.
> * With respect to user.eclass, I'm proposing that /home be treated
> EXACTLY THE SAME as it
On 1/19/20 2:19 PM, Alec Warner wrote:
>
> All I want to do is *set* a user's home directory to /home/foo.
>
> Why wouldn't you set the homedirectory to /dev/null then?
>
Because /dev/null is not /home/foo? Is this a trick question? =)
On 1/19/20 2:02 PM, Rich Freeman wrote:
>
>> If you're sharing /home, you also have to be sharing user accounts,
>> unless you want everyone to be assigned a random set of files.
>
> I imagine that most people setting up something like this would only
> be sharing high-value UIDs (>1000 in our
On 1/19/20 12:42 PM, Rich Freeman wrote:
>
> Typically you wouldn't share service accounts across multiple hosts.
> I'd think that something like amavisd is going to go on a mail server.
> You're not going to be logging into that account to do typical
> desktop-oriented functions.
>
> If you had
On 1/19/20 6:29 AM, Rich Freeman wrote:
>
> Daemons are local users. There is no guarantee that /home is a local
> filesystem. Heck, there is no guarantee that /home is even mounted
> when portage is running. Portage shouldn't be touching /home at all.
> With stuff like automounted or
On 1/18/20 7:21 PM, Rich Freeman wrote:
> On Sat, Jan 18, 2020 at 6:38 PM Michael Orlitzky wrote:
>>
>> But now users have to follow one more step (create /home/amavis) when
>> setting up amavisd-new. Is the QA check really assuring a quality user
>> experience here?
&
On 1/18/20 1:10 PM, Ulrich Mueller wrote:
>
>> Should option (3) be viable, or do I go back to the drawing board?
>
> Chances are that /home is site specific, e.g. with a special backup
> policy, or shared between many hosts via NFS. So IMHO /home is off
> limits for the package manager.
>
We
On 1/18/20 2:03 PM, Alec Warner wrote:
>
> I tend to agree that in theory keeping the working directory and home
> directory the same is not ideal. However I'm not really aware of any
> practical problems. Haven't we basically run in this configuration for
> years? What kind of issues does it
On 1/18/20 2:08 PM, Michał Górny wrote:
>
> Sounds like you've created an arbitrary rule that prevents the two
> packages from using the same directory, and therefore you've created
> this problem yourself. Why not just go back and reconsider using
> the same directory instead of adding
We forbid packages from installing to /home for good reason: for most of
history, users (and their home directories) were outside the purview of
the package manager. But with GLEP81, that's changed: the package
manager is now in charge of creating each system user's home directory
and of giving it
On 1/4/20 2:13 PM, Rolf Eike Beer wrote:
>
> Bad idea. If you wonder why: eshowkw dev-lang/rust.
>
Or consider that every rust package in Gentoo bundles hundreds of
libraries. We'd be fixing one security issue by introducing 10x more.
Not that rewriting it in rust would fix anything; writing
On 1/3/20 9:52 AM, Michael Orlitzky wrote:
>
> But here we are. Do we make OpenRC Linux-only and steal the fix from
> systemd? Or pretend to support other operating systems, but leave them
> insecure?
>
Or the gripping hand: rewrite opentmpfiles in C, so that it's only as
insecu
On 1/3/20 9:46 AM, Rich Freeman wrote:
>
> ...
>
> In any case this seems more like an OpenRC issue than a Gentoo issue.
>
It's a specification issue. There's no way to implement tmpfiles safely
on a POSIX system, and opentmpfiles shouldn't exist if OpenRC wants to
work on anything other than
On 1/3/20 9:40 AM, Toralf Förster wrote:
> On 1/3/20 3:37 PM, Michael Orlitzky wrote:
>> The gentoo-sources aren't 100% safe either, but the exploitable scenario
>> is less common thanks to fs.protected_{hardlinks,symlinks}=1.
>
> But this can be easily achieved w/o inst
On 1/2/20 6:35 PM, Rolf Eike Beer wrote:
>
> I only run vanilla-sources since there are still lot of cache corruption
> problems in hppa kernels, or whatever makes them flaky.
The vanilla-sources are unsafe to use on Gentoo. Many services have
stupid-easy root exploits, since we install
On 12/26/19 11:56 AM, Thomas Deutschmann wrote:
>
> Why can't I use rm, mv, cp or text editor to change things?
If you change a file belonging to a system package, then the next time
you upgrade or reinstall that package, your changes get overwritten.
> System configuration management is
On 12/26/19 9:41 AM, Thomas Deutschmann wrote:
>
> which would remove nginx from myapp group to match ACCT_USER_GROUPS set
> in acct-*/nginx ebuild which would break my application server. Does
> that really happen?
Yes; if we want to be able to add/remove groups in acct-user ebuilds,
then
On 12/26/19 8:28 AM, Thomas Deutschmann wrote:
> On 2019-12-26 12:04, Michael Orlitzky wrote:
>> On 12/25/19 10:11 AM, Thomas Deutschmann wrote:
>>> +ACCT_USER_HOME=/var/lib/jenkins
>> Needed?
>
> I cannot answer that for sure. In *my* setups I need a valid home fo
On 12/25/19 10:11 AM, Thomas Deutschmann wrote:
> +ACCT_USER_HOME=/var/lib/jenkins
Needed?
On 12/21/19 6:39 AM, Ulrich Mueller wrote:
>>>>>> On Sat, 21 Dec 2019, Michael Orlitzky wrote:
>
>> I was being safe, and assuming that your standards for shell scripting
>> are as low as your standards for tree quality.
>
> Nice, resorting to
On 12/21/19 6:39 AM, Ulrich Mueller wrote:
>>>>>> On Sat, 21 Dec 2019, Michael Orlitzky wrote:
>
>> I was being safe, and assuming that your standards for shell scripting
>> are as low as your standards for tree quality.
>
> Nice, resorting to a personal a
On 12/21/19 1:57 AM, Ulrich Mueller wrote:
>
> See? You say it yourself, with 400 revbumps there is quite some chance
> for breakage.
>
I was being safe, and assuming that your standards for shell scripting
are as low as your standards for tree quality.
On 12/18/19 6:28 PM, Michael Orlitzky wrote:
>
> This *does* happen if you mask virtual/emacs. It *could* happen if you
> delete it.
>
I tested this out.
Portage seems OK with the missing dependency, but for the overall plan
to work, you have to wait a long time before deleting v
On 12/19/19 12:37 PM, Michał Górny wrote:
>
> Just because someone did something crappy, it doesn't mean it was
> considered 'good enough'. It was just a cheap hack that someone once
> did just to get it over with and stop caring. Not a good solution we
> should keep copying.
>
These should
On 12/18/19 4:02 PM, Sebastian Pipping wrote:
> Hi all,
>
>
> I noticed that dev-util/cmake depends on dev-libs/expat and that
> libexpat upstream (where I'm involved) is in the process of
> dropping GNU Autotools altogether in favor of CMake in the near future,
> potentially the next release
On 12/18/19 11:34 AM, Ulrich Mueller wrote:
>
> Removal of the virtual/emacs ebuilds won't remove the installed package
> from users' systems. It will eventually disappear, when all its reverse
> dependencies have been updated. Why would its continued presence as an
> installed package (for
On 12/18/19 6:08 AM, Ulrich Müller wrote:
> No revbumps will be done for this (and virtual/emacs will be simply
> removed without prior masking).
I guess it's nice that we know ahead of time, but is there any reason to
suspect that this won't cause havoc?
On 12/14/19 5:02 PM, Thomas Deutschmann wrote:
>
> acct-* shouldn't mess with already *existing* users. So upgrade
> experience shouldn't be affected...
Even on upgrades, pkg_postinst() in acct-user.eclass will update the
home directory, shell, groups, and comment field.
Without more
On 12/15/19 9:46 AM, Ralph Seichter wrote:
>
> Milter-regex only needs a user to isolate the process and it's single
> configuration file (/etc/milter-regex.conf). My PR adds acct-user/milter
> without a home directory, because milter-regex does not need one, nor
> does it write anything to disk.
On 12/14/19 11:53 PM, Ralph Seichter wrote:
Of the three packages you mentioned, milter-regex (not regex-milter) is
the only one with a name that actually contains "milter". OpenDMARC
should never have user a user named milter in the first place, and in
the future it should use "opendmarc".
On 12/13/19 4:17 PM, Ralph Seichter wrote:
The mail-filter/milter-regex ebuild already uses user/group 'milter',
and for the currently open bump to version 2.7 I'd like to claim GID/UID
438.
I recently cited the "milter" user on this list as a bad example from
the user.eclass days... it was
On 12/13/19 9:28 AM, Fabian Groffen wrote:
>
> We are providing those patches, maybe. In reality very often the
> patches originate from somewhere else though. And you don't want to
> have to respin all of those just because. At least that's what I feel.
>
Just because... the context
On 12/12/19 3:15 PM, Ulrich Mueller wrote:
>
> It was also suggested that we add -F0 in EAPI 8, but that would break
> the build in those cases that are producing extra output now. I don't
> think that would be preferable.
It would only break the build for the maintainer, who would then
On 12/11/19 8:45 AM, Marek Szuba wrote:
> +ACCT_USER_HOME=/var/lib/suricata
> +ACCT_USER_HOME_PERMS=0750
Please don't set these unless it's absolutely necessary. The rationale
for this has finally been committed to the devmanual, but has yet to be
pushed to the website. In the meantime it's
On 12/10/19 11:05 AM, Joonas Niilola wrote:
>
> I was more thinking along sys admins being able to modify their acct-
> ebuilds with static numbers. If you're bind-mounting already, why not
> bind your portage (or local overlay) to children as well. 2 minute more
> work for those who need it, but
On 12/9/19 3:17 AM, Michał Górny wrote:
>
> 2. Mailing list reviews don't serve their original purpose.
>
> The original purpose of mailing list reviews was to verify that
> the developers use new packages correctly. For example, Michael
> Orlitzky has found a lot o
On 12/9/19 3:10 PM, Thomas Deutschmann wrote:
> On 2019-12-09 19:48, Ulrich Mueller wrote:
>>> On Mon, 09 Dec 2019, Thomas Deutschmann wrote:
>>
>>> Like said, if an ID is already taken for any reason on user's system,
>>> that's not a problem. acct-* can handle that... there's nothing like a
On 12/6/19 11:29 AM, Alexis Ballier wrote:
>
> Without good integration from the checker it is probably a PITA to
> figure out that 23 too
If you're reading through your commit log and if you see something
wrong, you can
$ git rebase -i
to do a rebase starting at the one you'd like to fix.
On 12/3/19 5:41 AM, Petr Vaněk wrote:
>
> Btw, I am just curios about the situation when there is a foo overlay
> with acct-{user,group}/foo using UID/GID already set in main gentoo
> overlay and later on we would like to move it to the main gentoo
> overlay. It would be necessary to chose
On 12/2/19 10:23 AM, Petr Vaněk wrote:
>
> Would it be possible to move tox to 199/199 and set rspamd to 236/236 to
> be more compatible with other distributions, or should I chose some
> other UID/GID?
>
Changing an existing UID/GID isn't possible. It's technically infeasible
-- not just that
On 11/27/19 11:57 AM, Michał Górny wrote:
>
> Also I'm sure Michael would love to see a patch, so he could complain
> that you're unnecessarily setting a home directory.
>
Ha! ...but seriously though.
On 11/27/19 2:17 PM, Michał Górny wrote:
>
> To achieve that, attempt to apply each patch with -F0 --dry-run first.
> If this succeeds, just silently apply the patch for real. If it
> doesn't, output an explicit eqawarn that the patch does not apply
> cleanly and retry with the default fuzz
On 11/20/19 10:32 PM, Haelwenn (lanodan) Monnier wrote:
>
> To reflect this I think the "gles[123]" USE flags should be renamed,
> first kind to "gles[123]support" and second kind to "gles[123]only".
> Might also be the time to globalize them? I'm not sure but I think that
> would help in
On 11/16/19 4:41 PM, Michał Górny wrote:
>
> More precisely, this is in context of dependency corrections. There is
> no need to go through stabilization to restrict too broad dependency
> specifications, while stable users hit the issue for the next two
> months.
>
The word "dependency"
On 11/16/19 8:55 AM, Ulrich Mueller wrote:
>
> This is in the context of revision bumps, not version bumps.
The things allowed in a revision bump are,
* New EAPI,
* Adding/dropping eclasses,
* Adding/dropping dependencies,
* Adding/dropping a phase function,
* Literally anything,
On 11/15/19 7:22 AM, Michał Górny wrote:
>
> https://devmanual.gentoo.org/general-concepts/ebuild-revisions/index.html
>
Two things on that page are outright wrong:
1. If the package has stable keywords, they should be moved to the new
revision without dropping. To commit the ebuild,
On 11/15/19 7:04 AM, Alexey 'Alexxy' Shvetsov wrote:
>
> As i remember some decades ago policy was: revbump needed if you change
> chnages stuff installed on filesystem. So in case of py addition it is. So
> what
> changed?
>
> Are there some new written rules that says in what case you need
On 11/12/19 3:59 AM, Lars Wendler wrote:
>
> You can find the commits (among others) for possible review here:
> https://github.com/Polynomial-C/gentoo/commits/accts-cronie
>
Please leave ACCT_USER_HOME at the default and create /var/spool/cron in
the cronie ebuild (with whatever permissions it
On 11/10/19 12:36 PM, Jaco Kroon wrote:
>
> What's the motivation for trying to match the UID and GID values from
> other distributions?
>
> I previously tried to motivate a "purely dynamic" allocation with -1,
> I'm showing this as an example where such an implementation would once
> more be
On 11/9/19 2:04 PM, Aaron Bauman wrote:
> # Aaron Bauman (2019-11-09)
> # upstream moved to Github. not bumped in years
> # EAPI=4 and maintainer-needed. Removal in 30 days
> app-laptop/hdaps-gl
>
I took this one and made an EAPI=7 revision. I also contacted the
maintainer of the other hdaps
2. Those other files don't get installed to the root filesystem on the
systems that we're talking about.
I do not understand what you think I'm referring to and which files you
are talking about.
The way I'm thinking of a root fs is, /bin, maybe /boot, /etc, /lib* and /sbin.
Most junk
On 11/4/19 2:40 PM, William Hubbs wrote:
This is a whole other thread I've been talking about for years, but if
we want to be concerned about dumping "garbage" on people's limited root
file systems, there are other things we need to re-consider, like our
notion that we have to install small
* Error: The above package list contains packages which cannot be
* installed at the same time on the same system.
(dev-tex/xcolor-2.12-r1:0/0::gentoo, installed) pulled in by
>=dev-tex/xcolor-2.11 required by
(app-text/texlive-2019:0/0::gentoo, installed)
commit
On 11/4/19 11:02 AM, Michał Górny wrote:
I did request a QA vote to confirm it. William demands that I close it
Take a page out of the WilliamH playbook and completely ignore him.
On 11/4/19 10:01 AM, Michał Górny wrote:
Hi,
TL;DR: If a QA check is enforced by Portage for a reasonably long time,
does it constitute policy? Or can it be changed unilaterally by Portage
team?
To avoid these sorts of questions in the future, it might be worth the
time it would take to
On 10/24/19 10:03 PM, Michael Everitt wrote:
>
> Forgive my lack of git-fu, but which commit did this? Can we name & shame
> the author and committer publicly, and in front of QA, so that this kind of
> violation is highlighted to all, and noted for future reference?
>
I left it out on purpose.
Here we go again. All week I've been trying to update @world. I'm trying
to troubleshoot a portage bug[0], deal with portage taking forever to
fail, and now I've got to deal with the fact that someone was too clever
to follow the PMS and replaced virtual/pam with sys-libs/pam across the
entire
> dev-ruby/vcard
And this one's used by a popular Redmine plugin. I'll have to do
something to keep it working. Redmine is still making releases (as of
yesterday) that support only ruby24, so I don't expect the plugin
developers to treat this very urgently.
I filed an issue at least...
On 8/30/19 10:34 AM, michael.lienha...@laposte.net wrote:
>
> All comments/suggestions are welcomed.
>
Since no one else has said it yet (?), I think this approach is really
cool and I'm glad someone is working on it.
Modeling difficult computations as abstract optimization problems is a
On 9/21/19 3:59 PM, Michał Górny wrote:
>
> Honestly, do you believe having the choice of 'GPL-2' and 'GPL-2-only'
> people would choose the latter without actually checking the difference?
I've seen twenty people do ten stupider things in the last five minutes.
On 9/21/19 12:09 PM, Michał Górny wrote:
> Hi,
>
> TL;DR: I'd like to replace 'GPL-2' with 'GPL-2-only' etc., having
> the former trigger QA warning asking the dev to double-check if it's
> 'GPL-2-only' or 'GPL-2+'.
>
This works only until people start putting
LICENSE="GPL-2-only"
for
On 9/18/19 3:33 PM, Alec Warner wrote:
>
> I think the problem I have with this conversation is that I am
> discussing things that are technically possible (e.g. we can in fact
> propagate security fixes to all go packages, same as dynamically linked
> packages) with things we do not think we
On 9/18/19 5:28 PM, William Hubbs wrote:
>>
>> I don't really understand why you're adding it to *this* eclass. Isn't
>> it true for all Go packages? So I suppose golang-* eclasses are
>> affected as well.
>
> You are correct, they are affected. No one, including myself, caught
> that during
On 9/18/19 2:04 PM, Alec Warner wrote:
>
> I'm actually pretty fine with this wording, upstream has said not to
> dynamically link in these use cases.
>
Respectfully, the fact that you're OK with it doesn't make it not BS. It
reads like "there's no way we can fix this!" when really it means
On 9/16/19 10:17 AM, William Hubbs wrote:
> +
> +# @FUNCTION: go-module_pkg_postinst
> +# @DESCRIPTION:
> +# Display a warning about security updates for Go programs.
> +go-module_pkg_postinst() {
> + ewarn "${PN} is written in the Go programming language."
> + ewarn "Since this language
On 9/14/19 1:06 PM, Alec Warner wrote:
>
> - There appears to be some expectation that consensus is required on
> the ML; this has (IMHO) never been true. The 'decider' for what to do
> isn't the mailing list (by GLEP, it's the council). So this idea that
> you can object on the ML and stop a
(Replying to both messages at once.)
On 9/13/19 4:17 PM, Patrick McLean wrote:
>>
> I don't think anyone here has suggested that any go packages are
> installed in the stage3 tarballs, or included in profiles. Something's
> presence in the tree does not mean that you are required to install it.
On 9/12/19 1:45 PM, Alec Warner wrote:
>
> Er, I'm fairly sure computer *science* has not conclusively proven that
> dynamic binaries are somehow superior to static binaries.
>
Please don't make me work this hard ever again.
The principal of modularity in software design goes back to at least
On 9/13/19 5:19 AM, Kent Fredric wrote:
> On Thu, 12 Sep 2019 17:58:08 -0400
> Michael Orlitzky wrote:
>
>> What kind of math would convince you that an idea with all "cons" and no
>> "pros" is bad?
>
> Is "upstream tooling doesn't work w
On 9/12/19 5:23 PM, Mike Gilbert wrote:
>
> Putting the dependencies in RDEPEND means users get stuck with yet
> another copy of the code installed, in addition to the copy that is
> statically linked into all reverse dependencies.
>
> It's not a very good solution to the problem.
>
No
On 9/12/19 1:45 PM, Alec Warner wrote:
>
> Er, I'm fairly sure computer *science* has not conclusively proven that
> dynamic binaries are somehow superior to static binaries.
>
What are the benefits of static linking to the end user on Gentoo? The
comprehensive list is usually,
* The
On 9/12/19 1:43 PM, Mike Gilbert wrote:
>
> They do "go away" if you pass the right options to emerge, or if you
> install it from a binpkg in the first place.
>
The dependencies are statically linked into the final executable forever
and receive no security updates. Portage doesn't even know
On 9/12/19 12:55 PM, Mike Gilbert wrote:
>
> Portage only handles rebuilds for slot-operator deps in RDEPEND. It
> ignores slot-operators in DEPEND.
>
Sure, but putting them in RDEPEND isn't a problem. It's not like the
statically-linked bundled dependencies actually go away with a depclean,
On 9/12/19 12:42 PM, Alec Warner wrote:
>
> In general I don't see bundling as a major problem. In the land of
> dynamic binaries, it's a big advantage because you can upgrade libfoo
> and all consumers of libfoo get the upgrade upon process restart. This
> isn't true for most go programs which
On 9/12/19 11:46 AM, William Hubbs wrote:
>
> In other words, the way I see this is a tree-wide issue. LICENSE= for
> any package should list every license for every package it links to or
> uses.
>
There is no issue tree-wide, because no one else is trying to cut
corners and bundle every
On 9/11/19 1:47 PM, William Hubbs wrote:
> On Wed, Sep 11, 2019 at 01:39:32PM -0400, Michael Orlitzky wrote:
>> On 9/11/19 1:21 PM, William Hubbs wrote:
>>> +++ b/dev-vcs/hub/hub-2.12.3.ebuild
>>> ...
>>>
>>> LICENSE="MIT"
>>
>>
On 9/11/19 1:21 PM, William Hubbs wrote:
> +++ b/dev-vcs/hub/hub-2.12.3.ebuild
> ...
>
> LICENSE="MIT"
This license is wrong, as it's pretty much guaranteed to be every time
you commit one of these packages. I find it pretty troubling that one
corporation is able to force this stuff through
On 9/10/19 4:25 PM, Rolf Eike Beer wrote:
>
> I'm not entirely sure. It's what qmail always has done and what the eclass
> also did.
>
This is suggested by the qmail documentation,
http://lifewithqmail.org/lwq.html#create-users
...but goes back to at least 1998, and likely earlier. I
On 9/9/19 2:19 PM, Zac Medico wrote:
> On 9/9/19 10:34 AM, William Hubbs wrote:
>
>> There is another option I want to try which is adding "go mod vendor" to
>> src_unpack for go packages.
>
> If you do that then it will violate FEATURES=network-sandbox (default)
> unless you also do
On 9/8/19 2:40 PM, JoMull01 wrote:
> I would like to reserve UID/GID 236 for tox (net-libs/tox).
>
> Pending PR: https://github.com/gentoo/gentoo/pull/12888
>
Do you need the UID too? The pull request is only for the group.
On 9/2/19 12:32 PM, Mike Gilbert wrote:
>
> I can't really agree with the advice given in this section.
>
> If I'm maintaining a package and an associated acct-user package, I'm
> going to keep the two in sync. I don't see why I should have to create
> a directory via pkg_postinst when I could
Now that GLEP81 is in the devmanual, this is a rough draft of the
guidelines from my earlier message. Please send me your comments,
suggestions, and complaints now so that I can address them before
posting the final draft on bugzilla.
Michael Orlitzky (1):
ebuild-writing/users-and-groups: GLEP
GLEP 81 significantly changes the way that user management is handled,
and reveals some subtle issues in existing packages that have remained
hidden until now. Many of these issues can be avoided (in GLEP 81, but
also in general) by exercising some discipline when choosing the data
for new users
On 8/31/19 4:03 AM, Michał Górny wrote:
>
> I've already cleaned up some false positives (like svgalib). If you
> know more, please let me know.
>
> ...
> dev-libs/gnulib
This one has only prefix keywords and is maintained by prefix@. It has a
recentish EAPI=6 version.
On 8/17/19 4:35 AM, Ulrich Mueller wrote:
>>>>>> On Sat, 17 Aug 2019, Michael Orlitzky wrote
>
> Same for the "sshd" user, which IIRC chroots to /var/empty, but must
> not (be able to) write to that dir.
>
OpenSSH is configurable in this regard, but th
On 8/29/19 4:31 PM, Azamat Hackimov wrote:
> Hello.
>
> I need UID/GID for www-apps/redmine. Originally package creates own user
> and group named redmine, but I think it's better to create generic
> user/group for all web-applications, like www-data in Debian/Ubuntu or http
> in Arch.
> Is there
On 8/23/19 3:45 PM, Michał Górny wrote:
>>
>> That used to be acceptable, since the "enewuser" command with the home
>> directory was part of the package that used that directory. But now that
>> the user data are in another package, we can't depend on them reliably.
>>
>
> ...and why is that,
On 8/23/19 3:27 PM, Alexey 'Alexxy' Shvetsov wrote:
> +DESCRIPTION="User for the slurm - Highly Scalable Resource Manager"
> +ACCT_USER_ID=500
> +ACCT_USER_HOME=/var/lib/slurm
> +ACCT_USER_HOME_PERMS=0770
> +ACCT_USER_GROUPS=( slurm )
If your package uses that directory, I would recommend you not
On 8/17/19 4:43 PM, Michał Górny wrote:
>>
>> I realize we'd have to tell people how to rename the account to support
>> upgrades -- but is there some other reason to keep the shared "git" name?
>
> The argument I've been told is that users expect 'git@...' to work
> as remote URI on their boxes.
On 8/17/19 4:35 AM, Ulrich Mueller wrote:
>
>> 2 No two acct-user packages should define the same ACCT_USER_HOME.
>
> These two points are not fulfilled by the users that currently belong
> to baselayout. For example, "operator" (and "toor" on BSD) share /root
> with the root user.
>
Let me
201 - 300 of 942 matches
Mail list logo
