On 24/10/19 18:58, Azamat Hackimov wrote:
> Hello.
>
> As per https://github.com/gentoo/gentoo/pull/12807 I need UID/GID for
> web-application Redmine. Could I please get those for it? Any available
> number will OK.
>
> --
> From Siberia with Love!
Check https://api.gentoo.org/uid-gid.txt ..
> 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 10/10/19 03:57, Kent Fredric wrote:
> On Wed, 9 Oct 2019 19:45:34 -0700
> Zac Medico wrote:
>
>> I'd prefer to disable --autounmask by default and include warnings about
>> harmful behavior in the documentation.
> I think autounmasks behaviour with regards to USE flags is useful,
> (heh), its
On 10/10/19 03:57, Kent Fredric wrote:
> On Wed, 9 Oct 2019 19:45:34 -0700
> Zac Medico wrote:
>
>> I'd prefer to disable --autounmask by default and include warnings about
>> harmful behavior in the documentation.
> I think autounmasks behaviour with regards to USE flags is useful,
> (heh), its
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 10/8/19 7:21 AM, Andreas K. Huettel wrote:
In any case, since many people *do* rely on it, maybe we should declare it
official? [+]
And, if that's OK with both of you, move it onto infra hardware?
Happy to sponsor both for the next council meeting agenda.
[+] At some point the one
On 10/4/19 5:32 AM, Robin H. Johnson wrote:
On Wed, Oct 02, 2019 at 08:43:44AM -0700, Matt Turner wrote:
On Thu, Sep 26, 2019 at 12:29 AM Sergei Trofimovich wrote:
I noticed that stable-bot stopped marking bugs as verified for stbilization.
Example:
...
It looks like it is working now, but
Sorry for the late reply here.
On 10/3/19 1:43 AM, Matt Turner wrote:
On Thu, Sep 26, 2019 at 12:29 AM Sergei Trofimovich wrote:
I noticed that stable-bot stopped marking bugs as verified for stbilization.
Example:
https://bugs.gentoo.org/695252
1. Is it gone forever and arch teams
It looks like your GPG setup isn't quite working .. your key is attached,
but your messages don't appear to be being signed, if that was your
intention :) just a FYI!
On 28/09/19 21:13, waebbl wrote:
> Version 7 doesn't require parmgridgen. I has dependencies on scoth,
> paraview and cgal, all of
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
LGTM
On 9/6/19 9:06 PM, Ben Kohler wrote:
> Signed-off-by: Ben Kohler
> ---
> eclass/prefix.eclass | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/eclass/prefix.eclass b/eclass/prefix.eclass
> index 8ae3e3a531d..435e99fdf92 100644
> --- a/eclass/prefix.eclass
> +++
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 06/09/19 20:09, Kent Fredric wrote:
> On Fri, 6 Sep 2019 20:02:05 +0100
> Michael Everitt wrote:
>
>> so that the original source makes sense when reading it
>> without external tools ? Thoughts?
> The source still makes sense without external tools.
>
> You just
On 06/09/19 20:00, Georgy Yakovlev wrote:
> On Friday, September 6, 2019 11:52:53 AM PDT Michael Everitt wrote:
>> On 06/09/19 18:27, Ben Kohler wrote:
>>
>> This series seems super counter-intuitive to me .. surely all usage
>> examples (in Linux/etc in general)
On 06/09/19 18:27, Ben Kohler wrote:
> Signed-off-by: Ben Kohler
> ---
> eclass/tmpfiles.eclass | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/eclass/tmpfiles.eclass b/eclass/tmpfiles.eclass
> index 68478ffbcd6..360c5e3b816 100644
> --- a/eclass/tmpfiles.eclass
>
On 05/09/19 20:47, Michał Górny wrote:
> On Thu, 2019-09-05 at 15:14 +0200, Thomas Deutschmann wrote:
>> On 2019-09-05 06:02, Michał Górny wrote:
In my case I am working on a new mysql eclass to outsource pkg_config
function which is shared at least between dev-db/mysql and
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.
the rest
- start reading portage's bug tracker and continue reading its code
- extend pdepa with other kind of relevant analysis
All comments/suggestions are welcomed.
Best,
Michael
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
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
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
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
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
> 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 problem
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
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
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/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
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
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
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
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 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 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
>
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:
>
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/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 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/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/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
Closes: https://bugs.gentoo.org/690686
---
eclass/toolchain.eclass | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/eclass/toolchain.eclass b/eclass/toolchain.eclass
index 6bc04b4cbfe..40d46ed0707 100644
--- a/eclass/toolchain.eclass
+++ b/eclass/toolchain.eclass
@@ -687,9
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
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/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.
---
eclass/ssl-cert.eclass | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/eclass/ssl-cert.eclass b/eclass/ssl-cert.eclass
index b5b4250ef22..01783b75848 100644
--- a/eclass/ssl-cert.eclass
+++ b/eclass/ssl-cert.eclass
@@ -18,7 +18,7 @@ case "${EAPI:-0}" in
0)
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/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
On 8/4/19 10:36 PM, Hasan Calisir wrote:
Thank you.
FYI
https://wiki.gentoo.org/wiki/Project:Quality_Assurance/UID_GID_Assignment
439 ldap fixed id used in old packages
450 firebird fixed id used in old packages
495 gvm assignment requested
*496 strelaysrv acct-group/strelaysrv*
497
On 8/4/19 8:00 PM, Hasan ÇALIŞIR wrote:
I have a request waiting for "gvm" user on ID 495 ??
https://github.com/gentoo/gentoo/pull/12609
I have updated my local branch to use 496 instead.
Package-Manager: Portage-2.3.69, Repoman-2.3.16
Signed-off-by: Michael Palimaka
---
acct-user/unrealircd/metadata.xml| 7 +++
acct-user/unrealircd/unrealircd-0.ebuild | 11 +++
2 files changed, 18 insertions(+)
create mode 100644 acct-user/unrealircd/metadata.xml
create
Package-Manager: Portage-2.3.69, Repoman-2.3.16
Signed-off-by: Michael Palimaka
---
acct-group/unrealircd/metadata.xml| 7 +++
acct-group/unrealircd/unrealircd-0.ebuild | 8
2 files changed, 15 insertions(+)
create mode 100644 acct-group/unrealircd/metadata.xml
create mode
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
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
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
On 7/15/19 2:45 PM, Michael Palimaka wrote:
> On 7/12/19 3:14 AM, hero...@gentoo.org wrote:
>> From: Benda Xu
>>
>> Prefix/standalone does not need it.
>> ---
>> eclass/cmake-utils.eclass | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
On 7/25/19 4:29 PM, Michał Górny wrote:
>>
>> * In the md5-cache entry, maybe use a common prefix like EXT_ for the
>> extra keys in order to distinguish them from normal keys.
>
> Yeah, I was thinking of something like '__ext_foo', or '__ext[foo]'.
>
What are the pros/cons of this? The names
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
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
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
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/12/19 3:14 AM, hero...@gentoo.org wrote:
From: Benda Xu
Prefix/standalone does not need it.
---
eclass/cmake-utils.eclass | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/eclass/cmake-utils.eclass b/eclass/cmake-utils.eclass
index ea1858e9735f..109b584afb39 100644
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 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
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
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
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
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
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.
version REQUIRED_USE="^^ ( consolekit, elogind systemd )"
In practice however, this was not a problem, as some dependencies of polkit
deep in the tree did require one of ( systemd consolekit ) to be set.
If you want, I can implement a test that check if this optimization is a
problem in practice.
Checking the issue shouldn't be too difficult (I think I just need to check
that all REQUIRED_USE and *DEPEND are equivalent for a SLOT).
Best,
Michael
such that
the latest corresponding cpv could be installed, while the previous version
could be).
Is it really the default behavior of emerge, and if yes, is there a way to make
emerge consider all matching cpv for an atom?
Thank you!
Michael
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/13/19 2:45 PM, James Le Cuirot wrote:
> On Thu, 13 Jun 2019 13:08:15 +0200
> Michael Haubenwallner wrote:
>
>> EAUTORECONF_DEPENDS is non-empty for ppc-aix and x86-winnt only.
>> Also, unset variable 'arch' after use.
>> ---
>> eclass/xorg-3.eclass | 3 ++-
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
401 - 500 of 2333 matches
Mail list logo
