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 so, we could just list them all.






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 bootstrap package?

There is some chicken-and-egg problem to be solved, but I don't think
that we should be assuming that e.g. GNU grep is always present just
because, during the base case of some recursive process, POSIX grep
must be available temporarily.

Anyway, https://bugs.gentoo.org/485356 awaits reopening if you make any
progress on this.





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-separated. Probably only
> > repoman/pkgcheck would require trivial changes.
> 
> No, there are other tools as well, e.g. ekeyword and ebuild-mode.
> 

But only repoman/pkgcheck should be enforcing ::gentoo QA policy. The
others are already buggy if they don't support newlines and should be
fixed independently. Then GOTO 1: only repoman/pkgcheck require trivial
updates.





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. Probably only
repoman/pkgcheck would require trivial changes. Anything not enforcing
::gentoo policy should (ha ha) already support the PMS format.





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 first place?
> 
> Why don't we change 30 thousand ebuilds rather than use this script?
> 

If we're going to enforce a format, it makes more sense to sed things
into the easy format once than it does to leave things in the hard
format forever and maintain a custom tool that makes the hard format
more like the easy format.

With everything currently on one line, QA could easy change them all at
once in one big commit.





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 single line,

Is that enforced? If not, will the merge driver handle other formats
correctly? And if it is... why don't we just enforce putting each
keyword on a separate line instead, so that we don't have this problem
in the first place?





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 stripping.
> 
> We found this issue in Chrome OS when we tried to switch the defaults to
> llvm's objcopy/strip.

Thanks, I still agree that some consistent behavior is needed. The only
reason I asked is because the fact that you *noticed* the problem is a
red flag to me. A suid group is a valid use case, but a few of these
examples don't set any special group permissions on the executables
whose group they change. For example...

> ./net-analyzer/netselect/netselect-.ebuild: fowners root:wheel
> /usr/bin/netselect

This ebuild does,

  fowners root:wheel /usr/bin/netselect
  fperms 4711 /usr/bin/netselect

which makes you wonder why it changed the group in the first place. The
ebuilds for mail-filter/procmail and games-arcade/xboing are also
suspect.





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 my reply is
> missing)
> 

Apologies for hijacking your post with a tangential question, but you
reminded me to ask: how did you notice this problem? Ultimately all
system executables (in $PATH) should be owned by (and writable only by)
root anyway; otherwise you get silly security vulnerabilities like "cat
~/virus > /usr/bin/foo" as a regular user.





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 be able to retain minor keywords a lot of packages
> > without too much pain.
> 
> I could feel the pain.  
> 
> Bootstraping Rust on Prefix is somewhere between alpha, hppa, ia64,
> m68k, s390 and amd64[1].  The problem was exposed by
> gnome-base/librsvg[2].
> 
> I am wondering how useable pkgcore is on alpha, hppa, etc.  Maybe it's
> time for us to plan for a Gentoo without essential Python dependency.

It's not usable anywhere. We keep updating the PMS, and the council
keeps voting to approve the new versions, and we teach all new
developers that they need to respect both the PMS and council
decisions... and then from that day on, everyone completely, publicly,
ignores it, adding thousands of packages across entire ecosystems that
don't work properly without portage. I'd like to say it's one of the
craziest things I've ever seen, but, there was 2020.

We "started" with three package managers, and now we're down to one.
The council needs to grow some balls and enforce the PMS before that
can change. Pkgcore could be salvaged if you could actually update your
system with it.

For my "me too," I've been told by upstream that the next major version
of clamav will require rust. There are a lot of "real" UNIX machines
relying on clamav for e.g. PCI compliance that will be screwed by that,
not to mention all of the small business routers and mail gateways on
obscure or limited hardware. Personally, I just haven't spent the last
20 years contributing to free software to be casually migrated to a
system of bundled binary blobs; nor am I able to set aside 8GB of RAM
for hours to rebuild the latest version of rust and its myriad
unofficial dependencies every day on a production mail server.
Eventually clamav will disappear, and we'll likely move a few big
customers to Microsoft O365 as a result.





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

Not only that, but you will be dropping support for at least two of my
machines that are literally incapable of building the 10+ GiB bundled
rust package due to the amount of disk space and RAM required.





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 probably safe in portage because the temporary directory is no
longer user-accessible, but it seems perverse to seek feature parity by
adding the security vulnerability into the implementations that don't
have it, rather than by removing it from the ones that do. Hopefully
LLVM just accepts the patch.





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 this ofc doesn't guarantee that people will do
> things
> right, it will at least make it clear that these packages are
> somewhat
> different from regular virtuals and hopefully avoid making wrong
> assumptions.
> 
> 

I would go all the way and move (say) the libjpeg provider to media-
libs/libjpeg.





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 permissions."
Any package depending on a new revision of an acct-user ebuild to change 
its home directory is broken.


This was the exact problem I was trying to avoid while you made rude 
comments about how I was wasting everyone's time =P




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 implement this with something like an /etc/users.d directory 
that would be populated with entries by either the admin or package 
manager with CONFIG_PROTECT enabled. Then the system database would be 
updated by running something like "users-update" (cf. env-update). The 
essential problem that we need to work around is that e.g. /etc/passwd 
is "owned" by multiple system packages.


I think this would accomplish what you and Robin are talking about, but 
it wouldn't solve whissi's problem since it's still a Gentoo-specific 
solution.




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 need customization, fork the
user/group ebuild in your overlay" we will disconnect these users from
future changes.


There's pretty much no reason to change a user's settings unless you've 
completely fucked them up the first time around. This is precisely why 
the original GLEP had mailing list reviews.


If a package depends on a user having e.g. a specific home directory so 
that upgrading the package requires a corresponding revision bump of the 
user, then the package is broken. I tried really hard to document this, 
and to enforce it back when we had mailing list reviews. It's all in the 
devmanual now.




...
When you will get LPIC certification one can expect that you have some
basic knowledge in Linux stuff allowing you to do common tasks on all
different Linux systems. Now there comes Gentoo where you aren't allowed
to use standard Linux tools like 'usermod' when deploying another
service if you don't want to risk that your service will go down when
following best practice and do regular world upgrades. Really?


You also can't use the standard linux tools to edit scripts in /usr/bin 
without your changes being overwritten. This is no different... some 
things need to belong to the package manager if you want package 
management to work.




3) More important, the idea of forking acct-* packages whenever you need
to make modifications don't scale. Like I already outlined in February
2020, you cannot create overlays for each different user configuration:

I.e. using memcached/redis: You grant permission to socket via group. So
you put other services belonging to that application you are deploying
into your user running the key value store. Do you really expect that
one would create multiple overlays per application using one of these
services? How would you maintain hundreds of overlays? How would you
keep track that each box will use the correct overlay to get the
specific customized acct-* package? How do you deal with scenarios where
you don't just deploy single instances?


This is literally the example I gave. Our acct-user ebuilds can be added 
to additional groups based on USE flags. Every server uses the same 
overlay/ebuilds, but different machines get different package.use files, 
pushed out by the configuration management tool.


I understand that creating an overlay with acct-user overrides will not 
be for everyone, so I have no problem with adding an escape hatch. I do 
think it should be off by default though, and that missing future 
::gentoo changes will not be a problem unless some other error has been 
committed first.




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 it
would be unexpected to see these changes reverted during normal
world upgrade (which could break services).


It would be nice if this was well-supported by the official way of 
modifying system users/groups; that is, by using an overlay with 
modified user/group ebuilds.


Right now it's awkward to do because of the way the eclasses are 
structured. For example, some of our servers allow the "postfix" user to 
write to OpenDKIM's socket, but only on our *outgoing* mail servers (not 
on the incoming MX, where no signing takes place.) This is accomplished 
by creating an acct-group/dkimsocket ebuild (ok so far), and then by 
overriding the acct-user/postfix ebuild:


  EAPI=7

  inherit acct-user

  DESCRIPTION="user for postfix daemon"
  IUSE="dkimsocket"
  ACCT_USER_ID=207
  ACCT_USER_GROUPS=( postfix mail )
  acct-user_add_deps

  # This needs to be done outside of acct-user_add_deps because we can't
  # test use flags in global scope, and therefore we can't add groups
  # to ACCT_USER_GROUPS before calling acct-user_add_deps.
  RDEPEND+=" dkimsocket? ( acct-group/dkimsocket )"

  pkg_setup() {
  # https://wiki.gentoo.org/wiki/OpenDKIM
  #
  # Even though we added the group to RDEPEND manually, we still
  # need to add it to the array.
  if use dkimsocket; then
  ACCT_USER_GROUPS+=( dkimsocket )
  fi
  }

That's the common case of adding a system user to a group, and it's 
pretty ugly, so it's no wonder that people want to use "usermod" and 
then ignore subsequent changes by the PM.


And there's probably a backwards-compatible way we could support 
USE-conditional supplementary groups.




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 upstream to use pkg-config, and then
I have to hack it in Gentoo to avoid using pkg-config.


Sorry, I was wrong about this. Patching the upstream build system to 
support pkg-config does work if you use the eclasses.





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 only option that comes to mind is to
build
the entire project with LIBS="-llua5.2", but that's not right if only
some of the executables are supposed to be linked with lua.


You either fix upstream to use pkg-config, or you set up the cache
variable for your configure call to tell configure what the answer is,
without making it do the work wrong.


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 upstream to use pkg-config, and then 
I have to hack it in Gentoo to avoid using pkg-config.


Overriding the cached check variable does work, but you have to override 
every single call to AC_SEARCH_LIBS(function...) with 
ac_cv_search_ which depends highly on the implementation 
details of configure.ac. This is roughly as invasive and hard to 
maintain as patching, and should just not be the default way to link 
against a library IMO.




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 ignore the wrong SONAMEd even with the -L/usr/lib64/lua5.2/



eselect-lua creates a symlink named /usr/lib64/liblua.so, but the -L 
path should take precedence when looking for liblua.so. When it's 
looking for e.g. liblua5.2.so at runtime, there is only one copy to 
find, so no problem there.




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

Maybe something similar can work for your use case?


Yes, patching the build system works.



The problem with just using -L/path/to/lua/lib/ -llua would be loading
library at runtime, unless autotools is smart enough to actually change this
CFLAGs into a -Wl,-rpath,/path/to/lua/lib -L/path/to/lua/lib -llua.
I am not sure how intelligent autotools is to be able to do this or not.



We already add entries to /etc/ld.so.conf to make things like slotted 
LLVM work.




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 /usr/$(get_libdir).  Then you could simply
point those build systems at that directory and they would still use the
correct version.  As a hack in an ebuild, you probably could just create
such a setup in (subdirectories of) ${T}, pointing liblua.a, liblua.so,
and lua.pc at the appropriately-versioned files.


All of these packages are masked, so breakage isn't an issue.

And since these hacks are needed in every package that will link against 
liblua, doesn't it sound like something the eclass should be doing? Even 
the CMake packages would benefit, no longer having to pass in 
-DLUA_INCLUDE_DIR and -DLUA_LIBRARY by hand.




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.

Anyway, I'm on IRC as jkroon if you'd like to exchange notes.  I don't
particularly like the patch Marek did as I'll NEVER be able to push that
upstream.  The patch will work for us, but as a policy I highly prefer
patches which I can get unstreamed such that we don't need to carry them
more than one or two versions.


Agreed. This is more of a system library packaging issue than anything 
to do with Lua specifically.




I'd prefer to patch upstream to keep it's behaviour of detecting a lua
version, but have a --with-lua(version)? type argument that can take an
optional argument which will then be the version, but --with-* generally
takes a prefix where the include and lib folders can be found ... and
I'd prefer to depend on pkg-config as primary and fallback to the
./configure mess which tries to guess at things ...



This is exactly what I'm trying to get across. Support for multiple 
versions of libraries in weird locations is not a new thing. Generally, 
you can put CPPFLAGS="-I/foo/bar" and LIBS="-L/baz/quux" before running 
./configure and everything will just work with your header files and 
libraries in the non-standard paths /foo/bar and /baz/quux, 
respectively. Those paths take precedence over the defaults (if used 
correctly...), so you can use them to override the default version of a 
library and compile/link against a specific copy if you need to do that. 
Likewise, one could prepend a path to PKG_CONFIG_PATH to override the 
version that will be detected via pkg-config.


The problem that we've gotten ourselves into is that we've copied Debian 
by not only relocating the library, but renaming it (and its *.pc file) 
entirely. There is no good way to tell an autotools build system that 
you've renamed a library completely, and that it should prefer the 
renamed version over the standard one if the standard one also exists.


If you want to build against the eselected version of Lua on Gentoo, 
then eselect-lua makes everything OK. It creates symlinks from the 
standard names to the nonstandard ones, and everything just works. But 
if you want to build against a specific, not-eselected version of Lua? 
You have to tell the build system what to do. The eselected version 
lives in the correct locations (via those symlinks), so the build system 
is going to want to find that first. If the eselected version is not the 
one you want to build against, oops. Then, since the version you 
*do* want to link against has the wrong name, you have to tell the build 
system to link against it somehow. You can't simply override the 
PKG_CONFIG_PATH, because our *.pc files have the wrong names. You can't 
just override the library search path, because our libraries have the 
wrong names.


The work I've done so far for OpenDKIM does nothing to address these 
larger problems. If lua.pc is on the system, it will get used first, 
regardless of the version you actually want to build against. AFAIK 
there's no good way around this without patching.


If the libraries (and pkg-config files?) were installed to 
subdirectories instead, then the standard method of overrides could be 
used to build against a specific version, rather than requiring every 
upstream build system to support our weird layout.




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 this works use CMake, and 
CMake already tries to guess[0] the name of the lua library (thanks 
Debian) and so it has a pre-defined variable to store the result.


Not all build systems are going to work like that. Suppose I know that 
the name of the lua library is "lua5.2". An autotools build system is 
going to run something like,


  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 option that comes to mind is to build 
the entire project with LIBS="-llua5.2", but that's not right if only 
some of the executables are supposed to be linked with lua.


For contrast, if the lua library was stored in /usr/lib64/lua5.2, then I 
could just set LIBS="-L/usr/lib64/lua5.2" and let ./configure do its thing.



[0] https://github.com/Kitware/CMake/blob/master/Modules/FindLua.cmake



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 upstream names. The 
libraries, on the other hand, all get installed directly to $libdir.. 
but with NON-standard names like liblua5.2.a (as opposed to simply 
liblua.a).


This makes it impossible to build against a specific version of Lua 
without using pkg-config. The usual way would be to add 
/usr/include/lua5.2 to the compiler's include path, and $libdir/lua5.2 
to its library path (via -I and -L)... but there's no way to tell the 
build system to look for a library of an entirely different name. Things 
like AC_SEARCH_LIBS are going to try -llua, and that's it.




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" strongly implies that we check the 
non-Gentoo pools with a non-zero 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 can take much longer to replicate over the
  keyserver network, while 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:

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_keyserver

 However, you can pull from this server.

I tried to test your key but I am currently getting a failure from
our keyserver. Waiting for infra to check.



It's working now. I hadn't pushed directly to the internal server, 
unaware that it was still internal. An update to the error message (git 
hook) that mentions that wiki page could mitigate similar headaches in 
the future. GLEP63 still says,


  == Bare minimum requirements ==
  ...
7. Upload your key to the SKS keyserver rotation before usage!

which should also be amended if there's no imminent plan to resume 
pulling keys from there.




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 GLEP 
need an update? I guess we never resumed fetching from them after the 
incident?




[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 Expiration date is too close,
  please renew (is 2020-12-26 23:31:43, less than 14 days)

over a week after I've renewed my keys. The answer I get back from the 
keyserver(s) looks OK:


  $ gpg --search-keys 0x6F48D3DA05C2DADB
  gpg: data source: http://85.25.207.23:11371
  (1)   Michael Orlitzky 
Michael Orlitzky 
  4096 bit RSA key 0x1C49724D229E93A2, created: 2010-03-17,
  expires: 2022-12-05


Did I forget a step? How long should it take for infra to refresh?



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:

https://dev.gentoo.org/~marecki/open_blocking_lua_eclass_bugs-20201207135752.txt



I think the slotted lua ebuilds should be doing some eselect-lua stuff 
in pkg_postinst() and pkg_postrm(). For example:


  * I have lua-5.1 and lua-5.2 installed
  * Lua-5.2 is eselected
  * I uninstall lua-5.2
  * Now /usr/lib64/pkgconfig/lua.pc is a dangling symlink

Related to the above: is there a way to trigger rebuilds of consumers 
when the "single implementation" changes? If I have a package that links 
against liblua and if I upgrade from lua-5.1 to lua-5.2, then my package 
should rebuild. I don't think $LUA_DEPS from lua-single.eclass can do that?




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 aren't even fixed for systemd's tmpfiles provider.
> It will always rely on fs.protected_hardlinks for example. And checking
> for hardlinks like happened to address CVE-2017-18078 will create
> another TOCTOU race. Where is the follow-up report for this?

Systemd only supports Linux, and sets fs.protected_hardlinks=1 itself.
There's not much more we can ask from them.

I normally err on the side of caution, but if someone goes out of their
way to disable a security setting, I don't consider it CVE-worthy if the
thing that setting was preventing is now exploitable.


> In short: As long as it is possible for attacker to write to directory
> you are working on you can never do mentioned things in a safe way. You
> first have to revoke access for everyone except you and then you can
> start checking file per file... but *no* implementation is doing
> something like that.

This came up in the old (late 1990s, early 2000s) LKML discussions about
the protected_* sysctls. The Right Thing To Do is to drop privileges to
the user who owns the directory if you need to do stuff in a directory
that a user owns or can write to.

To quote your earlier message:

> Rule of thumb: Just make sure that you only create top level directories.

...and then drop privileges.





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 tmpfiles.d specification can only be implemented (safely)
>> on Linux after all.
> 
> So should virtual/tmpfiles differentiate based on system?
> 

There's no scenario where opentmpfiles is preferable.

systemd-tmpfiles with the fs.protected_hardlinks=1 sysctl is secure on
Linux. On other kernels, you're out of luck -- none of the options are
secure. Securing the service manager on other kernels would require
dropping tmpfiles entirely, and major changes to OpenRC.



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 allowing for race conditions first (according to
> the 10 immutable laws of security, if this is already possible, you are
> already lost).

Most of these security issues were fixed in systemd-tmpfiles years ago,
and you can easily find upstream tmpfiles.d entries that contain e.g.
"Z" entries. In that case, the upstream file is not in error, and root
doesn't have to be actively tricked into installing anything -- it will
just happen.

Opentmpfiles literally cannot fix this. There is no POSIX API to safely
handle hardlinks. At best it can be reduced to the same race condition
we have in checkpath, but the entire project would have to be rewritten
in C to accomplish even that.

Corollary: the tmpfiles.d specification can only be implemented (safely)
on Linux after all.



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 EAPI=6:

  https://bugs.gentoo.org/616612

I left a comment there with a proposal for how to fix it, but I haven't 
thought about it much since then.




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 false positives eventually. If
you're using amavisd-new, you can score them instead of reject outright:

  @virus_name_to_spam_score_maps =
(new_RE(
  [ qr'^MBL_.*' => 4.0 ],
  ));

That doesn't totally fix the problem, but if the message is otherwise
pristine (no blacklists, etc.) then a MalwarePatrol hit won't be fatal.




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:

https://archives.gentoo.org/gentoo-dev/message/64c42804eb4cf4bc7d1161a2e9222c6a

Last month, someone brought up that example and named the QA team as
partly responsible for the --changed-deps requirement, which goes
against the PMS and a council decision:

https://archives.gentoo.org/gentoo-dev/message/dcebabbd6f13aed6622424d439f7becc

Shortly thereafter, another QA member opened a pull request that would
retroactively make what the first QA member did OK:

https://github.com/gentoo/devmanual/pull/177

And now, we are having a third QA team member in charge of approving
that change to the devmanual, which will later be cited as "policy."

Your problem is that you're not a member of the right gang.



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 should be done when a new runtime
> dependency is added to an ebuild, but it doesn't say that for removal of
> a dependency.
> 

One dependency is removed, and another is added. All completely besides
the point that this breaks things.



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

This has caused dependency resolution problems in the past. The PMS
implies a new revision, the council said make a new revision, and the
devmanual already says make a new revision. Documenting this behavior
might make people feel better about ignoring all of that, but your lack
of guilt doesn't do me any good when portage starts crashing.



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 tests, then it becomes possible to construct a fortress of
flawed reasoning to defend the claim that "this won't cause problems for
end users."



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 needed package or
> manually rm'ed some random files
> 

There's no need to speculate; use pkgcore for a month and come back and
tell me how much comfort these hypotheticals were.


>> or..
>>
>>   3b. Some reverse dependency of foo-1.2.3 gets python-3.8 support.
>>   4b. A user tries to install that revdep, but the PM sees that
>>   the latest version of foo is already installed, and it (the
>>   installed version) doesn't support python-3.8. Mysterious
>>   error messages and manual intervention ensue.
> 
> 
> precisely the case I wrote above: unsatisfied dep -> pull ebuild.
> non-issue too.

It's easy to say "well this is not an issue because it can be solved by
..."

If it's easy, get it added to the PMS and I'll agree with you.



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 bash *just in case* there was an
>> important change in some ebuild is a huge waste of users' time.
> 
> That's wrong: The metadata has to be (re)generated anyway,
> independent of whether this is a revision bump or just a modification.
> For most syncing methods the bash sourcing does not happen on the
> user's machine, and on those machines where the metadata is actually
> calculated, there are checksums and timestamps used to minimize the
> effort. From this perspective there is no difference between a
> modification or a revision bump.

This is Hollywood accounting =)

Who generates the metadata when I `git pull`? Or in overlays? It's me,
but if you record that wasted time in a different "metadata generation"
ledger, then it looks like I've saved a bunch of time because the "bash
sourcing" ledger reads zero.

Even if I believe in a metadata angel and if we pretend that the PMS
requires the metadata to be there, then rebuilding whenever metadata
changes is still not 100% correct (as you point out), because it often
rebuilds pointlessly. But that's getting into a harder problem.


> ... costs thousands of users a lot of compilation time, although
> the recompilation is completely pointless for each of them, but
> done only to keep the PM simpler.

The recompilation isn't always pointless. In the present scenario, the
rebuild is what installs the python-3.8 copy of the program.

I'm not arguing that this is the best way to do things, but that it's
the only way to do them given what's in the PMS today. The foundation is
always looking for ways to spend money; maybe it should pay a few people
to sit around and think about this for a week. In any case, until a
better solution finds its way into the PMS, we should make the revisions.



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 per se. The situation is roughly this:

  1. User installs foo-1.2.3.ebuild, which supports python-3.7.
  2. Developer ninja-edits the ebuild to support python-3.8.
  3a. (crickets)
  4a. Developer removes python-3.7 support from foo-1.2.3.ebuild.
  5a. The next time something pulls foo-1.2.3 into the depgraph,
  the PM will see that the installed version of foo-1.2.3 depends on
  python-3.7, but that there is no python-3.7 in the tree or that
  it's masked. Now emerge always fails.

or..

  3b. Some reverse dependency of foo-1.2.3 gets python-3.8 support.
  4b. A user tries to install that revdep, but the PM sees that
  the latest version of foo is already installed, and it (the
  installed version) doesn't support python-3.8. Mysterious
  error messages and manual intervention ensue.

What's happening is that the PM is using the metadata from the installed
version of the package, rather than the ninja-edited metadata in the
repo (how would it know which ebuilds were edited meaningfully?). That's
completely legal according to the PMS, and also the smart thing to do:
sourcing a few thousand lines of bash *just in case* there was an
important change in some ebuild is a huge waste of users' time.

Developers have an easy way to signal that there was an important
change: to bump the "r" number at the end of the ebuild. This forces any
upgrade involving e.g. foo-1.2.3 to pull in foo-1.2.3-r1, and the fact
that an upgrade is available is evident from `ls`, rather than from
sourcing a mountain of bash. One developer makes a change, and it saves
thousands of users each a lot of time. That's what we're all here for.

A package manager that uses the installed metadata is acting within its
rights (both pkgcore and portage without dynamic deps do it), so we
shouldn't be doing anything to break them in ::gentoo. Requiring
--changed-use is both insisting that users' waste time finding out
something that the developer could have told them, and also precluding
the use of a package manager that doesn't implement the (unspecified)
--changed-use flag in the same way portage does.

tl;dr the name of an ebuild is the only sensible (and PMS-compliant) way
to determine if something important changed inside it. The PMS says that
a new revision will be noticed by the PM, and it doesn't specify any
heuristics like --changed-use that ask the PM to (slowly) guess at it.
So, we should use revisions for these things.



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
>> supports python-3.8. Otherwise, you will eventually find a lot of people
>> stuck unable to upgrade because they have an ebuild installed that only
>> supports <=python-3.7, and were never prompted to install the copy that
>> supports python-3.8.
> 
> Python target changes must be done with -U, also documented by the 
> accompanying repository news item, not really a problem.
> 

If you want to write the GLEP that obsoletes the PMS, I might even
support it at this point. But until then, requiring --changed-use to
have a functional system is not allowed. Any PMS-compliant package
manager must be able to use ::gentoo, including one that does not
implement portage-only heuristics.



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 there).
> 

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
supports python-3.8. Otherwise, you will eventually find a lot of people
stuck unable to upgrade because they have an ebuild installed that only
supports <=python-3.7, and were never prompted to install the copy that
supports python-3.8.



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**. Killer feature
right there.



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

2020-08-14 Thread Michael Orlitzky
This reverts commit a73024729860f9224b8d1660d24c450080b67d9f. This
eclass was successfully purged from the tree, so the deprecation is no
longer needed. And eventually, to address an eblit infestation,
another eclass with the same name will return. The new one will not be
deprecated.

Signed-off-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
--- a/repoman/lib/repoman/modules/linechecks/deprecated/inherit.py
+++ b/repoman/lib/repoman/modules/linechecks/deprecated/inherit.py
@@ -33,7 +33,6 @@ class InheritDeprecated(LineCheck):
"gst-plugins10": "gstreamer",
"ltprune": False,
"mono": "mono-env",
-   "netsurf": False,
"python": "python-r1 / python-single-r1 / python-any-r1",
"ruby": "ruby-ng",
"user": "GLEP 81",
-- 
2.26.2




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 made by 
> someone at Wed Oct 16 19:41:02 2019 + and I do wonder why nobody else run 
> into that issue since that time?
> 

Beats me. I run a stable system, so probably it just needed the right
combination of packages to stabilize. Or maybe it was the change in
xorg-2.eclass that triggered it. Or maybe no one else has noticed that
there's a useless package on his system (that will be stranded until all
of the affected packages get upgrades/revisions) and tried to remove it.
Or maybe everyone has set USE="-gentoo-dev" for portage to avoid this
perpetual clown show. Or...

what difference does it make? It already took me 100x longer to figure
out what went wrong than it would have taken to make the revisions in
the first place. I don't want to waste any more. I'm still tracking down
more packages that need to be rebuilt by hand because RDEPEND was
changed in an eclass too.



[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
  +# Copyright 1999-2019 Gentoo Authors
   # Distributed under the terms of the GNU General Public License v2

   EAPI=6
  @@ -21,8 +21,7 @@ RDEPEND="${RDEPEND}
  x11-apps/bitmap
  x11-apps/iceauth
  x11-apps/luit
  -   x11-apps/mkfontdir
  -   x11-apps/mkfontscale
  +   >=x11-apps/mkfontscale-1.2.0
  x11-apps/sessreg


This is what portage does:

  $ sudo emerge -uDN @world
  Password:
  Calculating dependencies... done!

  emerge: there are no ebuilds to satisfy "x11-apps/mkfontdir".
  (dependency required by "x11-base/xorg-x11-7.4-r3::gentoo"
  [installed])
  (dependency required by "@selected" [set])
  (dependency required by "@world" [argument])


I have too many other things to do to waste time reverse-engineering
these fuck-ups. Get it together.



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 suggest to upstream that they don't force a particular
compiler in their Makefile. One uncontroversial way to do this is by
setting the default only if the user does not already have one set, with
the "?=" assignment operator:

  cc ?= g++

Then, you should suggest that they change the name of that variable to
the relatively-standard "CXX" that is used for the C++ compiler:

  CXX ?= g++

Finally, in your ebuild, you should run

  emake CXX=$(tc-getCXX) ...

to override the default CXX in the Makefile. Even if upstream doesn't
respond right away, you can patch the Makefile with these suggestions in
Gentoo and send them the patch.



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 environment variables had to be whitelisted, ebuilds would still
need to know how to use them when they happen to be defined.

I basically just want to write down things like "If set, CC is assumed
to contain the name of a compiler driver such as /usr/bin/gcc." That way
ebuilds can be written to pass $CC to the build system in places that
are expecting a compiler driver. Conversely, if LD is documented to
contain a dynamic linker such as /bin/ld, then ebuilds must mangle LD
whenever the upstream build system (e.g. pari, perl) interprets it
otherwise.

These meanings are already enshrined in the tc-getFOO() functions and
the various de-facto standards, but there's no user or developer
documentation promising that the variables will be used in any
particular way.



[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],

  * CXX
  * CPP
  * AS

and a few are de-facto GNU libtool standards[2]:

  * NM
  * RANLIB
  * LD

If we expect them all to work properly in Gentoo, we have to agree on
what they mean, and thus how they should be injected into build systems.
For example, we had a problem with sci-mathematics/pari, whose upstream
is using the LD environment variable for something other than what GNU
libtool uses it for. With LD set to something libtooly in the
environment, the pari build fails. We can solve that by unsetting LD in
the ebuild, but for that to be The Right Thing To Do, we should be
expecting LD to contain something libtooly, and thus something
inappropriate to be passed to the pari build.

To avoid these issues, I suggest creating a list of "Gentoo environment
variables" in the devmanual with descriptions of how they should be used
and pointers to the references (for why we chose that meaning). That way
a user can export LD, for example, and know that it will be used how he
thinks it will be used.


[0] https://pubs.opengroup.org/onlinepubs/009695399/utilities/make.html

[1]
https://www.gnu.org/software/make/manual/html_node/Implicit-Variables.html

[2] https://www.gnu.org/software/libtool/manual/libtool.html



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 parse XML, and takes the maintainer's email address as an argument:

REPO=/var/db/repos/gentoo
XPATH="/pkgmetadata/maintainer/email[normalize-space(text()) = '${1}']"

find -L "${REPO}" \
  -mindepth 3 \
  -maxdepth 3 \
  -name 'metadata.xml' \
  -exec sh -c "
for f in \"\${@}\"; do
  xmllint --xpath \"${XPATH}\" \"\${f}\" >/dev/null 2>&1 && \
echo \"\$(dirname -- \"\${f}\")\" | sed \"s:${REPO%/}/::\"
done
  " - {} +



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

2020-06-16 Thread Michael Orlitzky
While investigating bug 489542, it became clear that the netsurf
eclass is deprecated in spirit if not in fact. All of the newer
netsurf ebuilds use a custom function loaded from a script that is
shipped in netsurf-buildsystem's $FILESDIR to do (some of) what the
eclass used to do. That function probably does belong in an eclass,
but at this point, we should throw this thing out and start from
scratch.

By deprecating the eclass, we make sure that no one else inherits it
during the time it takes to purge the two remaining consumers. Then,
once those are gone, the build system script magic 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 a/repoman/lib/repoman/modules/linechecks/deprecated/inherit.py 
b/repoman/lib/repoman/modules/linechecks/deprecated/inherit.py
index 5848a0c37..60410347b 100644
--- a/repoman/lib/repoman/modules/linechecks/deprecated/inherit.py
+++ b/repoman/lib/repoman/modules/linechecks/deprecated/inherit.py
@@ -33,6 +33,7 @@ class InheritDeprecated(LineCheck):
"gst-plugins10": "gstreamer",
"ltprune": False,
"mono": "mono-env",
+   "netsurf": False,
"python": "python-r1 / python-single-r1 / python-any-r1",
"ruby": "ruby-ng",
"user": "GLEP 81",
-- 
2.26.2




[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 relocated from netsurf.eclass into
/usr/share/netsurf-buildsystem/gentoo-helpers.sh (which it looks like is
just an out-of-tree eclass?).

There are only two ebuilds left in the tree using netsurf.eclass:

  * dev-libs/libparserutils-0.2.3 (superseded by v0.2.4-r1)
  * net-libs/libhubbub-0.3.3 (superseded by v0.3.6)

The first one needs a stabilization, but then the old versions can be
removed and netsurf.eclass can be last-rited. That leaves us with a
similar problem in gentoo-helpers.sh, which does...

  NSSHARED="${EROOT}"/usr/share/netsurf-buildsystem
  LIBDIR="$(get_libdir)"
  PREFIX="${EROOT}/usr"

Digging into the netsurf buildsystem it looks like PREFIX is already
pre/appended to the uses of NSSHARED and DESTDIR. So I think we should
have instead,

  LIBDIR="$(get_libdir)"
  PREFIX="${EPREFIX}/usr"

and then the ebuilds themselves need to be fixed. For example,

  _emake TARGET=framebuffer DESTDIR="${ED}" install

should have DESTDIR="${D}" instead, because the buildsystem already
installs to $(DESTDIR)$(PREFIX). As it is, you're getting the "E" twice.

Removing the EROOT (as in the proposed patch) would also fix this, but
the standard pattern for ebuilds is to use the "E" variables at
configure-time, and only $D at install-time.



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 why lzip is the dominant compression format now, and nobody
> is using xz any more.
> 

If you believed that argument, you would be using Windows =P

Dude has GRAPHS, it must be true.



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 pieces of software
> running in prod and actually serving customers I had to update up to
> the latest LTS after 3-4 years of inactivity, I tend to disagree. Even
> the latter was a surprisingly smooth process boiling down to about an
> hour or two of very effortless, mechanical and thus boring code
> changes (mostly about Semigroup/Monoid hierarchy, if you wonder).
> 
> This is surely offtopic, but I just don't want to silently participate
> in spreading things that aren't objectively true (even if they are
> subjectively true in your/mine/etc experience).

Fair enough, I was speaking only from personal experience. But if you do
an experiment I bet you'll agree with me. Updating your code to work
with the latest GHC is pretty easy. But if you wanted to write an ebuild
for that program, it would have a dependency on that specific version of
GHC, leading to these same problems that we're talking about when other
programs require other specific versions.

I can compile my C programs with any GCC going back to the 4.x days --
or even clang. In the past three years, we've collected ghc-8.0 though
ghc-8.10 in ::gentoo. Try to make your code work with all of those GHC
releases at once; if you come back and tell me it was easy, I'll be
impressed (and may start asking you to update my Haskell code).

Working around something like gcc-10's -fno-common breakage, on the
other hand, is relatively easy. We write a patch, send it upstream, add
it to ::gentoo in the meantime, and everything keeps working. But that's
only backwards-compatible because the C standard says how it should
work, and the C standard doesn't change every six months to be "whatever
this version of GCC does."

To refer back to something on-topic: some projects are willing to make
the extra effort, and some aren't. The ones that are, are easy to
package and definitely belong in ::gentoo. The others... should be dealt
with case-by-case. But lowering the standards of the main tree should
not be how we get them over the bar.



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 trying to convince
> upstreams to make changes to their build systems to support a single,
> somewhat niche, distribution. We certainly don't have time to be
> patching build systems with every version bump.
> 

You're introducing unfixable security vulnerabilities into a
distribution that I recommend to people, that my name implicitly
endorses, and that I use to professionally to handle peoples' sensitive
personal data.

Likewise with the license issues that can't be fixed.

It's a waste of time having to explain to every new contributor that Go
ebuilds in ::gentoo are "special" and aren't something they should be
using as an example.

You're setting an example that our QA and security standards (that we
beat to death in the quizzes) can be ignored whenever you feel like it.
This indirectly creates technical debt as other developers follow your
example.

You're directly creating technical debt that someone else is going to
have to clean up when you move on to the next shiny and the treecleaners
have to waste six months last-riting everything.

And you're blocking a golang implementation that doesn't have these
problems.



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 minor releases.
> 
> That's not a matter of just the API per se. Even the library file name
> encodes its deps in its name (if I understand correctly, that's the
> hash in libHSregex-base-0.94.0.0-541xQVwwNRiBGjsNKmOPoy-ghc8.6.5.so
> for example). Personally I just find it hard to reason about this sort
> of dependencies management. But, again, I should probably avoid trying
> that and just jump head first to packaging.

Haskell already requires transitive rebuilds of dependencies due to a
(serious) implementation constraint. Subslots help with that, but it
will take a new EAPI to truly tell an ebuild how to do what we need to
do. In any case, all Haskell ebuilds depend on separate packages for
their dependencies, and with haskell-updater, subslots, and
@preserved-rebuild it all more or less works.

I think that's largely separate from the "diamond dependency problem"
you posed. Diamond dependencies manifest mainly in delayed version
bumps, while slyfox does all the work to make sure that the things
already in the tree will work with the new version. This requires lots
of careful updates to neighboring packages, and unfortunately a lot of
cabal file hacking.


> Dunno much about Go and I don't have a single Go package locally to
> check. Do they do static or dynamic linking with the deps, for
> instance? What's the language model wrt API and linking?

FORGET I MENTIONED IT


>> and C.
> 
> More stable API (and ABI).
> 

Definitely. The "Haskell" language changes entirely every few years.
I've learned the hard way that it discourages you from doing all the
things that I just said high-quality software should do.

There's a core of mature Haskell that's pretty easy to develop against.
(I think you just have to wait about five years with any project before
the authors realize that changing everything every month isn't fun.) Out
in the woods you can still get into a lot of trouble though. We now have
the mature core stuff in ::gentoo, and the crazies out in the ::haskell
overlay. That feels like the right mix.



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 and
committed the last time we did this. We're not in this together and you
sound like a COVID commercial from a billionaire that wants me to go
back to work. You're in this for you, and everything you do for you
makes things worse for me.


[0] Sony Interactive Entertainment



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 haskell software, which has somewhat similar issues:
> 
> ...
> 3. What is major is the following. Let's say two executables A and B
> depend on libfoo:1 and libfoo:2 respectively, and depend on the same
> version of libbar. libbar itself depends on libfoo (and supports both
> versions), but libbar built with libfoo:1 is incompatible with libbar
> built with libfoo:2. Loosely speaking, the slot of a library is
> defined by all its dependencies' _versions_.
> 
> Of all these, (3) is quite major, as it leads to exponential explosion
> of the slots count. Otherwise, one might choose to carefully curate
> the library versions, ensuring that no such situation arises, but this
> approach is neither feasible nor possible at all for sufficiently
> large packages base.

There's nothing Haskell-specific here, is there? Except that Haskell as
a research language tends to inspire more "fire and forget" software.
(And Haskell works better in Gentoo than anywhere else, in my opinion.)

You package each dependency as a separate package. If there's a conflict
between two packages, then... you can't have those two packages
installed together. When that happens, you alert upstream, and try to
convince them to be more lenient with their dependencies (again, nothing
Haskell-specific here). Sometimes that involves code changes, but often
it's just an edit to the cabal file. Many people follow either semver or
the PVP (https://pvp.haskell.org/) which keeps things from getting too
far out of control.

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

Software engineering is a fractal. Curating APIs and dependencies is as
much a part of it as what sorting algorithms you choose. These are all
old problems with known solutions (sonames, semver, etc.) and software
isn't magically high-quality because it's written in a language that
came our last week.

So aside from the "What's Gentoo?" that's going to be more common among
Haskell upstreams, I don't see anything fundamentally different here
between Haskell (or Go, or...) and C. We should be helping to make
upstream software more good, and then packaging it. (It's OK to hack the
cabal file while the bug report is open.)



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* in dev-go/* with my name on it.

You quoted me one sentence prior saying that it's the Go ebuilds that
are trash and not anyone personally. But OK, I should have said "Sony
Interactive Entertainment" there instead of "you."


> Are you volunteering to do the work to package go packages? The people doing 
> the work generally get to decide how that work gets done, and which approach 
> they would like to take. The upstream situation makes it very 
> labour-intensive to do the work in a the way you are proposing (many packages 
> would end up with hundreds to thousands of packages in the tree). Separating 
> everything out in to separate packages will just increase the maintenance 
> load exponentially, with no gains as go upstreams version lock all their 
> dependencies.
> 

I'm volunteering to work on one or two small Go packages. Can I convert
the eclass to use dynamic linking? Can I start replacing your packages
with my own if I need them as dependencies? I suspect not, and that's
one of many reasons why "having things in ::gentoo does not affect
anyone who does not use them" is bullshit.



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 libraries doesn't worth the effort to
> package them all. I mean, most of these projects have an immutable
> deployment approach that are not feasable to be packaged. The problem
> starts from upstream...

You can do whatever you want in an overlay, but you can't introduce
security vulnerabilities and license issues into thousands of peoples'
homes and businesses through ::gentoo because it makes your life a tiny
bit easier.

The job description of distribution developer is, ultimately, to fix all
the dumb things that upstream does before packaging the result so that
your users get a consistent, usable, reliable, and secure product. But
the first step isn't optional. Re-packaging garbage is easy -- that's a
service nobody needs.

Using ebuilds this way is also simply a waste of your time. If you're
not going to package the dependencies, then you're better off using the
upstream bundling tool. At least then you can update the hundreds of
bundled dependencies afterwards. With an ebuild that's not possible.

I don't mean to discourage you any more than necessary. I'm glad you
want to help. But please quit looking to Go as an example of anything
anyone should be doing.



[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
packages for each package. I know, it sounds crazy when you say it.



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 totally different things. IMO it would be
better to use names like qt-designer, plasma-activities, etc.



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 just rely on components, or
> 

I've been setting them just in case someone has a workflow/automation
involving the keywords that hasn't been updated in ten years. If you
kill the keywords, I wouldn't have to worry about that, so +1.



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

2020-04-02 Thread Michael Orlitzky
This is a straightforward import of the latest fflas-ffpack-2.4.3.ebuild
that François Bissey has been maintaining in the sage-on-gentoo overlay,
with only a few minor changes:

  * I added a "+" to the LICENSE to match the upstream LGPL-2.1+.

  * I switched the openmp check to use tc-check-openmp() conditionally
on the MERGE_TYPE variable.

  * Added BDEPEND="virtual/pkgconfig" since we patch in a call to
PKG_CHECK_MODULES.

I also removed a warning about build failures with USE=openmp. From what
I can tell, this stems from an older report (upstream Github issue 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|  1 +
 .../fflas-ffpack/fflas-ffpack-2.4.3.ebuild| 62 +
 .../files/fflas-ffpack-2.3.2-blaslapack.patch | 90 +++
 sci-libs/fflas-ffpack/metadata.xml| 37 
 4 files changed, 190 insertions(+)
 create mode 100644 sci-libs/fflas-ffpack/Manifest
 create mode 100644 sci-libs/fflas-ffpack/fflas-ffpack-2.4.3.ebuild
 create mode 100644 
sci-libs/fflas-ffpack/files/fflas-ffpack-2.3.2-blaslapack.patch
 create mode 100644 sci-libs/fflas-ffpack/metadata.xml

diff --git a/sci-libs/fflas-ffpack/Manifest b/sci-libs/fflas-ffpack/Manifest
new file mode 100644
index 000..d10a12abc35
--- /dev/null
+++ b/sci-libs/fflas-ffpack/Manifest
@@ -0,0 +1 @@
+DIST fflas-ffpack-2.4.3.tar.gz 1059033 BLAKE2B 
e416429bb426a81cf9c25d54c83380ff9a9d658c711da06e6359d968843d4d9d26cf8389379f9ad4a5cbcee93e0afc9fe0497bb7a8f190e0c72c0b1f7b67de18
 SHA512 
c7620ba5a92e4114a581a6bea32267f9d5a9f0eb7e23fc0a7a97ce4b8124bb7b29f89ff2ad6ad270d97c76489625b57a354e581905b74ee57b35f4ca3e196a44
diff --git a/sci-libs/fflas-ffpack/fflas-ffpack-2.4.3.ebuild 
b/sci-libs/fflas-ffpack/fflas-ffpack-2.4.3.ebuild
new file mode 100644
index 000..4115dc61ace
--- /dev/null
+++ b/sci-libs/fflas-ffpack/fflas-ffpack-2.4.3.ebuild
@@ -0,0 +1,62 @@
+# Copyright 1999-2020 Gentoo Authors
+# Distributed under the terms of the GNU General Public License v2
+
+EAPI=7
+
+inherit autotools toolchain-funcs
+
+DESCRIPTION="Library for dense linear algebra over word-size finite fields"
+HOMEPAGE="https://linbox-team.github.io/fflas-ffpack/;
+SRC_URI="https://github.com/linbox-team/${PN}/releases/download/${PV}/${P}.tar.gz;
+
+LICENSE="LGPL-2.1+"
+SLOT="0"
+KEYWORDS="~amd64 ~x86 ~amd64-linux ~x86-linux ~ppc-macos ~x64-macos ~x86-macos"
+IUSE="static-libs openmp cpu_flags_x86_fma3 cpu_flags_x86_fma4 
cpu_flags_x86_sse3 cpu_flags_x86_ssse3 cpu_flags_x86_sse4_1 
cpu_flags_x86_sse4_2 cpu_flags_x86_avx cpu_flags_x86_avx2 cpu_flags_x86_avx512f 
cpu_flags_x86_avx512dq cpu_flags_x86_avx512vl"
+
+# Our autotools patch hacks in PKG_CHECK_MODULES calls.
+BDEPEND="virtual/pkgconfig"
+DEPEND="virtual/cblas
+   virtual/blas
+   virtual/lapack
+   dev-libs/gmp[cxx]
+   =sci-libs/givaro-4.1*"
+RDEPEND="${DEPEND}"
+
+PATCHES=( "${FILESDIR}/${PN}-2.3.2-blaslapack.patch" )
+
+pkg_pretend() {
+   [[ "${MERGE_TYPE}" != "binary" ]] && use openmp && tc-check-openmp
+}
+
+pkg_setup(){
+   tc-export PKG_CONFIG
+}
+
+src_prepare(){
+   default
+   eautoreconf
+}
+
+src_configure() {
+   econf \
+   --enable-precompilation \
+   $(use_enable openmp) \
+   $(use_enable cpu_flags_x86_fma3 fma) \
+   $(use_enable cpu_flags_x86_fma4 fma4) \
+   $(use_enable cpu_flags_x86_sse3 sse3) \
+   $(use_enable cpu_flags_x86_ssse3 ssse3) \
+   $(use_enable cpu_flags_x86_sse4_1 sse41) \
+   $(use_enable cpu_flags_x86_sse4_2 sse42) \
+   $(use_enable cpu_flags_x86_avx avx) \
+   $(use_enable cpu_flags_x86_avx2 avx2) \
+   $(use_enable cpu_flags_x86_avx512f avx512f) \
+   $(use_enable cpu_flags_x86_avx512dq avx512dq) \
+   $(use_enable cpu_flags_x86_avx512vl avx512vl) \
+   $(use_enable static-libs static)
+}
+
+src_install(){
+   default
+   find "${ED}" -name '*.la' -delete || die
+}
diff --git a/sci-libs/fflas-ffpack/files/fflas-ffpack-2.3.2-blaslapack.patch 
b/sci-libs/fflas-ffpack/files/fflas-ffpack-2.3.2-blaslapack.patch
new file mode 100644
index 000..3154a261819
--- /dev/null
+++ b/sci-libs/fflas-ffpack/files/fflas-ffpack-2.3.2-blaslapack.patch
@@ -0,0 +1,90 @@
+diff --git a/configure.ac b/configure.ac
+index 5b46b18..5e0264a 100644
+--- a/configure.ac
 b/configure.ac
+@@ -248,49 +248,24 @@ dnl echo 
'**
+ dnl exit 1

[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: https://bugs.gentoo.org/715678
---
 profiles/desc/cpu_flags_x86.desc | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/profiles/desc/cpu_flags_x86.desc b/profiles/desc/cpu_flags_x86.desc
index d891398e7a6..156b677e5a4 100644
--- a/profiles/desc/cpu_flags_x86.desc
+++ b/profiles/desc/cpu_flags_x86.desc
@@ -10,7 +10,9 @@
 aes - Enable support for Intel's AES instruction set (AES-NI)
 avx - Adds support for Advanced Vector Extensions instructions
 avx2 - Adds support for Advanced Vector Extensions 2 instructions
+avx512dq - Use AVX-512 double- and quad-word instructions
 avx512f - Adds support for AVX-512 Foundation instructions
+avx512vl - Use AVX-512 vector-length instructions
 f16c - Adds support for F16C instruction set for converting between 
half-precision and single-precision floats
 fma3 - Use the Fused Multiply Add 3 instruction set ([fma] in cpuinfo)
 fma4 - Use the Fused Multiply Add 4 instruction set
-- 
2.24.1




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

 profiles/desc/cpu_flags_x86.desc  |  2 +
 sci-libs/fflas-ffpack/Manifest|  1 +
 .../fflas-ffpack/fflas-ffpack-2.4.3.ebuild| 62 +
 .../files/fflas-ffpack-2.3.2-blaslapack.patch | 90 +++
 sci-libs/fflas-ffpack/metadata.xml| 37 
 5 files changed, 192 insertions(+)
 create mode 100644 sci-libs/fflas-ffpack/Manifest
 create mode 100644 sci-libs/fflas-ffpack/fflas-ffpack-2.4.3.ebuild
 create mode 100644 
sci-libs/fflas-ffpack/files/fflas-ffpack-2.3.2-blaslapack.patch
 create mode 100644 sci-libs/fflas-ffpack/metadata.xml

-- 
2.24.1




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 object. In a bundling scenario, we will be forced to rebuild[5]
> all consumers. 

This is highly euphemistic. What actually happens is: someone discovers
a security issue in a Go library. That library is not "in" Gentoo,
because it only ever appears in a string inside of another ebuild that
bundles everything. Thereafter, a whole lot of nothing happens. Users
remain vulnerable "forever," until some other unrelated event causes
both the ebuild and its dependency to be updated.

Your license scenario is also wishful thinking. All of the LICENSE bugs
reported when this eclass was proposed have been sitting open for six
months. As soon as the eclass was committed, that shit went out the door
and the developers moved on to make more money at our expense. You got
scammed.



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 list. I don't see a
> single email from you during that entire period.
> 

Seriously?



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 additional tar.gz with that code along with
> the software release tar.gz.
> That additional tar.gz needs to be stored somewhere and as I understand
> local mirror could be the right place.

Normally we don't bundle dependencies, avoiding that problem entirely.
The Go eclasses however are badly designed, committed against protest by
paid corporate interests, and serve only to facilitate large-scale
copyright infringement and security vulnerabilities. If you're looking
for a consistent explanation of how they're supposed to work with the
rest of Gentoo, you won't find one.



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 ::gentoo. The gentoo infrastructure will automatically mirror
anything in SRC_URI unless you set RESTRICT=mirror -- and that's where
most people will download them from -- so (for example) adding a bunch
of extra thirdpartymirrors entries to ensure that the distfiles are
accessible is counter-productive: everyone will get the stuff from the
gentoo mirrors anyway, and you wind up with a bunch of dead entries in
the thirdpartymirrors file (at least half of the entries in there right
now are dead, and no one is ever going to clean them up because no one
uses them).



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 already have the ability to fake this. Instead of KEYWORDS="~noarch",
if you really believe that your package is architecture-independent, you
can just add all ~arch keywords to it. If you're right, no one will ever
notice, and if you're wrong, you'll get shit for it -- just like you
would have if you marked it ~noarch incorrectly.

Maintainers can do their own stabilization (on all arches) for those
packages. I hesitate to invoke "common sense," but in cases where common
sense truly does prevail, you should have no problem keywording and
stabilizing a package on all arches that e.g. downloads a PDF of API
documentation.



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
users, which you've purposely omitted.

I was never going to commit the patch. If anyone wants to discuss the
technical merits of using /home, I find it interesting, but please let
this thread die and just email me personally or ping me on IRC.



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 avoid
putting what is practically and factually a home directory in /home. I
have a few of these packages. I will echo ulm's sentiment that it's just
awful to put them all in

  /var/lib/user1-home
  /var/lib/user2-home
  ...

rather than /home/user1 and /home/user2.

That's also second-guessing the administrator, whose home directory
policies for e.g. backups very likely apply to the home directories I'm
creating. (Keep in mind that I'm only talking about exceptions for very
special packages that install a system user that will also be used by a
human or that stores per-user configuration. And the exception is only
for the keepdir file.)

Home directories in /home were also allowed with user.eclass, which
means that we now hit a roadblock updating those accounts to GLEP81.


> 
> I mean, user configuration works perfectly fine there, even if you have to 
> log in. And the purpose of the account is closer to, say, root (with its 
> nonstandard home directory location) than a normal user.
> 
> I've seen all possible site-specific changes to /home layout, including, 
> e.g., 
> * /home/server1/username
> * /home/large/username
> * /home/u/username
> ...
> which would all get somehow messy if a system account with a fixed path is 
> forced in there.
> 

Sure, but is having them scattered across BOTH /home AND /var/lib less
messy? We're picking a default, and with GLEP81, the people who do this
could move it to /home/u/${PN} with an overlay ebuild; whatever makes
them happy. For everyone else, it's a good default.



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 automounter.) So if these machines ran Gentoo
> and you went to do something like "create /home/amavisd" it would fail
> because the root user doesn't have the ability to make home directories
> in /home (uid=0 is mapped to nobody, who doesn't have +w on /home.) All
> home directories were created by a business application and there were
> specific hosts where root was not squashed (and we used sec=sys instead
> of krb5) and so root on the admin host would have +w on /home and not be
> squashed to nobody.)
>
> In practice in that enterprise environment, if we needed something like
> /home/web/ (which I think did exist at one point) we would create a role
> account in LDAP (www-data is a common user for example), assign it a
> uid, create the homedirectory (/home/web) and it would be owned by
> www-data:www-data. Then we would configure the web front ends to use
> www-data instead of the normal user (apache or nginx or whatever.)

That's all relatively normal. As I've said, a human uses the "amavis"
account. Yes, the install of acct-user/amavis would crash because it
can't create the home directory, but I contend that crashing is the best
thing to do.

When the acct-user ebuild crashes, you get to ask yourself if you want
his home directory to be shared among the people with authority to
release spam from the quarantine. I'm betting you would, and that you
would therefore add the account to LDAP and start over. Same deal as
apache/web, and you don't have to involve an overlay to do the right
thing. In this case, the fact that we used /home was a boon, because it
helped you accomplish what you were trying to accomplish by sharing
/home in the first place.

If you don't want to share the home directory... well, no harm done.
You'll have to override the ebuild to tell it what location to use as an
alternative. But I think this case is somewhat less likely, and the base
rate was already single digits.

If only good exceptions are made (with home directories that people
would actually want to share under /home), this approach does a little
good and no bad.



> (2) I don't think most people running Gentoo are running these
> environments, which is why you don't see many practical objections on
> the list. I think it's reasonable to avoid service account homedirs in
> /home not because of fancy examples like above (that maybe 10 companies
> in the world run) and instead just focus on this idea that "system stuff
> doesn't go in /home." Its somewhat arbitrary as mgorny points out
> earlier in the thread.

I was never discounting these sorts of environments. On the contrary,
the point I'm trying to make above appeared somewhere in the discussion
with rich0, but it's hard to articulate without details.

If it's arbitrary and we admit that, I'm fine with it. I'm moving on
with my life. QA can choose what kind of sauce users get on their turd
sandwich =P



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

Ok. How to move forward?

The old user.eclass allowed using /home, and we have packages using
/home. One of them is spamd, and I've beaten to death the reasons why I
think that's the best choice. I would rather not move it somewhere
*less* appropriate on principle. I would also like to not break running
mail systems the second the acct-user package is emerged.

What are the options?

  * Upgrade to GLEP81 anyway and ignore the warning (my interim plan).

  * Hack the acct-user ebuild so that it doesn't trigger the warning, by
bypassing $D.

  * Leave it on user.eclass.

  * ???



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 override the home directory in those rare cases to put it under
/home/guests. For everyone else, you get

  /home/user1
  /home/user2
  /home/user3
  /home/user4

instead of

  /home/user1
  /home/user2
  /var/lib/user3/home
  /home/user4

I think it's weird that my bash_history winds up under /var/lib.


> Besides, nothing guarantees that your username under /home won't collide
> with an existing subdirectory name. 

You can make the same argument about /var/lib. And keep in mind that we
already have "collisions" for $HOME every time someone switches from
user.eclass to a GLEP81 user. The risk for /home is no greater than
anywhere else, and we've deemed that risk acceptable, whatever it is.



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 describe in detail the havoc that this could cause and under what
precise circumstances.



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 that are incompatible with the package manager installing
> things there (the only exception being baselayout creating the directory
> itself).

I haven't been given a single technical reason why using /home would
cause a problem. What specific incompatibilities are you talking about?


> Quoting FHS-3.0 again:
> 
> | On large systems (especially when the /home directories are shared
> | amongst many hosts using NFS) it is useful to subdivide user home
> | directories. Subdivision may be accomplished by using subdirectories
> | such as /home/staff, /home/guests, /home/students, etc.
> 
> So, how are you going to detect if such a scheme is used on the system,
> and in which subdirectory the amavis user should be placed?

The same way we detect that scheme before setting a home directory to
/var/lib/whatever, which you may notice, is not under /home/guests or
anything like that. Does this cause a real technical problem, or is it
just more FUD?


> I also wonder why you would send this patch, when there wasn't a single
> voice supporting your proposition in the other thread and several
> opposing ones.

I don't want to just complain without offering a solution.

No one has pointed out any problems with it.

This stuff is already in /home, and I'd like to get off user.eclass
without introducing a new QA warning for a keepdir file.



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's retarded is copy/pasting words from last week's buzzword bingo as
if they're valid reasons to not use /home for home directories.

LUKS is a thing, but you don't use it. CIFS is a thing, but you don't
use it. Shared home directories are a thing, but you don't use it. Give
me one real example of how any of these things cause a problem and I'll
change my stance. I don't have a special emotional attachment to /home.
I think it's where this stuff should go because (a) home directories are
what /home is for, and (b) it doesn't cause any other problems. If (b)
isn't true, you win.



[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
index e6cd7e67442..5161aef9922 100644
--- a/metadata/install-qa-check.d/08gentoo-paths
+++ b/metadata/install-qa-check.d/08gentoo-paths
@@ -17,8 +17,6 @@ gentoo_path_check() {
local allowed_paths_toplevel=(
"${allowed_common_dirs[@]}"
boot dev etc opt srv usr var
-   nix # sys-apps/nix, bug #670902
-   gnu # sys-apps/guix, bug #670902
)
 
# directories in /usr which can be installed to by ebuilds
-- 
2.24.1




[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 are no real technical obstacles to it aside from
an install-time QA warning about the path.

Before GLEP81, the efficacy of this check was unarguable. With
enewuser, you could still set a user's home directory to a location
under /home, but the lack of a "keepdir" meant that it would fly under
the radar during the QA check. As a result, the QA check would only
flag truly problematic files. With GLEP81, however, an implementation
detail leads this check to flag the user's home directory.

This commit makes an exception for the home directory /home/${PN}
itself, and the /home/${PN}/.keep* file it contains. This lets us
migrate existing user.eclass ebuilds to GLEP81 without triggering a
new QA warning on a dummy file.

This will be useful in at least two real situations:

  * The "amavis" user exists to launch the amavisd daemon, but much of
the configuration for that user is created in $HOME by a human who
is logged in as "amavis" interactively. This is user data by any
definition, and should be stored in /home/amavis rather than
dumping it in the daemon's working directory.

  * The "spamd" user gets its SpamAssassin configuration the same way
local users do in a traditional UNIX mail setup: by reading it out
of $HOME. This is user data, even though it happens to affect the
daemon. With user.eclass, /home/spamd is already used as the home
directory. When migrating to GLEP81, we should not break existing
systems and force a migration just to avoid an old warning.

There are other potential uses as well. If I want to share (real
human) user accounts across multiple Gentoo installs per the design of
GLEP81, then I can do that with acct-user packages in an overlay. The
user packages ensure that the same UIDs and GIDs get used on every
system, but if I do this with my "mjo" account, I'm going to want
/home/mjo to be my home directory. There's nothing wrong with that,
so we shouldn't warn about it.
---
 metadata/install-qa-check.d/08gentoo-paths | 27 ++
 1 file changed, 27 insertions(+)

diff --git a/metadata/install-qa-check.d/08gentoo-paths 
b/metadata/install-qa-check.d/08gentoo-paths
index 5161aef9922..ab9bd64d0e0 100644
--- a/metadata/install-qa-check.d/08gentoo-paths
+++ b/metadata/install-qa-check.d/08gentoo-paths
@@ -19,6 +19,10 @@ gentoo_path_check() {
boot dev etc opt srv usr var
)
 
+   # We make an exception and allow acct-user packages to install to
+   # /home in rare circumstances.
+   [[ "${CATEGORY}" == "acct-user" ]] && allowed_paths_toplevel+=( home )
+
# directories in /usr which can be installed to by ebuilds
# /usr/games is not included as it is banned nowadays
local allowed_paths_usr=(
@@ -61,6 +65,29 @@ gentoo_path_check() {
fi
done
 
+   # Normally ebuilds should not install anything under /home. If this
+   # is a GLEP81 user package, however, we make an exception for the
+   # user's home directory itself and the ".keep" file within it. This
+   # allows GLEP81 user packages to have home directories under /home,
+   # which can be useful if the account is meant to be used by a human
+   # to store configuration data or run maintenance tasks.
+   if [[ "${CATEGORY}" == "acct-user" ]]; then
+   local f found=()
+   while read -r -d '' f; do
+   found+=( "${f}" )
+   done < <(find -L "${ED%/}/home" \
+ -mindepth 1 \
+ -maxdepth 2 \
+ ! -path "${ED%/}/home/${PN}" \
+ ! -path "${ED%/}/home/${PN}/.keep*" \
+ -print0)
+
+   if [[ ${found[@]} ]]; then
+   # mimic the output for non-acct-user packages.
+   bad_paths+=( "/home" )
+   fi
+   fi
+
${shopt_save}
 
# report
-- 
2.24.1




[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-check.d/08gentoo-paths | 29 --
 1 file changed, 27 insertions(+), 2 deletions(-)

-- 
2.24.1




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 belongs?
> 
> Uh, I'm pretty confident that nothing in my /home is owned by a UID
> under 1000, or has an ACL referencing such a UID.  I just checked with
> myself and I don't want you creating directories in /home.

This is retarded, stop wasting my time.


>>>
>>> I mean, would it kill you to just talk to QA first?
>>
>> I've already got responses from two QA members. This thread is pretty
>> hard to miss.
> 
> Well, then why go posting stuff like "guess we'll be triggering a
> warning after all?"

If these two things are logically connected, I don't see it.


> 
>> I'm working on a patch for the install-qa-check.d check
>> and I'm sure I'll get more when I post it.
> 
> Are you just allowing it to not create the directory, or are we
> considering patching it to allow creating stuff under /home?  It would
> seem that the policy would also need updating in that case, but
> probably not the former.
> 

The patch will make an exception for acct-user packages only; for /home,
/home/${PN}, and /home/${PN}/.keep*. In other words, it makes things
work exactly how they did before the GLEP81 eclass started keepdir'ing
the home directory.



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 these ownership issues
> periodically and treat those responsible for them appropriately.

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


> On the topic of treating those responsible appropriately, somehow I
> could see this scenario turning into a quiz question.
> 
> I mean, would it kill you to just talk to QA first?

I've already got responses from two QA members. This thread is pretty
hard to miss. I'm working on a patch for the install-qa-check.d check
and I'm sure I'll get more when I post it.



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 warning gets
shown anyway (for a file that's not there, noice).

Guess we'll be triggering a warning after all.



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 can't go
> creating stuff with the wrong UID anyway.

That's not enough. You also need to sync any user/group that appears as
the owner or group of a file in /home, and every user/group that appears
in an ACL in /home, and so on. And since you have no idea what files or
access control lists will show up in /home, you'd better sync them all.


>> We've talked this to death. Barring any new evidence, /home still seems
>> like the best place for these, and I don't want to put them in the wrong
>> spot (forcing users to migrate) just to appease a QA warning from before
>> GLEP81 was a thing.
> 
> Well, great, then by all means ask QA for a policy exception.  Not my
> place to yell at you if you don't, but don't be surprised if somebody
> else does...
> 

I'm not going to violate the policy, I'm going to delete the keepdir
file from $D. Then everything is back to normal.

If I was willing to introduce a QA warning, this thread would have been
a lot shorter =P



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 always has been.
> ---
> 
> So my question is "why not leave the homedir unset, or set it to /dev/null?"
> The claim is that the daemon doesn't need a home directory, so why are
> we trying to make one?
> 

Ah, good question. As the de facto no-homedir police, even I think this
case warrants an exception. Technically, the daemon's user does not need
a home directory. But almost everyone that uses amavis will want to
combine it with one of these programs that looks in $HOME.

We could install the user with no homedir, and make the people who need
it override the acct-user ebuild in an overlay, but that's a pain in the
butt. Since the common case will utilize a home directory, I'd rather
pick one decent location upstream, and not have 99% of users define one
ad-hoc in an overlay.

The reason I'm being so annoying is because it's important to get the
location right. Every time the user package is reinstalled, its homedir
gets reset. So it's non-trivial to override, and can't really be changed
in an ebuild (usermod fails if the user is running a process).



  1   2   3   4   5   6   7   8   9   >