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] [PATCH] profiles/default/linux: Add USE="bzip2 lzma zstd" to defaults

2021-07-08 Thread Michael Orlitzky
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? This list should be getting smaller, not larger. Polluting the base profiles makes running a minimal system that much harder, and only "adds no

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

Re: [gentoo-dev] xorg-x11 RDEPEND changes without revisions

2020-08-07 Thread Michael Orlitzky
On 2020-08-07 14:43, Toralf Förster wrote: > On 8/7/20 8:25 PM, Michael Orlitzky wrote: >> >> I have too many other things to do to waste time reverse-engineering >> these fuck-ups. Get it together. > > I'm just curious if you refer to commit d8c442ba8 - b/c that was ma

[gentoo-dev] xorg-x11 RDEPEND changes without revisions

2020-08-07 Thread Michael Orlitzky
When you ignore the devmanual and the pkgcheck warning and the 10+ threads I've started about the issue, and make changes like... --- a/x11-base/xorg-x11/xorg-x11-7.4-r3.ebuild +++ b/x11-base/xorg-x11/xorg-x11-7.4-r3.ebuild @@ -1,4 +1,4 @@ -# Copyright 1999-2018 Gentoo Foundation +#

Re: [gentoo-dev] How to set CXX compiler?

2020-07-03 Thread Michael Orlitzky
On 2020-07-03 18:35, Xianwen Chen (陈贤文) wrote: > > In the Makefile, it is written that > > cc = g++ > > I would like to use sed to patch it so that it ebuild knows which g++ to > use. For example, depending on whether ccache is set, ebuild shall know > whether to use ccache. First, you should

Re: [gentoo-dev] RFC: Standard build environment variables

2020-07-01 Thread Michael Orlitzky
On 2020-06-30 12:22, Matthew Thode wrote: > > I'd like to suggest allowing only approved variables in the build > environment, having portage unset all variables and setting only what is > needed (or configured). I think this is orthogonal to the problem I'm trying to solve. Even if all

[gentoo-dev] RFC: Standard build environment variables

2020-06-28 Thread Michael Orlitzky
As many of you probably know, ago@ has been expanding the scope of our CFLAGS/CC support to include some other common build variables: * CC * CXX * AR * CPP * NM * RANLIB * AS * LD Some of those are POSIX standards[0], * CC * AR Others are de-facto GNU make standards[1],

Re: [gentoo-dev] */*: Mask Py2 only packages

2020-06-25 Thread Michael Orlitzky
On 2020-06-24 16:08, Michał Górny wrote: > > $ git grep -l mgo...@gentoo.org '**/metadata.xml' | cut -d/ -f1-2 | > xargs gpy-py2 2>/dev/null > The big problem with this is that it misses any aliases (like graphics@) that you're a member of. But let's golf; this is POSIX sh, doesn't use grep to

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

2020-06-16 Thread Michael Orlitzky
can be put back into an eclass, and its consumers updated one-at-a-time. Bug: https://bugs.gentoo.org/489542 Bug: https://bugs.gentoo.org/637824 Signed-off-by: Michael Orlitzky --- repoman/lib/repoman/modules/linechecks/deprecated/inherit.py | 1 + 1 file changed, 1 insertion(+) diff --git

[gentoo-dev] Re: [PATCH] netsurf.eclass: remove EROOT from PREFIX

2020-06-16 Thread Michael Orlitzky
On 2020-06-14 16:30, a...@freemail.hu wrote: > > Suggested fix for: https://bugs.gentoo.org/show_bug.cgi?id=489542 > Bug 489542 - netsurf.eclass should not include EROOT in PREFIX > Well, I've applied this as well as some other fixes for the eclass, only to find that the problem has been

Re: [gentoo-portage-dev] [PATCH] Change BINPKG_COMPRESS default from bzip2 to xz

2020-04-26 Thread Michael Orlitzky
On 4/26/20 3:25 PM, Ulrich Mueller wrote: >>>>>> On Sun, 26 Apr 2020, Michael Orlitzky wrote: > >> Fuel for the fire: > >> * https://www.nongnu.org/lzip/lzip_benchmark.html >> * https://www.nongnu.org/lzip/xz_inadequate.html > > Yep. That's

Re: [gentoo-portage-dev] [PATCH] Change BINPKG_COMPRESS default from bzip2 to xz

2020-04-26 Thread Michael Orlitzky
On 4/26/20 12:55 PM, Matt Turner wrote: > Bug: https://bugs.gentoo.org/715108 > Signed-off-by: Matt Turner > --- > Strawman patch. Bikeshed away. > Fuel for the fire: * https://www.nongnu.org/lzip/lzip_benchmark.html * https://www.nongnu.org/lzip/xz_inadequate.html

Re: [gentoo-dev] Re: [PR] ivy, mvn, sbt, gradle builders improvement for ebuild development

2020-04-20 Thread Michael Orlitzky
On 4/20/20 5:48 PM, Georg Rudoy wrote: > >> I've learned the hard way that it discourages you from doing all the >> things that I just said high-quality software should do. > > Again, ranging from one-off pseudo-scripts that I had to come back to > after a couple of years, to quite complicated

Re: [gentoo-dev] Re: [PR] ivy, mvn, sbt, gradle builders improvement for ebuild development

2020-04-20 Thread Michael Orlitzky
On 4/20/20 5:25 PM, Patrick McLean wrote: > > Please explain how we are actively making things worse for you? We > are contributing useful packages to the tree, we are doing the work > and we are doing it in the way that makes the most effective use of > our time. We simply do not have time to be

Re: [gentoo-dev] Re: [PR] ivy, mvn, sbt, gradle builders improvement for ebuild development

2020-04-20 Thread Michael Orlitzky
On 4/20/20 5:05 PM, Georg Rudoy wrote: > >> If upstream absolutely insists on minor-version dependencies, then you >> either tolerate it conflicting with everything else, or leave it out of >> the tree. You probably shouldn't even be packaging a library whose API >> is distinguishable across

Re: [gentoo-dev] Re: [PR] ivy, mvn, sbt, gradle builders improvement for ebuild development

2020-04-20 Thread Michael Orlitzky
On 4/20/20 4:19 PM, Patrick McLean wrote: > > My co-workers are not the only ones adding/maintaining go packages in the > tree, please do not single out any groups, and let's all work to make Gentoo > the best it can be. > Everyone else is just using the eclass that your coworkers defended

Re: [gentoo-dev] Re: [PR] ivy, mvn, sbt, gradle builders improvement for ebuild development

2020-04-20 Thread Michael Orlitzky
On 4/20/20 4:21 PM, Georg Rudoy wrote: > вс, 19 апр. 2020 г. в 16:09, Michael Orlitzky : >> But please quit looking to Go as an example of anything >> anyone should be doing. > > On a somewhat related note, I'd like to take this chance to ask about > packaging has

Re: [gentoo-dev] Re: [PR] ivy, mvn, sbt, gradle builders improvement for ebuild development

2020-04-20 Thread Michael Orlitzky
On 4/20/20 2:58 PM, Patrick McLean wrote: >> >> You keep saying that, but the fact that dev-go/* is filled with trash >> that has your name on it prevents anyone else from doing a better job. >> > Ad-hominen attacks are unwarranted, please refrain from them. I challenge you > to find *anything*

Re: [gentoo-dev] Re: [PR] ivy, mvn, sbt, gradle builders improvement for ebuild development

2020-04-20 Thread Michael Orlitzky
On 4/20/20 1:31 PM, Patrick McLean wrote: >> Simply having things in ::gentoo does not affect anyone who does not use them. > You keep saying that, but the fact that dev-go/* is filled with trash that has your name on it prevents anyone else from doing a better job.

Re: [gentoo-dev] Re: [PR] ivy, mvn, sbt, gradle builders improvement for ebuild development

2020-04-19 Thread Michael Orlitzky
On 4/19/20 3:41 PM, Samuel Bernardo wrote: >> >> EGO_SUM is not a legitimate approach to packaging. You have to create >> packages for each package. I know, it sounds crazy when you say it. >> > I understand what you mean, but deem this dependencies as internal > project dependencies where those

[gentoo-dev] Re: [PR] ivy, mvn, sbt, gradle builders improvement for ebuild development

2020-04-19 Thread Michael Orlitzky
On 4/19/20 10:55 AM, Samuel Bernardo wrote: > > Taking into account the network sandbox requirement, sbt.eclass needs to > download all dependencies with some approach like EGO_SUM implementation > in go-module.eclass[1]. > EGO_SUM is not a legitimate approach to packaging. You have to create

Re: [gentoo-dev] [RFC] New global USE flag 'feedback'

2020-04-13 Thread Michael Orlitzky
On 4/13/20 10:58 AM, Andreas Sturmlechner wrote: > Going to be used by 10 packages. > > Description: "Send anonymized usage information to upstream so they can > better > understand our users" > These are all really generic words that might be used by other (non-QT/KDE) packages to mean

Re: [gentoo-dev] Package up for grabs: dev-libs/ppl

2020-04-13 Thread Michael Orlitzky
On 4/13/20 4:55 AM, Sergei Trofimovich wrote: > Single fresh test failure bug: https://bugs.gentoo.org/717258. I took it, there are some known arch-specific test failures on the upstream bug tracker that I'll try to temporarily patch out.

Re: [gentoo-dev] [RFC] KEYWORDREQ and STABLEREQ keywords

2020-04-11 Thread Michael Orlitzky
On 4/11/20 11:33 AM, Michał Górny wrote: > Hi, > > Now that we have proper components for keywording and stabilization, > the old keywords are redundant. Nevertheless, some people still set > them. I would like to propose two solutions going forward. Either: > > 1. We kill both keywords, and

[gentoo-dev] [PATCH 2/2] sci-libs/fflas-ffpack: new package for finite-field linear algebra.

2020-04-02 Thread Michael Orlitzky
48) using gcc-4.9.x that was never fully debugged. If the problems persist, we can revisit that report, or just mask the flag. Closes: https://bugs.gentoo.org/show_bug.cgi?id=715678 Package-Manager: Portage-2.3.89, Repoman-2.3.20 Signed-off-by: Michael Orlitzky --- sci-libs/fflas-ffpack/Manifest

[gentoo-dev] [PATCH 1/2] profiles/desc/cpu_flags_x86.desc: add avx512dq and avx512vl.

2020-04-02 Thread Michael Orlitzky
These two flags are already supported by cpuid2cpuflags, but so far no package in ::gentoo uses them. The forthcoming sci-libs/fflas-ffpack will use them, however, and -- given that they're CPU flags whose names are fixed -- it seems most sensible to add them globally right away. Bug:

[gentoo-dev] [PATCH 0/2] New x86 CPU flags and a package to use them.

2020-04-02 Thread Michael Orlitzky
Sending to the list because it adds two new global CPU flags, already supported by cpuid2cpuflags but not listed in the profiles yet. Michael Orlitzky (2): profiles/desc/cpu_flags_x86.desc: add avx512dq and avx512vl. sci-libs/fflas-ffpack: new package for finite-field linear algebra

Re: [gentoo-dev] network sandbox challenge

2020-04-01 Thread Michael Orlitzky
On 4/1/20 4:03 PM, Samuel Bernardo wrote: > > Couldn't security issue in a Go library be solved with keyword mask and > announce in portage? If there's an ebuild for the library, then yeah, you've got the right idea. But with the Go eclasses, there are no ebuilds for any of the dependencies.

Re: [gentoo-dev] network sandbox challenge

2020-04-01 Thread Michael Orlitzky
On 4/1/20 11:49 AM, Alec Warner wrote: > Imagine a common dep (CommonFoo-x-y-z) > has a security problem, so we must upgrade to CommonFoo-y-z. In the > scenario where CommonFoo is a dynamically linked package we can > recompile it once[4] and new consumers will just use the new dynamic > shared

Re: [gentoo-dev] network sandbox challenge

2020-04-01 Thread Michael Orlitzky
On 4/1/20 1:36 AM, Robin H. Johnson wrote: > mjo: Can you please substantiate your claims? > > It would have been nice to have heard your concerns during February, any > of one the three times that William and I posted the go-module.eclass > EGO_SUM development work for review on this mailing

Re: [gentoo-dev] network sandbox challenge

2020-03-31 Thread Michael Orlitzky
On 3/31/20 8:48 PM, Samuel Bernardo wrote: > > My question started with the network sandbox issue when we need to load > external code dependencies. For example, a go project will download all > dependencies from git repositories that will happen after src_unpack. In > this case I need to add an

Re: [gentoo-dev] network sandbox challenge

2020-03-31 Thread Michael Orlitzky
On 3/31/20 6:21 PM, Samuel Bernardo wrote: > > But after your explanation, I understand now that mirror types provides > alias to use in ebuild SRC_URI, specially useful for the update task > (awesome). > Beware: thirdpartymirrors doesn't really do anything useful for normal ebuilds in

Re: [gentoo-dev] Last rites: dev-ruby/rails:4.2 and related packages, including net-analyzer/metasploit

2020-03-30 Thread Michael Orlitzky
On 3/29/20 1:35 PM, Hans de Graaff wrote: > # Migrate to Rails 5.2. And here I was, thinking I knew what the worst thing to happen in 2020 was going to be.

Re: [gentoo-dev] rfc: noarch keyword

2020-03-19 Thread Michael Orlitzky
On 3/18/20 10:54 AM, William Hubbs wrote: > > So, my question is, why can't we add a noarch/~noarch keyword and see > how things go? If it gets abused we can always nuke it later. > This is a good goal, but as others have pointed out, adding a new magic keyword poses some workflow problems. We

Re: [gentoo-dev] Last rites: virtual/cargo

2020-01-26 Thread Michael Orlitzky
On 1/26/20 9:46 PM, Georgy Yakovlev wrote: > # update your rust packages running emerge with the > # --changed-deps option if you have problems If this advice helps, you have violated the PMS.

Re: [gentoo-dev] [PATCH 0/2] allow acct-user home directories in /home

2020-01-21 Thread Michael Orlitzky
On 1/21/20 6:44 AM, Jaco Kroon wrote: > > There is technically no real issue, but it's the right thing to do. > > Right, motivations for your proposal for allowing this: > > * You want it. > > Motivations against: > This is dishonest. "I want it" because it improves some things for our

Re: [gentoo-dev] [PATCH 2/2] install-qa-check.d: allow acct-user home directories under /home.

2020-01-20 Thread Michael Orlitzky
Let it die =) I'm not going to apply the patch; it's there if someone else decides that it's the least-bad solution to this problem. On 1/20/20 6:57 PM, Andreas K. Huettel wrote: > > Why *isn't* some /var/lib/... possible here? It is, the question is how many backflips we should be doing to

Re: [gentoo-dev] [PATCH 0/2] allow acct-user home directories in /home

2020-01-20 Thread Michael Orlitzky
On 1/20/20 5:08 PM, Alec Warner wrote: > > So I can describe in detail one example, but its not running Gentoo; so > I'm not sure if you care in practice. Yes, I'm happy to see a real example. > At work we had sec=krb5 NFS v3 mounted home directories. They were > mounted in /home (via the

Re: [gentoo-dev] [PATCH 0/2] allow acct-user home directories in /home

2020-01-20 Thread Michael Orlitzky
On 1/20/20 1:39 PM, Michał Górny wrote: > > I'm going to be blunt. We arbitrarily made a decision that /home > belongs to sysadmin. Please respect that. If you really believe your > package is *this* special to justify changing this arbitrary decision, > the burden of proof lies on you. >

Re: [gentoo-dev] [PATCH 0/2] allow acct-user home directories in /home

2020-01-20 Thread Michael Orlitzky
On 1/20/20 1:01 PM, Ulrich Mueller wrote: > > It's just awful to have a one user at second level (like /home/amavis) > when all others are at third level (like /home/staff/joe). > Finally an honest argument =) I agree. But all we're doing is choosing the default here. GLEP81 lets the user

Re: [gentoo-dev] moving uid-gid.txt to metadata

2020-01-20 Thread Michael Orlitzky
On 1/20/20 11:57 AM, William Hubbs wrote: > > Imo a better fit is the metadata directory in the ebuild repository. > That way you can add users/groups along with the acct-* packages that > install them. What benefit is there to syncing that file to everyone's machines?

  1   2   3   4   5   6   7   8   9   >