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 al
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/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 PROPERTIES+=
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 greppe
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 even
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/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 dependen
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 ar
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,
any
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 th
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 applicat
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 argument
On 9/12/19 11:13 PM, Mike Gilbert wrote:
>
> I'm really objecting to your suggestion that we abuse an existing
> Portage/PMS feature to do something beyond its design. Adding
> fictitious runtime dependencies is wrong, and seems like a very lazy
> solution.
Ok, you're right.
> If you want to pr
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
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
1
(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/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 thi
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 is
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 "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 the
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 will
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 things
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.
> 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...
htt
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 tree
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. T
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 vot
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.
* 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 6bcaed54ee9d8f0a987d4
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 file
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 g
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 pro
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 ben
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/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/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, rep
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, excep
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" doesn'
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 signall
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 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 w
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 differe
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/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/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
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/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 here:
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 us
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".
Bes
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 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 information
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/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 anothe
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 (wi
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 al
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/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/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 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/25/19 10:11 AM, Thomas Deutschmann wrote:
> +ACCT_USER_HOME=/var/lib/jenkins
Needed?
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/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 that's
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 abstra
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 tmpfiles
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 ins
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 L
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
i
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 it
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/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 complexit
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 pos
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 d
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/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 encrypted
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 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 ca
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: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: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 c
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 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 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 be
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.
metadat
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 a
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
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.
>
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 wa
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 d
On 1/20/20 11:57 AM, William Hubbs wrote:
>
> Imo a better fit is the metadata directory in the ebuild repository.
> That way you can add users/groups along with the acct-* packages that
> install them.
What benefit is there to syncing that file to everyone's machines?
On 1/20/20 1:01 PM, Ulrich Mueller wrote:
>
> It's just awful to have a one user at second level (like /home/amavis)
> when all others are at third level (like /home/staff/joe).
>
Finally an honest argument =)
I agree. But all we're doing is choosing the default here. GLEP81 lets
the user overr
On 1/20/20 1:39 PM, Michał Górny wrote:
>
> I'm going to be blunt. We arbitrarily made a decision that /home
> belongs to sysadmin. Please respect that. If you really believe your
> package is *this* special to justify changing this arbitrary decision,
> the burden of proof lies on you.
>
Ok.
On 1/20/20 5:08 PM, Alec Warner wrote:
>
> So I can describe in detail one example, but its not running Gentoo; so
> I'm not sure if you care in practice.
Yes, I'm happy to see a real example.
> At work we had sec=krb5 NFS v3 mounted home directories. They were
> mounted in /home (via the autom
Let it die =) I'm not going to apply the patch; it's there if someone
else decides that it's the least-bad solution to this problem.
On 1/20/20 6:57 PM, Andreas K. Huettel wrote:
>
> Why *isn't* some /var/lib/... possible here?
It is, the question is how many backflips we should be doing to avo
On 1/21/20 6:44 AM, Jaco Kroon wrote:
>
> There is technically no real issue, but it's the right thing to do.
>
> Right, motivations for your proposal for allowing this:
>
> * You want it.
>
> Motivations against:
>
This is dishonest. "I want it" because it improves some things for our
users,
On 1/26/20 9:46 PM, Georgy Yakovlev wrote:
> # update your rust packages running emerge with the
> # --changed-deps option if you have problems
If this advice helps, you have violated the PMS.
On 3/18/20 10:54 AM, William Hubbs wrote:
>
> So, my question is, why can't we add a noarch/~noarch keyword and see
> how things go? If it gets abused we can always nuke it later.
>
This is a good goal, but as others have pointed out, adding a new magic
keyword poses some workflow problems.
We
On 12/03/2014 07:28 AM, Diamond wrote:
> On Mon, 01 Dec 2014 11:38:44 +0100
> Pacho Ramos wrote:
>
>>
>> # Pacho Ramos (01 Dec 2014)
>> # Upstream dead for a long time, use sys-power/cpupower
>> # instead. Removal in a month.
>> sys-power/cpufrequtils
>> x11-plugins/gkrellm-cpufreq
>>
>
> Give
# Michael Orlitzky (24 Dec 2014)
# Masked for removal in 30 days (bug #531954). All current versions of
# nagios block it, and it has unresolved LICENSE issues (bug #320241).
net-analyzer/nagios-imagepack
I vaguely remember a discussion about maintainers stabilizing their own
packages -- maybe just on x86 and amd64 -- to take the load off of the
arch teams.
Did that really happen or am I making it up? Is it written down anywhere?
On 01/08/2015 12:57 PM, Mikle Kolyada wrote:
>
> 08.01.2015 20:15, Michael Orlitzky пишет:
>> I vaguely remember a discussion about maintainers stabilizing their own
>> packages -- maybe just on x86 and amd64 -- to take the load off of the
>> arch teams.
>>
>
601 - 700 of 919 matches
Mail list logo
