ps://bugs.gentoo.org/635720
Signed-off-by: Michael Orlitzky
---
profiles/base/make.defaults | 5 -
profiles/default/linux/make.defaults | 5 -
profiles/features/hardened/make.defaults | 1 -
3 files changed, 11 deletions(-)
diff --git a/profiles/base/make.defaults b/profile
On 10/01/2018 11:19 AM, Zac Medico wrote:
>
> The first bug report [2] is for qt-core, which installs documentation
> into /usr/share/doc/${PN}-${PV} instead of /usr/share/doc/${PF}
It would be helpful to know why qtcore installs into the wrong directory
in the first place.
If ${PF} really caus
On 10/03/2018 12:38 PM, Zac Medico wrote:
>
> Until this QA check has adjustable whitelist support, we can consider it
> an unstable work in progress.
Has anyone said why these things need to be in ${PN}-${PV} rather than
${PF}?
If they don't need to be in ${PN}-${PV} in the first place, then th
Pushed.
On 10/13/2018 02:32 PM, Mikle Kolyada wrote:
>
> Quizzes are irrelevant, a person does the quizzes when he/she is
> ready to be the dev, doing quizzes for quizzes or quizzes to become a
> developer is the best way to get rejected by the recruiters team.
I thought this was kind of a strange thing
On 10/20/2018 04:05 AM, Mikle Kolyada wrote:
>
> ...
>
Ok, thanks for clarifying. I wanted to be sure that I wasn't getting
anyone into trouble by suggesting that they look into the quizzes (if
they are really willing to put in the effort).
On 10/26/2018 04:40 AM, Michal Prívozník wrote:
>
> So the desired way is to use github pull requests? That is rather
> unfortunate.
In this case there's no "project" associated with libvirt-snmp; but if
there were, it would have a @gentoo.org alias that you
could send patches to. Bugzilla is st
On 11/01/2018 06:27 PM, Andrew Savchenko wrote:
>
> This eclass is small, so no harm here. But for larger eclasses
> (hello java-*.eclass) this will hinder updates considerably. I
> prefer to fix something rather than to fix nothing while
> frustrating in attempt to fix everything at once.
>
> Al
On 11/08/2018 09:44 AM, Ralph Seichter wrote:
> Three weeks ago I sent the message shown below to the Gentoo Net-Mail
> team. Since I did not receive a reply, I am now asking on this mailing
> list: What can I do to have the pull request, which I opened six weeks
> ago, taken care of?
It's an open
On 11/08/2018 03:36 PM, Ralph Seichter wrote:
> * Michael Orlitzky:
>
>> It's an open secret that packages maintained by
>> category-n...@gentoo.org are in reality unmaintained; or are
>> maintained by one guy (who may or may not be on the alias).
>
> As some
On 11/12/2018 03:33 PM, Zac Medico wrote:
>
> QA_INSTALL_PATHS=( /nix )
>
That really, really, really doesn't belong there.
On 11/12/2018 04:06 PM, Zac Medico wrote:
> On 11/12/18 12:57 PM, Michael Orlitzky wrote:
>> On 11/12/2018 03:33 PM, Zac Medico wrote:
>>>
>>> QA_INSTALL_PATHS=( /nix )
>>
>> That really, really, really doesn't belong there.
>
> I'm open t
On 11/12/2018 06:47 PM, Zac Medico wrote:
>>
>> The idea being, to put it in the right place by default, and let people
>> override it with EXTRA_ECONF if they really want to download random
>> binaries from strangers and run them.
>
> I recommend to add /nix to the whitelist because this is the d
On 11/13/2018 01:21 AM, Zac Medico wrote:
>
> What's inherently wrong about nix having a file store under /nix? Is
> this purely about FHS?
>
It goes against not only the FHS, but against our existing policies and
common sense. There's no reason to expect that path to even be writable.
And nix s
On 12/8/18 1:27 PM, Ralph Seichter wrote:
I am trying to add NodeJS support to www-servers/nginx-unit, but the
upstream build relies on a working network connection to download
dependencies and execute "npm install ..." during the build process.
How can this scenario be handled properly in an eb
On 2/19/19 10:23 PM, Matthew Thode wrote:
> As the title says, I think this should be done.
>
> First sync is impossible to verify without keys (webrsync)
> app-crypt/gentoo-keys has no dependencies, which help avoid some bloat
> in the base install.
>
> Let the bikeshedding begin.
>
I don't ha
On 2/19/19 11:21 PM, Matthew Thode wrote:
>>
>> What problem would this solve? (Is adding gentoo-keys to @system the
>> least bad way to solve it?)
>>
>
> It'd allow the stage tarballs (3,4) to use webrsync-gpg to verify
> portage tarballs. This is useful for the initial sync (as called out in
>
On 2/21/19 1:09 AM, Matt Turner wrote:
>
> 2)Suggestions welcome for solving https://bugs.gentoo.org/637898
> I have no ideas...
>
The eclass documentation script wants a fixed default value for
variables that are optional.
For XORG_MODULE, instead of a case statement,
if [[ -z ${X
On 3/2/19 7:05 PM, William Hubbs wrote:
>
> Is there a reason we still use run-parts and the
> /etc/cron.{hourly,daily,weekly,monthly} structure to run repeating cron jobs?
>
> From what I read in the chat earlier, it sounds like the modern crons
> might be able to handle this without that struct
On 3/2/19 7:44 PM, Rich Freeman wrote:
>>
>> Totally. We should replace run-parts with something much simpler and
>> more predictable. Then, if that doesn't work for you, all modern crons
>> can do the things that run-parts tries to do, but better.
>>
>
> I'm not sure I see the connection here. A
On 3/2/19 9:01 PM, Rich Freeman wrote:
>
> So, the problem with cron.d is that you're now using crontab syntax,
> and for compatibility you have to use the lowest common denominator
> which is vixie.
>
> That means your jobs are STILL running as root, so the only problem
> you had with run-parts
On 3/26/19 3:43 PM, Michał Górny wrote:
> On Tue, 2019-03-26 at 19:33 +, Aaron Bauman wrote:
>> commit: 2e32186bbee30a4a2e1c4f37c79c61897e53d8df
>> Author: Michael Mair-Keimberger gmail com>
>> AuthorDate: Tue Mar 26 19:28:48 2019 +
>> Commit: Aaron Bauman gentoo org>
>> Com
On 3/26/19 4:32 PM, Aaron Bauman wrote:
> On Tue, Mar 26, 2019 at 09:10:28PM +0100, Ralph Seichter wrote:
>> * Michał Górny:
>>
>>> mail-filter/opendkim
>>
>> I can take OpenDKIM if no former team member wants to.
>>
>
> Please have a look at bug #629914 as well. Let me know if you submit a
> pul
On 3/26/19 5:09 PM, Ralph Seichter wrote:
> * Michael Orlitzky:
>
>> I'd be happy to work on all of that stuff either before or after you
>> guys take over and get settled in.
>
> I'd appreciate you adding all improvements you already have in store.
> It w
On 3/27/19 3:19 PM, Matt Turner wrote:
>>
>> You got it: I just pushed 17 commits, addressing ~5 open bugs. I've
>> added you, klondike, proxy-maint, and myself as maintainers.
>
> Nice. I'm curious: what were you waiting on before?
>
It was pretend-maintained by net-mail, and I wasn't a member
We have two eclasses with almost-identical functions for handling
tmpfiles.d entries:
1. systemd.eclass
a. systemd_dotmpfilesd
b. systemd_newtmpfilesd
c. systemd_tmpfiles_create
2. tmpfiles.eclass
a. dotmpfiles
b. newtmpfiles
c. tmpfiles_process
The do/new fun
On 4/23/19 6:25 PM, Zac Medico wrote:
>
> Note that systemd.eclass is lighter on dependencies, which is why I
> chose it for the solution to bug 490676 [1] and bug 643386 [2] in the
> sys-apps/portage ebuilds.
>
> [1] https://bugs.gentoo.org/490676
> [2] https://bugs.gentoo.org/643386
>
I think
On 4/24/19 8:24 AM, Michał Górny wrote:
>>
>> which will still work (albeit with a warning) if you somehow manage not
>> to have virtual/tmpfiles installed. So, if it's important, I think we
>> could drop the RDEPEND="virtual/tmpfiles" from tmpfiles.eclass.
>
> Programs depend on tmpfiles being ac
On 4/24/19 8:53 AM, Michał Górny wrote:
>
> systemd.eclass has more than one purpose, and therefore such dep didn't
> belong there (ebuilds should take care of the dependencies when using
> tmpfiles logic from it). tmpfiles.eclass on the other hand has a single
> purpose, so we've solved the prob
On 4/25/19 4:20 PM, Michał Górny wrote:
>
> Wrong. tmpfiles_process() requires virtual/tmpfiles on any system,
> including daemontools, bare minimal init and whatever. Keeping it
> installed afterwards is a minor side effect, and technical limitation of
> our dependency types (lack of install-de
On 4/25/19 5:23 PM, Michał Górny wrote:
>>
>> What's wrong? You only need the effect of tmpfiles_process() if you're
>> running systemd or OpenRC. If the user is running SysV-init and if the
>> package also installs a SysV-init script, then that init script is going
>> to have to create any tempora
On 4/26/19 12:53 AM, Michał Górny wrote:
>>
>> And the only reason we would need a transient directory created and/or
>> cleaned-up is because one of those service managers is going to start a
>> program that needs it. Two of them can use the tmpfiles mechanism, but
>> the others must handle it on
On 4/26/19 7:07 AM, Michael Orlitzky wrote:
> Thus it should have its own RDEPEND on virtual/tmpfiles, making the
> one in the eclass redundant.
Correction, it should RDEPEND on either systemd or OpenRC. Having the
"tmpfiles" binary installed is not enough; it needs to be run e
On 4/26/19 12:53 AM, Michał Górny wrote:
>
> No. tmpfiles is also used for programs started directly by user, such
> as eix.
>
This configuration is buggy to begin with: if I run eix-update as my
user, then the permissions on the files it creates under /var/cache/eix
are wrong (mjo:mjo, mode 66
On 4/26/19 9:07 AM, Michał Górny wrote:
>
>> I don't think so -- not if it needs that tmpfiles
>> entry to be processed every reboot. Thus it should have its own RDEPEND
>> on virtual/tmpfiles, making the one in the eclass redundant.
>
> It doesn't need to be processed every reboot. It needs to
On 4/26/19 9:32 AM, Michał Górny wrote:
>
> Whether it can be deleted is up to system's configuration. The current
> solution works for majority of cases, including a. people who use
> systemd or OpenRC, and set their systems to clean it up, and b. people
> who don't use either but don't clean it
On 4/26/19 10:54 AM, Michał Górny wrote:
In cases like that, adding RDEPEND=virtual/tmpfiles to the ebuild is a
better solution, because (a) the end result is exactly the same, (b) it
keeps the dependency out of the eclass, and (c) it localizes the
dependency to the place that needs it, namely t
On 5/29/19 4:01 AM, Ulrich Mueller wrote:
>
> I wonder why that would be needed. It won't catch collisions with users
> created by the system administrator.
The reference implementation did its best not to annoy you here.
Ultimately, no, it can't prevent the system administrator from
clobbering a
On 5/29/19 5:50 AM, Jaco Kroon wrote:
>>
>> This GLEP follows the best practice of leaving obsolete user/groups
>> accounts intact. This guarantees that no files with stale ownership are
>> left (e.g. on unmounted filesystems) and that the same UID/GID is not
>> reused for another user/group.
>
>
On 5/29/19 3:28 AM, Michał Górny wrote:
>
> Home directory ownership
>
>
> If the user in question uses a regular home directory (i.e. not
> ``/dev/null``), the user package should maintain the directory
> via ``keepdir`` command. This allows for clean removal of the hom
Should we require a mailing list review for new user/group packages?
It's difficult to modify a user once you've settled on a UID, home
directory, and shell; so it pays to get things right the first time.
The need is more apparent with fixed UIDs: if a popular package "steals"
a UID that some oth
On 6/5/19 5:12 AM, Michał Górny wrote:
> +
> + # check for ACCT_USER_ID collisions early
> + if [[ -n ${ACCT_USER_ENFORCE_ID} ]]; then
> + local pwd=$(egetent passwd "${ACCT_USER_ID}")
> + if [[ -n ${pwd} ]]; then
> + eerror "The required UID is a
On 6/9/19 7:28 AM, Michał Górny wrote:
> _assert_pkg_ebuild_phase() {
> case ${EBUILD_PHASE} in
> - setup|preinst|postinst) ;;
> + setup|preinst|postinst|prerm|postrm) ;;
> *)
> eerror "'$1()' called from '${EBUILD_PHASE}' phase which is not
> OK:"
>
On 6/9/19 7:28 AM, Michał Górny wrote:
>
> +# @FUNCTION: egetusername
> +# @USAGE:
> +# @DESCRIPTION:
> +# Gets the username for given UID.
> +egetusername() {
> + local pos
> +
> + [[ $# -eq 1 ]] || die "usage: egetusername "
> +
> + egetent passwd "$1" | cut -d: -f1
> +}
Unused lo
On 6/6/19 1:06 AM, Andreas K. Huettel wrote:
> Hi all,
>
> for the package maintainers among you, here's the list of remaining EAPI=2
> packages. Please help getting the number down to zero soon!!!
>
> ...
> net-analyzer/nagtrap-0.1.3
Last release in 2008, no maintainer, dead homepage, dead S
On 6/11/19 12:23 PM, Michał Górny wrote:
>
> +# @FUNCTION: user_get_nologin
> +# @INTERNAL
> +# @DESCRIPTION:
> +# Find an appropriate 'nologin' shell for the platform, and output
> +# its path.
> +user_get_nologin() {
This isn't a great name for this function, because it doesn't have
anything t
On 6/11/19 12:23 PM, Michał Górny wrote:
> +++ b/net-ftp/ftpbase/ftpbase-0.01-r3.ebuild
> @@ -0,0 +1,39 @@
> +# Copyright 1999-2019 Gentoo Authors
> +# Distributed under the terms of the GNU General Public License v2
> +
> +EAPI=7
> +
> +inherit eutils pam user
> +
user.eclass can go, and I'm pret
On 6/9/19 7:39 AM, Michał Górny wrote:
>
> +
> +All new users and groups must have unique UIDs/GIDs assigned
> +by developers. The developer adding them is responsible for checking
> +for collisions.
>
> ...
>
> +All user and group packages must define preferred fixed UIDs/GIDs,
> +and they mus
On 6/13/19 4:54 AM, Alexey Shvetsov wrote:
> Hi!
>
> Its a good thing that you're reviewing user class. I write some thought
> previosly about it.
>
> Why not create some set for standart uid:gid for services so they will
> be identicall in all installations?
>
> like slurm has uid:gid 500:500
On 6/13/19 1:33 AM, Michał Górny wrote:
>>
>>> + eshell=$(user_get_nologin)
>>
>> Then this would have to become
>>
>> eshell=$(userland_get_nologin "${USERLAND}")
>
> Do you have any real use for that?
>
No. It's a better design IMO since you can e.g. test the function by
passing it
On 6/20/19 9:53 AM, Brian Evans wrote:
>> +
>> +Following the acceptance of this GLEP, all new users and groups must
>> +be created via user/group packages as defined in this GLEP. The old
>> +method may still be used for existing users/groups, in existing
>> +packages.
>> +
>> +All new users and
On 6/26/19 6:35 AM, Marek Szuba wrote:
> Here is the RFC for acct-* packages corresponding to users and groups
> created by packages I currently maintain. This is also a request to
> reserve the respective UIDs/GIDs, namely:
>
> Groups:
> - burp - 501
> - rtkit - 133
And syncthing GID 502.
On 7/10/19 7:16 PM, William Hubbs wrote:
> 3. add a sysvinit use flag to openrc, which will be off by default. When
> it is on, openrc will block sysvinit since it will provide /sbin/init
> and /sbin/shutdown.
>
This logic, or maybe the name of the flag, sounds backwards to me. I
only get sysvini
On 7/10/19 8:03 PM, William Hubbs wrote:
>>
>> This logic, or maybe the name of the flag, sounds backwards to me. I
>> only get sysvinit when USE=sysvinit is NOT set?
>
> If you don't set sys-apps/openrc[sysvinit], you would have /sbin/init
> and /sbin/shutdown as they are now, from sys-apps/sysvi
On 7/10/19 11:14 PM, William Hubbs wrote:
>
> I don't want to remove sysvinit by default. If you want to remove it,
> you can, but I don't want to force that issue. That's why I don't want
> to turn the use flag on by default like systemd does.
>
After re-reading the bug report and sleeping on t
On 7/11/19 11:43 AM, William Hubbs wrote:
>>
>> then by default, OpenRC will pull in sys-apps/sysvinit, and use its
>> implementations of init/shutdown. Then later if someone wants to get rid
>> of sys-apps/sysvinit, he has the option to uninstall sys-apps/sysvinit
>> and then re-emerge OpenRC with
On 7/14/19 7:50 PM, Mike Gilbert wrote:
>
> +# Mike Gilbert (2019-07-14)
> +# Enable split-usr by default to keep systems working.
> +USE="${USE} split-usr"
A mandatory USE="keep-working" raises some philosophical red flags for
me. Wouldn't it be better to name the flag "merge-usr" and leave th
On 7/14/19 10:02 PM, Andreas K. Huettel wrote:
> Am Montag, 15. Juli 2019, 03:49:00 CEST schrieb Michael Orlitzky:
>> (This will be especially bad for the people who start
>> with USE="-*")
>
> Not recommended, not supported. Garbage in, garbage out.
>
Nothing In, Garbage Out.
On 7/14/19 9:56 PM, William Hubbs wrote:
>
> The ultimate goal is to turn this flag off in the 19.0 profiles, we are
> just preserving the current status in the earlier ones.
>
So, to be clear: the plan is to force a /usr merge after all?
On 7/15/19 10:45 AM, Jaco Kroon wrote:
> I have no idea who wrote this:
>
> "The historical justification for a /bin, /sbin and /lib separate from
> /usr no longer applies today." but I strongly disagree.
All of that stuff is written from the perspective of "I feel like doing
it this way in syste
On 7/15/19 11:22 AM, Mike Gilbert wrote:
>
> The "split-usr" flag is already being used by a few packages, so I
> would like to keep it.
The merits of the usr-merge notwithstanding, this does make more sense
if the plan is to eventually drop the flag entirely.
>> (This will be especially bad f
On 7/15/19 11:37 AM, William Hubbs wrote:
>
> https://www.osnews.com/story/25556/understanding-the-bin-sbin-usrbin-usrsbin-split/
>
> In particular, note Rob Landley's response linked in that story.
>
> So, this has nothing to do with systemd at all, please stop conflating
> it.
>
That wiki pa
On 8/2/19 5:53 AM, Michał Górny wrote:
>
> Sure. Please preferably address two of them separately, so we can
> commit the 0 patch first, and -1 when CI is ready.
>
Maybe I'm just feeling cynical, but what do we gain by adding support
for something that no real package should do? Is it just to av
On 8/2/19 11:58 AM, Michał Górny wrote:
>
> Given that overlays won't do proper assignment, the numbers they choose
> may collide with numbers used in ::gentoo. Forcing explicit assignment
> from dynamic range is cleaner in that regard.
>
I think it would be cleanest to leave the hacks in the o
On 8/3/19 2:43 PM, Ralph Seichter wrote:
> +
> +EAPI=7
> +
> +inherit acct-user
> +
> +ACCT_USER_ID=333
> +ACCT_USER_GROUPS=( amavis )
> +DESCRIPTION="User for mail-filter/amavisd-new"
> +
> +acct-user_add_deps
The existing user created by the amavisd-new ebuilds has a home
directory of /var/amavi
On 8/4/19 2:07 PM, Conrad Kostecki wrote:
> +
> +ACCT_USER_GROUPS=( "minecraft" )
> +ACCT_USER_HOME="/var/lib/minecraft-server"
> +ACCT_USER_HOME_OWNER="minecraft:minecraft"
You don't have to set ACCT_USER_HOME_OWNER here. That ownership is the
common case, so the eclass will do the right thing fo
On 8/4/19 2:02 PM, Conrad Kostecki wrote:
> +
> +ACCT_USER_GROUPS=( "fhem" )
> +ACCT_USER_HOME="/opt/fhem"
> +ACCT_USER_HOME_OWNER="fhem:fhem"
Same comment for the rest of these.
On 8/3/19 7:49 PM, Michael Orlitzky wrote:
>
> That makes me think that we should set
>
> ACCT_USER_HOME=/var/lib/amavis
>
We'll do this during the next version/revision bump, keeping everything
else the same.
On 8/7/19 11:30 AM, Hasan ÇALIŞIR wrote:
> +ACCT_USER_ID=495
> +ACCT_USER_HOME=/var/lib/gvm
> +ACCT_USER_HOME_OWNER=gvm:gvm
> +ACCT_USER_GROUPS=( gvm )
The HOME_OWNER is redundant, that's the eclass default.
On 8/7/19 1:10 PM, Michał Górny wrote:
>
> Using '999' was also suggested (as the first dynamic
> UID/GID) but it would cause issues for people enabling
> ACCT_*_ENFORCE_ID. To avoid this, '-1' does not trigger collision
> checks.
>
Feel free to proceed with this, I'm just curious: what's the p
On 8/8/19 3:37 AM, Tomas Mozes wrote:
>
> Pending PR:
> https://github.com/gentoo/gentoo/pull/12375
>
Is the group-writability really needed here?
> ACCT_USER_HOME_PERMS=0770
I don't think the existing ebuilds change the permissions on that
directory. In any case,
> keepdir "/var/lib/${MY_PN
On 8/9/19 5:59 PM, Alexey I. Korepanov wrote:
> Hi!
>
> I need a UID/GID for i2pd. I used 170 in
> https://github.com/gentoo/gentoo/pull/12509
> I did not find any conflict.
>
>
You deleted your entire pkg_preinst phase, but you probably only wanted
to delete the enewuser and enewgroup calls.
On 8/9/19 6:42 PM, Alexey I. Korepanov wrote:
> I wanted also to remove write access for i2pd group for config files in
> /etc, thus extra removal. I wrote about it in the pr.
>
Ah, sorry, I only read the commit and not the PR conversation. Is the
group still used for anything?
On 8/10/19 4:27 AM, Alexey I. Korepanov wrote:
> The process runs as i2pd:i2pd. The group is not used for anything specific.
I think I confused myself. The user does need a primary group, in any
case. Everything's fine, carry on.
On 8/9/19 3:26 PM, Rolf Eike Beer wrote:
>
> + use ssl && epatch "${FILESDIR}"/qmail-smtputf8.patch
EAI doesn't require SSL as far as I know. Is this conditional on the USE
flag only because the patch won't apply otherwise? (If so, it may be
worth a comment to that effect.)
On 8/12/19 6:28 PM, Ulrich Mueller wrote:
>
> I didn't understand that argument in 2011, and I understand it even
> less in 2019. Why would we add xz but not bzip2 and tar as dependencies?
>
> The devmanual is clear on this:
> https://devmanual.gentoo.org/general-concepts/dependencies/index.html#
On 8/13/19 1:14 PM, Lars Wendler wrote:
> I would like to reserve UID/GID 81 for apache (www-servers/apache).
>
> This is the historical UID/GID for apache user in Gentoo.
> Fedora and RedHat use UID/GID 48. Arch Linux has no
> "apache" user but a "http" user with UID/GID 33 (which is already
> re
On 8/13/19 1:53 PM, Lars Wendler wrote:
>
> thanks for the review. I've force-pushed the acct-user/apache commit
> with ACCT_USER_HOME_OWNER being set to root:root.
>
Is there any benefit to
ACCT_USER_HOME=/var/www
ACCT_USER_HOME_OWNER=root:root
versus
keepdir /var/www
in the eclass?
On 8/13/19 2:30 PM, Lars Wendler wrote:
>
> If we leave ACCT_USER_HOME empty HOME will be set to
> /dev/null for apache user. I don't know if this is what we want.
I'm not 100% sure either, but it's pretty likely that if an unwritable
root-owned home directory would work, then so would /dev/null.
On 8/13/19 3:15 PM, Lars Wendler wrote:
>
> I'm not really sure what the impact might be. I have only one single
> apache installation and that is a productive one. I do not want to mess
> with that installation.
>
I'm not trying to hassle you, but now's the time to get it right. The
old enewuse
On 8/13/19 10:30 AM, Pierre-Olivier Mercier wrote:
>
> Pending PR: https://github.com/gentoo/gentoo/pull/12481
>
>
> DESCRIPTION="User for knot DNS server"
> ACCT_USER_ID=53
> ACCT_USER_HOME=/var/lib/knot
> ACCT_USER_HOME_OWNER=knot:knot
> ACCT_USER_GROUPS=( knot )
> ACCT_USER_SHELL=/bin/false
A
On 8/14/19 5:14 PM, Mike Gilbert wrote:
> Closes: https://bugs.gentoo.org/691478
> Signed-off-by: Mike Gilbert
> ---
> eclass/acct-user.eclass | 5 +
This is a symptom of another problem. The man user claims /usr/share/man
as its home directory, and insists on changing its permissions to
root
On 8/14/19 5:41 PM, Mike Gilbert wrote:
>
> (If the "man" user really reads things from e.g. $HOME/man5/ebuild.5,
> I'll eat my foot.)
>
>
> Agreed. Please file a bug about this.
>
We already have bug 691478 for this issue? Only it should have been
assigned to the failing package's pro
On 8/15/19 3:19 AM, Ulrich Mueller wrote:
>
> I don't think that's a sane situation, so maybe the eclass should just
> die here? (Basically, there are two possibilities: Either, things will
> break if the dir is missing, then dying might be the best option.
> Or, everything works without the dir,
On 8/7/19 5:24 AM, Eray Aslan wrote:
> I would like to reserve UID/GID 76 for dovecot (net-mail/dovecot)
>
> This id differs from what we have provided historically (97) but gid/97
> is used by acct-group/input. So use 76 instead.
>
> This id is the same in Arch (76) but differs from Redhat (97)
On 8/15/19 11:43 AM, Mike Gilbert wrote:
>
> + # Path might be missing due to INSTALL_MASK, etc.
> + # https://bugs.gentoo.org/691478
> + if [[ ! -e "${ED}/${ACCT_USER_HOME#/}" ]]; then
> + eerror "Home directory is missing from the installat
> On 8/3/19 7:49 PM, Michael Orlitzky wrote:
>>
>> That makes me think that we should set
>>
>> ACCT_USER_HOME=/var/lib/amavis
>
> We'll do this during the next version/revision bump, keeping everything
> else the same.
>
The recent homedir pr
Pending https://github.com/gentoo/devmanual.gentoo.org/pull/99, I'd like
to get something like this written down.
Please give it a quick read and see if it makes sense, or if I've
overlooked anything. Most of these would just be suggestions, to be
implemented as post-install QA checks or repoman w
On 8/17/19 4:54 AM, Michał Górny wrote:
> On Sat, 2019-08-17 at 10:52 +0200, Ulrich Mueller wrote:
>>
>> Shouldn't there be a blocker against dev-vcs/gitolite{,-gentoo}
>> (and vice versa)? These packages cannot be installed at the same time,
>> and I guess that a direct blocker would result in a f
On 8/17/19 2:36 AM, Eray Aslan wrote:
>
> For the record, it wasnt me who wrote those acct-user ebuilds.
Apologies, I checked the metadata and assumed that I missed these as
part of your patch series. In any case, I'm not trying to throw blame
around -- this is all new and we're still figuring it
On 8/17/19 12:29 AM, Haelwenn (lanodan) Monnier wrote:
>
> Any reason why sharing home directories isn't simply forbidden?
> This is sure to blow on us at some point if there is shared home directories.
>
> ...
>
> Shouldn't this be owned instead of writable? I'm pretty sure we can
> have case
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 f
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/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/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, exa
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/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 this
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.
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 an
501 - 600 of 919 matches
Mail list logo
