Re: [gentoo-dev] Are users forced to use PAM?

Am 05. Oct 2014, 15:20 schrieb Diego Elio Pettenò flamee...@flameeyes.eu: Simple as this: -pam is not by default tested and you keep the pieces if it breaks. Upstream bug is at [1]. According to comment 1 also upstream does not seem to test non-pam use cases all that often. I have the

Re: [gentoo-dev] status of bugs blocking gcc-4.8.3

Not sure if the llvm C++ runtime might help here or it is any better than the one provided by gnu, but might be a good time to gather volunteers to provide a mean to use clang as main compiler out of box. libc++ makes stricter ABI guarantees [1]. But from personal experience I would not

[gentoo-dev] Clang toolchain [Was: status of bugs blocking gcc-4.8.3]

Could you please blog or add some notes to the wiki about it? I've put up a preliminary version for the toolchain part: https://gist.github.com/tamiko/7e3a0be806fac11f2a35 Best, Matthias

Re: [gentoo-dev] Clang toolchain [Was: status of bugs blocking gcc-4.8.3]

Am 27. Oct 2014, 11:14 schrieb Alexis Ballier aball...@gentoo.org: By the way, any help for maintaining the libc++ stack is very welcome; as you can see from the age of the current snapshots, it's been some time I've not been playing with it. Some notes: - why not adding a clang

Re: [gentoo-dev] Clang toolchain [Was: status of bugs blocking gcc-4.8.3]

Am 27. Oct 2014, 12:07 schrieb M. Ziebell ziebell_ma...@posteo.de: Does clang compile glibc already? At the last GNU Cauldron the speaker said that clang fails because of:[1] - nested functions - VLAIS How did you avoid that problem? Even without this issues there remains the fact that

Re: [gentoo-dev] Clang toolchain

- libcxxabi is probably the new way to go instead of libcxxrt; last time I checked there was a chicken and egg problem: libcxxabi needed clang + libc++ to build, so bootstrapping the stack was a bit painful. I give libcxxabi a try. Does anybody has a bit insight in the current status

Re: [gentoo-dev] terminal spreadsheet - sc fork

Am 03. Nov 2014, 00:24 schrieb Andrés Martinelli andma...@gmail.com: I am working on a terminal spreadsheet based on sc, but with some adds like undo/redo.. you can find it here: https://github.com/andmarti1424/scim Any new ideas and/or contribution is always welcome! Just out of

[gentoo-dev] last-rites: app-emulation/virtinst

# Matthias Maier tam...@gentoo.org (4 Nov 2014) # Masked for removal in 30 days. The package has multiple open bugs # (bug #482472, bug #501818, bug #528190) and is superseded by # app-emulation/virt-manager[-gtk] app-emulation/virtinst

Re: [gentoo-dev] Portage dependency solving algorithm

Am 07. Nov 2014, 19:30 schrieb Ciaran McCreesh ciaran.mccre...@googlemail.com: On Fri, 07 Nov 2014 19:11:04 +0100 Jauhien Piatlicki jauh...@gentoo.org wrote: Then the same question for you: where can one read about the algorithm Paludis uses? It's basically a two stage process: simple

Re: [gentoo-dev] Portage dependency solving algorithm

Am 07. Nov 2014, 20:21 schrieb Ciaran McCreesh ciaran.mccre...@googlemail.com: On Fri, 07 Nov 2014 19:54:08 +0100 Matthias Maier tam...@gentoo.org wrote: Currently, for portage just to decide that nothing has to be done on my machine takes around 1 minute. Are you running with or without

Re: [gentoo-dev] fixed my virt-manager issue; libvirt-python-9999.ebuild

I've commited a live ebuild for libvirt-python to CVS. Given the fact that we already have one for libvirt and one for virt-manager, this makes sense. Best, Matthias *libvirt-python- (08 Nov 2014) 08 Nov 2014; Matthias Maier tam...@gentoo.org +libvirt-python-.ebuild: provide live

Re: [gentoo-dev] Packages up for grabs

Am 11. Nov 2014, 15:59 schrieb Pavlos Ratis daster...@gentoo.org: * dev-vcs/mr I can take care of this one - I use dev-vcs/mr quite heavily. Best, Matthias

Re: [gentoo-dev] Packages up for grabs

* dev-vcs/mr * dev-vcs/vcsh On second thought, I think, I'll adapt both of them. :-) Best, Matthias

[gentoo-dev] Last rites: Various mate 1.6 related packages

As we have a stable mate 1.8 desktop and mate 1.6 related packages start to pick up a bunch of outstanding issues, I've remove all 1.6 version for mate packages from the tree. The following list contains mate-1.6-only packages that will be removed: # Matthias Maier tam...@gentoo.org (20 Dec 2014

Re: [gentoo-dev] rfc: glibc versions prior to 2.19-r1

IMHO, maintaining a sensible set of old glibc versions of the last 5 years makes sense, and we should try to support it: +1 from me. I cannot think of any scenario where we need to keep such old glibc versions around. One scenario is to create a cross-compile toolchain with specific old

Re: [gentoo-dev] rfc: glibc versions prior to 2.19-r1

+1 for an archive overlay This sounds like a reasonable compromise. For the toolchain.eclass problem you mentioned. We could just version the eclass as needed, something like toolchain-crossdev-vX.eclass. With this development on the main repository is independent and we would still have old

Re: [gentoo-dev] rfc: glibc versions prior to 2.19-r1

I'm a bit surprised about this discussion as Mike, who currently maintains the toolchain, has never implied that suddenly older versions of glibc are unusable. Or that we need a big cleanup. He simply stated two facts (that have been true for a long time) - for a current kernel a current

Re: [gentoo-dev] rfc: glibc versions prior to 2.19-r1

Am 23. Dec 2014, 16:51 schrieb William Hubbs willi...@gentoo.org: just the simple fact that crossdev without the ability to select specific versions of glibc is only half as useful. And please, do not underestimate the usefulness of our crossdev script in this regard! I'm not saying

Re: [gentoo-dev] debootstrap equivalent for Gentoo?

I'm wondering if there is an equivalent of debootstrap of Debian anywhere. By equivalent I mean a tool that .. Given the fact that such a tool only has to handle 3 files (tarball, digest + signature file) I guess there was never much need for such a thing. * I can run like command FOLDER

Re: [gentoo-dev] [RFC] New ebuild metadata variables for filtering of binary package soname dependencies (analogous to Fedora __provides_exclude and __requires_exclude)

Am 29. Dec 2014, 09:46 schrieb Zac Medico zmed...@gentoo.org: In order to implement something like this for Gentoo, we could add PROVIDES_EXCLUDE and REQUIRES_EXCLUDE ebuild metadata variables. These variables would be used to automatically generate PROVIDES and REQUIRES data for binary

Re: [gentoo-dev] [RFC] New ebuild metadata variables for filtering of binary package soname dependencies (analogous to Fedora __provides_exclude and __requires_exclude)

Thanks for the detailed explanation. Best, Matthias

Re: [gentoo-dev] ffmpeg vs libav choice of default

So can someone please remind me what are the technical reasons why we prefer libav over ffmpeg? *ugh* Please no. What about leaving the default (if there ever was such a default) as it is and avoid the otherwise imminent trainwreck? Best, Matthias signature.asc Description: PGP signature

Re: [gentoo-dev] RFC: USE=libav as replacement for broken || ( libav:= ffmpeg:= )

Any comments? Sounds good!

Re: [gentoo-dev] Re: maintainer-needed@ packages need you!

Am 09. Jan 2015, 23:42 schrieb Diamond diam...@hi-net.ru: [...] (that's why I used all that LXC and separate X server precautions). Can you give any reference about how to isolate Skype properly using LXC? I'm also interested in the separate X server part =)

Re: [gentoo-dev] Maintainer stabilizations

I'm going to write a devmanual patch but don't want to sound like a lunatic. Also, an informal definition on what is supposed to be appropriate hardware and userland (e.g. clean amd64 profile) and what are keywording best practices would be nice to have. (Alternatively a link to the

Re: [gentoo-dev] rfc: add-on files handling improvements

Thoughts? One point in favor of the current practice (installing add-on files unconditionally) is the fact that you can basically do it for free - you neither have to depend on additional packages, nor is the presence of the add-on files a penalty in download time or storage. Further, a lot of

Re: [gentoo-dev] RFC: c++14 global USE flag

gcc upstream has at least unified the C++98(03) and C++11 abis in gcc-5 [1] and declared the C++11 abi stable. This could resolve [2] in the near future.. Best, Matthias [1] https://gcc.gnu.org/onlinedocs/libstdc++/manual/using_dual_abi.html [2] https://bugs.gentoo.org/show_bug.cgi?id=542482

[gentoo-dev] Packages up for grabs

Just a bunch of packages I'm no longer interested in (and that are hardly useful to begin with...): app-misc/grabcartoons sys-apps/conspy sys-fs/safecopy Best, Matthias signature.asc Description: PGP signature

Re: [gentoo-dev] Re: rsync mirror security

constantly adds any security to the tree. What might add security for end-users is if git automatically checked the push signatures, which are the signatures that ensure that branches aren't tampered with (which is what rebasing you bring up actually does). It is news to me that a signature

Re: [gentoo-dev] Infra plans regarding $Id$ - official answer...

They will be OpenPGP signed by a releng key during thickening and portage will auto-verify it using gkeys once things are in place. As such checksum for ebuilds and other files certainly needs to be part of the manifest, otherwise it can open up for malicious alterations of these files. And

[gentoo-dev] Re: rsync mirror security

Users can fetch/pull from Github. We could also provide automatic signed tags every 30min/1h/2h/whatever (signed with a suitable infrastructure key). With that, the integrity of a tagged git checkout can be easily verified on client side. Best, Matthias signature.asc Description: PGP

Re: [gentoo-dev] Re: rsync mirror security

That is, I was under the impression signing a tag only signs the references themselves, and then relies on SHA1 referential integrity beyond that. No, a signed tag verifies that the whole integrirty of the entire repository, whereas a signed commit only authenticates the differences introduced

Re: [gentoo-dev] Re: rsync mirror security

it would have to re-use the same tag name every time otherwise we end up with 17.5k/8.7k/4.3k/whatever new tags per year ... a really bad idea Or we supply a signature of the sha1-sum of the tag in question by some external procedure... Best, Matthias signature.asc Description: PGP

Re: [gentoo-dev] Re: rsync mirror security

On Mon, Aug 10, 2015, at 22:56 CDT, Kent Fredric kentfred...@gmail.com wrote: So how is GPG verifying The whole repository ? You can verify the state of the repository via $ git fsck after that you can verify that the current HEAD is tagged with a valid and singed tag with something like

Re: [gentoo-dev] Re: Referencing bug reports in git

On Fri, Aug 14, 2015, at 15:04 CDT, Andrew Savchenko birc...@gentoo.org wrote: On Thu, 13 Aug 2015 19:19:10 +0800 Ben de Groot wrote: I vote for a simple Bug: 333531 +1 Of course, for external bugs (e.g. in other projects) full URI should be used. +1 signature.asc Description: PGP

Re: [gentoo-dev] Is the $Id$ line in our ebuilds still useful?

This expansion doesn't take place under git, so now I don't understand the usefulness of this line. If I have missed something, can someone fill me in, or if it isn't useful any more can we consider removing it? It is possible to define custom keyword expansions for $Id$ with .gitattributes

Re: [gentoo-dev] Revise EAPI 6?

On Wed, Nov 11, 2015, at 15:52 CST, "Jason A. Donenfeld" wrote: > I'd be in favor of full-on LC_ALL=C. ++ I'm surprised that we do not have such a policy already. Best, Matthias

Re: [gentoo-dev] [RFC/announcement] Reviewers project

Just a comment before this discussion gets entirely side tracked. On Mon, Oct 12, 2015, at 11:45 CDT, Ian Delaney wrote: > [...] > Users are neither seasoned nor prepared for the type of review put > upon them by him and mgorny. My impression is that the reception of

Re: [gentoo-dev] news item: libvirt-1.2.19 init script upgrades

Cardoe's second mail didn't make it to the list. Please find attached the second mail and the updated news announcement. = On 9/9/15 9:17 AM, Doug Goldstein wrote: > The following is the proposed news item to inform OpenRC users of a > change to the init script setup for libvirt 1.2.19 and

[gentoo-dev] Last rites: media-plugins/quodlibet-plugins

# Matthias Maier <tam...@gentoo.org> (06 Jan 2016) # Obsolete package, nowadays bundled with media-sound/quodlibet # Masked for removal in 30 days media-plugins/quodlibet-plugins signature.asc Description: PGP signature

Re: [gentoo-dev] USE=desktop-file request

> I'd have to check but I suspect that portage hangs onto build-time > dependencies by default, probably so that you're not uninstalling them > and reinstalling them anytime you do anything. Strictly speaking, > however, it would be safe to depclean anything that is only a > build-time

[gentoo-dev] Last rites: sci-calculators/qalculate-{bases|currency|units}

# Matthias Maier <tam...@gentoo.org> (3 Aug 2016) # Masked for removal in 30 days. Obsolete packages that are now part of # sci-libs/libqalculate and/or sci-calculators/qalculate-gtk sci-calculators/qalculate-bases sci-calculators/qalculate-currency sci-calculators/qalculate-units signatu

Re: [gentoo-dev] rfc: /etc/init.d/modules loading modules defined in files

On Tue, Aug 16, 2016, at 18:20 CDT, William Hubbs wrote: > All, > > I have received a request to implement a feature in OpenRC to allow > multiple software packages to drop files in a directory, /etc/modules.d > for example, which would define modules the

Re: [gentoo-dev] rfc: /etc/init.d/modules loading modules defined in files

On Tue, Aug 16, 2016, at 18:49 CDT, Matthias Maier <tam...@gentoo.org> wrote: > On Tue, Aug 16, 2016, at 18:20 CDT, William Hubbs <willi...@gentoo.org> wrote: > >> All, >> >> I have received a request to implement a feature in OpenRC to allow >>

[gentoo-dev] Last rites: app-crypt/cryptkeeper

# Matthias Maier <tam...@gentoo.org> (31 Jan 2017) # Dead upstream (no development since 2010) [1,2], outstanding security # issue with newer encfs versions [3], oustanding Gentoo bugs [4,5]. # Mask for removal in 30 days. # [1] https://github.com/tomm/cryptkeeper/commits/master # [2]

Re: [gentoo-dev] Pre-GLEP for review: mix-in profiles

On Mon, Jan 23, 2017, at 13:30 CST, Alexis Ballier wrote: > still that doesn't account for a 'ihatelennart' mixin masking udev & > systemd and a 'ilovelennart' mixin masking udev & eudev and an user > enabling them both But that's exactly what is ruled out by the "blocks

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: net-wireless/gr-air-modes/

> Nice .. esp. coming from a QA dev ... This is an absolutely inappropriate response. Especially from a Mentee and prospective new Developer. Matthias signature.asc Description: PGP signature

Re: [gentoo-dev] Pre-GLEP for review: mix-in profiles

> well then 'ihateudev' masking udev, 'ihateeudev' masking eudev and > 'ihatesystemd' masking systemd; what are the blockers here? You make three profiles, 'udev', 'eudev', 'systemd' and put them in one group and let them block said group.

Re: [gentoo-dev] [RFC] New USE_EXPAND: LLVM_TARGETS

On Sun, Sep 25, 2016, at 16:08 CDT, Michał Górny wrote: > Hi, > > I'd like to introduce a new USE_EXPAND for LLVM & clang. It'd be named > LLVM_TARGETS, and it's going to replace the current solution based on > USE=multitarget & VIDEO_CARDS=radeon. > > In the old system, the

Re: [gentoo-dev] rfc: the demise of grub:0

On Mon, Oct 3, 2016, at 16:59 CDT, William Hubbs wrote: > All, > > I want to look into removing grub:0 from the tree; here are my thoughts > on why it should go. > > - the handbook doesn't document grub:0; we officially only support > grub:2. > > - Removing grub:0 from

Re: [gentoo-dev] Dealing with GitHub Pull Requests the easy way

> So, it is probably simpler to avoid controversy by just incorporating > it by reference under their original name, which is certainly the > intention of the Linux Foundation in promoting it. +1 :-) signature.asc Description: PGP signature

Re: [gentoo-dev] newsitem: important fstab update

> please make also clear that UUID=... syntax will still work, one for all I > don't like labels and will gladly continu to use this format: > UUID=debd07a3-fbbc-4433-89db-29e6f91d25e4 /boot ext2 noauto,noatime 1 2 +1 Slightly revising the example given later on by simply showing one example

Re: [gentoo-dev] Are "Copyright 1999-20xx Gentoo Foundation" headers bogus?

> I think you could make an argument that voluntarily placing that > header on your work is an assignment of copyright. I very much doubt that. > Personally I'd rather move to an explicit system. Yes! And I see absolutely no harm in explicitly annotating the actual copyright in gentoo

Re: [gentoo-dev] Are "Copyright 1999-20xx Gentoo Foundation" headers bogus?

> Well, depending on how this is done the main harm is in administrative > overhead, unless this is automated, or we use a simplistic approach of > just continuing to append names. The pragmatic approach would be to remove the policy and associated repoman warning and allow contributors to use an

Re: [gentoo-dev] newsitem: important fstab and localmount update, round 2

On Tue, Nov 1, 2016, at 11:52 CDT, William Hubbs wrote: > requirement for udev to "settle" before it's startup completes. The ^~~~ its Best, Matthias signature.asc Description: PGP

Re: [gentoo-dev] Dealing with GitHub Pull Requests the easy way

> Therefore, we may indeed consider taking the DCO from the Linux source > tree which is distributed under the GPL-2 I highly doubt that the DCO in the readme is licensed under GPL-2. There is no readme/header, or other indicator stating this. Not everything in the linux repository falls under

Re: [gentoo-dev] Dealing with GitHub Pull Requests the easy way

On Thu, Oct 27, 2016, at 09:11 CDT, Rich Freeman wrote: > I'd think that the title of a legal document falls more under > trademark law than copyright law. That is why the FSF publishes the > "GNU GENERAL PUBLIC LICENSE" and not just the "GENERAL PUBLIC > LICENSE." The

Re: [gentoo-dev] Cross Post due to technical component - Thanks for all the fish

On Tue, Dec 6, 2016, at 20:37 CST, james wrote: > So do I need to apply again, or an I on the list? I went (nomail) > cause at the time reading via gmane.org was working. Perhaps I should > just change the status to receive the mails? I can test post, if > that is

Re: [gentoo-dev] [RFC] New Manifest hashes and how to enable them

> manifest-hashes = SHA512 SHA3-512 WHIRLPOOL > > Your thoughts? I just want to point out that according to GLEP 63 we only require pgp signatures with at least sha-256 [1]. Further, our PGP signatures by the release team are as well either SHA-256/SHA-512. So using SHA3-512 (or whirlpool for

Re: [gentoo-dev] Re: stable gcc 5.4.0 ??

On Thu, Apr 20, 2017, at 17:17 CDT, "Walter Dnes" wrote: > ...fun !NOT. If you're doing a fresh install, ***WITH A GCC5-BUILT > INSTALL CD AND STAGE 3***, then yes, go for it. But changing horses in > mid-stream can be painfull. Would it hurt to stay with 4.9.4 for the

Re: [gentoo-dev] RFC: Update bitcoin eclass to default to knots

On Tue, Mar 7, 2017, at 10:52 CST, Rich Freeman wrote: >> As a Bitcoin user I personally don't feel too happy with my experience >> changing without me changing USE-flags. I'm not against changing the name of >> the USE-flag, just against changing the default behavior and

Re: [gentoo-dev] News item for Exim 4.88

On Wed, Mar 1, 2017, at 13:43 CST, Fabian Groffen wrote: > Hi, > > I'd like to push out attached news item ASAP. Please review. Looks good. Has a clear and precise structure. > Title: =mail-mta/exim-4.88 problem with chunking > Author: Fabian Groffen

Re: [gentoo-dev] RFC: Update bitcoin eclass to default to knots

> The kernel doesn't give you a choice of multiple independent patch > sets. We have just a few options that bundle many patches. You can't > selectively turn them on and off. > > I'm not asking whether patching bitcoin is good or bad. > > I'm pointing out that if you want to do the same thing

[gentoo-dev] Re: toolchain team lead election and team meeting

On Wed, Aug 9, 2017, at 15:43 CDT, "Andreas K. Huettel" wrote: > Hey there, > > it's time we do a proper lead election and have a toolchain meeting again. > > So, here's the plan: > > 1) team lead election: > * Nominations from now until August 18, by e-mailing to the

Re: [gentoo-dev] [PATCH] toolchain-funcs.eclass: We only support little-endian Alpha

On Sat, Jul 1, 2017, at 03:55 CDT, James Le Cuirot wrote: > Funny that no one noticed this for 10 years. :) Thanks to klausman for > clearing this up. > --- > eclass/toolchain-funcs.eclass | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git

Re: [gentoo-dev] [PATCH] toolchain.eclass: Remove kludge that blocks gcc-6+ on sys-libs/uclibc-ng systems

t for some time now, have completed several >> catalyst runs, and am at the tail end of a fresh install of a >> sys-libs/uclibc-ng userland on actual MIPS hardware. >> >> Signed-off-by: Joshua Kinard <ku...@gentoo.org> Signed-off-by: Matthias Maier <tam...@gentoo.

Re: [gentoo-dev] gcc-6.x status inquiry

> Just as a datapoint, my main dev system is ~80% stable and has been updating > with gcc-6 since beginning of february; no problems. [*] [**] Same here. The gcc-6 incompatibilities were resolved quite a while ago. Let's keyword gcc-6 and try to get gcc-7 into the tree on time. Best, Matthias

Re: [gentoo-dev] Removal of rxvt

On Thu, May 11, 2017, at 10:57 CDT, "Jason A. Donenfeld" wrote: > Does anybody have any objections to me doing this? (I'll wait a week > from now before taking any actions.) There is a clear and easy upgrade path to rxvt-unicode, so please mask right away. Best, Matthias

Re: [gentoo-dev] [RFC] News item: GCC 6 defaults to USE="pie ssp", v2

> Has anyone checked 32-bit systems? "emerge -pv =sys-devel/gcc-6.3.0" > on a 2008 Core2duo 32-bit install (my GCC 6.3.0 testbed) shows "(-pie)". > I read that as the "pie" USE flag being hard-masked out. On my 64-bit > desktop, "pie" is the default. Yes, we are aware of this. Unfortunately,

[gentoo-dev] [PATCH] profiles: update pie use-flag masks for sys-devel/gcc

-2017 Gentoo Foundation. # Distributed under the terms of the GNU General Public License v2 - -# Matthias Maier <tam...@genoto.org> (07 May 2017) -# masked in arch/base, unmask for hardened/musl/amd64 ->=sys-devel/gcc-6.3.0 -pie diff --git a/profiles/hardened/linux/musl/package.use.mask

[gentoo-dev] [PATCH] profiles: update pie use-flag masks for sys-devel/gcc

Hello all, In light of the recent discussion, I will restore the status quo for the pie use-flag: masked on non-hardened profiles, unmasked and forced on hardened profiles. The next step will be to switch the pie use-flag on default profiles from masked to unmasked/forced with a profile update.

[gentoo-dev] [PATCH] toolchain.eclass: add DEPEND to dev-libs/boehm-gc, bug #617788

sys-devel/gcc-7.1.0 requires external dev-libs/boehm-gc, the internal copy got removed [1]. [1] https://gcc.gnu.org/viewcvs/gcc?view=revision=242985 --- eclass/toolchain.eclass | 6 ++ 1 file changed, 6 insertions(+) diff --git a/eclass/toolchain.eclass b/eclass/toolchain.eclass index

[gentoo-dev] Re: New profiles for default-pie transition

> -> This would also give us some time to discuss what other changes we might > make with the transition to the new profiles. > > -> Also, this means the transition is independent of gcc release timing. > > (We just need to be careful since hardened also inherits 13.0, so the setting > must be

Re: [gentoo-dev] Re: [RFC] News item: GCC 6 defaults to USE="pie ssp"

On Wed, May 10, 2017, at 02:28 CDT, Martin Vaeth wrote: > I am using gcc-6 since ages and tried to run a desktop with default pie > for quite a while, but soon was forced to give up: > [...] I have pie enabled on a desktop for years. Almost all major linux distribution have

[gentoo-dev] Re: New profiles for default-pie transition

On Wed, May 10, 2017, at 10:32 CDT, Hanno Böck wrote: > Can't we just provide a small script or bash oneliner that will rebuild > all affected packages? See mail e-mail with the updated news item. "[RFC] News item: GCC 6 defaults to USE="pie ssp", v2" Best, Matthias

Re: [gentoo-dev] [RFC] News item: GCC 6 defaults to USE="pie ssp"

On Tue, May 9, 2017, at 15:10 CDT, Alexis Ballier wrote: > There is a *huge* difference between: > Disable PIE support (NOT FOR GENERAL USE) > and the negation of: > pie - Build programs as Position Independent Executables (a security > hardening technique) > > Enabling

[gentoo-dev] [PATCH] profiles: Mask pie useflag for >=sys-devel/gcc-6

ckage.use.mask b/profiles/base/package.use.mask index 9f55b27..c8faec7 100644 --- a/profiles/base/package.use.mask +++ b/profiles/base/package.use.mask @@ -7,6 +7,10 @@ # This file is only for generic masks. For arch-specific masks (i.e. # mask everywhere, unmask on arch/*) use arch/base. +# Matthias Maier &l

[gentoo-dev] [RFC] News item: GCC 6 defaults to USE="pie ssp"

Title: GCC 6 defaults to USE="pie ssp" Author: Matthias Maier <tam...@gentoo.org> Content-Type: text/plain Posted: 2017-05-07 Revision: 1 News-Item-Format: 1.0 Display-If-Installed: >=sys-devel/gcc-6.3.0 Display-If-Keyword: amd64 In Gentoo, several GCC features can be default

Re: [gentoo-dev] mingw-w64 crossdev prefix?

Hi there, On Wed, May 17, 2017, at 17:25 CDT, Marty Plummer wrote: > Greetings, > > So, I'm a relatively new gentoo user (as of 2016-12) coming from arch, > and one thing I've noticed is the relative difficulty of setting up a > mingw-w64 cross-compile toolchain and

Re: [gentoo-dev] mingw-w64 crossdev prefix?

On Wed, May 17, 2017, at 22:53 CDT, Alon Bar-Lev <alo...@gentoo.org> wrote: > On 18 May 2017 at 06:46, Matthias Maier <tam...@gentoo.org> wrote: >> [2] I had to manually disable libsanitizer for gcc-6.3.0. Just set >> EXTRA_ECONF="--disable-l

Re: [gentoo-dev] [RFC] News item: GCC 6 defaults to USE="pie ssp"

On Wed, May 10, 2017, at 00:07 CDT, Jason Zaman wrote: > I just want to make sure im understanding this right, only .a files that > were compiled without -pie will cause issues if you compile the later > thing that uses the .a with -pie? > So: > 1) people on hardened

Re: [gentoo-dev] [RFC] News item: GCC 6 defaults to USE="pie ssp"

> For a transition we can probably build everything with -fPIE but not > link with -pie. If we want that to happen fast, gcc-6 might do that and > gcc-7 add the -pie option. I am not entirely convinced that a transition period of one gcc version is enough for a smooth transition [1]. It might be

Re: [gentoo-dev] [RFC] News item: GCC 6 defaults to USE="pie ssp", v2

This is a reworded news item (assuming we proceed with the plan to default-enable USE=pie). Suggestions for improving the emerge command to fix static archives is highly welcomed. Matthias Title: GCC 6 defaults to USE="pie ssp" Author: Matthias Maier <tam...@gentoo.org> Co

Re: [gentoo-dev] Fixing elasticsearch maintainer

> Were this an actual office, this would be better solved with a "ok, > we've clearly been working too hard this week, everyone stop, ITS PUB > O-CLOCK!" This is most definitely true for almost everything going on for the last days in Gentoo. signature.asc Description: PGP signature

Re: [gentoo-dev] toolchain meeting agenda for today 19:00 UTC #gentoo-toolchain

On Fri, May 26, 2017, at 13:07 CDT, Alexis Ballier wrote: > On Sat, 20 May 2017 19:38:01 +0200 > "Andreas K. Huettel" wrote: >> - Globally setting -std=c++14 in upcoming 17.0 profiles > > A bit late to the party, but what was the outcome of the

Re: [gentoo-dev] [PATCH 01/05] toolchain-funcs.eclass: Add functions for detection of PIE / SSP in way compatible with GCC >=6.

> [[ ${ret} == true ]] > > Would be the canonical bash way. Updated.

[gentoo-dev] [PATCH 01/05] toolchain-funcs.eclass: Add functions for detection of PIE / SSP in way compatible with GCC >=6.

From: Arfrever Frehtes Taifersar Arahesis <arfre...@apache.org> Newly added tc-enables-pie(), tc-enables-ssp(), tc-enables-ssp-strong() and tc-enables-ssp-all() check macros instead of specs. This solution also works with older GCC and with Clang. Signed-off-by: Matthias Maier <tam...@g

[gentoo-dev] [RFC v2] toolchain-funcs.eclass / toolchain-glibc.eclass - gcc-6 bugfixes and updates

OK. This is a slightly modified version that uses string comparison to form the result. Best, Matthias

Re: [gentoo-dev] New 17.0 release profiles

On Sun, Jun 11, 2017, at 13:39 CDT, "Walter Dnes" wrote: > 1) Should I be doing bug reports on the Gentoo bugzilla or upstream? Please check [1] and if not already reported open a bug report blocking [1] on our bugzilla. Best, Matthias [1]

[gentoo-dev] [PATCH 3/5] toolchain-glibc.eclass: Always enable stack guard randomization (bug #621742).

From: Arfrever Frehtes Taifersar Arahesis <arfre...@apache.org> Signed-off-by: Matthias Maier <tam...@gentoo.org> --- eclass/toolchain-glibc.eclass | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/eclass/toolchain-glibc.eclass b/eclass/toolchain-glibc.eclass inde

[gentoo-dev] [PATCH 4/5] eclass/toolchain-glibc.eclass: use tc-enables-pie instead of gcc-specs-pie

--- eclass/toolchain-glibc.eclass | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/eclass/toolchain-glibc.eclass b/eclass/toolchain-glibc.eclass index 5be31eb193..270c9cdac7 100644 --- a/eclass/toolchain-glibc.eclass +++ b/eclass/toolchain-glibc.eclass @@ -266,7 +266,7 @@

[gentoo-dev] [PATCH 1/5] toolchain-funcs.eclass: Add functions for detection of PIE / SSP in way compatible with GCC >=6.

From: Arfrever Frehtes Taifersar Arahesis <arfre...@apache.org> Newly added tc-enables-pie(), tc-enables-ssp(), tc-enables-ssp-strong() and tc-enables-ssp-all() check macros instead of specs. This solution also works with older GCC and with Clang. Signed-off-by: Matthias Maier <tam...@g

[gentoo-dev] [PATCH 5/5] eclass/toolchain-glibc.eclass: skip pie check for gcc-6 or newer

For gcc-6 and newer the old logic in the toolchain-glibc eclass: if use hardened && gcc-specs-pie ; then append-cppflags -DPIC else filter-flags -fPIE fi is obsolete. Simply disable the check. --- eclass/toolchain-glibc.eclass | 24 +++- 1 file changed, 15

[gentoo-dev] Re: [RFC] toolchain-funcs.eclass / toolchain-glibc.eclass - gcc-6 bugfixes and updates

On Wed, Jun 14, 2017, at 18:15 CDT, Matthias Maier <tam...@gentoo.org> wrote: > [...] and of course, many thanks to Arfrever for patches and his kind support! Best, Matthias signature.asc Description: PGP signature

[gentoo-dev] [RFC] toolchain-funcs.eclass / toolchain-glibc.eclass - gcc-6 bugfixes and updates

Hello all, this is a series of patches against the toolchian-funcs and toolchain-glibc eclasses, most notably - introducing new tc-enables-pie(), tc-enables-ssp(), tc-enables-ssp-strong() and tc-enables-ssp-all() functions in toolchain-funcs compatible with gcc >=6 and clang as a

[gentoo-dev] [PATCH 2/5] toolchain-glibc.eclass: Build most of >=sys-libs/glibc-2.25 with -fstack-protector-all (bug #609048).

From: Arfrever Frehtes Taifersar Arahesis <arfre...@apache.org> configure accepts --enable-stack-protector=... option which results in build system passing appropriate -fstack-protector... option when possible. Signed-off-by: Matthias Maier <tam...@gentoo.org> --- eclass/toolchain-

Re: [gentoo-dev] Hardening a default profile

> there should be a way of turning these off systematically. the > advantage of the current hardened gcc specs is that one can switch > between them using gcc-config. if these are forced on for the default > profile then there will be no easy way to systematically turn them off. No - there

Re: [gentoo-dev] [RFC] toolchain-funcs.eclass / toolchain-glibc.eclass - gcc-6 bugfixes and updates

On Wed, Jun 14, 2017, at 18:15 CDT, Matthias Maier <tam...@gentoo.org> wrote: > Hello all, > > this is a series of patches against the toolchian-funcs and toolchain-glibc > eclasses, most notably > > - introducing new tc-enables-pie(), tc-enables-ssp(), >tc-

Re: [gentoo-dev] Hardening a default profile

Hi Michael, On Sun, Jun 11, 2017, at 16:39 CDT, Michael Brinkman wrote: > So I was just wondering if ~arch is ready for more secure defaults on > the 17.0 profiles in the linker flags. There are several > distributions which ship RELRO by default and I am not

Re: [gentoo-dev] gcc-6.x status inquiry

> After the discussion on this thread (no one seemed to object), I went > ahead just now and added ~ keywords to sys-devel/gcc-6.3.0. Thanks a lot! Did you update any keywording bug (if one is open at all)? Best, Matthias signature.asc Description: PGP signature

  1   2   >