Re: [gentoo-dev] New USE_EXPAND: POSTGRES_TARGETS

On 01/24/2016 06:21 PM, Aaron W. Swenson wrote: > Attached are the changes I'm looking to make. I've never play with > global use flags, so I'd like for somebody to make sure I've done them > right. > Tiny typo "postges.eclass".

Re: [gentoo-dev] New Eclasses: postgres and postgres-multi

On 01/24/2016 06:29 PM, Aaron W. Swenson wrote: > Okay, provided that the new USE_EXPAND is okay for POSTGRES_TARGETS, > attached are the eclasses that I'll commit to the tree. > > case ${EAPI:-0} in > 0|1|2|3|4) die "postgres-multi.eclass requires EAPI 5 or higher" ;; > *) ;; > esac Does th

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

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] network sandbox challenge

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 ::gentoo.

Re: [gentoo-dev] network sandbox challenge

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 a

Re: [gentoo-dev] network sandbox challenge

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 lis

Re: [gentoo-dev] network sandbox challenge

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 obj

Re: [gentoo-dev] network sandbox challenge

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.

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

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: https://bugs

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

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

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

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

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

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 j

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

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] New global USE flag 'feedback'

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 totall

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

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 pa

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

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 li

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

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

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* in

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

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 > packagin

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

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 and

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

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 minor

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

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

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 pi

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

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 relocat

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

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 p

[gentoo-dev] RFC: Standard build environment variables

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] RFC: Standard build environment variables

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 environme

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

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 s

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

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 +# Copy

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

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 w

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

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**. Kil

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

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 ther

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

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

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 per

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

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 bash

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

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 ne

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

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 tes

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

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] [PATCH] ebuild-maintenance/removal: Process for virtual removal

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 sho

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

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: https://archives.gentoo.

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

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 0/1] depend.apache.eclass: support EAPI-7

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] PSA: switching default tmpfiles virtual provider

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 allow

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

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 tmpf

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

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 a

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

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: https://dev.gentoo.org/~marecki/o

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

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? =/

[gentoo-dev] GPG key refresh

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:

Re: [gentoo-dev] GPG key refresh

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 G

Re: [gentoo-dev] GPG key refresh

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 https://wiki.gentoo.org/wiki/Project:Infrastructure/Generating_GLEP_63_based_OpenPGP_keys#Submit_your_new_key_to_the_

Re: [gentoo-dev] GPG key refresh

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 can

Re: [gentoo-dev] GPG key refresh

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" st

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

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 upstrea

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

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 th

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

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. An

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

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 /usr/$(get

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

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 - https://github.com/TACC/Lmod/commit/0913bf05dd7e8f478f69d5297e26d744d

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

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 i

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

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 only

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

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 hav

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

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 i

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

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] Re: [PATCH] acct-user.eclass: don't modify existing user by default

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 imp

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

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

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 perm

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

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 thi

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

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 p

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

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] dev-python/cryptography to use rust, effectively killing alpha, hppa, ia64, m68k, s390

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] Re: portage reliance on GNU objcopy ownership perseverance behavior in strip

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] Re: portage reliance on GNU objcopy ownership perseverance behavior in strip

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 stri

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

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] New tool: merge-driver-ekeyword automatically resolves git merge conflicts involving KEYWORDS=...

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 sing

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

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 > &g

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

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. Probabl

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

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] [PATCH v2 3/3] gnuconfig.eclass: use BDEPEND, BROOT where available (drop support for EAPI <4)

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] [PATCH v2 3/3] gnuconfig.eclass: use BDEPEND, BROOT where available (drop support for EAPI <4)

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 bootstr

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

> > 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 so

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

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 t

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

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

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 compiler

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

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 depe

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

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

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

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 th

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

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] 2021-07-09-systemd-tmpfiles: re-add news item

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 should

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

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? Con

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

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 p

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

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.

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

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 02/44] apache-module.eclass: Set @PROVIDES

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 s

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

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 itsel

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

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

[gentoo-dev] Common Lisp project is empty

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 dev-lisp/fle

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

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 &

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

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 suggestions,

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

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 c

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

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, pe

<    4   5   6   7   8   9   10   >