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
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
>
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
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 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
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"
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 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
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
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
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
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:
>
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
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 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
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 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/
, 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
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
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
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
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
e)
* 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/thirdpart
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
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 --git
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
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
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
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() {
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
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 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
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
>
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 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
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
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 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
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-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
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)
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 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.
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
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
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
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 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
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
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
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
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
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
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
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
>
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
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 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
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 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
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.
On Tue, 2022-01-25 at 21:59 +0100, Agostino Sarubbo wrote:
>
> - If you are CC'ed by the hook and you are part of the alias that is the
> assignee of the bug,
> you will receive two emails unless the hook integrates the alias.
>
> - Based on the previous point, I'd suggest to use a wrapper if
On Tue, 2022-01-25 at 11:29 -0800, Alec Warner wrote:
>
> Just to clarify here:
> For your own commits (e.g. fixing a package you own) you are already
> typically on the bug..right?
Right.
> I assume the major use case here is proxying commits for others (where
> they are on the bug, but you
Can I request that Bug: and Closes: tags in our commits automatically
CC the committer on the bug that is modified?
Use case: I often fix (sci-*) bugs that I'm not CCed on, and a user
will leave a comment like "it still crashes on x86" that I never see.
Of course, I could manually CC myself on
On 2022-01-20 16:32:30, Brian Evans wrote:
>
> GNOME and Mozilla products still pull in spidermonkey but other users
> will have a much reduced requirement for rust.
>
Avoiding librsvg used to be difficult because it's required by our GTK
icon packages to render PNGs from SVGs. Luckily
On Tue, 2022-01-04 at 19:26 +0100, Piotr Karbowski wrote:
>
> And none of which happens unless you intentionally trigger it.
>
> ...
>
> Sure, acl and how chmod manipulate mask on ACL-enabled entities is not
> very simple, but nothing will break by itself just because you have acl
> support
On Tue, 2022-01-04 at 12:03 -0500, Mike Gilbert wrote:
>
> I disagree with the claim that "most people" should disable ACL
> support at build time. That just gives you partially functional tools.
> The ACL behavior can generally be controlled using runtime options.
I understand why people would
On Tue, 2022-01-04 at 03:38 +, Sam James wrote:
>
> ACL is kind of similar to what Ionen said for PAM, i.e. sometimes
> people may want to turn it off and it makes sense to expose
> this option for those who do, but we don't need to try support it.
>
This is another important one. It has
On Mon, 2022-01-03 at 16:51 -0800, Alec Warner wrote:
> >
> >
> > Many packages need their ipv6 code disabled if the kernel has no ipv6
> > support, and enabling ipv6 in the kernel is a pointless security risk
> > for pretty much anyone in the United States.
>
>
On Mon, 2022-01-03 at 21:29 +0100, Piotr Karbowski wrote:
>
> Perhaps the 'pam' example was extreme, but ipv6, or threads as Sam
> shared, does not make sense to be togglable.
>
Many packages need their ipv6 code disabled if the kernel has no ipv6
support, and enabling ipv6 in the kernel is a
On Sat, 2021-12-04 at 10:47 +0100, Fabian Groffen wrote:
>
> Now, if you would make a supported claim that all terminals we install
> use a black background by default, your change becomes more valid.
>
>
For one, when you're working through the handbook to install Gentoo,
you're doing it on a
On 2021-12-02 08:12:55, Alec Warner wrote:
>
> Can we automate any of it? Emit QA warnings? etc.
>
I would love to be proven wrong, but I don't think so. We have two
main problems. First, The service scripts are POSIX sh, which is
better than bash, but still can't easily be parsed for semantic
On 2021-12-01 21:02:20, Brian Evans wrote:
> After a cursory scan of the Gentoo repository, I've noticed an
> overabundance of start_stop_daemon_args being declared in scripts committed.
>
> I would like to draw attention and see if we can clean these up together.
A lot of this is covered in the
On Tue, 2021-11-30 at 22:45 -0800, Alec Warner wrote:
>
> So questions from my side are:
> Does your cluster not have human users?
> Do the userids for the human users also not have to match between
> hosts in the cluster?
>
>
You can easily create ebuilds for the human users who access the
On Tue, 2021-11-30 at 19:32 -0600, William Hubbs wrote:
>
> This is the part of this that I don't understand. If we aren't enforcing
> an ID, why do we care which ID to try first? It seems to be an
> unnecessary step since users can pick the IDs they want by putting
> settings in make.conf.
>
On Mon, 2021-11-29 at 05:05 +, Sam James wrote:
>
> What I wish we had done (and there's still time to do, albeit belated --
> it's still useful for the remaining big bits like Apache and nginx) is
> write a news item explaining the implications and linked to a page
> like
On Sun, 2021-11-28 at 23:39 +, Sam James wrote:
>
> Whissi and others raised some points that I think you may have some views on
> (and I'm interested in hearing them).
>
I don't want to put words in his mouth, but I think Whissi takes issue
with using the package manager to manage users,
On Sun, 2021-11-28 at 16:31 -0600, William Hubbs wrote:
> All,
>
> I want to discuss why we ban -1 as the ACCT_USER_ID and ACCT_GROUP_ID setting
> for all acct-user and acct-group packages in ::gentoo.
>
> Here are my thoughts about it.
>
> - As Gordon pointed out, it isn't necessary for us to
On 2021-11-28 11:06:36, Ulrich Mueller wrote:
>
> While the rationale for static allocation that made it into GLEP 81 [1]
> is rather weak, several people had argued in favour of it on the mailing
> list [2].
>
We don't even do static allocation. The UIDs and GIDs in the ebuilds
are
On Wed, 2021-11-03 at 16:25 +0100, Max Zettlmeißl wrote:
> On Wed, 3 Nov 2021 at 14:15, Michael Orlitzky wrote:
> > If no one intends to join, we should drop the following to maintainer-
> > needed:
>
> I use some of those packets daily. Is there a way to join the Common
&
If no one intends to join, we should drop the following to maintainer-
needed:
app-misc/rlwrap
dev-libs/ffcall
dev-libs/libsigsegv
dev-lisp/alexandria
dev-lisp/asdf
dev-lisp/cl-ppcre
dev-lisp/cl-ppcre-unicode
dev-lisp/clisp
dev-lisp/clozurecl
dev-lisp/clx
dev-lisp/cmucl
dev-lisp/ecls
On Tue, 2021-10-05 at 17:13 +0200, Michał Górny wrote:
>
> > 2. What happens to the LTS branch when the next EAPI is released?
> >
>
> I haven't really thought about it. Are you suggesting that we could
> bump 'master' Portage to newer EAPI earlier or...?
>
I just mean that, a priori, the
On Tue, 2021-10-05 at 10:31 +0200, Michał Górny wrote:
> Hi, everyone.
>
> I've been thinking about this for some time already, and the recent
> FILESDIR mess seems to confirm it: I'd like to start a more stable LTS
> branch of Portage.
>
I think this is healthy for most software projects, but
On Mon, 2021-09-27 at 15:44 -0400, Mike Gilbert wrote:
> On Mon, Sep 27, 2021 at 3:11 PM Peter Stuge wrote:
> >
> > Mike Gilbert wrote:
> > > It's a waste of time and effort to pepper random ebuilds with checks
> > > for options that everyone should have enabled in the first place.
> >
> > It's
On Thu, 2021-09-02 at 14:58 +0200, Michał Górny wrote:
> >
> Apparently, need_apache* is the problem. Most of the ebuilds in www-
> apache/* are calling it:
>
The apache-module eclass tells you to do that because it needs some of
those APACHE_* paths. It should really be figuring them out
On Thu, 2021-09-02 at 12:46 +0200, Michał Górny wrote:
> Signed-off-by: Michał Górny
> ---
> eclass/apache-module.eclass | 1 +
> 1 file changed, 1 insertion(+)
> ...
> # @SUPPORTED_EAPIS: 5 6 7
> +# @PROVIDES: depend.apache
I'm not sure about this one. The depend.apache eclass is junk and we
There have been some attacks on STARTTLS lately, so I'm finally getting
around to using implicit TLS for mail submission on port 465.
I tried this on dev.gentoo.org, and it seems to work. For example: I
just switched Evolution to port 465, with always-on TLS, and am sending
this message.
Is this
On Thu, 2021-08-12 at 17:22 +0200, Rolf Eike Beer wrote:
> The default owner is root:root anyway.
>
This is only true of you don't call insopts earlier with some other
value. I see "insopts -o root -g qmail -m 700" in there so you might
want to double check.
On Fri, 2021-07-23 at 00:20 +0200, Conrad Kostecki wrote:
> This update drops the function 'postgres_new_user', which was used to
> create the 'postgres' user and group.
>
> ...
>
> Since many other packages depend on the 'postgres' and 'postgres-multi'
> eclass, adding the core acct-*/postgres
On Mon, 2021-07-12 at 10:46 -0500, Ben Kohler wrote:
>
> Nobody is "disabling choice" here, a change in defaults doesn't remove
> your ability to choose something else.
I think what you're suggesting is that default-on is not any worse for
choice than default-off, since both can be changed?
On Sun, 2021-07-11 at 15:53 +0200, Thomas Deutschmann wrote:
>
> Furthermore, tmpfiles.d settings are only supposed for creation,
> deletion and cleaning of volatile and temporary files. Any package which
> will install tmpfiles.d settings which will create files in persistent
> locations
On Fri, 2021-07-09 at 12:05 +0200, Ulrich Mueller wrote:
> > > > > >
>
> Sorry, but that doesn't make sense. These are global USE flags, and
> the aim here is to set a _global_ default for them, based on the fact
> that these libraries are present on every Gentoo system.
>
> So if we agree that
On Thu, 2021-07-08 at 13:17 -0700, Matt Turner wrote:
>
> I hear you, and I appreciate the theoretical concerns.
>
> I could maybe even support this position if you were actively working
> towards this new and glorious future, but the only time I hear
> anything about it is when you're arguing
On Thu, 2021-07-08 at 11:15 -0700, Matt Turner wrote:
>
> So, the thing about running a minimal system is... you already have
> these dependencies installed. This doesn't change that...
>
> I could of course change the default of every bzip2/lzma/zstd in IUSE
> (and might as well handle zlib too
On Thu, 2021-07-08 at 07:19 -0500, Ben Kohler wrote:
> On 7/8/21 6:54 AM, Michael Orlitzky wrote:
> > On Wed, 2021-07-07 at 22:01 -0700, Matt Turner wrote:
> > > Enable these flags by default, since they effectively add no additional
> > > dependencies:
> > Why? Th
On Mon, 2021-06-28 at 16:52 +0200, Michał Górny wrote:
> >
> > This is long overdue, for many reasons, but in particular it would
> > force us to declare a dependency on a C compiler if one is needed and
> > allow you to re-test only those packages that use a C compiler.
> >
>
> Which C
On Mon, 2021-06-28 at 16:31 +0200, Gerion Entrup wrote:
>
> This should only build, if _all_ build dependencies are present
> (including every compiler and base system tool). Of course, it needs a
> bigger rework of the portage build process.
We had a GSoC project that aimed to do something like
On Mon, 2021-06-28 at 15:00 +0200, Agostino Sarubbo wrote:
>
> Instead, imagine that each ebuild declares a variable called SOURCETYPE ( or
> similar, or in metadata.xml if you prefer ) and with a tool like equery/eix
> we
> are able to get the list of all packages that compiles C code.
>
I
>
> This depends on the actual domain of numbers. If the primes involved
> have 20 digits as in your example, then factor should be used of course.
>
> I suspect though that we're talking about small numbers (below 100?)
> here, in which case a solution in pure bash would be preferable.
>
If
On Sat, 2021-04-10 at 00:32 +0100, Sam James wrote:
>
>
> Yes, this is the part I find difficult too. The important
> distinction here was *bootstrapping* (which I missed)
> but I think at least we should make a list of packages generally considered
> critical for bootstrap.
>
What is a
1 - 100 of 929 matches
Mail list logo
