Re: [gentoo-dev] EAPI 2 must die

[Alon Bar-Lev]

On Thu, Jun 6, 2019 at 8:07 AM Andreas K. Huettel 
wrote:

> Hi all,
>
> for the package maintainers among you, here's the list of remaining EAPI=2
> packages. Please help getting the number down to zero soon!!!
>
> Cheers,
> Andreas
>
> media-fonts/culmus-0.120-r4
>
>
Done.

Re: [gentoo-dev] Best way to create a GLEP 63 compliant GPG key on Nitrocard?

[Alon Bar-Lev]

On Wed, Apr 24, 2019 at 5:19 PM Rich Freeman  wrote:
> Well, in that case recommendations for how to generate a key that
> complies in software would be helpful.  There used to be a wiki
> article on it, but it is marked with various warnings saying it isn't
> recommended to follow it, and has seemingly vanished with a note that
> it moved somewhere.


Please wait for me to receive mine... :)

In the meantime, I think that you may find the following commands useful...

$ gpg --expert --full-generate-key
$ gpg --expert --edit-key ${MASTER_KEY_ID}
gpg> addkey

Regards,
Alon

[gentoo-dev] app-crypt/openssl-tpm-engine mask for removal in 30 days

[Alon Bar-Lev]

Upstream is dead.
Package does not support openssl-1.1, significant change to package.
Removal in 30 days.

Re: [gentoo-dev] Changing policy about -Werror

[Alon Bar-Lev]

On Sat, Sep 22, 2018 at 1:33 AM Chí-Thanh Christopher Nguyễn
 wrote:
>
> Richard Yao schrieb:
>
> >> To make code behave differently it needs substantial amount of code
> >> to provide you an example. You need to him O2<->O3 behaviour delta
> >> after all. But I will try (for a different warning, it should not matter
> >> much).
> > Thanks. I had been incorrect about -O3 giving not us some additional 
> > information for warnings. My apologies for the confusion.
> >>
> >> Below is a reduced example of a larger C++ program.
> >> Many thanks to Ulya for providing recent example!
>
> Not that it matters now, but there are examples of packages building at -O2
> but failing to build at -O3 optimization levels, due to -Werror.
>
> One is dev-libs/libcss: https://bugs.gentoo.org/626752
>

It is matter, and shows that for selected packages in which upstream
has strict policy of no warning, each warning should be investigated
as it may be a true issue. The tool compiler provide to find these
edge condition should not be ignored nor overridden. The fact that a
package "builds" does not mean it is free of bugs.

Regards,
Alon

Re: [gentoo-dev] Changing policy about -Werror

[Alon Bar-Lev]

On Sat, Sep 15, 2018 at 1:14 AM Richard Yao  wrote:
> > On Sep 14, 2018, at 5:28 PM, Fabian Groffen  wrote:
> >
> > On 15-09-2018 00:07:12 +0300, Alon Bar-Lev wrote:
> >>>
> >>> Perhaps, if one persists on going this route, only do this for platforms
> >>> that upstream supports, such that arches which will suffer from this
> >>> (typically ppc, sparc, ...) don't have to be blocked by this.
> >>
> >> Exactly in these cases the -Werror is useful as if upstream expects no
> >> warnings then any warning should block installation and trigger bug
> >> report. In Gentoo in many cases we use packages on platform has no
> >> access to, our feedback to upstream is valuable. A great example is
> >> gnutls in which we collectively (maintainer, unstable users,
> >> architecture teams, stable users) found issues on architectures that
> >> almost nobody other than Gentoo has access to.
> >>
> >
> > I don't believe Gentoo users are (supposed to be) an extension of
> > upstreams.  If upstreams insist on that, they should make their software
> > non-free, adding a non-modification clause or something.  In any case,
> > it is not Gentoo's job IMHO.  In the end it is Gentoo who needs to care
> > for its users.  I prefer we do that by giving them an option to become
> > that extension of upstream, e.g. by USE=upstream-cflags, which Gentoo
> > disables by default.
> I am in complete agreement on this. Users should not be guinea pigs to help 
> upstream unless they opt into it.

A new release of upstream is out, early adopters (what we call
unstable users) are guinea pings.
A new release is stabilized, users are guinea pings.
A new toolchain that upstream did not test, users are guinea pings.
A new dependency version or a Gentoo virtual with "compatible
library", users are guinea pings.
Let's say upstream does not have access to architecture X we at Gentoo
decide to support this architecture, maintainer do not have access to
this architecture as well, architecture team is guinea pings, but it
does not actually use the package, then back to early adopters and
users.

This process has nothing to do with -Werror, our process relays on
users as guinea pings, by definition developers and arch teams cannot
test entire software and all permutation of the software.

The -Werror (if supported by upstream and downstream, I outlined the
conditions many times) is a tool (among other) to help stop the
process at early stage when suspicious finding is there to allow deal
with the situation to make sure that the software is compatible with
an environment or permutation that upstream and maintainer do not have
direct access to. It is a tool to help users to have better system
integrity (once again, provided some conditions apply).

Re: [gentoo-dev] Changing policy about -Werror

[Alon Bar-Lev]

On Sat, Sep 15, 2018 at 12:29 AM Fabian Groffen  wrote:
>
> On 15-09-2018 00:07:12 +0300, Alon Bar-Lev wrote:
> > >
> > > Perhaps, if one persists on going this route, only do this for platforms
> > > that upstream supports, such that arches which will suffer from this
> > > (typically ppc, sparc, ...) don't have to be blocked by this.
> >
> > Exactly in these cases the -Werror is useful as if upstream expects no
> > warnings then any warning should block installation and trigger bug
> > report. In Gentoo in many cases we use packages on platform has no
> > access to, our feedback to upstream is valuable. A great example is
> > gnutls in which we collectively (maintainer, unstable users,
> > architecture teams, stable users) found issues on architectures that
> > almost nobody other than Gentoo has access to.
> >
>
> I don't believe Gentoo users are (supposed to be) an extension of
> upstreams.

This is exactly what I think that is special about Gentoo, and the
reason I use Gentoo. Unlike other distribution Gentoo is the closest
thing of using upstream. A maintainer in Gentoo who is not see himself
part of the upstream packages he maintains has far less impact than a
maintainer who does see himself as part of upstream or is upstream.

Per your statement, we should not allow any architecture or setup that
upstream, such as exact versioning, architecture or toolchain.

> If upstreams insist on that, they should make their software
> non-free, adding a non-modification clause or something.  In any case,
> it is not Gentoo's job IMHO.

Then we cannot re-distribute or patch, how is it related to the
discussion? We are talking about open source projects and I know it is
cliche... the "greater good" and helping the "free open source
movement" a a viable alternative. I thought this is what unite us
here.

> In the end it is Gentoo who needs to care
> for its users.  I prefer we do that by giving them an option to become
> that extension of upstream, e.g. by USE=upstream-cflags, which Gentoo
> disables by default.

Do you think someone do not care about the users? Do you actually
think upstream does not care about users? I do not understand this
statement. If downstream maintainer believes that upstream is friendly
for the Gentoo overhead (which is higher than binary distributions) or
create the relationship in which Gentoo is 1st citizen at upstream,
why do you think users cannot use vanilla upstream?

> As maintainer and/or enthusiastic user, like you wrote for gnutls, I
> would be more than happy to provide build logs/errors for all the arches
> I have access to.  So like I wrote before, I think we should consider
> case-by-case basis to make it easy to do so.

This entire discussion is to allow case-by-case and not black and
white approach recently enforced.

Regards,
Alon

Re: [gentoo-dev] Changing policy about -Werror

[Alon Bar-Lev]

On Sat, Sep 15, 2018 at 12:02 AM Fabian Groffen  wrote:
>
> On 14-09-2018 16:29:43 -0400, Rich Freeman wrote:
> > On Fri, Sep 14, 2018 at 4:20 PM Michael Orlitzky  wrote:
> > >
> > > On 09/14/2018 03:58 PM, Richard Yao wrote:
> > > >>
> > > >> No one has answered the question: what do you do when a stable package
> > > >> breaks because of a new warning?
> > > >>
> > > >> ...>
> > > > Wouldn’t this be largely covered as part of GCC stabilization? We could 
> > > > reserve the right to kill -Werror in a package where it blocks GCC 
> > > > stabilization if the maintainer does not handle it in a timely manner.
> > > >>
> > >
> > > They would be uncovered during GCC stabilization, but then you're right
> > > back in the original situation: how do you fix the stable package? The
> > > only answer that doesn't violate some other policy is to patch it in a
> > > new revision and wait for it to stabilize again.
> > >
> > > Other questions arise: Do we block stabilization of clang et al.?
> > >
> >
> > Presumably we could make it a blocker, so then portage won't install
> > the new stable toolchain.  That buys time and only affects users of
> > that particular package.  But, as I pointed out before you can do that
> > without using -Werror - just block installation with an unqualified
> > toolchain.
> >
> > You would only use an approach like this for packages where QA was
> > fairly important, so the inconvenience would be worth it.
>
> Perhaps, if one persists on going this route, only do this for platforms
> that upstream supports, such that arches which will suffer from this
> (typically ppc, sparc, ...) don't have to be blocked by this.

Exactly in these cases the -Werror is useful as if upstream expects no
warnings then any warning should block installation and trigger bug
report. In Gentoo in many cases we use packages on platform has no
access to, our feedback to upstream is valuable. A great example is
gnutls in which we collectively (maintainer, unstable users,
architecture teams, stable users) found issues on architectures that
almost nobody other than Gentoo has access to.

Re: [gentoo-dev] Changing policy about -Werror

[Alon Bar-Lev]

On Fri, Sep 14, 2018 at 10:53 PM Sergei Trofimovich  wrote:
>
> On Fri, 14 Sep 2018 19:40:13 +0300
> Alon Bar-Lev  wrote:
>
> >
> > No dependency of toolchain nor annotations.
> > A strict policy of no warnings will require changes as dependencies
> > including toolchain are progressing.
> > This creates an overhead for selected packages.
> > A maintainer and the non-stable team should be able to know the package 
> > status.
> > Preferably this may be done by automation, I appreciate the work of
> > Toralf Förster with tinderbox to automate check various cases.
> > When a new slot of toolchain is available, maintainers should check
> > their packages in any case, there are other issues and side affects
> > that we experienced, especially in C++ packages.
> > For these packages usually there are 3 for each slot: the current
> > stable, the next stable and the non-stable, so the overhead is
> > constrained.
>
> Sorry. I'm afraid I missed your answer. I'll restate the question again:
>
>   If you do it then what is your workflow to fix breakages
>   appearing in stable packages caused by minor environment
>   changes like toolchain tweaks?
>
> I mean mechanically as a package maintainer.
>
> Since you did not mention it I see a few alternatives:
> - revbump a package with a backport of a local fix and fast-track
>   stabilization without usual soak time in ~arch

Fix in place if false positive.
Revision bump if positive.

> - pull new upstream version and fast-track stabilization without
>   usual soak time in ~arch

No reason to wait for upstream if obvious positive just like any bug fix.

> - no revbump, apply the patch as-is and hope it does not break
>   existing users.

Correct.

> - anything else?

Patching the package (stable and unstable) to remove -Werror if too
many of them and downstream maintainer reaches to a conclusion that
the overhead is too high and benefit is little and provide this
feedback to upstream to work together on a new release of upstream
which resolves all warnings with newer toolchain.

>
> > > Unused variable is a good example of typical benign warning:
> > > it was there all the time, it's not a new bug and does not
> > > warrant need for an immediate fix.
> >
> > Unused variable is a good example of CRITICAL potential issue
>
> I understand you point. I disagree with it.
>
> My litmus test: if behaviour of the package did not change after
> the fix then the issue was not real.

But how can you get the report to evaluate if it is real or not? I
fail to understand this argument that is repeated over and over.
Everyone is smart after the did... while we are looking for the
trigger to evaluate.

> > > Toolchain just happend to get better at control flow graph
> > > analysis. Fix can easily wait for next release and save
> > > everyone's time.
> >
> > Once again, the number of permutation of build and architecture may
> > reveal issues that are cannot be detected on maintainer machine.
> > If a fix is a real issue that is found in stable package, do you
> > suggest to wait for next release to save whose time?
>
> It's up to maintainer to decide on how to resolve the issue once
> maintainer understands the scope of the problem.

Correct. My believe is that it is up to maintainer to decide.

> > Once again I outlined the cases in which -Werror can be preserved, I
> > will repeat... (a) upstream has strict policy of no-warnings, (b)
> > upstream added -Werror, (c) downstream opinion is that upstream is
> > following the policy, (d) upstream is friendly, (e) downstream accepts
> > the potential maintenance overhead.
>
> Your proposal is clear. Thanks for restating it.
>
> I still think keeping -Werror enabled by default makes more harm
> than good.

Yes, but we are not talking about by default, right?

> > > Gentoo does not normally run tests on user's systems either.
> > > Tests are arguably a lot more precise in pointing out real
> > > problems in software.
> >
> > Correct. I believe that this may be revisit as well, for selected
> > packages in which tests are stable run them on user machines. There is
> > no reason why we cannot add a directive to ebuild to enable tests by
> > default and let user to disable this to save CPU/time of build.
>
> Additional thanks for considering an option to disable tests back.
>

Any mechanism that is fully supported by upstream and downstream
maintainer find it stable should be enabled by default. I do see the
benefit of disabling tests not because they may break as per the same
argument I would like to have these reported and investigated, but to
save resources (time and CPU) which may be significant.

Thanks,
Alon

Re: [gentoo-dev] Changing policy about -Werror

[Alon Bar-Lev]

On Fri, Sep 14, 2018 at 8:53 PM Michał Górny  wrote:
>
> On Fri, 2018-09-14 at 20:48 +0300, Alon Bar-Lev wrote:
> > On Fri, Sep 14, 2018 at 8:33 PM Michał Górny  wrote:
> >
> > > > Let's do this the other way around and be react based on facts and not
> > > > speculations.
> > > > Let's change the policy for a year for selected packages as I
> > > > outlined, monitor bugs and after a year see response times, affected
> > > > users and if downstream patches are accumulated. Then we can decide if
> > > > we need to patch upstream packages.
> > > > If we need to patch upstream package anyway, not follow upstream
> > > > policy and not accepting input for various of permutations and
> > > > architecture from all users, this discussion is nearly void.
> > > >
> > >
> > > ...and for how long did you exactly ignore the standing policy that
> > > suddenly we need a new testing period?  How about we do the opposite
> > > and you prove a *single* bug found downstream using this method so far?
> > >
> > > Because so far this discussion is not much different than "let's make
> > > the ebuild fail for some values of ${RANDOM}, and add extra values when
> > > users complain".  Though the variant with random has probably a greater
> > > chance of failing when *actual* security issues happen.
> >
> > OK, back to personal discussion, unfortunately you question this in
> > this principal thread.
> >
> > Personal response:
> > In all my years in Gentoo, I've never thought the maintainer lose his
> > judgement of how to maintain a package as long as the he/she provide a
> > great service to users.
> > I've never thought or read this (and other) paragraph as a strict
> > white and black nor the holy bible , but a suggestion of how to
> > provide a great service to user with the least overhead to maintainer,
> > the best practice, the common case.
> > I believe there was no complains from users about these packages, on
> > the opposite users report issues and are happy when resolved after
> > proper investigation.
> > I guess something had changed recently in Gentoo in which QA try to
> > take the maintainer judgement try to enforce a black and white
> > perspective and without looking at bug history and other sources.
> > I believe this is a regression and not a progression, I was very
> > disappointed to see this new side of Gentoo in which common sense for
> > a specific case cannot be discussed individually, nor that a fixed bug
> > is hijacked to discuss a principal issue without opening a separate
> > formal QA request to discuss properly, address some of the argument
> > raised by fellow developers and the reaction of requesting to ban
> > developers without any mature discussion. As you can see this in this
> > thread is not black and white.
> >
>
> I should point out *once again* that:
>
> a. nobody requested banning developers,
>
> b. Bugzilla access suspension was requested because of your hostility
> in closing the bug and not the technical issue in question --
> or in other words, to prevent you from closing the bug again.
>
> However, if you continue spreading harmful misinformation about my
> intentions in attempt to prove your point in technical matter, then
> I believe we have much more serious problem to address here.

Unfortunately you still continue the personal discussion in principal
thread. I will not cooperate with that as it missing the point. Throw
the entire process you are trying to enforce your view and your
interpretation of the process as if enforcing that may have benefit.
Your request to ban via bugzilla access was rejected with explanation.
The bug that was closed was fixed, if you wanted to have a principal
discussion you should had opened a different principal one and discuss
the issue in opened mind, reaching to a conclusion that we need to
escalate the discussion together. I beg you as I beg you in bugzilla,
please do not turn this thread to personal one, it is not productive.

Re: [gentoo-dev] Changing policy about -Werror

[Alon Bar-Lev]

On Fri, Sep 14, 2018 at 8:33 PM Michał Górny  wrote:

> > Let's do this the other way around and be react based on facts and not
> > speculations.
> > Let's change the policy for a year for selected packages as I
> > outlined, monitor bugs and after a year see response times, affected
> > users and if downstream patches are accumulated. Then we can decide if
> > we need to patch upstream packages.
> > If we need to patch upstream package anyway, not follow upstream
> > policy and not accepting input for various of permutations and
> > architecture from all users, this discussion is nearly void.
> >
>
> ...and for how long did you exactly ignore the standing policy that
> suddenly we need a new testing period?  How about we do the opposite
> and you prove a *single* bug found downstream using this method so far?
>
> Because so far this discussion is not much different than "let's make
> the ebuild fail for some values of ${RANDOM}, and add extra values when
> users complain".  Though the variant with random has probably a greater
> chance of failing when *actual* security issues happen.

OK, back to personal discussion, unfortunately you question this in
this principal thread.

Personal response:
In all my years in Gentoo, I've never thought the maintainer lose his
judgement of how to maintain a package as long as the he/she provide a
great service to users.
I've never thought or read this (and other) paragraph as a strict
white and black nor the holy bible , but a suggestion of how to
provide a great service to user with the least overhead to maintainer,
the best practice, the common case.
I believe there was no complains from users about these packages, on
the opposite users report issues and are happy when resolved after
proper investigation.
I guess something had changed recently in Gentoo in which QA try to
take the maintainer judgement try to enforce a black and white
perspective and without looking at bug history and other sources.
I believe this is a regression and not a progression, I was very
disappointed to see this new side of Gentoo in which common sense for
a specific case cannot be discussed individually, nor that a fixed bug
is hijacked to discuss a principal issue without opening a separate
formal QA request to discuss properly, address some of the argument
raised by fellow developers and the reaction of requesting to ban
developers without any mature discussion. As you can see this in this
thread is not black and white.

Re: [gentoo-dev] Changing policy about -Werror

[Alon Bar-Lev]

On Fri, Sep 14, 2018 at 8:16 PM Richard Yao  wrote:
>
> On 09/14/2018 12:40 PM, Alon Bar-Lev wrote:
> > On Fri, Sep 14, 2018 at 12:34 AM Sergei Trofimovich  
> > wrote:
> >>
> >> On Tue, 11 Sep 2018 12:44:38 +0300
> >> Alon Bar-Lev  wrote:
> >>
> >> I'm personally in favour of not allowing -Werror
> >> to be in build system unconditionally.
> >>
> >> Maintainer is free to implement --enable-werror any way
> >> it's convenient to run on their own extended sanity checks
> >> and optionally expose it to users. Be it USE flag or
> >> EXTRA_ECONF option.
> >
> > This discussion is not for downstream to have a more strict policy
> > than upstream. People try to hijack discussion and introduce noise to
> > de-focus the discussion.
> >
> > Downstream policy cannot be more strict than upstream as then every
> > change upstream is doing downstream need to rebase and invest in even
> > more changes.
> >
> > This discussion is to follow upstream strict policy if upstream proves
> > that it stands behind it and downstream is willing to follow.
> I don't think we should do that unless we provide a USE flag for users
> to opt into the behavior. Forcing it on users is problematic for the
> reasons others stated. However, letting them opt into the behavior is
> reasonable.
>
> In the case of sys-fs/zfs, enabling -Werror (which includes -Wall) on
> USE=debug is following upstream's wishes to build debug builds with -Werror.

Let's do this the other way around and be react based on facts and not
speculations.
Let's change the policy for a year for selected packages as I
outlined, monitor bugs and after a year see response times, affected
users and if downstream patches are accumulated. Then we can decide if
we need to patch upstream packages.
If we need to patch upstream package anyway, not follow upstream
policy and not accepting input for various of permutations and
architecture from all users, this discussion is nearly void.

Re: [gentoo-dev] Changing policy about -Werror

[Alon Bar-Lev]

On Fri, Sep 14, 2018 at 12:34 AM Sergei Trofimovich  wrote:
>
> On Tue, 11 Sep 2018 12:44:38 +0300
> Alon Bar-Lev  wrote:
>
> I'm personally in favour of not allowing -Werror
> to be in build system unconditionally.
>
> Maintainer is free to implement --enable-werror any way
> it's convenient to run on their own extended sanity checks
> and optionally expose it to users. Be it USE flag or
> EXTRA_ECONF option.

This discussion is not for downstream to have a more strict policy
than upstream. People try to hijack discussion and introduce noise to
de-focus the discussion.

Downstream policy cannot be more strict than upstream as then every
change upstream is doing downstream need to rebase and invest in even
more changes.

This discussion is to follow upstream strict policy if upstream proves
that it stands behind it and downstream is willing to follow.

For your question: No. Downstream should not add -Werror to upstream
package, not in a parameter or USE flag, as this will probably break
and cause a queue of downstream patches.

> > I would like to suggest a modify our policy with the following
> > exception clause: Package maintainer may decide to keep upstream
> > -Werror as long as he is willing to resolve all issues resulting from
> > -Werror as if it was a blocker bug.
>
> Do you intend to keep -Werror for case when ebuild goes
> stable as well?

Correct.

> If you do it then what is your workflow to fix breakages
> appearing in stable packages caused by minor environment
> changes like toolchain tweaks?

Correct.

> Add another round of stabilization on each arch team? It
> sounds like your default assumption that code needs to be
> changed in a semantically significant way: add annotations
> that might not like some toolchains, remove unused code.

No dependency of toolchain nor annotations.
A strict policy of no warnings will require changes as dependencies
including toolchain are progressing.
This creates an overhead for selected packages.
A maintainer and the non-stable team should be able to know the package status.
Preferably this may be done by automation, I appreciate the work of
Toralf Förster with tinderbox to automate check various cases.
When a new slot of toolchain is available, maintainers should check
their packages in any case, there are other issues and side affects
that we experienced, especially in C++ packages.
For these packages usually there are 3 for each slot: the current
stable, the next stable and the non-stable, so the overhead is
constrained.

> Or patch package in-place without bumping? None of options
> sound optimal compared to dropping -Werror.

Success of build is not the only concern although I see people here
that are interested only in that.
Patching upstream package and/or change upstream quality policy is
something that we should avoid as well to maintain upstream warranty.

> > The package maintainer decision may be based on the package state and
> > the relationship with upstream, but basically, it is his decision as
> > long as issues are fixed in timely manner, it is his overhead after
> > all.
>
> I agree that maintainer's will and upstream's will should be
> respected and it's not something needs to be absolutely
> enforced all the time.
>
> Personally I disagree -Werror on end-user machine is worth
> it (or cppcheck, or coverity round-trip run is worth running
> on user's machine unconditionally).
>
> Unused variable is a good example of typical benign warning:
> it was there all the time, it's not a new bug and does not
> warrant need for an immediate fix.

Unused variable is a good example of CRITICAL potential issue, the bug
that triggered this this discussion has a return code that was not
used. The permutation was not tested by upstream as it rarely used, it
was not tested by me either by the same reason, both is a mistake.
Fortunately, someone else tested this permutation and his build
failed, triggered a bug. If -Werror has not been used we would not
have known about this issue. In many cases these happen in
architecture that maintainer nor upstream have access to. In this
specific case I went over the code history to the time the return code
have been used and determined that this indeed should be ignored,
imagine the opposite. A patch was submitted to upstream to confirm
resolution as any issue in code, upstream confirmed and merged this in
timely fashion. Bottom line we all (Gentoo, upstream and any other
distribution) enjoy better quality.

> Toolchain just happend to get better at control flow graph
> analysis. Fix can easily wait for next release and save
> everyone's time.

Once again, the number of permutation of build and architecture may
reveal issues that are cannot be detected on maintainer machine.
If a fix is a real issue that is found in stable package, do you
sugges

Re: [gentoo-dev] Changing policy about -Werror

[Alon Bar-Lev]

On Thu, Sep 13, 2018 at 7:20 PM Fabian Groffen  wrote:
> > > To illustrate harmless:
> > >   warning: this statement may fall through [-Wimplicit-fallthrough=]
> > > The warning message already has it in it that it's just a pure guess.
> >
> > One that exposed a lot of unintentional fallthoughs which were fixed
> > when reporting to upstream.
>
> Sure that's why the warning is there.  But you ignore the point that the
> same code compiled fine and ran fine for years without problems.

The fact that something is compiling and running fine meaning there
are no issues (bugs) within code?
Seriously?
Even after no-warning with multiple compiler vendors, code coverage,
unit testing, test on various of architecture developer has access to,
static code analysis and running for years, bugs are there. Any method
to help detect suspicious code, even if it produces amount of false
positive, must be embraced of those who care about quality. New
toolchains, new scanners, new architectures all can help to improve
quality to make sure great service is provided to users.

In Gentoo language, all these issues should be detected for selected
packages by non-stable users, on architecture and permutations that
upstream do not have access to, and to help upstream to filter false
positives and find the positives ones. Even one case of funding real
issue is sufficient to justify the maintenance costs, once again for
selected packages in which upstream following strict quality policy
and downstream follows. Once policy is applied, the amount of noise is
very little, toolchain evolution is not as it was 10 years ago.

Regards,
Alon

Re: [gentoo-dev] Changing policy about -Werror

[Alon Bar-Lev]

On Thu, Sep 13, 2018 at 6:51 PM Fabian Groffen  wrote:
>
> On 12-09-2018 17:46:03 -0700, Matt Turner wrote:
> > On Wed, Sep 12, 2018 at 5:11 PM Rich Freeman  wrote:
> > With new GCC comes new warnings, and harmless as the vast majority are
> > they cause the build to break with Werror.
>
> To illustrate harmless:
>   warning: this statement may fall through [-Wimplicit-fallthrough=]
> The warning message already has it in it that it's just a pure guess.

One that exposed a lot of unintentional fallthoughs which were fixed
when reporting to upstream.

Once again... we should discuss to leave -Werror when policy of
upstream to have no warnings and is maintaining that policy properly
while we at downstream may cooperate and avoid patching upstream but
discuss issues when found.

Re: [gentoo-dev] Changing policy about -Werror

[Alon Bar-Lev]

Hi,

I was the one that (re)trigger this discussion, I thank bircoph for
opening this up.

First, let me apologize that I did not test the capi USE for long
time, as this option is not used for long time by users, I am also
apologize of treating bug from anyone (may it be user, developer or
even qa) at the same SLA. It took one hour from report to fix
including evaluation of the issue and submitting the fix to upstream.
The package is non-stable for four months and stable in amd64 for a
while without users reporting that because as expected feature is
seldom used. Please avoid flaming me for this and address the
principal subject at hand as it is important.

I would like to suggest a modify our policy with the following
exception clause: Package maintainer may decide to keep upstream
-Werror as long as he is willing to resolve all issues resulting from
-Werror as if it was a blocker bug.

The package maintainer decision may be based on the package state and
the relationship with upstream, but basically, it is his decision as
long as issues are fixed in timely manner, it is his overhead after
all.

I am maintaining selected packages in which upstream is fully aware of
-Werror implications, accepting any patches to resolve issues found by
anyone. My judgment as Gentoo developer for these selected packages is
to absorb additional overhead in maintaining these packages while
helping upstream and users to enjoy higher quality. I've never assumed
that an effort individual project is willing to invest is something
that overrule by any other project as long as users receives a great
service (bugzilla stats are available).

I believe that a maintainer in Gentoo is a special role, we not only
helping users, but we also help upstream to improve their packages. We
are unique as permutations and architectures that are used by Gentoo
users are so diverse that we find issues that nobody else finds. In
addition to these, we also use latest and greatest toolchains, tools
and utilities, this triggers issues at Gentoo even before other
distributions.
Gentoo non-stable users are a great asset as they are willingly
helping to find these issues, with the understanding that their system
may break. A good relationship between Gentoo downstream maintainer
and upstream actually helps to find fixes long before other
distributions are affected. Even when I was in Red Hat, my policy was
Gentoo first, as a package that is built in Gentoo without tweaks will
be built successfully in all distributions (except of Java maven
packages in which we are far behind).

Over the years, many Gentoo developers, I included, have built
relationship with most active upstreams in my slot to push Gentoo
interests into upstream, I invite you to portage tree to see in how
many packages we drag patches from one version to another or to
evaluate ebuild tweaks. This mutual respect also suggests that if
upstream has a -Werror policy, in which every issue as minor as it can
be must be taken care of before package is considered to be usable, I
as downstream maintainer should help and apply the policy to help
upstream to improve its policy.

More and more upstream developers are aware of static code analysis
benefits, they use every source of information possible, opening
coverity to opensource made a great difference, the -Werror is yet
another tool to find unexpected issues. The collective mindset was
progressed greatly since 2009 where flameeyes opened bug#260867. At
least once per 10 years one should re-evaluate his policies, the
industry is changing.

When upstream policy is to have zero warnings policy, suppressed by
explicit suppression (code or compile argument), and when upstream is
friendly and actively following the policy of investigating each
incident and fix it properly, we can help for selected packages.

ARGUMENT: If a package compiled in the past using toolchain X then it
must continue to do so with any future toolchain.

I do not understand when "build" is the test for runtime, for 30 years
I tell my developers and students that "It compiles" and "It works"
are two different statements. One should only be thankful for any tool
to detect issues hidden within code, stop and re-evaluate when new
issues are found.

Let's take two recent examples from my queue:

bug#665464 in which there was unused return code variable, this made
me look into source code of upstream from master back in time until
code was introduced to find out when return code was used and why it
was removed, reaching to a conclusion that indeed return code should
be ignored and submitting a patch to upstream to validate that,
upstream confirmed and merged. Imagine what would happen if I would
have found that it is a real issue and should be addressed? Both users
and upstream would have benefit from finding and fixing the issue.

bug#664198 in which -Werror found mismatched memcpy, this was an
actual bug that must be fixed.

Based on the above we have in recent month one false 

Re: [gentoo-dev] Packages up for grabs: sys-apps/fakechroot, sys-apps/fakeroot-ng

[Alon Bar-Lev]

I can take them.

On Sun, Aug 19, 2018 at 11:24 AM Jonas Stein  wrote:

> Dear all,
>
> The following packages are up for grabs:
>
> sys-apps/fakechroot
> sys-apps/fakeroot-ng
>
> after retirement of the proxied maintainer.
> It was defacto maintained by various gentoo devs.
>
> https://packages.gentoo.org/packages/sys-apps/fakechroot
> https://packages.gentoo.org/packages/sys-apps/fakeroot-ng
>
> --
> Best,
> Jonas
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>

Re: [gentoo-dev] [News item review] Portage rsync tree verification (v2)

[Alon Bar-Lev]

On 26 January 2018 at 00:21, Robin H. Johnson <robb...@gentoo.org> wrote:
> On Thu, Jan 25, 2018 at 11:55:58PM +0200, Alon Bar-Lev wrote:
>> I did not looked into the detailed implementation, however, please
>> make sure integrity check handles the same cases we have applied to
>> emerge-webrsync in the past, including:
> Gemato is the implementation of GLEP74/MetaManifest, which DOES
> explicitly address both of these concerns.

Good!
Thanks.

>
>> 1. Fast forward only in time, this is required to avoid hacker to
>> redirect into older portage to install vulnerabilities that were
>> approved at that time.
> Replay attacks per #1 are addressed via TIMESTAMP field in MetaManifest.

Interesting, I tried again to understand how it is working without
performing rsync to a temporary directory, compare the timestamp and
reject if unexpected.
Are we doing multiple rsync for the metadata?
Long since I used this insecure rsync...

For me it seems like webrsync and/or squashfs are much easier/faster
to apply integrity into than rsync... :)

Regards,
Alon

Re: [gentoo-dev] [News item review] Portage rsync tree verification (v2)

[Alon Bar-Lev]

Hi,

On 25 January 2018 at 14:35, Michał Górny  wrote:
>
> Starting with sys-apps/portage-2.3.22, Portage enables cryptographic
> verification of the Gentoo rsync repository distributed over rsync
> by default. This aims to prevent malicious third parties from altering
> the contents of the ebuild repository received by our users.



I did not looked into the detailed implementation, however, please
make sure integrity check handles the same cases we have applied to
emerge-webrsync in the past, including:
1. Fast forward only in time, this is required to avoid hacker to
redirect into older portage to install vulnerabilities that were
approved at that time.
2. Content integrity, especially removal, as far as I understand, the
mechanism will not enable to detect authorized removal of content.

Regards,
Alon

Re: [gentoo-dev] profiles 17.0 hardened/no-multilib missing?

[Alon Bar-Lev]

On 2 December 2017 at 23:08, Michał Górny <mgo...@gentoo.org> wrote:
>
> W dniu sob, 02.12.2017 o godzinie 22∶43 +0200, użytkownik Alon Bar-Lev
> napisał:
> > Hi,
> > Any reason we do not publish hardened/no-multilib?
> > I see we have[1] in place and is working if explicitly added.
> >
>
> One reason might be that:

Thanks.

>
> 1) there's barely any use for it,

Well, I think that whoever use hardened barely use multilib.

> 2) we have too many profiles, and

This has not stopped us so far.

> 3) every added profile slows down repoman & pkgcheck seriously.

Only when using '-d', no?
Anyway, probably the default of hardened should be multilib so we end
up with the same number.

> > [1] profiles/features/hardened/amd64/no-multilib

Regards,
Alon

[gentoo-dev] profiles 17.0 hardened/no-multilib missing?

[Alon Bar-Lev]

Hi,
Any reason we do not publish hardened/no-multilib?
I see we have[1] in place and is working if explicitly added.
Thanks,
Alon

[1] profiles/features/hardened/amd64/no-multilib

Re: [gentoo-dev] dev-libs/cryptlib masked for removal in 30 days

[Alon Bar-Lev]

On 8 September 2017 at 22:44, R0b0t1 <r03...@gmail.com> wrote:
>
> On Fri, Sep 8, 2017 at 2:40 PM, Alon Bar-Lev <alo...@gentoo.org> wrote:
> > Complex build system, hard to maintain, no dependencies in tree, upstream
> > does not cooperate (Bug#630420).
> > Removal in 30 days.
> >
>
> I don't have any reason to disagree with this but I expected a
> citation for those things to be in the bug you referenced. They're
> not, and I don't see any bugs on the tracker.

The effort of upgrade per each version is becoming greater.
Previous and next versions required significant work, issues reported
to upstream with the hope of a change, but most is rejected.
The build system is so complex that is specific to gcc/ld and
hard-coded dependencies locations and cflags/ldflags magic.
Unless we have a very good reason (important dependency), my
suggestion is to drop it.
Do we have such a reason?

[gentoo-dev] dev-libs/cryptlib masked for removal in 30 days

[Alon Bar-Lev]

Complex build system, hard to maintain, no dependencies in tree, upstream
does not cooperate (Bug#630420).
Removal in 30 days.

[gentoo-dev] sys-auth/pam_pkcs11 masked for removal in 30 days

[Alon Bar-Lev]

Upstream no longer maintain (Bug#628908).
Removal in 30 days.

[gentoo-dev] Call for help in testing - sparc + gnutls-3.5

[Alon Bar-Lev]

Hello,

I am looking for someone that is using gentoo on sparc and is willing to
help out to resolve an issue[1] of gnutls-3.5 with sparc so that we can
drop gnutls-3.3 from tree.

I tried to create a bootable sparc qemu gentoo image and failed, so need
someone with a live system.

Regards,
Alon

[1] https://bugs.gentoo.org/show_bug.cgi?id=613418

Re: [gentoo-dev] dev-libs/libressl: mingw-w64 build calls wine

[Alon Bar-Lev]

On 18 May 2017 at 07:10, Marty Plummer <netz.ker...@gmail.com> wrote:
> On Thu, May 18, 2017 at 06:53:48AM +0300, Alon Bar-Lev wrote:
>> On 18 May 2017 at 06:54, Marty Plummer <netz.ker...@gmail.com> wrote:
>> > Greetings,
>> >
>> > As the subject states, compiling dev-libs/libressl for x86_64-w64-mingw32
>> > target via crossdev ends up calling wine to run checks, which fails with
>> > an access violation, and as such emerge cannot finish.
>> >
>> > Would it be an acceptable change to disable emake check for mingw-w64
>> > crossdev targets?
>> >
>>
>> Why do you enable tests?
>>
> I did not, there is no use flag for dev-libs/libressl I can use to
> disable tests. if there is a global flag I should disable, I'd be
> greatly appreciative of it.
>

If you enable tests globally, then you can disable them for a specific
build using:
FEATURES="-test" emerge ...

Re: [gentoo-dev] dev-libs/libressl: mingw-w64 build calls wine

[Alon Bar-Lev]

On 18 May 2017 at 06:54, Marty Plummer  wrote:
> Greetings,
>
> As the subject states, compiling dev-libs/libressl for x86_64-w64-mingw32
> target via crossdev ends up calling wine to run checks, which fails with
> an access violation, and as such emerge cannot finish.
>
> Would it be an acceptable change to disable emake check for mingw-w64
> crossdev targets?
>

Why do you enable tests?

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

[Alon Bar-Lev]

On 18 May 2017 at 06:46, Matthias Maier  wrote:
> [2] I had to manually disable libsanitizer for gcc-6.3.0. Just set
> EXTRA_ECONF="--disable-libsanitizer" via env/package.env for the
> cross-x86_64-w64-mingw32/gcc package.

Hi,
You should use the USE flags and not apply such workarounds, for example:
USE="-sanitizer" crossdev ...
Alon

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

[Alon Bar-Lev]

Hi,
You can emerge crossdev and then run crossdev -t x86_64-w64-mingw32 or
crossdev -t i686-w64-mingw32
Alon

On 18 May 2017 at 01:25, 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 libraries.
>
> I'm considering the idea of setting up a sort of prefix specifically
> with the intent of being used on a 'normal' gentoo system with the sole
> purpose of creating 'normal' windows binaries; does anyone have
> suggestions/objections about the idea?
>
> As it currently stands I have to use an archlinux chroot to do my
> cross-compiling, and I'd really enjoy to be able to do this sort of
> thing without depending on an auxiliary distro.
>
> Marty.
>

[gentoo-dev] gnutls-3.5 last remaining issues - please assist

[Alon Bar-Lev]

Hello,

I would like to push gnutls-3.5 into stable per[1].

Below are known related issues we still have, please help to push these forward.

If anyone wishes to help testing before we progress, please move to
non-stable gnutls and report back any issue.

Please also emerge using the following settings and report back any failure:

   USE="test-full" FEATURES="test" emerge gnutls

Thanks,
Alon

[1] https://bugs.gentoo.org/showdependencytree.cgi?id=612340_resolved=1

---

url:  https://bugs.gentoo.org/show_bug.cgi?id=595952
desc:   net-libs/glib-networking-2.48.2 with
net-libs/gnutls-3.5.4[-sslv3] fails test...
owner: gnome
If it is only test issue, we should disable the test.

url:  https://bugs.gentoo.org/show_bug.cgi?id=613418
desc:   net-libs/gnutls-3.5.10 fails cert-key-exchange tests on sparc
owner: sparc
We have outage of sparc machine, if anyone with sparc can help it
would be great.

url:  https://bugs.gentoo.org/show_bug.cgi?id=615008
desc:   =sys-devel/autogen-5.18.4 - please add slot operator for guile
owner: toolchain
As the guile tests requires guile-2, it will be nice if we can have
this to allow seamless upgrade/downgrade of guile without experiencing
autogen issues.

url:  https://bugs.gentoo.org/show_bug.cgi?id=612348
desc:   =app-admin/gkrellm-2.3.10 stable request
owner: hppa, ia64, sparc
gnutls-3.5 compatibility

url:  https://bugs.gentoo.org/show_bug.cgi?id=612344
desc:   =mail-client/cone-0.92 stable request
owner: ppc
gnutls-3.5 compatibility

url:  https://bugs.gentoo.org/show_bug.cgi?id=391463
desc:   Please stabilize =dev-libs/iksemel-1.4
owner: ppc
gnutls-3.5 compatibility, a patch is available to fix test failure on ppc.

[gentoo-dev] dev-libs/engine_pkcs11 masked for removal in 30 days

[Alon Bar-Lev]

Replaced by dev-libs/libp11 unmaintained by upstream.
Bug#609668. Removal in 30 days.

[gentoo-dev] net-misc/gnutls-3.4 stabilization

[Alon Bar-Lev]

Hi,
I would like to start stabilizing gnutls-3.4.
If anyone is aware of an issue please speak up.
Thanks!
Alon

Re: [gentoo-dev] RFC: Future EAPI version operator changes

[Alon Bar-Lev]

On 6 November 2016 at 12:52, Michał Górny  wrote:
> Hi, everyone.



> So, what are your comments?

Hi,

Just my 2 cents...
I kinda love the prefix nature of the expressions which is consistent
and easier to parse.
Using infix only for versions and leaving all the rest prefix will
create abnormality.

Regards,
Alon

[gentoo-dev] dev-python/pssi package masked for removal in 30 days

[Alon Bar-Lev]

# Alon Bar-Lev <alo...@gentoo.org> (05 Nov 2016)
# Masked for removal in 30 days, bug#598982.
# Upstream does not publish releases, no tags, last publish is on
# google code, no dependencies.
dev-python/pssi

[gentoo-dev] app-crypt/scl011-bin package masked for removal in 30 days

[Alon Bar-Lev]

# No upstream, no maintainer (bug #592164)
# Package will be removed from Gentoo in 30 days.
app-crypt/scl011-bin

[gentoo-dev] app-crypt/bcrypt package masked for removal in 30 days

[Alon Bar-Lev]

# Weak cryptography (bug #592114)
# Package will be removed from Gentoo in 30 days.
app-crypt/bcrypt

Re: [gentoo-dev] Last rites: kde-apps/ksnapshot

[Alon Bar-Lev]

On 14 July 2016 at 23:15, Johannes Huber <j...@gentoo.org> wrote:
> Am Donnerstag 14 Juli 2016, 21:47:10 schrieb Alon Bar-Lev:
>> I have only three: Application, Global, Web
>> Shouldn't it be integrated into Global?
>
> Maybe this helps:
> https://bbs.archlinux.org/viewtopic.php?id=206600

yes, I saw that, I thought it is older version of plasma as. I tried
to installed khotkeys before I sent my question and it did not show
the new tab, now I tried again just to make sure and it does, strange.
When I installed it it created the ~/.config/khotkeysrc without the
spectacle profile, I had to remove it logout/login in order to make it
work.

please consider making khotkeys a dependency of spectacle.

Regards,
Alon

Re: [gentoo-dev] Last rites: kde-apps/ksnapshot

[Alon Bar-Lev]

I have only three: Application, Global, Web
Shouldn't it be integrated into Global?

On 14 July 2016 at 21:44, Johannes Huber <j...@gentoo.org> wrote:
> Please check systemsettings -> shortcuts -> 4th tab.
>
> Greetings,
> Johannes
>
> Am Donnerstag 14 Juli 2016, 21:26:04 schrieb Alon Bar-Lev:
>> Just tried to switch.
>> Print-Screen shortcut is not working, any idea why?
>> Saw some similar issues, but could not find out what is wrong as most
>> of the fixes are embedded.
>> Thanks!
>>
>> On 14 July 2016 at 20:33, Johannes Huber <j...@gentoo.org> wrote:
>> > # Johannes Huber <j...@gentoo.org> (14 Jul 2016)
>> > # No longer released upstream. Use kde-apps/spectacle instead.
>> > # Masked for removal in 30 days.
>> > kde-apps/ksnapshot
>
>

Re: [gentoo-dev] Last rites: kde-apps/ksnapshot

[Alon Bar-Lev]

Just tried to switch.
Print-Screen shortcut is not working, any idea why?
Saw some similar issues, but could not find out what is wrong as most
of the fixes are embedded.
Thanks!

On 14 July 2016 at 20:33, Johannes Huber  wrote:
>
> # Johannes Huber  (14 Jul 2016)
> # No longer released upstream. Use kde-apps/spectacle instead.
> # Masked for removal in 30 days.
> kde-apps/ksnapshot

Re: [gentoo-dev] dev-util/nsis: Maintainer request

[Alon Bar-Lev]

Can you please check it out?
I had no time nor setup.

On 12 June 2016 at 14:49, M. J. Everitt <m.j.ever...@iee.org> wrote:
> Cheers Alon,
>
> Michael.
> On 12/06/16 12:43, Alon Bar-Lev wrote:
>> Hi,
>> I've revbumped this package.
>> Regards,
>> Alon
>>
>> On 6 June 2016 at 03:23, M. J. Everitt <m.j.ever...@iee.org> wrote:
>>> On 05/06/16 22:55, Kristian Fiskerstrand wrote:
>>>> dev-util/nsis curretly has no maintainer. It has a [critical security
>>>> bug filed against it]. Does anyone want to pick it up? if not we'll
>>>> start a last rite process for it.
>>>>
>>>> [critical security bug filed against it]
>>>> https://bugs.gentoo.org/show_bug.cgi?id=568398
>>> Per conversation in #g-p-m I'll take this on via proxy if nobody else
>>> volunteers in the next 7 days (w/e 12th June) to start with, as I'm
>>> pretty sure a colleague is using it on a project, and we could do
>>> without losing it from the tree .. !
>>>
>>> Quick glance at the project page, and bug suggests revbump, stabilise
>>> and drop old version might cure the existing issue, but will investigate
>>> further.
>>> Cheers,
>>> Michael.
>>>
>
>

Re: [gentoo-dev] dev-util/nsis: Maintainer request

[Alon Bar-Lev]

Hi,
I've revbumped this package.
Regards,
Alon

On 6 June 2016 at 03:23, M. J. Everitt  wrote:
> On 05/06/16 22:55, Kristian Fiskerstrand wrote:
>> dev-util/nsis curretly has no maintainer. It has a [critical security
>> bug filed against it]. Does anyone want to pick it up? if not we'll
>> start a last rite process for it.
>>
>> [critical security bug filed against it]
>> https://bugs.gentoo.org/show_bug.cgi?id=568398
> Per conversation in #g-p-m I'll take this on via proxy if nobody else
> volunteers in the next 7 days (w/e 12th June) to start with, as I'm
> pretty sure a colleague is using it on a project, and we could do
> without losing it from the tree .. !
>
> Quick glance at the project page, and bug suggests revbump, stabilise
> and drop old version might cure the existing issue, but will investigate
> further.
> Cheers,
> Michael.
>

Re: [gentoo-dev] RFC: new USE="win32" flag for mingw and prefix/windows support

[Alon Bar-Lev]

On 20 April 2016 at 18:52, Ian Stakenvicius  wrote:
>
> Hi everyone:
>
> After doing some experimentation with a mingw crossdev, I found that I
> needed to do a lot of EXTRA_ECONF settings in combination with
> USE="aqua" in order to get packages supporting a win32 API to be
> configured appropriately.  In order to support this situation better,
> I propose adding a new global flag 'win32', modelled after the 'aqua'
> flag, that can be used instead to provide this configuration directly
> in ebuilds.
>
> Just like USE="aqua", the flag will be use.mask'ed in base/ so that
> users don't erroneously enable it.  I didn't un-use.mask it anywhere
> yet since (A) I don't have a prefix/windows environment to test, and
> (B) the mingw-based crossdev environments use profiles/embedded by
> default, which doesn't inherit from profiles/base and so doesn't have
> the use.mask restriction.
>
> The attached patch lists the necessary changes to profile/ as well as
> the addition of USE=win32 to *ONE VERSION* of gtk+:2, gtk+:3 and cairo
> (the actual commit will include more versions).
>
> Comments?

You should be able to achieve similar behavior by looking at libc
and/or CHOST without introducing new USE flag, just like we do for
aix/solaris/freebsd etc...

Re: [gentoo-dev] Changing order of default virtual/udev provider

[Alon Bar-Lev]

On 14 February 2016 at 22:23, Mike Frysinger  wrote:
> udev: it's the default in every major distro that everyone tests and
> develops against.
>
> eudev: no one of any relevance outside of Gentoo runs it.

I honestly don't understand this argument that pops over and over.

No "major distro" using udev without systemd, so OpenRC people are
already using udev in unsupported setup.

Better to use a tool that is tested and supported in this setup.

Or maybe I do not understand and mission is for us to switch to systemd?

Systemd users/developers should not mind what the default is as they
are forced to use one variant anyway, these users/developers should
not force their opinion upon others.

Thanks,
Alon

Re: [gentoo-dev] Changing order of default virtual/udev provider

[Alon Bar-Lev]

On 9 February 2016 at 13:59, Rich Freeman  wrote:
>
> On Tue, Feb 9, 2016 at 12:27 AM, Anthony G. Basile  
> wrote:
> > On 2/8/16 10:09 PM, Rich Freeman wrote:
> >> How many of those 14 distros have more than 14 users?
> >
> > gentoo is very unpopular as a distro.  however, it excels as a meta
> > distro.  if you marginalize its special features, you take away all its
> > charm.
>



> The controversy comes in when you want to make it a default, and start
> arguing that it is somehow better than the solution everybody else is
> using.
>
> Outside of Gentoo people either aren't concerned at all with eudev (it
> probably isn't even in their distro repositories), or they're a tiny
> distro whose main purpose in life seems to be to avoid installing
> systemd.  Of course you're going to get praise from them.
>
> I've always supported having eudev hosted by Gentoo.  I just don't
> support it being the default udev provider.
>

I too support eudev as default for openrc people, Gentoo is about
choice, and OpenRC eco-system should get rid of all systemd related
dependencies. This is a choice we provide. eudev should stand as its
own and provide a service for the non-systemd users, these users
actually care about what we provide, Gentoo is one of the last distros
that enables that. I use eudev since its first beta, and these guys
provides good service.

I also mask all systemd files that somehow find their way into my
system thanks to your past decisions as systemd supporter, instead of
installing these only when systemd USE flag is set and adding openrc
USE flag for the systemd users folks.

It may in future that udev will completely relay on systemd and we
left with eudev as the only choice for non systemd-eco system, it is
better to start building this eco-system now, make sure we have a
working solution at any given point in time.

Alon

Re: [gentoo-dev] [RFC] name of smartcard support USE flag

[Alon Bar-Lev]

On 13 December 2015 at 18:20, Gilles Dartiguelongue  wrote:
>
> I was trying to cleanup my local USE flag settings and stumbled on the
> following three: smartcard, pcsc-lite and pkcs11.
>
> Knowing all 3 are related, I greped use.local.desc to see what each
> meant for different packages. To sum up what I found:
>  * pcsc-lite is basically: enable smartcard support through sys-
> apps/pcsc-lite
>  * pkcs11: enabled PKCS#11 (smartcard) via $pkg
>
> These look like the same thing to me so I propose we merge them all
> into USE=smartcard as this is the feature being enabled, not the lib or
> the standard being used to access the hardware if any.

pcsc-lite and PKCS#11 interfaces are both related to smartcards but
different unrelated interfaces. I am unsure merging them will serve
the purpose for applications that are capable of supporting more than
one interface.

also, please notice that PKCS#11 is not all about smartcards, but an
interface to any cryptographic hardware.

Regards,
Alon

Re: [gentoo-dev] [RFC] name of smartcard support USE flag

[Alon Bar-Lev]

On 13 December 2015 at 19:28, Gilles Dartiguelongue <e...@gentoo.org> wrote:
> Le dimanche 13 décembre 2015 à 18:25 +0200, Alon Bar-Lev a écrit :
>> On 13 December 2015 at 18:20, Gilles Dartiguelongue <e...@gentoo.org>
>> wrote:
>> >
>> > I was trying to cleanup my local USE flag settings and stumbled on
>> > the
>> > following three: smartcard, pcsc-lite and pkcs11.
>> >
>> > Knowing all 3 are related, I greped use.local.desc to see what each
>> > meant for different packages. To sum up what I found:
>> >  * pcsc-lite is basically: enable smartcard support through
>> > sys-
>> > apps/pcsc-lite
>> >  * pkcs11: enabled PKCS#11 (smartcard) via $pkg
>> >
>> > These look like the same thing to me so I propose we merge them all
>> > into USE=smartcard as this is the feature being enabled, not the
>> > lib or
>> > the standard being used to access the hardware if any.
>>
>> pcsc-lite and PKCS#11 interfaces are both related to smartcards but
>> different unrelated interfaces. I am unsure merging them will serve
>> the purpose for applications that are capable of supporting more than
>> one interface.
>
>> also, please notice that PKCS#11 is not all about smartcards, but an
>> interface to any cryptographic hardware.
>
> I agree with your points, my point is that it seems most of the time,
> both use flags are used in place of smartcard (or another name if this
> one does not fit in your opinion).
>
> According to local description, app-mobilephone/gnoki, net-
> libs/libosmocore and net-misc/rdesktop at least should be using
> USE=smartcard instead of USE=pcsc-lite

rdesktop - I agree.
I do not know the other packages.

Re: [gentoo-dev] [RFC] name of smartcard support USE flag

[Alon Bar-Lev]

On 13 December 2015 at 19:30, Alon Bar-Lev <alo...@gentoo.org> wrote:
> On 13 December 2015 at 19:28, Gilles Dartiguelongue <e...@gentoo.org> wrote:
>> Le dimanche 13 décembre 2015 à 18:25 +0200, Alon Bar-Lev a écrit :
>>> On 13 December 2015 at 18:20, Gilles Dartiguelongue <e...@gentoo.org>
>>> wrote:
>>> >
>>> > I was trying to cleanup my local USE flag settings and stumbled on
>>> > the
>>> > following three: smartcard, pcsc-lite and pkcs11.
>>> >
>>> > Knowing all 3 are related, I greped use.local.desc to see what each
>>> > meant for different packages. To sum up what I found:
>>> >  * pcsc-lite is basically: enable smartcard support through
>>> > sys-
>>> > apps/pcsc-lite
>>> >  * pkcs11: enabled PKCS#11 (smartcard) via $pkg
>>> >
>>> > These look like the same thing to me so I propose we merge them all
>>> > into USE=smartcard as this is the feature being enabled, not the
>>> > lib or
>>> > the standard being used to access the hardware if any.
>>>
>>> pcsc-lite and PKCS#11 interfaces are both related to smartcards but
>>> different unrelated interfaces. I am unsure merging them will serve
>>> the purpose for applications that are capable of supporting more than
>>> one interface.
>>
>>> also, please notice that PKCS#11 is not all about smartcards, but an
>>> interface to any cryptographic hardware.
>>
>> I agree with your points, my point is that it seems most of the time,
>> both use flags are used in place of smartcard (or another name if this
>> one does not fit in your opinion).
>>
>> According to local description, app-mobilephone/gnoki, net-
>> libs/libosmocore and net-misc/rdesktop at least should be using
>> USE=smartcard instead of USE=pcsc-lite
>
> rdesktop - I agree.

BTW: why don't you use net-misc/freerdp, works better to me and does
have smartcard USE :)

> I do not know the other packages.

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: dev-libs/libgcrypt/files/, dev-libs/libgcrypt/

[Alon Bar-Lev]

On 2 December 2015 at 21:52, Michał Górny <mgo...@gentoo.org> wrote:
> On Wed, 2 Dec 2015 21:48:24 +0200
> Alon Bar-Lev <alo...@gentoo.org> wrote:
>
>> On 2 December 2015 at 21:45, Brian Evans <grkni...@gentoo.org> wrote:
>> >
>> > -BEGIN PGP SIGNED MESSAGE-----
>> > Hash: SHA1
>> >
>> > On 12/1/2015 1:45 AM, Alon Bar-Lev wrote:
>> > > Yes, sorry my bad, repoman did not complain.
>> >
>> > This is still not working because some packages, i.e sys-fs/ntfs3g,
>> > have a dependency like >
>> in this specific case ntfs3g-2014.2.15-r1 is stable the previous
>> versions should be cleaned up.
>
> It is *your* responsibility to ensure that previous versions are
> cleaned up *before* you remove libgcrypt. Also, I'm more worried about
> sys-power/suspend where the stable version still requires it. And yes,
> you've broken the stable tree and I'd really appreciate having it fixed
> right away.

OK, done.

>
> --
> Best regards,
> Michał Górny
> <http://dev.gentoo.org/~mgorny/>

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: dev-libs/libgcrypt/files/, dev-libs/libgcrypt/

[Alon Bar-Lev]

On 2 December 2015 at 21:45, Brian Evans <grkni...@gentoo.org> wrote:
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 12/1/2015 1:45 AM, Alon Bar-Lev wrote:
> > Yes, sorry my bad, repoman did not complain.
>
> This is still not working because some packages, i.e sys-fs/ntfs3g,
> have a dependency like 

[gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: dev-libs/libgcrypt/files/, dev-libs/libgcrypt/

[Alon Bar-Lev]

Yes, sorry my bad, repoman did not complain.

On 1 December 2015 at 08:44, Michał Górny <mgo...@gentoo.org> wrote:
> On Tue,  1 Dec 2015 06:16:40 + (UTC)
> "Alon Bar-Lev" <alo...@gentoo.org> wrote:
>
>> commit: 1519f072b810c69428badbe5fc54960f1a2a12b3
>> Author: Alon Bar-Lev  gentoo  org>
>> AuthorDate: Tue Dec  1 06:16:26 2015 +
>> Commit: Alon Bar-Lev  gentoo  org>
>> CommitDate: Tue Dec  1 06:16:26 2015 +
>> URL:https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=1519f072
>>
>> dev-libs/libgcrypt: cleanup
>>
>> Package-Manager: portage-2.2.20.1
>>
>>  dev-libs/libgcrypt/Manifest|  1 -
>>  .../libgcrypt/files/libgcrypt-1.5.0-uscore.patch   | 33 -
>>  .../files/libgcrypt-1.5.4-clang-arm.patch  | 84 
>> --
>>  dev-libs/libgcrypt/libgcrypt-1.5.4-r1.ebuild   | 57 ---
>>  dev-libs/libgcrypt/libgcrypt-1.5.4-r100.ebuild | 58 ---
>
> Isn't the point of compatibility slots like :11 there that they should
> be kept for binary packages to work? Because you just removed that,
> plus all 1.5* versions, effectively causing huge breakage:
>
> https://qa-reports.gentoo.org/output/gentoo-ci/c08cdfb/2.html#l1193
> https://qa-reports.gentoo.org/output/gentoo-ci/c08cdfb/2.html#l1219
> https://qa-reports.gentoo.org/output/gentoo-ci/c08cdfb/3.html#l1082
> https://qa-reports.gentoo.org/output/gentoo-ci/c08cdfb/3.html#l1108
> https://qa-reports.gentoo.org/output/gentoo-ci/c08cdfb/3.html#l1134
> https://qa-reports.gentoo.org/output/gentoo-ci/c08cdfb/3.html#l1997
> https://qa-reports.gentoo.org/output/gentoo-ci/c08cdfb/11.html#l208
> https://qa-reports.gentoo.org/output/gentoo-ci/c08cdfb/11.html#l234
> https://qa-reports.gentoo.org/output/gentoo-ci/c08cdfb/11.html#l249
> https://qa-reports.gentoo.org/output/gentoo-ci/c08cdfb/11.html#l460
> https://qa-reports.gentoo.org/output/gentoo-ci/c08cdfb/12.html#l898
> https://qa-reports.gentoo.org/output/gentoo-ci/c08cdfb/12.html#l2088
>
> Please fix this ASAP and next time check reverse dependencies before
> removing packages.
>
> --
> Best regards,
> Michał Górny
> <http://dev.gentoo.org/~mgorny/>

Re: [gentoo-dev] Re: rfc: openrc mount service prototype

[Alon Bar-Lev]

On 30 July 2015 at 19:15, Ian Stakenvicius a...@gentoo.org wrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA256

 On 30/07/15 01:55 AM, Duncan wrote:
  Patrick McLean posted on Wed, 29 Jul 2015 15:35:02 -0700 as
  excerpted:
 
  On Thu, 30 Jul 2015 01:11:30 +0300 Alon Bar-Lev
  alo...@gentoo.org wrote:
 
  On 29 July 2015 at 23:20, William Hubbs willi...@gentoo.org
  wrote:
 
  so that there is a better idea out there of what I'm talking
  about, the OpenRC github repository now has a mount-service
  branch.
 
  But I still trying to figure out why do we need to keep fstab
  around. It is pure legacy.
 
 
  On what planet is fstab pure legacy? Many utilities use it and
  expect it to exist. For example the ability to do mount /foo
  requires a properly configured fstab file (also mount -a).
 

 I think there are two meanings of the word legacy here.

 #1, /etc/fstab on linux is not legacy, and I don't think anyone here
 (except possibly for WilliamH as I can't actually tell from his
 statements) has been calling it 'legacy' in this context.

/etc/fstab is legacy in the sense it did not evolve since early days of UNIX.
Imagine /etc/crontab was left the same single file, but it at least
evolved to usr /etc/cron.*/ to ease management of multiple sources and
ease packaging/maintenance without need to parse and rewrite single
file when provisioning.

Nobody ignores /etc/fstab existence, I provided solutions of how
/etc/fstab can be read in flexible method as netifrc does (which was
actually the core idea of this move), doing so will make the service
much simpler as it can use external helper scripts to provide the data
out of whatever source, please re-read my message.

However, having the option *NOT* to use /etc/fstab has many advantages
in security (storing credentials in own files), provisioning (no need
to race parse/rewrite), dynamic (define the location of nfs server
based on logic) and many more.

I do not understand why people are so sensitive for a change that does
not effect the outcome of their need, all that I recommended to add is
driver:

mount_driver_\${NAME}=fstab
mount_mountpoint_\${NAME}=/mnt/auto

driver will be executed by the service, in this case:

openrc-mount-helper-${openrc_mount_driver_\${NAME}}
${mount_mountpoint_\${NAME}}

the output will be evaluated. This simple solution will enable the
service to be generic and provide flexible pure configuration
(whatever we choose), while support any source of information that is
capable of constructing this configuration.

Loose nothing gain some, simpler service and constraint fstab within driver.

Another drive I can think of is UPnP.

Regards,
Alon

Re: [gentoo-dev] rfc: openrc mount service prototype

[Alon Bar-Lev]

On 29 July 2015 at 23:20, William Hubbs willi...@gentoo.org wrote:

 All,

 so that there is a better idea out there of what I'm talking about, the
 OpenRC github repository now has a mount-service branch.

Nice!

But I still trying to figure out why do we need to keep fstab around.
It is pure legacy.

There can be a migration script to generate /etc/conf.d/*
configuration once, but there is no need to keep it around.
The conf.d can contain everything that fstab contains.

mount_mountpoint_\${NAME}=
mount_type_\${NAME}=
mount_fs_\${NAME}=
mount_opts_\${NAME}=
mount_dump_\${NAME}=
mount_pass_\${NAME}=

There can even be a script to set above environments from fstab as
pure utility given mountpoint as parameter. This will simplify the
service as it will always accept the variables at one form.

Regards,
Alon

Re: [gentoo-dev] rfc: openrc mount service prototype

[Alon Bar-Lev]

On 30 July 2015 at 01:33, William Hubbs willi...@gentoo.org wrote:
 On Wed, Jul 29, 2015 at 05:22:54PM -0500, William Hubbs wrote:
 On Thu, Jul 30, 2015 at 01:11:30AM +0300, Alon Bar-Lev wrote:
  On 29 July 2015 at 23:20, William Hubbs willi...@gentoo.org wrote:
  
   All,
  
   so that there is a better idea out there of what I'm talking about, the
   OpenRC github repository now has a mount-service branch.
 
  Nice!
 
  But I still trying to figure out why do we need to keep fstab around.
  It is pure legacy.

 Is it? I have heard different people say it is, and it isn't, so I have
 no idea.

 If fstab is truly legasy, I'll look into that.

 It seems that it is not legasy...

 For example, what happens if you do:

 mount /foo/bar

 and don't have fstab?

 William


if I choose to not use fstab, I will not use mount /foo/bar

Why will I do that?
For example, I can put passwords in different ACL.
I can add logic, for example dynamic mount point.
This is why using netifrc like configuration is so great.

I can choose to use fstab, then I lost all these goodies but can do
mount /foo/bar...

Re: [gentoo-dev] rfc: openrc mount service prototype

[Alon Bar-Lev]

On 30 July 2015 at 01:22, William Hubbs willi...@gentoo.org wrote:
 On Thu, Jul 30, 2015 at 01:11:30AM +0300, Alon Bar-Lev wrote:
 On 29 July 2015 at 23:20, William Hubbs willi...@gentoo.org wrote:
 
  All,
 
  so that there is a better idea out there of what I'm talking about, the
  OpenRC github repository now has a mount-service branch.

 Nice!

 But I still trying to figure out why do we need to keep fstab around.
 It is pure legacy.

 Is it? I have heard different people say it is, and it isn't, so I have
 no idea.

 If fstab is truly legasy, I'll look into that.

for what it worth, a fstab.d would have been something usable... :)

but if you are providing netifrc like configuration, there is no need
to split configuration between the layout and the fstab, everything
should be at one place if possible.

maybe we can have some intermediate options... to bridge the gap, but
all are in the scope of conf.d, examples:

eval $(openrc-mount-helper-fstab ${NAME} /mnt/auto)

or... builtin

mount_driver_\${NAME}=fstab  # will call eval
$(openrc-mount-helper-${openrc-mount-driver-\${NAME}} ${NAME} $@)
mount_mountpoint=/mnt/auto

but this fstab usage is optional.

Re: [gentoo-dev] rfc: improve file system mounting and unmounting in OpenRC

[Alon Bar-Lev]

On 28 July 2015 at 01:26, William Hubbs willi...@gentoo.org wrote:
 The proposal in [3], on the other hand, is to create a mount script that
 works like netifrc. It would mount a single file system, which would be
 determined by the link it was called from, much like how netifrc
 determines which interface to work on.

Hi,

This is great and consistent with all other services.

What I would like to see is how to not relay on /etc/fstab content, if possible.

If it is like netifrc, there can be fstab module that provides entries
for fstab.

It can be in /etc/conf.d/filesystem.@name@ instead of openrc core. for example:
---
modules=fstab
config__usr=fstab # replace /-_
---

Regards,
Alon

Re: [gentoo-dev] Git, GPG Signing, and Manifests

[Alon Bar-Lev]

On 17 July 2015 at 15:36, Rich Freeman ri...@gentoo.org wrote:
 On Fri, Jul 17, 2015 at 12:42 AM, Brian Dolbec dol...@gentoo.org wrote:

 I don't know tbh, most are already signed, with the git migration, the
 strongly recommended commit signing will become MANDATORY.

 So, we are at 50 devs with valid gpg keys now, with 200 more gpg keys
 listed in LDAP that fail to meet the new spec.  PLEASE fix them or
 create new keys...

 How does somebody know whether their key meets the spec or not?  I
 looked at the gentoo-keys website and didn't see any simple way to
 check.

 There was documentation on the gkeys utility for checking keys, but I
 ran into a few issues with this.  First, it can't be installed on a
 stable system with mirrorselect.

The use of keys should be by counter signature, when pushing the
counter signature service should check if signature is valid and dev
key is valid using the internal ldap for example, and counter sign
with its own key and add timestamp. Users should trust only the
counter signature service key which is formal and should be valid for
long time.

This is yet another reason why it is best to not use signature within
git but remain the signed manifest. When commit one can sign the
manifest, send the manifest to the counter signature service and
obtain a formal signed manifest to be committed into tree.

Using signed manifest also reduce the merge conflict, survive rebase,
enable code review without loosing original signer and will enable
future migration to other technology.

Regards,
Alon

Re: [gentoo-dev] Git workflow

[Alon Bar-Lev]

On 4 July 2015 at 23:28, Alexandre Rostovtsev tetrom...@gentoo.org wrote:

 On Sun, 2015-07-05 at 02:16 +0700, C Bergström wrote:
  2) I don't understand your comment about signatures.

 Gpg commit signatures [1] which are a requirement for any gentoo git
 workflow. Rebasing breaks the author's signature afaict, so the user
 who is doing rebasing needs to re-sign the commit using his own key.

 [1] https://git-scm.com/book/tr/v2/Git-Tools-Signing-Your-Work#Signing-Commits


Maybe this is the root cause of all issues, and simpler was to remain
with signed manifests.
Just a thought... Not every git feature out there should be actually
be leveraged.
Doing so would enable rebase without loosing data, more secure (than
SHA-1) signatures, using code review tools such as gerrit without an
issue, migration out of git in future and probably more.

Re: [gentoo-dev] News item review: SquashDelta syncing support

[Alon Bar-Lev]

On 15 May 2015 at 17:51, Michał Górny mgo...@gentoo.org wrote:
 Please note that the current syncing code does not verify the OpenPGP
 signature to confirm the authenticity of fetched snapshots and deltas.
 This feature will be added as soon as gentoo-keys support in Portage is
 available.

These are great news!
We can retire the webrsync.
Why not sign it similar to the portage snapshot are signed for now?
The webrsync signature validation is quite simple.

Just a reminder: please note the rollback prevention mechanism in
webrsync, it is not enough to check signature, but also prevent older
snapshot to be used.

Regards,
Alon

[gentoo-dev] bugs.gentoo.org and dnssec

[Alon Bar-Lev]

Hi,

Not sure where the problem is... maybe others can reproduce this.

When using bugs.gentoo.org with dnsmasq and dnssec enabled, I cannot
access attachments.

The attachments are forwarded to a CNAME, for example:
---
546330.bugs.gentoo.org. 60  IN  CNAME   bugs-gossamer.gentoo.org.
bugs-gossamer.gentoo.org. 300   IN  CNAME   gannet.gentoo.org.
gannet.gentoo.org.  604800  IN  A   204.187.15.4
---

When trying to access without dnssec all is ok:
---
Apr 21 20:19:04 [dnsmasq] query[A] 546330.bugs.gentoo.org from 127.0.0.1
Apr 21 20:19:04 [dnsmasq] forwarded 546330.bugs.gentoo.org to 192.168.1.1
Apr 21 20:19:04 [dnsmasq] validation result is INSECURE
Apr 21 20:19:04 [dnsmasq] reply 546330.bugs.gentoo.org is CNAME
Apr 21 20:19:04 [dnsmasq] reply bugs-gossamer.gentoo.org is CNAME
Apr 21 20:19:04 [dnsmasq] reply gannet.gentoo.org is 204.187.15.4
---

When trying to access with dnssec, notice the validation result is
BOGUS, no result is returned:
---
Apr 21 20:09:33 [dnsmasq] query[A] 546330.bugs.gentoo.org from 127.0.0.1
Apr 21 20:09:33 [dnsmasq] forwarded 546330.bugs.gentoo.org to 10.38.5.26
Apr 21 20:09:33 [dnsmasq] dnssec-query[DNSKEY] gentoo.org to 10.38.5.26
Apr 21 20:09:33 [dnsmasq] dnssec-query[DS] gentoo.org to 10.38.5.26
Apr 21 20:09:33 [dnsmasq] dnssec-query[DNSKEY] org to 10.38.5.26
Apr 21 20:09:33 [dnsmasq] dnssec-query[DS] org to 10.38.5.26
Apr 21 20:09:33 [dnsmasq] dnssec-query[DNSKEY] . to 10.38.5.26
Apr 21 20:09:33 [dnsmasq] reply . is DNSKEY keytag 19036
Apr 21 20:09:33 [dnsmasq] reply . is DNSKEY keytag 48613
Apr 21 20:09:33 [dnsmasq] reply org is DS keytag 21366
- Last output repeated twice -
Apr 21 20:09:33 [dnsmasq] reply org is DNSKEY keytag 3213
Apr 21 20:09:33 [dnsmasq] reply org is DNSKEY keytag 21366
Apr 21 20:09:33 [dnsmasq] reply org is DNSKEY keytag 9795
Apr 21 20:09:33 [dnsmasq] reply org is DNSKEY keytag 34023
Apr 21 20:09:33 [dnsmasq] reply gentoo.org is DS keytag 46873
- Last output repeated twice -
Apr 21 20:09:33 [dnsmasq] reply gentoo.org is DNSKEY keytag 52980
Apr 21 20:09:33 [dnsmasq] reply gentoo.org is DNSKEY keytag 46873
Apr 21 20:09:33 [dnsmasq] validation result is BOGUS
Apr 21 20:09:33 [dnsmasq] reply 546330.bugs.gentoo.org is CNAME
Apr 21 20:09:33 [dnsmasq] reply bugs-gossamer.gentoo.org is CNAME
Apr 21 20:09:33 [dnsmasq] reply gannet.gentoo.org is 204.187.15.4
---

Maybe it is local issue of the dns I am using (I have no access to
it), but maybe there is a issue at infra.

Regards,
Alon Bar-Lev.

Re: [gentoo-dev] bugs.gentoo.org and dnssec

[Alon Bar-Lev]

On 21 April 2015 at 20:40, James Cloos cl...@jhcloos.com wrote:
 AB == Alon Bar-Lev alo...@gentoo.org writes:

 AB When using bugs.gentoo.org with dnsmasq and dnssec enabled, I cannot
 AB access attachments.

 It works here using a local unbound.

 But dnsmasq had some growth pains when it added dnssec verification, due
 to its bottom-up rather than the ususal top-down approach.

 AIUI, the current release should work.

 If you see that issue with 2.72 or later, they'd like to hear about it.

 Their list is:  dnsmasq-disc...@lists.thekelleys.org.uk


Thanks!
I suspected that.
Yes, I am using 2.72, I will send message.

[gentoo-dev] New sysfs based battery monitor widget for kde

[Alon Bar-Lev]

Hi,

I had some time to resolve the long outstanding issue I had with loosing
upower to systemd.

The only feature I personally had was the battery monitor stopped working,
yes, I did not install pm-utils either...

So after few times my battery went empty while I worked... decided that
enough is enough and I need to learn how to write kde plasmoid.

Documentation of kde plasmoid is not great, especially when using scripts,
but after looking on various of valid examples, I managed to produce a new
battery monitor[1][2] which is very simple and looks decent.

All that it does is once per interval read the /status and /capacity and
update the images within widget, it does not create a load nor adds
dependencies.

Install to user home by:

$ plasmapkg -i kbatsysfs-1.0.0.plasmoid

I hope someone will find this useful,
Alon

[1] http://kde-apps.org/content/show.php/kbatsysfs?content=168436
[2] https://github.com/alonbl/kbatsysfs

Re: [gentoo-dev] Re: git security (SHA-1)

[Alon Bar-Lev]

On Sun, Sep 21, 2014 at 2:13 PM, Ulrich Mueller u...@gentoo.org wrote:
 On Sun, 21 Sep 2014, Michał Górny wrote:

 Do you really consider keeping a key open for machine signing
 somewhat secure?

 You mean, as compared to manifests (or commits) signed by 250
 different developers' keys?

 Ulrich

Unrelated to git discussion, in the past we discussed co-sign, so that
developer signs using short term key, and infra co-sign using long
term key if the developer sign is valid at that time. Portage infra
should relay on infra key signature, while tractability is available
up to developer.

I will take the opportunity of responding to write that my preference
is to keep the manifest signature detached from the version management
technology, with no git specific feature usage, nor git specific
development (signed hrefs). It will enable much easier use of each
technology, one for file management and the other for security, while
enabling rebase and reorg without effecting integrity. If we can
establish co-sign I will be very happy.

Regards,
Alon

Re: [gentoo-dev] Re: Banning modification of pkg-config files

[Alon Bar-Lev]

On Mon, May 12, 2014 at 9:48 PM, Peter Stuge pe...@stuge.se wrote:
 Samuli Suominen wrote:
  If we say we stick to upstream then we don't provide pkg-config files
  at all (in these cases).

  I think this is a sane default.

 Except having pkg-config is the only way to fix some of the build
 issues we are seeing today, like getting 'Libs.private: ' for
 static linking, there has been multiple bugs lately,

 I honestly don't think that it's Gentoo's place to fix those issues.

 Just error out. Make users complain to upstream when upstream has a
 problem. Don't hide the problem and amass a huge support workload.


From my experience, there are lots of issues in upstream projects'
build system, most of the these result from lack of knowledge. Up
until now, downstream patches that were actually used by users found
their way better into upstream than just complaining that stuff
breaks, as upstream honestly does not have the knowledge to fix. It
also gives a chance to test them properly before submitting.

There are projects that will not accept any patch regardless of the
problem it solves, unless it is for their own favour distribution and
packager, so not providing solution for our users does not makes sense
to me.

Regards,
Alon

Re: [gentoo-dev] Re: RFC: enabling ipc-sandbox network-sandbox by default

[Alon Bar-Lev]

Hi,

I do not know if this came up... glibc must be bumped first[1].

Alon

[1] https://bugs.gentoo.org/show_bug.cgi?id=504032

Re: [gentoo-dev] FHS or not (WAS: [gentoo-project] Call for agenda items - Council meeting 2014-03-11)

[Alon Bar-Lev]

On Sat, Mar 1, 2014 at 2:03 AM, William Hubbs willi...@gentoo.org wrote:

 On Fri, Feb 28, 2014 at 09:57:15PM +, David Leverton wrote:
  William Hubbs wrote:
   The reason the split happened is pretty straight forward, and every other
   justification for continuing it was come up with after the fact.
 
  I keep hearing this, but I really don't see how it's relevant.  I'm sure
  you'll find lots of things in your life that you use for some purpose
  other than what they were originally invented for¹, and there's no
  reason why /usr should be any different.  All that matters is whether or
  not the newer reasons for having separate /usr actually provide a benefit.

 And I would argue that the maintenance cost of having separate /usr in a
 general sense is much higher than the benefit it provides.

 The problem with it is that it is next to impossible nowadays to define
 what should go in / vs what should go in /usr.

 William

Now it is difficult as too much time it was ignored.

In the past it was quite simple, everything that requires a server to
reach default runlevel.

The problem is that instead of telling users: If you are using
special user mode devices,  such as bluetooth keyboards, please make
sure /usr is mounted at boot, we enforce all that configuration, so
now initramfs should contain all that once was / with much harder
maintenance.

Alon

[gentoo-dev] Commit into profiles fails

[Alon Bar-Lev]

Hi,

Long time since I done this... maybe something had been changed.

$ cvs commit -m thirdpartymirrors: fixup gnupg mirros, bug#494842, thanks
to Ben Kohler
cvs commit: cannot exec /var/cvsroot/CVSROOT/cvslogdate: Permission denied
cvs commit: cannot exec /var/cvsroot/CVSROOT/checkgroup.pl: Permission
denied
cvs commit: Pre-commit check failed
cvs [commit aborted]: correct above errors first!

It looks like something is wrong in remote, but I see people succeed in
committing today...

What's wrong?

Thanks,
Alon

Re: [gentoo-dev] rfc: renaming rc binary in OpenRC

[Alon Bar-Lev]

On Wed, Dec 11, 2013 at 10:41 PM, William Hubbs willi...@gentoo.org wrote:

 All,

 We got a request from Debian to rename the rc binary of OpenRC due to
 a naming conflict they have. They have a port of the att plan 9 shell,
 which has a binary named rc as well[1].

 My thought is to rename our rc to openrc, since that would be
 unique.

 I know at least one thing that will break is everyone's inittab, so
 should I sed their inittab in our live ebuild or expect them to fix it
 and give a warning? I know that once OpenRC with this change is
 released, it will need to probably be p.masked until there is a new
 release of sysvinit that updates the inittab.

 I'm not sure what else will break.

 Does anyone have any ideas wrt other things to look for, or should I
 make the changes upstream and have people let us know what
 else breaks?

are you going to rename also rc-service and rc-update?


 William

 [1] https://bugs.gentoo.org/show_bug.cgi?id=493958

Re: [gentoo-dev] open season on other-dev's packages -- policy change?

[Alon Bar-Lev]

On Fri, Nov 1, 2013 at 9:53 PM, Peter Stuge pe...@stuge.se wrote:
 Peter Stuge wrote:
 It matters a whole lot if I have to wait for someone else to
 unblock me, in practice that completely demotivates me to
 contribute back, and I would simply work around the block.

 To clarify this point; contributing fixes back must always be the
 least effort of all ways to implement the fix in my own system.
 Optimize for the (desired) common case. Anything else pushes
 contributions away.

Hi,

Just for me to understand, do you suggest everyone can commit into the tree?

Or do you want to join in as a developer?

Or something else?

Regards,
Alon Bar-Lev.

Re: [gentoo-dev] open season on other-dev's packages -- policy change?

[Alon Bar-Lev]

On Fri, Nov 1, 2013 at 10:06 PM, Peter Stuge pe...@stuge.se wrote:
 Alon Bar-Lev wrote:
  It matters a whole lot if I have to wait for someone else to
  unblock me, in practice that completely demotivates me to
  contribute back, and I would simply work around the block.
 
  To clarify this point; contributing fixes back must always be the
  least effort of all ways to implement the fix in my own system.
  Optimize for the (desired) common case. Anything else pushes
  contributions away.

 Just for me to understand, do you suggest everyone can commit into
 the tree?

 Or do you want to join in as a developer?

 Or something else?

 I'm discussing the policies for Gentoo developers, stating my
 preferences and opinions under the assumption that my contributions
 to such a discussion are receivable and maybe even appreciated
 regardless of whether I ever become a developer or not.


Sure, but I may missed what you recommended...  not exist in the thread...

Blind commit without review of maintainer?
More maintainers?
More proxies?

I understand that you want to shorten the time between bug opening and
commit... but I do not understand what you suggest...


 //Peter

Re: [gentoo-dev] systemd team consensus?

[Alon Bar-Lev]

On Sun, Aug 11, 2013 at 9:59 PM, Tom Wijsman tom...@gentoo.org wrote:
 On Sun, 11 Aug 2013 13:29:16 -0500
 William Hubbs willi...@gentoo.org wrote:

 You may ask why I have offered patches instead of just fixing the
 ebuild since I am a team member. That is because even team members
 aren't allowed to touch bugs assigned to syst...@gentoo.org [1],

 Well, if there are conflicts within a team then I can agree that no
 member is allowed to touch the bug without a collaborative decision;
 but from what it appears this bug has been handed in a way that one
 member appears to take all decisions and the other member has nothing
 to say. In particular, comments 5 and 11 change the state of the bug
 without giving any reasoning about why that change in state was made;
 this is unacceptable, it gives us no reason to believe the state change.

This is expected, as it is similar to how systemd/gnome is managed :)

Regards,
Alon Bar-Lev.

Re: [gentoo-dev] systemd team consensus?

[Alon Bar-Lev]

On Mon, Aug 12, 2013 at 2:08 AM, Gilles Dartiguelongue e...@gentoo.org wrote:
 Le dimanche 11 août 2013 à 22:09 +0300, Alon Bar-Lev a écrit :
 On Sun, Aug 11, 2013 at 9:59 PM, Tom Wijsman tom...@gentoo.org wrote:
  On Sun, 11 Aug 2013 13:29:16 -0500
  William Hubbs willi...@gentoo.org wrote:
 
  You may ask why I have offered patches instead of just fixing the
  ebuild since I am a team member. That is because even team members
  aren't allowed to touch bugs assigned to syst...@gentoo.org [1],
 
  Well, if there are conflicts within a team then I can agree that no
  member is allowed to touch the bug without a collaborative decision;
  but from what it appears this bug has been handed in a way that one
  member appears to take all decisions and the other member has nothing
  to say. In particular, comments 5 and 11 change the state of the bug
  without giving any reasoning about why that change in state was made;
  this is unacceptable, it gives us no reason to believe the state change.

 This is expected, as it is similar to how systemd/gnome is managed :)

 I hope you are not talking about the Gentoo Gnome team as this would be
 very wrong. Every team member is heard on the team.

I was talking about the designated upstreams.

Regards,
Alon

Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8

[Alon Bar-Lev]

On Sat, Aug 10, 2013 at 1:59 PM, Rich Freeman ri...@gentoo.org wrote:
 On Sat, Aug 10, 2013 at 6:51 AM, Patrick Lauer patr...@gentoo.org wrote:
 not must, but if I choose to run the official supported configuration,
 well, then telling me to go to an unsupported state is quite confusing
 and sends the wrong signal.


 There is no one official supported configuration of Gentoo.  Nobody
 has to agree to make systemd an official supported configuration,
 because OpenRC isn't an official supported configuration either.  At
 least, not in the way that the terms seems to be being used.  There is
 no policy that requires packages to run when OpenRC is the service
 manager, and there is no policy that requires packages to supply an
 OpenRC init.d script.

Every long lawyer like response make me re-check my sanity.

The split of openrc was done by Roy in the past to be usable by other
audiences, especially busybox and *bsd configurations.

OpenRC is baselayout-1, just packaged in different way.

Gentoo, well up to now, did have a policy that packages should support
the baselayout which was single one, no alternatives where formally
supported. The fact that OpenRC is now provided as own package
(technical bit) could not have changed the policy of providing stable
coherent solution for users.

The fact that someone decided that init system may be virtual means
nothing if the implications of users and developers were not been
understood.

Of course it matches the gnome and affiliated vendor agenda but
for that do we break the entire tree and produce extra load for
developers who maintain unrelated packages?

Alon

Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8

[Alon Bar-Lev]

On Fri, Aug 9, 2013 at 3:28 PM, Rich Freeman ri...@gentoo.org wrote:
 On Fri, Aug 9, 2013 at 7:31 AM, Patrick Lauer patr...@gentoo.org wrote:
 You just removed the upgrade path for users.


 Just install systemd.  There really isn't any practical alternative.
 Gentoo with systemd is as Gentooish a configuration as Gentoo with
 OpenRC, or Gentoo with libav, or Gentoo with emacs.

Again, I repeat my-self.

Please stop writing these statements!

There was no decision to support Gentoo using any other layout than
openrc (baselayout).

There is *HUGE* difference between optional components and core components.

Claiming that Gentoo can use alternate layout is same as alternate
that freebsd port is stable or that intel icc can be used as compiler.
It has broad implications, which is far from the actual component
usage or its own dependencies.

If you have the agenda to switch to systemd, and you hide your
intention in the argument of supporting multiple layouts, please do
not hide and state so clearly.

But do not claim that Gentoo with different layout than baselayout is
still formal Gentoo, and is supported by the Gentoo developers.

Regards,
Alon Bar-Lev.

Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8

[Alon Bar-Lev]

On Fri, Aug 9, 2013 at 4:49 PM, Samuli Suominen ssuomi...@gentoo.org wrote:
 On 09/08/13 15:36, hasufell wrote:

 On 08/09/2013 12:27 PM, Rich Freeman wrote:

 On Fri, Aug 9, 2013 at 5:30 AM, hasufell hasuf...@gentoo.org wrote:

 On 08/09/2013 09:36 AM, Gilles Dartiguelongue wrote:

 It is not a regression if a new version of gnome mrequires systemd
 and does not work with OpenRc; it is a design choice.


 We are not just talking about random ebuild features here that have been
 dropped. It's a MAJOR feature. And it _matters_ for gentoo. So it IS a
 _regression_.


 How does not supporting OpenRC matter for Gentoo?


 The question puzzles me. For one it is
 * an implementation of virtual/service-manager which is in @system
 * it is the default init system in stage3
 * OpenRC is developed by gentoo devs, which means we especially want to
 make/keep it a usable tool. If we can't, then there is a regression. It
 doesn't matter whose fault it is. This is not about blame.


 baselayout-1, then later baselayout-2 and OpenRC were all created because
 there was an need and no suitable ready solutions
 systemd however is starting to look like a viable ready solution to switch
 to
 it's definately not an regression to switch to actively maintained software,
 it's more of an improvement because OpenRC has been stalled ever since Roy
 stopped hacking on it (all work put in by vapier, WilliamH, and others is of
 course appericiated)
 you know it's true if you have been with gentoo enough long


At least we know what ssuominen thinks... some prople are trying to
hijack the Gentoo project at the excuse of Gnome to switch into
specific vendor solution, and be on its mercies from now on. This was
the exact plan of whoever put all these $$ in
udev/systemd/gnome/fedora and effect the entire ecosystem, and slowly
own the entire solutions. As Linux userland become more and more
monolithic per the plan of that vendor, and if we yield, there will be
no real difference between Fedora and Gentoo, so what have we
accomplished? There come the new Microsoft and conquered the free open
source world using $$ and ambassadors.

What we basically say is that Gentoo cannot have their own agenda and
now submit to dictation of a single vendor of how Linux should be
managed and run.

To provide good service to our users we need a clear stand, what will
developers (throughout the tree) will be maintaining. If a user
installs a component he does expect it to work and maintained. And we
cannot force all developers to support two different layouts, and we
cannot allow developers to support layout of their choice, as users
will get a totally broken solution, because of the aspirations of
developer/herd they get different level of support.

I don't care if systemd is worked on by people, however it must be
clearly mark as unstable as long as there is no decision to switch.

Regards,
Alon Bar-Lev

Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8

[Alon Bar-Lev]

On Fri, Aug 9, 2013 at 5:44 PM, Chí-Thanh Christopher Nguyễn
chith...@gentoo.org wrote:
 Alon Bar-Lev schrieb:
 On Fri, Aug 9, 2013 at 3:28 PM, Rich Freeman ri...@gentoo.org wrote:
 On Fri, Aug 9, 2013 at 7:31 AM, Patrick Lauer patr...@gentoo.org wrote:
 You just removed the upgrade path for users.

 Just install systemd.  There really isn't any practical alternative.
 Gentoo with systemd is as Gentooish a configuration as Gentoo with
 OpenRC, or Gentoo with libav, or Gentoo with emacs.
 Again, I repeat my-self.

 Please stop writing these statements!

 There was no decision to support Gentoo using any other layout than
 openrc (baselayout).

 I think there may be a misunderstanding here. He only said that if you
 want to run Gnome 3.8, then switch to systemd. Because the Gnome team
 will not support any other configuration.

 He did not say that everyone should install systemd, nor that you need
 to support such a configuration.

So users will have gnome working but not any other component? How can
this a good service for  users?

Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8

[Alon Bar-Lev]

On Fri, Aug 9, 2013 at 5:57 PM, Chí-Thanh Christopher Nguyễn
chith...@gentoo.org wrote:
 Alon Bar-Lev schrieb:
 I think there may be a misunderstanding here. He only said that if you
 want to run Gnome 3.8, then switch to systemd. Because the Gnome team
 will not support any other configuration.

 He did not say that everyone should install systemd, nor that you need
 to support such a configuration.
 So users will have gnome working but not any other component? How can
 this a good service for  users?

 I am not sure what you mean by that. But every developer is free to
 commit and support in Gentoo whatever package he wishes to, within
 limitations set by policy.
 And when a package is 30 days in tree and there is no objection from QA
 or security teams then it can go stable.

This is so narrow interpretation of the policy.
You talk about a process, and user do not care about the process.
30 days? and what if a user has an issue 31 days after?
And what if QA decides that now systemd must be supported? so we delay
stabilization?

People here tend to forget that Gentoo is not just ebuilds, but also
an organization which requires a policy for the sake of its *USERS*.

Regards,
Alon

Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8

[Alon Bar-Lev]

On Thu, Aug 8, 2013 at 5:01 PM, Fabio Erculiani lx...@gentoo.org wrote:
 Moreover, the lvm problem is caused by a very ancient and ill decision
 about doing what upstream tells you to avoid: have mdev in the
 initramfs and udev on the final pivot rooted system. This was just
 looking for troubles but the smarties at the time decided that they
 knew better... And now, tadam, the bug is served...
 People can use genkernel-next, which comes with _proper_ udev support
 (see --udev).

I won't comment about the entire gnome monolithic windows like, vendor
controlled system that we cooperate with.

But the above statement is way too much... there should be nothing
wrong in having mdev during boot. initramfs should be simple as
possible and busybox provides this functionality well. The problem is
in udev not in any other component, that probably expects now to run
first and have total control over the boot process. I hope eudev does
not suffer from this.

If genkernel will start using udev instead of busybox, it will
probably be the last day of me use it.

I am just waiting for the point in which you claim that systemd should
be run at initramfs, because of the dependency lock-in, so you have
almost the entire system within initramfs.

Regards,
Alon

Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8

[Alon Bar-Lev]

On Thu, Aug 8, 2013 at 8:41 PM, Rich Freeman ri...@gentoo.org wrote:
 Stability is about the quality of the ebuilds and the user experience
 in general.  It is not a statement that all Gentoo developers think
 that the package is useful.  Many would say that nobody should be
 using MySQL/MariaDB for production work, but that has nothing to do
 with its stability as a package either.

This is not entirely correct.

If from now on, a bug with systemd of new version of a package blocks
that package stabilization, it means that all developers must support
systemd. So having systemd stable is a decision that should be made by
the entire community, and have huge overhead on us all.

So apart of the politic message, there are implications of maintenance
efforts, stabilization efforts.

I appreciate the discussion at debian, it is not wise to support [I am
adding: at stable] more than one solution for layout.

Regards,
Alon Bar-Lev.

Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8

[Alon Bar-Lev]

On Thu, Aug 8, 2013 at 9:08 PM, Samuli Suominen ssuomi...@gentoo.org wrote:
 On 08/08/13 20:57, Alon Bar-Lev wrote:

 On Thu, Aug 8, 2013 at 8:41 PM, Rich Freeman ri...@gentoo.org wrote:

 Stability is about the quality of the ebuilds and the user experience
 in general.  It is not a statement that all Gentoo developers think
 that the package is useful.  Many would say that nobody should be
 using MySQL/MariaDB for production work, but that has nothing to do
 with its stability as a package either.


 This is not entirely correct.

 If from now on, a bug with systemd of new version of a package blocks
 that package stabilization, it means that all developers must support
 systemd. So having systemd stable is a decision that should be made by
 the entire community, and have huge overhead on us all.


 That's not really true with systemd when the unit files (and related) are in
 a format that they can be carried also by upstream and can be shared between
 distributions. They are comparable to logrotate or bash-completion files.

 You don't necessarily use distcc, ccache, clang, ... and yet you let people
 compile packages you maintain using them.
 You don't necessarily use uclibc, yet you allow users to compile the
 packages against it and expect them to file bugs if something is broken.
 You don't necessarily use selinux and yet support building against
 libselinux where possible.
 You don't necessarily use zsh as your shell and yet let zsh-completion files
 to be installed when requested.

 Yet any of the mentioned packages can be stabilized, what makes systemd so
 special that it can't follow the same rules as other packages?

logrotate, autocompletion are not functional dependencies.

uclibc - is not mainline, people who use it for embedded are aware the
it may be broken every bump.

autocompletion, distcc, ccache etc... are optional components which
can be disabled, while having usable system until issue is resolved.

selinux - if a package breaks selinux it will be reverted (if
maintainer care about his users) until resolution is found.

as you may have unusable system if a bump does not support specific
stable init layout, you do expect rollback similar to libselinux
issue. init layout is not optional package nor optional feature, it
how the system operates.

 So apart of the politic message, there are implications of maintenance
 efforts, stabilization efforts.


 Just the normal efforts.



 I appreciate the discussion at debian, it is not wise to support [I am
 adding: at stable] more than one solution for layout.

 Regards,
 Alon Bar-Lev.

Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8

[Alon Bar-Lev]

On Thu, Aug 8, 2013 at 9:26 PM, Tom Wijsman tom...@gentoo.org wrote:
 On Thu, 8 Aug 2013 20:57:15 +0300
 Alon Bar-Lev alo...@gentoo.org wrote:

 On Thu, Aug 8, 2013 at 8:41 PM, Rich Freeman ri...@gentoo.org wrote:
  Stability is about the quality of the ebuilds and the user
  experience in general.  It is not a statement that all Gentoo
  developers think that the package is useful.  Many would say that
  nobody should be using MySQL/MariaDB for production work, but that
  has nothing to do with its stability as a package either.

 This is not entirely correct.

 If from now on, a bug with systemd of new version of a package blocks
 that package stabilization, it means that all developers must support
 systemd.

 This is not entirely correct either.

 Not necessarily, one can opt to mask this combination and stabilize
 this combination later by removing the mask; it's an implementation
 detail, but certainly there's no need to imply that they must.

 Another example is that when you add a package to the tree, you are not
 required to initially commit both an OpenRC unit and systemd service
 file; you are suggested to provide them for the convenience of the
 user, if you don't know systemd service files then you aren't obligated
 to support them as far as I am aware of. There are people that can help
 you in supporting them as well as following up on their bugs; and if
 you wonder, the ebuild change to support a systemd service is trivial.

1. There is huge difference between adding a new package that lacks
feature and maintaining existing features.

2. When people say that something is trivial, my immediate reaction is
fear. systemd is far from being trivial, but let's don't get into that
one again.


 So having systemd stable is a decision that should be made by
 the entire community, and have huge overhead on us all.

 systemd is already stable, it has not found to be an huge overhead;
 whether it should have been a decision made by the entire community, I
 doubt it, it neither seems to show any problematic wide spread problems.

 So apart of the politic message, there are implications of maintenance
 efforts, stabilization efforts.

 Agreed; though, they are quite small and shouldn't be a bother. It's
 worth doing these small implications to provide choice to our users...

 I appreciate the discussion at debian, it is not wise to support [I am
 adding: at stable] more than one solution for layout.

 Can you share the link? I'm yet to see good reasoning why it's not wise.

Latest[1], you can search for debian openrc for more.

[1] 
http://www.marshut.com/rnvrp/survey-answers-part-3-systemd-is-not-portable-and-what-this-means-for-our-ports.html

 --
 With kind regards,

 Tom Wijsman (TomWij)
 Gentoo Developer

 E-mail address  : tom...@gentoo.org
 GPG Public Key  : 6D34E57D
 GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

Re: Multiple implementations shouldn't block Gentoo's progress. Stabilize package combinations? (was: Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8)

[Alon Bar-Lev]

On Thu, Aug 8, 2013 at 9:47 PM, Tom Wijsman tom...@gentoo.org wrote:
 On Thu, 8 Aug 2013, 20:57:18 +0300
 Alon Bar-Lev alo...@gentoo.org wrote:

 If from now on, a bug with systemd of new version of a package blocks
 that package stabilization, it means that all developers must support
 systemd. So having systemd stable is a decision that should be made by
 the entire community, and have huge overhead on us all.

 On Thu, 8 Aug 2013 21:23:29 +0300
 Alon Bar-Lev alo...@gentoo.org wrote:

 selinux - if a package breaks selinux it will be reverted (if
 maintainer care about his users) until resolution is found.

 as you may have unusable system if a bump does not support specific
 stable init layout, you do expect rollback similar to libselinux
 issue. init layout is not optional package nor optional feature, it
 how the system operates.

 Reverting and rolling back isn't really the good way going forward, it
 implies waiting and that's going to certainly make people sad because
 they need to wait for something that doesn't affect the package
 combination that the user uses; we need to look at a different approach.

 What if we could stabilize package combinations instead of packages? Or
 rather, when during stabilization it was found that a certain package
 combination doesn't work, exclude that combination from stabilization?

 This is a concept that shouldn't be too hard to implement; it could
 even be implemented using existing USE flag mask opportunities, although
 we probably would have to figure out a solution for those occasions
 where an USE flag is not present.

 Perhaps specify in the ebuild that the package shouldn't be regarded as
 keyworded for a certain dependency?

 Since it's just an idea that jumps to mind, I'm not sure if this is the
 best approach to do this; but we'll probably want to start brainstorming
 in this field if this is going to stay or become a big problem.

 Multiple implementations shouldn't block Gentoo going forward.

 We need to come up with a solution similar to the above to avoid this...

This is called a 'profile'.

You can have systemd and openrc profiles, and then able to mask
specific packages...

It is a technical solution, but won't make lives much easier in this regard.

Regards,
Alon Bar-Lev

Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8

[Alon Bar-Lev]

On Thu, Aug 8, 2013 at 9:58 PM, Samuli Suominen ssuomi...@gentoo.org wrote:
 On 08/08/13 21:23, Alon Bar-Lev wrote:

 On Thu, Aug 8, 2013 at 9:08 PM, Samuli Suominen ssuomi...@gentoo.org
 wrote:

 On 08/08/13 20:57, Alon Bar-Lev wrote:


 On Thu, Aug 8, 2013 at 8:41 PM, Rich Freeman ri...@gentoo.org wrote:


 Stability is about the quality of the ebuilds and the user experience
 in general.  It is not a statement that all Gentoo developers think
 that the package is useful.  Many would say that nobody should be
 using MySQL/MariaDB for production work, but that has nothing to do
 with its stability as a package either.



 This is not entirely correct.

 If from now on, a bug with systemd of new version of a package blocks
 that package stabilization, it means that all developers must support
 systemd. So having systemd stable is a decision that should be made by
 the entire community, and have huge overhead on us all.



 That's not really true with systemd when the unit files (and related) are
 in
 a format that they can be carried also by upstream and can be shared
 between
 distributions. They are comparable to logrotate or bash-completion files.

 You don't necessarily use distcc, ccache, clang, ... and yet you let
 people
 compile packages you maintain using them.
 You don't necessarily use uclibc, yet you allow users to compile the
 packages against it and expect them to file bugs if something is broken.
 You don't necessarily use selinux and yet support building against
 libselinux where possible.
 You don't necessarily use zsh as your shell and yet let zsh-completion
 files
 to be installed when requested.

 Yet any of the mentioned packages can be stabilized, what makes systemd
 so
 special that it can't follow the same rules as other packages?


 logrotate, autocompletion are not functional dependencies.

 uclibc - is not mainline, people who use it for embedded are aware the
 it may be broken every bump.

 autocompletion, distcc, ccache etc... are optional components which
 can be disabled, while having usable system until issue is resolved.

 selinux - if a package breaks selinux it will be reverted (if
 maintainer care about his users) until resolution is found.

 as you may have unusable system if a bump does not support specific
 stable init layout, you do expect rollback similar to libselinux
 issue. init layout is not optional package nor optional feature, it
 how the system operates.


 Replying very loosely

 I guess that's why we call Gentoo a meta-distribution instead of
 distribution since we are not bound to one certain type of system operation
 like eg. Debian is or any other binary distribution is.

As this alternate layout did not exist at that time, I don't think it
had not been the reason for this term.

Re: [gentoo-dev] renaming gentoo-oldnet

[Alon Bar-Lev]

On Sun, Aug 4, 2013 at 11:37 PM, William Hubbs willi...@gentoo.org wrote:

 Doug and Brian, I'm going to reply in a little more detail.

 On Sat, Aug 03, 2013 at 07:38:04PM -0700, Brian Dolbec wrote:
  On Sat, 2013-08-03 at 21:03 -0500, Doug Goldstein wrote:
   On Sat, Aug 3, 2013 at 7:30 PM, William Hubbs willi...@gentoo.org wrote:
On Sun, Aug 04, 2013 at 01:49:46AM +0300, Alon Bar-Lev wrote:
On Sun, Aug 4, 2013 at 1:38 AM, William Hubbs willi...@gentoo.org 
wrote:
 
OK... so gentoo-networking? or just come up with own name? 
best-networking?
   
 
   You and I have had this talk more times than I can remember at this
   point. Using the name oldnet sucks and was one of the worst choices
   possible. Looking through our IRC chats, I had also suggested
   gentoo-networking.

 I thought about gentoo-networking, but that sucks in a way too because
 it implies that everyone on gentoo should be using it.

  That's not quite right because we have at least five network stacks I
  can think of off the top of my head, and OpenRc upstream supports
  another.

 - OpenRc upstream supports newnet, which I have played with, and I
   believe people on Gentoo are using successfully.
   - what we have been calling the oldnet stack, which most gentoo users
 have been using.
 - dhcpcd in standalone mode.
 - wicd
 - NetworkManager
 - badvpn

I do not understand... the 'old net' which is actually gentoo
networking for years, are fully functional script to manage and create
a lot of configurations, and one of the advantages we have at Gentoo
over other distributions.

The only reason why this is called old net is because Roy switched to
*BSD. What you call new net requires vast knowledge in network tools
usage and interaction, which makes life very difficult.

Some examples I managed to document:

http://alonbl.tropicalwikis.com/wiki/Gentoo/Firewall_Using_Firehol
http://alonbl.tropicalwikis.com/wiki/Gentoo/OpenVPN_Server
http://alonbl.tropicalwikis.com/wiki/Gentoo/OpenVPN_Non_Root
http://alonbl.tropicalwikis.com/wiki/Gentoo/Vpnc_Non_Root
http://alonbl.tropicalwikis.com/wiki/Gentoo/VM_Tap_Networking
http://alonbl.tropicalwikis.com/wiki/Gentoo/PPP_Client
http://alonbl.tropicalwikis.com/wiki/Gentoo/PPPoE_Client

 As I have said before, none of this is an attempt to kill or deprecate
 anything. It is just re-arranging things by moving the old gentoo
 network stack into its own package. There are no plans to stop you from
 using it if you want to use it. There is definitely nothing being said
 here about the state of OpenRc in general.

From behind the words it indeed looks like there is a change coming.

Alon

Re: [gentoo-dev] OpenRc-0.12 and gentoo-oldnet-0.1 keywording question

[Alon Bar-Lev]

On Sun, Aug 4, 2013 at 12:44 AM, William Hubbs willi...@gentoo.org wrote:
 All,

 one thing that is going to be different about OpenRc-0.12 is the oldnet
 scripts (net.* and /lib*/rc/net/*) are going to be split out into their
 own package, gentoo-oldnet-0.1. This will be brought in by a pdepend
 initially to make sure everyone who doesn't have newnet gets the
 package.

Hi,

I do understand why Roy refer this as oldnet... but why in Gentoo do
we keep the term old? The functionality of these script is huge, and
is better than most distros out there. Do we want keep users out of
it? are we going to obsolete this huge work? If we don't I suggest to
remove the 'old' implication, to something like openrc-gentoo-net.

Regards,
Alon Bar-Lev.

Re: [gentoo-dev] renaming gentoo-oldnet

[Alon Bar-Lev]

On Sun, Aug 4, 2013 at 1:38 AM, William Hubbs willi...@gentoo.org wrote:
 Hi all,

 I'm splitting the thread because this is a separate subject.

 On Sun, Aug 04, 2013 at 12:59:56AM +0300, Alon Bar-Lev wrote:
 I do understand why Roy refer this as oldnet... but why in Gentoo do
 we keep the term old? The functionality of these script is huge, and
 is better than most distros out there. Do we want keep users out of
 it? are we going to obsolete this huge work? If we don't I suggest to
 remove the 'old' implication, to something like openrc-gentoo-net.

 Actually the plan is to generalize it so that it works with other init
 systems. Right now it is very tightly integrated with OpenRc, but there
 is interest in changing that, so adding openrc to the name would be
 misleading eventually.

OK... so gentoo-networking? or just come up with own name? best-networking?

However, I do not understand how you can port it without changing the
notations... or lowering features... example: rc_net_*_provide,
rc_net_*_need, or the rc_config, rc_use, rc_net_*_provide=!net
etc...

Do you think systemd users can understand that /etc/conf.d/net is
actually a shell script? I hope this is not going to be eliminated, as
I use it a lot.

Regards,
Alon Bar-Lev.

[gentoo-dev] Goodbye

[Alon Bar-Lev]

Hello,

I guess I am tired of fighting with people here. I am too old for this crap.

There are few brutal developers here that make Gentoo a terrible place
to be. Well... I can handle few developers, but when devrel enters the
picture with arguments such as volunteers can do crappy job as long
as they have fun enough is enough.

I signed-up to work on distribution if I have fun in the process it is
great! But always keep in mind the delivery I provide to users.

Gentoo has some fundamental issues, the obvious one is lack of
leadership. There is *NOBODY* that formally responsible or cares about
the delivery Gentoo (AS A WHOLE) provide to its users. The council is
just a political body that discuss the void issues.

As a result the laud and brutal developers dictate the tune. With no
proper mechanism to decide if a decision that was taken aligns with
Gentoo goals.

The devrel process is ridiculous, as proxy between developers without
ability to determine anything does not help anyone.

During the short time I was around Gentoo lost some of the best
developers that were around, due to similar reasons.

If Gentoo community cannot provide its own goals, at least it should
embrace standards. Compliant to standards may resolve many conflicts.
Roy worked hard to make Gentoo POSIX shell compliant, but this was not
accepted, but imagine fully Gentoo work with busybox based system,
isn't this an advantage we have? especially on small systems. I
appreciate flameeyes work on reducing the system size, I am aware how
hard it is. There are new violations of HFS in Gentoo, but nobody
cares.

Jacub, one of the best developers around that actually cared about the
service we provide to our users was suspended while trying to do so,
and now he is not active anymore.

There are some more examples... The brutal developers remain, the quiet leave.

Gentoo is built on a lot of inexperienced students, but the backbone
of core developers with real-life experience is very weak. I think
that current approach of the developers community will not able to
resolve this, as a result Gentoo community will not mature.

Gentoo has a great piece of technology (portage), this is unique and
with the right leadership may be the tool to make Gentoo more stable
and popular, as a result extending the user community and gain more
resources. But leadership derives goals, goals derive complaint,
complaint derives means of enforcement. None of these currently
available in the community.

Personal note on leadership: vapier - you are good, so good that many
envy you. But this does not give you the right to not being nice. You
are on of the few people here that can take at least partially resolve
the leadership issue. With a little patience and care. (Just to make
it clear: I am not leaving because of vapier).

Packages to reassign:

mobile:
dev-libs/libx86
sys-power/suspend
sys-power/hibernate-script

antivirus
./sys-fs/dazuko

misc:
net-misc/openvpn
media-sound/mp3unicode

I am available at email:[EMAIL PROTECTED]

Have fun,
Alon.
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] RFC: qemu - add gcc-3.x dependency

[Alon Bar-Lev]

On 5/5/08, Jan Kundrát [EMAIL PROTECTED] wrote:
  Hi Enrico, it is usually a good idea to search through the Bugzilla before
 asking for some feature, chances are that it has been already requested (in
 this case, you're looking for bug 190102). FYI, at least some of qemu's
 features were ported to gcc4 -- for example, see the kvm-qemu ebuild from
 bug 157987.

I also waiting for gcc-4 enabled qemu for long time...
The problem that emerge --emptytree world will not work when
packages are compiled in different gcc versions.
The kvm-qemu is not relevant if you don't have the hardware.

One solution I saw is to compile gcc-3 as part of the qemu build
process, and make the qemu use this gcc-3 instance. This way you can
have qemu up and running while the system is configured for gcc-4.

It is very disappointing that upstream does not allow gcc-4
configuration so long after gcc-4 release.

Alon.

Re: [gentoo-dev] New developer : Markus Duft (mduft)

[Alon Bar-Lev]

On 4/30/08, Denis Dupeyron [EMAIL PROTECTED] wrote:
 It's my pleasure to introduce Markus Duft (mduft) as a new developer.
  He will go among us under the name of mduft, and will work in the
  Gentoo/Alt project porting Gentoo Prefix to Interix. Yes, people, that
  means Gentoo on Win32.

Welcome!

I will love to see Windows support via cygwin and not commartial product.
Something like [1], [2].

Alon.

[1] http://gentoocygwin.sourceforge.net/
[2] http://gentoo-wiki.com/HOWTO_Gentoo_on_Cygwin
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] New developer : Markus Duft (mduft)

[Alon Bar-Lev]

On 4/30/08, Fabian Groffen [EMAIL PROTECTED] wrote:
 On 30-04-2008 19:51:42 +0300, Alon Bar-Lev wrote:
   On 4/30/08, Denis Dupeyron [EMAIL PROTECTED] wrote:
It's my pleasure to introduce Markus Duft (mduft) as a new developer.
 He will go among us under the name of mduft, and will work in the
 Gentoo/Alt project porting Gentoo Prefix to Interix. Yes, people, that
 means Gentoo on Win32.
  
   Welcome!
  
   I will love to see Windows support via cygwin and not commartial product.
   Something like [1], [2].


 Interix is free and these days bundled with Windwows, IIRC.

I couldn't understand it from [1], anyway the source is unavailable right?

  Why do you want it to run on Cygwin?  (Honest question...)

It is the only project I know providing good support for POSIX Windows
platform while having Open Source license.

But if you are correct and a good POSIX layer is provided built-in in
Windows, I will be happy to see stage3 for Windows.

Alon.

[1] http://www.interix.com/products_services.htm
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] New developer : Markus Duft (mduft)

[Alon Bar-Lev]

On 4/30/08, Fabian Groffen [EMAIL PROTECTED] wrote:
 I think in that sense Cygwin is more Open Source, because how you get
  the primary shell/environment is available too.  However, for me that
  doesn't matter, as the OS itself is inherently non-free in that sense,
  so that's what you have to accept first thing anyway.

I separate operating system and applications... Just like you run on
HPUX or AIX... There is Windows.

 Just for your information, we don't do stages at the moment, not in the
  forseeable future from my point of view either.  Binpkgs are in the
  planning.  In general we just do a full bootstrap, on Interix you need
  extra help from prefix-launcher.

This is sad... I would really like to see fully operating portage on
Windows... It was more important to me in the past when I actually
used this OS...

I this sense [1] was a great idea! You could always use quickpkg to
extract binaries.

Alon.

[1] http://gentoocygwin.sourceforge.net/
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] New global USE flag: keyring

[Alon Bar-Lev]

This may be confusing with Linux key store.
I suggest gnome-something as it is gnome feature.

Alon

On Sun, Apr 20, 2008 at 5:45 PM, Peter Weller [EMAIL PROTECTED] wrote:
 Unless anyone has any objections, I'll magically turn 'keyring' into a
 global USE flag tomorrow evening:

 [EMAIL PROTECTED] ~/gentoo/cvs/gentoo-x86/profiles $ grep ':keyring'
 use.local.desc
 app-crypt/seahorse:keyring - Enable gnome-keyring support for storing
 passwords
 app-text/evince:keyring - Enable gnome-keyring support for storing
 passwords
 gnome-base/gvfs:keyring - Enable gnome-keyring support for storing
 passwords
 gnome-extra/evolution-data-server:keyring - Enable gnome-keyring support
 for storing passwords
 media-sound/rhythmbox:keyring - Enable gnome-keyring support for storing
 passwords
 net-im/gossip:keyring - Enable gnome-keyring support for storing
 passwords
 net-im/telepathy-mission-control:keyring - Enable gnome-keyring support
 for storing passwords
 net-misc/twitux:keyring - Enable gnome-keyring support for storing
 passwords
 net-misc/vino:keyring - Enable gnome-keyring support for storing
 passwords
 [EMAIL PROTECTED] ~/gentoo/cvs/gentoo-x86/profiles $

 --
 gentoo-dev@lists.gentoo.org mailing list


-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Re: New global USE flag: keyring

[Alon Bar-Lev]

2008/4/20 Peter Weller [EMAIL PROTECTED]:
 On Sun, 2008-04-20 at 18:32 +0300, Ali Polatel wrote:
  Alon Bar-Lev yazmış:
   I suggest gnome-something as it is gnome feature.
 
  How about gnome-keyring? :)
 

 Why? All the ebuilds currently using the 'keyring' use flag are using it
 for gnome-keyring. As long as there is a proper description of the USE
 flag, there should be no confusion caused.

Because it may be confusing.
As long as it is local flag for gnome packages, the gnome is implicit.
If you want it to be global, gnome should be explicit.

Alon

Re: [gentoo-dev] Re: Re: New global USE flag: keyring

[Alon Bar-Lev]

On Sun, Apr 20, 2008 at 7:06 PM, Tiziano Müller [EMAIL PROTECTED] wrote:
 I'd say we should convert it to a global use flag now with a good
 description and change it to gnome-keyring later in case we really have a
 package which needs 'keyring' for something else.

If we know there may be a future problem, why make the next *VALID*
addition perform extra work? This is gnome specific feature, should
have gnome explicit mark.
If we have keyring in KDE, or keyring in kernel or any other generic
keyring. The extra work should be done now, so we have less conflict
in future.

Alon
���^�X�����(��j)b�b�

Re: [gentoo-dev] New global USE flag: keyring

[Alon Bar-Lev]

On 4/20/08, Gilles Dartiguelongue [EMAIL PROTECTED] wrote:
 for what it's worth, as a gnome dev I didn't see any convincing
  arguments as to why it should be renamed. Gnome makes things optional
  for other to reuse (like xfce) but afaik no other keyring like
  programs are optional deps of another package in portage. Let's not cast
  a simple change into breakage for users already using it (even in
  stable, and yes I'm lazy :D).

Lazy is the word.
I cannot argue with this one, I just know that it won't be the gnome
herd who do the work when the time come to fix this (resolve
conflict).
The gnome herd will re-introduce the lazy ticket, and make other herd
use yet another confusing USE flag.
This is not the right way to maintain long term constants.

You asked for objections... You got some.

You can leave this local USE flag, and stay with generic term.
Or you can rename it when it goes global so it have proper name.
You can also ignore this and force gnome onto all users.

Alon.
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] [SECURITY] Minimizing the suid usage

[Alon Bar-Lev]

On 3/24/08, Mike Frysinger [EMAIL PROTECTED] wrote:
 Diego and i were talking ... we're going to go with USE=filecaps because it's
  so new and doesnt require the libcap library in order to work at runtime.
  probably be worthwhile to put together a little eclass of functions to make
  people's lives easier ...

Great!!!
You write eclass, me start patching ebuilds and open bugs against maintainers :)

Alon.
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] [SECURITY] Minimizing the suid usage

[Alon Bar-Lev]

On 3/24/08, Mike Frysinger [EMAIL PROTECTED] wrote:
  how much do we want to help the user ?  if they have USE=filecaps, then dont
  perform any checking ?  we'll need a kernel with file capabilities turned on,
  otherwise the prog wont work unless it's setuid ... so do we perform checking
  and drop the setuid bit on the post sly ?  i'd prefer we just make the
  filecaps desc verbose: dont set this unless you have new enough kernel with
  options enabled, otherwise things may stop working properly as non-root.

I also prefer descriptive warning and not runtime checks. Worse case
scenario, system will be usable for root only. root can remove this
USE flag and emerge --update --deep --newuse world.

Alon.
-- 
gentoo-dev@lists.gentoo.org mailing list

[gentoo-dev] [SECURITY] Minimizing the suid usage

[Alon Bar-Lev]

Hello All,

linux-2.6.24 supports file based capabilities via:
CONFIG_SECURITY_FILE_CAPABILITIES

This enables the use of filesystem attributes in order to store per
executable capabilities list, more information at [1].

This enables improved security level for people who don't wish to move
into SELinux or similar.

I think a new global USE flags (or use current caps) may enable
ebuilds to set correct capabilities on files.

On my system at least: ping, ping6, tcpdump, wireshark, samba, ntpd,
rlogin, vmware may enjoy this and drop the root suid.

In order to make it simple for everybody, a new eclass may be
introduced to force dependency on =libcap-2 and provide some atoms.

This will provide more secured installation for users with a little
effort, less usage of root user.

What do you think?

Alon.

[1] http://www.friedhoff.org/fscaps.html
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] [SECURITY] Minimizing the suid usage

[Alon Bar-Lev]

On 3/23/08, Ciaran McCreesh [EMAIL PROTECTED] wrote:
 On Sun, 23 Mar 2008 20:21:29 +0200
  Alon Bar-Lev [EMAIL PROTECTED] wrote:
   linux-2.6.24 supports file based capabilities via:
   CONFIG_SECURITY_FILE_CAPABILITIES
  

  This will provide more secured installation for users with a little
   effort, less usage of root user.
  
   What do you think?


 Needs package manager support. Effectively this requires an EAPI bump,
  since ebuilds need to know whether they can rely upon caps being
  preserved across a merge or whether they have to degrade to a setuid
  bit.

Why? A simple USE flag should be enough, if set use caps, if not use current.

Alon.
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] [SECURITY] Minimizing the suid usage

[Alon Bar-Lev]

On 3/23/08, Ciaran McCreesh [EMAIL PROTECTED] wrote:
   Why? A simple USE flag should be enough, if set use caps, if not use
   current.


 A user turns the use flag on, the ebuild creates files using caps
  rather than set*id, the package manager merges it by copying the file
  and the installed file ends up with no caps and no set*id bit.

File system attributes already supported for selinux. I also checked
this with capabilities and it works with portage.

Alon.
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Upcoming Infra maintenance/downtimes: anon{cvs,svn,git}, archives, bouncer, overlays

[Alon Bar-Lev]

On 1/19/08, Mike Frysinger [EMAIL PROTECTED] wrote:
 using https:// to secure your data here is the wrong way to go.  if you have a
 man-in-the-middle attacking you, they can do a lot more than inject crap into
 your syncs, some of which you wouldnt even notice.  for the topic at hand,
 this topic does not matter i think.

The https solves man-in the middle for svn/git sync.

There is an option for rsync people (not to use it):
http://bugs.gentoo.org/show_bug.cgi?id=130039

Best Regards,
Alon Bar-Lev.
-- 
gentoo-dev@lists.gentoo.org mailing list

Re: [gentoo-dev] Upcoming Infra maintenance/downtimes: anon{cvs,svn,git}, archives, bouncer, overlays

[Alon Bar-Lev]

On 1/19/08, Arfrever Frehtes Taifersar Arahesis [EMAIL PROTECTED] wrote:
  If I understand correctly, the performance of svn under apache is
  better than the svnserver

 The other way round.

We are talking about read-only anonymous repository, right?
But I will take your word for it :)

Thanks!
Alon.
-- 
gentoo-dev@lists.gentoo.org mailing list