[gentoo-dev] Packages up for grabs: www-plugins/passff{,-host}
Hello,
I'll be removing myself from (proxy-)maintainer of www-plugins/passff
and www-plugins/passff-host as firefox as been more and more of a pain
to deal with.
For example today I ended up discovering that firefox-68.3.0 bundles
Python 2.7.9 at ${S}/obj-x86_64-pc-linux-gnu/_virtualenvs/init/bin/python2.7
which triggered my blob remover that I use to make sure it is actually
built from sources. (not sure if I should file a gentoo bug on this one btw)
They have few bugs, one being solvable by a version bump which should
fix it. Feel free to ping me on IRC (nick: lanodan) or email for
questions about the packaging.
Should also be noted that www-plugins/passff could simply go away as
Mozilla plans to remove sideloaded extensions for Firefox 73.0[1].
1:
https://blog.mozilla.org/addons/2019/10/31/firefox-to-discontinue-sideloaded-extensions/
Re: [gentoo-dev] Packages up for grabs due to slis' retirement
On Wed, 18 Dec 2019 22:35:40 + Michael 'veremitz' Everitt wrote: > There is some very strange wrapping/formatting in this message, was that > intentional? If I had to guess, I'd say the word-wrap length was accidentally set to "8" instead of "80". pgpHbspqNJkzy.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] Needs ideas: Upcoming circular dependency: expat <> CMake
On Wed, 18 Dec 2019 23:58:22 + Sergei Trofimovich wrote: > [c] would be nice to be solved at portage level if portage could schedule > multiple merges for the same package with different USE flags. Related bugs: - Portage should be able to auto-flip USE="test" & FEATURES="test" https://bugs.gentoo.org/697914#c0 - Portage needs an extension to package.use specification to provide a level of discretion to portage to flip flags on its own https://bugs.gentoo.org/698920#c0 pgp4qmLQa8qhA.pgp Description: OpenPGP digital signature
Re: [gentoo-dev] Needs ideas: Upcoming circular dependency: expat <> CMake
On 12/18/19 4:02 PM, Sebastian Pipping wrote: > Hi all, > > > I noticed that dev-util/cmake depends on dev-libs/expat and that > libexpat upstream (where I'm involved) is in the process of > dropping GNU Autotools altogether in favor of CMake in the near future, > potentially the next release (without any known target release date). >> ... > > Do you have any ideas how to avoid a bad circular dependency issue for > our users in the future? Are you aware of similar problems and > solutions from the past? Keep autotools?
Re: [gentoo-dev] Needs ideas: Upcoming circular dependency: expat <> CMake
On Wed, 18 Dec 2019 22:02:47 +0100 Sebastian Pipping wrote: > Hi all, > > > I noticed that dev-util/cmake depends on dev-libs/expat and that > libexpat upstream (where I'm involved) is in the process of > dropping GNU Autotools altogether in favor of CMake in the near future, > potentially the next release (without any known target release date). > > CMake bundles a (previously outdated and vulnerable) copy of expat so > I'm not sure if re-activating that bundle — say with a new use flag > "system-expat" — would be a good thing to resort to for breaking the > cycle, with regard to security in particular. > > Do you have any ideas how to avoid a bad circular dependency issue for > our users in the future? Are you aware of similar problems and > solutions from the past? Fun fact: cmake is not keyworded for riscv. To think of solutions enumerating the arising problems explicitly might help here. I see a few: 1. initial system bootstrap requires solving a circular dependency 2. recovery from broken state (expat soname bump without preserved libs or cmake broken by one of many depends it has) [2.] effectively forbids a dependency circle. [1.] is hard to solve without users' intervention to at least flip a default flag. Some other distributions provide two packages to break the cycle. Example Gentoo solution would be: "cmake.ebuild" depends on "expat.ebuild", "expat.ebuild" depends on "cmake-with-bundled-expat.ebuild". Some examples of circular dependencies are: a) gcc/glibc/binutils toolchain. the solution is to provide prebuilt binaries as part of stage3. b) self-hosted languages without an interpreter in C (rust, golang, ghc). The solution is to provide prebuilt binaries in ebuilds. c) circular dependencies in tests. The solution is careful user's USE flags juggling: enable USE=test only for a package being tested. d) glibc depends on libidn2 to implement modern DNS demangling. glibc fixes it by not depending on libidn at build time and does manual library loading with dlopen()/dlsym(). e) vast majority of others: dependency bundling (users of autotools, gnulib, zlib, lua). All the above are not pretty. a) is simplest to maintain by ebuild maintainer and gentoo user, but probably not by releng. c) moves the burden to user. I personally would explore [e]: unconditional bundling of expat into cmake and make sure it's kept up-to-date there. [c] would be nice to be solved at portage level if portage could schedule multiple merges for the same package with different USE flags. -- Sergei
Re: [gentoo-dev] [PATCH 0/3] elisp{,-common}.eclass update for emacs-vcs consolidation
On 12/18/19 11:34 AM, Ulrich Mueller wrote: > > Removal of the virtual/emacs ebuilds won't remove the installed package > from users' systems. It will eventually disappear, when all its reverse > dependencies have been updated. Why would its continued presence as an > installed package (for another while) cause any problems? Unless the VDB is updated, portage will see a dependency on a package that doesn't exist and could refuse to do a lot of things like a @world update involving a rebuild of one of those packages, or a --depclean. This *does* happen if you mask virtual/emacs. It *could* happen if you delete it. > Revbumping its more than 400 reverse dependencies really doesn't sound > so attractive, and would cause rebuilds on users' systems for virtually > (pun intended :-) no benefit. If portage bails on an update and I have to troubleshoot the problem for ten minutes, then that's already wasted more of my time than if it reinstalled all 400 revdeps. The benefit is that people don't get cryptic messages from a confused packaged manager that they have to debug all day.
Re: [gentoo-dev] Packages up for grabs due to slis' retirement
On 18/12/19 22:33, Michał Górny wrote: > Hi, > > Due to slis retiring, the following packages are now in need of a new > maintainer: > > [ v] app-arch/wimlib > [ v] dev-embedded/lpc21isp > [b?] dev-libs/libflatarray > [ ] dev-libs/libpfm > [bv] dev-libs/papi > [ v] dev-python/aldryn- > boilerplates > [ v] dev-python/aldryn-common > [ v] dev-python/click-plugins > [ > v] dev-python/cligj > [ v] dev-python/django-durationfield > [ v] dev- > python/django_polymorphic > [ v] dev-python/django-sortedm2m > [bv] dev- > python/django-spurl > [ v] dev-python/easy-thumbnails > [ v] dev- > python/ipdbplugin > [bv] dev-python/Kivy > [ ] dev-python/kivy-garden > [ ] > dev-python/munch > [ v] dev-python/scoop > [ ] dev-python/URLObject > [ v] dev- > python/YURL > [b ] media-gfx/librecad > [b ] media-gfx/pycam > [b ] media- > libs/assimp > [S ] net-analyzer/ntopng > [ ] net-libs/nDPI > [ v] sci-libs/deap > [ > v] sci-libs/Fiona > [b?] sci-libs/libgeodecomp > [ v] sci-libs/pyshp > [ v] sci- > libs/Rtree > [ ] sci-libs/Shapely > [bv] sci-misc/repsnapper > [bv] sci- > visualization/visit > [bv] sys-cluster/hpx > > Legend: > b - package has (regular) bugs > S - package has vulnerabilities reported > v - package needs version bump > There is some very strange wrapping/formatting in this message, was that intentional? signature.asc Description: OpenPGP digital signature
[gentoo-dev] Packages up for grabs due to slis' retirement
Hi, Due to slis retiring, the following packages are now in need of a new maintainer: [ v] app-arch/wimlib [ v] dev-embedded/lpc21isp [b?] dev-libs/libflatarray [ ] dev-libs/libpfm [bv] dev-libs/papi [ v] dev-python/aldryn- boilerplates [ v] dev-python/aldryn-common [ v] dev-python/click-plugins [ v] dev-python/cligj [ v] dev-python/django-durationfield [ v] dev- python/django_polymorphic [ v] dev-python/django-sortedm2m [bv] dev- python/django-spurl [ v] dev-python/easy-thumbnails [ v] dev- python/ipdbplugin [bv] dev-python/Kivy [ ] dev-python/kivy-garden [ ] dev-python/munch [ v] dev-python/scoop [ ] dev-python/URLObject [ v] dev- python/YURL [b ] media-gfx/librecad [b ] media-gfx/pycam [b ] media- libs/assimp [S ] net-analyzer/ntopng [ ] net-libs/nDPI [ v] sci-libs/deap [ v] sci-libs/Fiona [b?] sci-libs/libgeodecomp [ v] sci-libs/pyshp [ v] sci- libs/Rtree [ ] sci-libs/Shapely [bv] sci-misc/repsnapper [bv] sci- visualization/visit [bv] sys-cluster/hpx Legend: b - package has (regular) bugs S - package has vulnerabilities reported v - package needs version bump -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
[gentoo-dev] RFC: UID/GID assignment for shellinabox (139)
I would like to reserve UID/GID 139 for shellinabox (www-misc/shellinabox) Debian, Fedora, and Red Hat do not have UID/GIDs reserved for shellinabox. FreeBSD [1] uses 139 so that's what I'm requesting. Gentoo API [2] shows these numbers are currently unused. Here's a PR for this change: https://github.com/gentoo/gentoo/pull/14046 [1] https://svnweb.freebsd.org/ports/head/GIDs?view=co [2] https://api.gentoo.org/uid-gid.txt Thanks, ~Craig signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Needs ideas: Upcoming circular dependency: expat <> CMake
Il giorno mer 18 dic 2019 alle ore 22:03 Sebastian Pipping ha scritto: > > CMake bundles a (previously outdated and vulnerable) copy of expat so > I'm not sure if re-activating that bundle — say with a new use flag > "system-expat" — would be a good thing to resort to for breaking the > cycle, with regard to security in particular. > > Pushing gently upstream to upgrade bundled expat copy would (at least temporarily) fix the issue and also benefit other use cases. Maybe they are Gentoo friendly they also release quite often, which would fix the problem soon
Re: [gentoo-dev] Needs ideas: Upcoming circular dependency: expat <> CMake
On Wed, 2019-12-18 at 22:10 +0100, Piotr Karbowski wrote: > Hi, > > On 18/12/2019 22.08, Michał Górny wrote: > > I know that's an unhappy idea but maybe it's time to include CMake > > in stage3. Then it would be just a matter of temporarily enabling > > bundled libs for stage builds, I guess. > > Not sure what's unhappy about it, but I like the idea, it will be > painless for new users with rather limited cost of ownership on Gentoo side. > Increase of stage size may make people unhappy. -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Needs ideas: Upcoming circular dependency: expat <> CMake
Hi, On 18/12/2019 22.08, Michał Górny wrote: > I know that's an unhappy idea but maybe it's time to include CMake > in stage3. Then it would be just a matter of temporarily enabling > bundled libs for stage builds, I guess. Not sure what's unhappy about it, but I like the idea, it will be painless for new users with rather limited cost of ownership on Gentoo side. -- Piotr. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Needs ideas: Upcoming circular dependency: expat <> CMake
On Wed, 2019-12-18 at 22:02 +0100, Sebastian Pipping wrote: > Hi all, > > > I noticed that dev-util/cmake depends on dev-libs/expat and that > libexpat upstream (where I'm involved) is in the process of > dropping GNU Autotools altogether in favor of CMake in the near future, > potentially the next release (without any known target release date). > > CMake bundles a (previously outdated and vulnerable) copy of expat so > I'm not sure if re-activating that bundle — say with a new use flag > "system-expat" — would be a good thing to resort to for breaking the > cycle, with regard to security in particular. > > Do you have any ideas how to avoid a bad circular dependency issue for > our users in the future? Are you aware of similar problems and > solutions from the past? > I know that's an unhappy idea but maybe it's time to include CMake in stage3. Then it would be just a matter of temporarily enabling bundled libs for stage builds, I guess. -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
[gentoo-dev] Needs ideas: Upcoming circular dependency: expat <> CMake
Hi all, I noticed that dev-util/cmake depends on dev-libs/expat and that libexpat upstream (where I'm involved) is in the process of dropping GNU Autotools altogether in favor of CMake in the near future, potentially the next release (without any known target release date). CMake bundles a (previously outdated and vulnerable) copy of expat so I'm not sure if re-activating that bundle — say with a new use flag "system-expat" — would be a good thing to resort to for breaking the cycle, with regard to security in particular. Do you have any ideas how to avoid a bad circular dependency issue for our users in the future? Are you aware of similar problems and solutions from the past? Thanks and best Sebastian
Re: [gentoo-portage-dev] Build path abi missing in qemu-user
On 18/12/19 17:36, Joakim Tjernlund wrote: > On Wed, 2019-12-18 at 11:22 -0500, Mike Gilbert wrote: >> CAUTION: This email originated from outside of the organization. Do not >> click links or open attachments unless you recognize the sender and know the >> content is safe. >> >> >> On Thu, Dec 12, 2019 at 10:18 AM Joakim Tjernlund >> wrote: >>> When build in a qemu-user chroot I get odd build paths: >>> /var/tmp/portage/dev-libs/libxml2-2.9.9-r1/work/libxml2-2.9.9-.ppc >>> >>> This path is missing the abi_ppc_32 like so: >>> >>> /var/tmp/portage/dev-libs/libxml2-2.9.9-r1/work/libxml2-2.9.9-abi_ppc_32.ppc >>> >>> I struggle to find out why this happens, any ideas? >> I would guess you are using a profile that doesn't define the ABI_PPC >> USE_EXPAND variable properly. >> > # portageq envvar USE_EXPAND > ABI_MIPS ABI_PPC ABI_S390 ABI_X86 ALSA_CARDS APACHE2_MODULES APACHE2_MPMS > CALLIGRA_FEATURES CAMERAS COLLECTD_PLUGINS CPU_FLAGS_X86 CROSSCOMPILE_OPTS > CURL_SSL DRACUT_MODULES > DVB_CARDS ELIBC ENLIGHTENMENT_MODULES FCDSL_CARDS FFTOOLS FOO2ZJS_DEVICES > FRITZCAPI_CARDS GPSD_PROTOCOLS GRUB_PLATFORMS INPUT_DEVICES KERNEL > LCD_DEVICES LIBREOFFICE_EXTENSIONS > LINGUAS LIRC_DEVICES MONKEYD_PLUGINS NETBEANS_MODULES NGINX_MODULES_HTTP > NGINX_MODULES_MAIL OFED_DRIVERS OFFICE_IMPLEMENTATION OPENMPI_FABRICS > OPENMPI_OFED_FEATURES OPENMPI_RM > PHP_TARGETS PYTHON_SINGLE_TARGET PYTHON_TARGETS QEMU_SOFTMMU_TARGETS > QEMU_USER_TARGETS ROS_MESSAGES RUBY_TARGETS SANE_BACKENDS USERLAND > UWSGI_PLUGINS VIDEO_CARDS > VOICEMAIL_STORAGE XFCE_PLUGINS XTABLES_ADDONS > cu3-jocke fs # portageq envvar ABI_PPC > 32 > cu3-jocke fs # eselect profile list > Available profile symlink targets: > [1] default/linux/powerpc/ppc32/13.0 > [2] default/linux/powerpc/ppc32/13.0/desktop > [3] default/linux/powerpc/ppc32/13.0/desktop/gnome > [4] default/linux/powerpc/ppc32/13.0/desktop/gnome/systemd > [5] default/linux/powerpc/ppc32/13.0/desktop/kde > [6] default/linux/powerpc/ppc32/13.0/desktop/kde/systemd > [7] default/linux/powerpc/ppc32/13.0/developer > [8] default/linux/powerpc/ppc64/13.0/32bit-userland > [9] default/linux/powerpc/ppc64/13.0/32bit-userland/desktop > [10] default/linux/powerpc/ppc64/13.0/32bit-userland/desktop/gnome > [11] default/linux/powerpc/ppc64/13.0/32bit-userland/desktop/gnome/systemd > [12] default/linux/powerpc/ppc64/13.0/32bit-userland/desktop/kde > [13] default/linux/powerpc/ppc64/13.0/32bit-userland/desktop/kde/systemd > [14] default/linux/powerpc/ppc64/13.0/32bit-userland/developer > [15] hardened/linux/powerpc/ppc32 > [16] hardened/linux/powerpc/ppc64/32bit-userland > [17] hardened/linux/musl/ppc > [18] default/linux/uclibc/ppc > [19] hardened/linux/uclibc/ppc > [20] tmv3-target-overlay:cusfpv3 * > > cusfpv3 inherits default/linux/powerpc/ppc32/13.0 > > Jocke > Haven't 13.0 profiles been deprecated? (and/or deleted by now ...) signature.asc Description: OpenPGP digital signature
Re: [gentoo-portage-dev] Build path abi missing in qemu-user
On Wed, 2019-12-18 at 11:22 -0500, Mike Gilbert wrote: > CAUTION: This email originated from outside of the organization. Do not click > links or open attachments unless you recognize the sender and know the > content is safe. > > > On Thu, Dec 12, 2019 at 10:18 AM Joakim Tjernlund > wrote: > > When build in a qemu-user chroot I get odd build paths: > > /var/tmp/portage/dev-libs/libxml2-2.9.9-r1/work/libxml2-2.9.9-.ppc > > > > This path is missing the abi_ppc_32 like so: > > > > /var/tmp/portage/dev-libs/libxml2-2.9.9-r1/work/libxml2-2.9.9-abi_ppc_32.ppc > > > > I struggle to find out why this happens, any ideas? > > I would guess you are using a profile that doesn't define the ABI_PPC > USE_EXPAND variable properly. > # portageq envvar USE_EXPAND ABI_MIPS ABI_PPC ABI_S390 ABI_X86 ALSA_CARDS APACHE2_MODULES APACHE2_MPMS CALLIGRA_FEATURES CAMERAS COLLECTD_PLUGINS CPU_FLAGS_X86 CROSSCOMPILE_OPTS CURL_SSL DRACUT_MODULES DVB_CARDS ELIBC ENLIGHTENMENT_MODULES FCDSL_CARDS FFTOOLS FOO2ZJS_DEVICES FRITZCAPI_CARDS GPSD_PROTOCOLS GRUB_PLATFORMS INPUT_DEVICES KERNEL LCD_DEVICES LIBREOFFICE_EXTENSIONS LINGUAS LIRC_DEVICES MONKEYD_PLUGINS NETBEANS_MODULES NGINX_MODULES_HTTP NGINX_MODULES_MAIL OFED_DRIVERS OFFICE_IMPLEMENTATION OPENMPI_FABRICS OPENMPI_OFED_FEATURES OPENMPI_RM PHP_TARGETS PYTHON_SINGLE_TARGET PYTHON_TARGETS QEMU_SOFTMMU_TARGETS QEMU_USER_TARGETS ROS_MESSAGES RUBY_TARGETS SANE_BACKENDS USERLAND UWSGI_PLUGINS VIDEO_CARDS VOICEMAIL_STORAGE XFCE_PLUGINS XTABLES_ADDONS cu3-jocke fs # portageq envvar ABI_PPC 32 cu3-jocke fs # eselect profile list Available profile symlink targets: [1] default/linux/powerpc/ppc32/13.0 [2] default/linux/powerpc/ppc32/13.0/desktop [3] default/linux/powerpc/ppc32/13.0/desktop/gnome [4] default/linux/powerpc/ppc32/13.0/desktop/gnome/systemd [5] default/linux/powerpc/ppc32/13.0/desktop/kde [6] default/linux/powerpc/ppc32/13.0/desktop/kde/systemd [7] default/linux/powerpc/ppc32/13.0/developer [8] default/linux/powerpc/ppc64/13.0/32bit-userland [9] default/linux/powerpc/ppc64/13.0/32bit-userland/desktop [10] default/linux/powerpc/ppc64/13.0/32bit-userland/desktop/gnome [11] default/linux/powerpc/ppc64/13.0/32bit-userland/desktop/gnome/systemd [12] default/linux/powerpc/ppc64/13.0/32bit-userland/desktop/kde [13] default/linux/powerpc/ppc64/13.0/32bit-userland/desktop/kde/systemd [14] default/linux/powerpc/ppc64/13.0/32bit-userland/developer [15] hardened/linux/powerpc/ppc32 [16] hardened/linux/powerpc/ppc64/32bit-userland [17] hardened/linux/musl/ppc [18] default/linux/uclibc/ppc [19] hardened/linux/uclibc/ppc [20] tmv3-target-overlay:cusfpv3 * cusfpv3 inherits default/linux/powerpc/ppc32/13.0 Jocke
Re: [gentoo-dev] Last rites: app-editors/emacs-vcs
> On Wed, 18 Dec 2019, Ulrich Mueller wrote: > # Ulrich Müller (2019-12-18) > # Live ebuilds for Emacs from Git have been consolidated > # into separate slots of the app-editors/emacs package. > # Please update your package.keywords file accordingly. Sorry, this should have read "package.accept_keywords". > # Masked for removal in 30 days. Bug #291296. > app-editors/emacs-vcs signature.asc Description: PGP signature
[gentoo-dev] Last rites: app-editors/emacs-vcs
# Ulrich Müller (2019-12-18) # Live ebuilds for Emacs from Git have been consolidated # into separate slots of the app-editors/emacs package. # Please update your package.keywords file accordingly. # Masked for removal in 30 days. Bug #291296. app-editors/emacs-vcs signature.asc Description: PGP signature
Re: [gentoo-dev] [PATCH 0/3] elisp{,-common}.eclass update for emacs-vcs consolidation
> On Wed, 18 Dec 2019, Michael Orlitzky wrote: >> No revbumps will be done for this (and virtual/emacs will be simply >> removed without prior masking). > I guess it's nice that we know ahead of time, but is there any reason > to suspect that this won't cause havoc? Removal of the virtual/emacs ebuilds won't remove the installed package from users' systems. It will eventually disappear, when all its reverse dependencies have been updated. Why would its continued presence as an installed package (for another while) cause any problems? Revbumping its more than 400 reverse dependencies really doesn't sound so attractive, and would cause rebuilds on users' systems for virtually (pun intended :-) no benefit. Ulrich signature.asc Description: PGP signature
Re: [gentoo-portage-dev] Build path abi missing in qemu-user
On Thu, Dec 12, 2019 at 10:18 AM Joakim Tjernlund wrote: > > When build in a qemu-user chroot I get odd build paths: > /var/tmp/portage/dev-libs/libxml2-2.9.9-r1/work/libxml2-2.9.9-.ppc > > This path is missing the abi_ppc_32 like so: > /var/tmp/portage/dev-libs/libxml2-2.9.9-r1/work/libxml2-2.9.9-abi_ppc_32.ppc > > I struggle to find out why this happens, any ideas? I would guess you are using a profile that doesn't define the ABI_PPC USE_EXPAND variable properly.
Re: [gentoo-dev] Output of ANSI escape sequences in ebuilds
On Sat, Dec 14, 2019 at 08:16:03AM +0100, Ulrich Mueller wrote:
> Some ebuilds output SGR control sequences (formerly known as ANSI escape
> sequences) to the terminal, i.e., they do things like:
>
> echo -e "\033[1m${@}\033[0m"
> einfo "Fetching \e[1m${r}\e[22m ..."
> ewarn "\033[1;33m**\033[00m"
> echo -ne "\a" # (not actually an ANSI escape sequence)
>
> These prevent NOCOLOR in make.conf or emerge --color=n from working
> correctly, and I guess they are also problematic from an accessibility
> point of view.
>
> Are there any objections against removing these sequences from strings?
> AFAICS, they are used by less than ten packages, and one eclass.
I just found another place that uses them very heavily. I don't know if
it is part of cargo.eclass, or if it is a bug in /usr/bin/ebuild, but
I'm working on an ebuild and found that if I run:
$ ebuild foobar.ebuild compile >& output
that output file is full of ansi sequences even though I have
NOCOLOR=yes in make.conf.
Thanks,
William
signature.asc
Description: Digital signature
Re: [gentoo-dev] [PATCH 0/3] elisp{,-common}.eclass update for emacs-vcs consolidation
On 12/18/19 6:08 AM, Ulrich Müller wrote: > No revbumps will be done for this (and virtual/emacs will be simply > removed without prior masking). I guess it's nice that we know ahead of time, but is there any reason to suspect that this won't cause havoc?
Re: [gentoo-dev] [PATCH 0/3] elisp{,-common}.eclass update for emacs-vcs consolidation
> On Wed, 18 Dec 2019, Michał Górny wrote: >> - Package mask app-editors/emacs-vcs (but not the virtual) for removal. > Maybe package.deprecated the virtual? Good idea. I have to get used to this. :-) signature.asc Description: PGP signature
Re: [gentoo-dev] [PATCH 0/3] elisp{,-common}.eclass update for emacs-vcs consolidation
Dnia December 18, 2019 11:08:16 AM UTC, "Ulrich Müller" napisał(a): >The package split between app-editors/emacs for regular ebuilds and >app-editors/emacs-vcs for live ebuilds has outlived its usefulness, and >it entails additional maintenance effort to keep the two packages >(e.g., >the list of their use flags in metadata.xml) synchronised. > >Therefore, consolidate all GNU Emacs ebuilds in a single package. Now >is >a good time to do this change, because no further releases of Emacs 26 >are to be expected, and the release cycle of Emacs 27 hasn't started >yet. > >So, the plan is: > >- Copy the live ebuilds into separate slots of app-editors/emacs >(done). > >- Update all reverse dependencies to depend on app-editors/emacs:* > directly, instead of virtual/emacs. Since we allow switching the > version with eselect, this includes a ":*" type slot dependency. > No revbumps will be done for this (and virtual/emacs will be simply > removed without prior masking). See patches 2 and 3 of this series. > >- This allows NEED_EMACS to be more fine-grained and include the minor > version. Therefore, elisp-need-emacs() from elisp-common.eclass > switches to ver_test() for version comparison, instead of comparing > the major version only. See patch 1 of this series. > >- Package mask app-editors/emacs-vcs (but not the virtual) for removal. Maybe package.deprecated the virtual? > >Ulrich Müller (3): > elisp-common.eclass: Allow full versions in elisp-need-emacs(). > elisp-common.eclass: Update documentation. > elisp.eclass: Depend on app-editors/emacs directly. > > eclass/elisp-common.eclass | 36 +++- > eclass/elisp.eclass| 4 ++-- > 2 files changed, 21 insertions(+), 19 deletions(-) -- Best regards, Michał Górny
[gentoo-dev] [PATCH 3/3] elisp.eclass: Depend on app-editors/emacs directly.
This replaces the indirect dependency on virtual/emacs.
Signed-off-by: Ulrich Müller
---
eclass/elisp.eclass | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/eclass/elisp.eclass b/eclass/elisp.eclass
index df160ea01e2..8f907bbb5d6 100644
--- a/eclass/elisp.eclass
+++ b/eclass/elisp.eclass
@@ -70,7 +70,7 @@ esac
EXPORT_FUNCTIONS src_{unpack,prepare,configure,compile,install} \
pkg_{setup,postinst,postrm}
-RDEPEND=">=virtual/emacs-${NEED_EMACS:-23}"
+RDEPEND=">=app-editors/emacs-${NEED_EMACS:-23.1}:*"
case ${EAPI} in
4|5|6) DEPEND="${RDEPEND}" ;;
*) BDEPEND="${RDEPEND}" ;;
@@ -82,7 +82,7 @@ esac
# version requirement of the NEED_EMACS variable.
elisp_pkg_setup() {
- elisp-need-emacs "${NEED_EMACS:-23}"
+ elisp-need-emacs "${NEED_EMACS:-23.1}"
case $? in
0) ;;
1) die "Emacs version too low" ;;
--
2.24.1
signature.asc
Description: PGP signature
[gentoo-dev] [PATCH 2/3] elisp-common.eclass: Update documentation.
After the package split between emacs and emacs-vcs is gone, packages
can depend on app-editors/emacs directly.
Signed-off-by: Ulrich Müller
---
eclass/elisp-common.eclass | 22 +-
1 file changed, 9 insertions(+), 13 deletions(-)
diff --git a/eclass/elisp-common.eclass b/eclass/elisp-common.eclass
index 6f79caee2f0..47e33ac28ae 100644
--- a/eclass/elisp-common.eclass
+++ b/eclass/elisp-common.eclass
@@ -24,26 +24,26 @@
# When relying on the emacs USE flag, you need to add
#
# @CODE
-# emacs? ( virtual/emacs )
+# emacs? ( app-editors/emacs:* )
# @CODE
#
# to your DEPEND/RDEPEND line and use the functions provided here to
# bring the files to the correct locations.
#
-# If your package requires a minimum Emacs version, e.g. Emacs 24, then
-# the dependency should be on >=virtual/emacs-24 instead. Because the
-# user can select the Emacs executable with eselect, you should also
-# make sure that the active Emacs version is sufficient. This can be
-# tested with function elisp-need-emacs(), which would typically be
-# called from pkg_setup(), as in the following example:
+# If your package requires a minimum Emacs version, e.g. Emacs 26.1,
+# then the dependency should be on >=app-editors/emacs-26.1:* instead.
+# Because the user can select the Emacs executable with eselect, you
+# should also make sure that the active Emacs version is sufficient.
+# This can be tested with function elisp-need-emacs(), which would
+# typically be called from pkg_setup(), as in the following example:
#
# @CODE
-# elisp-need-emacs 24 || die "Emacs version too low"
+# elisp-need-emacs 26.1 || die "Emacs version too low"
# @CODE
#
# Please note that such tests should be limited to packages that are
# known to fail with lower Emacs versions; the standard case is to
-# depend on virtual/emacs without version.
+# depend on app-editors/emacs without version.
#
# @ROFF .SS
# src_compile() usage:
@@ -152,10 +152,6 @@
#
# When having optional Emacs support, you should prepend "use emacs &&"
# to above calls of elisp-site-regen().
-# Don't use "has_version virtual/emacs"! When unmerging the state of
-# the emacs USE flag is taken from the package database and not from the
-# environment, so it is no problem when you unset USE=emacs between
-# merge and unmerge of a package.
case ${EAPI:-0} in
4|5|6) inherit eapi7-ver ;;
--
2.24.1
signature.asc
Description: PGP signature
[gentoo-dev] [PATCH 1/3] elisp-common.eclass: Allow full versions in elisp-need-emacs().
To this end, replace the simple numeric comparison of the first
component by a call to ver_test.
Signed-off-by: Ulrich Müller
---
eclass/elisp-common.eclass | 14 ++
1 file changed, 10 insertions(+), 4 deletions(-)
diff --git a/eclass/elisp-common.eclass b/eclass/elisp-common.eclass
index 79f29ef95ad..6f79caee2f0 100644
--- a/eclass/elisp-common.eclass
+++ b/eclass/elisp-common.eclass
@@ -158,7 +158,8 @@
# merge and unmerge of a package.
case ${EAPI:-0} in
- 4|5|6|7) ;;
+ 4|5|6) inherit eapi7-ver ;;
+ 7) ;;
*) die "${ECLASS}: EAPI ${EAPI:-0} not supported" ;;
esac
@@ -230,11 +231,16 @@ elisp-need-emacs() {
have_emacs=$(elisp-emacs-version) || return 2
einfo "Emacs version: ${have_emacs}"
if [[ ${have_emacs} =~ XEmacs|Lucid ]]; then
- eerror "This package needs GNU Emacs."
+ eerror "XEmacs detected. This package needs GNU Emacs."
return 1
fi
- if ! [[ ${have_emacs%%.*} -ge ${need_emacs%%.*} ]]; then
- eerror "This package needs at least Emacs ${need_emacs%%.*}."
+ # GNU Emacs versions have only numeric components.
+ if ! [[ ${have_emacs} =~ ^[0-9]+(\.[0-9]+)*$ ]]; then
+ eerror "Malformed version string: ${have_emacs}"
+ return 2
+ fi
+ if ! ver_test "${have_emacs}" -ge "${need_emacs}"; then
+ eerror "This package needs at least Emacs ${need_emacs}."
eerror "Use \"eselect emacs\" to select the active version."
return 1
fi
--
2.24.1
signature.asc
Description: PGP signature
[gentoo-dev] [PATCH 0/3] elisp{,-common}.eclass update for emacs-vcs consolidation
The package split between app-editors/emacs for regular ebuilds and app-editors/emacs-vcs for live ebuilds has outlived its usefulness, and it entails additional maintenance effort to keep the two packages (e.g., the list of their use flags in metadata.xml) synchronised. Therefore, consolidate all GNU Emacs ebuilds in a single package. Now is a good time to do this change, because no further releases of Emacs 26 are to be expected, and the release cycle of Emacs 27 hasn't started yet. So, the plan is: - Copy the live ebuilds into separate slots of app-editors/emacs (done). - Update all reverse dependencies to depend on app-editors/emacs:* directly, instead of virtual/emacs. Since we allow switching the version with eselect, this includes a ":*" type slot dependency. No revbumps will be done for this (and virtual/emacs will be simply removed without prior masking). See patches 2 and 3 of this series. - This allows NEED_EMACS to be more fine-grained and include the minor version. Therefore, elisp-need-emacs() from elisp-common.eclass switches to ver_test() for version comparison, instead of comparing the major version only. See patch 1 of this series. - Package mask app-editors/emacs-vcs (but not the virtual) for removal. Ulrich Müller (3): elisp-common.eclass: Allow full versions in elisp-need-emacs(). elisp-common.eclass: Update documentation. elisp.eclass: Depend on app-editors/emacs directly. eclass/elisp-common.eclass | 36 +++- eclass/elisp.eclass| 4 ++-- 2 files changed, 21 insertions(+), 19 deletions(-) -- 2.24.1 signature.asc Description: PGP signature
Re: [gentoo-dev] RFC: Introducing VIDEO_CARDS=iris to virtual/opencl
Hi, As someone with a Radeon / Intel hybrid/dual graphics chip. I can only emphasise what Matt says below. It's a PITA currently. Having said that ... I don't see how this can be made simpler, unless we have a tool of sorts that when run on *any* hardware gives you what this needs to be set to, or unconditionally install all possible drivers (something I'd prefer to avoid completely). Kind Regards, Jaco On 2019/12/17 23:21, Matt Turner wrote: > 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. >
