On Thu, 10 Aug 2017 21:41:24 + (UTC)
Duncan <1i5t5.dun...@cox.net> wrote:
> Sergei Trofimovich posted on Tue, 08 Aug 2017 16:53:22 +0100 as excerpted:
>
> > The failure happens when live glibc- ebuild is installed:
> > * QA Notice: Missing gen_usr_ldscript for libm-2.26.90.so * ERROR:
>
Sergei Trofimovich posted on Fri, 11 Aug 2017 09:14:42 +0100 as excerpted:
> What is your point there? I'm afraid I lost you.
Just saying interesting it's the same lib and apparently the same
symlinking logic and line involved, and while it doesn't seem to be the
same bug, it might be worth a b
On 08/11/2017 12:30 AM, Michael Mair-Keimberger wrote:
> Hi Gentoo Team,
>
> As some of you may noticed i started to clean up some old patches in the
> gentoo portage tree. I did so already a while ago, and like before I'm
> using a small script in order to identify unused patches.
I just wanted
Hi, everyone.
I've just reverted the LDFLAGS stripping code I've committed earlier
because it failed hard with clang. Here's an updated patch set that
ensures that clang is going to work fine. Please review.
--
Best regards,
Michał Górny
---
eclass/flag-o-matic.eclass | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/eclass/flag-o-matic.eclass b/eclass/flag-o-matic.eclass
index b2f3742b3ecf..0393a30b74c3 100644
--- a/eclass/flag-o-matic.eclass
+++ b/eclass/flag-o-matic.eclass
@@ -433,11 +433,15 @@ test
By default, clang considers unused arguments as error when -Werror is
used. Since flag tests are performed without linking, this causes all
tests for linker flags to fail inadvertently and all those flags
are stripped as a result.
While the correctness of passing unused flags is doubtful, silently
Include LDFLAGS in the variables stripped by strip-unsupported-flags.
The code reuses the current functions for testing CC, and so only remove
LDFLAGS that are rejected by the C compiler and not the linker. This
solves the case of bug #621274 where LDFLAGS contained GCC-specific
-flto flag.
---
ec
Hi, everyone.
Due to the Bazaar project being disbanded [1], the following packages
are up for grabs:
[n] dev-vcs/bzr-explorer
[o] dev-vcs/bzr-git
[n] dev-vcs/bzr-gtk
[o] dev-vcs/bzr-rewrite
[n] dev-vcs/bzr-xmloutput
[n] dev-vcs/bzr
[o] dev-vcs/bzrtools
[o] dev-vcs/qbzr
[n] -- newest/current, [o
Hi,
Due to the Forensics project [1] being disbanded, the following packages
are now up for grabs. Please note that some of the packages will
probably be taken by former project members.
app-admin/integrit
app-forensics/afflib [o]
app-forensics/air
app-forensics/autopsy
app-forensics/chkrootkit [
On Fri, Aug 11, 2017 at 11:40 AM, Michał Górny wrote:
> app-admin/integrit
> app-forensics/afflib [o]
> app-forensics/air
> app-forensics/autopsy
> app-forensics/chkrootkit [o]
> app-forensics/cmospwd
> app-forensics/examiner
> app-forensics/galleta
> app-forensics/libewf [o]
> app-forensics/lynis
I have used chkrootkit and rkhunter in the past. Will copy them to my
overlay (https://github.com/petteyg/gentoo-overlay) if they don't get a
maintainer.
On Fri, Aug 11, 2017 at 12:49 PM, RB wrote:
> On Fri, Aug 11, 2017 at 11:40 AM, Michał Górny wrote:
> > app-admin/integrit
> > app-forensics/
We have a pull request for the devmanual that will update the revision
documentation; namely, when to create a new one:
https://github.com/gentoo/devmanual.gentoo.org/pull/67
The comments bring up an issue that I think can benefit from some
hindsight. Specifically, the PR says that it's OK to c
Hi,
I was able to test this one a bit.
The test subjects were:
~amd64/openrc/desktop system which I was going to wipe anyway.
amd64/openrc latest snapshot, updated to ~amd64 with boostrtap.sh
for the latter symlink migration was done before bootstrapping,
So far I found 3 issues so far:
1) k
On 08/11/2017 07:50 PM, Michael Orlitzky wrote:
> == New revisions for USE flag changes ==
>
> I suggest that in hindsight, we can do better. Suppose we require a new
> revision for every change to IUSE. Then,
>
> * We can delete all of the PM code for --changed-use and --newuse and
> frien
On 08/11/2017 08:45 PM, Brian Evans wrote:
>
> I disagree about removing --newuse and --changed-use from portage.
> This is not their only use.
>
> If you happen to change the effective use system wide, USE= in make.conf
> for portage, these options scan the entire system for such changes.
>
Do
On 08/11/2017 08:59 PM, Michael Orlitzky wrote:
>
> Does --changed-use help there? I can see the argument for --newuse, but
> I thought --changed-use only applied to flags that were added or removed
> to installed packages (which becomes impossible, if we require new
> revisions).
>
^ this doesn
On 08/11/2017 08:59 PM, Michael Orlitzky wrote:
> On 08/11/2017 08:45 PM, Brian Evans wrote:
>>
>> I disagree about removing --newuse and --changed-use from portage.
>> This is not their only use.
>>
>> If you happen to change the effective use system wide, USE= in make.conf
>> for portage, these o
On 08/12/2017 09:50 AM, Michael Orlitzky wrote:
> Q. But what about the rebuilds?
>
> For most packages, the rebuilds simply don't matter. Unless you're
> the maintainer of libreoffice, firefox, chromium, etc. -- just do the
> revision and forget about the (quick) rebuilds.
I really wish pe
On Fri, 2017-08-11 at 19:50 -0400, Michael Orlitzky wrote:
>
> == New revisions for USE flag changes ==
>
> I suggest that in hindsight, we can do better.
Not all IUSE changes are equal and thus a policy that treats them all
the same doesn't make sense to me. Maintainers are in a better position
19 matches
Mail list logo
