Re: [gentoo-dev] News item for review: Change of ACCEPT_LICENSE default
On Tue, Apr 23, 2019 at 10:11:04AM +0200, Ulrich Mueller wrote: > Hello, > > As the Council has decided in its 20190210 meeting, we are about to > change the ACCEPT_LICENSE default in the base profile (pending final > acknowledgement from RelEng). > > Please review the corresponding news item included below. > > > Title: Change of ACCEPT_LICENSE default > Author: Ulrich Mueller > Posted: 2019-04-XX > Revision: 1 > News-Item-Format: 2.0 > > The default set of accepted licenses has been changed [1,2] to: > >ACCEPT_LICENSE="-* @FREE" > > This means that by default only free software and documentation > will be installable. The "FREE" license group is defined in the > profiles/license_groups file in the Gentoo repository. It contains > licenses that are explicitly approved by the Free Software Foundation > or by the Open Source Initiative, or that follow the Free Software > Definition. > It would probably read better as: "It contains licenses that are explicitly approved by the Free Software Foundation, the Open Source Initiative, or that follow the Free Software Definition." > The system wide default for the accepted licenses is controlled by > the ACCEPT_LICENSE variable in /etc/portage/make.conf, or it can be > specified on a per-package basis in /etc/portage/package.license. > > For example, to allow the app-arch/unrar and sys-kernel/linux-firmware > packages to be installed, the following lines would have to be added > to /etc/portage/package.license: > >app-arch/unrar unRAR >sys-kernel/linux-firmware linux-firmware no-source-code > > If you want to revert to the previous default, add the following line > to /etc/portage/make.conf: > >ACCEPT_LICENSE="* -@EULA" > > This will permit all licenses, except End User License Agreements that > require reading and signing an acceptance agreement. Note that this > will also accept non-free software and documentation. > > See GLEP 23 [3] as well as the make.conf(5) and portage(5) man pages > for the detailed syntax of the ACCEPT_LICENSE variable. > > [1] https://projects.gentoo.org/council/meeting-logs/20190210-summary.txt > [2] https://bugs.gentoo.org/676248 > [3] https://www.gentoo.org/glep/glep-0023.html -- Cheers, Aaron signature.asc Description: PGP signature
Re: [gentoo-dev] What's going on with the tmpfiles eclasses?
On 4/23/19 2:03 PM, Michael Orlitzky wrote: > We have two eclasses with almost-identical functions for handling > tmpfiles.d entries: > > 1. systemd.eclass > > a. systemd_dotmpfilesd > b. systemd_newtmpfilesd > c. systemd_tmpfiles_create > > 2. tmpfiles.eclass > > a. dotmpfiles > b. newtmpfiles > c. tmpfiles_process > > The do/new functions are basically identical, while the create/process > functions differ only in the fact that the one from tmpfiles.eclass > supports opentmpfiles as well. Why do we have both? Couldn't the > systemd.eclass ones be implemented in terms of the tmpfiles.eclass ones, > and then deprecated (in favor of tmpfiles.eclass itself) in newer EAPIs? > > Or am I missing something? Note that systemd.eclass is lighter on dependencies, which is why I chose it for the solution to bug 490676 [1] and bug 643386 [2] in the sys-apps/portage ebuilds. [1] https://bugs.gentoo.org/490676 [2] https://bugs.gentoo.org/643386 -- Thanks, Zac signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Last rites: dev-java/oracle-{jre,jdk}-bin
On Wed, Apr 17, 2019 at 07:44:53PM -0700, Georgy Yakovlev wrote: > I've modified the mask for now, but I still believe we should drop it. > I do not maintain it at all, I only work on openjdk and a bit of icedtea. Speaking of openjdk, all versions are masked and the ebuilds contain: if use gentoo-vm ; then ewarn "WARNING! You have enabled the gentoo-vm USE flag, making this JDK" ewarn "recognised by the system. This will almost certainly break things." else When will openjdk be a viable vm? As you say, the Oracle license is screwy now, and icedtea isn't really current. Thanks...
Re: [gentoo-dev] What's going on with the tmpfiles eclasses?
On Tue, Apr 23, 2019 at 5:03 PM Michael Orlitzky wrote: > > We have two eclasses with almost-identical functions for handling > tmpfiles.d entries: > > 1. systemd.eclass > > a. systemd_dotmpfilesd > b. systemd_newtmpfilesd > c. systemd_tmpfiles_create > > 2. tmpfiles.eclass > > a. dotmpfiles > b. newtmpfiles > c. tmpfiles_process > > The do/new functions are basically identical, while the create/process > functions differ only in the fact that the one from tmpfiles.eclass > supports opentmpfiles as well. Why do we have both? Couldn't the > systemd.eclass ones be implemented in terms of the tmpfiles.eclass ones, > and then deprecated (in favor of tmpfiles.eclass itself) in newer EAPIs? > > Or am I missing something? Nope, seems like you have a pretty good handle on it. Just nobody has gotten around to doing the work to deprecate the functions in systemd.eclass.
[gentoo-dev] What's going on with the tmpfiles eclasses?
We have two eclasses with almost-identical functions for handling tmpfiles.d entries: 1. systemd.eclass a. systemd_dotmpfilesd b. systemd_newtmpfilesd c. systemd_tmpfiles_create 2. tmpfiles.eclass a. dotmpfiles b. newtmpfiles c. tmpfiles_process The do/new functions are basically identical, while the create/process functions differ only in the fact that the one from tmpfiles.eclass supports opentmpfiles as well. Why do we have both? Couldn't the systemd.eclass ones be implemented in terms of the tmpfiles.eclass ones, and then deprecated (in favor of tmpfiles.eclass itself) in newer EAPIs? Or am I missing something?
[gentoo-dev] How to map a manually installed TeXLive (via tlmgr) properly on Gentoo?
Hi, some users need recent TeX packages. These users install TeXLive via tlmgr either for every user, or system wide. We are not able at the moment to provide a full set of TeX packages in the Gentoo tree, which are less than a year old. Tlmgr users know how many updates they get every week. In a system wide installation one could add the list of provided packages to package.provided and other tools, which depend on the specific LaTeX packages can be installed properly. What is the best way to continue without package.provided? Should we prepare a virtual package for virtual/tlmgr and rewrite the dependencies in the way, that either virtual/latex-base or virtual/tlmgr can satisfy a package? Any better ideas? -- Best, Jonas signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Looking for members for the openstack project
Le 21/04/2019 7:00, Matthew Thode a écrit : You (and the other gentoo dev who contacted me privately) feel free to add yourself to the member list in the wiki. https://wiki.gentoo.org/wiki/Project:Openstack I'll be calling an election soon as well. I will add myself to the list (and wiki page), I know a thing or 2 about upstream :) -- Matthew Thode (prometheanfire) On 19-04-16 23:55:39, Geaaru wrote: Hi Matthew, I'm not a Gentoo dev but a maintainer of some package through proxy-maint. I have few time for a full support but if you want I could help you for some specific package. In the past I pushed some patches to cinder and I would like to try to play again with openstack stuff. Let me know wdyt. Thanks for your work with the ebuilds of Openstack. # geaaru On Tue, Apr 16, 2019, 21:16 Matthew Thode wrote: > I'm considering disbanding the project and switching to sole > maintainership of the project. So far I'm the only active maintianer in > the project that I can see. > > I'm looking for others that are interested in helping maintain the > openstack ebuilds. It's fairly easy as an ongoing thing with two major > releases a year (which starts an update of 160 or so packages). It's > python based and I've found maintaining the ebuilds to be very easy > individually if that helps. > > There are other actions that'd be helpful as well. Some arm64 stage > work to then do some arm64 diskimage-builder work to work on building VM > images for other arches (openstack or 'vanilla'). > > Please respond if you are intrested in joining. > > -- > Matthew Thode (prometheanfire) > -- Bernard Cafarelli (Voyageur) Gentoo developer
Re: [gentoo-dev] [PATCH] use.desc: Make USE=zstd global
On Mon, 2019-04-15 at 15:45 +0200, David Seifert wrote: > From bdb44cf710f268e8a82930a8bd8de76b5cca775a Mon Sep 17 00:00:00 > 2001 > From: David Seifert > Date: Mon, 15 Apr 2019 15:19:41 +0200 > Subject: [PATCH] use.desc: Make USE=zstd global > > Signed-off-by: David Seifert > --- > app-arch/libarchive/metadata.xml| 3 --- > app-arch/rpm/metadata.xml | 3 --- > app-backup/fsarchiver/metadata.xml | 1 - > app-text/groonga/metadata.xml | 1 - > dev-libs/boost/metadata.xml | 1 - > dev-libs/c-blosc/metadata.xml | 1 - > dev-python/fastparquet/metadata.xml | 1 - > dev-util/heaptrack/metadata.xml | 3 --- > media-libs/tiff/metadata.xml| 3 --- > net-vpn/tor/metadata.xml| 1 - > profiles/use.desc | 1 + > sci-libs/gdal/metadata.xml | 1 - > sys-fs/btrfs-progs/metadata.xml | 1 - > sys-fs/squashfs-tools/metadata.xml | 1 - > sys-fs/squashfuse/metadata.xml | 1 - > 15 files changed, 1 insertion(+), 22 deletions(-) > > diff --git a/profiles/use.desc b/profiles/use.desc > index 1f5b27e9190..fc19bbd0bba 100644 > --- a/profiles/use.desc > +++ b/profiles/use.desc > @@ -375,3 +375,4 @@ zeroconf - Support for DNS Service Discovery > (DNS- > SD) > zip - Enable support for ZIP archives > zlib - Add support for zlib (de)compression > zsh-completion - Enable zsh completion support > +zstd - Enable support for ZSTD compression > diff --git a/sci-libs/gdal/metadata.xml b/sci-libs/gdal/metadata.xml > index 14e5e92e78f..7088f71ba0f 100644 Merged
[gentoo-dev] News item for review: Change of ACCEPT_LICENSE default
Hello, As the Council has decided in its 20190210 meeting, we are about to change the ACCEPT_LICENSE default in the base profile (pending final acknowledgement from RelEng). Please review the corresponding news item included below. Title: Change of ACCEPT_LICENSE default Author: Ulrich Mueller Posted: 2019-04-XX Revision: 1 News-Item-Format: 2.0 The default set of accepted licenses has been changed [1,2] to: ACCEPT_LICENSE="-* @FREE" This means that by default only free software and documentation will be installable. The "FREE" license group is defined in the profiles/license_groups file in the Gentoo repository. It contains licenses that are explicitly approved by the Free Software Foundation or by the Open Source Initiative, or that follow the Free Software Definition. The system wide default for the accepted licenses is controlled by the ACCEPT_LICENSE variable in /etc/portage/make.conf, or it can be specified on a per-package basis in /etc/portage/package.license. For example, to allow the app-arch/unrar and sys-kernel/linux-firmware packages to be installed, the following lines would have to be added to /etc/portage/package.license: app-arch/unrar unRAR sys-kernel/linux-firmware linux-firmware no-source-code If you want to revert to the previous default, add the following line to /etc/portage/make.conf: ACCEPT_LICENSE="* -@EULA" This will permit all licenses, except End User License Agreements that require reading and signing an acceptance agreement. Note that this will also accept non-free software and documentation. See GLEP 23 [3] as well as the make.conf(5) and portage(5) man pages for the detailed syntax of the ACCEPT_LICENSE variable. [1] https://projects.gentoo.org/council/meeting-logs/20190210-summary.txt [2] https://bugs.gentoo.org/676248 [3] https://www.gentoo.org/glep/glep-0023.html signature.asc Description: PGP signature
