On 2020-09-04 04:39, Martin Vaeth wrote:
>
>> That's completely legal according to the PMS, and also the
>> smart thing to do:
>
> s/smart/dumb/, but necessary for a dumb PM
Word games notwithstanding, these are the package managers described by
the PMS.
>> sourcing a few thousand lines of
On 2020-09-03 12:38, Alexis Ballier wrote:
>
> if some upgrade wants a package with unmatched deps (e.g. not installed
> at all or py38 usedep not satisfied), $PM will surely try to satisfy
> it by installing an ebuild. I don't think PMS specifies this, nor should
> it.
>
It's not an upgrade
On 2020-09-02 14:08, Andreas Sturmlechner wrote:
> On Wednesday, 2 September 2020 19:42:33 CEST Michael Orlitzky wrote:
>> New USE flags generally change dependencies (as is the case here), so a
>> new revision ensures that people are forced to install the ebuild that
>>
On 2020-09-02 13:23, Sam James wrote:
>
> Please request stabilisation of your Python 3.8+ changes at the 30 days
> point, or earlier if it’s a trivial revbump
> (as new Python targets are equivalent to new USE flags, there is no real need
> for a revbump unless doing other tidying
> whilst
On 2020-09-01 08:38, Max Magorsch wrote:
> Do you think this is something you would be interested in? Do you
> have any features you like to see included in this case?
Yes!
Here's a trick that bugzilla cannot do: show me the bugs that are
assigned to me **or a project that I'm a member of**.
-by: Michael Orlitzky
---
repoman/lib/repoman/modules/linechecks/deprecated/inherit.py | 1 -
1 file changed, 1 deletion(-)
diff --git a/repoman/lib/repoman/modules/linechecks/deprecated/inherit.py
b/repoman/lib/repoman/modules/linechecks/deprecated/inherit.py
index 60410347b..5848a0c37 100644
On 2020-08-07 14:43, Toralf Förster wrote:
> On 8/7/20 8:25 PM, Michael Orlitzky wrote:
>>
>> I have too many other things to do to waste time reverse-engineering
>> these fuck-ups. Get it together.
>
> I'm just curious if you refer to commit d8c442ba8 - b/c that was ma
When you ignore the devmanual and the pkgcheck warning and the 10+
threads I've started about the issue, and make changes like...
--- a/x11-base/xorg-x11/xorg-x11-7.4-r3.ebuild
+++ b/x11-base/xorg-x11/xorg-x11-7.4-r3.ebuild
@@ -1,4 +1,4 @@
-# Copyright 1999-2018 Gentoo Foundation
+#
This adds support for using system-bootstrap to build Rust for the
armv5tel profile. It does not add binary bootstrap compilers.
Signed-off-by: David Michael
---
Hi,
I have an ARM9 chip that I'd like to be able to target for Rust
packages. Things are getting masked in the armv5tel profile
On 2020-07-03 18:35, Xianwen Chen (陈贤文) wrote:
>
> In the Makefile, it is written that
>
> cc = g++
>
> I would like to use sed to patch it so that it ebuild knows which g++ to
> use. For example, depending on whether ccache is set, ebuild shall know
> whether to use ccache.
First, you should
On 2020-06-30 12:22, Matthew Thode wrote:
>
> I'd like to suggest allowing only approved variables in the build
> environment, having portage unset all variables and setting only what is
> needed (or configured).
I think this is orthogonal to the problem I'm trying to solve. Even if
all
As many of you probably know, ago@ has been expanding the scope of our
CFLAGS/CC support to include some other common build variables:
* CC
* CXX
* AR
* CPP
* NM
* RANLIB
* AS
* LD
Some of those are POSIX standards[0],
* CC
* AR
Others are de-facto GNU make standards[1],
On 2020-06-24 16:08, Michał Górny wrote:
>
> $ git grep -l mgo...@gentoo.org '**/metadata.xml' | cut -d/ -f1-2 |
> xargs gpy-py2 2>/dev/null
>
The big problem with this is that it misses any aliases (like graphics@)
that you're a member of. But let's golf; this is POSIX sh, doesn't use
grep to
Le 17/06/2020 à 08:15, Michał Górny a écrit :
On Tue, 2020-06-16 at 23:07 +, Michael Lienhardt wrote:
Dear all,
My bad for not noticing it sooner, but when there is a dependency like
">=sys-fs/udev-208-r1:0/0[static-libs?]" (that occurs in
virtual/libgudev-215-r3),
Le 17/06/2020 à 10:35, Ulrich Mueller a écrit :
On Wed, 17 Jun 2020, Michael Lienhardt wrote:
But maybe, "error" here in the PMS mean "the cpvs without the use flag
does not match that dependency and a warning should be raised to
improve compatibility in the future". In
On 6/17/20 1:25 AM, Zac Medico wrote:
> On 6/16/20 7:47 PM, Michael Lienhardt wrote:
>>
>>
>> On 6/16/20 11:59 PM, Zac Medico wrote:
>>> On 6/16/20 6:38 PM, Michael Lienhardt wrote:
>>>> With the first version of DEPEND, emerge succee
On 6/16/20 11:59 PM, Zac Medico wrote:
> On 6/16/20 6:38 PM, Michael Lienhardt wrote:
>> With the first version of DEPEND, emerge succeed:
>> # emerge -pv app-misc/dummy-master
>>
>> These are the packages that would be merged, in order:
>>
>> Calculat
On 6/16/20 9:31 PM, Zac Medico wrote:
> On 6/16/20 11:07 PM, Michael Lienhardt wrote:
>> I'm sorry, my client didn't allow to send plain text email anymore...
>>
>> So, here is my original email.
>>
>> Dear all,
>>
>> My bad for not noticing i
ild
has EAPI=6).
So it seems to me that this current behavior of emerge should be considered an
error, no? Or the PMS should be updated?
This is related to the tool I'm working on: should my tool allow this behavior,
or fail like it is currently doing (I guess the former)?
Best,
Michael
On 6/
can be put back
into an eclass, and its consumers updated one-at-a-time.
Bug: https://bugs.gentoo.org/489542
Bug: https://bugs.gentoo.org/637824
Signed-off-by: Michael Orlitzky
---
repoman/lib/repoman/modules/linechecks/deprecated/inherit.py | 1 +
1 file changed, 1 insertion(+)
diff --git
On 2020-06-14 16:30, a...@freemail.hu wrote:
>
> Suggested fix for: https://bugs.gentoo.org/show_bug.cgi?id=489542
> Bug 489542 - netsurf.eclass should not include EROOT in PREFIX
>
Well, I've applied this as well as some other fixes for the eclass, only
to find that the problem has been
On Tue, May 5, 2020 at 4:22 PM Peter Stuge wrote:
> Hi,
>
> I'm trying something out over here and I'm surprised to find that
> acct-group/* do not work with ROOT+SYSROOT != "/".
>
> Should I file yet another bug about this?
>
> I suppose the limitation is in user.eclass, but what about the 11
On 4/26/20 3:25 PM, Ulrich Mueller wrote:
>>>>>> On Sun, 26 Apr 2020, Michael Orlitzky wrote:
>
>> Fuel for the fire:
>
>> * https://www.nongnu.org/lzip/lzip_benchmark.html
>> * https://www.nongnu.org/lzip/xz_inadequate.html
>
> Yep. That's
On 4/26/20 12:55 PM, Matt Turner wrote:
> Bug: https://bugs.gentoo.org/715108
> Signed-off-by: Matt Turner
> ---
> Strawman patch. Bikeshed away.
>
Fuel for the fire:
* https://www.nongnu.org/lzip/lzip_benchmark.html
* https://www.nongnu.org/lzip/xz_inadequate.html
On 4/20/20 5:48 PM, Georg Rudoy wrote:
>
>> I've learned the hard way that it discourages you from doing all the
>> things that I just said high-quality software should do.
>
> Again, ranging from one-off pseudo-scripts that I had to come back to
> after a couple of years, to quite complicated
On 4/20/20 5:25 PM, Patrick McLean wrote:
>
> Please explain how we are actively making things worse for you? We
> are contributing useful packages to the tree, we are doing the work
> and we are doing it in the way that makes the most effective use of
> our time. We simply do not have time to be
On 4/20/20 5:05 PM, Georg Rudoy wrote:
>
>> If upstream absolutely insists on minor-version dependencies, then you
>> either tolerate it conflicting with everything else, or leave it out of
>> the tree. You probably shouldn't even be packaging a library whose API
>> is distinguishable across
On 4/20/20 4:19 PM, Patrick McLean wrote:
>
> My co-workers are not the only ones adding/maintaining go packages in the
> tree, please do not single out any groups, and let's all work to make Gentoo
> the best it can be.
>
Everyone else is just using the eclass that your coworkers defended
On 4/20/20 4:21 PM, Georg Rudoy wrote:
> вс, 19 апр. 2020 г. в 16:09, Michael Orlitzky :
>> But please quit looking to Go as an example of anything
>> anyone should be doing.
>
> On a somewhat related note, I'd like to take this chance to ask about
> packaging has
On 4/20/20 2:58 PM, Patrick McLean wrote:
>>
>> You keep saying that, but the fact that dev-go/* is filled with trash
>> that has your name on it prevents anyone else from doing a better job.
>>
> Ad-hominen attacks are unwarranted, please refrain from them. I challenge you
> to find *anything*
On 4/20/20 1:31 PM, Patrick McLean wrote:
>> Simply having things in ::gentoo does not affect anyone who does not
use them.
>
You keep saying that, but the fact that dev-go/* is filled with trash
that has your name on it prevents anyone else from doing a better job.
On Sat, Apr 18, 2020 at 11:15 AM David Michael wrote:
> The build system's rpm2tar command is executed during unpack, so it
> must be install in /.
>
> Signed-off-by: David Michael
> ---
>
> This patch fixes failures like this:
> >>> Unpacking source...
&g
On 4/19/20 3:41 PM, Samuel Bernardo wrote:
>>
>> EGO_SUM is not a legitimate approach to packaging. You have to create
>> packages for each package. I know, it sounds crazy when you say it.
>>
> I understand what you mean, but deem this dependencies as internal
> project dependencies where those
On 4/19/20 10:55 AM, Samuel Bernardo wrote:
>
> Taking into account the network sandbox requirement, sbt.eclass needs to
> download all dependencies with some approach like EGO_SUM implementation
> in go-module.eclass[1].
>
EGO_SUM is not a legitimate approach to packaging. You have to create
The build system's rpm2tar command is executed during unpack, so it
must be install in /.
Signed-off-by: David Michael
---
This patch fixes failures like this:
>>> Unpacking source...
>>> Unpacking urw-fonts-2.4-9.fc13.src.rpm to
/var/tmp/portage/media-fonts/ur
On Tue, Apr 14, 2020 at 10:32 PM Matt Turner wrote:
> At the same time, fix the dependency on sys-libs/libcap by moving it to
> RDEPEND, as dependencies in DEPEND/BDEPEND are not guaranteed to exist
> during pkg_postinst() when this eclass is intended to run.
The BDEPEND was added for
On 4/13/20 10:58 AM, Andreas Sturmlechner wrote:
> Going to be used by 10 packages.
>
> Description: "Send anonymized usage information to upstream so they can
> better
> understand our users"
>
These are all really generic words that might be used by other
(non-QT/KDE) packages to mean
On 4/13/20 4:55 AM, Sergei Trofimovich wrote:
> Single fresh test failure bug: https://bugs.gentoo.org/717258.
I took it, there are some known arch-specific test failures on the
upstream bug tracker that I'll try to temporarily patch out.
On 4/11/20 11:33 AM, Michał Górny wrote:
> Hi,
>
> Now that we have proper components for keywording and stabilization,
> the old keywords are redundant. Nevertheless, some people still set
> them. I would like to propose two solutions going forward. Either:
>
> 1. We kill both keywords, and
48)
using gcc-4.9.x that was never fully debugged. If the problems persist,
we can revisit that report, or just mask the flag.
Closes: https://bugs.gentoo.org/show_bug.cgi?id=715678
Package-Manager: Portage-2.3.89, Repoman-2.3.20
Signed-off-by: Michael Orlitzky
---
sci-libs/fflas-ffpack/Manifest
These two flags are already supported by cpuid2cpuflags, but so far no
package in ::gentoo uses them. The forthcoming sci-libs/fflas-ffpack
will use them, however, and -- given that they're CPU flags whose names
are fixed -- it seems most sensible to add them globally right away.
Bug:
Sending to the list because it adds two new global CPU flags, already
supported by cpuid2cpuflags but not listed in the profiles yet.
Michael Orlitzky (2):
profiles/desc/cpu_flags_x86.desc: add avx512dq and avx512vl.
sci-libs/fflas-ffpack: new package for finite-field linear algebra
On 4/1/20 4:03 PM, Samuel Bernardo wrote:
>
> Couldn't security issue in a Go library be solved with keyword mask and
> announce in portage?
If there's an ebuild for the library, then yeah, you've got the right
idea. But with the Go eclasses, there are no ebuilds for any of the
dependencies.
On 4/1/20 11:49 AM, Alec Warner wrote:
> Imagine a common dep (CommonFoo-x-y-z)
> has a security problem, so we must upgrade to CommonFoo-y-z. In the
> scenario where CommonFoo is a dynamically linked package we can
> recompile it once[4] and new consumers will just use the new dynamic
> shared
On 4/1/20 1:36 AM, Robin H. Johnson wrote:
> mjo: Can you please substantiate your claims?
>
> It would have been nice to have heard your concerns during February, any
> of one the three times that William and I posted the go-module.eclass
> EGO_SUM development work for review on this mailing
On 3/31/20 8:48 PM, Samuel Bernardo wrote:
>
> My question started with the network sandbox issue when we need to load
> external code dependencies. For example, a go project will download all
> dependencies from git repositories that will happen after src_unpack. In
> this case I need to add an
On 3/31/20 6:21 PM, Samuel Bernardo wrote:
>
> But after your explanation, I understand now that mirror types provides
> alias to use in ebuild SRC_URI, specially useful for the update task
> (awesome).
>
Beware: thirdpartymirrors doesn't really do anything useful for normal
ebuilds in
veloper
to add a "=" sign (simplicity is very important)? Or for another reason?
Many thanks!
Michael
On 3/29/20 1:35 PM, Hans de Graaff wrote:
> # Migrate to Rails 5.2.
And here I was, thinking I knew what the worst thing to happen in 2020
was going to be.
On Fri, Mar 27, 2020 at 4:49 PM James Le Cuirot wrote:
> On Fri, 27 Mar 2020 13:10:34 -0400
> David Michael wrote:
>
> > I'd like to be able to install qt5 packages in a sysroot for staging,
> > and this is an initial patch for it. The pkg-config variables migh
Signed-off-by: David Michael
---
Hi,
I'd like to be able to install qt5 packages in a sysroot for staging,
and this is an initial patch for it. The pkg-config variables might not
be required, but it seemed appropriate to pass the sysroot-configured
versions through the build. There are a few
detect all
implementation dependency breakage.
Again, there's something I probably don't see: why was slot operators chosen
(among other possibilities) as a mechanism to trigger recompilation?
I'm very grateful to you all for the time you take to read and answer my
questions.
Best,
Michael
On Fri, Mar 20, 2020 at 5:12 PM David Michael wrote:
> Signed-off-by: David Michael
> ---
>
> Changes since v1:
> * Drop the dependency altogether
>
> eclass/fixheadtails.eclass | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/eclas
dependency breakage?
You have far more experience than me on this, and it would be nice for me to
know what I'm up against.
Many thanks!
Michael
e on how to achieve
it?
Among these two solutions, I prefer the first one: we stay at the level of
package dependencies (and it looks simpler to implement).
However, it is maybe easier/better to use the second approach, I don't know.
Do you have some suggestions?
Thanks!
Michael
ays checks if it is used by
another package: this means that installed packages' dependencies are never
broken.
Many thanks!
Michael
Signed-off-by: David Michael
---
Changes since v1:
* Drop the dependency altogether
eclass/fixheadtails.eclass | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/eclass/fixheadtails.eclass b/eclass/fixheadtails.eclass
index c19d33924aa..475b182843a 100644
--- a/eclass
It executes sed at build time, so it should be installed in /.
Signed-off-by: David Michael
---
Hi,
Here is another simple dependency move to put a required program in the
correct ROOT so it can be executed during the build. It's basically the
same as 814ab1294edf3565fc02fe63d15d6fa7ca886429
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
Michael
---
Changes since v1:
* Inverted patterns so EAPI 7+ is the default.
eclass/fcaps.eclass | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/eclass/fcaps.eclass b/eclass/fcaps.eclass
index 467f955f5e9..2b6e5be4683 100644
--- a/eclass/fcaps.eclass
+++ b/eclass
The old autoconf-2.13 version requires options to be specified
before the file name argument, so packages with WANT_AUTOCONF="2.1"
would fail to build in a sysroot with the -l option at the end.
Closes: https://bugs.gentoo.org/710792
Signed-off-by: David Michael
---
eclass/autotools.
Michael
---
eclass/fcaps.eclass | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/eclass/fcaps.eclass b/eclass/fcaps.eclass
index 467f955f5e9..b0479f32456 100644
--- a/eclass/fcaps.eclass
+++ b/eclass/fcaps.eclass
@@ -1,4 +1,4 @@
-# Copyright 1999-2015 Gentoo Foundation
On 3/12/20 11:23 AM, Alexis Ballier wrote:
> On Thu, 2020-03-12 at 09:06 +0100, ha...@gentoo.org wrote:
>> As this native Win32 support is considered highly experimental still,
>> I
>> would like to apply the libtool patches for parity via elibtoolize
>> only,
>> without applying them in
On 3/12/20 9:48 PM, James Le Cuirot wrote:
> On Thu, 12 Mar 2020 09:06:26 +0100
> ha...@gentoo.org wrote:
>
>> From: Michael Haubenwallner
>>
>> Signed-off-by: Michael Haubenwallner
>> ---
>> eltpatch.in | 14 +-
>> 1 file changed, 13
On 21/02/20 05:29, Matt Turner wrote:
> I found the original code to be nearly incomprehensible. Instead of
> populating a dict of potential binpkgs to remove and then removing from
> the to-be-removed list, just selectively add to-be-removed packages.
>
> Signed-off-by: Matt Turner
> ---
> I
On Wed, Feb 19, 2020 at 3:00 PM Mike Gilbert wrote:
> On Wed, Feb 19, 2020 at 3:41 PM Michael Jones wrote:
> >
> > How does this effect systemd's socket activation?
> >
> > E.g. The systemd sshd.socket unit file.
>
> Please avoid top-posting.
>
> Whe
How does this effect systemd's socket activation?
E.g. The systemd sshd.socket unit file.
On Wed, Feb 19, 2020 at 2:12 PM Mike Gilbert wrote:
> On Wed, Feb 19, 2020 at 3:02 PM Patrick McLean
> wrote:
> >
> > Title: OpenSSH 8.2_p1 running sshd breakage
> > Author: Patrick McLean
> > Posted:
On 18/02/20 19:52, Ulrich Mueller wrote:
> The devmanual says about live ebuilds:
>
> | CVS ebuilds must be either with empty KEYWORDS or package.masked
> | (but not both). Empty KEYWORDS are strongly preferred. This applies
> | to "live" ebuilds (-) and to ebuilds that extract a static
> |
On 18/02/20 13:02, hero...@gentoo.org wrote:
> From: Benda Xu
>
> Gentoo Prefix runs with a normal user and cannot manage any other user.
> Exit gracefully with a message.
>
> Closes: https://bugs.gentoo.org/709570
> Signed-off-by: Benda Xu
> ---
> eclass/acct-user.eclass | 10 ++
>
On 14/02/20 19:48, Vadim A. Misbakh-Soloviov wrote:
>> And now you're changing the subject. You've just claimed that *your*
>> user's group ownership will be overwritten and when challenged you
>> present the case of *system* user's group ownership being overwritten.
> Actually, he showed the
On 13/02/20 16:17, Mike Gilbert wrote:
> On Wed, Feb 12, 2020 at 8:32 PM Thomas Deutschmann wrote:
>> In short: It was a very bad decision that acct-* stuff is *changing*
>> existing stuff. This must be turned of *by default*. Maybe provide a
>> setting a user can put into make.conf to opt into
On 09/02/20 21:16, Michael 'veremitz' Everitt wrote:
> On 09/02/20 20:59, Michael 'veremitz' Everitt wrote:
>> On 09/02/20 20:57, Michael 'veremitz' Everitt wrote:
>>> On 09/02/20 20:55, Michał Górny wrote:
>>>> On Sun, 2020-02-09 at 20:38 +, Michael 'veremitz' Ev
On 09/02/20 20:59, Michael 'veremitz' Everitt wrote:
> On 09/02/20 20:57, Michael 'veremitz' Everitt wrote:
>> On 09/02/20 20:55, Michał Górny wrote:
>>> On Sun, 2020-02-09 at 20:38 +, Michael 'veremitz' Everitt wrote:
>>>> Hrm, pardon my ignorance, but do 'we' r
On 09/02/20 20:57, Michael 'veremitz' Everitt wrote:
> On 09/02/20 20:55, Michał Górny wrote:
>> On Sun, 2020-02-09 at 20:38 +, Michael 'veremitz' Everitt wrote:
>>> Hrm, pardon my ignorance, but do 'we' really need to review 232 lines of
>>> Manifest?!
>> Pa
On 09/02/20 20:55, Michał Górny wrote:
> On Sun, 2020-02-09 at 20:38 +0000, Michael 'veremitz' Everitt wrote:
>> Hrm, pardon my ignorance, but do 'we' really need to review 232 lines of
>> Manifest?!
> Pardon mine but do 'we' really need to read your useless comments
> eve
On 09/02/20 20:47, Robin H. Johnson wrote:
> On Sun, Feb 09, 2020 at 08:38:23PM +0000, Michael 'veremitz' Everitt wrote:
>> On 09/02/20 20:31, Robin H. Johnson wrote:
> ...
>> Hrm, pardon my ignorance, but do 'we' really need to review 232 lines of
>> Manifest?!
> No,
On 09/02/20 20:31, Robin H. Johnson wrote:
> Signed-off-by: Robin H. Johnson
> ---
> app-admin/kube-bench/Manifest | 232 ++
> .../kube-bench/kube-bench-0.2.3-r1.ebuild | 120 +
> 2 files changed, 352 insertions(+)
> create mode 100644
On 07/02/20 20:39, Matt Turner wrote:
> On Fri, Feb 7, 2020 at 12:03 PM Michael 'veremitz' Everitt
> wrote:
>> On 07/02/20 19:50, Matt Turner wrote:
>>> On Fri, Feb 7, 2020 at 11:39 AM Ulrich Mueller wrote:
>>>>>>>>> On Fri, 07 Feb 2020, Matt Tu
On 07/02/20 19:50, Matt Turner wrote:
> On Fri, Feb 7, 2020 at 11:39 AM Ulrich Mueller wrote:
>>> On Fri, 07 Feb 2020, Matt Turner wrote:
>>> On Fri, Feb 7, 2020 at 9:10 AM Mike Pagano wrote:
# Mike Pagano (2020-02-07)
# The standalone ebuild for this driver is made
#
On 03/02/20 12:19, Benda Xu wrote:
> Hi Gerion,
>
> Gerion Entrup writes:
>
>>> Yes, that makes a lot of sense. The R overlay follows this model. Most
>>> of the ebuilds are automated. When an ebuild generation fails, we add
>>> the ebuild manually, understand it and then update the generator
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 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
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
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
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.
>
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
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 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
201 - 300 of 2333 matches
Mail list logo
