Re: [gentoo-dev] [RFC] sys-meta/* to own and control /bin/{cpio,sh,tar,...} symlinks (alternatives-ish)

2022-11-23 Thread Michael Orlitzky
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

Re: [gentoo-dev] [RFC] sys-meta/* to own and control /bin/{cpio,sh,tar,...} symlinks (alternatives-ish)

2022-11-23 Thread Michael Orlitzky
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

Re: [gentoo-dev] [RFC] sys-meta/* to own and control /bin/{cpio,sh,tar,...} symlinks (alternatives-ish)

2022-11-23 Thread Michael Orlitzky
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

Re: [gentoo-dev] [PATCH] git-r3.eclass: Add checkout dirs as "safe" directories

2022-11-06 Thread Michael Orlitzky
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

Re: [gentoo-dev] Clang 16 is coming - and it'll break your packages!

2022-10-09 Thread Michael Orlitzky
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

Re: [gentoo-dev] Last rites: various more revdep-less Haskell packages

2022-08-21 Thread Michael Orlitzky
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

Re: [gentoo-dev] Last rites: various more revdep-less Haskell packages

2022-08-21 Thread Michael Orlitzky
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 >

Re: [gentoo-dev] [PATCH] elisp-common.eclass: fix for Emacs 29 (explicitly require autoload)

2022-08-18 Thread Michael Orlitzky
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

Re: [gentoo-dev] Last rites: large amount of unmaintained dev-haskell/* package

2022-07-23 Thread Michael Orlitzky
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.

Re: [gentoo-dev] Last rites: large amount of unmaintained dev-haskell/* package

2022-07-23 Thread Michael Orlitzky
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

Re: [gentoo-dev] Should we join the which hunt?

2022-05-13 Thread Michael Orlitzky
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

Re: [gentoo-dev] Should we join the which hunt?

2022-05-13 Thread Michael Orlitzky
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

Re: [gentoo-dev] [PATCH] metadata/install-qa-check.d: add 60libtool-la (check for unnecessary .la files)

2022-04-15 Thread Michael Orlitzky
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.

Re: [gentoo-dev] Feature request: auto-CC for bugs modified via commit tags

2022-01-25 Thread Michael Orlitzky
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

Re: [gentoo-dev] Feature request: auto-CC for bugs modified via commit tags

2022-01-25 Thread Michael Orlitzky
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

[gentoo-dev] Feature request: auto-CC for bugs modified via commit tags

2022-01-25 Thread Michael Orlitzky
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

Re: [gentoo-dev] [RFC] making rust-bin ordered first in virtual/rust

2022-01-20 Thread Michael Orlitzky
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

Re: [gentoo-dev] Rationalizing USE flags by narrowing the scope of them.

2022-01-04 Thread Michael Orlitzky
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

Re: [gentoo-dev] Rationalizing USE flags by narrowing the scope of them.

2022-01-04 Thread Michael Orlitzky
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

Re: [gentoo-dev] Rationalizing USE flags by narrowing the scope of them.

2022-01-03 Thread Michael Orlitzky
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

Re: [gentoo-dev] Rationalizing USE flags by narrowing the scope of them.

2022-01-03 Thread Michael Orlitzky
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. > >

Re: [gentoo-dev] Rationalizing USE flags by narrowing the scope of them.

2022-01-03 Thread Michael Orlitzky
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

Re: [gentoo-portage-dev] [PATCH] portage.output: Replace darkblue colors with teal

2021-12-04 Thread Michael Orlitzky
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

Re: [gentoo-dev] Common options missed in OpenRC declarative scripts and how to improve them

2021-12-02 Thread Michael Orlitzky
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

Re: [gentoo-dev] Common options missed in OpenRC declarative scripts and how to improve them

2021-12-02 Thread Michael Orlitzky
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

Re: [gentoo-dev] rfc: allow -1 for ACCT_USER_ID and ACCT_GROUP_ID in ::gentoo

2021-12-01 Thread Michael Orlitzky
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

Re: [gentoo-dev] rfc: allow -1 for ACCT_USER_ID and ACCT_GROUP_ID in ::gentoo

2021-11-30 Thread Michael Orlitzky
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. >

Re: [gentoo-dev] rfc: allow -1 for ACCT_USER_ID and ACCT_GROUP_ID in ::gentoo

2021-11-29 Thread Michael Orlitzky
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

Re: [gentoo-dev] rfc: allow -1 for ACCT_USER_ID and ACCT_GROUP_ID in ::gentoo

2021-11-28 Thread Michael Orlitzky
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,

Re: [gentoo-dev] rfc: allow -1 for ACCT_USER_ID and ACCT_GROUP_ID in ::gentoo

2021-11-28 Thread Michael Orlitzky
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

Re: [gentoo-dev] Don't use UIDs and GIDs below 100 without QA approval

2021-11-28 Thread Michael Orlitzky
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

Re: [gentoo-dev] Common Lisp project is empty

2021-11-03 Thread Michael Orlitzky
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 &

[gentoo-dev] Common Lisp project is empty

2021-11-03 Thread Michael Orlitzky
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

Re: [gentoo-portage-dev] [RFC] LTS branch of Portage

2021-10-05 Thread Michael Orlitzky
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

Re: [gentoo-portage-dev] [RFC] LTS branch of Portage

2021-10-05 Thread Michael Orlitzky
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

Re: [gentoo-dev] Guidance on adding kernel config checks to ebuilds

2021-09-28 Thread Michael Orlitzky
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

Re: [gentoo-dev] [PATCH 02/44] apache-module.eclass: Set @PROVIDES

2021-09-02 Thread Michael Orlitzky
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

Re: [gentoo-dev] [PATCH 02/44] apache-module.eclass: Set @PROVIDES

2021-09-02 Thread Michael Orlitzky
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

[gentoo-dev] Infra support for mail submission with implicit TLS on port 465

2021-08-14 Thread Michael Orlitzky
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

Re: [gentoo-dev] [PATCH 2/3] qmail.eclass: remove magic to query root group

2021-08-12 Thread Michael Orlitzky
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.

Re: [gentoo-dev] [PATCH] eclass/postgres.eclass: migrate to GLEP 81

2021-07-22 Thread Michael Orlitzky
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

Re: [gentoo-dev] [PATCH] profiles/default/linux: Add USE="bzip2 lzma zstd" to defaults

2021-07-12 Thread Michael Orlitzky
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?

Re: [gentoo-dev] [PATCH] 2021-07-09-systemd-tmpfiles: re-add news item

2021-07-12 Thread Michael Orlitzky
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

Re: [gentoo-dev] [PATCH] profiles/default/linux: Add USE="bzip2 lzma zstd" to defaults

2021-07-09 Thread Michael Orlitzky
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

Re: [gentoo-dev] [PATCH] profiles/default/linux: Add USE="bzip2 lzma zstd" to defaults

2021-07-08 Thread Michael Orlitzky
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

Re: [gentoo-dev] [PATCH] profiles/default/linux: Add USE="bzip2 lzma zstd" to defaults

2021-07-08 Thread Michael Orlitzky
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

Re: [gentoo-dev] [PATCH] profiles/default/linux: Add USE="bzip2 lzma zstd" to defaults

2021-07-08 Thread Michael Orlitzky
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

Re: [gentoo-dev] Declare the type of source

2021-06-28 Thread Michael Orlitzky
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

Re: [gentoo-dev] Declare the type of source

2021-06-28 Thread Michael Orlitzky
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

Re: [gentoo-dev] Declare the type of source

2021-06-28 Thread Michael Orlitzky
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

Re: [gentoo-dev] [PATCH] qmail.eclass: simplify is_prime()

2021-06-18 Thread Michael Orlitzky
> > 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

Re: [gentoo-dev] [PATCH v2 3/3] gnuconfig.eclass: use BDEPEND, BROOT where available (drop support for EAPI <4)

2021-04-09 Thread Michael Orlitzky
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

Re: [gentoo-dev] [PATCH v2 3/3] gnuconfig.eclass: use BDEPEND, BROOT where available (drop support for EAPI <4)

2021-04-07 Thread Michael Orlitzky
On Tue, 2021-04-06 at 20:32 +0100, Sam James wrote: > > > > > We usually don't add basic tools like grep to dependencies. > > Few points: > > ... 5) There are no clear rules about what @system packages can be left out of *DEPEND and when, so their presence is wildly inconsistent.

Re: [gentoo-dev] New tool: merge-driver-ekeyword automatically resolves git merge conflicts involving KEYWORDS=...

2021-03-03 Thread Michael Orlitzky
On Wed, 2021-03-03 at 13:09 +0100, Ulrich Mueller wrote: > > > > > > On Tue, 02 Mar 2021, Michael Orlitzky wrote: > > > Are you volunteering to fix all the tools to support the new format > > > correctly? > > The PMS says that KEYWORDS is whitespace-sep

Re: [gentoo-dev] New tool: merge-driver-ekeyword automatically resolves git merge conflicts involving KEYWORDS=...

2021-03-02 Thread Michael Orlitzky
On Tue, 2021-03-02 at 20:42 +0100, Michał Górny wrote: > > Are you volunteering to fix all the tools to support the new format > correctly? > When you already spend all day fixing other peoples' software, this doesn't sound that scary. The PMS says that KEYWORDS is whitespace-separated.

Re: [gentoo-dev] New tool: merge-driver-ekeyword automatically resolves git merge conflicts involving KEYWORDS=...

2021-03-02 Thread Michael Orlitzky
On Tue, 2021-03-02 at 14:02 -0500, Matt Turner wrote: > On Tue, Mar 2, 2021 at 12:11 AM Michael Orlitzky wrote: > > why don't we just enforce putting each > > keyword on a separate line instead, so that we don't have this problem > > in the

Re: [gentoo-dev] New tool: merge-driver-ekeyword automatically resolves git merge conflicts involving KEYWORDS=...

2021-03-01 Thread Michael Orlitzky
On Mon, 2021-03-01 at 22:54 -0500, Matt Turner wrote: > tl;dr: In app-portage/gentoolkit-0.5.1 there's a new tool I wrote, > called merge-driver-ekeyword that can automatically resolve git merge > conflicts involving the KEYWORDS=... line in ebuilds. > > Since the KEYWORDS=... assignment is a

Re: [gentoo-dev] Re: portage reliance on GNU objcopy ownership perseverance behavior in strip

2021-02-09 Thread Michael Orlitzky
On Tue, 2021-02-09 at 21:44 -0500, Michael Orlitzky wrote: > > ... games-arcade/xboing are also suspect. > (This one's fine, that's the documented way to do things now. Although I don't see why we couldn't use a separate group for each game's score file.)

Re: [gentoo-dev] Re: portage reliance on GNU objcopy ownership perseverance behavior in strip

2021-02-09 Thread Michael Orlitzky
On Tue, 2021-02-09 at 18:25 -0800, Manoj Gupta wrote: > > > > Root is the owner but often there is also a group that has access to the > files. > After stripping with llvm-strip, new ownership is root:root instead of > root:. > Therefore, the members of the group lose access to the files post

Re: [gentoo-dev] Re: portage reliance on GNU objcopy ownership perseverance behavior in strip

2021-02-09 Thread Michael Orlitzky
On Tue, 2021-02-09 at 17:53 -0800, Fāng-ruì Sòng wrote: > (I replied via https://groups.google.com/g/linux.gentoo.dev/c/WG-OLQe3yng > "Reply all" (which only replied to the list AFAICT) but I did not > subscribe to gentoo-dev via the official > https://www.gentoo.org/get-involved/mailing-lists/ so

Re: [gentoo-dev] dev-python/cryptography to use rust, effectively killing alpha, hppa, ia64, m68k, s390

2021-02-09 Thread Michael Orlitzky
On Wed, 2021-02-10 at 08:51 +0800, Benda Xu wrote: > > > > The first big blocker we're going to hit is trustme [3] package that > > relies on cryptography API pretty heavily to generate TLS certs for > > testing. If we managed to convince upstream to support an alternate > > crypto backend, we'd

Re: [gentoo-dev] dev-python/cryptography to use rust, effectively killing alpha, hppa, ia64, m68k, s390

2021-02-08 Thread Michael Orlitzky
On Mon, 2021-02-08 at 12:19 +0100, Michał Górny wrote: > > Since cryptography is a very important package in the Python ecosystem, > and it is an indirect dependency of Portage, this means that we will > probably have to entirely drop support for architectures that are not > supported by Rust. >

Re: [gentoo-dev] portage reliance on GNU objcopy ownership perseverance behavior in strip

2021-02-04 Thread Michael Orlitzky
On Thu, 2021-02-04 at 16:09 -0800, Manoj Gupta wrote: > > What does everyone think of modifying usages of calls to strip and > objcopy > inside estrip so that file ownership is manually restored. e.g > > owner=$(stat -U file) > group=$(stat -G file) > strip > chown owner:group file > This is

Re: [gentoo-dev] [RFC] Moving subslot-only virtuals to a separate category to reduce confusion

2021-01-30 Thread Michael Orlitzky
On Sat, 2021-01-30 at 18:35 +0100, Michał Górny wrote: > > To make this SOVERSION-virtual concept more visible and easily > distinguishable from regular virtuals, I'd like to propose that we > start > moving them into a dedicated category. For example, 'lib-sover' > comes > to my mind. While

Re: [gentoo-dev] Re: [PATCH] acct-user.eclass: don't modify existing user by default

2021-01-04 Thread Michael Orlitzky
On 1/4/21 1:20 PM, Michał Górny wrote: Most importantly, it doesn't resolve the core issue of 'we need to update home before merging reverse dependencies'. Quoth the devmanual, "if your package requires a user, you can no longer be sure of that user's home directory or its ownership and

Re: [gentoo-dev] Re: [PATCH] acct-user.eclass: don't modify existing user by default

2021-01-04 Thread Michael Orlitzky
On 1/4/21 1:23 PM, Thomas Deutschmann wrote: People like me could just ignore changed users if changes won't go live until you run said users-update command or make use of INSTALL_MASK. Changes wouldn't go live until you ran etc-update, and *then* users-update.

Re: [gentoo-dev] Re: [PATCH] acct-user.eclass: don't modify existing user by default

2021-01-04 Thread Michael Orlitzky
On 1/4/21 11:45 AM, James Cloos wrote: "RHJ" == Robin H Johnson writes: RHJ> The best I can come up with at the moment, is that any packaging should RHJ> detect if there are user modifications, and provide control to users RHJ> based on that fact. Exactly. Akin to etc-update. We could

Re: [gentoo-dev] [PATCH] acct-user.eclass: don't modify existing user by default

2021-01-04 Thread Michael Orlitzky
On 1/4/21 9:46 AM, Thomas Deutschmann wrote: So the main problem I see with doing this is that it becomes impossible to reliably make changes to a user in later ebuild revisions. He is obviously looking for a way to allow maintainers to change users afterwards. But if we tell people, "If you

Re: [gentoo-dev] [PATCH] acct-user.eclass: don't modify existing user by default

2021-01-03 Thread Michael Orlitzky
On 1/3/21 8:35 PM, Thomas Deutschmann wrote: Modifying an existing user is a bad default and makes Gentoo special because it is common for system administrators to make modifications to user (i.e. putting an user into another service's group to allow that user to access service in question) and

Re: [gentoo-dev] Slotted Lua + revdeps to be unmasked on Christmas Eve

2020-12-23 Thread Michael Orlitzky
On 12/23/20 6:18 PM, Michael Orlitzky wrote: Using pkg-config has a related problem. If lua-5.1 is eselected and if the upstream build system runs $(pkg-config ... lua), it's going to get the information for lua-5.1, even if you're trying to build against lua-5.2. So, first I have to patch

Re: [gentoo-dev] Slotted Lua + revdeps to be unmasked on Christmas Eve

2020-12-23 Thread Michael Orlitzky
On 12/23/20 4:51 PM, Mart Raudsepp wrote: Ühel kenal päeval, K, 23.12.2020 kell 07:49, kirjutas Michael Orlitzky:    AC_SEARCH_LIBS([whatever], [lua], [lua_found="yes"]) How do I pass the name "lua5.2" to that, without hacking configure.ac and running autoreconf? The on

Re: [gentoo-dev] Re: Slotted Lua + revdeps to be unmasked on Christmas Eve

2020-12-23 Thread Michael Orlitzky
On 12/23/20 6:04 PM, Aisha Tammy wrote: Yes, this sounds doable and should work > Only problem is that if there is an actual liblua.so with the proper SONAME available in /usr/lib64 (I dunno if Gentoo has any provider of liblua.so with that SONAME, IIRC SLOT=0 currently does that) then it will

Re: [gentoo-dev] Re: Slotted Lua + revdeps to be unmasked on Christmas Eve

2020-12-23 Thread Michael Orlitzky
On 12/23/20 1:14 PM, Aisha Tammy wrote: I've recently had the same problem for TACC/Lmod which uses autotools to get lua versions and lua.cpath and lua.path and did infact manage to push the horrendously large patch upstream -

Re: [gentoo-dev] Re: Slotted Lua + revdeps to be unmasked on Christmas Eve

2020-12-23 Thread Michael Orlitzky
On 12/23/20 12:13 PM, Jonathan Callen wrote: One way this could be done without breaking things might be to create a subdirectory of /usr/$(get_libdir) for each version of Lua and creating a liblua.a and/or liblua.so symlink in that directory pointing to the liblua${VERSION}.* file in

Re: [gentoo-dev] Slotted Lua + revdeps to be unmasked on Christmas Eve

2020-12-23 Thread Michael Orlitzky
On 12/23/20 8:35 AM, Jaco Kroon wrote: Michael, I'm busy disecting what Marek has done for asterisk as I need to make that work for multiple versions of net-misc/asterisk-16.14.0-r100, not merely the one he did it for - perhaps that would be helpful for you as well? I don't know lua at all.

Re: [gentoo-dev] Slotted Lua + revdeps to be unmasked on Christmas Eve

2020-12-23 Thread Michael Orlitzky
On 12/23/20 4:09 AM, Marek Szuba wrote: I think what you are looking for is lua_get_shared_lib() from lua-utils.eclass. We have already got ebuilds in the tree which use it. Knowing the library name only helps if I patch the build system; that's what I'm getting at. The few packages where

Re: [gentoo-dev] Slotted Lua + revdeps to be unmasked on Christmas Eve

2020-12-22 Thread Michael Orlitzky
On 12/22/20 6:15 PM, Marek Szuba wrote: Dear all, mail-filter/opendkim - committed ebuild needs one extra fix One last design issue that I ran into during the migration. The slotted lua ebuilds install the headers into subdirectories like /usr/include/lua5.2, but otherwise with their

Re: [gentoo-dev] GPG key refresh

2020-12-15 Thread Michael Orlitzky
On 12/15/20 11:11 AM, Thomas Deutschmann wrote: What do you mean exactly? For Gentoo tooling, only Gentoo keyservers are important and Gentoo no longer synchronizes with any other pool. "The Gentoo developer tooling explicitly checks the Gentoo keyserver pool with a much higher frequency"

Re: [gentoo-dev] GPG key refresh

2020-12-15 Thread Michael Orlitzky
On 12/15/20 10:27 AM, Thomas Deutschmann wrote: https://wiki.gentoo.org/wiki/Project:Infrastructure/Generating_GLEP_63_based_OpenPGP_keys#Submit_your_new_key_to_the_keyserver And FWIW this sentence is a little misleading if the SKS refresh frequency is zero =) The SKS keyserver pool

Re: [gentoo-dev] GPG key refresh

2020-12-15 Thread Michael Orlitzky
On 12/15/20 10:27 AM, Thomas Deutschmann wrote: Hi, what exactly did you do already? Did you uploaded to our internal key server? You can only upload through dev.gentoo.org, see

Re: [gentoo-dev] GPG key refresh

2020-12-14 Thread Michael Orlitzky
On 12/14/20 2:17 PM, Alec Warner wrote: I think you need to push to hkps://keys.gentoo.org Ok, did that. The error message specifically states, remote: *** None of your keys comply with GLEP 63. and GLEP63 says to upload your keys to the SKS keyservers. Does the

[gentoo-dev] GPG key refresh

2020-12-14 Thread Michael Orlitzky
I'm still getting this, $ git push --signed ... remote: 1C49724D229E93A2 [Michael Orlitzky ] [E] expire:short Expiration date is too close, please renew (is 2020-12-26 23:30:47, less than 14 days) remote: 1C49724D229E93A2:6F48D3DA05C2DADB [Michael Orlitzky ] [E] expire:short

Re: [gentoo-dev] Slotted Lua: 2020-12-04 status update

2020-12-09 Thread Michael Orlitzky
On 12/9/20 10:10 AM, Marek Szuba wrote: LUA_DEPS itself will not but the change of LUA_SINGLE_TARGET in the package in question will, same way other packages can be rebuilt on USE-flag changes. So lua has inherited the python approach of requiring everyone to use portage? =/

Re: [gentoo-dev] Slotted Lua: 2020-12-04 status update

2020-12-09 Thread Michael Orlitzky
On 12/7/20 9:11 AM, Marek Szuba wrote: On 2020-12-04 13:16, Marek Szuba wrote: Since a week ago the number of open bugs blocking the slotted-Lua tracker has been reduced from 119 to under 80. Updated count as of a few minutes ago: 64 open tickets! Full list:

Re: [gentoo-dev] PSA: switching default tmpfiles virtual provider

2020-11-26 Thread Michael Orlitzky
On 11/26/20 5:57 PM, Thomas Deutschmann wrote: > > I disagree here: Packages installing tmpfiles configs requiring > recursive chown on each boot are doing something wrong from  my P.O.V. No argument there, but me thinking they're wrong doesn't stop people from doing it. > Note that hardlinks

Re: [gentoo-dev] PSA: switching default tmpfiles virtual provider

2020-11-26 Thread Michael Orlitzky
On 11/26/20 5:37 PM, Peter Stuge wrote: > Georgy Yakovlev wrote: >> I'll be switching default tmpfiles provider to sys-apps/systemd-tmpfiles >> by the end of the week by updating virtual/tmpfiles ebuild. > > Michael Orlitzky wrote: >> Corollary: the tmpfil

Re: [gentoo-dev] PSA: switching default tmpfiles virtual provider

2020-11-26 Thread Michael Orlitzky
On 11/26/20 10:07 AM, Thomas Deutschmann wrote: > > Only root is allowed to write to these directories. In other words: To > exploit this, a malicious local user (or a remote attacker who already > gained user access) would have to trick root into creating specially > crafted tmpfiles config

Re: [gentoo-dev] [PATCH 0/1] depend.apache.eclass: support EAPI-7

2020-11-03 Thread Michael Orlitzky
On 11/3/20 11:25 AM, Marek Szuba wrote: The fact this eclass does not support EAPI-7 yet blocks migration of www-apache/mod_security to Lua eclasses. Seems simple enough to address though, likely simpler than adding EAPI-6 support to lua.eclass. It's likely broken in EAPI=7, because it was in

Re: [gentoo-dev] [infra] Anti-spam changes: removal of malware patrol and other older ClamAV rules

2020-09-11 Thread Michael Orlitzky
On 2020-09-11 15:09, Robin H. Johnson wrote: > Hi, > > As a result of a recent high-impact [1] false positive spam detection in > Gentoo mail, we've disabled using the MalwarePatrol ruleset in Clamav > for spam detection for all inbound mail to @gentoo.org > All of these services produce killer

Re: [gentoo-dev] [PATCH] ebuild-maintenance/removal: Process for virtual removal

2020-09-07 Thread Michael Orlitzky
On 2020-09-07 08:47, Alessandro Barbieri wrote: > Being consistent in decision is hard I see. You're missing some context. In October of last year, a QA team member broke dependency resolution on a lot of systems by making the same sort of change that this patch proposes:

Re: [gentoo-dev] [PATCH] ebuild-maintenance/removal: Process for virtual removal

2020-09-07 Thread Michael Orlitzky
On 2020-09-07 08:10, Ulrich Mueller wrote: >> This has caused dependency resolution problems in the past. The PMS >> implies a new revision, > > PMS says nothing about new revisions or revision bumps: > That is indeed what the word "implies" implies. > The devmanual [1] says that a revbump

Re: [gentoo-dev] [PATCH] ebuild-maintenance/removal: Process for virtual removal

2020-09-07 Thread Michael Orlitzky
On 2020-09-07 02:14, Michał Górny wrote: > + > +Update all ebuilds not to reference the virtual. Since there is > +no urgent need to remove the virtual from user systems > +and the resulting rebuilds would be unnecessary, do not bump ebuilds > +when replacing the dependency. > +

Re: [gentoo-dev] Please port your packages to Python 3.8

2020-09-04 Thread Michael Orlitzky
On 2020-09-04 09:22, Rich Freeman wrote: > > Current Gentoo policy: > > ...if the changes are likely to cause problems for end users." If you're willing to ignore the user reports of problems, and ignore the mailing list threads telling you that it will cause problems, and avoid running any

Re: [gentoo-dev] Please port your packages to Python 3.8

2020-09-04 Thread Michael Orlitzky
On 2020-09-04 08:54, Alexis Ballier wrote: > > py37 will (*) still be installed as it cannot be depcleaned because of > 1. emerge won't fail since deps are satisfied. > > > (*) or rather should, but I think the only case that matters is a valid > system state where noone forced uninstall of a

Re: [gentoo-dev] Re: Please port your packages to Python 3.8

2020-09-04 Thread Michael Orlitzky
On 2020-09-04 04:39, Martin Vaeth wrote: > >> That's completely legal according to the PMS, and also the >> smart thing to do: > > s/smart/dumb/, but necessary for a dumb PM Word games notwithstanding, these are the package managers described by the PMS. >> sourcing a few thousand lines of

Re: [gentoo-dev] Please port your packages to Python 3.8

2020-09-03 Thread Michael Orlitzky
On 2020-09-03 12:38, Alexis Ballier wrote: > > if some upgrade wants a package with unmatched deps (e.g. not installed > at all or py38 usedep not satisfied), $PM will surely try to satisfy > it by installing an ebuild. I don't think PMS specifies this, nor should > it. > It's not an upgrade

Re: [gentoo-dev] Please port your packages to Python 3.8

2020-09-02 Thread Michael Orlitzky
On 2020-09-02 14:08, Andreas Sturmlechner wrote: > On Wednesday, 2 September 2020 19:42:33 CEST Michael Orlitzky wrote: >> New USE flags generally change dependencies (as is the case here), so a >> new revision ensures that people are forced to install the ebuild that >>

Re: [gentoo-dev] Please port your packages to Python 3.8

2020-09-02 Thread Michael Orlitzky
On 2020-09-02 13:23, Sam James wrote: > > Please request stabilisation of your Python 3.8+ changes at the 30 days > point, or earlier if it’s a trivial revbump > (as new Python targets are equivalent to new USE flags, there is no real need > for a revbump unless doing other tidying > whilst

Re: [gentoo-dev] RFC: pgo - a command line interface for packages.g.o

2020-09-01 Thread Michael Orlitzky
On 2020-09-01 08:38, Max Magorsch wrote: > Do you think this is something you would be interested in? Do you > have any features you like to see included in this case? Yes! Here's a trick that bugzilla cannot do: show me the bugs that are assigned to me **or a project that I'm a member of**.

[gentoo-portage-dev] [PATCH 1/1] Revert "repoman: deprecate netsurf.eclass."

2020-08-14 Thread Michael Orlitzky
-by: Michael Orlitzky --- repoman/lib/repoman/modules/linechecks/deprecated/inherit.py | 1 - 1 file changed, 1 deletion(-) diff --git a/repoman/lib/repoman/modules/linechecks/deprecated/inherit.py b/repoman/lib/repoman/modules/linechecks/deprecated/inherit.py index 60410347b..5848a0c37 100644

  1   2   3   4   5   6   7   8   9   >