Re: [gentoo-dev] Last Rites: Ancient x11-drivers/*
W dniu pią, 24.11.2017 o godzinie 18∶02 -0800, użytkownik Matt Turner napisał: > On Thu, Nov 23, 2017 at 10:52 PM, Richard Bradfield wrote: > > On Thu, Nov 23, 2017 at 11:24:24PM -0800, Matt Turner wrote: > > > > > > Very few if any users. They break occasionally with new xserver > > > versions, and then I have to do the leg work to fix them, make the > > > upstream releases, and then push them into Gentoo. Again, for between > > > zero and one person to use. > > > ... > > > x11-drivers/xf86-video-modesetting > > > > > > I guess I should put my hand up and admit to being "the one user" for > > this driver. I've got an ancient netbook with an Intel GMA3600, for > > which there is no accelerated Xorg driver, which means I'm stuck with > > xf86-video-modesetting. > > You must not have updated in quite a while if it's still installed on > your system. The driver has been included in the xserver since 1.17 > (with the appropriate blocker). > > The driver's not going away, just the separate package :) You should probably update the p.mask message to make that clear. Possibly maybe even split this driver (and any other that is not necessary) to a separate mask. -- Best regards, Michał Górny
Re: [gentoo-dev] Last Rites: Ancient x11-drivers/*
On Fri, Nov 24, 2017 at 06:02:12PM -0800, Matt Turner wrote: On Thu, Nov 23, 2017 at 10:52 PM, Richard Bradfield wrote: On Thu, Nov 23, 2017 at 11:24:24PM -0800, Matt Turner wrote: Very few if any users. They break occasionally with new xserver versions, and then I have to do the leg work to fix them, make the upstream releases, and then push them into Gentoo. Again, for between zero and one person to use. ... x11-drivers/xf86-video-modesetting I guess I should put my hand up and admit to being "the one user" for this driver. I've got an ancient netbook with an Intel GMA3600, for which there is no accelerated Xorg driver, which means I'm stuck with xf86-video-modesetting. You must not have updated in quite a while if it's still installed on your system. The driver has been included in the xserver since 1.17 (with the appropriate blocker). The driver's not going away, just the separate package :) You would be correct! Have you any idea how enjoyable `emerge --update` is on an Atom N2600? :) I've gone ahead and updated the machine to Xorg 1.19.5, and depclean removed the old separate package, thanks for the hint! signature.asc Description: PGP signature
Re: [gentoo-dev] Packages up for grabs
Am Dienstag, 21. November 2017, 22:01:01 CET schrieb Manuel Rüger: > Packages up for grabs: > [...] > * app-shells/thefuck > [...] I think this tool is...magnificent and therefore I’ll proxy maintain it. -- GPG fingerprint: '00EF D31F 1B60 D5DB ADB8 31C1 C0EC E696 0E54 475B' Nils Freydank signature.asc Description: This is a digitally signed message part.
[gentoo-dev] Patch for toolchain.eclass for uclibc-ng
-- Anthony G. Basile, Ph.D. Gentoo Linux Developer [Hardened] E-Mail: bluen...@gentoo.org GnuPG FP : 1FED FAD9 D82C 52A5 3BAB DC79 9384 FA6E F52D 4BBA GnuPG ID : F52D4BBA From 909298f47c98f698923c834f67e53bed3bc6ab25 Mon Sep 17 00:00:00 2001 From: "Anthony G. Basile" Date: Sat, 25 Nov 2017 08:47:41 -0500 Subject: [PATCH] eclass/toolchain.eclass: do not die if uclibc patches are not available gcc-6 and above no longer needs uclibc specific patches, so we don't die if the patchset is not available. We do, however, still apply it if UCLIBC_VER is defined in the ebuild to future proof the code in case we need to reintroduce the patchset in the future. --- eclass/toolchain.eclass | 3 --- 1 file changed, 3 deletions(-) diff --git a/eclass/toolchain.eclass b/eclass/toolchain.eclass index 503f7dbe94f..58d859dfaf3 100644 --- a/eclass/toolchain.eclass +++ b/eclass/toolchain.eclass @@ -378,9 +378,6 @@ toolchain_pkg_pretend() { "in your make.conf if you want to use this version." fi - [[ -z ${UCLIBC_VER} ]] && [[ ${CTARGET} == *-uclibc* ]] && \ - die "Sorry, this version does not support uClibc" - if ! use_if_iuse cxx ; then use_if_iuse go && ewarn 'Go requires a C++ compiler, disabled due to USE="-cxx"' use_if_iuse objc++ && ewarn 'Obj-C++ requires a C++ compiler, disabled due to USE="-cxx"' -- 2.13.6
[gentoo-dev] Patch for toolchain.eclass for uclibc-ng
Hi everyone, With the stabilization of gcc-6.4.0, the uclibc build broke because the eclass requires UCLIBC_VER to be define on uclibc systems else it will die(). Since uclibc specific patches are no longer needed in gcc-6 and above, we don't want to error out in the eclass when the patchset is not found. Note that there are some musl specific patches which I would like to migrate out of the overlay and into the tree. In a future patch, I'd like to duplicate the uclibc code for musl in toolchain.eclass. Feedback welcome. -- Anthony G. Basile, Ph.D. Gentoo Linux Developer [Hardened] E-Mail: bluen...@gentoo.org GnuPG FP : 1FED FAD9 D82C 52A5 3BAB DC79 9384 FA6E F52D 4BBA GnuPG ID : F52D4BBA From 909298f47c98f698923c834f67e53bed3bc6ab25 Mon Sep 17 00:00:00 2001 From: "Anthony G. Basile" Date: Sat, 25 Nov 2017 08:47:41 -0500 Subject: [PATCH] eclass/toolchain.eclass: do not die if uclibc patches are not available gcc-6 and above no longer needs uclibc specific patches, so we don't die if the patchset is not available. We do, however, still apply it if UCLIBC_VER is defined in the ebuild to future proof the code in case we need to reintroduce the patchset in the future. --- eclass/toolchain.eclass | 3 --- 1 file changed, 3 deletions(-) diff --git a/eclass/toolchain.eclass b/eclass/toolchain.eclass index 503f7dbe94f..58d859dfaf3 100644 --- a/eclass/toolchain.eclass +++ b/eclass/toolchain.eclass @@ -378,9 +378,6 @@ toolchain_pkg_pretend() { "in your make.conf if you want to use this version." fi - [[ -z ${UCLIBC_VER} ]] && [[ ${CTARGET} == *-uclibc* ]] && \ - die "Sorry, this version does not support uClibc" - if ! use_if_iuse cxx ; then use_if_iuse go && ewarn 'Go requires a C++ compiler, disabled due to USE="-cxx"' use_if_iuse objc++ && ewarn 'Obj-C++ requires a C++ compiler, disabled due to USE="-cxx"' -- 2.13.6
Re: [gentoo-dev] Last Rites: Ancient x11-drivers/*
On Sat, Nov 25, 2017 at 12:05 AM, Michał Górny wrote: > W dniu pią, 24.11.2017 o godzinie 18∶02 -0800, użytkownik Matt Turner > napisał: >> On Thu, Nov 23, 2017 at 10:52 PM, Richard Bradfield >> wrote: >> > On Thu, Nov 23, 2017 at 11:24:24PM -0800, Matt Turner wrote: >> > > >> > > Very few if any users. They break occasionally with new xserver >> > > versions, and then I have to do the leg work to fix them, make the >> > > upstream releases, and then push them into Gentoo. Again, for between >> > > zero and one person to use. >> > > ... >> > > x11-drivers/xf86-video-modesetting >> > >> > >> > I guess I should put my hand up and admit to being "the one user" for >> > this driver. I've got an ancient netbook with an Intel GMA3600, for >> > which there is no accelerated Xorg driver, which means I'm stuck with >> > xf86-video-modesetting. >> >> You must not have updated in quite a while if it's still installed on >> your system. The driver has been included in the xserver since 1.17 >> (with the appropriate blocker). >> >> The driver's not going away, just the separate package :) > > You should probably update the p.mask message to make that clear. > Possibly maybe even split this driver (and any other that is not > necessary) to a separate mask. Will do. I didn't expect there was anyone with it still installed on their system, since it hasn't been separately installable since I think 1.17 has been stable since before the transition to git :)
[gentoo-dev] Initial tests for full-tree Manifest verification (MetaManifest)
Hi, everyone. Last night Infra has started deploying the initial version of full-tree Manifest coverage (MetaManifest) on rsync mirrors. While things are not yet fully settled down, we think it is ready for the initial public testing. The Manifest format is based on GLEP 74 [1] draft. Its earlier version has been pre-approved by Council for testing on 20171112 [2] meeting. Please note that the format may still be subject to changes, and you should not rely on it or a fully defined behavior of the tooling. Along with the change, we have also made some changes to the git->rsync pipeline and switched the local Manifest hashes to BLAKE2B + SHA512. Users will experience a one-time resync of all package Manifests. Afterwards, only relevant package Manifests and their parent Manifests should be updating. The package Manifests remain compatible with the existing format and are still verified using the existing tooling. However, performing a full-tree verification at the moment requires using the external app-portage/gemato [3] tool. The work on Portage integration is planned to start after some initial testing. To verify the repository after updating from rsync: $ gemato verify "$(portageq get_repo_path / gentoo)" If you experience any problems with rsync or the verification process, please let us know. Git mirror users are not affected. The git repository is still verified against the git commit signatures. [1]:https://www.gentoo.org/glep/glep-0074.html [2]:https://projects.gentoo.org/council/meeting-logs/20171112-summary.txt [3]:https://github.com/mgorny/gemato -- Best regards, Michał Górny
Re: [gentoo-dev] Initial tests for full-tree Manifest verification (MetaManifest)
On 25/11/17 22:05, Michał Górny wrote: > Hi, everyone. > > Last night Infra has started deploying the initial version of full-tree > Manifest coverage (MetaManifest) on rsync mirrors. While things are not > yet fully settled down, we think it is ready for the initial public > testing. Thanks to all involved developers for pushing this forward. I can just roughly imagine how many hours, mails, discussions on IRC and nerves had been required for this. Best, -- Jonas signature.asc Description: OpenPGP digital signature
[gentoo-dev] Last rites: dev-tex/notoccite
# Jonas Stein (25 Nov 2017) # The latest version of this LaTeX package is part of # dev-texlive/texlive-latexextra # Masked for removal on 2017-12-30 dev-tex/notoccite -- Best regards, Jonas Stein signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: [RFC, PATCH] user.eclass: gracefully return when unprivileged
Hi Patrick, Patrick McLean writes: > I use portage as non-root all the time when developing and testing > ebuilds, via the "ebuild" command. The enewgroup and enewuser are used in pkg_* functions, as documented in user.eclass _assert_pkg_ebuild_phase() function. They require root to execute. So no worries, your workflow will not be affected. Yours, Benda
Re: [gentoo-dev] [RFC, PATCH] db.eclass: support Prefix
Committed, thanks a lot! Benda
Re: [gentoo-dev] Re: [RFC, PATCH] user.eclass: gracefully return when unprivileged
Fabian Groffen writes: > I think we could definitely live with this until someone requests > otherwise. Indeed. Committed, thanks a lot! Benda signature.asc Description: PGP signature
[gentoo-dev] Last Rites: Unmaintained x11-drivers/xf86-input-* drivers
Unmaintained upstream since 2011. Likely zero users. Masked for removal in 30 days. Bug: https://bugs.gentoo.org/606132 x11-drivers/xf86-input-acecad x11-drivers/xf86-input-aiptek x11-drivers/xf86-input-fpit x11-drivers/xf86-input-hyperpen x11-drivers/xf86-input-mutouch x11-drivers/xf86-input-pentouch signature.asc Description: Digital signature