Re: [gentoo-dev] LiveCD Project disbanding: packages up for grabs
On Fri, Nov 6, 2020 at 7:24 PM Patrick McLean wrote: > > On Wed, 4 Nov 2020 16:09:37 -0500 > Matt Turner wrote: > > > The LiveCD project is only me now, which isn't much of a project, so > > I'm putting these packages up for grabs. livecd@ is co-maintainer on a > > few others that aren't listed. > > > > app-misc/livecd-tools > > > > - Releng@ will take this > > > > sys-libs/libkudzu > > sys-apps/hwdata-gentoo > > sys-apps/hwsetup > > > > - These are used on the Live CDs, but I don't know if they actually > > do anything useful. > > - Releng@ will take them with the understanding that I might remove > > them from the tree. > > > > dev-python/pyparted > > dev-util/dialog > > sys-block/parted > > sys-fs/squashfs-tools > > x11-themes/gentoo-artwork-livecd > > Please do not remove pyparted, parted or squashfs-tools these are most > certainly useful. I will maintain them if RelEng does not want them. I'm not planning to...? The comment about "I might remove them from the tree" was in reference to the packages above it: libkudzu, hwdata-gentoo, and hwsetup.
Re: [gentoo-dev] New QA policy suggestion: Disallow "live-only" packages
On Tue, Nov 3, 2020 at 12:13 AM Joonas Niilola wrote: > I'm suggesting a new QA policy to disallow any "live-ebuild-only > packages" being hosted in ::gentoo. Is there value in making snapshots of app-portage/no-distcc-env? I don't really think so, and that's why I didn't do it. Should I reconsider?
[gentoo-dev] LiveCD Project disbanding: packages up for grabs
The LiveCD project is only me now, which isn't much of a project, so I'm putting these packages up for grabs. livecd@ is co-maintainer on a few others that aren't listed. app-misc/livecd-tools - Releng@ will take this sys-libs/libkudzu sys-apps/hwdata-gentoo sys-apps/hwsetup - These are used on the Live CDs, but I don't know if they actually do anything useful. - Releng@ will take them with the understanding that I might remove them from the tree. dev-python/pyparted dev-util/dialog sys-block/parted sys-fs/squashfs-tools x11-themes/gentoo-artwork-livecd
[gentoo-dev] [PATCH 1/2] xorg-3.eclass: Drop font IUSE=nls handling
The previous logic incorrectly added IUSE=nls for font-bitstream-100dpi,
font-bitstream-75dpi, font-cronyx-cyrillic, font-misc-cyrillic,
font-screen-cyrillic, and font-winitzki-cyrillic. This caused
"QA Notice: Unrecognized configure options: ..." with USE=-nls.
Instead, we'll simply have IUSE="nls" in the packages' ebuilds that need
it.
Closes: https://bugs.gentoo.org/745756
Signed-off-by: Matt Turner
---
eclass/xorg-3.eclass | 2 --
1 file changed, 2 deletions(-)
diff --git a/eclass/xorg-3.eclass b/eclass/xorg-3.eclass
index 78c843401cc..af28f6fa30d 100644
--- a/eclass/xorg-3.eclass
+++ b/eclass/xorg-3.eclass
@@ -168,8 +168,6 @@ if [[ ${FONT} == yes ]]; then
FONT_DIR=${FONT_DIR/otf/OTF}
FONT_DIR=${FONT_DIR/type1/Type1}
FONT_DIR=${FONT_DIR/speedo/Speedo}
-
- [[ ${PN} = font-misc-misc || ${PN} = font-schumacher-misc || ${PN##*-}
= 75dpi || ${PN##*-} = 100dpi || ${PN##*-} = cyrillic ]] && IUSE+=" nls"
fi
# @ECLASS-VARIABLE: XORG_STATIC
--
2.26.2
Re: [gentoo-dev] [PATCH 1/2] xorg-3.eclass: Fix font IUSE=nls handling
On Thu, Oct 1, 2020 at 1:07 AM Ulrich Mueller wrote:
>
> >>>>> On Thu, 01 Oct 2020, Matt Turner wrote:
>
> > - [[ ${PN} = font-misc-misc || ${PN} = font-schumacher-misc ||
> > ${PN##*-} = 75dpi || ${PN##*-} = 100dpi || ${PN##*-} = cyrillic ]] &&
> > IUSE+=" nls"
> > + case ${PN#font-} in
> > +
> > adobe-100dpi|adobe-utopia-100dpi|bh-100dpi|bh-lucidatypewriter-100dpi|\
> > + adobe-75dpi |adobe-utopia-75dpi |bh-75dpi |bh-lucidatypewriter-75dpi|\
> > + misc-misc|schumacher-misc)
> > + IUSE+=" nls"
> > + ;;
> > + esac
>
> This looks like the kind of logic that would better be moved to ebuilds.
> Especially when it has just proven to be error prone.
Yeah, that seems like a good idea. In fact, that seems easier since
it's actually xorg-3_font_configure() that uses the presence of nls to
choose configure arguments. I think I can simply add IUSE="nls" to the
relevant packages and remove this code from the eclass.
Thanks for making me think through that again!
[gentoo-dev] [PATCH 2/2] xorg-3.eclass: Require --disable-all-encodings for fonts
Presumably in the distant past all font packages did not support this
option. They do today, so we can simplify our logic.
Signed-off-by: Matt Turner
---
eclass/xorg-3.eclass | 28 +---
1 file changed, 5 insertions(+), 23 deletions(-)
diff --git a/eclass/xorg-3.eclass b/eclass/xorg-3.eclass
index 515c1aeea2e..543021af46e 100644
--- a/eclass/xorg-3.eclass
+++ b/eclass/xorg-3.eclass
@@ -338,30 +338,12 @@ xorg-3_font_configure() {
debug-print-function ${FUNCNAME} "$@"
if has nls ${IUSE//+} && ! use nls; then
- if grep -q -s "disable-all-encodings"
${ECONF_SOURCE:-.}/configure; then
- FONT_OPTIONS+="
- --disable-all-encodings
- --enable-iso8859-1"
- else
- FONT_OPTIONS+="
- --disable-iso8859-2
- --disable-iso8859-3
- --disable-iso8859-4
- --disable-iso8859-5
- --disable-iso8859-6
- --disable-iso8859-7
- --disable-iso8859-8
- --disable-iso8859-9
- --disable-iso8859-10
- --disable-iso8859-11
- --disable-iso8859-12
- --disable-iso8859-13
- --disable-iso8859-14
- --disable-iso8859-15
- --disable-iso8859-16
- --disable-jisx0201
- --disable-koi8-r"
+ if ! grep -q -s "disable-all-encodings"
${ECONF_SOURCE:-.}/configure; then
+ die "--disable-all-encodings option not available in
configure"
fi
+ FONT_OPTIONS+="
+ --disable-all-encodings
+ --enable-iso8859-1"
fi
}
--
2.26.2
[gentoo-dev] [PATCH 1/2] xorg-3.eclass: Fix font IUSE=nls handling
The previous logic incorrectly added IUSE=nls for font-bitstream-100dpi,
font-bitstream-75dpi, font-cronyx-cyrillic, font-misc-cyrillic,
font-screen-cyrillic, and font-winitzki-cyrillic. This caused
"QA Notice: Unrecognized configure options: ..." with USE=-nls.
Closes: https://bugs.gentoo.org/745756
Signed-off-by: Matt Turner
---
eclass/xorg-3.eclass | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/eclass/xorg-3.eclass b/eclass/xorg-3.eclass
index 78c843401cc..515c1aeea2e 100644
--- a/eclass/xorg-3.eclass
+++ b/eclass/xorg-3.eclass
@@ -169,7 +169,13 @@ if [[ ${FONT} == yes ]]; then
FONT_DIR=${FONT_DIR/type1/Type1}
FONT_DIR=${FONT_DIR/speedo/Speedo}
- [[ ${PN} = font-misc-misc || ${PN} = font-schumacher-misc || ${PN##*-}
= 75dpi || ${PN##*-} = 100dpi || ${PN##*-} = cyrillic ]] && IUSE+=" nls"
+ case ${PN#font-} in
+ adobe-100dpi|adobe-utopia-100dpi|bh-100dpi|bh-lucidatypewriter-100dpi|\
+ adobe-75dpi |adobe-utopia-75dpi |bh-75dpi |bh-lucidatypewriter-75dpi|\
+ misc-misc|schumacher-misc)
+ IUSE+=" nls"
+ ;;
+ esac
fi
# @ECLASS-VARIABLE: XORG_STATIC
--
2.26.2
Re: [gentoo-dev] Last Rites: app-eselect/eselect-opengl
On Tue, Aug 11, 2020 at 8:00 PM Philip Webb wrote:
>
> 200811 Matt Turner wrote:
> > # Matt Turner (2020-08-11)
> > # Replaced by media-libs/libglvnd.
> > # Masked for removal in 30 days. Bug #728286
> > app-eselect/eselect-opengl
>
> root:552 ~> emerge -cpv eselect-opengl
> Calculating dependencies... done!
> app-eselect/eselect-opengl-1.3.1-r4 pulled in by:
> media-libs/mesa-20.0.8 requires >=app-eselect/eselect-opengl-1.3.0
> x11-base/xorg-server-1.20.8-r1 requires >=app-eselect/eselect-opengl-1.3.0
>
> 'mesa' is installed with USE="egl", which perhaps needs changing :
>
> root:554 ~> eixe mesa
> [I] media-libs/mesa
> Available versions: 20.0.8^t ~20.1.4^t ~20.1.5^t ***l^t {+X
> +classic d3d9 debug +dri3 +egl +gallium +gbm gles1 +gles2 +libglvnd +llvm
> lm-sensors opencl osmesa selinux test unwind vaapi valgrind vdpau vulkan
> vulkan-overlay wayland xa xvmc +zstd ABI_MIPS="n32 n64 o32" ABI_RISCV="lp64
> lp64d" ABI_S390="32 64" ABI_X86="32 64 x32" KERNEL="linux"
> VIDEO_CARDS="freedreno i915 i965 intel iris lima nouveau panfrost r100 r200
> r300 r600 radeon radeonsi vc4 virgl vivante vmware"}
> Installed versions: 20.0.8^t([2020-06-20 09:13:08])(X egl gallium gbm
> wayland -classic -d3d9 -debug -dri3 -gles1 -gles2 -libglvnd -llvm -lm-sensors
> -opencl -osmesa -selinux -test -unwind -vaapi -valgrind -vdpau -vulkan
> -vulkan-overlay -xa -xvmc -zstd ABI_MIPS="-n32 -n64 -o32" ABI_RISCV="-lp64
> -lp64d" ABI_S390="-32 -64" ABI_X86="64 -32 -x32" KERNEL="linux"
> VIDEO_CARDS="nouveau -freedreno -i915 -i965 -intel -iris -lima -panfrost
> -r100 -r200 -r300 -r600 -radeon -radeonsi -vc4 -virgl -vivante -vmware")
>
> but there is no similar flag on 'xorg-server' :
>
> root:553 ~> eix xorg-server
> [I] x11-base/xorg-server
> Available versions: 1.20.8(0/1.20.8) 1.20.8-r1(0/1.20.8)
> **(0/)*l {debug dmx doc (+)elogind ipv6 kdrive +libglvnd libressl
> minimal selinux static-libs (+)suid systemd +udev unwind wayland xcsecurity
> xephyr xnest xorg xvfb}
> Installed versions: 1.20.8-r1(0/1.20.8)([2020-08-09 20:16:16])(elogind
> udev xorg -debug -dmx -doc -ipv6 -kdrive -libglvnd -libressl -minimal
> -selinux -static-libs -suid -systemd -unwind -wayland -xcsecurity -xephyr
> -xnest -xvfb)
>
> Before I do anything damaging, can you advise how to handle the above ?
The eix output indicates that you have both mesa and xorg-server built
with USE=-libglvnd. Rebuild both with USE=libglvnd, and then neither
will depend on eselect-opengl. In the same series of commits as I
added this mask, I added 'libglvnd' to use.force, so no local
configuration changes should be necessary, although you appear to have
USE=-libglvnd set somewhere, so you probably will want to clean that
up.
[gentoo-dev] Last Rites: app-eselect/eselect-opengl
# Matt Turner (2020-08-11) # Replaced by media-libs/libglvnd. # Masked for removal in 30 days. Bug #728286 app-eselect/eselect-opengl signature.asc Description: PGP signature
[gentoo-dev] Last Rites: app-eselect/eselect-opencl
# Matt Turner (2020-08-11) # No longer needed with virtual/opencl-3 # Masked for removal in 30 days. Bug #728284 app-eselect/eselect-opencl signature.asc Description: PGP signature
[gentoo-dev] Last Rites: x11-drivers/nvidia-drivers:0/340
# Matt Turner (2020-08-11) # NVIDIA declared this branch to have reached end of life about six months ago. # Blocks removal of app-eselect/eselect-opengl and app-eselect/eselect-opencl. # Masked for removal in 30 days. Bug #728290 x11-drivers/nvidia-drivers:0/340 signature.asc Description: PGP signature
Re: [gentoo-dev] Python 2.7 cleanup: plan B
On Tue, Aug 11, 2020 at 9:31 AM Michał Górny wrote: > TL;DR: we might keep Python 2.7 supported as a build-time dependency > of a few packages as necessary, while removing the eclass support for > installing packages for py2.7. I think this is the right plan (and is along the lines of what I suggested in the context of removing offlineimap, which didn't need anything except the Python 2.7 interpreter).
Re: [gentoo-dev] xorg-x11 RDEPEND changes without revisions
On Fri, Aug 7, 2020 at 11:25 AM Michael Orlitzky wrote: > I have too many other things to do to waste time reverse-engineering > these fuck-ups. Get it together. You're fucking welcome for all the X11 maintenance.
[gentoo-dev] Last Rites: dev-util/cmdtest
# Matt Turner (2020-08-03) # Package is dead and upstream maintainer asked that it be removed. # Removal in 30 days. Bug #735314 dev-util/cmdtest signature.asc Description: PGP signature
Re: [gentoo-dev] Last rites: */*: More Py2 stuff
On Tue, Jul 28, 2020 at 7:32 PM Aaron Bauman wrote: > On July 28, 2020 9:57:44 PM EDT, Gordon Pettey wrote: > >That dependency is only if USE="-gnuefi". sys-boot/gnu-efi has no > >Python > >dependency. Instead of masking/removing refind, remove the USE flag and > >force the gnu-efi dependency, or reverse the condition, add > >IUSE="tianocore", and mask that USE flag. > > > >On Tue, Jul 28, 2020 at 7:06 PM Aaron Bauman wrote: > > > >> On Tue, Jul 28, 2020 at 04:55:57PM -0700, Matt Turner wrote: > >> > On Tue, Jul 28, 2020 at 4:17 PM Aaron Bauman > >wrote: > >> > > sys-boot/refind > >> > > >> > How did you conclude that this package depends on Python at all? > >> > > >> > >> Hi, Matt. It has a dependency on sys-boot/udk which was masked due to > >> using py2.7 only. Hope that helps. > >> > >> -- > >> Cheers, > >> Aaron > >> > > That is for the maintainer to decide. Hence, all the previous discussions > surrounding this topic. It is a massive undertaking to remove py2.7 from the > tree. You've made a very strong case for filing bugs and asking maintainers to figure out what to do before masking packages for removal.
Re: [gentoo-dev] Last rites: */*: More Py2 stuff
On Tue, Jul 28, 2020 at 4:17 PM Aaron Bauman wrote: > sys-boot/refind How did you conclude that this package depends on Python at all?
Re: [gentoo-dev] */*: Mask Py2 only packages
On Thu, Jun 25, 2020 at 8:14 PM Aaron Bauman wrote: > > On Wed, Jun 24, 2020 at 10:12:18AM -0700, Matt Turner wrote: > > offlineimap is widely used and blocks no further work. It can easily > > remain in the tree after all other python2_7 support is gone. > > > > This is not a hill worth dying on. > > > > I am confused here... are you saying that due to usage of the package > that it should stay until dev-lang/python:2 is gone? > > More importantly, I simply responded to Thomas' mention that the package > has alternatives, but apparently, I don't understand how the package is > used :) Two reasons: because it's widely used *and* because its python:2.7 dependency is on only the interpreter itself. The second reason means that its removal doesn't enable any further clean ups.
Re: [gentoo-dev] */*: Mask Py2 only packages
On Wed, Jun 24, 2020 at 2:52 AM Thomas Deutschmann wrote: > On 2020-06-20 21:24, Aaron Bauman wrote: > > Thomas, unfortunately, I am shocked at your choice of words here. I > > think it is reasonable that any developer would understand a lack > > of forward momentum in removing Py2 only packages only drives > > stagnation. > > > > If you have a more effective method to doing so, I am open to > > suggestions. > > Like I am shocked about your recent actions: I'm shocked that you're shocked that he's shocked! Let's stop the theatrics.
Re: [gentoo-dev] */*: Mask Py2 only packages
On Sat, Jun 20, 2020 at 12:24 PM Aaron Bauman wrote: > > On Sat, Jun 20, 2020 at 01:29:46PM +0200, Thomas Deutschmann wrote: > > On 2020-06-20 12:07, Michał Górny wrote: > > >> Al least, python2 is not on your list. > > >> > > >> Be first into the future by masking this stuff and > > >> Last out of the past by leaving up to users to decide. > > >> It could stay in the tree, masked, as long as python2. > > >> > > > > > > Do you really think it'd be better to last rite a 1000 packages > > > simultaneously? > > > > What's the purpose of this at all? > > > > dev-lang/python:2.7 won't go away that soon. > > > > Removing perfectly working and up-to-date software which is in > > maintenance-only mode like net-mail/offlineimap is just not user-friendly. > > > > It doesn't even has deps on other Python packages blocking your cleanup > > delusion. > > > > Thomas, unfortunately, I am shocked at your choice of words here. I > think it is reasonable that any developer would understand a lack > of forward momentum in removing Py2 only packages only drives > stagnation. > > If you have a more effective method to doing so, I am open to > suggestions. Between the disagreements about whether a package should be masked, the length of time the last rites period should be, and the steps required to disband a project, I think there's been enough pushback that it's necessary to change how you approach these projects. Please start by using the standard 30-day last rites period. It's a simple thing and whether the packages are in tree for an additional 16 days should not affect any of your work. > re: net-mail/offlineimap... there are alternatives. Removing python2_7 support from the tree is a valuable goal, but offlineimap is widely used and blocks no further work. It can easily remain in the tree after all other python2_7 support is gone. This is not a hill worth dying on.
Re: [gentoo-dev] Re: News item: xorg-server dropping default suid
On Sun, Jun 21, 2020 at 4:53 PM Philip Webb wrote: > > 200621 Piotr Karbowski wrote: > > Title: xorg-server dropping default suid > ... > > The Gentoo X11 Team is announcing that starting with 15th of July, > > the x11-base/xorg-server will no longer default to suid > > and will default to using logind interface instead. This change > > makes xorg-server run as regular user rather than root by default, > > however those who do not have any logind interface provider > > -- either systemd or elogind -- will need to enable either > > to make it possible to run X session as unprivileged user. > > No action is required from systemd and desktop profile users, > > since systemd provides logind interface > > and desktop profile already enables 'elogind' USE flag globally. > > Rest of the non-systemd users is required to globally enable > > 'elogind' USE flag and apply it by 'emerge --newuse @world', > > after which, re-login is required so that PAM can allocate seat. > > One can confirm that a seat has been assigned upon login by running: > > $ loginctl user-status > > Those who for whatever reason want to preserve current state, > > while heavily discouraged, > > can still use x11-base/xorg-server with 'suid -elogind'. > > Gentoo Wiki says : > > elogind is the systemd project's logind, extracted to a standalone package. > It's designed for users who prefer a non-systemd init system, > but still want to use popular software such as KDE/Wayland or GNOME > that otherwise hard-depends on systemd. > > startx integration : To have an elogind session created > when using startx to start the X server (instead of a display manager), > add the following to the user's ~/.xinitrc file : FILE ~/.xinitrc >exec dbus-launch --exit-with-session > WINDOW_MANAGER in the above example needs to be replaced > by a window manager or a single application. > > I want to use 'startx' to start X , because I don't want to be trapped > if some problem arises with X or KDE or the login manager > & I need to change config files or remerge pkgs (etc) to rescue myself. > With 'startx' I can do all that work from raw TTYs with no problems, > as I am not forced to go into an X session if I don't want to. Thank you for actually participating in the discussion, unlike the last thread about this topic. > I don't want to use 'systemd', as I want to run a traditional UNIX version > of Linux + KDE (or Fluxbox) for a simple single-user desktop system. > > Why is running 'xorg-server' as root "heavily discouraged" ? > -- I've been doing that with Gentoo for > 16 yr without any problems. > AFAIK there are no problems re exploits via I/net browsers, > which are started by my user as all such user software always is. > What might go wrong, if I continue to 'startx' > with 'xorg-server' merged with 'suid -elogind' > & without the '.xinitrc' line show above in the Wiki ? For the majority of users (those that use a graphics driver with kernel modesetting support), X only needs root access for a small set of things: accessing the DRM device node, accessing the input device nodes, and some stuff around VTs. The rest of the time, X doesn't need root access but still must run as root for those cases I mention. With elogind, those bits are handled in a small daemon, and X no longer needs to run as root. Most people find that to be valuable, especially with the knowledge that there have been a number of security vulnerabilities found that would allow arbitrary code execution in the xserver over the years [1]. Our current default of USE=suid installs /usr/bin/Xorg with the setuid bit set, allowing it to be run *as root* by any user. This enables non-root users to execute startx, for example. I appreciate that Gentoo users are a diverse bunch, to say the least. This news item is about *defaults*. I'm happy to explain the value of the new default to people who are genuinely curious but I have no interest in trying to convince you or anyone else of anything. You're free to keep the status quo with a single line in /etc/portage/package.use. The people building and maintaining the distro think that the new defaults are better defaults for the vast majority of users, but again they're just defaults. [1] https://www.cvedetails.com/vulnerability-list/vendor_id-88/product_id-8600/X.org-Xorg-server.html
Re: [gentoo-dev] Last rites: app-cdr/sync2d
On Fri, Jun 5, 2020 at 9:55 AM Jonas Stein wrote: > > On 04/06/2020 01.39, Aaron Bauman wrote: > > # Aaron Bauman (2020-06-03) > > # py2 only. dead upstream. m-n. > > # Masked for removal in 15 days > > app-cdr/sync2cd > > > > is there a good reason to reduce the time to 15 days? > > https://devmanual.gentoo.org/ebuild-maintenance/removal/index.html > "Wait 30 days (or more)" I think we all agree that Python 2-only packages are going to have to be removed. This package is Python 2-only, and it was last released more than 13 years ago, and the website even says that the project is dead (http://c-space.org/). With that in mind, I don't expect it to gain Python 3 support, nor do I expect an additional 15 days of waiting time to change that fact. 15 vs 30 days doesn't seem worth squabbling over.
Re: [gentoo-dev] Value of Continuous integration vs Code Review / Pull Requests
On Wed, May 27, 2020 at 1:14 AM Alec Warner wrote: > On Tue, May 26, 2020, 23:08 Michał Górny wrote: >> >> On Tue, 2020-05-26 at 20:24 -0700, Alec Warner wrote: >> > The TL;DR is that a crack team of infra-folks[0] have been putting together >> > demos of CI services and things like gitlab / gitea / gerrit and so on. >> > >> > Some of these come in combined (e.g. gitlab offers repo hosting, code >> > review / pull reqs, CI services, and deploy services.) Some of these are >> > piecemeal (e.g. gerrit has code review, zuul has CI) and gitea offers >> > repo-hosting but CI is separate (e.g. drone.) >> > >> > On the infra-side, I think we are pretty happy with repo-hosting (gitolite) >> > and repo-serving (gitweb). We are missing a CI piece and a pull-request >> > piece. Most of the users using PRs use either a gitlab or github mirror. >> > >> > I think the value of CI is pretty obvious to me (and I see tons of use >> > cases in Infra.) We could easily build CI into our current repository >> > solution (e.g. gitolite.) However gitolite doesn't really support PRs in a >> > uniform way and so CI is mostly for submitted code; similar to the existing >> > ::gentoo repo CI offered by mgorny. >> > >> > If we build a code review solution (like gitea / gerrit) would people use >> > it? Would you use it if you couldn't merge (because the code review >> > solution can't gpg sign your commits or merges) so a tool like the existing >> > pram tool would be needed to merge? >> > >> >> Does GitLab count? Gerrit is just PITA. I think we had some concerns >> about Gitea, so I'd like to test it before deciding. GitLab OTOH works >> just fine for a lot of projects, and seems the next best thing after >> GitHub > > > Gitlab does count (we deployed and tested an onprem version.) I think there > are some major issues with it though. > - Licensing. Gitlab-CE is available, gitlab-EE is not OSS nor OSI approved > and many of the features we need are EE only and are not available in CE. It's very surprising to me that CE wouldn't work for our purposes. Debian, GNOME, KDE, XFCE, and FreeDesktop have all switched to GitLab and are using CE. It's hard to believe that Gentoo's usage or requirements would be so different as to make GitLab a non-viable option. What features of EE do you think we need?
Re: [gentoo-dev] New USE=-native-symlinks for gcc-config and binutils-config
On Sat, May 23, 2020 at 10:21 PM Joonas Niilola wrote: > > > On 5/24/20 5:41 AM, Mike Gilbert wrote: > > Also, people are likely to disable this accidentally via USE="-*". > > Counts as > > > if they want to break their system intentionally. Yes, but unfortunately catalyst's stage1 build does exactly this. Suggestions how to avoid doing this would be appreciated, but until that's resolved we don't have carte blanche to break USE="-*".
Re: [gentoo-dev] [PATCH 0/1] remove EGO_VENDOR support from go-module.eclass
On Mon, May 11, 2020 at 4:00 PM William Hubbs wrote: > > On Tue, May 12, 2020 at 01:45:45AM +0300, Andreas K. Hüttel wrote: > > > This patch makes migrating mandatory by forcing ebuilds to die if they > > > have EGO_VENDOR set and are using go-module.eclass. > > > > You can't commit this as long as there is a single such ebuild in the tree. > > Sure, and I'm working on migrating them. I think all the replies to this thread could have been avoided by just saying that in your initial email. :)
Re: [gentoo-dev] [RFC] Ideas for gentoostats implementation
On Mon, May 4, 2020 at 5:48 PM Thomas Deutschmann wrote: > > On 2020-04-26 15:46, Kent Fredric wrote: > > On Sun, 26 Apr 2020 14:38:54 +0200 > > Thomas Deutschmann wrote: > > > >> Let's assume we will get reports that app-misc/foo is only installed 20 > >> times. If you are going to judge based on this data, "Obviously, nobody > >> is using that package, it's stuck on ... safe to remove" your > >> view is biased: > > > > I see this as more like what bloom filters get you, but in reverse: > > > > [...] > > > > - But now, instead of having "we don't know if anybody uses this", you > > *can* have a "we know for sure somebody uses this". > > But how does that information really help us to decide anything in the end? > > Case A, stats are showing 0 users: > > Like said, we can't know if this is true or if this package is only used > in setups where people don't report stats. > > > Case B, stats are showing x users: > > Now what? Package from case A could have similar users -- we just don't > know. Assume firefox has 1.000 users, chromium has 500 users and vivaldi > doesn't show up in stats. How does that help us? Would this allow us to > skip publishing GLSAs for vivalid because we assume nobody in Gentoo is > using vivaldi? Does it allow Python project to go forward pushing a mask > for removal in case vivaldi would depend on Python version, Python > project want to get rid of? Would this allow Gentoo PR to make a public > statement like "Firefox is the most popular browser in Gentoo, twice as > users as chromium"? I hate the saying "the perfect is the enemy of the good" but I think it applies here. You're of course correct that we would not have perfect information. But the thing about statistics is that you can still know some things based on a sampling of that perfect information. I would personally like to have data on whether users of my packages have certain USE flags enabled. Knowing that would allow me to decide whether its worth the maintenance burden of supporting features that I *think* are very rarely used. If instead the data showed me that 50% of users had IUSE=xyz enabled, I probably wouldn't consider removing it. I think your example of potential misuse of data is a bit over dramatic.
Re: [gentoo-dev] [RFC] Mask gnome-extra/cinnamon and deps for removal
On Thu, Apr 30, 2020 at 2:32 PM Olivier Laurantin wrote: > > Hi, blueberry is developed by the cinnamon team but can be used without > cinnamon (it should work fine with mate, gnome or xfce at least). > I can maintain dev-python/xapp if necessary. Thanks for confirming. Yes, please add yourself to metadata.xml of x11-libs/xapps and dev-python/xapp if you wouldn't mind :) > According to https://bugs.gentoo.org/704532 there might be some people > interested in maintaining cinnamon. Are they aware of its possible removal? Hm, no. I hadn't noticed that bug. Hopefully they'll get picked up by proxy maintainers, etc.
[gentoo-dev] Last Rites: Cinnamon
# Matt Turner (2020-04-30) # Unmaintained. Blocks removal of other dead packages. No Python3 support. # Masked for removal in 30 days. Bug #720190 gnome-extra/cinnamon gnome-extra/cinnamon-control-center gnome-extra/cinnamon-desktop gnome-extra/cinnamon-menus gnome-extra/cinnamon-screensaver gnome-extra/cinnamon-session gnome-extra/cinnamon-settings-daemon gnome-extra/cinnamon-translations gnome-extra/cjs gnome-extra/nemo x11-wm/muffin signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] Mask gnome-extra/cinnamon and deps for removal
On Tue, Apr 28, 2020 at 10:06 PM Joonas Niilola wrote: > > > On 4/28/20 9:18 PM, Matt Turner wrote: > > I'd like to mask the following packages for removal due to lack of an > > active maintainer. I'll wait a couple of days for comments before > > adding the mask to be extra nice. > > > > dev-python/xapp > > Note that (at least) this has revdeps outside cinnamon. Thanks, you're right. I excluded net-wireless/blueberry from this list because it has a maintainer other than cinnamon@. I assume that means it's useful outside of cinnamon, or should it go to?
[gentoo-dev] [RFC] Mask gnome-extra/cinnamon and deps for removal
I'd like to mask the following packages for removal due to lack of an active maintainer. I'll wait a couple of days for comments before adding the mask to be extra nice. dev-python/xapp gnome-extra/cinnamon gnome-extra/cinnamon-control-center gnome-extra/cinnamon-desktop gnome-extra/cinnamon-menus gnome-extra/cinnamon-screensaver gnome-extra/cinnamon-session gnome-extra/cinnamon-settings-daemon gnome-extra/cinnamon-translations gnome-extra/cjs gnome-extra/nemo x11-libs/xapps x11-wm/muffin
Re: [gentoo-dev] [PATCH] Have x11-drivers/nvidia-drivers use an ICD loader
On Mon, Apr 20, 2020 at 5:14 AM Marek Szuba wrote: > > On 2020-04-20 06:13, Joonas Niilola wrote: > > > He has been on devaway for a while. > > > > I would've much rather seen the differences between -r0 -r1 ebuilds to > > focus on what is actually done there. Not that I have any say what will > > be done in the end, but it's easier for the eyes... > > Indeed, that is a bit of a problem with revbumps. That said, jer did > update the ebuilds today (jer: thank you!) so no list review will be > required after all... > > OpenCL status update: looks like we are good to go, I'll run some tests > to confirm that there are no obvious issues with the deptree and > assuming there aren't, will unleash the whole thing (by which I mean > "post the news item and unmask the updated loader packages") on the > unsuspecting public this weekend. Great! Thank you so much for your work on this.
[gentoo-dev] Re: [PATCH] meson.eclass: export NM and READELF variables
Nice. Thanks!
Re: [gentoo-dev] [PATCH] fcaps.eclass: Remove sys-libs/libcap-ng support
On Wed, Apr 15, 2020 at 6:44 AM David Michael wrote: > > On Tue, Apr 14, 2020 at 10:32 PM Matt Turner wrote: > > At the same time, fix the dependency on sys-libs/libcap by moving it to > > RDEPEND, as dependencies in DEPEND/BDEPEND are not guaranteed to exist > > during pkg_postinst() when this eclass is intended to run. > > The BDEPEND was added for https://bugs.gentoo.org/700018 , which is > still needed so the command is in / during sysroot builds, or > installing fails. Maybe deps could be: > > EAPI < 7: RDEPEND > EAPI = 7: RDEPEND + BDEPEND > EAPI > 7: IDEPEND Thanks, yeah. That makes sense.
Re: [gentoo-dev] [PATCH] fcaps.eclass: Remove sys-libs/libcap-ng support
On Wed, Apr 15, 2020 at 1:37 AM Ulrich Mueller wrote: > > >>>>> On Wed, 15 Apr 2020, Matt Turner wrote: > > > At the same time, fix the dependency on sys-libs/libcap by moving it to > > RDEPEND, as dependencies in DEPEND/BDEPEND are not guaranteed to exist > > during pkg_postinst() when this eclass is intended to run. > > This is a CBUILD type dependency, right? Then there is no good way to > express it in EAPI 7. Still, I think that it should be specified in > BDEPEND (and maybe RDEPEND in addition). I'm not sure what CBUILD means. What is that?
[gentoo-dev] [PATCH] fcaps.eclass: Remove sys-libs/libcap-ng support
libcap-ng-0.7.10 changed the output format slightly (in upstream commit
bc1a9c07ebf5 "- Add capng_have_permitted_capabilities function and use
it in filecap"), breaking our usage of it. It's obvious that it's not
supposed to be used programmatically given the awful sed'ing we were
already doing. It doesn't seem like there was a compelling reason why it
was added either (bug #454908), so let's just get rid of it.
At the same time, fix the dependency on sys-libs/libcap by moving it to
RDEPEND, as dependencies in DEPEND/BDEPEND are not guaranteed to exist
during pkg_postinst() when this eclass is intended to run.
Signed-off-by: Matt Turner
---
eclass/fcaps.eclass | 95 +
1 file changed, 27 insertions(+), 68 deletions(-)
diff --git a/eclass/fcaps.eclass b/eclass/fcaps.eclass
index 0bb23f8cca7..43a76e253df 100644
--- a/eclass/fcaps.eclass
+++ b/eclass/fcaps.eclass
@@ -33,11 +33,8 @@ _FCAPS_ECLASS=1
IUSE="+filecaps"
-# We can't use libcap-ng atm due to #471414.
-case "${EAPI:-0}" in
- [0-6]) DEPEND="filecaps? ( sys-libs/libcap )" ;;
- *) BDEPEND="filecaps? ( sys-libs/libcap )" ;;
-esac
+# Since it is needed in pkg_postinst() it must be in RDEPEND
+RDEPEND="filecaps? ( sys-libs/libcap )"
# @ECLASS-VARIABLE: FILECAPS
# @DEFAULT_UNSET
@@ -134,69 +131,31 @@ fcaps() {
# by people.
chmod ${caps_mode} "${file}" || die
- # Set/verify funcs for sys-libs/libcap.
- _libcap(){ setcap "${caps}" "${file}" ; }
- _libcap_verify() { setcap -v "${caps}" "${file}"
>/dev/null ; }
-
- # Set/verify funcs for sys-libs/libcap-ng.
- # Note: filecap only supports =ep mode.
- # It also expects a different form:
- # setcap cap_foo,cap_bar
- # filecap foo bar
- _libcap_ng() {
- local caps=",${caps%=ep}"
- filecap "${file}" "${caps//,cap_}"
- }
- _libcap_ng_verify() {
- # libcap-ng has a crappy interface
- local rcaps icaps caps=",${caps%=ep}"
- rcaps=$(filecap "${file}" | \
- sed -nr \
- -e "s:^.{${#file}} +::" \
- -e 's:, +:\n:g' \
- -e 2p | \
- LC_ALL=C sort)
- [[ ${PIPESTATUS[0]} -eq 0 ]] || return 1
- icaps=$(echo "${caps//,cap_}" | LC_ALL=C sort)
- [[ ${rcaps} == ${icaps} ]]
- }
-
- local out cmd notfound=0
- for cmd in _libcap _libcap_ng ; do
- if ! out=$(LC_ALL=C ${cmd} 2>&1) ; then
- case ${out} in
- *"command not found"*)
- : $(( ++notfound ))
- continue
- ;;
- # ENOTSUP and EOPNOTSUPP might be the
same value which means
- # strerror() on them is unstable -- we
can get both. #559608
- *"Not supported"*|\
- *"Operation not supported"*)
- local fstype=$(stat -f -c %T
"${file}")
- ewarn "Could not set caps on
'${file}' due to missing filesystem support:"
- ewarn "* enable XATTR support
for '${fstype}' in your kernel (if configurable)"
- ewarn "* mount the fs with the
user_xattr option (if not the default)"
- ewarn "* enable the relevant
FS_SECURITY option (if configurable)"
- break
- ;;
- *)
- eerror "Setting caps '${caps}'
on file '${file}' failed:"
- eerror &q
Re: [gentoo-dev] [RFC] CC-ARCHES keyword on Bugzilla
On Mon, Apr 13, 2020 at 10:18 AM Michał Górny wrote: > > Hi, > > One of the goals behind NATTkA was to make keywording/stabilization > easier. Right now it's mostly possible to file the most common requests > without having to copy keywords everywhere. Still, there's a need to CC > arches which isn't exactly the most convenient part. > > I was thinking how to make NATTkA help with that. After considering > a few options, I'd like to push forward the following proposition: let's > add a 'CC-ARCHES' keyword to Bugzilla. If a bug is marked with that > keyword and passes sanity check, NATTkA will automatically CC all > relevant arch teams (based on keyword list). > > What do you think? I like it.
[gentoo-dev] Re: [PATCH 2/3] media-libs/mesa: do not force use of specific ICD loader
Looks good to me. Thanks!
[gentoo-dev] [PATCH 2/3] gnome2-utils.eclass: Fix missing "/" with EAPI >= 7.
From: Arfrever Frehtes Taifersar Arahesis
Bug: https://bugs.gentoo.org/694012
Signed-off-by: Arfrever Frehtes Taifersar Arahesis
---
eclass/gnome2-utils.eclass | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/eclass/gnome2-utils.eclass b/eclass/gnome2-utils.eclass
index e808549272d..231d4ac7477 100644
--- a/eclass/gnome2-utils.eclass
+++ b/eclass/gnome2-utils.eclass
@@ -136,15 +136,15 @@ gnome2_gconf_install() {
# We are ready to install the GCONF Scheme now
unset GCONF_DISABLE_MAKEFILE_SCHEMA_INSTALL
- export GCONF_CONFIG_SOURCE="$("${updater}" --get-default-source | sed
"s;:/;:${ROOT};")"
+ export GCONF_CONFIG_SOURCE="$("${updater}" --get-default-source | sed
"s;:/;:${ROOT%/}/;")"
einfo "Installing GNOME 2 GConf schemas"
local F
for F in ${GNOME2_ECLASS_SCHEMAS}; do
- if [[ -e "${EROOT}${F}" ]]; then
+ if [[ -e "${EROOT%/}/${F}" ]]; then
debug-print "Installing schema: ${F}"
- "${updater}" --makefile-install-rule "${EROOT}${F}"
1>/dev/null
+ "${updater}" --makefile-install-rule "${EROOT%/}/${F}"
1>/dev/null
fi
done
@@ -176,15 +176,15 @@ gnome2_gconf_uninstall() {
fi
unset GCONF_DISABLE_MAKEFILE_SCHEMA_INSTALL
- export GCONF_CONFIG_SOURCE="$("${updater}" --get-default-source | sed
"s;:/;:${ROOT};")"
+ export GCONF_CONFIG_SOURCE="$("${updater}" --get-default-source | sed
"s;:/;:${ROOT%/}/;")"
einfo "Uninstalling GNOME 2 GConf schemas"
local F
for F in ${GNOME2_ECLASS_SCHEMAS}; do
- if [[ -e "${EROOT}${F}" ]]; then
+ if [[ -e "${EROOT%/}/${F}" ]]; then
debug-print "Uninstalling gconf schema: ${F}"
- "${updater}" --makefile-uninstall-rule "${EROOT}${F}"
1>/dev/null
+ "${updater}" --makefile-uninstall-rule
"${EROOT%/}/${F}" 1>/dev/null
fi
done
@@ -354,7 +354,7 @@ gnome2_gdk_pixbuf_update() {
local tmp_file=$(emktemp)
${updater} 1> "${tmp_file}" &&
chmod 0644 "${tmp_file}" &&
- cp -f "${tmp_file}"
"${EROOT}usr/$(get_libdir)/gdk-pixbuf-2.0/2.10.0/loaders.cache" &&
+ cp -f "${tmp_file}"
"${EROOT%/}/usr/$(get_libdir)/gdk-pixbuf-2.0/2.10.0/loaders.cache" &&
rm "${tmp_file}" # don't replace this with mv, required for SELinux
support
eend $?
}
@@ -368,7 +368,7 @@ gnome2_query_immodules_gtk2() {
[[ ! -x ${updater} ]] &&
updater=${EPREFIX}/usr/bin/gtk-query-immodules-2.0
ebegin "Updating gtk2 input method module cache"
-
GTK_IM_MODULE_FILE="${EROOT}usr/$(get_libdir)/gtk-2.0/2.10.0/immodules.cache" \
+
GTK_IM_MODULE_FILE="${EROOT%/}/usr/$(get_libdir)/gtk-2.0/2.10.0/immodules.cache"
\
"${updater}" --update-cache
eend $?
}
@@ -382,7 +382,7 @@ gnome2_query_immodules_gtk3() {
[[ ! -x ${updater} ]] &&
updater=${EPREFIX}/usr/bin/gtk-query-immodules-3.0
ebegin "Updating gtk3 input method module cache"
-
GTK_IM_MODULE_FILE="${EROOT}usr/$(get_libdir)/gtk-3.0/3.0.0/immodules.cache" \
+
GTK_IM_MODULE_FILE="${EROOT%/}/usr/$(get_libdir)/gtk-3.0/3.0.0/immodules.cache"
\
"${updater}" --update-cache
eend $?
}
--
2.24.1
[gentoo-dev] [PATCH 3/3] gnome2-utils.eclass: Inherit eutils.eclass for emktemp().
From: Arfrever Frehtes Taifersar Arahesis
Bug: https://bugs.gentoo.org/694012
Signed-off-by: Arfrever Frehtes Taifersar Arahesis
---
eclass/gnome2-utils.eclass | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/eclass/gnome2-utils.eclass b/eclass/gnome2-utils.eclass
index 231d4ac7477..83478931c2a 100644
--- a/eclass/gnome2-utils.eclass
+++ b/eclass/gnome2-utils.eclass
@@ -15,8 +15,9 @@
# * scrollkeeper (old Gnome help system) management
[[ ${EAPI:-0} == [012345] ]] && inherit multilib
-[[ ${EAPI:-0} == [0123456] ]] && inherit eutils
-inherit xdg-utils
+# eutils.eclass: emktemp
+# xdg-utils.eclass: xdg_environment_reset, xdg_icon_cache_update
+inherit eutils xdg-utils
case "${EAPI:-0}" in
0|1|2|3|4|5|6|7) ;;
--
2.24.1
[gentoo-dev] [PATCH 1/3] gnome2-utils.eclass: Fix double "/" with EAPI < 7.
From: Arfrever Frehtes Taifersar Arahesis
Bug: https://bugs.gentoo.org/694012
Signed-off-by: Arfrever Frehtes Taifersar Arahesis
---
eclass/gnome2-utils.eclass | 20 ++--
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/eclass/gnome2-utils.eclass b/eclass/gnome2-utils.eclass
index 06683a7467f..e808549272d 100644
--- a/eclass/gnome2-utils.eclass
+++ b/eclass/gnome2-utils.eclass
@@ -1,4 +1,4 @@
-# Copyright 1999-2019 Gentoo Authors
+# Copyright 1999-2020 Gentoo Authors
# Distributed under the terms of the GNU General Public License v2
# @ECLASS: gnome2-utils.eclass
@@ -122,7 +122,7 @@ gnome2_gconf_savelist() {
# This function should be called from pkg_postinst.
gnome2_gconf_install() {
has ${EAPI:-0} 0 1 2 && ! use prefix && EROOT="${ROOT}"
- local updater="${EROOT}${GCONFTOOL_BIN}"
+ local updater="${EROOT%/}${GCONFTOOL_BIN}"
if [[ ! -x "${updater}" ]]; then
debug-print "${updater} is not executable"
@@ -163,7 +163,7 @@ gnome2_gconf_install() {
# database.
gnome2_gconf_uninstall() {
has ${EAPI:-0} 0 1 2 && ! use prefix && EROOT="${ROOT}"
- local updater="${EROOT}${GCONFTOOL_BIN}"
+ local updater="${EROOT%/}${GCONFTOOL_BIN}"
if [[ ! -x "${updater}" ]]; then
debug-print "${updater} is not executable"
@@ -266,7 +266,7 @@ gnome2_scrollkeeper_savelist() {
# This function should be called from pkg_postinst and pkg_postrm.
gnome2_scrollkeeper_update() {
has ${EAPI:-0} 0 1 2 && ! use prefix && EROOT="${ROOT}"
- local updater="${EROOT}${SCROLLKEEPER_UPDATE_BIN}"
+ local updater="${EROOT%/}${SCROLLKEEPER_UPDATE_BIN}"
if [[ ! -x "${updater}" ]] ; then
debug-print "${updater} is not executable"
@@ -279,7 +279,7 @@ gnome2_scrollkeeper_update() {
fi
ebegin "Updating scrollkeeper database ..."
- "${updater}" -q -p "${EROOT}${SCROLLKEEPER_DIR}"
+ "${updater}" -q -p "${EROOT%/}${SCROLLKEEPER_DIR}"
eend $?
}
@@ -303,7 +303,7 @@ gnome2_schemas_savelist() {
# This function should be called from pkg_postinst and pkg_postrm.
gnome2_schemas_update() {
has ${EAPI:-0} 0 1 2 && ! use prefix && EROOT="${ROOT}"
- local updater="${EROOT}${GLIB_COMPILE_SCHEMAS}"
+ local updater="${EROOT%/}${GLIB_COMPILE_SCHEMAS}"
if [[ ! -x ${updater} ]]; then
debug-print "${updater} is not executable"
@@ -334,10 +334,10 @@ gnome2_gdk_pixbuf_savelist() {
# This function should be called from pkg_postinst and pkg_postrm.
gnome2_gdk_pixbuf_update() {
has ${EAPI:-0} 0 1 2 && ! use prefix && EROOT="${ROOT}"
- local updater="${EROOT}/usr/bin/${CHOST}-gdk-pixbuf-query-loaders"
+ local updater="${EROOT%/}/usr/bin/${CHOST}-gdk-pixbuf-query-loaders"
if [[ ! -x ${updater} ]]; then
- updater="${EROOT}/usr/bin/gdk-pixbuf-query-loaders"
+ updater="${EROOT%/}/usr/bin/gdk-pixbuf-query-loaders"
fi
if [[ ! -x ${updater} ]]; then
@@ -394,10 +394,10 @@ gnome2_query_immodules_gtk3() {
# This function should be called from pkg_postinst and pkg_postrm.
gnome2_giomodule_cache_update() {
has ${EAPI:-0} 0 1 2 && ! use prefix && EROOT="${ROOT}"
- local updater="${EROOT}/usr/bin/${CHOST}-gio-querymodules"
+ local updater="${EROOT%/}/usr/bin/${CHOST}-gio-querymodules"
if [[ ! -x ${updater} ]]; then
- updater="${EROOT}/usr/bin/gio-querymodules"
+ updater="${EROOT%/}/usr/bin/gio-querymodules"
fi
if [[ ! -x ${updater} ]]; then
--
2.24.1
[gentoo-dev] [RFC] News item: Stable ia64 keywords removed
Title: Stable ia64 keywords removed Author: Matt Turner Posted: 2020-03-30 Revision: 1 News-Item-Format: 2.0 Display-If-Keyword: ia64 The Gentoo/IA64 team no longer thinks that the time invested in package stabilization is warranted for the small number of users on IA64. As a result, we will drop all "ia64" keywords to "~ia64" on 2020-04-03 and will add "~ia64" to ACCEPT_KEYWORDS in the profile. Users need not make any changes to their systems, and the Gentoo/IA64 team has no plans to remove support for the architecture. signature.asc Description: PGP signature
Re: [gentoo-dev] [PATCH] flag-o-matic.eclass: add some missing MIPS CPU errata options to ALLOWED_FLAGS
On Sat, Mar 28, 2020 at 12:17 PM Joshua Kinard wrote: > > Noticed during a glibc build for MIPS-III ISA that the -mfix-r4000 > and -mfix-r4400 gcc flags got stripped off. These are needed to work > around known CPU errata in R4000 and R4400 CPUs. In addition, also > add the -mfix-rm7000 option (and it's -mno form) to fix errata in the > PMC RM7000 CPU, and the -mr10k-cache-barrier to control the generation > of cache barriers to work around the side-effects of R1's > speculative execution capabilities. Hah, I guess that tells us how many users we have :) Reviewed-by: Matt Turner
[gentoo-dev] Last rites: mail-client/mail-notification
# Matt Turner (2020-03-28) # Last release 2008. Last upstream commit 2013. Blocks removal of # gnome-base/libgnome-keyring # Bug #713030 mail-client/mail-notification signature.asc Description: PGP signature
[gentoo-dev] Last rites: games-puzzle/skoosh
# Matt Turner (2020-03-28) # Homepage gone. Dead project. Blocks removal of gnome-base/libgnome-keyring # Bug #713028 games-puzzle/skoosh signature.asc Description: PGP signature
[gentoo-dev] Last rites: dev-dotnet/gnome-keyring-sharp
# Matt Turner (2020-03-28) # No consumers. Dead project. Blocks removal of gnome-base/libgnome-keyring # Bug #713020 dev-dotnet/gnome-keyring-sharp signature.asc Description: PGP signature
Re: [gentoo-dev] [PATCH] Split python implementations definition to separate eclass
On Thu, Mar 26, 2020 at 2:03 PM Patrick McLean wrote: > > This patch splits the definition of _PYTHON_ALL_IMPLS and > _python_impl_supported to a separate eclass, this allows overlays > to easily support a different set of python implementations than > ::gentoo without having to fork the entire suite of eclasses. (I think the issue is that you have some packages that still need Python 3.4. Correct me if I'm wrong) How many packages do you need to work with Python 3.4? Presumably just a couple and then a pile of dependencies in ::gentoo?
[gentoo-dev] Last rites: media-libs/libav
Acked by lu_zero on IRC. # Matt Turner (2020-03-25) # No releases in two years. No commits in upstream git in last six months. # Many open security bugs. Masked for removal in 30 days. media-video/libav media-libs/libpostproc signature.asc Description: PGP signature
Re: [gentoo-dev] rfc: noarch keyword
On Fri, Mar 20, 2020 at 9:55 PM Kent Fredric wrote: > If X is "noarch" and its dependency Y is "amd64", then a user on "sparc" > will be able to install "X", but not its dependency "Y". Thank you. This is a good explanation of the problem. How do other distributions handle this? Arch, Fedora, and Debian have "noarch" packages. Surely they've found a reasonable way to make this work.
[gentoo-dev] [PATCH] profiles: Enable USE=user-session on systemd profiles
Signed-off-by: Matt Turner
---
.../linux/amd64/17.0/desktop/plasma/systemd/package.use| 7 ---
.../linux/amd64/17.1/desktop/plasma/systemd/package.use| 7 ---
.../linux/arm/17.0/desktop/plasma/systemd/package.use | 7 ---
.../linux/arm64/17.0/desktop/plasma/systemd/package.use| 7 ---
.../linux/x86/17.0/desktop/plasma/systemd/package.use | 7 ---
profiles/targets/systemd/make.defaults | 4 ++--
6 files changed, 2 insertions(+), 37 deletions(-)
delete mode 100644
profiles/default/linux/amd64/17.0/desktop/plasma/systemd/package.use
delete mode 100644
profiles/default/linux/amd64/17.1/desktop/plasma/systemd/package.use
delete mode 100644
profiles/default/linux/arm/17.0/desktop/plasma/systemd/package.use
delete mode 100644
profiles/default/linux/arm64/17.0/desktop/plasma/systemd/package.use
delete mode 100644
profiles/default/linux/x86/17.0/desktop/plasma/systemd/package.use
diff --git
a/profiles/default/linux/amd64/17.0/desktop/plasma/systemd/package.use
b/profiles/default/linux/amd64/17.0/desktop/plasma/systemd/package.use
deleted file mode 100644
index bdf6c817864..000
--- a/profiles/default/linux/amd64/17.0/desktop/plasma/systemd/package.use
+++ /dev/null
@@ -1,7 +0,0 @@
-# Copyright 2019-2019 Gentoo Authors
-# Distributed under the terms of the GNU General Public License v2
-
-# Brian Evans (2019-02-27)
-# Avoid conflict between kde-plasma/plasma-workspace[systemd] requiring
sys-apps/dbus[user-session]
-# and net-wireless/bluez[systemd,-user-session] requiring
sys-apps/dbus[-user-session].
-net-wireless/bluez user-session
diff --git
a/profiles/default/linux/amd64/17.1/desktop/plasma/systemd/package.use
b/profiles/default/linux/amd64/17.1/desktop/plasma/systemd/package.use
deleted file mode 100644
index bdf6c817864..000
--- a/profiles/default/linux/amd64/17.1/desktop/plasma/systemd/package.use
+++ /dev/null
@@ -1,7 +0,0 @@
-# Copyright 2019-2019 Gentoo Authors
-# Distributed under the terms of the GNU General Public License v2
-
-# Brian Evans (2019-02-27)
-# Avoid conflict between kde-plasma/plasma-workspace[systemd] requiring
sys-apps/dbus[user-session]
-# and net-wireless/bluez[systemd,-user-session] requiring
sys-apps/dbus[-user-session].
-net-wireless/bluez user-session
diff --git a/profiles/default/linux/arm/17.0/desktop/plasma/systemd/package.use
b/profiles/default/linux/arm/17.0/desktop/plasma/systemd/package.use
deleted file mode 100644
index bdf6c817864..000
--- a/profiles/default/linux/arm/17.0/desktop/plasma/systemd/package.use
+++ /dev/null
@@ -1,7 +0,0 @@
-# Copyright 2019-2019 Gentoo Authors
-# Distributed under the terms of the GNU General Public License v2
-
-# Brian Evans (2019-02-27)
-# Avoid conflict between kde-plasma/plasma-workspace[systemd] requiring
sys-apps/dbus[user-session]
-# and net-wireless/bluez[systemd,-user-session] requiring
sys-apps/dbus[-user-session].
-net-wireless/bluez user-session
diff --git
a/profiles/default/linux/arm64/17.0/desktop/plasma/systemd/package.use
b/profiles/default/linux/arm64/17.0/desktop/plasma/systemd/package.use
deleted file mode 100644
index bdf6c817864..000
--- a/profiles/default/linux/arm64/17.0/desktop/plasma/systemd/package.use
+++ /dev/null
@@ -1,7 +0,0 @@
-# Copyright 2019-2019 Gentoo Authors
-# Distributed under the terms of the GNU General Public License v2
-
-# Brian Evans (2019-02-27)
-# Avoid conflict between kde-plasma/plasma-workspace[systemd] requiring
sys-apps/dbus[user-session]
-# and net-wireless/bluez[systemd,-user-session] requiring
sys-apps/dbus[-user-session].
-net-wireless/bluez user-session
diff --git a/profiles/default/linux/x86/17.0/desktop/plasma/systemd/package.use
b/profiles/default/linux/x86/17.0/desktop/plasma/systemd/package.use
deleted file mode 100644
index bdf6c817864..000
--- a/profiles/default/linux/x86/17.0/desktop/plasma/systemd/package.use
+++ /dev/null
@@ -1,7 +0,0 @@
-# Copyright 2019-2019 Gentoo Authors
-# Distributed under the terms of the GNU General Public License v2
-
-# Brian Evans (2019-02-27)
-# Avoid conflict between kde-plasma/plasma-workspace[systemd] requiring
sys-apps/dbus[user-session]
-# and net-wireless/bluez[systemd,-user-session] requiring
sys-apps/dbus[-user-session].
-net-wireless/bluez user-session
diff --git a/profiles/targets/systemd/make.defaults
b/profiles/targets/systemd/make.defaults
index 8bc064858b2..7b7f59898a3 100644
--- a/profiles/targets/systemd/make.defaults
+++ b/profiles/targets/systemd/make.defaults
@@ -1,6 +1,6 @@
-# Copyright 1999-2014 Gentoo Foundation
+# Copyright 1999-2020 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
-USE="systemd udev"
+USE="systemd udev user-session"
BOOTSTRAP_USE="${BOOTSTRAP_USE} systemd udev"
--
2.24.1
Re: [gentoo-dev] News item: Removing ABI_X86_32 support from virtual/opencl
On Wed, Mar 4, 2020 at 8:49 AM Marek Szuba wrote: > > This will be shown as relevant to everyone who has installed > virtual/opencl, i.e. also to people on amd64 who have NOT enabled > abi_x86_32 for this package - but there is no way to filter news items > by use flags, is there? Anyway, comments are welcome! Yes, please!
Re: [gentoo-dev] Last rites: dev-python/*, python-maintained, py3.6-only, no-revdep
On Sat, Mar 7, 2020 at 12:17 PM Jonas Stein wrote: > > On 07/03/2020 19.27, Ulrich Mueller wrote: > >> On Sat, 07 Mar 2020, Michał Górny wrote: > > > >>> Just the ebuild being outdated doesn't sound like a sufficient reason > >>> for removal of a package, at least not for those packages that install > >>> applications for the end user. > > > >> The list is almost exclusively about dev-python/, i.e. packages that > >> do not install end-user applications but Python modules. > > > > Like www-apps/nikola, for example? > > > > Nikola is actively maintained and was recently updated. > It works fine and has many users. > > Did you look into that package before hard masking? > I see no problems with this package. > https://github.com/getnikola/nikola/blob/master/setup.py > > Please undo the masking of fully working packages. Christ guys. Just add python 3.7 support and unmask it.
Re: [gentoo-dev] Last rites: dev-python/*, python-maintained, py3.6-only, no-revdep
On Sat, Mar 7, 2020 at 11:21 AM Ulrich Mueller wrote: > > >>>>> On Sat, 07 Mar 2020, Matt Turner wrote: > > >> > The list is almost exclusively about dev-python/, i.e. packages that > >> > do not install end-user applications but Python modules. > >> > >> Like www-apps/nikola, for example? > > > This is not a productive way to communicate. > > The point is that packages that are perfectly working, actively > maintained upstream (and the ebuild version bumped in the last month) > are being last-rited all of a sudden. > > What message does that send to users about the suitability of Gentoo > for usage in a production environment? I would hope that it would communicate that the Gentoo developers doing the maintenance have too many packages to maintain and could use some help from those interested! That is, instead of getting a bunch of complaints.
Re: [gentoo-dev] Last rites: dev-python/*, python-maintained, py3.6-only, no-revdep
On Sat, Mar 7, 2020 at 10:27 AM Ulrich Mueller wrote: > > > On Sat, 07 Mar 2020, Michał Górny wrote: > > >> Just the ebuild being outdated doesn't sound like a sufficient reason > >> for removal of a package, at least not for those packages that install > >> applications for the end user. > > > The list is almost exclusively about dev-python/, i.e. packages that > > do not install end-user applications but Python modules. > > Like www-apps/nikola, for example? This is not a productive way to communicate.
[gentoo-dev] [PATCH] meson.eclass: Set needs_exe_wrapper in cross file
needs_exe_wrapper tells meson whether the build machine is able to
directly execute the binaries it produces or whether it needs an exe
wrapper (like QEMU). For non-native ABI builds like building 32-bit
libraries on an x86-64 system, we want this set to false to communicate
to meson that the build machine can run the binaries directly.
This allows dev-libs/wayland to execute the wayland-scanner binary it
builds rather than relying on the system's.
Signed-off-by: Matt Turner
---
eclass/meson.eclass | 4
1 file changed, 4 insertions(+)
diff --git a/eclass/meson.eclass b/eclass/meson.eclass
index 0588590b31e..16e17dd4a38 100644
--- a/eclass/meson.eclass
+++ b/eclass/meson.eclass
@@ -149,6 +149,9 @@ _meson_create_cross_file() {
# This may require adjustment based on CFLAGS
local cpu=${CHOST%%-*}
+ local needs_exe_wrapper=false
+ tc-is-cross-compiler && needs_exe_wrapper=true
+
cat > "${T}/meson.${CHOST}.${ABI}" <<-EOF
[binaries]
ar = $(_meson_env_array "$(tc-getAR)")
@@ -173,6 +176,7 @@ _meson_create_cross_file() {
objc_link_args = $(_meson_env_array "${OBJCFLAGS} ${LDFLAGS}")
objcpp_args = $(_meson_env_array "${OBJCXXFLAGS} ${CPPFLAGS}")
objcpp_link_args = $(_meson_env_array "${OBJCXXFLAGS} ${LDFLAGS}")
+ needs_exe_wrapper = ${needs_exe_wrapper}
[host_machine]
system = '${system}'
--
2.24.1
Re: [gentoo-dev] Last rites: dev-python/sphinxcontrib-issuetracker
On Fri, Feb 21, 2020 at 9:36 PM Michał Górny wrote: > On Fri, 2020-02-21 at 16:45 -0800, Matt Turner wrote: > > On Fri, Feb 21, 2020 at 12:34 PM Michał Górny wrote: > > > # Michał Górny (2020-02-21) > > > # Last bumped in 2013. Homepage gone. No reverse dependencies left. > > > # Removal in 30 days. Bug #527188. > > > dev-python/sphinxcontrib-issuetracker > > > > I committed a pull request adding pydocstyle-5.0.2 last week and it > > depends on this. > > > > I'm sorry about that. It seems that genrdeps on qa-reports.g.o is > broken. I have reverted this. No problem. It happens. I'll investigate a little further and check how exactly it's needed.
Re: [gentoo-dev] Last rites: dev-python/sphinxcontrib-issuetracker
On Fri, Feb 21, 2020 at 12:34 PM Michał Górny wrote: > > # Michał Górny (2020-02-21) > # Last bumped in 2013. Homepage gone. No reverse dependencies left. > # Removal in 30 days. Bug #527188. > dev-python/sphinxcontrib-issuetracker I committed a pull request adding pydocstyle-5.0.2 last week and it depends on this.
Re: [gentoo-dev] [PATCH 3/3] app-admin/kube-bench: convert to go-module go.sum
On Mon, Feb 17, 2020 at 11:47 PM desultory wrote: > You've got a particular knack for this kind of argumentative nonsense.
Re: [gentoo-dev] [PATCH 3/3] app-admin/kube-bench: convert to go-module go.sum
On Fri, Feb 14, 2020 at 12:31 AM Sam Jorna (wraeth) wrote: > In this instance, at least two people (myself included) have drawn an > impression that led them to voice their concern in some way (I'm unsure if > mpagano was voicing concern or just agreeing with the general concept). Maybe > we're the only ones. Maybe not. What do you think the threshold should be? If one person objects, should ComRel cease and desist? Two? Should we have a Gentoo-wide vote? I don't have the highest opinion of ComRel and I'm a member, but maybe you could let us do our jobs?
Re: [gentoo-dev] [PATCH 3/3] app-admin/kube-bench: convert to go-module go.sum
On Thu, Feb 13, 2020 at 4:12 AM Mike Pagano wrote: > > On Thu, Feb 13, 2020 at 06:46:43PM +1100, Sam Jorna (wraeth) wrote: > > On Thursday, 13 February 2020 5:40:46 AM AEDT Matt Turner wrote: > > > On Wed, Feb 12, 2020 at 9:59 AM William Hubbs wrote: > > > > On Wed, Feb 12, 2020 at 06:54:19PM +1100, Sam Jorna (wraeth) wrote: > > > > > On Monday, 10 February 2020 7:55:01 AM AEDT Michał Górny wrote: > > > > > > On Sun, 2020-02-09 at 20:38 +, Michael 'veremitz' Everitt wrote: > > > > > > > Hrm, pardon my ignorance, but do 'we' really need to review 232 > > > > > > > lines of > > > > > > > Manifest?! > > > > > > > > > > > > Pardon mine but do 'we' really need to read your useless comments > > > > > > everywhere, all the time and just get irritated for no benefit to > > > > > > Gentoo? > > > > > > > > > > Perhaps I'm the one being ignorant here, but why are we lambasting > > > > > someone for seeking clarification about an unusual inclusion on a > > > > > review thread?> > > > > I wasn't going to say anything, but I can't let this go by without > > > > commenting. > > > > > > > > Sam is correct. Maybe the tone is a bit off, (and that is debatable), > > > > but this definitely can be seen as a legit question, regardless of other > > > > things Michael has posted. > > > > > > Unfortunately it's not about a single issue or email. It's a > > > consistent pattern that multiple people have asked him to rein in over > > > a long period. :( > > > > Without going into specifics, veremit and I have certainly had our > > 'differences > > of opinion' in the past; but I don't believe this is one of those occasions. > > > > Calling out bad actors (not saying veremit is one, I just mean in the > > general > > sense) is an unfortunate but important task, but call them out on bad > > behaviour, not for what appears to be an impassioned but otherwise > > unremarkable query. > > > > I agree with this 100 percent. Not judging solely on the content of the > specific email in the thread does not allow people to grow and improve. Are we > all to be judged on our past behavior forever with no chance to overcome past > transgressions ? That's not what's going on.
Re: [gentoo-dev] [PATCH 3/3] app-admin/kube-bench: convert to go-module go.sum
On Wed, Feb 12, 2020 at 9:59 AM William Hubbs wrote: > > On Wed, Feb 12, 2020 at 06:54:19PM +1100, Sam Jorna (wraeth) wrote: > > On Monday, 10 February 2020 7:55:01 AM AEDT Michał Górny wrote: > > > On Sun, 2020-02-09 at 20:38 +, Michael 'veremitz' Everitt wrote: > > > > Hrm, pardon my ignorance, but do 'we' really need to review 232 lines of > > > > Manifest?! > > > > > > Pardon mine but do 'we' really need to read your useless comments > > > everywhere, all the time and just get irritated for no benefit to > > > Gentoo? > > > > Perhaps I'm the one being ignorant here, but why are we lambasting someone > > for > > seeking clarification about an unusual inclusion on a review thread? > > I wasn't going to say anything, but I can't let this go by without > commenting. > > Sam is correct. Maybe the tone is a bit off, (and that is debatable), > but this definitely can be seen as a legit question, regardless of other > things > Michael has posted. Unfortunately it's not about a single issue or email. It's a consistent pattern that multiple people have asked him to rein in over a long period. :(
Re: [gentoo-dev] [PATCH 3/3] app-admin/kube-bench: convert to go-module go.sum
On Sun, Feb 9, 2020 at 1:16 PM Michael 'veremitz' Everitt wrote: > > On 09/02/20 20:59, Michael 'veremitz' Everitt wrote: > > On 09/02/20 20:57, Michael 'veremitz' Everitt wrote: > >> On 09/02/20 20:55, Michał Górny wrote: > >>> On Sun, 2020-02-09 at 20:38 +, Michael 'veremitz' Everitt wrote: > Hrm, pardon my ignorance, but do 'we' really need to review 232 lines of > Manifest?! > >>> Pardon mine but do 'we' really need to read your useless comments > >>> everywhere, all the time and just get irritated for no benefit to > >>> Gentoo? > >>> > >> There's a really simple method to deal with that .. would you like me to > >> explain, or would that be 'useless' too? > >> > > For the benefit of other readers, it's clear Michal is incapable of > > implementing the measures I am thinking of .. or simply isn't aware of what > > they might be? > > which is quite unusual for a developer of his supposed capability ... > > > For the avoidance of doubt, whilst my ban from this list is enacted, here > is the list of "Unacceptable behaviour" from the Gentoo Code of Conduct[1]. > > "Deciding to suspend or ban someone isn't a decision to be taken lightly, > but sometimes it has to happen. Below is a list of things that could result > in disciplinary action. * Flaming and trolling. What is trolling? You are > deemed to be trolling if you make comments intended to provoke an angry > response from others. What is flaming? Flaming is the act of sending or > posting messages that are deliberately hostile and insulting. > * Posting/participating only to incite drama or negativity rather than to > tactfully share information. > * Being judgmental, mean-spirited or insulting. It is possible to > respectfully challenge someone in a way that empowers without being > judgemental. > * Constantly purveying misinformation despite repeated warnings." > > It is left as an exercise for the reader, who is transgressing here... > "Technically I'm not violating the rules" is the weakest argument. Can you just please save everyone the headache of litigating this and act a little more professional and a little less silly on the mailing list? (And on IRC if I'm asking) Here's a good approximation to determine whether your mail is worth sending: before you press send, ask yourself if the person you're replying to gains anything by reading your reply. If the answer is on the range "unlikely" to "no", then just don't send the reply.
Re: [gentoo-dev] Last rites: sys-firmware/iwl6050-ucode
On Fri, Feb 7, 2020 at 12:44 PM Alexander Tsoy wrote: > > 7 февраля 2020 г. 22:50:13 GMT+03:00, Matt Turner пишет: > >On Fri, Feb 7, 2020 at 11:39 AM Ulrich Mueller wrote: > >> > >> >>>>> On Fri, 07 Feb 2020, Matt Turner wrote: > >> > >> > On Fri, Feb 7, 2020 at 9:10 AM Mike Pagano > >wrote: > >> >> > >> >> # Mike Pagano (2020-02-07) > >> >> # The standalone ebuild for this driver is made > >> >> # unnecessary as it is included in the package: > >> >> # sys-kernel/linux-firmware > >> >> sys-firmware/iwl6050-ucode > >> > >> > How about all the others as well? > >> > >> > sys-firmware/iwl1000-ucode > >> > sys-firmware/iwl3160-7260-bt-ucode > >> > sys-firmware/iwl3160-ucode > >> > sys-firmware/iwl6005-ucode > >> > sys-firmware/iwl6030-ucode > >> > sys-firmware/iwl7260-ucode > >> > sys-firmware/iwl8000-ucode > >> > >> I had asked the same question back in November, but an argument > >against > >> it was that sys-kernel/linux-firmware is quite a monster. In the > >default > >> configuration, its installation footprint is 515 MiB. > > > >Oh yeah. The thread where the person arguing for keeping them didn't > >know about USE=savedconfig :) > > USE=savedconfig is very inconvinient, especially for a package that can > introduce new firmware files for the same hardware. Adding support for masks > would improve that a bit. Agreed. Mask/wildcard support would solve that problem well.
Re: [gentoo-dev] Last rites: sys-firmware/iwl6050-ucode
On Fri, Feb 7, 2020 at 12:03 PM Michael 'veremitz' Everitt wrote: > > On 07/02/20 19:50, Matt Turner wrote: > > On Fri, Feb 7, 2020 at 11:39 AM Ulrich Mueller wrote: > >>>>>>> On Fri, 07 Feb 2020, Matt Turner wrote: > >>> On Fri, Feb 7, 2020 at 9:10 AM Mike Pagano wrote: > >>>> # Mike Pagano (2020-02-07) > >>>> # The standalone ebuild for this driver is made > >>>> # unnecessary as it is included in the package: > >>>> # sys-kernel/linux-firmware > >>>> sys-firmware/iwl6050-ucode > >>> How about all the others as well? > >>> sys-firmware/iwl1000-ucode > >>> sys-firmware/iwl3160-7260-bt-ucode > >>> sys-firmware/iwl3160-ucode > >>> sys-firmware/iwl6005-ucode > >>> sys-firmware/iwl6030-ucode > >>> sys-firmware/iwl7260-ucode > >>> sys-firmware/iwl8000-ucode > >> I had asked the same question back in November, but an argument against > >> it was that sys-kernel/linux-firmware is quite a monster. In the default > >> configuration, its installation footprint is 515 MiB. > > Oh yeah. The thread where the person arguing for keeping them didn't > > know about USE=savedconfig :) > > > You still have to install the full 515MiB before you can apply savedconfig, > unless you already know the list of firmwares included, and create the file > in advance. For some systems (esp. storage constrained) that's not a very > good option ... Even that's not true. Just look at the git repo.
Re: [gentoo-dev] Last rites: sys-firmware/iwl6050-ucode
On Fri, Feb 7, 2020 at 11:39 AM Ulrich Mueller wrote: > > >>>>> On Fri, 07 Feb 2020, Matt Turner wrote: > > > On Fri, Feb 7, 2020 at 9:10 AM Mike Pagano wrote: > >> > >> # Mike Pagano (2020-02-07) > >> # The standalone ebuild for this driver is made > >> # unnecessary as it is included in the package: > >> # sys-kernel/linux-firmware > >> sys-firmware/iwl6050-ucode > > > How about all the others as well? > > > sys-firmware/iwl1000-ucode > > sys-firmware/iwl3160-7260-bt-ucode > > sys-firmware/iwl3160-ucode > > sys-firmware/iwl6005-ucode > > sys-firmware/iwl6030-ucode > > sys-firmware/iwl7260-ucode > > sys-firmware/iwl8000-ucode > > I had asked the same question back in November, but an argument against > it was that sys-kernel/linux-firmware is quite a monster. In the default > configuration, its installation footprint is 515 MiB. Oh yeah. The thread where the person arguing for keeping them didn't know about USE=savedconfig :)
Re: [gentoo-dev] Last rites: sys-firmware/iwl6050-ucode
On Fri, Feb 7, 2020 at 9:10 AM Mike Pagano wrote: > > # Mike Pagano (2020-02-07) > # The standalone ebuild for this driver is made > # unnecessary as it is included in the package: > # sys-kernel/linux-firmware > sys-firmware/iwl6050-ucode How about all the others as well? sys-firmware/iwl1000-ucode sys-firmware/iwl3160-7260-bt-ucode sys-firmware/iwl3160-ucode sys-firmware/iwl6005-ucode sys-firmware/iwl6030-ucode sys-firmware/iwl7260-ucode sys-firmware/iwl8000-ucode
[gentoo-dev] [RFC] News item: Stable alpha keywords removed
Title: Stable alpha keywords removed Author: Matt Turner Content-Type: text/plain Posted: 2020-01-22 Revision: 1 News-Item-Format: 1.0 Display-If-Keyword: alpha The Gentoo/Alpha team no longer thinks that the time invested in package stabilization is warranted for the small number of users on Alpha. As a result, we will drop all "alpha" keywords to "~alpha" on 2020-01-25 and will add "~alpha" to ACCEPT_KEYWORDS in the profile. Users need not make any changes to their systems, and the Gentoo/Alpha team has no plans to remove support for the architecture. signature.asc Description: PGP signature
Re: [gentoo-dev] Last rites: sci-astronomy/celestia
On Tue, Jan 21, 2020 at 3:57 PM David Seifert wrote: > > # David Seifert (2020-01-21) > # All released versions depend on EOL gtkglext, no revdeps. > # Bug #644334, #694834. Removal in 30 days. > sci-astronomy/celestia This is actually a really cool piece of software (give it a try!), and the bugs look solvable, so I might try to fix them and unmask.
[gentoo-dev] RFC: Dropping alpha keywords to unstable
Hello, It makes me a bit sad to say, having helped maintain Gentoo's DEC Alpha port for more than 10 years, that I think it is time to drop our stable keywords to ~alpha. Stable testing is a valuable service we provide to users. Time invested by developers during stabilization has the potential to pay dividends to users multiple times over. But the presumption in that statement is that the number of users meaningfully greater than the number of developers. I no longer believe this is the case for Alpha. As a result, I don't think it's a good use of my time to perform stable testing on alpha. I plan to keep the profiles "stable" (meaning no depgraph breakages) but to change to ACCEPT_KEYWORDS="~alpha". Thoughts? Matt signature.asc Description: PGP signature
Re: [gentoo-dev] RFC: Introducing VIDEO_CARDS=iris to virtual/opencl
On Mon, Dec 16, 2019 at 10:26 AM Marek Szuba wrote: > What do you think, guys? I don't love it. I don't like the mess that has become VIDEO_CARDS=... either. radeon vs radeonsi vs amdgpu. Different names for different bits of the stack, even for the same hardware. I would like to come up with something that avoids the confusion users often have. Does anyone have suggestions? Should we make a cpuid2cpuflags equivalent for VIDEO_CARDS? Should VIDEO_CARDS specify only the vendor with MESA_VIDEO_CARDS=... etc for individual packages? (Seems gross) Should VIDEO_CARDS be more fine grained with multiple names for the same thing sometimes? (e.g., offer VIDEO_CARDS=amdgpu for media-libs/mesa that enables the radeonsi driver; similarly offer VIDEO_CARDS=radeonsi for x11-libs/libdrm that enables libdrm_radeon). I think perhaps that in conjunction with a cpuid2cpuflags-equivalent is the most sensible.
Re: [gentoo-dev] stable-bot is down. Temporary? Forever? Can we have a contacts page for it?
stable-bot appears to be down again. I've been unsuccessful in reaching kensington on IRC. I think stable-bot has become an integral part of the workflow and as such (1) we should have the code available and (2) we should run it on some hardware that others are able to administer. Can we please?
Re: [gentoo-dev] [PATCH] package.deprecated: Create initial template
On Fri, Dec 6, 2019 at 5:51 AM Alexis Ballier wrote: > > On Fri, 6 Dec 2019 04:33:36 -0500 > Tim Harder wrote: > > > On 2019-12-06 Fri 04:03, Alexis Ballier wrote: > > > it's not just like repoman and cvs since repoman commit did push ;) > > > it will never be perfect but i really like repoman commit to refuse > > > to even commit if there's something obviously wrong > > > > I'm more of the opinion (and am working towards that practicality in > > terms of runtime speed) that a subset of QA checks should be run as a > > git hook which would cause push failures on certain classes of bad > > commits. > > > There should be both. Amending the 23rd commit message because one > mistyped a semicolon is kind of a PITA. It is? git rebase -i HEAD~23 Is that what you think is a pain in the ass, or do you not know about interactive rebase? :)
Re: [gentoo-dev] [PATCH] package.deprecated: Create initial template
On Thu, Dec 5, 2019 at 11:10 AM Michał Górny wrote: > > Signed-off-by: Michał Górny > --- > profiles/package.deprecated | 17 + > 1 file changed, 17 insertions(+) > create mode 100644 profiles/package.deprecated > > diff --git a/profiles/package.deprecated b/profiles/package.deprecated > new file mode 100644 > index ..b4803a4ce68f > --- /dev/null > +++ b/profiles/package.deprecated > @@ -0,0 +1,17 @@ > + > +# > +# This file specifies packages that are considered deprecated (but not > +# masked yet). It will trigger pkgcheck warnings whenever other > +# packages depend on them. > +# > +# When you add an entry to the top of this file, add your name, the date > +# in the UTC timezone, and an explanation of why something is getting > +# deprecated. > +# > +## Example: > +## > +## # Dev E. Loper (2019-07-01) > +## # This is no longer supported upstream, please switch to dev-foo/bar. > +## dev-foo/foo > + > +#--- END OF EXAMPLES --- > -- > 2.24.0 Yes, please!
[gentoo-dev] Last Rites: dev-go/logrus and dev-go/zglob
# Matt Turner (2019-12-01) # browserpass ebuild ported to go-modules, so these modules now have no reverse # dependencies. # Removal in 30 days. Bugs #683286, #683310, #687462, #700792 =www-plugins/browserpass-3.0.6 dev-go/zglob dev-go/logrus signature.asc Description: PGP signature
Re: [gentoo-dev] Addressing split usage of USE=gles[123]
On Thu, Nov 21, 2019 at 5:09 PM Matt Turner wrote:
>
> On Thu, Nov 21, 2019 at 4:54 PM Dennis Schridde wrote:
> >
> > On Donnerstag, 21. November 2019 09:11:46 CET Mart Raudsepp wrote:
> > > See also this related old thread:
> > > https://archives.gentoo.org/gentoo-dev/message/e04f6d321e424a237af62721d1d09
> > > 211
> >
> > I think tackling the triad of opengl/gles, egl/glx, X/wayland is also a good
> > idea. Generally, all these probably have to distinguish between "support
> > for
> > XYZ" and "use only XYZ", the latter hopefully being the exception, so that
> > the
> > former can take the shorter use-flag. That's what I don't like about the
> > proposal from 2018: Globally enabling USE=gles will have different effects
> > on
> > different packages. That's also what I like about the recent proposal: The
> > flags are more explicit.
>
> Totally agree. FWIW, we have bugs filed about this for USE=wayland [0]
> and USE=USE={egl,gles{,1,2,3}}.
>
> I would be happy to see someone take up this project. I'll be happy to help.
Is anyone planning to work on this?
> [0] https://bugs.gentoo.org/627714
> [1] https://bugs.gentoo.org/627758
Re: [gentoo-dev] Addressing split usage of USE=gles[123]
On Thu, Nov 21, 2019 at 4:54 PM Dennis Schridde wrote:
>
> On Donnerstag, 21. November 2019 09:11:46 CET Mart Raudsepp wrote:
> > See also this related old thread:
> > https://archives.gentoo.org/gentoo-dev/message/e04f6d321e424a237af62721d1d09
> > 211
>
> I think tackling the triad of opengl/gles, egl/glx, X/wayland is also a good
> idea. Generally, all these probably have to distinguish between "support for
> XYZ" and "use only XYZ", the latter hopefully being the exception, so that the
> former can take the shorter use-flag. That's what I don't like about the
> proposal from 2018: Globally enabling USE=gles will have different effects on
> different packages. That's also what I like about the recent proposal: The
> flags are more explicit.
Totally agree. FWIW, we have bugs filed about this for USE=wayland [0]
and USE=USE={egl,gles{,1,2,3}}.
I would be happy to see someone take up this project. I'll be happy to help.
[0] https://bugs.gentoo.org/627714
[1] https://bugs.gentoo.org/627758
Re: [gentoo-dev] Addressing split usage of USE=gles[123]
On Wed, Nov 20, 2019 at 10:32 PM Haelwenn (lanodan) Monnier wrote: > > Hello gentoo-dev, > > First proposition on this list so hopefully not missing some kind of > netiquette/policy. > > I noticed for some time that there seems to be two use cases for the > gles[123] family of USE flags in gentoo repo: > 1. enabling support of OpenGL ES, which seems interesting to have for > more runtime choices, probably better usage of the drivers and better > binary-compat support. > 2. switching from OpenGL (so the full API) to Open GL ES (reduced API), > which is an entirely different kind of action as that reduces it quite > significantly but might be useful for machines where the drivers do not > provide (good) OpenGL. > > To reflect this I think the "gles[123]" USE flags should be renamed, > first kind to "gles[123]support" and second kind to "gles[123]only". > Might also be the time to globalize them? I'm not sure but I think that > would help in signalling which USE flags are to be used in packages. > (and I'm probably not the only one which tends to only put global USE > flags in make.conf, this kind of USE flags being the reason) I think this is a good idea. I would suggest gles[123] and gles[123]-only to avoid some of the churn. Changing gles[123] to gles[123]-support would mean changing a ton of reverse dependencies of Mesa, and I think that's a bad idea. > ## Second kind, switch from OpenGL to OpenGL ES (20 packages) > dev-libs/weston:gles2 - Use GLESv2 cairo instead of full GL > dev-python/PyQt5:gles2 - Use GLES 2.0 or later instead of full OpenGL > dev-qt/qt3d:gles2 - Use GLES 2.0 or later instead of full OpenGL > dev-qt/qtdatavis3d:gles2 - Use GLES 2.0 or later instead of full OpenGL > dev-qt/qtdeclarative:gles2 - Use GLES 2.0 or later instead of full OpenGL > dev-qt/qtgui:gles2 - Use GLES 2.0 or later instead of full OpenGL > dev-qt/qtmultimedia:gles2 - Use GLES 2.0 or later instead of full OpenGL > dev-qt/qtopengl:gles2 - Use GLES 2.0 or later instead of full OpenGL > dev-qt/qtprintsupport:gles2 - Use GLES 2.0 or later instead of full OpenGL > dev-qt/qtwebkit:gles2 - Use GLES 2.0 or later instead of full OpenGL > dev-qt/qtwidgets:gles2 - Use GLES 2.0 or later instead of full OpenGL > games-emulation/mupen64plus-core:gles2 - Use GLES2 instead of OpenGL > games-emulation/mupen64plus-video-glide64mk2:gles2 - Use GLES2 instead of > OpenGL > games-emulation/mupen64plus-video-rice:gles2 - Use GLES2 instead of OpenGL > kde-apps/kdenlive:gles2 - Use GLES 2.0 or later instead of full OpenGL > kde-frameworks/plasma:gles2 - Use GLES 2.0 or later instead of full OpenGL > kde-plasma/kwin:gles2 - Use OpenGL ES 2 instead of full GL > sci-libs/opencascade:gles2 - Use OpenGL ES 2.0 > www-plugins/freshplayerplugin:gles2 - Use system GLESv2 libraries instead of > ANGLE for shader translation > www-plugins/lightspark:gles - Replace default OpenGL renderer with GLESv2 Making a pull request to change these seems like a great plan. I'll be happy to help or review.
Re: [gentoo-dev] Package up for grabs: sys-firmware/iwl1000-ucode
On Sat, Nov 16, 2019 at 9:08 AM Michael 'veremitz' Everitt wrote: > > On 16/11/19 16:59, Matt Turner wrote: > > On Sat, Nov 16, 2019 at 1:06 AM Jaco Kroon wrote: > >> Hi, > >> > >> On 2019/11/15 21:35, Matt Turner wrote: > >>> On Fri, Nov 15, 2019 at 2:20 AM Ulrich Mueller wrote: > >>>> The package is somewhat redundant, because sys-kernel/linux-firmware > >>>> installs the same files. (Same for all other sys-firmware/iwl*-ucode > >>>> packages.) > >>> Should last-rite all of them, IMO. > >>> > >> I both agree and disagree with this. It's the simpler solution and > >> therefore I agree. > >> > >> I disagree because in some cases I really only want specific firmware > >> for specific sets of hardware (especially where space constraints are an > >> issue, read: embedded type systems). > >> > >> The current linux-firmware package is getting quite big in terms of > >> install. > > USE=savedconfig allows you to choose exactly which files to install :) > > > I've never found a good way (yet...) to figure out how to write a fresh new > 'savedconfig' if you haven't ever previously emerged the package in > question. Does anyone have a good method for this, that doesn't require > unpacking the whole nine yards (Megs, Gigs...) first? You could look at the upstream git repo and make a list based on that. Or, since you have to download the tarball anyway, ebuild ... unpack it and inspect. Or, use the live ebuild to avoid downloading the same data multiple times per tarball. Or, if you want maximal bandwidth savings don't bother with any of this and install the files you want manually since the files aren't going to change.
Re: [gentoo-dev] Package up for grabs: sys-firmware/iwl1000-ucode
On Sat, Nov 16, 2019 at 1:06 AM Jaco Kroon wrote: > > Hi, > > On 2019/11/15 21:35, Matt Turner wrote: > > On Fri, Nov 15, 2019 at 2:20 AM Ulrich Mueller wrote: > >> The package is somewhat redundant, because sys-kernel/linux-firmware > >> installs the same files. (Same for all other sys-firmware/iwl*-ucode > >> packages.) > > Should last-rite all of them, IMO. > > > I both agree and disagree with this. It's the simpler solution and > therefore I agree. > > I disagree because in some cases I really only want specific firmware > for specific sets of hardware (especially where space constraints are an > issue, read: embedded type systems). > > The current linux-firmware package is getting quite big in terms of install. USE=savedconfig allows you to choose exactly which files to install :)
Re: [gentoo-dev] Package up for grabs: sys-firmware/iwl1000-ucode
On Fri, Nov 15, 2019 at 2:20 AM Ulrich Mueller wrote: > The package is somewhat redundant, because sys-kernel/linux-firmware > installs the same files. (Same for all other sys-firmware/iwl*-ucode > packages.) Should last-rite all of them, IMO.
Re: [gentoo-dev] RFC: Require full $P not just $PN on stable/keyword commit messages
On Fri, Nov 1, 2019 at 12:59 PM Michael 'veremitz' Everitt wrote: > > Hello, > > I've noticed a lot of stabilisation commit messages (and a few keywording > ones too) simply state the package atom and not the relevant > release/version. I find this a little meaningless, as unless this is the > first time the package has ever been either stabilised or keyworded, it is > reasonable to expect that there is/was some transition point for a package > from when it first entered the Gentoo Repository. > > Therefore, it would be much /more/ useful to have the package-version > tagged in the commit message, so that you could easily grep logs for when a > given version of a package was stabilised, and/or keyworded. Granted, this > is more of-use in a historical context compared to a present (future?!) > one, but I would argue that it conveys more meaning -with- the version than > without. Yes, I agree we should do this. My commit messages look like: sys-apps/systemd-243-r2: ppc64 stable, bug 698766 net-misc/mosh-1.3.2: added ~alpha In the past people have argued that the version in the title is superfluous since you can get the same info from git (log|show) --stat but the same (misguided argument) can be used to justify something absurd like simply making the bug number the subject. Honestly, just put the dang version in the title.
Re: [gentoo-dev] separate /usr without initramfs
On Sun, Oct 27, 2019 at 3:06 AM James Le Cuirot wrote: > > On Sun, 27 Oct 2019 05:38:48 -0400 > Joshua Kinard wrote: > > > Why do I not like an initramfs, though? Well, for one, it complicates the > > kernel compiles (and it makes them bigger, something which is an issue on > > the old SGI systems at times). Two, it's another layer that I have to > > maintain. Three, it violates, in my mind, the simplicity of keeping the > > kernel and userland separated (e.g., kernel does kernel-y things, userland > > does userland-y things). > > You make it sound like the initramfs has to be built into the kernel > image. It can be but it usually isn't. I suspect you know that though? > Admittedly that does depend on support from your bootloader. While GRUB > and U-Boot have supported this for years, I forget what oddball > bootloaders your hardware may be using. Though he's likely not using it, GRUB2 supports all the platforms he mentioned (x86, amd64, sparc64, [sgi] mips).
Re: [gentoo-dev] Proposal: change to default policy of doing changes to packages that are maintained by other developers
On Mon, Oct 21, 2019 at 5:37 PM Kent Fredric wrote: > > On Mon, 21 Oct 2019 19:37:28 +0200 > Piotr Karbowski wrote: > > > This is a bit unhealthy, especially when some developers that maintain > > packages are out of reach, or the patches to update ebuild just rot on > > the bugzilla and are not taken in by maintainers. > > IME this is far from the norm and should not be used as the > justification here. I think exceptional cases are the reason for many, many policies in Gentoo. That probably doesn't surprise you. > If you don't have the patience to even wait _one_ day for a response, > maybe you shouldn't be doing opensource. I'm not sure what this is in reference to so it seems to be a non-sequitur, but I like the policy of at least waiting a day for review of non-critical fixes. Phrased another way, let people in every timezone have a chance.
Re: [gentoo-dev] Proposal: change to default policy of doing changes to packages that are maintained by other developers
On Mon, Oct 21, 2019 at 10:37 AM Piotr Karbowski wrote: > > Hi, > > I'd like to bring the topic of defining default policy to do changes to > packages within ::gentoo that one does not maintain. > > This topic goes back from time to time on #gentoo-dev, and as I was > told, it was originally sent to gentoo-dev mailing list by robbat2 (I > failed to find this in archive, so if anyone have copy of it, please share). > > Current policy is to never touch ebuild that one did not claim as > maintainer unless maintainer of said package allowed you to do so. > > This is a bit unhealthy, especially when some developers that maintain > packages are out of reach, or the patches to update ebuild just rot on > the bugzilla and are not taken in by maintainers. > > What I'd like to end with would be to set a policy that allows any > developer with write access to ebuilds tree do changes that are small in > scope, like a minor bug fixes, adding missing flags, version bumps, > anything, that does not require complete overhaul of ebuild, with the > option to set in metadata.xml that policy for specified package is to > deny anyone but maintainers from doing changes. > > The packages that would require a flag to prohibit non-maintainers from > doing changes would of course be those of toolchain, or other big in > user base packages that are in very good shape, as in gnome packages, GNOME is not in good shape. > kde packages, X11 packages and so on. These are in good shape. > Of course, the policy would also define, that if there are any bug > introduced by changes that non-maintainer made, it's responsibility of > those who did the change in first place to fix it and clean any mess > that it has created. > > I personally am fine with others doing changes to packages I own, as > long as they won't break anything and I do know from the discussion on > #gentoo-dev, that there are others who have similar opinion about it. > > Those who feel territorial and those who believe only maintainers should > maintain specified packages can just set the flag in metadata.xml and > continue with the current state of things for their packages. > > The reason why I would like to get default policy to allow-all is that I > do not believe most of developers would want to go around all the > packages they own and set it manually to allow others doing changes even > if they're fine with others touching those packages. > > What do you think folks? I typically operate this way: If the package maintainer is active (on IRC, mailing lists, bugzilla) I file a bug. If no response after a week or two, depending on the importance of the change I commit it myself. If the package is not actively maintained (maintainer-needed@ or the maintainer has not touched the package in a long time while there are open bugs without response, etc) and the change is trivial (missing dependency, simple version bump for non-critical package, etc), then I'll just commit it directly. If the package is not actively maintained and the change is not trivial, I file a bug and try to get the maintainer to review. If they don't respond, I try to get others that may be interested to review and then commit after 2 weeks. For tree-wide stuff (package rename, removing amd64-fbsd keywords, $Header: ...$, etc) I think a mailing list post announcing what you're doing is a good idea. Wait a couple days for feedback and then do it. No need to get an ack from individual maintainers. I feel like these are pretty reasonable guidelines and have rarely gotten me yelled at. I know that a lot of the details of my personal behavior are subjective, but maybe that's good enough? Not sure. We seem to always have some disagreeable person force us to codify common sense. Am I missing any cases? The only thing I can think of is maintainers that are so territorial that try to prevent others from committing to their packages and also are not responsive to bug reports. Fortunately that is uncommon, but unfortunately it does still happen today. I don't really know how to solve that, but /that/ seems like the only real problem case to me.
Re: [gentoo-dev] New distfile mirror layout
On Mon, Oct 21, 2019 at 9:42 AM Richard Yao wrote: > Also, another idea is to use a cheap hash function (e.g. fletcher) and just > have the mirrors do the hashing behind the scenes. Then we would have the > best of both worlds. It probably would have been better to make these suggestions when the GLEP was discussed close to two years ago. I'm glad that we have ideas for improvements but I worry that we're just backseat driving at this point given that the GLEP's now implemented.
[gentoo-dev] Last Rites: dev-python/gnome-keyring-python
# Matt Turner (2019-10-21) # Replaced by introspection bindings. Bug #628938 # Removal in 30 days dev-python/gnome-keyring-python signature.asc Description: PGP signature
Re: [gentoo-dev] New distfile mirror layout
On Sun, Oct 20, 2019 at 1:25 AM Joshua Kinard wrote: > In any event, I still think using devspace is a bad idea. A centralized > distfiles repo is what most other distros use, and it's what we should use. I agree, but let's discuss that in a separate topic.
Re: [gentoo-dev] The demotivating process of contributing to devmanual
On Thu, Oct 17, 2019 at 9:38 PM desultory wrote: > Since the thread seemed to have already wrapped up with a positive resolution, I question why you responded in the way you did.
Re: [gentoo-dev] stable-bot is down. Temporary? Forever? Can we have a contacts page for it?
On Thu, Sep 26, 2019 at 12:29 AM Sergei Trofimovich wrote: > > I noticed that stable-bot stopped marking bugs as verified for stbilization. > Example: > https://bugs.gentoo.org/695252 > > 1. Is it gone forever and arch teams should stop relying on it's presence? > 2. If not can the owner tweak it? > 3. Can we have a wiki page that describes the setup and who to send reports > to? >Doc would be useful to run it locally, send bugs/enhancements, post current >status if it's known to be broken. > It looks like it is working now, but I think we really should know a few things: (1) Who maintains it (2) Where the code is (3) and perhaps what happened to bring it down It's a pretty important piece of infrastructure that we've come to rely on, so it should be treated as such.
[gentoo-dev] RFC: GID/UID assignment for mosquitto (482)
I don't see this being defined in other distros' lists, so I've selected the highest ID available (after Bitcoin gets 483).
Re: [gentoo-dev] [RFC] Adding 'GPL-2-only', 'GPL-3-only' etc. license variants for better auditing
On Tue, Sep 24, 2019 at 12:13 AM Ulrich Mueller wrote: > > >>>>> On Tue, 24 Sep 2019, Matt Turner wrote: > > > Just responding because the absurdity of this angers me, to be honest. > > See if you notice anything funny about the URL: > > > https://www.gnu.org/licenses/old-licenses/gpl-2.0.en.html > > What do you mean? Should we localise it, because translations in other > languages exist? Sorry, but that's not going to happen. No, I am pointing out that even the GNU project sometimes refers to the license as GPL "2.0", which you seemed to object to SPDX doing.
Re: [gentoo-dev] [RFC] Adding 'GPL-2-only', 'GPL-3-only' etc. license variants for better auditing
On Sat, Sep 21, 2019 at 4:46 PM Ulrich Mueller wrote: > > >>>>> On Sun, 22 Sep 2019, Matt Turner wrote: > > > An idea to consider: use SPDX license identifiers (see > > https://spdx.org/licenses/) > > > For GPL 2 they are "GPL-2.0-only" and "GPL-2.0-or-later" > > Yeah, they have a history of using silly names. What does 2.0 mean? > There is no such version of the GPL, and with Gentoo versioning rules, > 2 is not equal to 2.0. Just responding because the absurdity of this angers me, to be honest. See if you notice anything funny about the URL: https://www.gnu.org/licenses/old-licenses/gpl-2.0.en.html
Re: [gentoo-dev] Re: [RFC] Adding 'GPL-2-only', 'GPL-3-only' etc. license variants for better auditing
On Mon, Sep 23, 2019 at 6:42 PM Jason Zaman wrote: > > On Sat, Sep 21, 2019 at 09:17:53PM +0200, Ulrich Mueller wrote: > > > On Sat, 21 Sep 2019, Michał Górny wrote: > > > > > TL;DR: I'd like to replace 'GPL-2' with 'GPL-2-only' etc., having > > > the former trigger QA warning asking the dev to double-check if it's > > > 'GPL-2-only' or 'GPL-2+'. > > > > This has been discussed before. There is no such license as GPL-2-only. > > Yes there is: > https://spdx.org/licenses/GPL-2.0-only.html > https://spdx.org/licenses/GPL-2.0-or-later.html Just so everything is clear: Ulrich is just making an extremely pedantic point that the there's no version of the GPL-2 license itself with the "only" in it. Strange, now that I think about it I don't remember a "GPL-2+" license either...
Re: [gentoo-dev] [RFC] Adding 'GPL-2-only', 'GPL-3-only' etc. license variants for better auditing
On Sat, Sep 21, 2019 at 4:46 PM Ulrich Mueller wrote: > > >>>>> On Sun, 22 Sep 2019, Matt Turner wrote: > > > An idea to consider: use SPDX license identifiers (see > > https://spdx.org/licenses/) > > > For GPL 2 they are "GPL-2.0-only" and "GPL-2.0-or-later" > > Yeah, they have a history of using silly names. What does 2.0 mean? > There is no such version of the GPL, and with Gentoo versioning rules, > 2 is not equal to 2.0. > > Another funny thing is that they first introduced a "+" operator, but > then decided not to use it for the GPL family, but append "-or-later" > instead. (And IIUC, "GPL-2.0-only+" is valid in their scheme and > equivalent to "GPL-2.0-or-later".) Yes, from the page I cited it seems that they decided that differentiating with only a '+' character was a bad idea -- the exact thing Michał is suggesting we stop doing. > Release 3.0 replaced previous Identifiers for GNU licenses with more explicit > Identifiers to reflect the "this version only" or "any later version" option > specific to those licenses. As such, the previously used Identifiers for > those licenses are deprecated as of v3.0.
Re: [gentoo-dev] [RFC] Adding 'GPL-2-only', 'GPL-3-only' etc. license variants for better auditing
On Sat, Sep 21, 2019 at 9:57 AM Matt Turner wrote: > > On Sat, Sep 21, 2019 at 9:09 AM Michał Górny wrote: > > TL;DR: I'd like to replace 'GPL-2' with 'GPL-2-only' etc., having > > the former trigger QA warning asking the dev to double-check if it's > > 'GPL-2-only' or 'GPL-2+'. > > I think that's a good idea. An idea to consider: use SPDX license identifiers (see https://spdx.org/licenses/) For GPL 2 they are "GPL-2.0-only" and "GPL-2.0-or-later"
Re: [gentoo-dev] Re: [RFC] Adding 'GPL-2-only', 'GPL-3-only' etc. license variants for better auditing
On Sat, Sep 21, 2019 at 1:58 PM Ulrich Mueller wrote: > > > On Sat, 21 Sep 2019, Michał Górny wrote: > > > I'd like to propose to employ a more systematic method of resolving this > > problem. I would like to add additional explicit 'GPL-n-only' licenses, > > and discourage using short 'GPL-n' in favor of them. The end result > > would be three licenses per every version/variant, e.g.: > > > GPL-2-only -- version 2 only > > GPL-2+ -- version 2 or newer > > GPL-2 -- might be either, audit necessary > > To elaborate a bit more on this: "GPL-2" already has that well defined > meaning that your proposed "GPL-2-only" has, namely that the package is > licensed under the GNU General Public License, version 2. We are all aware. But the point is to explicitly put "-only" in the LICENSE metadata so that ebuild authors are less likely to confuse GPL-2 vs GPL-2+. > Presumably, your change would cause a long transition time, in which we > would have *three* variants for every GPL version (as well as LGPL, > AGPL, FDL), two of them with identical meaning. And after the transition > time, we would have "GPL-2-only" instead of "GPL-2", which is not only > longer but also not accurate. Sure, but who cares about a long transition time? We still have EAPI=0 ebuilds in tree -- and that's okay since we can quickly and easily tell what hasn't been transitioned! > Plus, it would result in paradoxical entries like "|| ( GPL-2-only > GPL-3-only )" for a package that can be distributed under GPL versions 2 > or 3 but no later version. That paradoxical entry is pretty clear to me. > If the goal of this exercise is to do an audit of ebuilds labelled as > "GPL-2", then a less intrusive approach (which I had already suggested > when this issue had last been discussed) would be to add a comment to > the LICENSE line, either saying "# GPL-2 only" for packages that have > been verified. Or the other way aroung, starting with a comment saying > that it is undecided, which would be removed after an audit. This would It's not a one-time audit. Michał has a history of fixing things in ways that does not allow the issue to return. I imagine that's what he's doing here, and it would not surprise me at all if something could be wired into CI to help ensure this. > have the advantage not to confuse users, and have no impact on their > ACCEPT_LICENSE settings. (For example, some people exclude AGPL and > would have to add entries for AGPL-3-only.) Trivial concern solved with a news item.
Re: [gentoo-dev] [RFC] Adding 'GPL-2-only', 'GPL-3-only' etc. license variants for better auditing
On Sat, Sep 21, 2019 at 9:09 AM Michał Górny wrote: > TL;DR: I'd like to replace 'GPL-2' with 'GPL-2-only' etc., having > the former trigger QA warning asking the dev to double-check if it's > 'GPL-2-only' or 'GPL-2+'. I think that's a good idea.
Re: [gentoo-dev] [PATCH 1/2] use.desc: Make lz4 a global flag
On Sun, Sep 15, 2019 at 7:12 AM Michał Górny wrote: > > The 'lz4' flag is used consistently for the LZ4 compression algorithm > in 23 packages. Make it a global flag. Good idea. Ack for both this and snappy.
Re: [gentoo-dev] Need ARM/AArch64 test data for cpuid2cpuflags
>From my original generation SolidRun Cubox: $ ./hwcap-dump hwcap:0004ead6 hwcap2: mattst88@cubox ~/cpuid2cpuflags-7-dev $ uname -a Linux cubox 5.2.7 #11 Wed Aug 7 17:50:03 PDT 2019 armv7l ARMv7 Processor rev 5 (v7l) Marvell Dove GNU/Linux cpuid2cflags says CPU_FLAGS_ARM: edsp iwmmxt thumb vfp vfpv3 v4 v5 v6 v7 thumb2 /proc/cpuinfo: processor : 0 model name : ARMv7 Processor rev 5 (v7l) BogoMIPS: 333.33 Features: half thumb fastmult vfp edsp iwmmxt thumbee vfpv3 vfpv3d16 tls idivt CPU implementer : 0x56 CPU architecture: 7 CPU variant : 0x0 CPU part: 0x581 CPU revision: 5 Hardware: Marvell Dove Revision: Serial : I've got an "iwmmxt2" flag on x11-libs/pixman, but I don't think there's a hwcap bit for it. At least not that I see in arch/arm/include/uapi/asm/hwcap.h That's just as well. It's only a very small optimization over iwmmxt.
Re: [gentoo-dev] Home directory for the 'portage' user
On Mon, Sep 2, 2019 at 10:05 AM Mike Gilbert wrote: > > I would like to create an acct-user package for the 'portage' user, > but I'm having trouble deciding on a home directory. > > baselayout currently sets it to /var/tmp/portage, and this just seems > like a bad idea to me. I'm pretty sure we have a QA policy against > installing files there anyway. Agreed. Many people would like to put /var/tmp/portage on tmpfs. If the portage user needs any persistent configuration (like an ssh key) putting its home on tmpfs would be difficult.
Re: [gentoo-dev] Last Rites: sci-chemistry/burrow-owl and dependencies
On Sun, Sep 1, 2019 at 1:04 PM Matt Turner wrote: > > # 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. Like with the games-strategy/liquidwar6 mask, I mistook guile:12 for guile < 2. Should we still give last rites to these packages? I'm inclined to keep the last rites mask in place and see if anyone wants any of these packages. > # 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
Re: [gentoo-dev] Last Rites: games-strategy/liquidwar6
On Sun, Sep 1, 2019 at 1:05 PM Matt Turner wrote: > > # Matt Turner (2019-09-01) > # Depends on dev-scheme/guile:12. Unpackaged versions from 2015. I made a mistake here (that I corrected in commit 7ca64f844e18). The mask now reads: # Matt Turner (2019-09-01) -# Depends on dev-scheme/guile:12. Unpackaged versions from 2015. +# Unmaintained, unpackaged versions from 2015. Incompatible with guile-2.2. # Removal in 30 days. # Bug #654654. > # Removal in 30 days. # Bug #654654. > games-strategy/liquidwar6
