On 01/24/2017 11:11 AM, Mart Raudsepp wrote:
>
> Currently this seems to be resulting in broken deptrees for arches that
> don't have a stable profile. arm64 in particular.
ALLARCHES should not include the unstable ones unless they are
specifically in CC, and of course you should be running repom
On 01/26/2017 10:33 PM, Mike Gilbert wrote:
>
> Is there any reason to have these USE flags enabled globally?
They are quite uncritical.
> These USE seem pretty package-specific in scope. On my system, they
> are used by around a dozen of 1000+ installed packages. I think it
> might make sense
Forked from the gdbm/berkdb thread, wall of text ensues...
On 01/27/2017 03:32 AM, Fabian Groffen wrote:
>
> You mention REQUIRED_USE should be used sparingly, I think I see your
> reasoning, but if so, then why did we add it in the first place?
There are a few conflicting interests at play. Bef
We approved GLEP 27 (https://wiki.gentoo.org/wiki/GLEP:27) in 2004 but
never implemented it. I'm wondering what are the explicit requirements
that we have for user and group management?
What I'm really wondering is, instead of the proposal in GLEP27, if we
couldn't simply handle users like any oth
On 01/27/2017 01:52 PM, Rich Freeman wrote:
>
> This doesn't really seem like a problem though. Just have a table
> somewhere (wiki?) to track who is using what UID/GID and encode those
> defaults into the ebuild that creates those users.
>
It should be possible to have two different users with
On 01/27/2017 02:53 PM, Rich Freeman wrote:
>
> I'm not saying we can't have random assignment for things where it
> doesn't matter, or fall back to random assignment, but it seems rather
> silly to go to all the trouble to have blockers when it would be just
> as easy to not have a conflict in th
On 01/27/2017 04:15 PM, Michał Górny wrote:
>
>> * users-update: cleanup can be done with --depclean now.
>
> Err, cleanup is never easy. You shouldn't really remove a user if it
> owns any files. I guess you could abuse pkg_prerm() for that but
> depclean will be terribly slow then.
>
What ar
On 01/27/2017 09:37 PM, Patrick McLean wrote:
>
> To make something to solve our problem (and I suspect everyone
> else who cares about this), it would be sufficient to have a mechanism
> to override the default random assignment with a fixed UID/GID.
What I had in mind for this is that a "normal
On 01/27/2017 11:21 PM, Rich Freeman wrote:
>
> It isn't like inconsistent UIDs are the end of the world. However,
> IMO it still makes sense to at least try to standardize such things.
> Really, if you have a package always installing the same user simply
> sticking a default UID without any eff
On 01/28/2017 09:22 PM, Rich Freeman wrote:
>>
>> Here's a problem I have no solution for. Suppose we tell everyone to
>> pick a fixed UID for their user packages. I have a randomly assigned
>> "tcpdump" user as UID 102 on my machine today. If we roll this out next
>> week and the tcpdump maintaine
On 01/28/2017 09:22 PM, Rich Freeman wrote:
>
> Honestly, I really will say "so what" here. :)
>
I forgot to mention a few of the advantages of having really-fixed UIDs.
First, it makes the code simpler. Yup, cool.
It also lets us play a nice trick and use the UID as a subslot, so that
if some
On 01/28/2017 10:23 PM, Gordon Pettey wrote:
>
> That's nonsense for reasons already mentioned by rich0. UIDs don't change
> except in the case of an admin doing it manually.
>
It shouldn't be common, but it can and will happen once you put users in
ebuilds. As an example, imagine an "echo" daem
On 01/29/2017 03:26 AM, Alan McKinnon wrote:
>>
>> Can anyone think of an upgrade path for fixed UIDs? That issue aside, I
>> may have convinced myself that fixed UIDs are better.
>
> The general process I would recommend is that if the ebuild finds the user
> already exists, leave it, it's UID an
On 01/29/2017 05:03 AM, Ulrich Mueller wrote:
>>>>>> On Sat, 28 Jan 2017, Michael Orlitzky wrote:
>
>> [...] sys-user/echo [...]
>
> [Replying to a random message in this thread, as I have some backlog.]
>
> Users and groups aren't packages, so IMHO p
On 01/27/2017 12:54 PM, Michael Orlitzky wrote:
> We approved GLEP 27 (https://wiki.gentoo.org/wiki/GLEP:27) in 2004 but
> never implemented it. I'm wondering what are the explicit requirements
> that we have for user and group management?
>
> What I'm really wondering is
On 01/29/2017 05:07 PM, Alan McKinnon wrote:
>
> Sure it can be done, just don't chown -R ~user. DO it the VERY
> long way round, file by file. Say you changed user "awesome" uid 300 to 400:
>
> find / -uid 300 -exec chown awesome {} \+
>
That will find symlinks created by UID 300, and chown w
On 01/29/2017 05:30 PM, Alan McKinnon wrote:
>
> Good catch with symlinks.
> I don't see the point about hardlinks, they are just files with 2
> dentries. When find gets to the second one it's already changed, so no
> problem.
>
Any user can create a hard link in its home directory to /etc/shado
On 01/29/2017 06:34 PM, Ulrich Mueller wrote:
>
> Our syntax for package names is more restrictive than what POSIX
> allows for a portable user name. Therefore, there could be user names
> that are not representable. Have you checked if all user and group
> names currently in use (at least in the
On 01/30/2017 09:25 AM, Alan McKinnon wrote:
>>
>> Any user can create a hard link in its home directory to /etc/shadow, so
>> long as (a) they live on the same filesystem, and (b) there are no
>> special kernel protections in place to prevent it. If you call chown on
>> that hard link, it will cha
On 01/30/2017 01:05 PM, Patrick McLean wrote:
>
> No, that is also enabled by default on vanilla kernels, I just verified
> on my machine running a vanilla kernel. It doesn't matter anyway, since
> the permissions and ownership information is stored in the inode, not
> the dentry so all hardlinks
On Fri, 2022-04-15 at 09:40 +0100, Sam James wrote:
> +
> + if grep -q "dev-libs/libltdl" <<<${RDEPEND}; then
> + # Nothing to do here
> + return
> + fi
We should probably have delimiters around that atom to future-proof it
against (say) dev-libs/libltdl2. W
On Fri, 2022-05-13 at 09:11 +0200, Ulrich Mueller wrote:
>
> So, should we join the "which hunt", with the goal of removing
> sys-apps/which from the system set and from stage1?
Yes, although I would suggest "command -v" as a POSIX replacement that
can be sent upstream. The "type" utility is also
On Fri, 2022-05-13 at 11:44 -0400, Mike Gilbert wrote:
>
> "which" is a built-in command in bash, but not in dash. For most
> users, /bin/sh points at bash and I don't expect to see much breakage
> when /usr/bin/which is removed. The bug reports will come from people
> who like pain and run their
On Sat, 2022-07-23 at 02:49 +0100, Sam James wrote:
> # Sam James (2022-07-22)
> # Monolithic mask for dev-haskell/* packages which have no reverse
> dependencies,
> # are broken, or severely out of date. The aim is to have the Haskell overlay
> # (::haskell) be the place for development packages
On 2022-07-23 23:23:38, Sam James wrote:
>
> The two people you refer to (solpeth and hololeap) both warmly
> welcomed this move and endorse it. It'd be great to have them as developers
> and I've offered to help mentor them, as have others.
Ok, awesome. Thank you both.
On Thu, 2022-08-18 at 20:18 +0100, Sam James wrote:
> Emacs 29's NEWS says: "The autoload.el library is now obsolete."
>
> ...
>
> ${EMACS} ${EMACSFLAGS} \
> + --eval "(require 'autoload)" \
> --eval "(setq make-backup-files nil)" \
> --eval "(setq g
On Sun, 2022-08-21 at 03:23 +0100, Sam James wrote:
> # hololeap (2022-08-21)
> # Monolithic mask for dev-haskell/* packages which have no reverse
> dependencies,
> # are broken, or severely out of date
> net-mail/list-remote-forwards
> net-mail/mailbox-count
> net-misc/haeredes
> net-misc/ha
On Sun, 2022-08-21 at 15:10 -0400, matoro wrote:
> Hey mjo, sorry about this - we were somewhat aggressive when building
> this list because much of the ecosystem has a tendency to do things like
> put strict upper bounds in their cabal files, leading to lots of
> blockers and manual patching wh
On Sun, 2022-10-09 at 22:25 +0100, Sam James wrote:
>
> * Some bugs simply need an `eautoreconf` because older
> autoconf-generated configure files had issues.
>
Vanilla autoconf still emits busted tests for e.g. AC_CHECK_FUNC, so
you'll want the ~arch autoconf with sam's backported patches in
On Sun, 2022-11-06 at 12:19 +0100, Florian Schmaus wrote:
>
> I guess there is no way we can avoid the --global and use --local instead?
>
The setting is only respected if it's in the global ($HOME) or system
(/etc) configs. There's no explanation for that in the man page, but
it's probably beca
On Wed, 2022-11-23 at 08:38 +0100, Michał Górny wrote:
> Hello, everyone.
>
> TL;DR: I'd like to add sys-meta/{cpio,sh,tar} to install and control
> (via USE flags) /bin/{cpio,sh,tar} symlinks.
>
> Draft PR: https://github.com/gentoo/gentoo/pull/28390
>
I generally favor using the package manag
On Wed, 2022-11-23 at 15:37 +0100, Michał Górny wrote:
>
>
> PMS doesn't say anything about (new-style) virtuals. It's a Gentoo
> policy entirely.
This is listed as a retroactive change,
Note: A ‘new-style virtual’ is a normal package that installs no
files and uses its dependency requir
On Wed, 2022-11-23 at 08:38 +0100, Michał Górny wrote:
>
> What are the advantages of proposed solution over eselect?
> ==
I think it's also worth mentioning the advantages over the usual
virtual approach, where we have a virtual pull in one
On Sat, 2022-12-03 at 02:59 +0100, Haelwenn (lanodan) Monnier wrote:
> [2022-12-02 05:11:15+] Andrey Grozin:
> > In principle, one can try a workaround: use some other lisp (say, clisp or
> > ecl) as the bootstrap lisp. This way is at best brittle: there is no
> > guarantee that these external
me is redundant for Gentoo developers. It's
often helpful to have it for other types (e.g. proxy) developers, but I
find it a bit pointless to copy/paste "Michael Orlitzky" into hundreds
of ebuilds when it can easily be deduced from "m...@gentoo.org."
On Fri, 2022-12-23 at 15:35 +0100, Michał Górny wrote:
> # Michał Górny (2022-12-23)
> # Packages that still use dev-python/nose and have no revdeps.
> #
> ...
> dev-python/python-redmine
I'm the (only) maintainer for this, and I didn't even know there was a
problem. I have at least filed an upst
On 2022-12-25 13:09:46, David Seifert wrote:
> Back when polynomial-c was retired, we forgot to send up for grabs for
> eclasses he maintained:
>
> apache-2.eclass
>
> is up for grabs, and is in general need of a revamp, it hasn't aged
> well.
If anyone is interested, I posted updates/replacem
On 2022-12-26 10:11:18, Hans de Graaff wrote:
>
> It would be great if you could dust these off and post them here so we
> can get these improvements merged. You mention in the bug that you'd
> rather wait for a dedicated maintainer to review them, but I'm (in
> name) that maintainer and I think y
On Mon, 2023-01-02 at 12:48 +, m1027 wrote:
> Hi and happy new year.
>
> When we create apps on Gentoo they become easily incompatible for
> older Gentoo systems in production where unattended remote world
> updates are risky. This is due to new glibc, openssl-3 etc.
>
Just update them. YOLO
On Wed, 2023-01-18 at 20:48 -0500, Joshua Kinard wrote:
>
> So is adding a default definition of TZ to our base system
> /etc/profile something we want to look at? I
> haven't tried any other methods of benchmarking to see if not making
> those additional syscalls is just placebo
> or if there
On Thu, 2023-01-19 at 13:25 +0200, Cedric Sodhi wrote:
>
> In this case, the expectation to compile manpages does not come free
> of cost and protects noone. By the above formulation, the cost
> "should" not come in the form of additional (heavy! dev-python/sphinx
> and deps are 75M) dependencies,
On Sun, 2023-04-30 at 16:30 +, Jorge Manuel B. S. Vicetto wrote:
>
> This is a friendly reminder that we're nearing (at the end of the day)
> the half-period for this election voting.
>
My options are "yes" and "no" but there's no indication of what I'm
saying yes/no to.
I'd wager that "ye
On Sun, 2023-06-04 at 13:31 -0400, Mike Gilbert wrote:
> This allows users to maintain the saved config file in some other
> location.
>
If so, the symlink should point to a superuser-only location to avoid
creating any new vulnerabilities. We can't fix the general problem, but
we could at least
On Sun, 2023-06-04 at 20:46 +0200, Arsen Arsenović wrote:
>
> I believe that the target directory of this cp can be considered
> equivalent in terms of access to any superuser-only directory, so I'm
> not sure I see the problem with this change.
It silently changes something that was safe (but st
On Sun, 2023-06-25 at 16:58 +0300, Joonas Niilola wrote:
> Hey,
>
> these packages are up for grabs:
>
Brian was the last member of the PHP project, so most of those packages
are now unmaintained too. I'm co-maintainer on a few of them but Brian
did most of the work.
On Fri, 2023-08-11 at 07:07 -0700, orbea wrote:
>
> Why does Gentoo lets PRs indefinitely sit around and collect dust? Its
> extremely discouraging for contributors if their work just gets ignored.
> With some extra work I imagine its possible to get the PR queue to a
> much more manageable size w
On Fri, 2023-08-11 at 07:46 -0700, orbea wrote:
>
> Understandable, but I still don't get how 1 or 2 people can take care
> of SBo every week while Gentoo the process stagnates.
Probably due to compartmentalization. In Gentoo you're often waiting
for one maintainer. Or worse, waiting for one "pro
On Fri, 2023-08-11 at 10:35 -0700, orbea wrote:
>
> Perhaps the correct answer would be neither Bugzilla or Github?
A mailing list (whose archives work :o) with git-send-email threads
would be an improvement over both.
On Fri, 2023-08-11 at 18:37 -0500, Gordon Pettey wrote:
>
> "Not using GitHub" is not an excuse for a PR to sit ignored when it has a
> bug attachment. Anyone can view a PR anonymously and clone the remote from
> the read-only https URL. There's no "using github" required for that beyond
> clickin
On Tue, 2023-09-12 at 22:52 -0400, Eli Schwartz wrote:
>
> Is portage generally expected to successfully complete (including
> internal metadata write stages) when its workdir drive runs out of space
> partway through?
>
No, but I think what everyone else is forgetting to mention is that if
it's
On 2023-09-17 08:26:50, Alexe Stefan wrote:
> One is written in shell, the other is written in c.(no problems here)
> One is not part of systemd, the other is.
> How are they identical.
The big picture is that the tmpfiles.d specification is impossible to
implement securely on a POSIX system. The
On 2023-09-17 15:32:46, Marc Joliet wrote:
> I just want to say how amazed I am that you (and Arsen, too) still have the
> patience to try and explain the realities of the situation like this,
> especially after the eudev thread.
I'm a founding member of the systemd haters club so I'm sympathetic,
On 2023-09-17 20:28:49, Alexe Stefan wrote:
>
> There are 2 open pr's on the opentmpfiles github. One removes the
> security vulnerability, but is non-compliant with the spec, the other
> is (at least is a start of) a rewrite in c.
The PR is still vulnerable. These checks,
_chown() {
local
On Sat, 2023-09-23 at 00:10 +0530, Siddhanth Rathod wrote:
>
> By establishing a universal remote-ID file, we can streamline this
> process. Your thoughts and feedback on this proposal would be greatly
> appreciated.Also, Any preferences on format?
Building the wiki page isn't too hard, but wha
On Sat, 2023-09-23 at 15:39 +0100, Sam James wrote:
>
> At the moment, we bundle the DTD in pkgcore. If we just shoved it in
> metadata/ instead in the main repo, we don't have that kind of problem.
>
I might be missing something obvious, but what I mean is, suppose we
have this plain-text mappi
On Sun, 2023-09-24 at 23:14 +0530, Siddhanth Rathod wrote:
> How does modifying the DTD with a git hook sound ?
That could work if we put the DTD, XML schema, and RELAX NG schema all
in the repo metadata. The remaining projects are programs and (given
access to ::gentoo) can probably parse the lis
The "cran" mirrorlist contained exactly one working mirror and was used
by exactly one ebuild. The working mirror has been inlined into the
ebuild's SRC_URI.
Signed-off-by: Michael Orlitzky
---
profiles/thirdpartymirrors | 1 -
1 file changed, 1 deletion(-)
diff -
This is no longer used anywhere in ::gentoo. It was needed once upon a
time for sci-geosciences/gmt but that project is now hosted on Github.
---
profiles/thirdpartymirrors | 1 -
1 file changed, 1 deletion(-)
diff --git a/profiles/thirdpartymirrors b/profiles/thirdpartymirrors
index 97d3f261bc5b
7;t resolve)
* http://mirror.cc.columbia.edu/ (timed out)
To confirm that these are in fact dead, the list at
http://mirrors.ubuntu.com/mirrors.txt
can be cross-referenced.
Signed-off-by: Michael Orlitzky
---
profiles/thirdpartymirrors | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/profiles
Close https://bugs.gentoo.org/916556 by inlining the samba mirror into
net-fs/samba and sys-auth/pam_smb and then dropping the entry from
thirdpartymirrors.
Michael Orlitzky (3):
net-fs/samba: inline mirror://samba/ into SRC_URI
sys-auth/pam_smb: inline mirror://samba/ into SRC_URI
profiles
Bug: https://bugs.gentoo.org/916556
Signed-off-by: Michael Orlitzky
---
net-fs/samba/samba-4.18.4-r1.ebuild | 4 ++--
net-fs/samba/samba-4.18.5-r1.ebuild | 4 ++--
net-fs/samba/samba-4.18.6-r1.ebuild | 4 ++--
net-fs/samba/samba-4.18.7.ebuild| 4 ++--
net-fs/samba/samba-4.18.8.ebuild| 4
Bug: https://bugs.gentoo.org/916556
Signed-off-by: Michael Orlitzky
---
sys-auth/pam_smb/pam_smb-2.0.0_rc6-r3.ebuild | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/sys-auth/pam_smb/pam_smb-2.0.0_rc6-r3.ebuild
b/sys-auth/pam_smb/pam_smb-2.0.0_rc6-r3.ebuild
index
In https://github.com/gentoo/gentoo/pull/34472 I'd like to add 61
packages under a new dev-gap category. GAP has its own package
ecosystem,
https://www.gap-system.org/Packages/packages.html
and a reasonably standard build/install process. Since most GAP
packages are written in its own GAP langu
, suggestions, and complaints are appreciated.
--
# Copyright 2024 Gentoo Authors
# Distributed under the terms of the GNU General Public License v2
# @ECLASS: gap-pkg.eclass
# @MAINTAINER:
# François Bissey
# Michael Orlitzky
# Gentoo Mathematics Project
# @AUTHOR:
# François Bissey
# Michael Orlitzky
On Tue, 2024-01-16 at 10:26 +0100, Florian Schmaus wrote:
> +ctan https://mirrors.ctan.org/ https://ftp.fau.de/ctan/
> https://mirror.physik.tu-berlin.de/pub/CTAN/ https://ftp.sun.ac.za/ftp/CTAN/
> https://mirror.math.princeton.edu/pub/CTAN/
> https://mirrors.sjtug.sjtu.edu.cn/ctan/ http
On Fri, 2024-02-09 at 10:54 -0500, Ionen Wolkens wrote:
>
> Is there even any reason to ever disable unicode support? Point is that
> why have USE for it? Or does it introduce additional dependencies?
Being able to disable things like this is one of the few reasons why
people choose Gentoo.
On Fri, 2024-02-09 at 11:57 -0500, Mike Gilbert wrote:
>
> Based on this pkgcheck issue, this originates from a decision from by
> Gentoo QA team.
>
> https://github.com/pkgcore/pkgcheck/issues/414#issuecomment-1213057268
>
Thanks for the dig. I agree with the reasoning for things like
USE=bash
On Fri, 2024-02-09 at 14:09 -0500, Eli Schwartz wrote:
>
> Asking out of genuine ignorance: what kind of direct behavioral changes
> occur as a result of setting or unsetting USE=ipv6.
One example I know off the top of my head is dev-lang/php where
USE=ipv6 isn't entirely about ipv6 connectivity
On Fri, 2024-02-09 at 16:04 -0500, Eli Schwartz wrote:
>
> Counterpoint: some PHP program out there is probably vulnerable because
> it tried to validate an ipv6 address and could not distinguish between
> "it's okay" and "idk if it's okay, the function you called does not
> exist" (because php is
On Sat, 2024-02-10 at 17:57 +0100, Daniel Simionato wrote:
> Hello,
> I'd like to start a discussion regarding setting HOME_MODE by default in
> the /etc/login.defs file (owned by sys-apps/shadow package).
>
> Upstream keeps HOME_MODE commented:
> https://github.com/shadow-maint/shadow/blob/3e59e
On Thu, 2024-02-29 at 14:47 +0100, Florian Schmaus wrote:
> >
> > +if [[ -z ${TL_PV} ]] \
> > + && [[ ${EAPI} -ge 8 ]] \
>
> I am skeptical of this construct, as in the past we had non-numeric
> EAPIs. So I may have to go with EAPI == 8 for now. Input appreciated.
>
The eclass only sup
On Thu, 2024-02-29 at 15:21 +0100, Florian Schmaus wrote:
> >
> > The eclass only supports EAPIs {7,8,...} so it should suffice to
> > blacklist EAPI=7.
>
> Fair point, but that would mean to remember to adjust this line once the
> eclass gets support for EAPI 9.
>
It should do the right thing
On Thu, 2024-03-21 at 16:44 +, Andrey Grozin wrote:
> sci-mathematics/arb has been merged into sci-mathematics/flint, see
> https://github.com/flintlib/arb
> Is it time to last-rite sci-mathematics/arb?
>
Yeah, I was waiting for flint-3.x to go stable first since arb is
stable. But until rece
On Wed, 2024-04-03 at 16:30 +0100, Eddie Chapman wrote:
> It does involve a
> relatively small hack and functionality previously provided by xz-utils is
> replaced by app-arch/p7zip.
I did the same thing with app-arch/unzip a long time ago. You caught a
lot of shit for your post, but I don't think
We finally had to migrate to a new nameserver, so net-dns/djbdns is up
for grabs. No open bugs, but you've been warned, it's a monster.
Unmaintained for roughly 20 years, weird init, lots of big patches that
conflict with one another, bit-rotting C code, etc.
On Sat, 2024-04-06 at 17:06 +0200, Andreas K. Huettel wrote:
> Hi all,
>
> so here's a small update on the state of the 23.0 profiles:
>
Why was this silently added to make.defaults for all 23.0 profiles?
> # This just makes sense nowadays, if only for distfiles...
> USE="lzma zstd"
On Sun, 2024-04-07 at 14:35 +0200, Andreas K. Huettel wrote:
>
> Uhh, I dont really remember, I think some Chinese-sounding guy asked
> me for it... (j/k)
It is remarkably bad timing. How it looks: Gentoo's response to the xz
incident is to have me rebuild my entire system with everything that
c
On Sun, 2024-04-07 at 16:48 +0200, Michał Górny wrote:
>
> So, what you're basically saying, is that the best Gentoo response right
> now would be to frantically remove LZMA support everywhere? I'm sure
> that would be so much better than our response of masking vulnerable
> versions and issuing
On Sun, 2024-04-07 at 15:07 +0200, Andreas K. Huettel wrote:
> > tl;dr can we turn them back off in the profile? In any scenario where
> > they are beneficial, there's a better place to put them.
>
> Easily doable with lzma, if there is consensus for it.
>
> Slightly more complex for zstd since t
On Mon, 2024-04-22 at 16:46 +0200, Jaco Kroon wrote:
>
> Which in my *opinion* is not desirable behaviour, but I'm open for
> discussion.
>
> xdebug.mode = off by default, but the extension still gets loaded.
>
> Not sure if there is a sensible "solution", further expanding USE flags
> certain
On Tue, 2024-04-23 at 13:05 +0200, Jaco Kroon wrote:
> but how do we handle
> users making manual additions/modifications to /etc/php/ or have some
> form of "fsck" for that?)
We'd have to use a new location that doesn't collide with anything that
the user might edit, like /etc/php/*/ext-eselect
acct-user.eclass makes the username variable read-only:
# The name of the user. This is forced to ${PN} and the
# policy prohibits it from being changed.
ACCT_USER_NAME=${PN}
readonly ACCT_USER_NAME
That enforces the ::gentoo policy, but in an overlay, makes it
impossible to create valid
e names to global scope so that the eclasses
won't try to use weird user/group names as bash variables names.
Michael Orlitzky (4):
acct-user.eclass: make ACCT_USER_NAME writable
acct-group.eclass: make ACCT_GROUP_NAME writable
acct-user.eclass: use an eclass variable for the override va
iting some otherwise-valid usernames. We drop the "readonly" to
allow those users to be managed (in overlays) using GLEP81 packages.
Signed-off-by: Michael Orlitzky
---
eclass/acct-user.eclass | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/eclass/acct-user.
iting some otherwise-valid group names. We drop the "readonly" to
allow those groups to be managed (in overlays) using GLEP81 packages.
Signed-off-by: Michael Orlitzky
---
eclass/acct-group.eclass | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/eclass/acct-group.
in a bash variable at the expense of violating expectations
about the override variable names.
Signed-off-by: Michael Orlitzky
---
eclass/acct-user.eclass | 32 ++--
1 file changed, 22 insertions(+), 10 deletions(-)
diff --git a/eclass/acct-user.eclass b/eclass/acct-user.
in a bash variable at the expense of violating expectations
about the override variable names.
Signed-off-by: Michael Orlitzky
---
eclass/acct-group.eclass | 23 +++
1 file changed, 19 insertions(+), 4 deletions(-)
diff --git a/eclass/acct-group.eclass b/eclass/acct-group.
On Thu, 2024-05-09 at 14:03 +0200, Michał Górny wrote:
> > @ECLASS_VARIABLE: _OVERRIDE_NAME
>
> This is not prefixed correctly.
>
ACCT_USER_OVERRIDE_NAME has an entirely different meaning, but I could
use _ACCT_USER_OVERRIDE_NAME if that's what you're suggesting.
> > +# @INTERNAL
> > +# @DESC
struct the make.conf overrides.
Changes in v2:
- Two spaces after a period.
- Use PN directly for override names
Michael Orlitzky (4):
acct-user.eclass: make ACCT_USER_NAME writable
acct-group.eclass: make ACCT_GROUP_NAME writable
eclass/acct-user.eclass: use $PN to construct make.conf ove
iting some otherwise-valid usernames. We drop the "readonly" to
allow those users to be managed (in overlays) using GLEP81 packages.
Signed-off-by: Michael Orlitzky
---
eclass/acct-user.eclass | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/eclass/acct-user.
iting some otherwise-valid group names. We drop the "readonly" to
allow those groups to be managed (in overlays) using GLEP81 packages.
Signed-off-by: Michael Orlitzky
---
eclass/acct-group.eclass | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/eclass/acct-group.
iable names using PN instead of ACCT_USER_NAME. In ::gentoo, the two
are equivalent, but in an overlay this allows weirder usernames at the
expense of slightly mismatched variable names.
Signed-off-by: Michael Orlitzky
---
eclass/acct-user.eclass | 12 +++-
1 file changed, 7 insertions(
s the
variable names using PN instead of ACCT_GROUP_NAME. In ::gentoo, the two
are equivalent, but in an overlay this allows weirder group names at the
expense of slightly mismatched variable names.
Signed-off-by: Michael Orlitzky
---
eclass/acct-group.eclass | 10 ++
1 file changed, 6 inser
On Thu, 2024-05-09 at 16:41 -0400, Michael Orlitzky wrote:
> Support changing the user/group name of GLEP81 packages. This is
> sometimes required in overlays because package naming restrictions
> prohibit valid user/group names from being package names.
Pushed.
On 2024-06-11 07:11:06, Viorel Munteanu wrote:
>
> # Viorel Munteanu (2024-06-11)
> # dev-php/pear, dev-php/PEAR-* and their reverse dependencies: mask for
> removal
> # in 30 days.
> # They are all unmaintained, most of the ebuilds are still EAPI 6, and
> together
> # they have around 40 bugs.
On Tue, 2024-06-11 at 14:56 +0300, Arthur Zamarin wrote:
>
> Sounds good to me, then please make sure all that dependency tree needed
> for those targets are EAPI bumped, and most QA warnings from pkgcheck
> are handled. Currently those packages look unmaintained.
>
> When you (or anyone else) ha
On Wed, 2024-06-12 at 08:57 +0300, Viorel Munteanu wrote:
>
> I had to bump to EAPI 8 and unmask dev-php/pear, because it's used by
> the eclass. This makes the thread subject a bit wrong, but I won't
> change it.
Thanks, I think once most of the PEAR packages are removed, we'll be
very close
On Wed, 2024-07-17 at 15:05 +0300, Zurab Kvachadze wrote:
>
> +NGINX_CONFIGFILE=${NGINX_CONFIGFILE:-/etc/nginx/nginx.conf}
> +pidfile=${NGINX_PIDFILE:-/run/nginx.pid}
OpenRC allows you to run multiple instances of the same service by
creating symlinks in /etc/init.d. For example, I might symlink
On Fri, 2024-07-19 at 09:20 +, Zurab Kvachadze wrote:
>
> I haven't even known of this OpenRC feature! As you explained it, the
> removal of NGINX_{CONFIG,PID}FILE totally makes sense. Should I also add
> '-g "pid ${pidfile};"' to command_args for your example with
> 'nginx-internal' to work a
On Sat, 2024-07-20 at 19:58 +0300, Alexander Tsoy wrote:
>
> Please note that systemd-tmpfiles can remove the whole /var/tmp/nginx
> directory if it and its contents are not touched for a long time. And
> then reload of nginx might fail. So it is better to create this
> directory via tmpfiles.d.
>
301 - 400 of 914 matches
Mail list logo
