Re: [gentoo-dev] Re: cmake + ninja vs autotools
Martin Vaeth wrote: > > 1. Doing a full clean build [..] the speed of make or ninja is hugely > > offset by the compilation speed, and their overhead is negligible. > > It depends on the definition of negligible. For huge projects like > boost or chromium it is several minutes It's arguably a bug that a projects gets huge. The simplicity of configure+make is difficult to beat, but I also agree that it's difficult or at least tedious to master autotools. That is arguably reason enough to choose meson, but I think I will stay with autotools for a while.. //Peter
[gentoo-dev] Last rites: net-analyzer/aimsniff
# Jonas Stein (23 Nov 2017) # Depends on the AIM service which will be discontinued on 2017-12-15. # See also bug #638564. Masked for removal on 2017-12-20 net-analyzer/aimsniff -- Best regards, Jonas Stein signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] GLEP 74 post-Council review update [v5]
W dniu czw, 16.11.2017 o godzinie 11∶19 +0100, użytkownik Michał Górny napisał: > Hi, everyone. > > Here's the updated version of GLEP 74 taking into consideration > the points made during the Council pre-review. > > ReST: https://dev.gentoo.org/~mgorny/tmp/glep-0074.rst > HTML: https://dev.gentoo.org/~mgorny/tmp/glep-0074.html > > Changes: 27c2a9e glep-0074: Grammar corrections from Ulrich Müller d39f865 glep-0074: Make extended filename encoding optional ed111f8 glep-0074: Always exclude control characters --- GLEP: 74 Title: Full-tree verification using Manifest files Author: Michał Górny , Robin Hugh Johnson , Ulrich Müller Type: Standards Track Status: Draft Version: 1 Created: 2017-10-21 Last-Modified: 2017-11-23 Post-History: 2017-10-26, 2017-11-16 Content-Type: text/x-rst Requires: 59, 61 Replaces: 44, 58, 60 --- Abstract This GLEP extends the Manifest file format to cover full-tree file integrity and authenticity checks. The format aims to be future-proof, efficient and provide means of backwards compatibility. Motivation == The Manifest files as defined by GLEP 44 [#GLEP44]_ provide the current means of verifying the integrity of distfiles and package files in Gentoo. Combined with OpenPGP signatures, they provide means to ensure the authenticity of the covered files. However, as noted in GLEP 57 [#GLEP57]_ they lack the ability to provide full-tree authenticity verification as they do not cover any files outside the package directory. In particular, they provide multiple ways for a third party to inject malicious code into the ebuild environment. Historically, the topic of providing authenticity coverage for the whole repository has been mentioned multiple times. The most noteworthy effort are GLEPs 58 [#GLEP58]_ and 60 [#GLEP60]_ by Robin H. Johnson from 2008. They were accepted by the Council in 2010 but have never been implemented. When potential implementation work started in 2017, a new discussion about the specification arose. It prompted the creation of a competing GLEP that would provide a redesigned alternative to the old GLEPs. This specification is designed with the following goals in mind: 1. It should provide means to ensure the authenticity of the complete repository, including preventing the injection of additional files. 2. The format should be universal enough to work both for the Gentoo repository and third-party repositories of different characteristics. 3. The Manifest files should be verifiable stand-alone, that is without knowing any details about the underlying repository format. Specification = Manifest file format This specification reuses and extends the Manifest file format defined in GLEP 44 [#GLEP44]_. For the purpose of it, the *file type* field is repurposed as a generic *tag* that could also indicate additional (non-checksum) metadata. Appropriately, those tags can be followed by other space-separated values. Unless specified otherwise, the paths used in the Manifest files are relative to the directory containing the Manifest file. The paths must not reference the parent directory (``..``). Forward slash (``/``) is used as path component separator. The Manifest files use UTF-8 encoding. Manifest file locations and nesting --- The ``Manifest`` file located in the root directory of the repository is called top-level Manifest, and it is used to perform the full-tree verification. In order to verify the authenticity, it must be signed using OpenPGP, using the armored cleartext format. The top-level Manifest may reference sub-Manifests contained in subdirectories of the repository. The sub-Manifests are traditionally named ``Manifest``; however, the implementation must support arbitrary names, including the possibility of multiple (split) Manifests for a single directory. The sub-Manifest can only cover the files inside the directory tree where it resides. The sub-Manifest can also be signed using OpenPGP armored cleartext format. However, the signature verification can be omitted since it already is covered by the signed top-level Manifest. Directory tree coverage --- The specification provides three ways of skipping Manifest verification of specific files and directories (recursively): 1. explicit ``IGNORE`` entries in Manifest files, 2. injected ignore paths via package manager configuration, 3. using names starting with a dot (``.``) which are always skipped. All files that are not ignored must be covered by at least one of the Manifests. A single file may be matched by multiple identical or equivalent Manifest entries, if and only if the entries have the same semantics, specify the same size and the checksums common to both entries match. It is an error for a single file to be matched by multiple entries of different semantics, file size or checksum values. It is an error to specify another entry for a fi
[gentoo-dev] Last Rites: Ancient x11-drivers/*
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. I left some other ancient ones that are also candidates for removal, but I thought might have *a* user: glint, mach64, mga, r128, tdfx, voodoo. Masked for removal in 30 days. Bug: https://bugs.gentoo.org/606132 x11-misc/afbinit x11-drivers/afb-ucode x11-drivers/xf86-video-apm x11-drivers/xf86-video-ark x11-drivers/xf86-video-chips x11-drivers/xf86-video-cirrus x11-drivers/xf86-video-freedreno x11-drivers/xf86-video-i128 x11-drivers/xf86-video-i740 x11-drivers/xf86-video-mach64 x11-drivers/xf86-video-modesetting x11-drivers/xf86-video-neomagic x11-drivers/xf86-video-opentegra x11-drivers/xf86-video-rendition x11-drivers/xf86-video-s3 x11-drivers/xf86-video-s3virge x11-drivers/xf86-video-savage x11-drivers/xf86-video-sis x11-drivers/xf86-video-sisusb x11-drivers/xf86-video-suncg14 x11-drivers/xf86-video-suncg3 x11-drivers/xf86-video-suncg6 x11-drivers/xf86-video-sunffb x11-drivers/xf86-video-sunleo x11-drivers/xf86-video-suntcx x11-drivers/xf86-video-tga x11-drivers/xf86-video-trident x11-drivers/xf86-video-tseng signature.asc Description: Digital signature
Re: [gentoo-dev] Last Rites: Ancient x11-drivers/*
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. Obviously not asking you to keep putting in effort just for me, so what are my next steps if this package is masked and I later need to update? signature.asc Description: PGP signature
Re: [gentoo-dev] Last Rites: Ancient x11-drivers/*
On Fri, 24 Nov 2017 06:52:59 +
Richard Bradfield wrote:
> 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.
>
> Obviously not asking you to keep putting in effort just for me, so what
> are my next steps if this package is masked and I later need to update?
I believe this driver now comes with xorg-server regardless, and so to
use xorg-server-1.19.5, you just have to remove the legacy split
modesetting drivers first.
xorg-server-1.19.5:
RDEPEND="${CDEPEND}
selinux? ( sec-policy/selinux-xserver )
!x11-drivers/xf86-video-modesetting
"
qlist xorg-server | grep -i modeset
/usr/lib64/xorg/modules/drivers/modesetting_drv.so
/usr/share/man/man4/modesetting.4.bz2
pgp6G_sRBYdYM.pgp
Description: OpenPGP digital signature
Re: [gentoo-dev] Last Rites: Ancient x11-drivers/*
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. > > I left some other ancient ones that are also candidates for removal, but > I thought might have *a* user: glint, mach64, mga, r128, tdfx, voodoo. Both mga & r128 still have life as drivers for embedded controllers on server systems. MGA on ~5 year old Dell servers, R128 in the RageXL variant on similar age Supermicro servers. > x11-drivers/xf86-video-modesetting Please keep this one for the generic KMS case. It's been useful. > x11-drivers/xf86-video-tseng Yep, had a few of these cards, 25 years ago. The hardware interface was nice and clean, but they can DIAF now. tdfx/voodoo: Kill with fire, also spent time programming them, but looking at 15/20-year old video hardware with no big-endian support. Doubtful of userbase. -- Robin Hugh Johnson Gentoo Linux: Dev, Infra Lead, Foundation Asst. Treasurer E-Mail : robb...@gentoo.org GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85 GnuPG FP : 7D0B3CEB E9B85B1F 825BCECF EE05E6F6 A48F6136 signature.asc Description: Digital signature
