[gentoo-dev] Last Rites: games-strategy/liquidwar6
# Matt Turner (2019-09-01) # Depends on dev-scheme/guile:12. Unpackaged versions from 2015. # Removal in 30 days. # Bug #654654. games-strategy/liquidwar6 signature.asc Description: PGP signature
[gentoo-dev] Last Rites: sci-chemistry/burrow-owl and dependencies
# Matt Turner (2019-09-01) # dev-scheme/guile-gnome-platform depends on dev-scheme/guile:12. Its only # reverse dependency is sci-chemistry/burrow-owl, so include it. The others are # dependencies of sci-chemistry/burrow-owl as well, and it is their only # reverse dependency. # Bug #693290. dev-libs/g-wrap dev-scheme/guile-cairo dev-scheme/guile-gnome-platform dev-scheme/guile-lib sci-chemistry/burrow-owl sci-libs/starparse signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] Mass last-riting of x86-but-not-amd64 packages
On Sat, Aug 31, 2019 at 1:04 AM Michał Górny wrote: > sys-fs/hfsplusutils Your script should probably check for other keywords as well. This package is almost entirely for use on ppc/ppc64 machines. For whatever reason it has an x86 keyword as well, so the lack of an amd64 keyword doesn't indicate that it should be removed.
Re: [gentoo-dev] [RFC] package.deprecated to mark packages deprecated and report dependencies
On Fri, Aug 16, 2019 at 10:10 AM Michał Górny wrote: > > Hi, > > leio asked me yesterday for the possibility of marking packages > as deprecated, so that CI would issue warnings when other packages > depend on them. I think that's quite a good idea, so I'd like to > propose a simple implementation for it. > > The idea is to provide profiles/package.deprecated using the same format > as package.mask. However, unlike the latter it wouldn't cause any user- > visible results but only affect pkgcheck (and possibly repoman, if > someone writes the check). > > Basically you'd put something like: > > # name (date) > # We don't like this package anymore, so we want to remove it ASAP. > dev-foo/bar > > # name (date) > # Old slot is not nice at all. > dev-bar/frobnicate:0.1 > > # name (date) > # Nononono, don't use that. >11.0 > > This would cause matching packages to be marked as deprecated. It > wouldn't affect normal install behavior but pkgcheck/CI would complain > if any package had a dependency that can only be satisfied > by the deprecated packages. > > What do you think? I think it's a great idea. It would have been perfect for the x11-proto/* -> x11-base/xorg-proto transition.
Re: [gentoo-dev] mark ppc64le profiles stable
Looks great!
Re: [gentoo-dev] [PATCH] xorg-3.eclass: Add XORG_TARBALL_SUFFIX
On Mon, Aug 12, 2019 at 3:29 PM Ulrich Mueller wrote: > > >>>>> On Tue, 13 Aug 2019, Matt Turner wrote: > > > +# Even though xz-utils are in @system, they must still be added to DEPEND; > > see > > +# > > https://archives.gentoo.org/gentoo-dev/msg_a0d4833eb314d1be5d5802a3b710e0a4.xml > > I didn't understand that argument in 2011, and I understand it even > less in 2019. Why would we add xz but not bzip2 and tar as dependencies? > > The devmanual is clear on this: > https://devmanual.gentoo.org/general-concepts/dependencies/index.html#implicit-system-dependency Thanks. I'm happy to drop that block. I copied the code from gnome.org.eclass and figured that was the best thing to do to not rock the boat.
[gentoo-dev] [PATCH] xorg-3.eclass: Add XORG_TARBALL_SUFFIX
To allow overriding the tarball type.
Signed-off-by: Matt Turner
---
eclass/xorg-3.eclass | 18 +-
1 file changed, 17 insertions(+), 1 deletion(-)
diff --git a/eclass/xorg-3.eclass b/eclass/xorg-3.eclass
index f135058fba6..bd857e1cca2 100644
--- a/eclass/xorg-3.eclass
+++ b/eclass/xorg-3.eclass
@@ -89,10 +89,26 @@ fi
HOMEPAGE="https://www.x.org/wiki/
https://gitlab.freedesktop.org/xorg/${XORG_MODULE}${XORG_PACKAGE_NAME}";
+# @ECLASS-VARIABLE: XORG_TARBALL_SUFFIX
+# @DESCRIPTION:
+# Most X11 projects provide tarballs as tar.bz2 or tar.xz. This eclass defaults
+# to bz2.
+: ${XORG_TARBALL_SUFFIX:="bz2"}
+
+# Even though xz-utils are in @system, they must still be added to DEPEND; see
+#
https://archives.gentoo.org/gentoo-dev/msg_a0d4833eb314d1be5d5802a3b710e0a4.xml
+if [[ ${XORG_TARBALL_SUFFIX} == "xz" ]]; then
+ if [[ ${EAPI:-0} != [0123456] ]]; then
+ BDEPEND="app-arch/xz-utils"
+ else
+ DEPEND="app-arch/xz-utils"
+ fi
+fi
+
if [[ -n ${GIT_ECLASS} ]]; then
:
${EGIT_REPO_URI:="https://gitlab.freedesktop.org/xorg/${XORG_MODULE}${XORG_PACKAGE_NAME}.git"}
elif [[ -n ${XORG_BASE_INDIVIDUAL_URI} ]]; then
- SRC_URI="${XORG_BASE_INDIVIDUAL_URI}/${XORG_MODULE}${P}.tar.bz2"
+
SRC_URI="${XORG_BASE_INDIVIDUAL_URI}/${XORG_MODULE}${P}.tar.${XORG_TARBALL_SUFFIX}"
fi
: ${SLOT:=0}
--
2.21.0
Re: [gentoo-dev] [RFC] Moving UID/GID assignments to api.gentoo.org
On Sun, Aug 11, 2019 at 3:54 PM William Hubbs wrote: > > On Sun, Aug 11, 2019 at 03:04:02PM -0700, Matt Turner wrote: > > On Sun, Aug 11, 2019 at 12:48 PM William Hubbs wrote: > > > If we are going to require a modeline, shouldn't we consider allowing > > > them by default so we can work out of the box instead of having to tweak > > > our editor settings? > > > > Perhaps we should. Is this really an important point for you? > > > > I don't think any of that needs to hold up Michał's proposal though. > > Let's move away from talking about alignment for a minute. > > The reason I responded originally was that his proposal is a bit > vague. It says that whitespace separates fields; that could be spaces > or tabs. whitespace can also be a completely valid character in > the notes field. So, since he says we can add more fields in the future, > you either have to escape whitespace in the notes field or quote the > field. > > Also, he may have used one whitespace character to separate fields in his > example, but the spec allows any number of whitespace characters. Sigh. The intention is to make it easily machine parseable and easily readable by humans. One or more whitespace characters is easy to recognize by a machine, be they space or tabs. Aligned columns are easily readable by humans. I think humans are able to follow existing convention when adding new lines to the file and don't require specific rules like this. There's nothing unclear or vague in his explanation. Can we please proceed?
Re: [gentoo-dev] [RFC] Moving UID/GID assignments to api.gentoo.org
On Sun, Aug 11, 2019 at 12:48 PM William Hubbs wrote:
>
> On Sat, Aug 10, 2019 at 05:41:56PM -0700, Matt Turner wrote:
> > On Sat, Aug 10, 2019 at 1:49 PM William Hubbs wrote:
> > >
> > > On Tue, Aug 06, 2019 at 11:29:50PM +0200, Michał Górny wrote:
> > > > Hi,
> > > >
> > > > Some time ago William asked me to move UID/GID assignments from wiki [1]
> > > > to something more accessible. I've finally gotten around to draft
> > > > something, and I'd like to hear your comments about it. The idea is to
> > > > keep a whitespace-separated record format file in api.gentoo.org repo.
> > > >
> > > > This is mostly inspired by Fedora's format, specifically the ability to
> > > > specify both UID and GID for matching user/group on the same line.
> > > > I've also decided not to attempt to specify disjoint Linux and FreeBSD
> > > > users/groups on a single line. Instead, they are specified separately
> > > > and defined by providers (as suggested by Ulrich).
> > > >
> > > > Sample, along with big comment explaining the file format, below.
> > >
> > > I'm not sure how I feel about whitespace delimiters for this. withno
> > > further specification, it would make these two lines completely valid:
> > >
> > > root 0 0 baselayout
> > > bin 1 1
> > > baselayout some notes here
> >
> > That's true, but I think with editor settings embedded in the file and
> > visual pattern of vertical alignment we shouldn't expect a bunch of
> > problems.
>
> We don't honor editor settings in files by default, so this will not
> work out of the box (see this in /etc/vim/vimrc).
>
> --- cut here ---
> " {{{ Modeline settings
> " We don't allow modelines by default. See bug #14088 and bug #73715.
> " If you're not concerned about these, you can enable them on a per-user
> " basis by adding "set modeline" to your ~/.vimrc file.
> set nomodeline
> " }}}
> --- cut here ---
>
> If we are going to require a modeline, shouldn't we consider allowing
> them by default so we can work out of the box instead of having to tweak
> our editor settings?
Perhaps we should. Is this really an important point for you?
I don't think any of that needs to hold up Michał's proposal though.
Re: [gentoo-dev] [RFC] Moving UID/GID assignments to api.gentoo.org
On Sat, Aug 10, 2019 at 1:49 PM William Hubbs wrote: > > On Tue, Aug 06, 2019 at 11:29:50PM +0200, Michał Górny wrote: > > Hi, > > > > Some time ago William asked me to move UID/GID assignments from wiki [1] > > to something more accessible. I've finally gotten around to draft > > something, and I'd like to hear your comments about it. The idea is to > > keep a whitespace-separated record format file in api.gentoo.org repo. > > > > This is mostly inspired by Fedora's format, specifically the ability to > > specify both UID and GID for matching user/group on the same line. > > I've also decided not to attempt to specify disjoint Linux and FreeBSD > > users/groups on a single line. Instead, they are specified separately > > and defined by providers (as suggested by Ulrich). > > > > Sample, along with big comment explaining the file format, below. > > I'm not sure how I feel about whitespace delimiters for this. withno > further specification, it would make these two lines completely valid: > > root 0 0 baselayout > bin 1 1 baselayout > some notes here That's true, but I think with editor settings embedded in the file and visual pattern of vertical alignment we shouldn't expect a bunch of problems. Michał's original proposal is very readable. Just because it's a "data file" I don't think we should go out of our way to limit readability.
[gentoo-dev] Last Rites: sci-physics/meep, sci-physics/harminv, sci-libs/libctl
# Matt Turner (2019-08-02) # Unmaintained in Gentoo. Incompatible with guile-2 # Masked for removal in 30 days, Bugs #685540, #629058 sci-libs/libctl sci-physics/harminv sci-physics/meep signature.asc Description: PGP signature
[gentoo-dev] Last Rites: mail-filter/anubis
# Matt Turner (2019-08-02) # Incompatible with guile-2. No longer a use case # Masked for removal in 30 days, Bugs #617792 mail-filter/anubis signature.asc Description: PGP signature
[gentoo-dev] Last Rites: sci-mathematics/drgeo
# Matt Turner (2019-08-02) # Incompatible with guile-2 # Masked for removal in 30 days, Bugs #592188 sci-mathematics/drgeo signature.asc Description: PGP signature
[gentoo-dev] Last Rites: x11-libs/guile-gtk
# Matt Turner (2019-08-02) # Unmaintained. Incompatible with guile-2 # Masked for removal in 30 days, Bugs #641864, #647536, #688244 x11-libs/guile-gtk signature.asc Description: PGP signature
[gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/
On Mon, Jul 29, 2019 at 10:20 PM Michał Górny wrote:
>
> On Tue, 2019-07-30 at 01:49 +, Matt Turner wrote:
> > commit: 6f680e4fe73925ae130343e02adb416cb799ce7d
> > Author: Chris Mayo gmail com>
> > AuthorDate: Fri Jul 26 18:48:13 2019 +
> > Commit: Matt Turner gentoo org>
> > CommitDate: Tue Jul 30 01:49:41 2019 +
> > URL:https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=6f680e4f
> >
> > virtualx.eclass: Fix no display for an emerge following a failure
> >
> > If using GNOME GDM, X is started on DISPLAY :0 but a lock file
> > /tmp/.X1024-lock is created instead of /tmp/.X0-lock.
> > virtx() will initially set XDISPLAY to 0 and attempt to start Xvfb on
> > DISPLAY :0 which fails but DISPLAY :1 (and greater) is not attempted if
> > a previous emerge left /tmp/.X1-lock behind.
> >
> > Closes: https://bugs.gentoo.org/690778
> > Signed-off-by: Chris Mayo gmail.com>
> > Signed-off-by: Matt Turner gentoo.org>
> >
> > eclass/virtualx.eclass | 7 +--
> > 1 file changed, 5 insertions(+), 2 deletions(-)
> >
> > diff --git a/eclass/virtualx.eclass b/eclass/virtualx.eclass
> > index fb6a867a35c..40eeea5463b 100644
> > --- a/eclass/virtualx.eclass
> > +++ b/eclass/virtualx.eclass
> > @@ -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
> >
> > # @ECLASS: virtualx.eclass
> > @@ -178,7 +178,10 @@ virtx() {
> > # Xvfb is started, else bump the display number
> > #
> > # Azarah - 5 May 2002
> > - XDISPLAY=$(i=0; while [[ -f /tmp/.X${i}-lock ]] ; do ((i++));done;
> > echo ${i})
> > + # GNOME GDM may have started X on DISPLAY :0 with a
> > + # lock file /tmp/.X1024-lock, therefore start the search at 1.
> > + # Else a leftover /tmp/.X1-lock will prevent finding an available
> > display.
> > + XDISPLAY=$(i=1; while [[ -f /tmp/.X${i}-lock ]] ; do ((i++));done;
> > echo ${i})
> > debug-print "${FUNCNAME}: XDISPLAY=${XDISPLAY}"
> >
> > # We really do not want SANDBOX enabled here
>
> Isn't this a cheap hack that doesn't fix the underlying issue but shifts
> the problem into hopefully-won't-happen-this-time?
Yes, but given that the prior code was a cheap hack as well (from
2002, no less!) and has worked out well enough for 17 years that no
one has reported problems with it until now, I don't think it's
critical to make it bullet-proof.
Of course I'm happy to accept patches.
> Also, why are you skipping mailing list review for eclass changes?
Ah, you are right. My apologies.
Re: [gentoo-dev] [RFC] New QA policy: Packages must not disable installing manpages via USE flags
On Sat, Jul 20, 2019 at 1:22 PM Michał Górny wrote: > > On Sat, 2019-07-20 at 23:04 +0300, Andrew Savchenko wrote: > > On Sat, 20 Jul 2019 20:28:39 +0200 Michał Górny wrote: > > > On Sat, 2019-07-20 at 20:50 +0300, Andrew Savchenko wrote: > > > > On Wed, 17 Jul 2019 15:25:10 +0200 Michał Górny wrote: > > > > > Hello, > > > > > > > > > > The QA team would like to introduce the following policy: > > > > > > > > > > """ > > > > > Packages must not disable installing manpages via USE flags (e.g. > > > > > USE=man or USE=doc). If upstream does not ship prebuilt manpages > > > > > and building them requires additional dependencies, the maintainer > > > > > should build them and ship along with the package. > > > > > """ > > > > > > > > > > > > > > > Explanatory note: > > > > > > > > > > This applies to having USE flags that specifically control building > > > > > manpages. It obviously does not affect: > > > > > > > > > > a. USE flags that disable building both a program and its manpage > > > > > (e.g. > > > > > if USE=gui disables building gfrobnicate, not installing > > > > > gfrobnicate(1) > > > > > is correct), > > > > > > > > > > b. use of LINGUAS to control installed manpages. > > > > > > > > > > > > > > > Rationale: > > > > > > > > > > Manpages are the basic form of user documentation on Gentoo Linux. > > > > > Not > > > > > installing them is harmful to our users. On the other hand, requiring > > > > > additional dependencies is inconvenient. Therefore, packaging > > > > > prebuilt > > > > > manpages (whenever upstream doesn't do that already) is a good > > > > > compromise that provides user with documentation without additional > > > > > dependencies. > > > > > > > > > > > > > > > What are your comments? > > > > > > > > The basic foundation of Gentoo is freedom of choise for our users. > > > > If installing man pages means no additional dependencies, than > > > > proposed rule is ok. However if such dependencies are required it is > > > > up to users to decide if they wan them or not. > > > > > > > > Having USE=man (or USE=doc) for such purposes is fine. Having > > > > USE=man enabled by default in user profile is also fine. Forcing > > > > users to install unnecessary dependencies on minimal systems in a > > > > no go and turns Gentoo into something else. > > > > > > > > > > Could you please read the proposed policy? It explicitly says you are > > > *not* supposed to force extra deps on users but build manpages for them. > > > > Could you please what the other developers have already replied to > > you on this matter? This will be a significant increase in > > maintenance burden for both developers and advanced users without > > much to gain. > > > > Yes, I get it. User experience is not important if it would mean > developers would actually do anything but the bare minimum to get > from one paycheck to another. The usual Gentoo attitude. I don't understand your reaction, but it's very common with predictable steps to generate it: 1) You make a proposal 2) People offer feedback and ask questions 3) You respond combatively (or not at all), as if you are upset that people perhaps are not 100% aligned with your view. ... which honestly shouldn't be at all unexpected and is precisely why requesting comments on a proposal is valuable. My question earlier in the thread is relevant and still unaddressed.
Re: [gentoo-dev] [PATCH] CPU_FLAGS_X86: Introduce 'sha' flag
On Thu, Jul 18, 2019 at 7:53 AM Michał Górny wrote: > > Introduce 'sha' flag that corresponds to SHA-NI instruction set. > This has two potential users, and is present in git version > of cpuid2cpuflags (pending release once the flag is added). Ack
Re: [gentoo-dev] [RFC] New QA policy: Packages must not disable installing manpages via USE flags
On Wed, Jul 17, 2019 at 6:25 AM Michał Górny wrote: > > Hello, > > The QA team would like to introduce the following policy: > > """ > Packages must not disable installing manpages via USE flags (e.g. > USE=man or USE=doc). Xorg libraries use USE=doc to control the build (sometimes) and installation of thousands of developer-documentation man pages. 99.9% of the time users don't want the developer man pages installed. With USE=-doc the packages still install man pages for the applications, just not the developer documentation man pages. Is that not reasonable?
Re: [gentoo-dev] [PATCH] CPU_FLAGS_X86: add global 'f16c' flag
Both this and the avx512f change look good to me.
[gentoo-dev] Re: Proposed last rites for sci-chemistry/coot and a bunch of reverse dependencies
Thanks. Done, except for x11-libs/guile-gtk which is still a dependency of the current stable sci-electronics/gwave. Bug: https://bugs.gentoo.org/639760
[gentoo-dev] Proposed last rites for sci-chemistry/coot and a bunch of reverse dependencies
I was investigating what needs to be done to drop guile-1.8 from the
tree (bug 590558, 587252). sci-chemistry/coot is one of the blocking
packages (bug 591410). It has a version bump request open for 18
months (bug 639760) and hasn't been maintained in as long. The new
version doesn't appear to work with guile-2.0 either, though it seems
that it may be possible to build without guile? Something for a
maintainer...
If we just drop it, we can remove the following dependencies as well:
sci-chemistry/coot (no rev deps)
sci-libs/coot-data (rev deps: sci-chemistry/coot)
sci-libs/ssm (rev deps: sci-chemistry/coot)
sci-libs/gpp4 (no rev deps)
sci-libs/cctbx (no rev deps)
sci-libs/clipper (rev deps: sci-chemistry/coot, sci-libs/cctbx)
sci-libs/libccp4 (rev deps: sci-chemistry/coot, sci-libs/{clipper,ssm}
sci-libs/monomer-db (rev deps: sci-chemistry/coot)
sci-libs/mmdb (rev deps: sci-chemistry/coot,
sci-libs/{clipper,gpp4,libcpp4,ssm}
sci-chemistry/reduce (rev deps: sci-chemistry/coot)
dev-scheme/guile-gui (rev deps: sci-chemistry/coot; dead home page)
dev-scheme/guile-www (rev deps: sci-chemistry/coot)
dev-scheme/net-http (rev deps: sci-chemistry/coot; dead home page)
x11-libs/guile-gtk (rev deps: dev-scheme/guile-gui, dev-scheme/guile-gui)
Thoughts?
[gentoo-dev] Re: EAPI 2 must die
On Wed, Jun 5, 2019 at 11:39 PM Agostino Sarubbo wrote: > > On giovedì 6 giugno 2019 08:25:54 CEST Luca Barbato wrote: > > Anybody has hardware to test it? > > I can do it on timberdoodle. The issue is that the package is for "OldWorld" Macs (like 20+ years old). We recently dropped the bootloader, sys-boot/quik, so I think we'd be fine to drop sys-apps/powerpc-utils as well.
Re: [gentoo-dev] Rethinking multilib flags in Gentoo
On Wed, May 8, 2019 at 3:19 AM Alexis Ballier wrote: > > On Wed, 08 May 2019 12:01:21 +0200 > Michał Górny wrote: > > > On Wed, 2019-05-08 at 11:54 +0200, Alexis Ballier wrote: > > > On Wed, 08 May 2019 11:41:41 +0200 > > > Michał Górny wrote: > > > > > > > > There's multilib that adds a lot of flags with a single eclass > > > > > change, but I'd guess the number of packages and flags is > > > > > constantly growing, so sooner or later you'll be hit by this > > > > > again and no multilib killing will help you then. > > > > > > > > > > I think it is more future proof to use the addition of multilib > > > > > flags to fix pkgcheck rather than actively reducing the number > > > > > of multilib flags to cope with its limitations. > > > > > > > > Then please do it, by all means. The reality is simple. If the > > > > tool is broken, you either fix it or stop doing what you know > > > > that breaks it. Being unable to do the former, and having no good > > > > replacement, I'd go for the latter. > > > > > > Well, why is it slow ? IO ? CPU ? Did you collect profiling data ? > > > > CPU definitely. More detail than that, I don't and I don't have time > > to investigate. > > So you don't have time to change 3 lines to add cProfile but do have > time to send various emails and rework the entire multilib system ? > weird. This isn't productive. If you'd like to do the work you're suggesting, I'm sure Michał will support that, but as is you're just passive-aggressively questioning his choices in the regards to the multilib system he created and the CI system he created.
[gentoo-dev] Re: Rethinking multilib flags in Gentoo
On Tue, May 7, 2019 at 2:47 PM Michał Górny wrote: > On the other hand, if I am consider the benefit of having large number > of flags that will never benefit the majority of users (if anyone) > vs. having much faster CI (= being able to run it more frequently, > and therefore report problems faster), you can guess which way I prefer. Does mips' multilib support affect CI since all the profiles are 'exp'? Presumably it's something we'd have to think a lot about if we ever wanted to promote the mips profiles...
Re: [gentoo-dev] Retirement / packages up for grabs
On Mon, Apr 8, 2019 at 8:51 PM Austin English wrote: > > Howdy all, > > I haven't had much time for Gentoo lately, so I'm turning in my keys. > It's been a great learning experience, and I hope my contributions were > helpful. Best of luck on your future endeavors. I'm sorry to see you go. Thank you for your contributions and good luck to you in the future :) > media-gfx/xdot I'll take this.
Re: [gentoo-dev] Fwd: [gentoo-commits] repo/gentoo:master commit in: dev-libs/elfutils/
On Sat, Apr 6, 2019 at 8:31 AM Andreas K. Huettel wrote: > > Public service announcement: Calling for stabilization requires maintainer > acknowledgment. > > While there may be parts of Gentoo where this requirement is seen a bit more > loosely, it is definitely true for TOOLCHAIN and BASE-SYSTEM. Just want to emphasize: this isn't a complaint about toe-stepping. This version actually cannot be stabilized yet because it will cause kernels to fail to build.
Re: [gentoo-dev] Packages up for grabs due to samba project being disbanded
On Wed, Mar 27, 2019 at 1:26 PM Michał Górny wrote: > > On Wed, 2019-03-27 at 12:18 -0700, Matt Turner wrote: > > On Wed, Mar 27, 2019 at 10:04 AM Michał Górny wrote: > > > The samba project will most likely be disbanded shortly. While > > > the current project members may stay as fallback maintainers, > > > the following packages (being part of the Samba stack) would really use > > > new, dedicated maintainers: What are you basing that on? I see Lars bumping Samba/talloc/tdb/tevent consistently. (Those are the only ones I checked)
Re: [gentoo-dev] (Lots of) Packages up for grabs due to net-mail@ project disbanding
On Wed, Mar 27, 2019 at 12:23 PM Michael Orlitzky wrote: > > On 3/27/19 3:19 PM, Matt Turner wrote: > >> > >> You got it: I just pushed 17 commits, addressing ~5 open bugs. I've > >> added you, klondike, proxy-maint, and myself as maintainers. > > > > Nice. I'm curious: what were you waiting on before? > > > > It was pretend-maintained by net-mail, and I wasn't a member of the > project. Most of the changes were available as part of bug 629914 > though, so it's not like I was keeping them secret. Makes sense. I suppose this is exactly the reason we want to disband these herd-projects.
Re: [gentoo-dev] Packages up for grabs due to samba project being disbanded
On Wed, Mar 27, 2019 at 10:04 AM Michał Górny wrote: > The samba project will most likely be disbanded shortly. While > the current project members may stay as fallback maintainers, > the following packages (being part of the Samba stack) would really use > new, dedicated maintainers: I understand disbanding projects when they're really just the old "herd" concept, but this actually looks like a coherent set of packages that a project should maintain. I don't see a bug about disbanding samba. What's the rationale?
Re: [gentoo-dev] (Lots of) Packages up for grabs due to net-mail@ project disbanding
On Wed, Mar 27, 2019 at 10:28 AM Michael Orlitzky wrote: > > On 3/26/19 5:09 PM, Ralph Seichter wrote: > > * Michael Orlitzky: > > > >> I'd be happy to work on all of that stuff either before or after you > >> guys take over and get settled in. > > > > I'd appreciate you adding all improvements you already have in store. > > It would be a shame to waste the work you have already done. > > > > You got it: I just pushed 17 commits, addressing ~5 open bugs. I've > added you, klondike, proxy-maint, and myself as maintainers. Nice. I'm curious: what were you waiting on before?
Re: Re[2]: [gentoo-dev] Last rites: sys-boot/raspberrypi-firmware
On Fri, Mar 15, 2019 at 2:55 PM Conrad Kostecki wrote: > > Hi! > > Am 15.03.2019 20:29:11, "Matt Turner" schrieb: > > On Fri, Mar 15, 2019 at 7:04 AM Conrad Kostecki wrote: > > > > Do you know something about media-libs/raspberrypi-userland as well? > I'm hoping to enable libglvnd support in media-libs/mesa and > x11-drivers/nvidia-drivers soon, and this is the only other package in > Gentoo that uses app-eselect/eselect-opengl. > > Do we care to keep this now that Mesa's vc4 driver is in good shape? > > At least, I've somewhere my modified release, which I've fixed for > myself, since there were some bugs and added eselect-opengl support to this. > What do you mean exactly with libglvnd or at what do you want to know? libglvnd is the "GL Vendor-Neutral Dispatch library" [0]. It provides libGL, libGLESv1_CM, libGLESv2, etc, and then dispatches those calls to the underlying hardware driver. This allows a single libGL.so to work for Mesa and nvidia-drivers for example. If media-libs/raspberrypi-userland doesn't support libglvnd (which it doesn't as far as I can tell) that kind of throws a wrench in the plan for IMO minimal benefit. [0] https://github.com/NVIDIA/libglvnd
Re: [gentoo-dev] Last rites: sys-boot/raspberrypi-firmware
On Fri, Mar 15, 2019 at 6:16 PM Chí-Thanh Christopher Nguyễn wrote: > > Matt Turner schrieb: > >> Do you know something about media-libs/raspberrypi-userland as well? > >> I'm hoping to enable libglvnd support in media-libs/mesa and > >> x11-drivers/nvidia-drivers soon, and this is the only other package in > >> Gentoo that uses app-eselect/eselect-opengl. > >> > >> Do we care to keep this now that Mesa's vc4 driver is in good shape? > > There are uses for raspberrypi-userland which the vc4 driver (last I checked > at least) does not cover very well. > > The most important one is support for the 256 MB RAM devices (original RPi > Model B), which works fine on raspberrypi-userland. vc4 still has issues if > less than 256 MB RAM are allocated to the GPU. That sounds like an awful device to run Gentoo on. I'd like to require libglvnd for all libGL providers and get rid of app-eselect/eselect-opengl. What do you suggest we do about raspberrypi-userland?
Re: [gentoo-dev] Last rites: sys-boot/raspberrypi-firmware
On Fri, Mar 15, 2019 at 12:29 PM Matt Turner wrote: > > On Fri, Mar 15, 2019 at 7:04 AM Conrad Kostecki wrote: > > > # Michael Weber (17 Jul 2013) > > > # Upstream next versions > > > # Michał Górny (15 Mar 2019) > > > # No single unmasked version since. Removal in 30 days. Bug #671238. > > > >=sys-boot/raspberrypi-firmware-1_pre > > > > Could we keep this package? I can take it, and make a proper release, if > > that would be enough to keep this package? I am using this on my gentoo > > with my Rpi3. > > Do you know something about media-libs/raspberrypi-userland as well? > I'm hoping to enable libglvnd support in media-libs/mesa and > x11-drivers/nvidia-drivers soon, and this is the only other package in > Gentoo that uses app-eselect/eselect-opengl. > > Do we care to keep this now that Mesa's vc4 driver is in good shape? Using correct email address for chithanh this time.
Re: [gentoo-dev] Last rites: sys-boot/raspberrypi-firmware
On Fri, Mar 15, 2019 at 7:04 AM Conrad Kostecki wrote: > > # Michael Weber (17 Jul 2013) > > # Upstream next versions > > # Michał Górny (15 Mar 2019) > > # No single unmasked version since. Removal in 30 days. Bug #671238. > > >=sys-boot/raspberrypi-firmware-1_pre > > Could we keep this package? I can take it, and make a proper release, if that > would be enough to keep this package? I am using this on my gentoo with my > Rpi3. Do you know something about media-libs/raspberrypi-userland as well? I'm hoping to enable libglvnd support in media-libs/mesa and x11-drivers/nvidia-drivers soon, and this is the only other package in Gentoo that uses app-eselect/eselect-opengl. Do we care to keep this now that Mesa's vc4 driver is in good shape?
Re: [gentoo-dev] Last Rites: sys-fs/cryptmount
On Thu, Mar 7, 2019 at 2:33 AM Conrad Kostecki wrote: > > Hi Matt, > > > Matt Turner hat am 7. März 2019 um 06:34 geschrieben: > > # Matt Turner (06 Mar 2019) > > # Does not build with glibc >= 2.25 (stabilized a year ago). Unmaintained by > > # maintainer-by-proxy: Bugs #628734 and #641176 > > # Removal in 30 days > > sys-fs/cryptmount > > I've submitted a PR for a version bump, which should fix all those bugs. Thank you, and thank you for taking maintainership as well!
[gentoo-dev] Last Rites: sys-fs/cryptmount
Frankly, I think this is a good example of why we shouldn't allow maintainer-by-proxy for random people without a track record of contributions. Especially when they want to *add* a package to the tree. # Matt Turner (06 Mar 2019) # Does not build with glibc >= 2.25 (stabilized a year ago). Unmaintained by # maintainer-by-proxy: Bugs #628734 and #641176 # Removal in 30 days sys-fs/cryptmount signature.asc Description: PGP signature
Re: [gentoo-dev] [PATCH 2/3] xorg-2.eclass: Remove use of prune_libtool_files
On Sat, Mar 2, 2019 at 3:41 PM Mike Gilbert wrote:
>
> On Sat, Mar 2, 2019 at 5:10 PM Michał Górny wrote:
> >
> > On Sat, 2019-03-02 at 16:59 -0500, Mike Gilbert wrote:
> > > On Mon, Feb 25, 2019 at 1:37 AM Ulrich Mueller wrote:
> > > > > > > > > On Wed, 20 Feb 2019, Michał Górny wrote:
> > > > > On Wed, 2019-02-20 at 07:20 +0100, Ulrich Mueller wrote:
> > > > > > > > > > > On Wed, 20 Feb 2019, Matt Turner wrote:
> > > > > > ># Don't install libtool archives (even for modules)
> > > > > > > - prune_libtool_files --all
> > > > > > > + find "${D}" -name '*.la' -delete || die
> > > > > >
> > > > > > Maybe restrict removal to regular files, i.e. add "-type f"?
> > > > > I suppose you should have spoken up when people started adopting that
> > > > > 'find' line all over the place. Though I honestly doubt we're going
> > > > > to see many packages installing '*.la' non-files.
> > > >
> > > > I have updated the example in ltprune.eclass now.
> > > >
> > > > That still won't catch regular non-libtool files, but people needing
> > > > additional sanity checks can still use the eclass.
> > >
> > > Perhaps we should un-ban the ltprune eclass for EAPI 7?
> > >
> > > It seems like it would still be useful to have a way of detecting
> > > libtool-archives instead of removing any file that ends with ".la".
> > >
> >
> > How many valid cases for this are there? For comparison, how many
> > useless complexity will be added to ebuilds by thoughtless maintainers
> > using the first thing that seems to work without actually verifying
> > whether it is necessary?
>
> As a maintainer, any time spent worrying about .la files is wasted
> time. We have code that can figure it out automatically and allow me
> to stop wasting brain power.
Exactly.
Re: [gentoo-dev] Last rites: some old X11 packages
On Sun, Mar 3, 2019 at 1:09 AM Joshua Kinard wrote: > > On 3/2/2019 13:46, Matt Turner wrote: > > # Matt Turner (02 Mar 2019) > > # Old, unused drivers. > > # Masked for removal in 30 days. Bug #679256 > > > x11-drivers/xf86-video-newport > > This is for the SGI Indy's newport graphics board. Does it not build with > modern Xorg or anything, or not maintained upstream? My Indy is dead due to > a bad RTC, so I can't test it for the foreseeable future. Yes, it no longer builds and it requires packed 24-bit color support which has been removed from the xserver. We would have to package an old xserver for -newport to be useful (which is something I'd be interested to do with sufficient time).
[gentoo-dev] Last rites: some old X11 packages
# Matt Turner (02 Mar 2019) # Old, unused drivers. # Masked for removal in 30 days. Bug #679256 x11-drivers/xf86-input-elographics x11-drivers/xf86-video-newport x11-drivers/xf86-video-tdfx x11-drivers/xf86-video-voodoo # Matt Turner (02 Mar 2019) # No reverse dependencies. No releases in 13 years. # Masked for removal in 30 days. Bug #679256 x11-libs/libxkbui signature.asc Description: PGP signature
Re: [gentoo-dev] [PATCH 3/3] xorg-2.eclass: Add EAPI=7 support
On Sun, Feb 24, 2019 at 4:44 AM Matija Skala wrote:
>
> Dne sreda, 20. februar 2019 ob 05:45:41 CET je Matt Turner napisal:
> > + default
> > xorg-2_reconf_source
> > - autotools-utils_src_prepare "$@"
> > +
> > + [[ ${PATCHES} ]] && epatch "${PATCHES[@]}"
> > }
> >
>
> On EAPI=7, this code would apply ${PATCHES} twice.
Thank you! Removed.
Re: [gentoo-dev] [PATCH 2/3] xorg-2.eclass: Remove use of prune_libtool_files
On Fri, Feb 22, 2019 at 8:30 PM desultory wrote:
>
> On 02/20/19 02:36, Michał Górny wrote:
> > On Wed, 2019-02-20 at 07:20 +0100, Ulrich Mueller wrote:
> >>>>>>> On Wed, 20 Feb 2019, Matt Turner wrote:
> >>
> >>
> >>> # Don't install libtool archives (even for modules)
> >>> - prune_libtool_files --all
> >>> + find "${D}" -name '*.la' -delete || die
> >>
> >> Maybe restrict removal to regular files, i.e. add "-type f"?
> >
> > I suppose you should have spoken up when people started adopting that
> > 'find' line all over the place. Though I honestly doubt we're going to
> > see many packages installing '*.la' non-files.
> >
> Just so we are all clear here: your argument is that more fully correct
> approaches should not be considered in the present and future because
> less fully correct approaches were implemented in the past? And,
> further, that since nothing matching a specific pattern happens to come
> to your mind at he moment, such things do not exist? Perhaps dialing
> back the rhetoric from 11 and considering feedback as an opportunity to
> improve existing code is called for in this case, among others.
I think you might be reading more into this than was intended.
I read his email as lamenting that the horse has left the barn, so to
speak. There are already hundreds of uses of find -name '*.la' -delete
without -type f in the tree, probably in large part because
ltprune.eclass suggests the form without it.
Suggesting dialing down the rhetoric when it appears that you have
overreacted is a bit humorous.
[gentoo-dev] [PATCH] xorg-3.eclass: Copy from xorg-2.eclass and add EAPI 7 support
Nearly all the work is just removing uses of autotools-multilib and
autotools-utils.
Bug: https://bugs.gentoo.org/619832
Signed-off-by: Matt Turner
---
Let's just make an xorg-3 eclass to avoid any possibility of breaking
stable things.
Points of concern:
1) The fonts code is dead code as a result of fonts.eclass only
supporting EAPI=6. None of the fonts ebuilds have changed since
the transition to git, so we might just drop that code from
xorg-3 and perhaps ultimately rename xorg-2 to xorg-fonts or
something when all other ebuilds have transitioned?
2) Suggestions welcome for solving https://bugs.gentoo.org/637898
I have no ideas...
3) Meson support? This eclass is pretty autotools focused. Can we
somehow allow Meson support without too much hassle? Maybe it's
not worth it, since I'm not aware of any X11 projects other than
the Xserver to have Meson build systems. I'm happy to punt.
eclass/xorg-3.eclass | 583 +++
1 file changed, 583 insertions(+)
create mode 100644 eclass/xorg-3.eclass
diff --git a/eclass/xorg-3.eclass b/eclass/xorg-3.eclass
new file mode 100644
index 000..fd045122013
--- /dev/null
+++ b/eclass/xorg-3.eclass
@@ -0,0 +1,583 @@
+# Copyright 1999-2019 Gentoo Authors
+# Distributed under the terms of the GNU General Public License v2
+
+# @ECLASS: xorg-3.eclass
+# @MAINTAINER:
+# x...@gentoo.org
+# @AUTHOR:
+# Author: Tomáš Chvátal
+# Author: Donnie Berkholz
+# Author: Matt Turner
+# @SUPPORTED_EAPIS: 7
+# @BLURB: Reduces code duplication in the modularized X11 ebuilds.
+# @DESCRIPTION:
+# This eclass makes trivial X ebuilds possible for apps, fonts, drivers,
+# and more. Many things that would normally be done in various functions
+# can be accessed by setting variables instead, such as patching,
+# running eautoreconf, passing options to configure and installing docs.
+#
+# All you need to do in a basic ebuild is inherit this eclass and set
+# DESCRIPTION, KEYWORDS and RDEPEND/DEPEND. If your package is hosted
+# with the other X packages, you don't need to set SRC_URI. Pretty much
+# everything else should be automatic.
+
+GIT_ECLASS=""
+if [[ ${PV} == ** ]]; then
+ GIT_ECLASS="git-r3"
+ XORG_EAUTORECONF="yes"
+fi
+
+# If we're a font package, but not the font.alias one
+FONT_ECLASS=""
+if [[ ${PN} == font* \
+ && ${CATEGORY} = media-fonts \
+ && ${PN} != font-alias \
+ && ${PN} != font-util ]]; then
+ # Activate font code in the rest of the eclass
+ FONT="yes"
+ FONT_ECLASS="font"
+fi
+
+# @ECLASS-VARIABLE: XORG_MULTILIB
+# @DESCRIPTION:
+# If set to 'yes', the multilib support for package will be enabled. Set
+# before inheriting this eclass.
+: ${XORG_MULTILIB:="no"}
+
+# we need to inherit autotools first to get the deps
+inherit autotools eutils libtool multilib toolchain-funcs \
+ flag-o-matic ${FONT_ECLASS} ${GIT_ECLASS}
+
+if [[ ${XORG_MULTILIB} == yes ]]; then
+ inherit multilib-minimal
+fi
+
+EXPORTED_FUNCTIONS="src_prepare src_configure src_unpack src_compile
src_install pkg_postinst pkg_postrm"
+case "${EAPI:-0}" in
+ 7) ;;
+ *) die "EAPI=${EAPI} is not supported" ;;
+esac
+
+# exports must be ALWAYS after inherit
+EXPORT_FUNCTIONS ${EXPORTED_FUNCTIONS}
+
+IUSE=""
+HOMEPAGE="https://www.x.org/wiki/ https://cgit.freedesktop.org/";
+
+# @ECLASS-VARIABLE: XORG_EAUTORECONF
+# @DESCRIPTION:
+# If set to 'yes' and configure.ac exists, eautoreconf will run. Set
+# before inheriting this eclass.
+: ${XORG_EAUTORECONF:="no"}
+
+# @ECLASS-VARIABLE: XORG_BASE_INDIVIDUAL_URI
+# @DESCRIPTION:
+# Set up SRC_URI for individual modular releases. If set to an empty
+# string, no SRC_URI will be provided by the eclass.
+: ${XORG_BASE_INDIVIDUAL_URI="https://www.x.org/releases/individual"}
+
+# @ECLASS-VARIABLE: XORG_MODULE
+# @DESCRIPTION:
+# The subdirectory to download source from. Possible settings are app,
+# doc, data, util, driver, font, lib, proto, xserver. Set above the
+# inherit to override the default autoconfigured module.
+if [[ -z ${XORG_MODULE} ]]; then
+ case ${CATEGORY} in
+ app-doc) XORG_MODULE=doc/ ;;
+ media-fonts) XORG_MODULE=font/;;
+ x11-apps|x11-wm) XORG_MODULE=app/ ;;
+ x11-misc|x11-themes) XORG_MODULE=util/;;
+ x11-base)XORG_MODULE=xserver/ ;;
+ x11-drivers) XORG_MODULE=driver/ ;;
+ x11-libs)XORG_MODULE=lib/ ;;
+ *) XORG_MODULE= ;;
+ esac
+fi
+
+# @ECLASS-VARIABLE: XORG_PACKAGE_NAME
+# @DESCRIPTION:
+# For git checkout t
Re: [gentoo-dev] [PATCH 2/3] xorg-2.eclass: Remove use of prune_libtool_files
On Tue, Feb 19, 2019 at 10:21 PM Ulrich Mueller wrote:
>
> >>>>> On Wed, 20 Feb 2019, Matt Turner wrote:
>
> > # Don't install libtool archives (even for modules)
> > - prune_libtool_files --all
> > + find "${D}" -name '*.la' -delete || die
>
> Maybe restrict removal to regular files, i.e. add "-type f"?
Is that ever a problem? The 'find ...' that I replaced
prune_libtool_files is a verbatim copy of what ltprune.eclass says to
use instead:
# Discouraged. Whenever possible, please use much simpler:
# @CODE
# find "${D}" -name '*.la' -delete || die
# @CODE
grepping the repo, I think a strong case can be made in favor of
ltprune.eclass given the wide variety of ways this is open coded...
Re: [gentoo-dev] [PATCH 3/3] xorg-2.eclass: Add EAPI=7 support
On Tue, Feb 19, 2019 at 10:24 PM Ulrich Mueller wrote: > > >>>>> On Wed, 20 Feb 2019, Matt Turner wrote: > > > Nearly all the work is just removing uses of autotools-multilib and > > autotools-utils. The new code should work in EAPI 4 and 5. Don't add > > support for EAPI 6; that ship has already sailed. > > AFAICS, adding EAPI 6 support wouldn't require any additional code? I think that is true. (I have no strong preference on whether to add EAPI 6 support. I just figured that anything that gets an EAPI bump now should go to the latest available)
[gentoo-dev] [PATCH 3/3] xorg-2.eclass: Add EAPI=7 support
Nearly all the work is just removing uses of autotools-multilib and
autotools-utils. The new code should work in EAPI 4 and 5. Don't add
support for EAPI 6; that ship has already sailed.
---
There are a number of trivial x11 bumps coming up, so I figured I'd try
to finally add EAPI=7 support to xorg-2.eclass. This is lightly tested,
and I don't feel like an expert at this, so any review and feedback is
appreciated.
I find the if-multilib ... fi blocks a little odd. Is there a better way
to do that?
eclass/xorg-2.eclass | 80 ++--
1 file changed, 48 insertions(+), 32 deletions(-)
diff --git a/eclass/xorg-2.eclass b/eclass/xorg-2.eclass
index 74660e7f213..eb2aa1594b4 100644
--- a/eclass/xorg-2.eclass
+++ b/eclass/xorg-2.eclass
@@ -1,4 +1,4 @@
-# Copyright 1999-2017 Gentoo Foundation
+# Copyright 1999-2019 Gentoo Authors
# Distributed under the terms of the GNU General Public License v2
# @ECLASS: xorg-2.eclass
@@ -7,7 +7,7 @@
# @AUTHOR:
# Author: Tomáš Chvátal
# Author: Donnie Berkholz
-# @SUPPORTED_EAPIS: 4 5
+# @SUPPORTED_EAPIS: 4 5 7
# @BLURB: Reduces code duplication in the modularized X11 ebuilds.
# @DESCRIPTION:
# This eclass makes trivial X ebuilds possible for apps, fonts, drivers,
@@ -44,16 +44,16 @@ fi
: ${XORG_MULTILIB:="no"}
# we need to inherit autotools first to get the deps
-inherit autotools autotools-utils eutils libtool multilib toolchain-funcs \
+inherit autotools eutils libtool multilib toolchain-funcs \
flag-o-matic ${FONT_ECLASS} ${GIT_ECLASS}
if [[ ${XORG_MULTILIB} == yes ]]; then
- inherit autotools-multilib
+ inherit multilib-minimal
fi
-EXPORTED_FUNCTIONS="src_unpack src_compile src_install pkg_postinst pkg_postrm"
+EXPORTED_FUNCTIONS="src_prepare src_configure src_unpack src_compile
src_install pkg_postinst pkg_postrm"
case "${EAPI:-0}" in
- 4|5) EXPORTED_FUNCTIONS="${EXPORTED_FUNCTIONS} src_prepare
src_configure" ;;
+ 4|5|7) ;;
*) die "EAPI=${EAPI} is not supported" ;;
esac
@@ -129,7 +129,16 @@ for arch in ${XORG_EAUTORECONF_ARCHES}; do
EAUTORECONF_DEPENDS+=" ${arch}? ( ${EAUTORECONF_DEPEND} )"
done
DEPEND+=" ${EAUTORECONF_DEPENDS}"
-[[ ${XORG_EAUTORECONF} != no ]] && DEPEND+=" ${EAUTORECONF_DEPEND}"
+if [[ ${XORG_EAUTORECONF} != no ]] ; then
+ case "${EAPI:-0}" in
+ 4|5)
+ DEPEND+=" ${EAUTORECONF_DEPEND}"
+ ;;
+ 7)
+ BDEPEND+=" ${EAUTORECONF_DEPEND}"
+ ;;
+ esac
+fi
unset EAUTORECONF_DEPENDS
unset EAUTORECONF_DEPEND
@@ -311,20 +320,6 @@ xorg-2_src_unpack() {
[[ -n ${FONT_OPTIONS} ]] && einfo "Detected font directory: ${FONT_DIR}"
}
-# @FUNCTION: xorg-2_patch_source
-# @DESCRIPTION:
-# Apply all patches
-xorg-2_patch_source() {
- debug-print-function ${FUNCNAME} "$@"
-
- # Use standardized names and locations with bulk patching
- # Patch directory is ${WORKDIR}/patch
- # See epatch() in eutils.eclass for more documentation
- EPATCH_SUFFIX=${EPATCH_SUFFIX:=patch}
-
- [[ -d "${EPATCH_SOURCE}" ]] && epatch
-}
-
# @FUNCTION: xorg-2_reconf_source
# @DESCRIPTION:
# Run eautoreconf if necessary, and run elibtoolize.
@@ -335,14 +330,17 @@ xorg-2_reconf_source() {
*-aix* | *-winnt*)
# some hosts need full eautoreconf
[[ -e "./configure.ac" || -e "./configure.in" ]] \
- && AUTOTOOLS_AUTORECONF=1
+ && XORG_EAUTORECONF=yes
;;
*)
# elibtoolize required for BSD
[[ ${XORG_EAUTORECONF} != no && ( -e "./configure.ac"
|| -e "./configure.in" ) ]] \
- && AUTOTOOLS_AUTORECONF=1
+ && XORG_EAUTORECONF=yes
;;
esac
+
+ [[ ${XORG_EAUTORECONF} != no ]] && eautoreconf
+ elibtoolize --patch-only
}
# @FUNCTION: xorg-2_src_prepare
@@ -351,9 +349,10 @@ xorg-2_reconf_source() {
xorg-2_src_prepare() {
debug-print-function ${FUNCNAME} "$@"
- xorg-2_patch_source
+ default
xorg-2_reconf_source
- autotools-utils_src_prepare "$@"
+
+ [[ ${PATCHES} ]] && epatch "${PATCHES[@]}"
}
# @FUNCTION: xorg-2_font_configure
@@ -447,17 +446,28 @@ xorg-2_src_configure() {
local selective_werror="--disable-selective-werror"
fi
- local myeconfargs=(
+ local econfargs=(
${dep_track}
${selective_werror}
${FONT_OPTIONS}
"${xorgconfadd[@]}"
)
+ # Handle static-libs found in IUSE, disable them by default
+ if in_iuse static-libs; then
+ econfargs+=(
+ --enable-shared
+ $(use_enable static-libs static)
[gentoo-dev] [PATCH 1/3] xorg-2.eclass: Drop support for EAPI 3
No ebuilds inheriting xorg-2 are EAPI=3.
---
eclass/xorg-2.eclass | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/eclass/xorg-2.eclass b/eclass/xorg-2.eclass
index 4ed65e676a0..7133aa365f1 100644
--- a/eclass/xorg-2.eclass
+++ b/eclass/xorg-2.eclass
@@ -7,7 +7,7 @@
# @AUTHOR:
# Author: Tomáš Chvátal
# Author: Donnie Berkholz
-# @SUPPORTED_EAPIS: 3 4 5
+# @SUPPORTED_EAPIS: 4 5
# @BLURB: Reduces code duplication in the modularized X11 ebuilds.
# @DESCRIPTION:
# This eclass makes trivial X ebuilds possible for apps, fonts, drivers,
@@ -53,7 +53,7 @@ fi
EXPORTED_FUNCTIONS="src_unpack src_compile src_install pkg_postinst pkg_postrm"
case "${EAPI:-0}" in
- 3|4|5) EXPORTED_FUNCTIONS="${EXPORTED_FUNCTIONS} src_prepare
src_configure" ;;
+ 4|5) EXPORTED_FUNCTIONS="${EXPORTED_FUNCTIONS} src_prepare
src_configure" ;;
*) die "EAPI=${EAPI} is not supported" ;;
esac
@@ -271,7 +271,7 @@ fi
if [[ ${XORG_MODULE_REBUILD} == yes ]]; then
case ${EAPI} in
- 3|4)
+ 4)
;;
*)
RDEPEND+=" x11-base/xorg-server:="
@@ -530,7 +530,7 @@ xorg-2_pkg_postrm() {
if [[ -n ${FONT} ]]; then
# if we're doing an upgrade, postinst will do
- if [[ ${EAPI} -lt 4 || -z ${REPLACED_BY_VERSION} ]]; then
+ if [[ -z ${REPLACED_BY_VERSION} ]]; then
create_fonts_scale
create_fonts_dir
font_pkg_postrm "$@"
--
2.19.2
[gentoo-dev] [PATCH 2/3] xorg-2.eclass: Remove use of prune_libtool_files
---
eclass/xorg-2.eclass | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/eclass/xorg-2.eclass b/eclass/xorg-2.eclass
index 7133aa365f1..74660e7f213 100644
--- a/eclass/xorg-2.eclass
+++ b/eclass/xorg-2.eclass
@@ -500,7 +500,7 @@ xorg-2_src_install() {
fi
# Don't install libtool archives (even for modules)
- prune_libtool_files --all
+ find "${D}" -name '*.la' -delete || die
[[ -n ${FONT} ]] && remove_font_metadata
}
--
2.19.2
Re: [gentoo-dev] wayland category
On Sat, Feb 9, 2019 at 2:26 AM Mart Raudsepp wrote:
>
> Ühel kenal päeval, R, 08.02.2019 kell 16:44, kirjutas Matthew Thode:
> > wayland, weston, sway{,lock,idle}, wl-clipboard, etc would be the
> > start,
> > I'm sure there are a ton I'm missing but I don't know where to put
> > things like wl-clipboard, dev-libs doesn't seem right.
>
>
> Another problem are many of the toolkits and GUI libraries; many either
> support wayland and X11 and more, or are really agnostic to it (but
> deal with GUI stuff on top of GTK or other stuff), but historically we
> have them in x11-libs/. As-is, they'd be better off in dev-libs/, but
> really a new gui-libs/ seems better to me.
> Maybe the pure-wayland stuff could be in some sort of gui-* category
> too.
Agreed. gui-*/ seems like the best plan.
Re: [gentoo-dev] Last rites: =x11-drivers/nvidia-drivers-375* =x11-drivers/nvidia-drivers-378* =x11-drivers/nvidia-drivers-381* =x11-drivers/nvidia-drivers-384* =x11-drivers/nvidia-drivers-387* =x11-d
On Sun, Dec 16, 2018 at 5:20 PM Jeroen Roovers wrote: > > On Sun, 16 Dec 2018 14:45:11 -0500 > Matt Turner wrote: > > > I guess my question to you is whether you think it's okay to mask -304 > > for removal or whether there are enough users that we should keep it > > under package.mask? > > "The Linux 304.* legacy driver series is the last to support the NV4x > and G7x GPUs and motherboard chipsets based on them. Support for new > Linux kernels and X servers, as well as fixes for critical bugs, will > be included in 304.* legacy releases through the end of 2017." [1] > > That should be fine, then: 304 no longer receives security support so it > can go away along with xorg-server-1.19. Thanks Jer!
Re: [gentoo-dev] Last rites: =x11-drivers/nvidia-drivers-375* =x11-drivers/nvidia-drivers-378* =x11-drivers/nvidia-drivers-381* =x11-drivers/nvidia-drivers-384* =x11-drivers/nvidia-drivers-387* =x11-d
On Sun, Dec 16, 2018 at 2:40 PM Jeroen Roovers wrote: > > On Fri, 14 Dec 2018 12:03:52 -0800 > Matt Turner wrote: > > > Thanks. What do we want to do about -304? > > It's not on the list above because it's a "legacy driver", not a > "short lived" branch[1]. It's not relevant in this context what happens > to the 304 branch, the context being a cleanup of intermediate branches > that were abandoned and surpassed by "long lived" branches. I understand. This was just a convenient place to ask a related question. > > It still requires xorg-server-1.19 which I'd like to drop due to a > > security vulnerability. After the listed versions are gone, -304 will > > be the only thing keeping 1.19 in tree. It's bug https://bugs.gentoo.org/669588 > I see no open security bug report for this. If we had one of those, then > we could write a package.mask entry for both xorg-server and > nvidia-drivers with a reference to the security issue, or add the > branches that are now masked for removal. That way people can plan > their hardware's obsolescence properly or shift to a different driver. I guess my question to you is whether you think it's okay to mask -304 for removal or whether there are enough users that we should keep it under package.mask?
Re: [gentoo-dev] Last rites: =x11-drivers/nvidia-drivers-375* =x11-drivers/nvidia-drivers-378* =x11-drivers/nvidia-drivers-381* =x11-drivers/nvidia-drivers-384* =x11-drivers/nvidia-drivers-387* =x11-d
On Fri, Dec 14, 2018 at 6:04 AM Jeroen Roovers wrote: > > According to Nvidia these are former "Short Lived" branches that are no > longer supported. > > > # Jeroen Roovers (14 Dec 2018) > # Deprecated short lived branches > # https://www.nvidia.com/object/unix.html > # File a bug report if you need to use one of these > # Removal on or about 14 January 2019 > =x11-drivers/nvidia-drivers-375* > =x11-drivers/nvidia-drivers-378* > =x11-drivers/nvidia-drivers-381* > =x11-drivers/nvidia-drivers-384* > =x11-drivers/nvidia-drivers-387* > =x11-drivers/nvidia-drivers-396* Thanks. What do we want to do about -304? It still requires xorg-server-1.19 which I'd like to drop due to a security vulnerability. After the listed versions are gone, -304 will be the only thing keeping 1.19 in tree.
Re: [gentoo-dev] AUTHORS file for portage repository
On Tue, Nov 27, 2018 at 12:11 PM Rich Freeman wrote:
>
> On Tue, Nov 27, 2018 at 2:58 PM Matt Turner wrote:
> >
> > What Copyright-owner header are you talking about?
>
> We would create one, just as we've created bugzilla tags in git for
> closing bugs/etc. Surely putting one line in a commit is no more
> difficult than putting one file in a repository? Indeed anybody can
> start sticking such a tag in commits today without any involvement
> from anybody else.
>
> > You've been the
> > most outspoken opponent of using what appears to be the standard
> > attribution form specified in GLEP-76
>
> When have I been opposed to anything in GLEP 76? I'll admit that I
Now what I said. You've been the most outspoken opponent of using the
standard attribution format specified in GLEP-76. You know, the one
that says
Copyright YEARS MAIN-CONTRIBUTOR [OTHER-CONTRIBUTOR]... [and others]
and would suggest that it's allowable for Sony's name to be listed as
the MAIN-CONTRIBUTOR instead of Gentoo Authors.
> don't 100% agree with everything in there, but I'm fine with following
> the GLEP as it is written. Multi-line copyright notices aren't in
> there, and the intent was never to be accumulating copyright holders
> on the single notice line. An authors file was a compromise I wasn't
> a huge fan of, but I'm suggesting that if we have one it ought to be
> auto-generated (presumably with the work being done by somebody who
> actually wants the file to be there).
>
> Also, GLEP 76 as it is written says: "Projects using this scheme must
> track authorship in a VCS, unless they list all authors of
> copyrightable contributions in an AUTHORS file."
>
> So, a VCS is the PREFERRED way of doing it. The alternative is
> listing ALL authors in the authors file. Right now it seems like
> people are advocating for only listing some authors.
Let's not pretend that the authors of the GLEP (you're listed first,
by the way!) foresaw these issues (and rather obvious ones at that, I
might add). I'm already having to communicate the authors' intentions
and how they're different from what regular folks would think after
reading the GLEP (see:
https://github.com/gentoo/gentoo/pull/10481#issuecomment-442175181)
So let's satisfy everyone and be done with it: Let's put AUTHORS in
Git with a section header that states that these Copyright holders are
not obvious from the git history. This is where Sony would go. Then
let's append the output of "git log --format='%aN <%aE>" during
metadata generation or whenever stuff like that gets expanded. That
output is currently 36k FWIW.
Or, I don't know. Come up with something better and continue
bikeshedding. I won't.
> > I know mailing list debates are your personal pastime but this is a
> > real wasteoftime.
>
> You're the one advocating for changing the status quo. I'm happy if
> we drop the whole topic entirely. You certainly can't point fingers
> at others when you're proposing doing something differently. We
> wouldn't be having this discussion if some contributors were unwilling
> to contribute under our current standards.
At what point would you say maybe gentoo-{dev,proj}@ has heard enough
of me for a while? I'd wager that you have an order of magnitude more
emails to these lists this calendar year than commits to gentoo.git. I
see 20 commits and I'm not going to try count all your messages.
Re: [gentoo-dev] AUTHORS file for portage repository
On Tue, Nov 27, 2018 at 9:49 AM Rich Freeman wrote: > > On Tue, Nov 27, 2018 at 11:59 AM Matt Turner wrote: > > > > On Tue, Nov 27, 2018 at 7:41 AM Rich Freeman wrote: > > > It makes sense to ensure that the solution actually solves the problem > > > before we simply implement it. > > > > > > If we really need such a file it would probably also make more sense > > > to have it auto-generated from git commit headers > > > > And how do you want to determine whether William's contributions are > > copyright Sony or now? Do you want to look up his timezone and check > > whether they were made during work hours? > > No, you look at the Copyright-owner header or whatever we want to call > it, and use that. Companies that care about labeling what they own > can take the time to properly document this. What Copyright-owner header are you talking about? You've been the most outspoken opponent of using what appears to be the standard attribution form specified in GLEP-76, and now that we have what I think is a really good compromise you're against that too? I know mailing list debates are your personal pastime but this is a real wasteoftime.
Re: [gentoo-dev] AUTHORS file for portage repository
On Tue, Nov 27, 2018 at 7:58 AM Andrey Utkin wrote: > > On Tue, Nov 27, 2018 at 09:12:26AM -0600, William Hubbs wrote: > > All, > > > > based on the previous thread about copyright attribution clarifications, > > I want to add the following AUTHORS file to the top level of the portage > > repository if no one objects. > > > > This is based on the description of the AUTHORS file at Google [1]. > > > > Everyone is not required to be listed, but there is no reason you can't > > add yourself if you have contributed to the tree and want to be listed. > > > > I hope this will satisfy everyone involved in the discussion. > > > > Thoughts? > > It seems to me this will grow huge, and be the source of annoyance for > users. I'm imagining it's only those that are not obvious from the commit log that will be listed here. But regardless, you're right that it will grow. At the same time I doubt it will be a serious concern, and in the case that it becomes one we can sort it out then.
Re: [gentoo-dev] AUTHORS file for portage repository
On Tue, Nov 27, 2018 at 7:41 AM Rich Freeman wrote: > It makes sense to ensure that the solution actually solves the problem > before we simply implement it. > > If we really need such a file it would probably also make more sense > to have it auto-generated from git commit headers And how do you want to determine whether William's contributions are copyright Sony or now? Do you want to look up his timezone and check whether they were made during work hours? If this satisfies Sony, please don't bikeshed this. The perfect it the enemy of the good.
Re: [gentoo-dev] Packages up for grabs from xmw@g.o
On Sun, Nov 25, 2018 at 2:05 AM Michał Górny wrote: > app-shells/autojump I'll take this.
[gentoo-dev] Last rites: app-eselect/eselect-mesa
Forgot to send this one out when I committed it. # Matt Turner (29 Sep 2018) # Removal in 30 days, bug #576334 app-eselect/eselect-mesa signature.asc Description: PGP signature
[gentoo-dev] Last rites: media-libs/libomxil-bellagio
# Matt Turner (16 Oct 2018) # Unmaintained. Unused. Removal in 30 days. Bug #668826 media-libs/libomxil-bellagio signature.asc Description: PGP signature
Re: [gentoo-dev] net-dns/dnssec-root: Blind stable on arm, critical bug 667774
On Thu, Oct 11, 2018 at 4:38 PM Sergei Trofimovich wrote: > > On Thu, 11 Oct 2018 17:10:10 +0200 > Thomas Deutschmann wrote: > > > Let me quote > > https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=f6f6bb91b7f134a121ef9fa1dd504b9ca52c5aa8: > > > > > net-dns/dnssec-root: Blind stable on arm, critical bug 667774 > > > > > > Note that this is a major fail for a stable architecture. > > > In addition, all arm devboxes are currently offline. > > > > > > Bug: https://bugs.gentoo.org/667774 > > > Signed-off-by: Andreas K. Hüttel > > > Package-Manager: Portage-2.3.49, Repoman-2.3.11 > > > > ...and now let's all sit down and enjoy how stable ARM users lose access > > to the Internet and have to figure out how to deactivate DNSSEC to get > > back online. ;] > > > > Maybe it is time to destabilize ARM on Gentoo to stop the impression > > that we really support ARM. > > [ CC: arm@ ] > > A few points to think about: > > 1. I have read this as a direct statement that ARM is not maintained. >I don't think it is a fair (or constructive) assessment of team's work >on ARM front. It's maintained, but in my experience it's often the last architecture to handle a bug. Often by a wide margin. Take a look at the shapes these graphs: https://www.akhuettel.de/gentoo-bugs/arches.php maekke and zlogene do a lot of arm stabilizations, but I'm sure it's too much work for two people alone, especially if all the arm devboxes are offline (WTF?).
Re: [gentoo-dev] [RFC] C++ standard in ebuilds
I don't understand what a potential solution would be. The various projects use -std=c++XXX because that's what their code requires. -std=c++XXX can't generally be changed. If a dependent project is incompatible that's no different than any other case of incompatible dependencies in Gentoo. I think -std=c++XXX discussions before happened because gcc changed the C++ ABI with -std=c++11. I don't think that's particularly relevant here, since as far as I know different -std=c++XXX values don't change the ABI with current gcc. So I guess my understanding is that there isn't a problem different than existing incompatible dependencies, but maybe I have misunderstood you.
Re: [gentoo-dev] Changing policy about -Werror
On Thu, Sep 13, 2018 at 5:44 PM Richard Yao wrote: > > On Sep 13, 2018, at 7:21 PM, Matt Turner wrote: > > > > On Thu, Sep 13, 2018 at 4:13 PM Richard Yao wrote: > >>> On Sep 13, 2018, at 12:03 PM, Fabian Groffen wrote: > >>> > >>>> On 13-09-2018 07:36:09 -0400, Richard Yao wrote: > >>>> > >>>> > >>>>>> On Sep 12, 2018, at 6:55 PM, Thomas Deutschmann > >>>>>> wrote: > >>>>>> > >>>>>> On 2018-09-12 16:50, Rich Freeman wrote: > >>>>>> There is also the case where we want these warnings to block > >>>>>> installation, because the risk of there being a problem is too great. > >>>>> > >>>>> I really disagree with that. So many devs have already said multiple > >>>>> times in this thread that "-Werror" is only turning existing warnings > >>>>> into fatal errors but "-Werror" itself doesn't add any new checks and > >>>>> more often requires "-O3" to be useful. > >>>> The way that compilers work is that the warnings are generated in the > >>>> front end while the optimization level affects the backend. That means > >>>> that -O3 has no effect on the code that does error generation. This > >>>> remark about -O3 being needed to make -Werror useful is just plain wrong. > >>> > >>> Huh? -O3 enables more checks, which can generate more warnings. > >> > >> What checks are those? -O3 affects backend optimization while warnings are > >> generated by the front end. Once the immediate representation is > >> generated, there are no other warnings aside from those from the linker. > > > > https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html > > > > Search for "depend on" > > > > -> [...] estimated based on heuristics that depend on thelevel > > argument and on optimization > > > > -> Because these warnings depend on optimization [...] > > > > Yes, warnings are dependent on optimization level. > > There are three such options. The first two are for format statements: > > > “When the exact number of bytes written by a format directive cannot be > > determined at compile-time it is estimated based on heuristics that depend > > on the level argument and on optimization. While enabling optimization will > > in most cases improve the accuracy of the warning, it may also result in > > false positives. “ > > My read of this is that the warning occurs regardless of optimization level, > but it could somehow be improved by optimization. > > As for the last, it is for uninitialized variable reads. However, I think you > are misinterpreting the claim. The way that optimization level could affect > warning generation would be if the warning generation came after optimization > passes that could hide reads. That means that -O3 would prevent the warning. > > This is a really odd design decision by the GCC developers. With other > compilers, the separation between front end and backend is strong enough that > you will never have this sort of thing. It does not seem necessary to me > either. :/ I'm sorry, but you really don't know what you're talking about. I've already told you once that you were just adding noise to this conversation.
Re: [gentoo-dev] Changing policy about -Werror
On Thu, Sep 13, 2018 at 4:13 PM Richard Yao wrote: > > On Sep 13, 2018, at 12:03 PM, Fabian Groffen wrote: > > > >> On 13-09-2018 07:36:09 -0400, Richard Yao wrote: > >> > >> > On Sep 12, 2018, at 6:55 PM, Thomas Deutschmann > wrote: > > On 2018-09-12 16:50, Rich Freeman wrote: > There is also the case where we want these warnings to block > installation, because the risk of there being a problem is too great. > >>> > >>> I really disagree with that. So many devs have already said multiple > >>> times in this thread that "-Werror" is only turning existing warnings > >>> into fatal errors but "-Werror" itself doesn't add any new checks and > >>> more often requires "-O3" to be useful. > >> The way that compilers work is that the warnings are generated in the > >> front end while the optimization level affects the backend. That means > >> that -O3 has no effect on the code that does error generation. This remark > >> about -O3 being needed to make -Werror useful is just plain wrong. > > > > Huh? -O3 enables more checks, which can generate more warnings. > > What checks are those? -O3 affects backend optimization while warnings are > generated by the front end. Once the immediate representation is generated, > there are no other warnings aside from those from the linker. https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html Search for "depend on" -> [...] estimated based on heuristics that depend on thelevel argument and on optimization -> Because these warnings depend on optimization [...] Yes, warnings are dependent on optimization level.
Re: [gentoo-dev] Changing policy about -Werror
On Wed, Sep 12, 2018 at 5:11 PM Rich Freeman wrote: > > On Wed, Sep 12, 2018 at 7:52 PM Matt Turner wrote: > > > > On Wed, Sep 12, 2018 at 4:03 PM Rich Freeman wrote: > > > Now, I could buy that -Werror turns NEW warnings into fatal errors, > > > due to the use of a newer toolchain, since upstream probably didn't > > > test with that toolchain and thus wouldn't have seen the warning. > > > > Yes, exactly. This is one of the major things people have said repeatedly. > > > > Werror makes moving gcc forward much more difficult. > > > > Sure, but wouldn't a block on newer versions of gcc cause similar headaches? Sure...? Who is suggesting that? I'm not sure where you're going with this. With new GCC comes new warnings, and harmless as the vast majority are they cause the build to break with Werror.
Re: [gentoo-dev] Changing policy about -Werror
On Wed, Sep 12, 2018 at 4:03 PM Rich Freeman wrote: > Now, I could buy that -Werror turns NEW warnings into fatal errors, > due to the use of a newer toolchain, since upstream probably didn't > test with that toolchain and thus wouldn't have seen the warning. Yes, exactly. This is one of the major things people have said repeatedly. Werror makes moving gcc forward much more difficult.
Re: [gentoo-dev] Changing policy about -Werror
On Mon, Sep 10, 2018 at 1:34 PM Chí-Thanh Christopher Nguyễn wrote: > > Jason Zaman schrieb: > >> No. With -Werror, upstream indicates that if a warning occurs, the build > >> should fail and the resulting code not be installed on user systems. > >> > >> Instead, someone knowledgeable should look at the situation *first* and > >> determine whether it is a bogus warning, a trivial issue, or something > >> which > >> warrants further attention. > >> > >> I have long disagreed with QA policy on this, and think that ebuilds should > >> respect upstream here. Of course giving users the ability to override. > > > > I disagree. -Werror means that upstream wants it to build without > > warnings on their distro with their version of the compiler with their > > versions of all the libraries. > > It means, upstream wants it to build without warnings everywhere. And if a > warning occurs (due to change in compiler, libraries, architecture, etc.), > have a developer look at it first before installing the code on user systems. This sounds good in theory, but I think it's pretty well established that in practice this isn't effective and instead is a large waste of time. In fact, the foundational premise that it's possible to build without warnings everywhere is simply wrong. Consider again the bug that started this. The maintainer had not built this configuration. None of the arch teams had built this configuration until I did for the last architecture Cc'd. The patch committed doesn't change anything installed on the system, if not for Werror preventing the code from building.
Re: [gentoo-dev] Changing policy about -Werror
On Sun, Sep 9, 2018 at 4:32 AM Andrew Savchenko wrote: > > Hi! > > Our current -Werror policy demands unconditional removal: > https://devmanual.gentoo.org/ebuild-writing/common-mistakes/index.html#-werror-compiler-flag-not-removed > > I think this is wrong, see bugs 665464, 665538 for a recent > discussion why. Bug 665464 supports the exact opposite conclusion. Werror turned a trivial warning into a build failure. > My point is that in *most* cases -Werror indeed should be removed, > because upstream rarely can keep up with all possible configure, > *FLAGS, compiler versions and arch combinations. But! In some cases > — especially for security oriented software — this flag may be > pertain and may be kept at maintainer's discretion. > > The rationale is that -Werror usually points to dangerous > situations like uninitialized variables, pointer type mismatch or > implicit function declaration (and much more) which may lead to > serious security implications. Warnings are often over unimportant details (like in this bug). It is certainly not the case that they "usually point to dangerous situations". > So, if maintainer has enough manpower to support this flag, we > should allow to keep it. Of course if it will cause long-standing > troubles (e.g. bugs opened for a long time) QA should have power to > remove it or demand its removal. In the bug that started this, it was the case that the maintainer himself had not built the package with this configuration. Nor had any arch team that recently stabilized the package (x86, amd64, ia64, ppc, ppc64, arm). So again, the bug supports the opposite conclusion. The policy is sound, and I don't think we could have found a worse bug as supporting evidence that we should revise the policy.
Re: [gentoo-dev] Gentoo i486 support
On Wed, Aug 22, 2018 at 5:26 AM Ben Kohler wrote:
> 2) Patch catalyst to start setting CXXFLAGS again. Rather than roll
> back to exactly CXXFLAGS="${CFLAGS}" again, it's been suggested that we
> start setting COMMON_FLAGS, and CFLAGS="${COMMON_FLAGS}"
> CXXFLAGS=${COMMON_FLAGS}" etc. I prepared such a patch a while back
> [4], which seems to work but may need a bit of updating.
[snip]
> [2]
> https://gitweb.gentoo.org/proj/catalyst.git/commit/?id=b409bd9bb4b50f69a555e4e148057ade86a7ed16
I don't think that was intentional, was it?
That commit looks like it's supposed to just be a plain refactor (It's
titled "stagebase.py: Refactor the *FLAGS handling code in
chroot_setup()" after all) so it shouldn't have changed behavior. I'm
guessing the commit is just broken. It doesn't even look like the
commit message was finished when it was pushed.
I think you should do whatever is required to fix catalyst brokenness.
[gentoo-dev] Last Rites: dev-libs/weston
# Matt Turner (18 Aug 2018) # Unmaintained in Gentoo. Removal in 30 days. # Bug 663998 dev-libs/weston signature.asc Description: PGP signature
Re: [gentoo-dev] rfc: moving default location of portage tree (was: [gentoo-project] Call for agenda items - Council meeting 2018-07-29)
On Sun, Jul 29, 2018 at 1:01 PM, Rich Freeman wrote:
> On Sun, Jul 29, 2018 at 3:56 PM Matt Turner wrote:
>>
>> On Fri, Jul 27, 2018 at 1:32 AM, Ulrich Mueller wrote:
>> >
>> > So, considering all the feedback from mailing list and IRC:
>> >
>> >/usr/portage -> /var/db/repos/gentoo
>> >/usr/portage/distfiles -> /var/cache{,/gentoo}/distfiles
>> >/usr/portage/packages -> /var/cache{,/gentoo}/binpkgs
>> >
>> > Open question: Should we have the additional "gentoo" path component
>> > for the ones in /var/cache? The tradeoff is between a path that is
>> > easier to type, or slightly easier usage if someone wants to NFS mount
>> > distfiles and binpkgs.
>>
>> That proposal has by vote of support. No strong preference on whether
>> to include gentoo/ or not. It's one NFS mount vs two so not a big deal
>> either way.
>>
>
> Why not stick the repos in /var/repos and not /var/db/repos? If we're
> just making up paths, why not make up a shorter one? I don't think
> any other linux distros use /var/db...
That would be fine with me as well :)
Re: [gentoo-dev] rfc: moving default location of portage tree (was: [gentoo-project] Call for agenda items - Council meeting 2018-07-29)
On Fri, Jul 27, 2018 at 1:32 AM, Ulrich Mueller wrote:
>> On Thu, 19 Jul 2018, Chí-Thanh Christopher Nguyễn wrote:
>
>>> Users must never need to modify files in /var/lib to configure a
>>> package's operation, and _the_specific_file_hierarchy_ used to
>>> store the data _must_not_be_ _exposed_ to regular users."
>
>> One small note, while it is never needed to modify, skel.ebuild
>> would then be a file that is meant to be accessed by users in
>> /var/lib if your proposal is realized.
>
> That's one of the reasons why the proposal prefers /var/db. The other
> reason is existing usage in eselect-repository.
>
>> On Thu, 19 Jul 2018, Ulrich Mueller wrote:
>
>> In my understanding, a cache is typically an open collection of items.
>> Some subset of them can be deleted without much negative consequence,
>> and there may also be surplus items that are no longer necessary and
>> will be expired at some later time in order to reclaim disk space.
>
>> Nothing of this is true for an ebuild repository, which is a closed
>> collection of files: A single file cannot be discarded without
>> invalidating the whole repository. Also there cannot be any stray
>> files which would be expired later. Same as above, a single stray file
>> will invalidate all.
>
>> (A collection of binary packages may qualify as a cache though, by
>> this definition.)
>
> So, considering all the feedback from mailing list and IRC:
>
>/usr/portage -> /var/db/repos/gentoo
>/usr/portage/distfiles -> /var/cache{,/gentoo}/distfiles
>/usr/portage/packages -> /var/cache{,/gentoo}/binpkgs
>
> Open question: Should we have the additional "gentoo" path component
> for the ones in /var/cache? The tradeoff is between a path that is
> easier to type, or slightly easier usage if someone wants to NFS mount
> distfiles and binpkgs.
That proposal has by vote of support. No strong preference on whether
to include gentoo/ or not. It's one NFS mount vs two so not a big deal
either way.
Re: [gentoo-dev] rfc: moving default location of portage tree (was: [gentoo-project] Call for agenda items - Council meeting 2018-07-29)
On Fri, Jul 27, 2018 at 1:40 AM, Michał Górny wrote:
> Dnia 27 lipca 2018 10:32:17 CEST, Ulrich Mueller napisał(a):
>>> On Thu, 19 Jul 2018, Chí-Thanh Christopher Nguyễn wrote:
>>
Users must never need to modify files in /var/lib to configure a
package's operation, and _the_specific_file_hierarchy_ used to
store the data _must_not_be_ _exposed_ to regular users."
>>
>>> One small note, while it is never needed to modify, skel.ebuild
>>> would then be a file that is meant to be accessed by users in
>>> /var/lib if your proposal is realized.
>>
>>That's one of the reasons why the proposal prefers /var/db. The other
>>reason is existing usage in eselect-repository.
>>
>>> On Thu, 19 Jul 2018, Ulrich Mueller wrote:
>>
>>> In my understanding, a cache is typically an open collection of
>>items.
>>> Some subset of them can be deleted without much negative consequence,
>>> and there may also be surplus items that are no longer necessary and
>>> will be expired at some later time in order to reclaim disk space.
>>
>>> Nothing of this is true for an ebuild repository, which is a closed
>>> collection of files: A single file cannot be discarded without
>>> invalidating the whole repository. Also there cannot be any stray
>>> files which would be expired later. Same as above, a single stray
>>file
>>> will invalidate all.
>>
>>> (A collection of binary packages may qualify as a cache though, by
>>> this definition.)
>>
>>So, considering all the feedback from mailing list and IRC:
>>
>> /usr/portage -> /var/db/repos/gentoo
>> /usr/portage/distfiles -> /var/cache{,/gentoo}/distfiles
>> /usr/portage/packages -> /var/cache{,/gentoo}/binpkgs
>>
>>Open question: Should we have the additional "gentoo" path component
>>for the ones in /var/cache? The tradeoff is between a path that is
>>easier to type, or slightly easier usage if someone wants to NFS mount
>>distfiles and binpkgs.
>
> Note that NFS is not exactly clear cut here since binpkgs are not portable to
> different hosts, so you can have multiple variants of it.
True, but trivially solvable by configuring like-hosts to share
packages. Skylake packages go here, Sandybridge packages go here, etc.
This is what I do.
Re: [gentoo-dev] RFC: gles global USE flag, USE=opengl clarifying
On Mon, Jul 23, 2018 at 10:11 AM, Mart Raudsepp wrote: > Hello, > > Currently we have rather a mess in terms of OpenGL API handling. > I think much of it comes from USE=opengl being rather vague - is it > supposed to mean "Use desktop GL", "Use GLX", or "Enable OpenGL > support". All of these mean quite different things: > * desktop GL means full OpenGL API, which in turn can be either used > via GLX platform (X11 only) or EGL platform. > * GLX means GLX platform - usable only on X11; all good and same as > desktop GL in the past, but we have people wanting wayland-only now > (and YES, desktop GL via EGL platform _is_ a thing), and GLX obviously > isn't something that works in native wayland. > * GL support could mean 3D via OpenGL in general; be it OpenGL, GLESv2, > GLESv3... > > To make things easier to follow, there are basically three different > concepts and potential choices to make: > > * API > * Platform > * Windowing system > > API is either "full desktop" OpenGL (think e.g. OpenGL 4.5), or GLES; > GLES has multiple versions, but in practice it's GLESv2 with optional > support for GLESv3 - however afaik latest mesa supports GLESv3 too > whenever GLESv2 is built. > > Platform is either GLX or EGL. GLX only works in combination with "full > desktop" OpenGL; EGL can work with either. > For non-Linux there's also CGL (OSX), WGL (Windows), EAGL (iOS) and > more. Can be interesting for Gentoo Prefix. > > "EGL is an interface between Khronos rendering APIs such as OpenGL ES > or OpenVG and the underlying native platform window system." - thus the > third choice with EGL platform - windowing system. This then is about > supporting a certain graphics environment with EGL (with GLX that can > be taken as just always X). > This can be for example x11, wayland, GBM (think rendering 3D directly > on top of a KMS terminal), win32, cocoa, android, vivante framebuffer > (with proprietary vivante 3D stack; not applicable to open source > etnaviv), DispmanX (RPi), etc. > This can be a choice especially for certain kind of OpenGL libraries; > one big example I know of is GStreamer GL libraries. > > > > Anyhow, here's an initial proposal to try to sort it out via a USE=gles > global USE flag and a set of guidelines how to use it together with a > USE=opengl and other related USE flags in ebuilds: > > > use.desc: > opengl - Add support for desktop OpenGL (3D graphics) > gles - Add support for OpenGL ES, or prefer it over desktop OpenGL. This > should usually only be enabled globally on embedded systems that do not > support full desktop GL. > > [How is it correct to refer to "full desktop" GL without it being > confusing with OpenGL in general?] That's what people on my team call it to differentiate. "Desktop" vs ES. > Guidelines: > > * If package has optional GL support in general (can work with either > desktop GL or GLES when OpenGL is enabled; doesn't care which one is > there), use both opengl and gles in IUSE and enable GL support and > ebuild logic when either is enabled Sounds good. > * If package is fully about OpenGL (GL itself isn't optional) and > supports either desktop GL or GLES, but not both at once: IUSE="gles" > and use GLES if that is set, "full desktop" GL otherwise. Probably the best thing to do. > * If package is fully about OpenGL (GL itself isn't optional) and > supports either desktop GL or GLES, including both at once: IUSE="gles > +opengl" and use whichever is enabled. As GL isn't optional as a whole, > require at least one of them: REQUIRED_USE="|| ( gles opengl )". Sounds good. > * If package has optional OpenGL support and needs specific logic for > the chosen API: IUSE="gles opengl" or IUSE="gles +opengl", depending if > GL should be default enabled (albeit we might want to revise this via > profile level defaults flag instead?) - don't default enable gles, as > it's not a common use case and such embedded system users will have it > globally enabled anyways. > ** Enable any of the GL logic only if either gles or opengl is enabled. > ** If both are supported at the same time, enable whichever is chosen > by user (this could often mean also passing a generic --enable-gl > passing if either USE is set and then specifying the API to use with a > separate build flag). > ** If both are not supported at the same time, set REQUIRED_USE="gles? > ( !opengl )", use whichever is chosen (keeping in mind that both might > be disabled → no GL at all). > > * If package needs to provide choices for the used GL platform or > windowing system, while GL itself is optional as a whole, don't forget > to keep the dependencies and other logic for the platform/WS > conditional to USE=gles and/or USE=opengl. This is usually easiest to > handle via GL_DEPS helper variable with dependencies applicable to > either and then putting it in as e.g. "opengl? ( $GL_DEPS ) gles? ( > $GL_DEPS )" together with any specific ones; similar for certain needed > REQUIRED_USEs, with appropriate conditional blocks in sr
Re: [gentoo-dev] Adding USE=udev to linux profiles
On Fri, Jul 20, 2018 at 7:13 AM, Michael Orlitzky wrote: > On 07/20/2018 03:37 AM, Matt Turner wrote: >>> >>> If I want to undo your new flag, I have to set USE="-udev" globally, and >>> that clobbers any important per-package defaults that maintainers have set. >> >> I understand the concern at least in theory. But can you please give >> me a concrete example of a package where you don't want USE=udev and >> another example of a package where you do? >> > > I... probably don't want USE=udev enabled anywhere. What does it > actually do? I don't know, and the flag description is useless, and I > don't have time to read the source code to every package with the flag. > > But, I'm willing to trust the maintainers who have set IUSE="+udev" in > their ebuilds. > > As an example of how this works out, I have both sys-apps/hwids and > sys-apps/pciutils built with USE=udev, but media-gfx/gimp built without it. If it adds no additional dependencies, why do you care?
Re: [gentoo-dev] Adding USE=udev to linux profiles
On Thu, Jul 19, 2018 at 3:00 PM, Michael Orlitzky wrote: > On 07/19/2018 05:51 PM, Ben Kohler wrote: >> Hello, >> >> I'd like to propose adding USE=udev to our linux profiles (in >> profiles/default/linux/make.defaults probably). This flag is already >> enabled on desktop profiles but it also affects quite a few packages >> used on non-desktop linux systems. >> >> ... >> >> Any objections to this idea? >> > > Please add defaults per-package, only where they make sense. Enabling > flags globally creates a huge headache for people that want them off. > > If I want to undo your new flag, I have to set USE="-udev" globally, and > that clobbers any important per-package defaults that maintainers have set. I understand the concern at least in theory. But can you please give me a concrete example of a package where you don't want USE=udev and another example of a package where you do? Grepping the tree, I see the following packages pulled in with USE=udev predominantly: virtual/libudev virtual/libgudev virtual/udev A few others have some additional dependencies enabled with USE=udev: app-emulation/libvirt: x11-libs/libpciaccess dev-qt/qtgui/qtgui: sys-kernel/linux-headers gnome-base/gnome-desktop: sys-apps/hwids media-gfx/iscan-data: dev-libs/libxslt, media-gfx/sane-backends sys-auth/consolekit: x11-libs/libdrm sys-fs/dosfstools: virtual/pkgconfig What dependency are you trying to avoid? Or is it just a design issue?
Re: [gentoo-dev] Re: What means bup?
On Wed, Jul 18, 2018 at 3:26 AM, Matthew Thode wrote: > On 18-07-18 09:16:07, Johannes Huber wrote: >> Hi all, >> >> english is not my mother language, so please clarify what bup means, just >> seen here: >> >> https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=ee0e0401478cf30b3ced0405f6b89391e05d2397 >> >> Just checked if it was a typo, but can't be: >> git log --oneline --grep bup | count -l >> Expected 0 lines, got 1248. >> > > It's similiar to a sound you make when you touch something's nose. > *boop* > > I just prefer bup instead. I generally only use it when doing simple > bumps of packages (copy ebuilds with only keyword edits). Cute. Since 94.5% of the 1248 instances were from you... can you please stop?
Re: [gentoo-dev] rfc: killing mediawiki
On Tue, Jul 3, 2018 at 1:39 PM William Hubbs wrote: > > All, > > some of us have talked about this on IRC off and on, but I want to bring > it up here as well. > > I don't care that we have a wiki, but can we please look into killing > mediawiki and look at something with a git backend? It would be very > nice to be able to edit wiki pages in markdown or another similar format > and use git to control the changes instead of editing in a browser. I assume that your primary reason for wanting to replace mediawiki is to improve accessibility. I suggest you state that more clearly when making such a proposal. I read from jstein's email that he does not have the same knowledge of the situation that I have, and so his reply is expectedly different from mine.
Re: [gentoo-dev] rfc: why are we still distributing the portage tree via rsync?
On Tue, Jul 3, 2018 at 12:36 PM Rich Freeman wrote: > > On Tue, Jul 3, 2018 at 12:22 PM Matt Turner wrote: > > > > On Tue, Jul 3, 2018 at 11:38 AM Rich Freeman wrote: > > > 4. by default git tends to accumulate history, which can eat up disk > > > space. I imagine this could be automatically trimmed if users wanted, > > > though during syncing it would at least need to store all the commits > > > between the last fetched and next-fetched, and that means fetching > > > things that might have been subsequently removed/changed > > > > This is why I have not switched to git. I have /usr/portage on a > > separate 1GB partition (with distfiles and packages stored elsewhere). > > The ebuild tree is 600MB with rsync and cannot fit on the partition > > with git. > > > > git clone https://github.com/gentoo-mirror/gentoo.git . --depth 1 > ... > du -sh . > 662M. > > So, with a shallow clone it seems comparable. > > The issue is getting git to constantly trim, probably along the lines of: > https://stackoverflow.com/a/34829535 Exactly. I'm not sure git can automatically trim out history on git pull and I'm even less sure it would be able to do it without temporarily exceeding 1GB of storage.
Re: [gentoo-dev] rfc: why are we still distributing the portage tree via rsync?
On Tue, Jul 3, 2018 at 12:33 PM Matthias Maier wrote: > > > On Tue, Jul 3, 2018, at 11:22 CDT, Matt Turner wrote: > > > I'd be happy to switch if the space requirements were similar. > > $ git clone --depth=1 https://github.com/gentoo-mirror/gentoo > > occupies 662M on my machine (just tested). With full history > (i.e. without --depth=1) I am at 1.1GB. Wait a week and emerge --sync again; it won't fit.
Re: [gentoo-dev] rfc: why are we still distributing the portage tree via rsync?
On Tue, Jul 3, 2018 at 11:38 AM Rich Freeman wrote: > 4. by default git tends to accumulate history, which can eat up disk > space. I imagine this could be automatically trimmed if users wanted, > though during syncing it would at least need to store all the commits > between the last fetched and next-fetched, and that means fetching > things that might have been subsequently removed/changed This is why I have not switched to git. I have /usr/portage on a separate 1GB partition (with distfiles and packages stored elsewhere). The ebuild tree is 600MB with rsync and cannot fit on the partition with git. I'd be happy to switch if the space requirements were similar.
[gentoo-dev] x11-terms/xterm up for grabs
xterm isn't part of the core set of X applications and libraries from FreeDesktop.org and it's not something I personally use. I've dropped x11@ ownership of it. Please pick it up if you use it or it interests you. There are only 4 bugs filed against it. None looks particularly difficult and the upstream maintainer is active on bugzilla.
[gentoo-dev] Suggestions for simplifying VIDEO_CARDS situation
Hello, VIDEO_CARDS is an annoying mess. We used to have radeon, intel, and some others in media-libs/mesa's VIDEO_CARDS. radeon and intel corresponded to disparate sets of drivers -- VIDEO_CARDS=radeon has meant classic r100, r200, r300, and r600 drivers and gallium r600 and radeonsi drivers. VIDEO_CARDS=intel has meant classic i915 and i965 drivers as well as gallium i915. I added more-specific VIDEO_CARDS for those separate drivers a few years ago, so that users could set VIDEO_CARDS="radeon radeonsi" and only get the one radeonsi driver they actually wanted while still enabling support for x11-libs/libdrm's radeon support code which is used by most of those radeon drivers. Of course some users want this control and others don't care at all. The confusion comes in with "classic" DRI drivers vs Gallium drivers. The Gallium abstraction layer allows a hardware driver to handle multiple APIs -- OpenGL, D3D9, OpenCL, video decode APIs, etc. For instance, users try to build the classic i965 driver (there is no Gallium driver for this hardware) with USE=opencl or USE=vaapi and don't understand why they didn't get what they wanted (or REQUIRED_USE prevents them from doing so). Should of Mesa's USE flags, d3d9, llvm, lm_sensors, opencl, openmax, unwind, vaapi, vdpau, xa, and xvmc are Gallium-only. Should I make a USE_EXPAND for Gallium-only options to attempt to avoid confusion? Another point of confusion: not all Gallium drivers support all of these features. For instance only the r600 and radeonsi drivers support OpenCL. How to best handle this? It seems like at one extreme you build an extensive set of REQUIRED_USE conditions that force users to micromanage their USE flags, or you let them enable all sorts of impossible combinations and deal with the confused bug reports. I would like to somehow get rid of the 'classic' and 'gallium' USE flags entirely, but I'm not totally sure how. Maybe I can enable them dependent on VIDEO_CARDS... Suggestions welcome.
[gentoo-dev] Monthly x11@ project status for June 2018
x11@ is currently assigned or cc'd on 176 bugs. This number is down from 222 on April 1st and more than 412 in February 2015 (I reported this on #gentoo-desktop after closing out a bunch of bugs that day). == Fix x11-base/xorg-server suid/systemd situation == https://bugs.gentoo.org/635102 Looks like these bugs are sorted out. There are a few issues in conjunction with Mesa 18.x, so I'm going to hold off on unmasking xorg-server-1.20 until those are sorted. I think fixes are at least in progress for all of those, so I expect we're in good shape and will have unmasked 1.20 by next month. == Convert media-libs/mesa ebuild to build with Meson == https://bugs.gentoo.org/652762 Lots of progress. floppym made the necessary changes to meson.eclass to let Mesa's build system use a different *-llvm-config per-ABI by always using a cross file. That lets multilib builds work. There are a couple of (hopefully minor) configuration options missing from Mesa's meson.build, so I'm targeting next month for the transition of mesa-.ebuild to Meson. I plan to ship Mesa 18.2 build with Meson. == Update packages to depend on x11-base/xorg-proto == https://bugs.gentoo.org/656250 Arfrever continued transitioning whole categories at a time! Big thanks to him! Apr 1May 7 Jun 1 Packages depending on x11-proto/*: 530 -> 432 -> 35 [1] ebuilds depending on x11-proto/*: 1908 -> 1503 -> 59 [2] Just some games-*/* and kde-frameworks/* packages remain to be updated. == media-libs/vulkan-* split packages == Nick (sarnex) had lots of fun this month splitting packages out of media-libs/vulkan-loader: media-libs/vulkan-layers media-libs/vulkan-tools media-libs/vulkan-headers Upstream continues to churn things and doesn't seem to have a good grasp of how Linux distributions operate. Nick's done a good job keeping on top of upstream changes. == Tree cleaning == Removed: x11-proto/printproto x11-libs/libXp x11-libs/xpyb Given Last Rites: x11-libs/libXfont app-i18n/fbiterm (reverse dependency of libXfont) == Add and require glvnd == https://bugs.gentoo.org/606924 https://github.com/NVIDIA/libglvnd Package added under package.mask: # New package. Needs to interact with media-libs/mesa and # x11-drivers/nvidia-drivers. Work in progress. media-libs/libglvnd nvidia-drivers-375 and newer support glvnd, so I'll have to figure out how to make things work. I guess we'll have to keep eselect-opengl for older nvidia-drivers, which means updating it to support glvnd (instead of removing it) == Drop app-eselect/eselect-mesa == https://bugs.gentoo.org/576334 Removed from mesa-.ebuild and mesa-18.1.0-r1.ebuild. Once older versions are gone from the tree we can give eselect-mesa last rites. Without eselect-mesa, the Gallium i915 and swrast drivers are installed if USE=gallium; otherwise the classic versions are installed. I suspect this is good enough. == Fix/Remove OpenCL == https://bugs.gentoo.org/546320 https://bugs.gentoo.org/647330 No progress. == Clean out x11 overlay == https://gitweb.gentoo.org/proj/x11.git/ No progress. [1] git grep x11-proto | cut -d '/' -f -2 | grep -vE 'xorg-proto|metadata|profiles' | sort -u | wc -l [2] git grep x11-proto | grep -vE 'xorg-proto|metadata|profiles' | wc -l signature.asc Description: Digital signature
Re: [gentoo-dev] Developers, please start switching to 17.1 amd64 profiles
On Fri, May 25, 2018 at 12:29 PM, Georgy Yakovlev wrote: > On Tuesday, May 22, 2018 9:36:17 AM PDT Michał Górny wrote: >> Hi, everyone. >> >> With some delay, I would like to officially announce that the Council >> has approved the direction in which 17.1 amd64 profiles are heading at >> its 2018-04-08 meeting [1]. >> >> [3]:https://bugs.gentoo.org/506276 > > This eselect-mesa bug[1] needs at least some hacky workaround treatment before > final and proper eselect solution is implemented. > > It breaks opengl/graphics stack in a really sneaky way as nothing gets > eselected and absolutely no errors produced or displayed. > > sddm breaks, and some other X/OpenGL features do not work. > I have a patch from the bugreport in /etc/portage/patches for now, but > it takes users a while to figure it out why X11 or mesa was partially broken. > > Can this bug be given some priority treatment? > This will provide much smoother profile switch experience for desktop users. > Rest of LIBDIR bugs break software/build in a more obvious way and easy do > detect and work around or fix. > > [1]:https://bugs.gentoo.org/486712 > > -- > Georgy. I just dropped eselect-mesa support from media-libs/mesa -- see bug https://bugs.gentoo.org/576334 I'll be giving it last rites after Mesa 18.1 is stabilized. Go forth and test :)
[gentoo-dev] Last rites: x11-libs/libXfont
# Matt Turner (20 May 2018) # Removal in 30 days. Bug #655102 x11-libs/libXfont signature.asc Description: Digital signature
[gentoo-dev] Last rites: app-i18n/fbiterm
# Matt Turner (20 May 2018) # Unmaintained. Dead homepage. Depends on dead libXfont. # Removal in 30 days. Bug #655104 app-i18n/fbiterm signature.asc Description: Digital signature
Re: [gentoo-dev] Access to DRM render nodes from portage sandbox?
On Wed, May 9, 2018 at 11:43 AM, Matt Turner wrote: > Irrespective to the answer to that question, it's my opinion that we > should not execute code via the package manager that has the potential > to bring down the whole system. ... and if anyone doubts that possibility, please do a full piglit [1] run before you reply. [1] https://cgit.freedesktop.org/piglit/
Re: [gentoo-dev] Access to DRM render nodes from portage sandbox?
On Wed, May 9, 2018 at 10:19 AM, Alec Warner wrote: > On Wed, May 9, 2018 at 12:34 PM, Matt Turner wrote: >> >> On Tue, May 8, 2018 at 11:51 PM, Dennis Schridde >> wrote: >> > Hello! >> > >> > I see sandbox violations similar to "ACCESS DENIED: open_wr: /dev/dri/ >> > renderD128" pop up for more and more packages, probably since OpenCL >> > becomes >> > used more widely. Hence I would like to ask: Could we in Gentoo treat >> > GPUs >> > just like CPUs and allow any process to access render nodes (i.e. the >> > GPUs >> > compute capabilities via the specific interface the Linux kernel's DRM >> > offers >> > for that purpose) without sandbox restrictions? >> > >> > --Dennis >> > >> > See-Also: https://bugs.gentoo.org/654216 >> >> This seems like a bad idea. With CPUs we've had decades to work out >> how to isolate processes and prevent them from taking down the system. >> >> GPUs are not there yet. It's simple to trigger an unrecoverable GPU >> hang and not much harder to turn it into a full system lock up. >> >> >> This is not safe. >> > > Is the sandbox considered a security boundary? Certainly in earlier > (LD_PRELOAD based) implementation it was not. > Instead it was intended to protect the build environment from leaks (e.g. > accessing unwanted host state in the build env.) > > Sure it also in theory prevented build environments from writing to the > host; but it didn't do a very secure job of it. I don't know. Irrespective to the answer to that question, it's my opinion that we should not execute code via the package manager that has the potential to bring down the whole system.
Re: [gentoo-dev] Access to DRM render nodes from portage sandbox?
On Tue, May 8, 2018 at 11:51 PM, Dennis Schridde wrote: > I see sandbox violations similar to "ACCESS DENIED: open_wr: /dev/dri/ > renderD128" pop up for more and more packages, probably since OpenCL becomes > used more widely. I want to respond to the mention of OpenCL being more widely used... https://www.x.org/wiki/Events/XDC2017/Program/#tomstellardredhat-currentstateofopensourcegpgpu In short, the state of OpenCL in general is bad. On top of that, many of the implementations we have in Gentoo are unmaintained, despite my repeated requests of interested parties.
Re: [gentoo-dev] Access to DRM render nodes from portage sandbox?
On Tue, May 8, 2018 at 11:51 PM, Dennis Schridde wrote: > Hello! > > I see sandbox violations similar to "ACCESS DENIED: open_wr: /dev/dri/ > renderD128" pop up for more and more packages, probably since OpenCL becomes > used more widely. Hence I would like to ask: Could we in Gentoo treat GPUs > just like CPUs and allow any process to access render nodes (i.e. the GPUs > compute capabilities via the specific interface the Linux kernel's DRM offers > for that purpose) without sandbox restrictions? > > --Dennis > > See-Also: https://bugs.gentoo.org/654216 This seems like a bad idea. With CPUs we've had decades to work out how to isolate processes and prevent them from taking down the system. GPUs are not there yet. It's simple to trigger an unrecoverable GPU hang and not much harder to turn it into a full system lock up. This is not safe.
Re: [gentoo-dev] Monthly x11@ project status for May 2018
On Mon, May 7, 2018 at 11:24 PM, Brian Dolbec wrote: > On Mon, 7 May 2018 13:38:47 -0700 > Matt Turner wrote: > >> >> If there's a way to have repoman alert developers to deprecated >> dependencies in the same way we handle deprecated eclasses, I'd like >> to know about it. >> >> > > Currently there is not. > > Thinking out loud... It would mean parsing package.mask to generate > the list filtering out those with "masked for removal", from other > general mask reasons, but even that is not consistent. Thanks for the reply. One clarification: the x11-proto/* packages aren't package.masked (for removal or otherwise) -- just deprecated. They still exist just to provide a simpler transition to x11-base/xorg-proto. After all reverse dependencies are updated, they will indeed be tree cleaned. But yeah. I kind of like your idea. Perhaps some method of marking a package deprecated would be a good addition to PMS. I can imagine it being useful in a case like mine, and it would provide a good path towards tree cleaning. I've always thought it was kind of silly to start the 30-day removal timer only after the last dependency is gone from the tree, so maybe a way of marking a package deprecated could speed that up. The workflow I envisage would be (1) Package is marked as deprecated by some method (call it package.deprecated) repoman would now emit warnings when it finds a dependency on the deprecated package, informing developers of the necessary changes and speeding up the transition. (2) When the transition is complete, the deprecated package could be masked for removal under some <30 day mask or perhaps removed directly if it's been deprecated for >=30 days. I'll figure out the process for suggesting a future EAPI feature... :)
[gentoo-dev] Re: Monthly x11@ project status for May 2018
On Mon, May 7, 2018 at 1:38 PM, Matt Turner wrote: > == Convert media-libs/mesa ebuild to build with Meson == > https://bugs.gentoo.org/652762 > > Ebuild posted. Blocked on problems surrounding LLVM (this is the story of > maintaining media-libs/mesa). > > The problem is that Meson has no way of specifying a different llvm-config > binary without a cross file, which our meson.eclass does not generate for > 32-bit x86 builds on amd64. We've filed a Meson issue here [4] but haven't > seen > any progress towards a solution. Just wanted to highlight this section for the Meson maintainers specifically. Why do we not generate cross files for 32-bit builds on 64-bit? As far as I understand that would be sufficient for us. Do you have any suggestions?
[gentoo-dev] Monthly x11@ project status for May 2018
Firstly, I'd like to welcome Nick Sarnie to the X11 team. He's been very helpful in improving the state of media-libs/vulkan-loader for a while now, so it's nice to make it official! == Fix x11-base/xorg-server suid/systemd situation == https://bugs.gentoo.org/635102 Frustratingly, not sure if this is sorted out. In 1.19.99.904 [1] I modified things so that Xorg is installed setuid when USE=-systemd. Only got one test report (unsuccessful) but it could be a separate problem. Please test 1.19.99.905 (RC5). The next version will be 1.20. I would appreciate an ebuild patch from any elogind user for elogind support. == Update packages to depend on x11-base/xorg-proto == https://bugs.gentoo.org/651286 All architectures have stabilized x11-base/xorg-proto! Non-empty x11-proto/* packages have been removed. I was finally able to close out 15+ bugs about missing (transitive) dependencies on x11-proto/*. That felt good. About 20% of the way there since April 1st: Packages depending on x11-proto/* down from 530 -> 432 [2] ebuilds depending on x11-proto/* down from 1908 -> 1503 [3] Big thanks to Arfrever for handling whole categories at a time! If there's a way to have repoman alert developers to deprecated dependencies in the same way we handle deprecated eclasses, I'd like to know about it. == media-libs/vulkan-loader updates and features == https://bugs.gentoo.org/619124 Sarnex worked hard to get vulkan-loader updated. He added USE=layers and USE=demos. The "layers" are an important feature of Vulkan: validation layers that can be enabled to help you fix your application. == Xorg stabilization for May 2018 == https://bugs.gentoo.org/649316 Stabilization of 27 packages appears to be going rather smoothly. The new xorg-server version being stabilized contains a fix Sarnex found that will be necessary for Mesa 18.0. == Remove x11-proto/printproto and x11-libs/libXp == https://bugs.gentoo.org/649076 All blockers handled. Packages given last rites. Will be removed May 21st or soon thereafter. == Remove x11-libs/xpyb == https://bugs.gentoo.org/651300 Given last rites. Will be removed May 22nd or soon thereafter == Remove media-libs/libtxc_dxtn == https://bugs.gentoo.org/654464 I merged the S3TC texture compression code in libtxc_dxtn into Mesa for 17.3 (the patent expired! yay!). A couple of packages actually depend directly on libtxc_dxtn. Once those are fixed, we'll be able to tree clean it. == Remove x11-libs/libXfont == https://bugs.gentoo.org/655102 libXfont has been replaced by libXfont2. With a few packages fixed, we'll be able to tree clean the old slot. == Convert media-libs/mesa ebuild to build with Meson == https://bugs.gentoo.org/652762 Ebuild posted. Blocked on problems surrounding LLVM (this is the story of maintaining media-libs/mesa). The problem is that Meson has no way of specifying a different llvm-config binary without a cross file, which our meson.eclass does not generate for 32-bit x86 builds on amd64. We've filed a Meson issue here [4] but haven't seen any progress towards a solution. == Convert media-libs/xorg-server ebuild to build with Meson == No progress. == Add and require glvnd == https://bugs.gentoo.org/606924 https://github.com/NVIDIA/libglvnd No progress. == Drop app-eselect/eselect-mesa == https://bugs.gentoo.org/576334 No progress. == Fix/Remove OpenCL == https://bugs.gentoo.org/546320 https://bugs.gentoo.org/647330 No progress, but an upstream Mesa developer interested in OpenCL and Gentoo user is interested in contributing in order to get rid of eselect-opencl and to use the ICD interface instead. == Clean out x11 overlay == https://gitweb.gentoo.org/proj/x11.git/ No progress. [1] https://bugs.gentoo.org/635102#c31 [2] git grep x11-proto | cut -d '/' -f -2 | grep -v metadata | sort -u | wc -l [3] git grep x11-proto | wc -l [4] https://github.com/mesonbuild/meson/issues/3327 signature.asc Description: Digital signature
[gentoo-dev] Re: [PATCH] profiles/profiles.desc: move hppa profiles stable->exp
On Sun, May 6, 2018 at 2:20 AM, Sergei Trofimovich wrote: > To release the burden on maintainers having to keep outdated > latest stable versions of packages do not block them on hppa > stabilization. > > hppa@ will still attempt to keep stable keywords for base packages. > > CC: h...@gentoo.org > CC: j...@gentoo.org > CC: matts...@gentoo.org > Bug: https://bugs.gentoo.org/629554 > Signed-off-by: Sergei Trofimovich > --- > profiles/profiles.desc | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) > > diff --git a/profiles/profiles.desc b/profiles/profiles.desc > index 7d4b5781c88..5c5d06c7d96 100644 > --- a/profiles/profiles.desc > +++ b/profiles/profiles.desc > @@ -108,9 +108,9 @@ arm64 default/linux/arm64/17.0/systemd > dev > > # HPPA Profiles > # @MAINTAINER: h...@gentoo.org > -hppadefault/linux/hppa/13.0 stable > -hppadefault/linux/hppa/13.0/desktop dev > -hppadefault/linux/hppa/13.0/developer dev > +hppadefault/linux/hppa/13.0 exp > +hppadefault/linux/hppa/13.0/desktop exp > +hppadefault/linux/hppa/13.0/developer exp > hppadefault/linux/hppa/17.0 exp > hppadefault/linux/hppa/17.0/desktop exp > hppa default/linux/hppa/17.0/developer exp > -- > 2.17.0 > Acked-by: Matt Turner For those not in #gentoo-hppa, I attempted to start a conversation with Jeroen about moving hppa to fully ~arch last week. Rolf (who has been stabilizing packages on hppa and sparc) said he was against it, but Jeroen never replied.
Re: [gentoo-dev] bug queue size over time
On Wed, May 2, 2018 at 10:24 AM, Andreas K. Huettel wrote: > Am Mittwoch, 2. Mai 2018, 18:42:32 CEST schrieb Paweł Hajdan, Jr.: >> >> Just checking back here - what would be the best way to graph number of >> bugs with given assignee, preferably with historical backfill? >> >> I'm not necessarily looking for something ready to use right away. If >> there's some work to be done or code to implement, I may be willing to >> do so. >> >> Paweł > > Hi Pawel, > > some graphs already exist (and I'm doing it the dumb way, ask me about the > details if interested). E.g., > https://www.akhuettel.de/gentoo-bugs/arches.php > > Feel free to send me any e-mail addresses you want on a similar page; it's > fairly easy to add. I'm only adding fresh data, though, so if I dont have it > yet your line will start today. Please add mips@ and x11@. Thank you!
[gentoo-dev] [PATCH 4/4] kde4-base.eclass: Transition deps to x11-base/xorg-proto
--- eclass/kde4-base.eclass | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/eclass/kde4-base.eclass b/eclass/kde4-base.eclass index 8abade2677d4..72e4fcfe526b 100644 --- a/eclass/kde4-base.eclass +++ b/eclass/kde4-base.eclass @@ -387,7 +387,7 @@ kdedepend=" dev-util/automoc virtual/pkgconfig >=x11-libs/libXtst-1.1.0 - x11-proto/xf86vidmodeproto + x11-base/xorg-proto " kderdepend="" -- 2.16.1
[gentoo-dev] [PATCH 3/4] toolchain.eclass: Transition deps to x11-base/xorg-proto
---
eclass/toolchain.eclass | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/eclass/toolchain.eclass b/eclass/toolchain.eclass
index 2da455ad4e3b..df76dc4feb8c 100644
--- a/eclass/toolchain.eclass
+++ b/eclass/toolchain.eclass
@@ -206,11 +206,10 @@ DEPEND="${RDEPEND}
if in_iuse gcj ; then
GCJ_DEPS=">=media-libs/libart_lgpl-2.1"
GCJ_GTK_DEPS="
+ x11-base/xorg-proto
x11-libs/libXt
x11-libs/libX11
x11-libs/libXtst
- x11-proto/xproto
- x11-proto/xextproto
=x11-libs/gtk+-2*
virtual/pkgconfig
"
--
2.16.1
[gentoo-dev] [PATCH 2/4] xorg-2.eclass: Fix typo'd DRI_COMMON_DEPEND
---
eclass/xorg-2.eclass | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/eclass/xorg-2.eclass b/eclass/xorg-2.eclass
index 96a469163cfd..0329a7aa623a 100644
--- a/eclass/xorg-2.eclass
+++ b/eclass/xorg-2.eclass
@@ -210,7 +210,7 @@ case ${XORG_DRI} in
IUSE+=" ${XORG_DRI}"
;;
esac
-unset DRI_COMMONDEPEND
+unset DRI_COMMON_DEPEND
if [[ -n "${DRIVER}" ]]; then
COMMON_DEPEND+="
--
2.16.1
[gentoo-dev] [PATCH 1/4] xorg-2.eclass: Transition deps to x11-base/xorg-proto
DRI_DEPEND can go away since all xf86-video-* drivers now directly
depend on x11-base/xorg-proto, which includes the dependencies from
DRI_DEPEND.
---
eclass/xorg-2.eclass | 25 ++---
1 file changed, 2 insertions(+), 23 deletions(-)
diff --git a/eclass/xorg-2.eclass b/eclass/xorg-2.eclass
index 42067095b55b..96a469163cfd 100644
--- a/eclass/xorg-2.eclass
+++ b/eclass/xorg-2.eclass
@@ -199,25 +199,17 @@ DRI_COMMON_DEPEND="
x11-base/xorg-server[-minimal]
x11-libs/libdrm
"
-DRI_DEPEND="
- x11-proto/xf86driproto
- x11-proto/glproto
- x11-proto/dri2proto
-"
case ${XORG_DRI} in
no)
;;
always)
COMMON_DEPEND+=" ${DRI_COMMON_DEPEND}"
- DEPEND+=" ${DRI_DEPEND}"
;;
*)
COMMON_DEPEND+=" ${XORG_DRI}? ( ${DRI_COMMON_DEPEND} )"
- DEPEND+=" ${XORG_DRI}? ( ${DRI_DEPEND} )"
IUSE+=" ${XORG_DRI}"
;;
esac
-unset DRI_DEPEND
unset DRI_COMMONDEPEND
if [[ -n "${DRIVER}" ]]; then
@@ -226,26 +218,13 @@ if [[ -n "${DRIVER}" ]]; then
"
fi
if [[ -n "${DRIVER}" && ${PN} == xf86-input-* ]]; then
- DEPEND+="
- x11-proto/inputproto
- x11-proto/kbproto
- x11-proto/xproto
- "
+ DEPEND+="x11-base/xorg-proto"
fi
if [[ -n "${DRIVER}" && ${PN} == xf86-video-* ]]; then
COMMON_DEPEND+="
x11-libs/libpciaccess
"
- # we also needs some protos and libs in all cases
- DEPEND+="
- x11-proto/fontsproto
- x11-proto/randrproto
- x11-proto/renderproto
- x11-proto/videoproto
- x11-proto/xextproto
- x11-proto/xineramaproto
- x11-proto/xproto
- "
+ DEPEND+="x11-base/xorg-proto"
fi
# @ECLASS-VARIABLE: XORG_DOC
--
2.16.1
[gentoo-dev] Last rites: x11-libs/xpyb
# Matt Turner (21 Apr 2018) # Awful, unmaintained, unused. Removal in 30 days. Bug #651300. x11-libs/xpyb signature.asc Description: Digital signature
[gentoo-dev] Last Rites: x11-libs/libXp and x11-proto/printproto
# Matt Turner (21 Apr 2018) # Protocol headers and client library for the long dead Xprint extension. # Removal in 30 days. Bug #649076. x11-proto/printproto x11-libs/libXp signature.asc Description: Digital signature
