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?

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

2020-01-20 Thread Michael Orlitzky
On 1/20/20 9:50 AM, David Seifert wrote: > > Rich has given reasons, ulm has, and mgorny suggested a solution. > Everyone's real intent on saying that there are problems without actually typing what those problems are into the email box. We're talking about a single keepdir file here. Please

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

2020-01-20 Thread Michael Orlitzky
On 1/20/20 2:02 AM, Ulrich Mueller wrote: >>>>>> On Mon, 20 Jan 2020, Michael Orlitzky wrote: > >> install-qa-check.d: allow acct-user home directories under /home. > > Nope. As you've been told, /home is site specific and can be setup in > multiple ways th

Re: [gentoo-dev] GLEP81 and /home

2020-01-19 Thread Michael Orlitzky
On 1/19/20 10:40 PM, Rich Freeman wrote: > On Sun, Jan 19, 2020 at 10:16 PM Michael Orlitzky wrote: >> >> This is retarded, stop wasting my time. >> > > There is nothing retarded about shared /home directories. They're > pretty common in the real world. > What

[gentoo-dev] [PATCH 1/2] install-qa-check.d: disallow "nix" and "gnu" as top-level paths.

2020-01-19 Thread Michael Orlitzky
These exceptions were made for the sys-apps/nix and sys-apps/guix packages that are no longer in the tree. --- metadata/install-qa-check.d/08gentoo-paths | 2 -- 1 file changed, 2 deletions(-) diff --git a/metadata/install-qa-check.d/08gentoo-paths b/metadata/install-qa-check.d/08gentoo-paths

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

2020-01-19 Thread Michael Orlitzky
In rare cases, a system user will need a real home directory to store per-user configuration data and/or be accessed interactively by a human being. In those cases, /home/${username} is an appropriate place for the user's home directory. Using /home is allowed and encouraged by the FHS, and there

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

2020-01-19 Thread Michael Orlitzky
It's late and I'm sure this is buggy, but just complaining about it isn't getting me anywhere. Michael Orlitzky (2): install-qa-check.d: disallow "nix" and "gnu" as top-level paths. install-qa-check.d: allow acct-user home directories under /home. metadata/install-qa-ch

Re: [gentoo-dev] GLEP81 and /home

2020-01-19 Thread Michael Orlitzky
On 1/19/20 9:52 PM, Rich Freeman wrote: >> >> Fantasy scenarios again. I'm not going to debunk a system that you just >> thought up and that has never existed. Why don't you find one person who >> actually does this, and see if it bothers him if we create a home >> directory under /home where it

Re: [gentoo-dev] GLEP81 and /home

2020-01-19 Thread Michael Orlitzky
On 1/19/20 8:20 PM, Rich Freeman wrote: > It would be far simpler for the sysadmin to simply ensure that no > unsynced user owns a file or appears in an ACL. That would be pretty > trivial to achieve. Whatever is hosting /home could be designed to > block such changes, or you could just scan for

Re: [gentoo-dev] GLEP81 and /home

2020-01-19 Thread Michael Orlitzky
On 1/19/20 4:00 PM, Michael Orlitzky wrote: > > If I was willing to introduce a QA warning, this thread would have been > a lot shorter =P > Just kidding, the eclass is rigged to die in src_install if you delete the home directory, and if you wait until pkg_preinst, the warnin

Re: [gentoo-dev] GLEP81 and /home

2020-01-19 Thread Michael Orlitzky
On 1/19/20 2:47 PM, Rich Freeman wrote: > > Obviously the UIDs associated with the shared /home need to be > identical. Simplest solution is to sync anything > 1000 in > /etc/passwd, and then not allow UIDs below 1000 in /home. A cron job > could easily handle both, and of course regular users

Re: [gentoo-dev] GLEP81 and /home

2020-01-19 Thread Michael Orlitzky
On 1/19/20 2:32 PM, Alec Warner wrote: > > Earlier you wrote: > >  * The daemon DOES NOT need a home directory for its user. >   * I DO NOT want to install anything to anyone's home directory. >   * With respect to user.eclass, I'm proposing that /home be treated >     EXACTLY THE SAME as it

Re: [gentoo-dev] GLEP81 and /home

2020-01-19 Thread Michael Orlitzky
On 1/19/20 2:19 PM, Alec Warner wrote: > > All I want to do is *set* a user's home directory to /home/foo. > > Why wouldn't you set the homedirectory to /dev/null then? > Because /dev/null is not /home/foo? Is this a trick question? =)

Re: [gentoo-dev] GLEP81 and /home

2020-01-19 Thread Michael Orlitzky
On 1/19/20 2:02 PM, Rich Freeman wrote: > >> If you're sharing /home, you also have to be sharing user accounts, >> unless you want everyone to be assigned a random set of files. > > I imagine that most people setting up something like this would only > be sharing high-value UIDs (>1000 in our

Re: [gentoo-dev] GLEP81 and /home

2020-01-19 Thread Michael Orlitzky
On 1/19/20 12:42 PM, Rich Freeman wrote: > > Typically you wouldn't share service accounts across multiple hosts. > I'd think that something like amavisd is going to go on a mail server. > You're not going to be logging into that account to do typical > desktop-oriented functions. > > If you had

Re: [gentoo-dev] GLEP81 and /home

2020-01-19 Thread Michael Orlitzky
On 1/19/20 6:29 AM, Rich Freeman wrote: > > Daemons are local users. There is no guarantee that /home is a local > filesystem. Heck, there is no guarantee that /home is even mounted > when portage is running. Portage shouldn't be touching /home at all. > With stuff like automounted or

Re: [gentoo-dev] GLEP81 and /home

2020-01-18 Thread Michael Orlitzky
On 1/18/20 7:21 PM, Rich Freeman wrote: > On Sat, Jan 18, 2020 at 6:38 PM Michael Orlitzky wrote: >> >> But now users have to follow one more step (create /home/amavis) when >> setting up amavisd-new. Is the QA check really assuring a quality user >> experience here? &

Re: [gentoo-dev] GLEP81 and /home

2020-01-18 Thread Michael Orlitzky
On 1/18/20 1:10 PM, Ulrich Mueller wrote: > >> Should option (3) be viable, or do I go back to the drawing board? > > Chances are that /home is site specific, e.g. with a special backup > policy, or shared between many hosts via NFS. So IMHO /home is off > limits for the package manager. > We

Re: [gentoo-dev] GLEP81 and /home

2020-01-18 Thread Michael Orlitzky
On 1/18/20 2:03 PM, Alec Warner wrote: > > I tend to agree that in theory keeping the working directory and home > directory the same is not ideal. However  I'm not really aware of any > practical problems. Haven't we basically run in this configuration for > years? What kind of issues does it

Re: [gentoo-dev] GLEP81 and /home

2020-01-18 Thread Michael Orlitzky
On 1/18/20 2:08 PM, Michał Górny wrote: > > Sounds like you've created an arbitrary rule that prevents the two > packages from using the same directory, and therefore you've created > this problem yourself. Why not just go back and reconsider using > the same directory instead of adding

[gentoo-dev] GLEP81 and /home

2020-01-18 Thread Michael Orlitzky
We forbid packages from installing to /home for good reason: for most of history, users (and their home directories) were outside the purview of the package manager. But with GLEP81, that's changed: the package manager is now in charge of creating each system user's home directory and of giving it

Re: [gentoo-dev] Vanilla sources

2020-01-05 Thread Michael Orlitzky
On 1/4/20 2:13 PM, Rolf Eike Beer wrote: > > Bad idea. If you wonder why: eshowkw dev-lang/rust. > Or consider that every rust package in Gentoo bundles hundreds of libraries. We'd be fixing one security issue by introducing 10x more. Not that rewriting it in rust would fix anything; writing

Re: [gentoo-dev] Vanilla sources

2020-01-03 Thread Michael Orlitzky
On 1/3/20 9:52 AM, Michael Orlitzky wrote: > > But here we are. Do we make OpenRC Linux-only and steal the fix from > systemd? Or pretend to support other operating systems, but leave them > insecure? > Or the gripping hand: rewrite opentmpfiles in C, so that it's only as insecu

Re: [gentoo-dev] Vanilla sources

2020-01-03 Thread Michael Orlitzky
On 1/3/20 9:46 AM, Rich Freeman wrote: > > ... > > In any case this seems more like an OpenRC issue than a Gentoo issue. > It's a specification issue. There's no way to implement tmpfiles safely on a POSIX system, and opentmpfiles shouldn't exist if OpenRC wants to work on anything other than

Re: [gentoo-dev] Vanilla sources

2020-01-03 Thread Michael Orlitzky
On 1/3/20 9:40 AM, Toralf Förster wrote: > On 1/3/20 3:37 PM, Michael Orlitzky wrote: >> The gentoo-sources aren't 100% safe either, but the exploitable scenario >> is less common thanks to fs.protected_{hardlinks,symlinks}=1. > > But this can be easily achieved w/o inst

Re: [gentoo-dev] Vanilla sources

2020-01-03 Thread Michael Orlitzky
On 1/2/20 6:35 PM, Rolf Eike Beer wrote: > > I only run vanilla-sources since there are still lot of cache corruption > problems in hppa kernels, or whatever makes them flaky. The vanilla-sources are unsafe to use on Gentoo. Many services have stupid-easy root exploits, since we install

Re: [gentoo-dev] [PATCH 2/4] acct-user/jenkins: Add jenkins user, UID 473

2019-12-26 Thread Michael Orlitzky
On 12/26/19 11:56 AM, Thomas Deutschmann wrote: > > Why can't I use rm, mv, cp or text editor to change things? If you change a file belonging to a system package, then the next time you upgrade or reinstall that package, your changes get overwritten. > System configuration management is

Re: [gentoo-dev] [PATCH 2/4] acct-user/jenkins: Add jenkins user, UID 473

2019-12-26 Thread Michael Orlitzky
On 12/26/19 9:41 AM, Thomas Deutschmann wrote: > > which would remove nginx from myapp group to match ACCT_USER_GROUPS set > in acct-*/nginx ebuild which would break my application server. Does > that really happen? Yes; if we want to be able to add/remove groups in acct-user ebuilds, then

Re: [gentoo-dev] [PATCH 2/4] acct-user/jenkins: Add jenkins user, UID 473

2019-12-26 Thread Michael Orlitzky
On 12/26/19 8:28 AM, Thomas Deutschmann wrote: > On 2019-12-26 12:04, Michael Orlitzky wrote: >> On 12/25/19 10:11 AM, Thomas Deutschmann wrote: >>> +ACCT_USER_HOME=/var/lib/jenkins >> Needed? > > I cannot answer that for sure. In *my* setups I need a valid home fo

Re: [gentoo-dev] [PATCH 2/4] acct-user/jenkins: Add jenkins user, UID 473

2019-12-26 Thread Michael Orlitzky
On 12/25/19 10:11 AM, Thomas Deutschmann wrote: > +ACCT_USER_HOME=/var/lib/jenkins Needed?

Re: [gentoo-dev] [PATCH 0/3] elisp{,-common}.eclass update for emacs-vcs consolidation

2019-12-21 Thread Michael Orlitzky
On 12/21/19 6:39 AM, Ulrich Mueller wrote: >>>>>> On Sat, 21 Dec 2019, Michael Orlitzky wrote: > >> I was being safe, and assuming that your standards for shell scripting >> are as low as your standards for tree quality. > > Nice, resorting to

Re: [gentoo-dev] [PATCH 0/3] elisp{,-common}.eclass update for emacs-vcs consolidation

2019-12-21 Thread Michael Orlitzky
On 12/21/19 6:39 AM, Ulrich Mueller wrote: >>>>>> On Sat, 21 Dec 2019, Michael Orlitzky wrote: > >> I was being safe, and assuming that your standards for shell scripting >> are as low as your standards for tree quality. > > Nice, resorting to a personal a

Re: [gentoo-dev] [PATCH 0/3] elisp{,-common}.eclass update for emacs-vcs consolidation

2019-12-21 Thread Michael Orlitzky
On 12/21/19 1:57 AM, Ulrich Mueller wrote: > > See? You say it yourself, with 400 revbumps there is quite some chance > for breakage. > I was being safe, and assuming that your standards for shell scripting are as low as your standards for tree quality.

Re: [gentoo-dev] [PATCH 0/3] elisp{,-common}.eclass update for emacs-vcs consolidation

2019-12-19 Thread Michael Orlitzky
On 12/18/19 6:28 PM, Michael Orlitzky wrote: > > This *does* happen if you mask virtual/emacs. It *could* happen if you > delete it. > I tested this out. Portage seems OK with the missing dependency, but for the overall plan to work, you have to wait a long time before deleting v

Re: [gentoo-dev] Needs ideas: Upcoming circular dependency: expat <> CMake

2019-12-19 Thread Michael Orlitzky
On 12/19/19 12:37 PM, Michał Górny wrote: > > Just because someone did something crappy, it doesn't mean it was > considered 'good enough'. It was just a cheap hack that someone once > did just to get it over with and stop caring. Not a good solution we > should keep copying. > These should

Re: [gentoo-dev] Needs ideas: Upcoming circular dependency: expat <> CMake

2019-12-18 Thread Michael Orlitzky
On 12/18/19 4:02 PM, Sebastian Pipping wrote: > Hi all, > > > I noticed that dev-util/cmake depends on dev-libs/expat and that > libexpat upstream (where I'm involved) is in the process of > dropping GNU Autotools altogether in favor of CMake in the near future, > potentially the next release

Re: [gentoo-dev] [PATCH 0/3] elisp{,-common}.eclass update for emacs-vcs consolidation

2019-12-18 Thread Michael Orlitzky
On 12/18/19 11:34 AM, Ulrich Mueller wrote: > > Removal of the virtual/emacs ebuilds won't remove the installed package > from users' systems. It will eventually disappear, when all its reverse > dependencies have been updated. Why would its continued presence as an > installed package (for

Re: [gentoo-dev] [PATCH 0/3] elisp{,-common}.eclass update for emacs-vcs consolidation

2019-12-18 Thread Michael Orlitzky
On 12/18/19 6:08 AM, Ulrich Müller wrote: > No revbumps will be done for this (and virtual/emacs will be simply > removed without prior masking). I guess it's nice that we know ahead of time, but is there any reason to suspect that this won't cause havoc?

Re: [gentoo-dev] RFC: acct-user/... modifies existing user sometimes

2019-12-15 Thread Michael Orlitzky
On 12/14/19 5:02 PM, Thomas Deutschmann wrote: > > acct-* shouldn't mess with already *existing* users. So upgrade > experience shouldn't be affected... Even on upgrades, pkg_postinst() in acct-user.eclass will update the home directory, shell, groups, and comment field. Without more

Re: [gentoo-dev] RFC: acct-{user,group} for milter (438)

2019-12-15 Thread Michael Orlitzky
On 12/15/19 9:46 AM, Ralph Seichter wrote: > > Milter-regex only needs a user to isolate the process and it's single > configuration file (/etc/milter-regex.conf). My PR adds acct-user/milter > without a home directory, because milter-regex does not need one, nor > does it write anything to disk.

Re: [gentoo-dev] RFC: acct-{user,group} for milter (438)

2019-12-14 Thread Michael Orlitzky
On 12/14/19 11:53 PM, Ralph Seichter wrote: Of the three packages you mentioned, milter-regex (not regex-milter) is the only one with a name that actually contains "milter". OpenDMARC should never have user a user named milter in the first place, and in the future it should use "opendmarc".

Re: [gentoo-dev] RFC: acct-{user,group} for milter (438)

2019-12-14 Thread Michael Orlitzky
On 12/13/19 4:17 PM, Ralph Seichter wrote: The mail-filter/milter-regex ebuild already uses user/group 'milter', and for the currently open bump to version 2.7 I'd like to claim GID/UID 438. I recently cited the "milter" user on this list as a bad example from the user.eclass days... it was

Re: [gentoo-portage-dev] [PATCH] eapply: Drop -s option for patch.

2019-12-13 Thread Michael Orlitzky
On 12/13/19 9:28 AM, Fabian Groffen wrote: > > We are providing those patches, maybe. In reality very often the > patches originate from somewhere else though. And you don't want to > have to respin all of those just because. At least that's what I feel. > Just because... the context

Re: [gentoo-portage-dev] [PATCH] eapply: Drop -s option for patch.

2019-12-12 Thread Michael Orlitzky
On 12/12/19 3:15 PM, Ulrich Mueller wrote: > > It was also suggested that we add -F0 in EAPI 8, but that would break > the build in those cases that are producing extra output now. I don't > think that would be preferable. It would only break the build for the maintainer, who would then

Re: [gentoo-dev] [PATCH 2/2] acct-user/suricata: new user for UID 477

2019-12-11 Thread Michael Orlitzky
On 12/11/19 8:45 AM, Marek Szuba wrote: > +ACCT_USER_HOME=/var/lib/suricata > +ACCT_USER_HOME_PERMS=0750 Please don't set these unless it's absolutely necessary. The rationale for this has finally been committed to the devmanual, but has yet to be pushed to the website. In the meantime it's

Re: [gentoo-dev] [RFC] Revisiting GLEP 81 (acct-*) policies (reviews, cross-distro syncing)

2019-12-10 Thread Michael Orlitzky
On 12/10/19 11:05 AM, Joonas Niilola wrote: > > I was more thinking along sys admins being able to modify their acct- > ebuilds with static numbers. If you're bind-mounting already, why not > bind your portage (or local overlay) to children as well. 2 minute more > work for those who need it, but

Re: [gentoo-dev] [RFC] Revisiting GLEP 81 (acct-*) policies (reviews, cross-distro syncing)

2019-12-10 Thread Michael Orlitzky
On 12/9/19 3:17 AM, Michał Górny wrote: > > 2. Mailing list reviews don't serve their original purpose. > > The original purpose of mailing list reviews was to verify that > the developers use new packages correctly. For example, Michael > Orlitzky has found a lot o

Re: [gentoo-dev] [RFC] Revisiting GLEP 81 (acct-*) policies (reviews, cross-distro syncing)

2019-12-10 Thread Michael Orlitzky
On 12/9/19 3:10 PM, Thomas Deutschmann wrote: > On 2019-12-09 19:48, Ulrich Mueller wrote: >>> On Mon, 09 Dec 2019, Thomas Deutschmann wrote: >> >>> Like said, if an ID is already taken for any reason on user's system, >>> that's not a problem. acct-* can handle that... there's nothing like a

Re: [gentoo-dev] [PATCH] package.deprecated: Create initial template

2019-12-06 Thread Michael Orlitzky
On 12/6/19 11:29 AM, Alexis Ballier wrote: > > Without good integration from the checker it is probably a PITA to > figure out that 23 too If you're reading through your commit log and if you see something wrong, you can $ git rebase -i to do a rebase starting at the one you'd like to fix.

Re: [gentoo-dev] RFC: UID/GID rspamd

2019-12-03 Thread Michael Orlitzky
On 12/3/19 5:41 AM, Petr Vaněk wrote: > > Btw, I am just curios about the situation when there is a foo overlay > with acct-{user,group}/foo using UID/GID already set in main gentoo > overlay and later on we would like to move it to the main gentoo > overlay. It would be necessary to chose

  1   2   3   4   5   6   7   8   9   >