[gentoo-dev] Last rites: www-apps/roundup

[Thomas Deutschmann]

# Thomas Deutschmann  (17 Feb 2017)
# Unpatched security vulnerability per bug #576868
# Removal in 30 days.
www-apps/roundup


-- 
Regards,
Thomas Deutschmann



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Suggested sync method/Portage config for devs on ~arch?

[Thomas Deutschmann]

On 2017-02-28 10:52, James Le Cuirot wrote:
> I use hasufell's repo too. I'm surprised we haven't made it more
> official.

The public Gentoo git mirror is

  https://github.com/gentoo-mirror/gentoo

This git mirror includes pre-generated metadata. No need for any
hack/additional step.

Devs maybe want to switch branch from stable (default branch) to master
branch (stable branch has CI coverage and will only sync if everything
is fine).


-- 
Regards,
Thomas




signature.asc
Description: OpenPGP digital signature

[gentoo-dev] [PATCH] mysql-v2.eclass: Drop dead g3nt8.org mirror

[Thomas Deutschmann]

Removing g3nt8.org mirror which is no longer hosting mysql-extras tarball and
not controlled by any Gentoo dev anymore (i.e. dead domain, up for sale).
---
 eclass/mysql-v2.eclass | 1 -
 1 file changed, 1 deletion(-)

diff --git a/eclass/mysql-v2.eclass b/eclass/mysql-v2.eclass
index 21931cc8e9..b63c306f74 100644
--- a/eclass/mysql-v2.eclass
+++ b/eclass/mysql-v2.eclass
@@ -182,7 +182,6 @@ SRC_URI="${SERVER_URI}"
 if [[ ${MY_EXTRAS_VER} != "live" && ${MY_EXTRAS_VER} != "none" ]]; then
SRC_URI="${SRC_URI}
mirror://gentoo/mysql-extras-${MY_EXTRAS_VER}.tar.bz2
-   http://g3nt8.org/patches/mysql-extras-${MY_EXTRAS_VER}.tar.bz2

https://dev.gentoo.org/~robbat2/distfiles/mysql-extras-${MY_EXTRAS_VER}.tar.bz2

https://dev.gentoo.org/~jmbsvicetto/distfiles/mysql-extras-${MY_EXTRAS_VER}.tar.bz2

https://dev.gentoo.org/~grknight/distfiles/mysql-extras-${MY_EXTRAS_VER}.tar.bz2";
-- 
2.12.0

[gentoo-dev] Re: RFC: Pre-GLEP: Security Project

[Thomas Deutschmann]

Hi,

I am quoting :

> == Abstract ==
> This GLEP outlines the purpose, responsibilities and abilities of the
> Gentoo Security Project.
>
> == Motivation ==
> This GLEP aims to document the processes of the Security Project and
> enpowering the project to operate on a wide scale across the Gentoo
> tree, within the structure provided by this GLEP.

I disagree with that. It looks like this GLEP was formed on base of
GLEP:48 [1] but I think this is wrong (like I would withdraw GLEP:48 now
that I read it).

For example, the purpose and the process of a project shouldn't be part
of any GLEP. These are project internal details and every project is
free to change its process without a new GLEP approval.

Also, for me the draft goes completely in the wrong direction.

I would get rid of the entire "Security Project Lead" and "Joining the
Project" paragraph:

Gentoo security project is a project like any other Gentoo project: The
team should decide in regular meetings how they want to do things. The
team is encouraged to elect a lead each year like any other project is
encouraged to do. In case of tied votes, the vote of the current lead
will be counting twice to get a decision but this isn't special so we
don't need to write it down for the security project.

Because project lead may change each year, the absolute majority of the
whole team must accept new members. Otherwise, the new project lead
would be responsible for people who maybe in the project just because
the previous lead liked them but he/she maybe don't trust them. But
again, this is something the project would decide and shouldn't be
handled in a GLEP.


The "Security package version/revision bumps and package masks" looks
relevant because it defines the "power" of the project:

> * The Security Project does not want to override the maintainer's
>   autonomy, but if inactive might be required to fix a security
>   vulnerability by means of version bump or application of a patch in
>   a revision bump.

I am not sure about this point. I am not aware of any GLEP/rule
disallowing devs to touch packages of any other devs. When I did my
quizzes I learned that you should have good reasons to do so and that
you are responsible for any breakage. In other words: Only do that after
you tried to contact the package maintainer (create a bug,
write an email, try to talk to the maintainer/project in IRC...) but did
not get a reply in time and always respect maintainer's coding
preferences (i.e. don't rewrite the whole ebuild because you would do
things differently when you just wanted to add a small patch fixing a
build issue).

In other words: Everyone is allowed to bump a package so we don't need
to write down that security project is allowed to do that as well.

It is different for QA project because QA members maybe rewrite a whole
ebuild and ignore maintainer's preferences for project goals.


> * If a vulnerability is unlikely to be fixed by upstream or the
>   package's maintainer it might require a package mask. Such mask
>   should never break the stable dependency tree.

From my understanding the intention of this point is to make clear that
security project members are allowed to remove an ebuild/package for
ARCH users.

I would get rid of the "such mask should never break stable dependency
tree" because this a general rule. However, sometimes this might be
required: Imagine an application (app-misc/awesome) which still depends
on dev-lang/openssl-0.9.8 or any other ancient version of a dev-lang/*
package. The application itself is fine and working but no one is
providing an update to work with newer dependencies.
Now the dependencies are EOL and a vulnerability was discovered. Because
everything else has already migrated to a newer version no one is
providing a patch. To get stable tree clean we would have to apply a
package.mask. This would break the stable dependency tree so we would
also need to take action against app-misc/awesome.

This is something we should write down so everyone knows that the
Gentoo security project has this power.


> * These actions, performed on behalf of the Security Project, should
>   only be used if the Project finds it is in the best interest of
>   users and fellow developers to have the issue addressed as soon as
>   possible. Such action needs to be approved by the Security Project
>   Lead (or if a Deputy is appointed; the Deputy)

This should be removed because this doesn't belong into a GLEP. That's
how the project internally works. And if the team decide to change
how it handle things this shouldn't require a new GLEP.


"Subscription to security lists and acting on behalf of Gentoo",
"Auditing and public reporting of issues in the name of Gentoo",
"Embargoed lists" and "CVE Numbering Authority (CNA) status" don't
belong into a GLEP. This is about the project's internal organization.


See also:
=
[1] https://wiki.gentoo.org/wiki/GLEP:48


-- 
Regard

Re: [gentoo-dev] RFC: Pre-GLEP: Security Project

[Thomas Deutschmann]

On 2017-03-12 00:54, Kristian Fiskerstrand wrote:
>> 1. From this proposal it looks like the Security Project Lead
>> obtains a lot of power and a lot of responsibility, maybe too much
>> for a single person to handle.
>>
>> While the Deputy may be assigned, this still gives all power to
>> single hands. Maybe it will be better to establish something like
>> the Security Project Council (SPC)? E.g. three project members may
>> be elected to this SPC, so that all serious decisions will require
>> some team agreement from at least 2 SPC members. This way the
>> Deputy will not be needed as well.
>>
> The thinking here is that the project lead is the responsible party. Any
> ambiguity can still be escalated to the Gentoo Council, but someone
> needs to be responsible from the side of the Gentoo Security Project.

I completely disagree with that.

The whole powerful lead/deputy thing is going in the wrong direction.

We don't need that. Security project is nothing special and doesn't need
a strong lead with such a power to rule the entire Gentoo project.

In general, every full member in the project should be equal. So I would
list them all as confidential contact for example. This would lower the
chance to compromise a member because an attacker wouldn't know who will
get contacted. If we would only have one contact (like the lead) this
would be a high-value target.
Because the security project has some inactive/dev away members the team
maybe want to select some main contacts instead. But this is up to the
team/project and doesn't belong in any GLEP.


-- 
Regards,
Thomas




signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] RFC: Pre-GLEP: Security Project

[Thomas Deutschmann]

On 2017-03-12 23:53, Kristian Fiskerstrand wrote:
> On 03/11/2017 11:23 PM, Andrew Savchenko wrote:
>> While the Deputy may be assigned, this still gives all power to
>> single hands. Maybe it will be better to establish something like
>> the Security Project Council (SPC)? E.g. three project members may
>> be elected to this SPC, so that all serious decisions will require
>> some team agreement from at least 2 SPC members. This way the
>> Deputy will not be needed as well.
> 
> Something like this has been discussed. I personally don't like the
> approach too much given that it adds a certain degree of bureaucracy and
> can remove responsibility. An important part of the GLEP is that the
> project lead is responsible to the council for the changes that is made.
> Having possibility to overrule that by members would mean that the lead
> is not able to control the action, and as such, can't be responsible for
> it. If the members disagree with the lead they can call for re-election
> as per GLEP:39 already.

Looks like we are disagreeing about the role of a project lead.

The primary goal of any Gentoo project is to group people working
towards the same goal(s) in small, manageable groups. It shouldn't need
a lead in most cases to control the project members.

A lead is only needed if the team can't get a decision.

Saying that the team could call for re-election if they don't like
lead's decision is ridiculous from my view: Like said it isn't the lead
who controls the direction. It is the lead who should step down if
he/she doesn't feel comfortable with the team decision and no longer
wants to represent the project anymore because he/she disagree so much
with the team decision.


-- 
Regards,
Thomas




signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] RFC: Pre-GLEP: Security Project

[Thomas Deutschmann]

On 2017-03-12 19:35, Kristian Fiskerstrand wrote:
>> Why do Security Project members need to be ebuild devs?
>> Non ebuild developers can contribute by producing GLSAs, 
>> for example.
>
> Where is that requirement stated?

I agree with Roy. That's also my reading of

>  * The applicant must have successfully completed the Gentoo Developer quiz.

I agree with that requirement for a full membership (nobody would share
not yet disclosed vulnerabilities with us if he/she can't be sure that
people who will get this information aren't part of the project. I.e.
people will assume that these people have agreed on the same things
which is part of the process).

My answer for people who aren't devs yet but want to help: Feel free to
help! There are so many ways to help/contribute. If your motivation is
just a badge your are wrong for the project.

However, this doesn't belong into a GLEP.


-- 
Regards,
Thomas




signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] RFC: Pre-GLEP: Security Project

[Thomas Deutschmann]

On 2017-03-13 21:33, Rich Freeman wrote:
> [...]
> 
> And this is why I think you are talking past each other.  Kristian is
> thinking in terms of security being a special project, and Thomas is
> thinking in terms of security being a normal project.  Both are making
> completely reasonable suggestions in those contexts.

Thank you for this good summary. Really appreciated. From my view, you
got all the stances.


> The two areas that I see as possibly pushing security towards being a
> special project are:
> 1.  Masking or otherwise directly touching packages without waiting
> for the maintainer if the timeline passes.

Like said, clarifying the p.mask thing would be nice. Is it required?
No, I don't think so. At the moment I still trust in the Gentoo project
to find a solution in case we would have a situation like described [1].
But maybe I am too new and missed a fight ;-)


> 2.  Being able to represent Gentoo on special security mailing lists
> that have tight distribution.  (If somebody betrays this trust Gentoo
> could find itself cut off from all such lists, so Gentoo should use
> care here.)

People trust people, not titles. While it is important to have a
security contact, and we have security contacts listed [2], people will
contact a dev they know/trust using established channels and don't check
for current project lead. And this is a good thing.

Yes, anyone with @gentoo.org address could do harm to the Gentoo
project. You cannot prevent situations like that. If someone decides to
do something stupid in the name of Gentoo he/she can do.
All we can do is to clearly distance ourselves from the person and
making clear using our channels that this is not Gentoo's position and
that we have taken actions (any project may decide to kick someone; go
to ComRel; go to Council... our process to deal with situations like
that is well defined).

When I am saying the security project isn't special I am saying this
about the need of special privileges in the Gentoo world. Joining the
project is special. At least I am not aware that there are other Gentoo
projects where you have to pass an additional recruitment process
(besides infra and QA project). This is needed because project members
will get in touch with confidential information. People sharing
information with Gentoo security project trust in Gentoo to handle that
as expected.

If someone manages to join Gentoo security project, become a full member
and then starts to abuse gained knowledge (i.e. share/use confidential
information), this would damages the trust in Gentoo for years. I.e.
external sources would stop sharing information with Gentoo.

But this is nothing a project lead can prevent. Also, if the project
lead would be the only one responsible, what should happen in that case?
Should the lead who failed because he/she trusted the wrong person also
leave the Gentoo project and we are done?


> I'll finally note that there is also a possible compromise.  We might
> make security somewhat special, but decide that its powers aren't that
> important and so let it self-govern without forced Council
> interaction.  Even so we should probably create some avenue for appeal
> so that the next time an argument comes up over whether long-term
> masks vs overlays are the right solution people feel like they had
> input into the decision.

Sounds good for me.


See also:
=
[1]
https://archives.gentoo.org/gentoo-dev/message/46fdaade8901c2bda3197aaf0e7b5d87

[2] https://gentoo.org/support/security/#contact


-- 
Regards,
Thomas




signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] RFC: Pre-GLEP: Security Project

[Thomas Deutschmann]

On 2017-03-13 22:47, Kristian Fiskerstrand wrote:
> now I'm even more lost. Gentoo Developer quiz does not imply ebuild
> repository access, we have current developers in the project without
> tree access and they are doing an outstanding job, so depending on the
> definition of "full membership" 

Mh, I missed : Staffer
quiz was renamed to Developer quiz in December 2016.

And yes, they are doing an outstanding job.


-- 
Regards,
Thomas




signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] [PATCH] mysql-v2.eclass: Drop dead g3nt8.org mirror

[Thomas Deutschmann]

This is now committed.


-- 
Regards,
Thomas



signature.asc
Description: OpenPGP digital signature

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

[Thomas Deutschmann]

On 2017-05-03 21:25, Matthias Maier wrote:
> Let's keyword gcc-6 and try to get gcc-7 into the tree on time.

+1


-- 
Regards,
Thomas




signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Dropping ia64/ppc/sparc profiles to dev/exp

[Thomas Deutschmann]

On 2017-05-07 21:23, David Seifert wrote:
> TL;DR
> ia64/ppc/sparc teams are pretty much dead. They have been for a long
> time and this won't change any time soon. Gentoo should focus its
> resources on archs that are important and has the manpower to support.
> Let us please drop these 3 archs to dev profiles to ease maintenance.

+1

In security project we are currently discussing something similar. I.e.
we wanted to ask council (after talking with ATs) to drop security
coverage for sparc like we have already dropped support for ia64.

While discussing I raised the question if it isn't confusing to have

  - ~arch (testing)
  - arch (stable)
  - arch with security coverage (stable without security)

and suggested to drop the latter. Given that gentoo.org says "Security
is a primary focus of Gentoo Linux" it doesn't make any sense for me to
have a *stable* architecture without security coverage.

It isn't like security project adds any additional load to any arch
team, an architecture capable to keep up with normal keyword and
stabilization requests should also be able to keep up with security. In
other words: Any architecture lacking behind security is also lacking
behind normal keyword and stabilization procedure...

So I would highly appreciate such a change.

If we won't do something like that but will drop security coverage,
managing all the open security bugs will become very challenging because
then we will also have to track bugs where architectures with security
coverage are done but stable architectures without security coverage
blocking cleanup and things like that.

But to be clear: I am just sharing *my* view with you. I am not security
project lead so I am not speaking for the project. I guess Yury
(blueknight), current security project lead, will jump into this
discussion very soon.


-- 
Regards,
Thomas



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Dropping ia64/ppc/sparc profiles to dev/exp

[Thomas Deutschmann]

On 2017-05-09 10:12, Rich Freeman wrote:
> Why not?  If an arch is considered a non-security-supported arch
> then you would just ignore it in a security bug.

We dropped security coverage already for ia64 and are in the process to
drop it for sparc as well.

So how do you want to cleanup a package which is the last ebuild of the
package and still marked stabled for ia64/sparc? You cannot. If you are
lucky you would only remove a package without any rdeps. But in most
cases you are breaking the tree.


> Otherwise a revbump could break stage3 on those arches.

Is this really a problem? What could happen:

Worst case: Existing stage3 for this specific dev/exp architecture will
be very old because any attempt to refresh the stage3 image will fail
with a build error. However, the last working stage3 image won't go away
until it was replaced by a newer working one...

Also, is this different from current status? Not really: If this
architecture would be capable to keep up with all the other major
architectures the stage3 image would be in a current working state.
Build errors would be solved in time. We wouldn't discuss dropping them.
So we are only talking about architectures which have shown that they
are not able to keep up. And those architectures are already lacking
behind, i.e. they don't have a current stage3...


-- 
Regards,
Thomas



signature.asc
Description: OpenPGP digital signature

[gentoo-dev] Last rites: www-apps/joomla

[Thomas Deutschmann]

# Thomas Deutschmann  (17 May 2017)
# Multiple unpatched security vulnerabilities (see bug #603756, #610696,
#612650 ...)
# Removal in 30 days.
www-apps/joomla


-- 
Regards,
Thomas Deutschmann / Gentoo Security Team
C4DD 695F A713 8F24 2AA1  5638 5849 7EE5 1D5D 74A5



signature.asc
Description: OpenPGP digital signature

[gentoo-dev] Last rites: mail-client/squirrelmail

[Thomas Deutschmann]

# Thomas Deutschmann  (17 May 2017)
# Unpatched security vulnerability per bug #616700
# Removal in 30 days.
mail-client/squirrelmail


-- 
Regards,
Thomas Deutschmann / Gentoo Security Team
C4DD 695F A713 8F24 2AA1  5638 5849 7EE5 1D5D 74A5



signature.asc
Description: OpenPGP digital signature

[gentoo-dev] [PATCH] ssl-cert.eclass: Set default key length to 4096 bit and allow to specify message digest

[Thomas Deutschmann]

---
 eclass/ssl-cert.eclass | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/eclass/ssl-cert.eclass b/eclass/ssl-cert.eclass
index 6bec347234d..bfe5291314c 100644
--- a/eclass/ssl-cert.eclass
+++ b/eclass/ssl-cert.eclass
@@ -1,4 +1,4 @@
-# Copyright 1999-2014 Gentoo Foundation
+# Copyright 1999-2017 Gentoo Foundation
 # Distributed under the terms of the GNU General Public License v2
 
 # @ECLASS: ssl-cert.eclass
@@ -66,7 +66,8 @@ gen_cnf() {
 
# These can be overridden in the ebuild
SSL_DAYS="${SSL_DAYS:-730}"
-   SSL_BITS="${SSL_BITS:-1024}"
+   SSL_BITS="${SSL_BITS:-4096}"
+   SSL_MD="${SSL_MD:-sha256}"
SSL_COUNTRY="${SSL_COUNTRY:-US}"
SSL_STATE="${SSL_STATE:-California}"
SSL_LOCALITY="${SSL_LOCALITY:-Santa Barbara}"
@@ -166,6 +167,7 @@ gen_crt() {
if [ "${1}" ] ; then
ebegin "Generating self-signed X.509 Certificate for CA"
openssl x509 -extfile "${SSL_CONF}" \
+   -${SSL_MD} \
-days ${SSL_DAYS} -req -signkey "${base}.key" \
-in "${base}.csr" -out "${base}.crt" &>/dev/null
else
@@ -173,7 +175,7 @@ gen_crt() {
ebegin "Generating authority-signed X.509 Certificate"
openssl x509 -extfile "${SSL_CONF}" \
-days ${SSL_DAYS} -req -CAserial "${SSL_SERIAL}" \
-   -CAkey "${ca}.key" -CA "${ca}.crt" \
+   -CAkey "${ca}.key" -CA "${ca}.crt" -${SSL_MD} \
-in "${base}.csr" -out "${base}.crt" &>/dev/null
fi
eend $?
-- 
2.13.0

Re: [gentoo-dev] [PATCH] ssl-cert.eclass: Set default key length to 4096 bit and allow to specify message digest

[Thomas Deutschmann]

Hi,

now committed via
https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=8daf322064245417d95057131f89e4e4e1d75f96


-- 
Regards,
Thomas



signature.asc
Description: OpenPGP digital signature

[gentoo-dev] Last rites: www-apps/postfixadmin

[Thomas Deutschmann]

# Thomas Deutschmann  (08 Jun 2017)
# Unmaintained in Gentoo; Unpatched security bugs.
# Removal in 30 days. Bug #608726
www-apps/postfixadmin


If you are using www-apps/postfixadmin or want to keep the package in
official Gentoo repository, it is now _your_ time to offer your help or
this package will be removed in 30 days.

Non-Gentoo developer who wants to help can contribute through the Gentoo
Proxy Maintainers project. See
https://wiki.gentoo.org/wiki/Project:Proxy_Maintainers#Getting_Started
for more information.


-- 
Regards,
Thomas Deutschmann / Gentoo Security Team
C4DD 695F A713 8F24 2AA1  5638 5849 7EE5 1D5D 74A5



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Re: taking a break from arches stabilization

[Thomas Deutschmann]

>>> Anecdotal evidence against, currently gnupg 2.1.21 scdaemon bug will
>>> happily sign a third party public keyblock's UID using signature subkey
>>> on smartcard, which results in useless signature that doesn't have any
>>> effect, but the application builds fine.
>>>
>>> This means gnupg 2.1.21 is not a candidate for stabilization, but it
>>> certainly builds fine.
>>>
>>
>> Stop trolling - you know perfectly well that this sort of issue would
>> never ever be caught during arch testing. Nor should it be - it's called
>> *arch* testing for a reason.

Question is what's more a problem: Having an outdated stable package
because nobody cared about stabilizing a new version (in most cases this
will end with a rushed stabilization once a security bug was fixed in
the package) or move a package in time from ~ARCH to ARCH and deal with
the fallout sometimes.

Having a real AT doing real arch testing work would be ideal. But face
it: We don't have the required man power. Let's try Debian's testing
approach and move packages to ARCH in time and don't wait for some
magical appearing bug reports because someone really tested a package in
~ARCH. Severe problems will be reported anyways...


-- 
Regards,
Thomas



signature.asc
Description: OpenPGP digital signature

[gentoo-dev] Last rites: media-gfx/autotrace

[Thomas Deutschmann]

# Thomas Deutschmann  (16 Jul 2017)
# Discontinued project with multiple vulnerabilities, removal
# in a month (#620802)
media-gfx/autotrace


-- 
Regards,
Thomas Deutschmann / Gentoo Security Team
C4DD 695F A713 8F24 2AA1  5638 5849 7EE5 1D5D 74A5



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Sanity check: enewuser in binpkg with portage-utils

[Thomas Deutschmann]

Hi,

keep in mind that when installing a binpkg, src_* functions are skipped,
see https://devmanual.gentoo.org/ebuild-writing/functions/

So when you are doing anything with the actual user, you have to do that
in a pkg_* function.

In case of "exeopts", if you do something like

  exeopts -m 6710 -g plgudev

in any src_* function, the created image will use the GID/UIDs from the
system used to create the binpkg. This is probably your problem...

Make sure to adjust permissions in pkg_* functions!


-- 
Regards,
Thomas



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Sanity check: enewuser in binpkg with portage-utils

[Thomas Deutschmann]

On 2017-07-20 19:17, Michał Górny wrote:
> No. This is entirely wrong and insane. Tar stores user and group
> names, and restores them correctly.
Oops, thanks for correction.


-- 
Regards,
Thomas



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] sys-libs/ncurses: erronious deletion of *.dll.a files; possibly other packages affected

[Thomas Deutschmann]

Hi,

sounds like we should convert to prune_libtool_files usage from
ltprune.eclass.

However, the eclass says

> # Discouraged. Whenever possible, please use much simpler:
> # find "${D}" -name '*.la' -delete || die

So this would need clarification.


-- 
Regards,
Thomas



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Packages up for grabs

[Thomas Deutschmann]

Hi,

I'll take

> dev-php/pecl-gearman> sys-cluster/gearmand
if nobody else is interested.


-- 
Regards,
Thomas



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] AMD64 Arch Testers needed urgently

[Thomas Deutschmann]

On 2017-12-12 19:24, Rich Freeman wrote:
> As far as I'm aware the standing policy already exists that
> maintainers can stabilize their own packages on amd64.

That's right but keep in mind that nevertheless you need a stable
system. Marking a package stable because it works on your ~arch box you
use for your daily dev work would lead the whole process ad absurdum.

And in general maintainer stabilization should be the last resort. The
person who wrote the ebuild maybe doesn't notice that the ebuild is
doing something wrong (doesn't honor CFLAGS, calls compiler directly,
not working with /bin/sh not /bin/bash ...).


-- 
Regards,
Thomas Deutschmann / Gentoo Linux Developer
C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] AMD64 Arch Testers needed urgently

[Thomas Deutschmann]

On 2017-12-13 18:51, William Hubbs wrote:
> In theory, this is correct. However, when maintainers don't stabilize
> packages and no one else does either, our stable tree suffers.

I agree but we have to pay attention that we don't stabilize packages at
all costs because otherwise they would never go stable.

If this is the problem then we should discuss stabilization at all. What
do people expect from something marked stable vs. reality. ;)

And in this case I would prefer a system like Debian SID -> Testing
supported by build bots. I can think of 2 variants:

a) Once maintainer files a stabilization request, a build bot will pick
up the bug and try building the package in a chroot per architecture. If
everything passes build bot will mark the version stable for the tested
architecture.

A flag or a blacklist could prevent build bot stabilization.


b) Because not all devs care about stable Gentoo, I would recommend
auto-stabilization: I.e. if a package is in the repository for x days
build bot would try to build the package and mark the package stable if
everything passes. If for some reason maintainer want to block a
specific version they could create a bug or set a flag in an already
existing bug which will cause build bot to ignore this version.


-- 
Regards,
Thomas Deutschmann / Gentoo Linux Developer
C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] AMD64 Arch Testers needed urgently

[Thomas Deutschmann]

On 2017-12-14 01:58, Kent Fredric wrote:
> On Wed, 13 Dec 2017 21:58:05 +0100
> Thomas Deutschmann  wrote:
> 
>> b) Because not all devs care about stable Gentoo, I would recommend
>> auto-stabilization: I.e. if a package is in the repository for x days
>> build bot would try to build the package and mark the package stable
>> if everything passes. If for some reason maintainer want to block a
>> specific version they could create a bug or set a flag in an already
>> existing bug which will cause build bot to ignore this version.
> 
> Slightly modified suggestion:
> 
> Add a flag called "autostabilize" with [unset], [y], [n]

Flag in Bugzilla?


> Default is 'unset', and if found unset after a given time, it flips to
> y and the stable bot gets queued up.
> 
> If its set to 'n', then stable bot never does anything.
> 
> This way maintainers who want to rush the stablebot on things they
> consider "safe" can get ahead of the queue.

Sounds good but the variant b was about full auto-stabilization. I.e.
the idea that we even don't require stabilization bugs anymore (like
Debian, where a package will move from SID to testing after some time if
nobody created a blocker bug).

We could auto-generate bugs but I am not sure if this is a good idea.
When mgorny set up autolinking of Github PRs there was some "bug spam"
when people lost control over Git and messed up the rebase (now
prevented via limits).

Also I am not sure how we should handle things like Gnome/KDE
stabilization which requires that a bunch of packages will be stabilized
at once. I.e. if bot detects a new ebuild of kde-frameworks/kservice
auto-stabilization is only allowed to kick in if it is a rev bump of an
already stable ebuild but shouldn't auto-start stabilization of next KDE
version on its own (at least I guess this is what we want).

But well, for the beginning we don't need the perfect solution. We can
start with an easy mode and blacklist most packages. So devs interested
can remove their packages from blacklist. And like said, build bot would
still handle stabilization bugs.


-- 
Regards,
Thomas Deutschmann / Gentoo Linux Developer
C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5



signature.asc
Description: OpenPGP digital signature

[gentoo-dev] Last rites: net-libs/polarssl

[Thomas Deutschmann]

# Thomas Deutschmann  (14 Dec 2017)
# Unpatched security vulnerability per bug #537108
# Removal in 30 days. Please migrate to net-libs/mbedtls if you have
# not done yet.
net-libs/polarssl


-- 
Regards,
Thomas Deutschmann / Gentoo Security Team
C4DD 695F A713 8F24 2AA1  5638 5849 7EE5 1D5D 74A5



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] AMD64 Arch Testers needed urgently

[Thomas Deutschmann]

On 2017-12-14 21:06, R0b0t1 wrote:
> In response to the concerns about stability: If I run a lot of unstable
> packages, would that preclude my system from being able to help?

Yes. Only clean stable systems are eligible for arch testing. That's the
whole idea of arch testing... ;)

Remember that mixed systems aren't officially supported.


-- 
Regards,
Thomas Deutschmann / Gentoo Linux Developer
C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] AMD64 Arch Testers needed urgently

[Thomas Deutschmann]

On 2017-12-14 20:45, William Hubbs wrote:
> I tend to like this better. Let's try to move away from filing stable
> requests for new versions of packages once an old version is stable and
> have a way to block newer versions from going stable. Maybe buildbot
> could check to see if there is a bug open against the version it is
> looking at, then check the keywords or severity of that bug and  use one
> or the other of those to decide whether or not to skip stabilizing that 
> version
> of the package.

How would you identify such a bug? Someone reports a bug. He/she is
using app-misc/foo-1.2-r2 at the moment. It is often not clear if the
bug affects only =app-misc/foo-1.2-r2, >=, ... What's about foo-2.0?
Maybe foo-1.1 is also affected but wasn't (yet) tested...


> In other words, the first stabilization for a package on an architecture
> should be done the way we currently do them, by filing a stable request
> then using the current stabilization process.

I am not sure if something like this should be a general rule. But like
said, maintainer could either opt-in or opt-out from auto-stabilization.
So if you think your new package is somehow special...


-- 
Regards,
Thomas Deutschmann / Gentoo Linux Developer
C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] AMD64 Arch Testers needed urgently

[Thomas Deutschmann]

On 2017-12-14 21:53, Alec Warner wrote:
> I'm skeptical the keywords for most packages matter, particularly on
> common arches. Remember this is usually software that upstream
> already tested and released; so most of the bugs would be ebuild /
> Gentoo related.

That's why I prefer Debian's SID -> Testing workflow.

If a package has multiple users, a serious problem will popup very soon.
So stabilization would be blocked.

If a package hasn't many users and a problem also affects only a special
configuration we maybe won't notice before "regular" stabilization and
after some time...

So why should we wait...


-- 
Regards,
Thomas Deutschmann / Gentoo Linux Developer
C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] [QA] New policy: 'files' directory must not be larger than 32 KiB

[Thomas Deutschmann]

On 2017-12-19 21:44, R0b0t1 wrote:
> How easy is it to move patches to Gentoo infrastructure if the patches
> are not provided by upstream? I am slightly uncomfortable with
> everything being pushed to websites like GitHub by default.

Don't get me wrong but this a *dev* mailing list. Your statement clearly
indicate that you don't understand about what we are talking. So maybe
it is better to not say a word?

1) Gentoo doesn't host anything on GitHub. We are only mirroring content
from git.gentoo.org on GitHub.

2) We are talking about Gentoo patches, nothing which can be found upstream.

3) https://devmanual.gentoo.org/general-concepts/mirrors/


-- 
Regards,
Thomas Deutschmann / Gentoo Linux Developer
C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] [QA] New policy: 'files' directory must not be larger than 32 KiB

[Thomas Deutschmann]

Hi,

mysql project is using https://gitweb.gentoo.org/proj/mysql-extras.git/
(i.e. an own repository) to track patches.

What I like about it:

1) We track patches/changes due to using a VCS.

2) We can fetch directly from gitweb.gentoo.org, i.e. no need to adjust
SRC_URI when changing a patch. Just push your patch, create and push a
new tag, update the patch set variable and you are done.

Reminds me of
https://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo/src/patchsets/

What I don't like about this:

Cleanup is probably not that easy, the patch tarball size will increase
over the time because tracking which patches are still in use can become
a challenge.

If you use a patch tarball the ebuild will probably don't use EAPI's
default src_prepare function. You will use code like

> eapply "${WORKDIR}"/patch/*.patch
> eapply_user

which makes it not an easy/clean task to just add *one* small/temporary
patch if you need to.


-- 
Regards,
Thomas Deutschmann / Gentoo Linux Developer
C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] The problem of unmaintained packages in Gentoo

[Thomas Deutschmann]

On 2017-12-21 01:35, William Hubbs wrote:
> ~arch *will* have breakages from time to time, sometimes major
> breakages, until they are masked or fixed. We are not supposed to leave
> major breakages there, but ~arch is definitely not for the faint of
> heart. If you are using ~arch, you are expected to be a power user at
> leasst and be able to recover if your system breaks. Production servers
> should not be running ~arch at all. That's the whole reason ~arch
> exists.

I don't agree with this.

Yes, ~arch can break sometimes so you should be familiar with masking.

But on the other hand: ~arch isn't a minefield. If you add something to
the repository which is keyworded you should at least know that it
builds and works in the default USE flag configuration. If you don't
know and there's a chance to break something badly, drop keywords or add
it with a mask.

Breaking ~arch because a dev was unable to test for some reason is IMHO
unacceptable -- even for ~arch. That's the whole reason why
keywords/p.mask exist ;-)


-- 
Regards,
Thomas Deutschmann / Gentoo Linux Developer
C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] RFC: Bugzilla arch list reordering

[Thomas Deutschmann]

Hi,

On 2018-01-23 12:46, Michał Górny wrote:
>> I've created a small HTML file with example of how this would look:
>>
>> https://dev.gentoo.org/~mgorny/tmp/cc.html
>>
> 
> I've updated the example to include the variant suggested by Dirkjan.
> All arches are order according to the popularity (based on the results
> from his mail), except Prefix which I left at the bottom as a special
> case.

grobian's variant doesn't work for me:

When I start stabilization (especially for security bugs) I check
existing keywords via "ekeywords". For many packages I can select
"ALPHA" and scroll down to "Unstable arches", i.e. press and hold SHIFT
key and click "X86". Very easy. Grobian's variant would require to
deselect arm64 for example.

djc's variant is better than grobian's variant, however I prefer a label
item like current "Unstable arches" which makes it easy for me to spot
the end of the typical list.

In mgorny's variant I don't understand the differentiation between "exp"
and "~arch". I won't split them to be honest.

Can't we keep current variant, maybe rename "Unstable arches" into
"Unstable arches / exp" and just update "Other teams" items?


-- 
Regards,
Thomas Deutschmann / Gentoo Linux Developer
C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5



signature.asc
Description: OpenPGP digital signature

[gentoo-dev] Last rites: sys-cluster/ganglia-web

[Thomas Deutschmann]

# Thomas Deutschmann  (23 Feb 2018)
# Unmaintained in Gentoo, known critical vulnerabilities like
# auth bypass. Removal in 30 days. Bugs #559658, #592080.
sys-cluster/ganglia-web


If you are using sys-cluster/ganglia-web or want to keep the package in
official Gentoo repository, it is now _your_ time to offer your help or
this package will be removed in 30 days.

Non-Gentoo developer who wants to help can contribute through the Gentoo
Proxy Maintainers project. See
https://wiki.gentoo.org/wiki/Project:Proxy_Maintainers#Getting_Started
for more information.


-- 
Regards,
Thomas Deutschmann / Gentoo Security Team
C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] python-any-r1 deps used only for testing

[Thomas Deutschmann]

On 2018-02-28 23:03, Francesco Riosa wrote:
> Result is that with no python:2.7 installed ebuild will fail, always
> both with test enabled or disabled.

Why haven't you posted this information in the bug?!


> I've realized all this after bug https://bugs.gentoo.org/648940 was
> closed, that discussion didn't go very well, [...]

Really? Thought

> Feel free to keep commenting if you think I am wrong. I'll be notified
> and read your comment.

was pretty clear that you can talk with me...

Anyway, fixed via
https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=cfaa5ec192519a74951fd57f05c483984e408e4b.
Thank you for the report.


-- 
Regards,
Thomas Deutschmann / Gentoo Linux Developer
C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] New Portage fork: sys-apps/portage-mgorny

[Thomas Deutschmann]

On 2018-03-23 18:44, Patrick McLean wrote:
> At my (and zmedico's) employer we use Gentoo heavily (all of our servers
> run it), and have a few large internal overlays and hundreds of internal
> profiles. There are packages in upstream Gentoo that we maintain an
> internal fork of, and it would be extremely useful if we could mask the
> ::gentoo version of something so a version bump does not cause it to be
> installed instead of our forked version.

I have the same need, but it works for me: I have several packages in
/etc/portage/package.mask directory with content like

  /::gentoo

to make sure the package from Gentoo repository isn't used.

But I guess you are talking about a different thing?


-- 
Regards,
Thomas Deutschmann / Gentoo Linux Developer
C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] New category: app-metrics

[Thomas Deutschmann]

On 2018-03-22 09:57, Dirkjan Ochtman wrote:
> On the face of it, I wouldn't drop the "prometheus-" prefix if
> app-metrics is to be the home to other tools. Otherwise, other tools
> like graphite or collectd might want very similar names for the same
> tools out  there.

I second this. Please keep "prometheus-" prefix.


-- 
Regards,
Thomas Deutschmann / Gentoo Linux Developer
C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5



signature.asc
Description: OpenPGP digital signature

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

[Thomas Deutschmann]

On 2016-08-17 01:49, Matthias Maier wrote:
>> I have received a request to implement a feature in OpenRC to allow
>> multiple software packages to drop files in a directory, /etc/modules.d
>> for example, which would define modules the /etc/init.d/modules script
>> would load.
>
> What about /etc/modules-load.d containing various files that list one
> module to load per line? With this, OpenRC's behavior would be
> compatible with systemd-modules-load [1].

+1

I wanted to ask the same after working on bug 480018 [1].



[1] https://bugs.gentoo.org/480018


-- 
Regards,
Thomas
aka Whissi




signature.asc
Description: OpenPGP digital signature

[gentoo-dev] [PATCH] eutils.eclass: Show death notice only when user patches were really applied

[Thomas Deutschmann]

As part of the user requested feature from [Gentoo-Bug #543878]
eutils.eclass shows a warning regarding user applied patches in case of an
error [Link 1].

However this warning will always be shown even if no user patch were
applied at all (example: empty /etc/portage// directory).

This commit adds a new global variable "EPATCH_N_APPLIED_PATCHES" which
tracks the number of applied user patches. This allows us to only show the
notice when user patches were really applied.

Link: 
https://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/eclass/eutils.eclass?r1=1.443&r2=1.444

Gentoo-Bug: https://bugs.gentoo.org/543878
---
 eclass/eutils.eclass | 11 ++-
 1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/eclass/eutils.eclass b/eclass/eutils.eclass
index dbedffe..025e388 100644
--- a/eclass/eutils.eclass
+++ b/eclass/eutils.eclass
@@ -292,6 +292,10 @@ EPATCH_OPTS=""
 #  -E - automatically remove empty files
 # @CODE
 EPATCH_COMMON_OPTS="-g0 -E --no-backup-if-mismatch"
+# @VARIABLE: EPATCH_N_APPLIED_PATCHES
+# @DESCRIPTION:
+# Counter variable which indicates how many patches were applied.
+EPATCH_N_APPLIED_PATCHES=0
 # @VARIABLE: EPATCH_EXCLUDE
 # @DESCRIPTION:
 # List of patches not to apply. Note this is only file names,
@@ -595,6 +599,8 @@ epatch() {
: $(( count++ ))
done
 
+   : $(( EPATCH_N_APPLIED_PATCHES++ ))
+
# if we had to decompress the patch, delete the temp one
if [[ -n ${PIPE_CMD} ]] ; then
rm -f "${PATCH_TARGET}"
@@ -1736,13 +1742,16 @@ epatch_user() {
[[ -r ${EPATCH_SOURCE} ]] || 
EPATCH_SOURCE=${EPATCH_USER_SOURCE}/${CHOST}/${check}
[[ -r ${EPATCH_SOURCE} ]] || 
EPATCH_SOURCE=${EPATCH_USER_SOURCE}/${check}
if [[ -d ${EPATCH_SOURCE} ]] ; then
+   local old_n_applied_patches=${EPATCH_N_APPLIED_PATCHES}
EPATCH_SOURCE=${EPATCH_SOURCE} \
EPATCH_SUFFIX="patch" \
EPATCH_FORCE="yes" \
EPATCH_MULTI_MSG="Applying user patches from 
${EPATCH_SOURCE} ..." \
epatch
echo "${EPATCH_SOURCE}" > "${applied}"
-   has epatch_user_death_notice ${EBUILD_DEATH_HOOKS} || 
EBUILD_DEATH_HOOKS+=" epatch_user_death_notice"
+   if [[ ${old_n_applied_patches} -lt 
${EPATCH_N_APPLIED_PATCHES} ]]; then
+   has epatch_user_death_notice 
${EBUILD_DEATH_HOOKS} || EBUILD_DEATH_HOOKS+=" epatch_user_death_notice"
+   fi
return 0
fi
done
-- 
2.9.3

Re: [gentoo-dev] [PATCH] eutils.eclass: Show death notice only when user patches were really applied

[Thomas Deutschmann]

On 2016-08-22 09:30, Ulrich Mueller wrote:
> I wonder if extending an obsolete feature is worth the effort.
> In EAPI 6, epatch_user has been replaced by eapply_user.

Well, I created the patch in November 2015 but never submitted it.
Yesterday someone in #gentoo-dev also asked about that false-positive
warning...

Yes, EAPI >=6 doesn't have this problem anymore. But many system
packages won't migrate to EAPI=6 very soon. So this irritating warning
will stay for the next years if we don't fix it. And because it is an
easy fix... isn't it?


>> +: $(( EPATCH_N_APPLIED_PATCHES++ ))
> 
> Why not simply:
>   (( EPATCH_N_APPLIED_PATCHES++ ))

When I created the patch I tried to use the same coding style. See

>   : $(( count++ ))

two lines above.

Can I keep this or should I change?


>> +if [[ ${old_n_applied_patches} -lt 
>> ${EPATCH_N_APPLIED_PATCHES} ]]; then
>> +has epatch_user_death_notice 
>> ${EBUILD_DEATH_HOOKS} || EBUILD_DEATH_HOOKS+=" epatch_user_death_notice"
> 
> Please keep lines no wider than 80 character positions.

OK, I'll split the "has epatch_..." line after the "||".


Thanks for reviewing.


-- 
Regards,
Thomas




signature.asc
Description: OpenPGP digital signature

[gentoo-dev] [PATCH v2] eutils.eclass: Show death notice only when user patches were really applied

[Thomas Deutschmann]

As part of the user requested feature from [Gentoo-Bug #543878]
eutils.eclass shows a warning regarding user applied patches in case of an
error [Link 1].

However this warning will always be shown even if no user patch were
applied at all (example: empty /etc/portage// directory).

This commit adds a new global variable "EPATCH_N_APPLIED_PATCHES" which
tracks the number of applied user patches. This allows us to only show the
notice when user patches were really applied.

Link: 
https://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/eclass/eutils.eclass?r1=1.443&r2=1.444

Gentoo-Bug: https://bugs.gentoo.org/543878
---
 eclass/eutils.eclass | 12 +++-
 1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/eclass/eutils.eclass b/eclass/eutils.eclass
index dbedffe..27b542c 100644
--- a/eclass/eutils.eclass
+++ b/eclass/eutils.eclass
@@ -292,6 +292,10 @@ EPATCH_OPTS=""
 #  -E - automatically remove empty files
 # @CODE
 EPATCH_COMMON_OPTS="-g0 -E --no-backup-if-mismatch"
+# @VARIABLE: EPATCH_N_APPLIED_PATCHES
+# @DESCRIPTION:
+# Counter variable which indicates how many patches were applied.
+EPATCH_N_APPLIED_PATCHES=0
 # @VARIABLE: EPATCH_EXCLUDE
 # @DESCRIPTION:
 # List of patches not to apply. Note this is only file names,
@@ -595,6 +599,8 @@ epatch() {
: $(( count++ ))
done
 
+   (( EPATCH_N_APPLIED_PATCHES++ ))
+
# if we had to decompress the patch, delete the temp one
if [[ -n ${PIPE_CMD} ]] ; then
rm -f "${PATCH_TARGET}"
@@ -1736,13 +1742,17 @@ epatch_user() {
[[ -r ${EPATCH_SOURCE} ]] || 
EPATCH_SOURCE=${EPATCH_USER_SOURCE}/${CHOST}/${check}
[[ -r ${EPATCH_SOURCE} ]] || 
EPATCH_SOURCE=${EPATCH_USER_SOURCE}/${check}
if [[ -d ${EPATCH_SOURCE} ]] ; then
+   local old_n_applied_patches=${EPATCH_N_APPLIED_PATCHES}
EPATCH_SOURCE=${EPATCH_SOURCE} \
EPATCH_SUFFIX="patch" \
EPATCH_FORCE="yes" \
EPATCH_MULTI_MSG="Applying user patches from 
${EPATCH_SOURCE} ..." \
epatch
echo "${EPATCH_SOURCE}" > "${applied}"
-   has epatch_user_death_notice ${EBUILD_DEATH_HOOKS} || 
EBUILD_DEATH_HOOKS+=" epatch_user_death_notice"
+   if [[ ${old_n_applied_patches} -lt 
${EPATCH_N_APPLIED_PATCHES} ]]; then
+   has epatch_user_death_notice 
${EBUILD_DEATH_HOOKS} || \
+   EBUILD_DEATH_HOOKS+=" 
epatch_user_death_notice"
+   fi
return 0
fi
done
-- 
2.9.3

[gentoo-dev] [PATCH v3] eutils.eclass: Show death notice only when user patches were really applied

[Thomas Deutschmann]

Here's v3. Ulm suggested to get rid of the global EPATCH_N_APPLIED_PATCHES 
variable
so that EAPI 6' environment stays clean.

Thomas Deutschmann (1):
  eutils.eclass: Show death notice only when user patches were really
applied

 eclass/eutils.eclass | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

-- 
2.9.3

[gentoo-dev] [PATCH v3] eutils.eclass: Show death notice only when user patches were really applied

[Thomas Deutschmann]

As part of the user requested feature from [Gentoo-Bug #543878]
eutils.eclass shows a warning regarding user applied patches in case of an
error [Link 1].

However this warning will always be shown even if no user patch were
applied at all (example: empty /etc/portage// directory).

This commit adds a new global variable "EPATCH_N_APPLIED_PATCHES" which
tracks the number of applied user patches. This allows us to only show the
notice when user patches were really applied.

Link: 
https://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/eclass/eutils.eclass?r1=1.443&r2=1.444

Gentoo-Bug: https://bugs.gentoo.org/543878
---
 eclass/eutils.eclass | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/eclass/eutils.eclass b/eclass/eutils.eclass
index dbedffe..aaf195b 100644
--- a/eclass/eutils.eclass
+++ b/eclass/eutils.eclass
@@ -595,6 +595,8 @@ epatch() {
: $(( count++ ))
done
 
+   (( EPATCH_N_APPLIED_PATCHES++ ))
+
# if we had to decompress the patch, delete the temp one
if [[ -n ${PIPE_CMD} ]] ; then
rm -f "${PATCH_TARGET}"
@@ -1736,13 +1738,17 @@ epatch_user() {
[[ -r ${EPATCH_SOURCE} ]] || 
EPATCH_SOURCE=${EPATCH_USER_SOURCE}/${CHOST}/${check}
[[ -r ${EPATCH_SOURCE} ]] || 
EPATCH_SOURCE=${EPATCH_USER_SOURCE}/${check}
if [[ -d ${EPATCH_SOURCE} ]] ; then
+   local 
old_n_applied_patches=${EPATCH_N_APPLIED_PATCHES:-0}
EPATCH_SOURCE=${EPATCH_SOURCE} \
EPATCH_SUFFIX="patch" \
EPATCH_FORCE="yes" \
EPATCH_MULTI_MSG="Applying user patches from 
${EPATCH_SOURCE} ..." \
epatch
echo "${EPATCH_SOURCE}" > "${applied}"
-   has epatch_user_death_notice ${EBUILD_DEATH_HOOKS} || 
EBUILD_DEATH_HOOKS+=" epatch_user_death_notice"
+   if [[ ${old_n_applied_patches} -lt 
${EPATCH_N_APPLIED_PATCHES} ]]; then
+   has epatch_user_death_notice 
${EBUILD_DEATH_HOOKS} || \
+   EBUILD_DEATH_HOOKS+=" 
epatch_user_death_notice"
+   fi
return 0
fi
done
-- 
2.9.3

Re: [gentoo-dev] newsitem: openrc runscript transition (draft 3)

[Thomas Deutschmann]

On 2016-08-24 19:07, William Hubbs wrote:
> I do not plan to drop runscript at this point, that will happen when
> openrc-1.0 is released, which will be a while yet.

...and that's the reason why I don't think this needs a newsitem.
There's _no_ problem and no _immediate_ user interaction is required.

I would only adjust the current warning from

>  * /etc/init.d/test uses runscript, please convert to openrc-run.

to

> * /etc/init.d/test uses runscript and must be converted to openrc-run
> * For more details see /usr/share/doc/openrc-*/openrc-migration*

In "/usr/share/doc/openrc-*/openrc-migration*" we describe _why_ this
was changed and tell them that all files in FILESDIR were already
migrated so chances are high that

  # emerge --oneshot -av $(grep -l '/sbin/runscript' /etc/init.d/*)

will replace most runscripts with migrated scripts.

If the user has already done that he/she should check which packages
owns the runscript (qfile /etc/init.d/foo) and should file a bug against
that package.

Finally add a note for package owner (don't forget user's repositories!)
and tell them what they need to do (which line must be changed, show
example before and after the migration).


And as additional help sys-apps/openrc ebuild should start scanning for
"/sbin/runscript" usage in pkg_postinst and show an ewarn with text
pointing to the same file.

Done.


...once an openrc version without "/sbin/runscript" will be released we
will have to release a newsitem before because _then_ we really require
user interaction and must force people to take notice.


PS: And don't forget to fix the warning from /sbin/runscript to honor
"--quiet". If this bug wouldn't exist we wouldn't talk about a newsitem
at the moment ;-)


-- 
Regards,
Thomas




signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] newsitem: openrc runscript transition (draft 3)

[Thomas Deutschmann]

On 2016-08-24 23:59, William Hubbs wrote:
> Since OpenRC is used outside of Gentoo, a warning like this would have
> to be:
> 
> * /etc/init.d/test uses runscript and must be converted to openrc-run
> * For more details see the OpenRC NEWS file
> 
> because we don't know where or if the file will be installed by
> downstreams.

Yes, this will be the message in OpenRC's SRC. However you could patch
that message for Gentoo in the ebuild.


>> In "/usr/share/doc/openrc-*/openrc-migration*" we describe _why_ this
>> was changed and tell them that all files in FILESDIR were already
>> migrated so chances are high that
>>
>>   # emerge --oneshot -av $(grep -l '/sbin/runscript' /etc/init.d/*)
>>
>> will replace most runscripts with migrated scripts.
>>
>> If the user has already done that he/she should check which packages
>> owns the runscript (qfile /etc/init.d/foo) and should file a bug against
>> that package.
> 
> We can't really put anything distro-specific in the news file, because we
> don't know how distros will handle it.

...now with the patched message you can promote our own file. And this
file can get installed from $FILESDIR for example.

You are using GitHub for OpenRC upstream, right? So create a guide in
project's Wiki (or add it to the docs folder in the src) which will
explain the changes. This guide can have a section to explain what to do
on Debian, one for Gentoo... but this is all upstream.

My point is, that for Gentoo downstream, you can patch/customize like we
do for all the other packages to work with Gentoo.


>> And as additional help sys-apps/openrc ebuild should start scanning for
>> "/sbin/runscript" usage in pkg_postinst and show an ewarn with text
> 
> I wouldn't say that the OpenRC ebuild should be concerned about this,
> but I believe there is a check in repoman for it.

I agree. However I see that more like a service for Gentoo users. Users
don't run repoman. And don't forget that the user could have _custom_
runscripts or additional packages from other sources which repoman will
never see... so it is nice to have a friendly reminder (the problem is,
that if an user acts _now_ and fixes all currently installed runscripts
he/she could face the problem in future again if he/she installs a new
package after that which wasn't updated yet... that's why I would add
such a scan).


...and we don't need to believe to catch all the runscripts in the world
even if openrc-1.0.0 will be released in 100y. Some user will finally
notice with the newsitem prior openrc-1.0.0 release which will tell them
that /sbin/runscript was finally removed... but there _will_ be users
after that which will get hit. And they will complain "you" broke their
system despite all the effort to prevent such situations. ;-)


-- 
Regards,
Thomas




signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] [PATCH v3] eutils.eclass: Show death notice only when user patches were really applied

[Thomas Deutschmann]

Hi,

now committed, see commit f7d866b62b.


-- 
Regards,
Thomas



signature.asc
Description: OpenPGP digital signature

[gentoo-dev] [PATCH] php-ext-source-r3.eclass: Add src_test function

[Thomas Deutschmann]

php-ext-source-r3 eclass currently does not provide FEATURES=test support
like php-ext-pecl-r3 eclass does. This commit will add and export the
src_test function from php-ext-pecl-r3 eclass to php-ext-source-r3 eclass
to allow testing of PHP standalone extensions as well.
---
 eclass/php-ext-source-r3.eclass | 14 +-
 1 file changed, 13 insertions(+), 1 deletion(-)

diff --git a/eclass/php-ext-source-r3.eclass b/eclass/php-ext-source-r3.eclass
index 3372a4b..f2999d4 100644
--- a/eclass/php-ext-source-r3.eclass
+++ b/eclass/php-ext-source-r3.eclass
@@ -12,7 +12,7 @@
 
 inherit autotools
 
-EXPORT_FUNCTIONS src_unpack src_prepare src_configure src_compile src_install
+EXPORT_FUNCTIONS src_unpack src_prepare src_configure src_compile src_install 
src_test
 
 case ${EAPI} in
6) ;;
@@ -230,6 +230,18 @@ php-ext-source-r3_src_install() {
php-ext-source-r3_createinifiles
 }
 
+# @FUNCTION: php-ext-source-r3_src_test
+# @DESCRIPTION:
+# Run tests delivered with the standalone PHP extension. Phpize will have 
generated
+# a run-tests.php file to be executed by `make test`. We only need to
+# force the test suite to run in non-interactive mode.
+php-ext-source-r3_src_test() {
+   for slot in $(php_get_slots); do
+   php_init_slot_env "${slot}"
+   NO_INTERACTION="yes" emake test
+   done
+}
+
 # @FUNCTION: php_get_slots
 # @DESCRIPTION:
 # Get a list of PHP slots contained in both the ebuild's USE_PHP and the
-- 
2.10.1

[gentoo-dev] [PATCH] php-ext-source-r3.eclass: Add src_test function

[Thomas Deutschmann]

Hi,

I'd like to commit the following changes to php-ext-source-r3.eclass to add
FEATURES=test support for PHP standalone extensions as well.

The function itself is copied from php-ext-pecl-r3.eclass, so nothing new.

Thanks.


Regards,
Thomas
aka Whissi


Thomas Deutschmann (1):
  php-ext-source-r3.eclass: Add src_test function

 eclass/php-ext-source-r3.eclass | 14 +-
 1 file changed, 13 insertions(+), 1 deletion(-)

-- 
2.10.1

Re: [gentoo-dev] [PATCH] php-ext-source-r3.eclass: Add src_test function

[Thomas Deutschmann]

On 2016-10-08 00:18, Thomas Deutschmann wrote:
> [...]
> 
> Thomas Deutschmann (1):
>   php-ext-source-r3.eclass: Add src_test function
> 
>  eclass/php-ext-source-r3.eclass | 14 +-
>  1 file changed, 13 insertions(+), 1 deletion(-)

Now committed:

https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=902f8fef9c80174eece928c918dfd2b8855c5e19


-- 
Regards,
Thomas





signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] gpg: signing failed: Inappropriate ioctl for device

[Thomas Deutschmann]

On 2016-12-11 15:13, gro...@gentoo.org wrote:
> But this commit sits in my copy of the tree, and I cannot
> push it. What can I do?

You can't push because the commit isn't signed?

If it is the last commit, just run `git commit --amend -S`

If it isn't the last commit, try `git log` to get the commit id before
your unsinged commit followed by `git rebase -i
^`. Now set the unsigned commit to
"EDIT" (don't touch any other commits, keep "PICK") and run `git commit
--amend -S` and continue rebase to finish.

Now your commit should be signed and you should be able to push.

For future, apply settings like shown in
https://wiki.gentoo.org/wiki/Gentoo_git_workflow#Repository_settings to
the Gentoo repository to prevent situations like that.


-- 
Regards,
Thomas





signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] [PATCH] linux-info.eclass: enable EAPI 7

[Thomas Deutschmann]

On 2018-07-11 04:02, Marty E. Plummer wrote:
> versionator is banned in EAPI 7, so switch to either native EAPI 7
> version functions or inherit eapi7-ver on EAPI 0-6
> ---
> [...]
Thanks, this is now merged [1].


[1]: 
https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=c6b150836dfef848e51ec2cce801b12daf2c77b1


-- 
Regards,
Thomas Deutschmann / Gentoo Linux Developer
C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5



signature.asc
Description: OpenPGP digital signature

[gentoo-dev] News item review: OpenSSH LDAP support

[Thomas Deutschmann]

Hello everyone,

please review the following news item. The 'xx'-es will be replaced with
the publication date.

---
Title: OpenSSH LDAP support
Author: Thomas Deutschmann 
Posted: 2018-08-xx
Revision: 1
News-Item-Format: 2.0
Display-If-Installed: net-misc/openssh

When your sshd authenticates against LDAP, you have to migrate your
current setup to a new one using sshd's "AuthorizedKeysCommand" option and
use a wrapper provided by packages like the new sys-auth/ssh-ldap-pubkey
because beginning with net-misc/openssh-7.7_p1, deprecated OpenSSH-LPK
patch set no longer applies.

We have created a short migration guide in the Wiki [1] for more details.


[1] https://wiki.gentoo.org/wiki/SSH/LDAP_migration
---

sys-auth/ssh-ldap-pubkey isn't yet available in Gentoo repository.
We will publish together with the merge of PR 9400 [1].


See also:
=
[1] https://github.com/gentoo/gentoo/pull/9400


-- 
Regards,
Thomas Deutschmann / Gentoo Linux Developer
C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] [PATCH 0/3] GLEP 63: rationale part

[Thomas Deutschmann]

On 2018-08-04 14:34, Ulrich Mueller wrote:
> So this should either have been submitted as part of that update, or
> you should at least have given notice to the council that further
> changes are pending (as you were present during the meeting). In the
> latter case, we may likely have postponed the decision about the GLEP
> update, which wasn't entirely uncontroversial.

I agree but nevertheless I appreciate that someone (Michał in this case)
doesn't rest and continue to improve things.


Michał Górny wrote:
> +Furthermore, the specification requires separate subkeys for different
> +purposes.  This is a generally agreed on practice (e.g. GnuPG defaults to
> +using a separate encryption key) aiming to further reduce the attack surface.
> +Kristian Fiskerstrand points out e.g. it is technically possible to obtain
> +a valid signature over crafted data while using the subkey for purposes
> +of authorization  [#COUNCIL-MEETING-20180729]_.

I challenge this one:

If an attacker is already able to trick a developer into signing
something the developer didn't want to sign, the same attacker will also
be able to trick the same developer into using the right sub key the
attacker is actually interested in.

My point is: While I don't disagree that best practice should be an own
sub key for every purpose, arguing that this has an impact on security
is wrong. And that was and still is my reason why I don't want that this
is getting enforced.


Michał Górny wrote:
> +This policy serves two purposes.  Firstly, it provides a last fallback option
> +in the event of access to the secret keys being lost and there being
> +no possibility of revoking them.  In this case, the keys eventually expire
> +and users can clearly see that they are no longer being used.  Secondly, it
> +ensures that the developers periodically confirm their access to the primary
> +key.

And I am also challenging this one:

Given that this a policy for Gentoo, we have to take Gentoo specifics
into account:

In Gentoo the primary purpose of OpenGPG is to sign commits and push
operations. A git hook ensures that each commit and push is well signed
by a known key. However, this key is coming from Gentoo's LDAP. LDAP is
accessed via SSH key. So anyone with access to a developer's SSH key is
able to add an additional (malicious) key which would be picked up by
other automated processes with the result that whoever is in control of
that additional key could now use it to commit and push to any Gentoo
repositories.

In this process, an expiration date isn't really used. Again, it is best
practice but when we don't use it, why do we care and enforce such a value?

Well, if you take the *now* proposed "Foreword" into account I *could*
arrange with such a statement because expiration date plays a role in
the web of trust and GLEP 63 seems to be more than just a OpenGPG policy
for commit/push.


-- 
Regards,
Thomas Deutschmann / Gentoo Linux Developer
C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5



signature.asc
Description: OpenPGP digital signature

Re: mcrypt status (Re: [gentoo-dev] Idea for a new project: gentoo-libs)

[Thomas Deutschmann]

On 2018-08-04 16:29, Hanno Böck wrote:
>> Do you have any evidence that mcrypt should not be used?
> Well, PHP was as far as I'm aware its main user and PHP has declared
> mcrypt support to be deprecated a while ago.

In all fairness:

Yes, PHP project has removed ext/mcrypt from core, but they only
moved it into an own PECL extension. My point here is, that they
did not drop and prune mcrypt from universe due to security
vulnerabilities.

Anyone interested in this should read the following posting [1].

tl;dr
Like most crypto libs, mcrypt isn't easy to use and you will
likely do something wrong. In favor of a better solutions which
should prevent such a misuse, mcrypt was deprecated.


See also:
=
[1] 
https://why-cant-we-have-nice-things.mwl.be/requests/deprecate-then-remove-mcrypt.


-- 
Regards,
Thomas Deutschmann / Gentoo Linux Developer
C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5



signature.asc
Description: OpenPGP digital signature

[gentoo-dev] Last rites: sys-apps/microcode-ctl

[Thomas Deutschmann]

# Thomas Deutschmann  (05 Aug 2018)
# Deprecated. Using recent microcodes with this package either won't work
# or crash your system. Please change your setup and make use of kernel's
# early microcode loading feature, see https://wiki.gentoo.org/wiki/Microcode
# for more details. Removal in 30 days.
sys-apps/microcode-ctl


-- 
Regards,
Thomas Deutschmann / Gentoo Linux Developer
C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5



signature.asc
Description: OpenPGP digital signature

[gentoo-dev] Re: commit 50078fbbb39667734 for linux-info.eclass

[Thomas Deutschmann]

Hi,

just an acknowledge for the moment that kernel project has seen the
request and is currently looking into this.

Thanks.


-- 
Regards,
Thomas Deutschmann / Gentoo Linux Developer
C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5



signature.asc
Description: OpenPGP digital signature

[gentoo-dev] Re: News item review v2: Migration required for OpenSSH with LDAP

[Thomas Deutschmann]

Changes:
 * Incorporated suggestions by Peter Stuge
 * Package sys-auth/sakcl added

---
Title: Migration required for OpenSSH with LDAP
Author: Thomas Deutschmann 
Posted: 2018-08-xx
Revision: 1
News-Item-Format: 2.0
Display-If-Installed: net-misc/openssh

If your sshd authenticates against LDAP, you have to migrate your
current setup to a new one using sshd's "AuthorizedKeysCommand" option and
a wrapper provided by packages like the new sys-auth/ssh-ldap-pubkey or
sys-auth/sakcl because beginning with net-misc/openssh-7.7_p1, deprecated
OpenSSH-LPK patch set is deprecated and no longer applies.

We have created a short migration guide in the Wiki [1] for more details.


[1] https://wiki.gentoo.org/wiki/SSH/LDAP_migration
---


-- 
Regards,
Thomas Deutschmann / Gentoo Linux Developer
C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5



signature.asc
Description: OpenPGP digital signature

[gentoo-dev] Re: News item review v3: Migration required for OpenSSH with LDAP

[Thomas Deutschmann]

Changes:
 * Incorporated suggestions by Peter Stuge
 * Package sys-auth/sakcl added
 * Last sentence corrected

---
Title: Migration required for OpenSSH with LDAP
Author: Thomas Deutschmann 
Posted: 2018-08-xx
Revision: 1
News-Item-Format: 2.0
Display-If-Installed: net-misc/openssh

If your sshd authenticates against LDAP, you have to migrate your
current setup to a new one using sshd's "AuthorizedKeysCommand" option and
a wrapper provided by packages like the new sys-auth/ssh-ldap-pubkey or
sys-auth/sakcl because beginning with net-misc/openssh-7.7_p1, OpenSSH-LPK
patch set is deprecated and no longer applies.

We have created a short migration guide in the Wiki [1] for more details.


[1] https://wiki.gentoo.org/wiki/SSH/LDAP_migration
---


-- 
Regards,
Thomas Deutschmann / Gentoo Linux Developer
C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5




signature.asc
Description: OpenPGP digital signature

[gentoo-dev] Re: News item review v3: Migration required for OpenSSH with LDAP

[Thomas Deutschmann]

On 2018-08-07 01:44, Thomas Deutschmann wrote:
> Title: Migration required for OpenSSH with LDAP
> Author: Thomas Deutschmann 
> Posted: 2018-08-xx
> Revision: 1
> News-Item-Format: 2.0
> Display-If-Installed: net-misc/openssh
> 
> If your sshd authenticates against LDAP, you have to migrate your
> current setup to a new one using sshd's "AuthorizedKeysCommand" option and
> a wrapper provided by packages like the new sys-auth/ssh-ldap-pubkey or
> sys-auth/sakcl because beginning with net-misc/openssh-7.7_p1, OpenSSH-LPK
> patch set is deprecated and no longer applies.
> 
> We have created a short migration guide in the Wiki [1] for more details.
> 
> 
> [1] https://wiki.gentoo.org/wiki/SSH/LDAP_migration

Committed.


-- 
Regards,
Thomas Deutschmann / Gentoo Linux Developer
C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] [PATCH] use.desc: Improve description of USE=test

[Thomas Deutschmann]

On 2018-08-21 22:06, Juippisi . wrote:
> It's really annoying if you try to make some conditional stuff apply
> using "if use test;" because it doesn't work with FEATURES="test".

Yes, but these are bugs which are getting fixed. See bugs like
https://bugs.gentoo.org/show_bug.cgi?id=664104.


-- 
Regards,
Thomas Deutschmann / Gentoo Linux Developer
C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] [PATCH] use.desc: Improve description of USE=test

[Thomas Deutschmann]

On 2018-08-21 18:23, Michał Górny wrote:
>> Wait, are you saying that I can set USE=-test while FEATURES=test is
>> enabled? Is that a valid combination?
>
> Yes.

The only thing I still don't understand yet: Do we support things like that?

I.e. should we add things like

> if has test ${FEATURES} && ! use test ; then
> eerror "FEATURES=test requires USE=test."
> die "FEATURES=test set but not USE=test"
> fi

if a package's src_test phase requires some conditional stuff or is it
something like "user shoot himself into the foot" so we do *not* care
because we still assume "if FEATURES=test, USE=test is *normally* set"?

Asking from user experience point of view: Imagine a user tries to
emerge a package which will compile multiple hours and src_test just
fails because some conditional stuff didn't run due to USE=-test
accidentally set by the user (in the past or was forgotten).

The code above in an early phase like pkg_setup would prevent such a bad
user experience, not?


-- 
Regards,
Thomas Deutschmann / Gentoo Linux Developer
C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Gentoo i486 support

[Thomas Deutschmann]

On 2018-08-22 16:30, Mike Gilbert wrote:
> So +1 from me on removing -march=i686 from the x86 arch profile.

+1


-- 
Regards,
Thomas Deutschmann / Gentoo Linux Developer
C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5



signature.asc
Description: OpenPGP digital signature

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

[Thomas Deutschmann]

Hi,

I disagree. Either discuss to drop the entire policy about "-Werror" or
don't but please do _not_ enter the game of differentiating between
"normal" and something you call "security-orientated" packages.

You will lose this game in the end.

If there's really a reason to allow "-Werror" it applies to *any*
package or there isn't a good reason. _Any_ package can be part of a
chained attack. Saying "Uh, this is a security-orientated package, we
must keep '-Werror' for..." -- for WHAT?! You are probably creating a
false sense of security...

Let me remind you of something like
https://daniel.haxx.se/blog/2016/10/14/a-single-byte-write-opened-a-root-execution-exploit/

No, "-Werror" wouldn't have prevent this, that's not my point. My point
is, that there's nothing like "security-orientated" packages. And in the
end you deal with chained attacks involving vectors you haven't thought
of before involving otherwise harmless packages.


Regarding a general drop of that policy: No, I wouldn't change that
policy at all. Gentoo is a rolling distribution and "-Werror" creates
undesired problems in most cases. Given that we have another rule that
any package must respect user's CFLAGS any user or dev who care can add
"-Werror" back to his/her CFLAGS... but don't force every user of Gentoo
to deal with that.


-- 
Regards,
Thomas Deutschmann / Gentoo Linux Developer
C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5



signature.asc
Description: OpenPGP digital signature

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

[Thomas Deutschmann]

On 2018-09-10 23:04, Kristian Fiskerstrand wrote:
> That it wasn't caught before being stabilized on several arches was
> indeed bad, but that likely says more about our stabilization procedures
> than the quality of the underlying package's upstream choices.

Eh, this depends on architecture. Not a general failure. See x86
build.log, https://paste.pound-python.org/show/F1361Zp3aCHJLje8sBRe/


-- 
Regards,
Thomas Deutschmann / Gentoo Linux Developer
C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5



signature.asc
Description: OpenPGP digital signature

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

[Thomas Deutschmann]

On 2018-09-12 16:50, Rich Freeman wrote:
> There is also the case where we want these warnings to block
> installation, because the risk of there being a problem is too great.

I really disagree with that. So many devs have already said multiple
times in this thread that "-Werror" is only turning existing warnings
into fatal errors but "-Werror" itself doesn't add any new checks and
more often requires "-O3" to be useful.

So let's turn this around: Please show us a *real* case within Gentoo
where "-Werror" prevented a real problem which wouldn't otherwise being
noticed. E.g. show us a package which was merged on user's system,
replacing a working previous version of that package causing *real*
problems which could have been prevented if package would have set
"-Werror".

Unless you can do that we don't really need to discuss this. Simply
because everyone interested in "-Werror" *can* set that flag via CFLAGS,
even just per package, whereas the majority, not interested in this,
cannot do the same to filter "-Werror". Nobody advocating for "-Werror"
replied to that fact yet.


-- 
Regards,
Thomas Deutschmann / Gentoo Linux Developer
C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] New copyright policy approved, please weigh your Signed-off-bys

[Thomas Deutschmann]

On 2018-09-16 10:59, Ulrich Mueller wrote:
>>> On Sun, 16 Sep 2018, Michał Górny wrote:
>> Since some developers were giving the sign-off 'in blanco' so far,
>> I would like to emphasize that now it will actually mean agreeing to
>> the document.  Unless you have read the new policy and agreed with it,
>> please don't do that.
> 
> I wonder how we should treat those existing Signed-off-by lines in the
> tree.
> 
> We could either say that we ignore any such lines on commits before
> 2018-09-16 00:00:00 UTC, because there was no policy in place.
> 
> Or we could say that they certify the commit under the Linux DCO 1.1
> (https://developercertificate.org/), because in absence of an explicit
> policy that's the only meaningful interpretation of a Signed-off-by
> line.
> 
> Presumably, the first alternative is cleaner. Especially, since there
> are commits with a Signed-off-by line that don't comply with the
> conditions of the Linux DCO.

+1 for ignoring "Signed-Off-By" line until 2018-09-16 00:00:00.


-- 
Regards,
Thomas Deutschmann / Gentoo Linux Developer
C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Last rites: sys-process/vixie-cron

[Thomas Deutschmann]

On 2018-09-20 11:17, Mikle Kolyada wrote:
> # Mikle Kolyada  (20 Sep 2018)
> # Dead upstream and unmaintained for a long time,
> # has multiple bugs open, use sys-process/cronie
> # instead (the fork). Removal in 30 days.
> sys-process/vixie-cron

I reverted that mask for now, see
https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=0fd44962557b7870ac34c9b64f9bcfefc508f1e0
for details.


-- 
Regards,
Thomas Deutschmann / Gentoo Linux Developer
C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Signed-off-by verification incoming

[Thomas Deutschmann]

On 2018-09-29 15:14, Jeroen Roovers wrote:
> Please:
> 
> 0a) Explain to me how to fix my commits that I now can't push, or

Like you have already figured out, "git commit --signoff" when doing
profile/eclass changes and to fix things, "git commit --amend --signoff".


> 1) Update repoman to enforce it _before_ the commit is executed.

Please add

> DCO_SIGNED_OFF_BY="Larry the Cow "

to your make.conf and "repoman commit" will do it for your.


> 2) Wait for the repoman update to trickle down to all developers.

DCO_SIGNED_OFF_BY is present since 2013-04-22 20:01:29 -0700. So it
should be available for all developers.


> 3) Announce it ahead of time.

I agree. Communication was bad. We should have included dev howto with
that announcement.


-- 
Regards,
Thomas Deutschmann / Gentoo Linux Developer
C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5



signature.asc
Description: OpenPGP digital signature

[gentoo-dev] net-dns/dnssec-root: Blind stable on arm, critical bug 667774

[Thomas Deutschmann]

Let me quote 
https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=f6f6bb91b7f134a121ef9fa1dd504b9ca52c5aa8:

> net-dns/dnssec-root: Blind stable on arm, critical bug 667774
> 
> Note that this is a major fail for a stable architecture.
> In addition, all arm devboxes are currently offline.
> 
> Bug: https://bugs.gentoo.org/667774
> Signed-off-by: Andreas K. Hüttel 
> Package-Manager: Portage-2.3.49, Repoman-2.3.11

...and now let's all sit down and enjoy how stable ARM users lose access
to the Internet and have to figure out how to deactivate DNSSEC to get
back online. ;]

Maybe it is time to destabilize ARM on Gentoo to stop the impression
that we really support ARM.


-- 
Regards,
Thomas Deutschmann / Gentoo Linux Developer
C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] net-dns/dnssec-root: Blind stable on arm, critical bug 667774

[Thomas Deutschmann]

On 2018-10-11 17:45, Corentin “Nado” Pazdera wrote:
> What's a "blind stable"? I'm guessing stabilizing without testing? If
> yes, why?

Yes, stabilized without testing.

Reason: No ARM arch team member with access to an ARM box was available
for the last ~7 days.

However, this update is critical for anyone using something like
net-dns/unbound with DNSSEC validation enabled (which isn't enabled by
default but you are encourage to switch this on).


-- 
Regards,
Thomas Deutschmann / Gentoo Linux Developer
C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] net-dns/dnssec-root: Blind stable on arm, critical bug 667774

[Thomas Deutschmann]

On 2018-10-11 17:48, Alec Warner wrote:
> This thread is missing a bunch of context...so I'll try to add it I guess.

All you need to know in this commit message, included linked bug report
for more details. :)


> I can't tell if the complaint is that:
> 
> 1) Someone blind-stabled something on arm and it broke (doesn't build?)
> 2) The arm team failed to mark a package stable before a hard deadline
> (DNSSEC key rotation)
> 
> I presume its the latter? Whats the impact? All DNS, or only DNSSEC
> validated entries?

It's the latter. It will affect anyone running an own DNS resolver like
net-dns/unbound on ARM with DNSSEC enabled (not default) using keys
provided by net-dns/dnssec-root package.

Of course anyone familiar with DNSSEC or unbound maybe knows how to
workaround:

  - Enable auto-anchor update; However it is too late to do that know,
it will take ~30 days until the new learned key will become trusted.
Same applies to any *new* setup within last 30 days.

  - Use unbound-anchor tool to force a manual immediate update.

  - Disable DNSSEC validation.

But that's not the point here. The point was to get some attention that
again we have a lacking architecture (net-dns/dnssec-root is not the
only package where ARM arch team is lacking behind) which affects anyone
"trusting" somehow in STABLE keywords.

If everyone is using ~ARCH and don't care about STABLE keywords, well,
we could save a bunch of time, energy...


-- 
Regards,
Thomas Deutschmann / Gentoo Linux Developer
C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] net-dns/dnssec-root: Blind stable on arm, critical bug 667774

[Thomas Deutschmann]

On 2018-10-12 01:38, Sergei Trofimovich wrote:
>> Maybe it is time to destabilize ARM on Gentoo to stop the impression
>> that we really support ARM.
> 
> [ CC: arm@ ]
> 
> A few points to think about:
> 
> 1. I have read this as a direct statement that ARM is not maintained.
>I don't think it is a fair (or constructive) assessment of team's work
>on ARM front.

See the ARM bug queue for stable requests. ARM is always last and behind
since we dropped HPPA.


> 2. The bug was created less than a week ago and was not communicated
>explicitly as urgent on #gentoo-arm. I see failure to handle the bug
>as a communication failure and not a team's death signal.
> 
>Were there any attempts to reach out to the teams or just arm users?

Bug was assigned highest priority in bugzilla. But it looks like ARM arch
team is ignoring set priority.

*I* didn't asked in #gentoo-arm but I pinged project several times in
#gentoo-dev channel.


> 3. I do not believe arm boxes (or most of users' boxes) update @world weekly
>and restart unbound automatically. Deadline of a few days is not feasible
>to propagate to users quickly. There is frequently no order-of-days 
> response
>from arch teams. It would be nice to have but it's not realistic (IMO).
> 
> [...]
> 
> 6. If this package is so important it needs to be stable months before keys 
> expire.
>Then users would have a chance to get the update during casual update. Or
>net-dns/unbound DNSSEC functionality should not be marked stable anywhere
>if package requires periodic manual intervention to just keep working.

Disclaimer: I am not the maintainer of unbound nor dnssec-root package. I took
action last week after I noticed that there was a time bomb ticking and
nobody cared. I fully agree that an updated dnssec-root package could have been
made available one year ago giving everyone enough time...


> 4. net-dns/dnssec-root is used by a single(ish) package in tree: 
> net-dns/unbound
> 
>Which is: not a system package, not a default package, not suggested by 
> handbook
>package, can operate without DNSSEC enabled.

Unbound is a popular resolver and many Gentoo users are operating ARM-based
routers. I don't get your point. Of course you could disable DNSSEC and DNS
will resume working. But is this really your point?


>While annoying it's not going to lock users out or corrupt their data.

Right, it doesn't cause data corruption. But when your Gentoo-based router
will stop working this can be a problem. Don't forget about remote systems.
Again, people who know how to deal with problems like that aren't the
problem. But why do we care about stable packages if we assume that everyone
knows what to do when experiencing problems?


> 5. net-dns/dnssec-root is a plain-text file package. It should have been 
> ALLARCHES
>stablewithout involvement of arm@.

It wasn't about dnssec-root package. Of course this could have been stabilized
under ALLARCHES policy. It wasn't because package has a new dependency
(>=dev-perl/XML-XPath-1.420.0 + deps) which was lacking stable keywords, too.



If ARM can keep up I am quiet. But please, be honest. We don't need another
HPPA. Nobody will win something if we tell world "ARM is a first class citizen
in Gentoo" when it isn't (anymore). But if people would know it is ~ARCH, we
would not disappoint expectations.


-- 
Regards,
Thomas Deutschmann / Gentoo Linux Developer
C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Is there any way I can help with pull requests?

[Thomas Deutschmann]

Hi,

in the end, only Gentoo developer can help because they have to do the
final review and are the only one who can merge.

But you can become a Gentoo developer!

Please read https://www.gentoo.org/get-involved/become-developer/

As Gentoo developer you could join Gentoo's Proxy Maintainers project
and deal with all those pull requests.

Looking forward to see your Gentoo developer bug in near future! :-)


-- 
Regards,
Thomas Deutschmann / Gentoo Linux Developer
C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] adding app-crypt/gentoo-keys to @system

[Thomas Deutschmann]

Hi,

On 2019-02-25 17:09, Matthew Thode wrote:
> How about we allow a setting for controling which keyserver to refresh
> from.  SKS has had problems, fedora has been better (and a coworker says
> MIT is ok too).  Aparently they have a max key size set or something to
> work around keyserver 'brokenness'.
> 
> Something similiar to this would be nice, but for keyservers.
> 
> https://gist.github.com/robbat2/551fc8ea56408ee48e99909f9c26c13e

I am still not sure which problem you are trying to solve:

If you provide a way to disable key updates, you can also disable
verification in general: Our threat model allows for compromised keys
(just because you can't prevent that), so it is _essential_ that you
verify that the key is still valid as part of _each_ validation.

Fedora's keyserver are part of the normal SKS network.

Yes, gnupg doesn't handle keyserver failures very well. I.e. no real
timeout and switch to another server. But we enabled WKD a long time ago
which fixed most problems for me because this will avoid normal
keyservers in general. So I am wondering which problems do you have...


-- 
Regards,
Thomas Deutschmann / Gentoo Linux Developer
C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5



signature.asc
Description: OpenPGP digital signature

[gentoo-dev] Re: dev-libs/libaio: package up for grabs

[Thomas Deutschmann]

On 2019-04-25 00:45, Gokturk Yuksek wrote:
> The following package is up for grabs:
> 
>   dev-libs/libaio

I'll take it.


-- 
Regards,
Thomas Deutschmann / Gentoo Linux Developer
C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] [RFC] New QA policy: Packages must not disable installing manpages via USE flags

[Thomas Deutschmann]

On 2019-07-17 16:56, Mike Gilbert wrote:
> I'm against this.
> 
> I seriously doubt maintainers will take the time/effort to pre-build
> and distribute manpages. The end result of this will be additional
> hard dependencies on heavyweight packages.

I second that.

Keep in mind that aside new time requirement for pre-building and
distributing per bump, you often cannot use build system anymore for
installation. For example, please see net-misc/iputils package:
Because it's a base system package, we need to avoid insane doc
dependencies (and this is only xsltproc -- not even the craziest doc
dep hell). Therefore we already ship pre-generated man pages.

But because package provides various USE flags it's becoming a pain to
manually install required docs, see [1]. I don't believe that we want
constructs like that for many packages...


See also:
=
[1] 
https://gitweb.gentoo.org/repo/gentoo.git/tree/net-misc/iputils/iputils-.ebuild?id=ec886beb76dc342eec146f7e4d3785437c12bfa9#n159


-- 
Regards,
Thomas Deutschmann / Gentoo Linux Developer
C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5



signature.asc
Description: OpenPGP digital signature

[gentoo-dev] [PATCH 1/3] savedconfig.eclass: Make save_config() re-use configuration file scheme used by restore_config()

[Thomas Deutschmann]

From: Arfrever Frehtes Taifersar Arahesis 

Fixes: https://bugs.gentoo.org/686348
Signed-off-by: Arfrever Frehtes Taifersar Arahesis 
Signed-off-by: Thomas Deutschmann 
---
 eclass/savedconfig.eclass | 40 ++-
 1 file changed, 27 insertions(+), 13 deletions(-)

diff --git a/eclass/savedconfig.eclass b/eclass/savedconfig.eclass
index e0b1953d56d0..b96f55d4c27c 100644
--- a/eclass/savedconfig.eclass
+++ b/eclass/savedconfig.eclass
@@ -38,6 +38,13 @@ case ${EAPI} in
*) die "EAPI=${EAPI:-0} is not supported" ;;
 esac
 
+# @ECLASS-VARIABLE: _SAVEDCONFIG_CONFIGURATION_FILE
+# @DEFAULT_UNSET
+# @INTERNAL
+# @DESCRIPTION:
+# Path of configuration file, relative to /etc/portage/savedconfig,
+# restored by restore_config() and saved by save_config().
+
 # @FUNCTION: save_config
 # @USAGE: 
 # @DESCRIPTION:
@@ -51,20 +58,26 @@ save_config() {
fi
[[ $# -eq 0 ]] && die "Usage: save_config "
 
-   local dest="/etc/portage/savedconfig/${CATEGORY}"
+   local configfile
+   if [[ -n ${_SAVEDCONFIG_CONFIGURATION_FILE} ]] ; then
+   
configfile="/etc/portage/savedconfig/${_SAVEDCONFIG_CONFIGURATION_FILE}"
+   else
+   configfile="/etc/portage/savedconfig/${CATEGORY}/${PF}"
+   fi
+
if [[ $# -eq 1 && -f $1 ]] ; then
-   # Just one file, so have the ${PF} be that config file
-   dodir "${dest}"
-   cp "$@" "${ED%/}/${dest}/${PF}" || die "failed to save $*"
+   # Just one file, so have the ${configfile} be that config file
+   dodir "${configfile%/*}"
+   cp "$@" "${ED%/}/${configfile}" || die "failed to save $*"
else
-   # A dir, or multiple files, so have the ${PF} be a dir
+   # A dir, or multiple files, so have the ${configfile} be a dir
# with all the saved stuff below it
-   dodir "${dest}/${PF}"
-   treecopy "$@" "${ED%/}/${dest}/${PF}" || die "failed to save $*"
+   dodir "${configfile}"
+   treecopy "$@" "${ED%/}/${configfile}" || die "failed to save $*"
fi
 
elog "Your configuration for ${CATEGORY}/${PF} has been saved in "
-   elog "/etc/portage/savedconfig/${CATEGORY}/${PF} for your editing 
pleasure."
+   elog "\"${configfile}\" for your editing pleasure."
elog "You can edit these files by hand and remerge this package with"
elog "USE=savedconfig to customise the configuration."
elog "You can rename this file/directory to one of the following for"
@@ -76,7 +89,7 @@ save_config() {
 # @FUNCTION: restore_config
 # @USAGE: 
 # @DESCRIPTION:
-# Restores the configuation saved ebuild previously potentially with user 
edits.
+# Restores the configuration saved ebuild previously potentially with user 
edits.
 # You can restore a single file or a whole bunch, just make sure you call
 # restore_config with all of the files to restore at the same time.
 #
@@ -107,10 +120,11 @@ restore_config() {
[[ -r ${configfile} ]] || configfile=${base}/${CHOST}/${check}
[[ -r ${configfile} ]] || configfile=${base}/${check}
einfo "Checking existence of ${configfile} ..."
-   if [[ -r "${configfile}" ]]; then
-   einfo "found ${configfile}"
-   found=${configfile};
-   break;
+   if [[ -r "${configfile}" ]] ; then
+   einfo "Found \"${configfile}\""
+   found=${configfile}
+   _SAVEDCONFIG_CONFIGURATION_FILE=${configfile#${base}/}
+   break
fi
done
if [[ -f ${found} ]]; then
-- 
2.22.0

[gentoo-dev] [PATCH 2/3] savedconfig.eclass: Always quote filename in output

[Thomas Deutschmann]

Signed-off-by: Thomas Deutschmann 
---
 eclass/savedconfig.eclass | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/eclass/savedconfig.eclass b/eclass/savedconfig.eclass
index b96f55d4c27c..5c6fd228269c 100644
--- a/eclass/savedconfig.eclass
+++ b/eclass/savedconfig.eclass
@@ -128,14 +128,14 @@ restore_config() {
fi
done
if [[ -f ${found} ]]; then
-   elog "Building using saved configfile ${found}"
+   elog "Building using saved configfile \"${found}\""
if [ $# -gt 0 ]; then
cp -pPR "${found}" "$1" || die "Failed to restore 
${found} to $1"
else
die "need to know the restoration filename"
fi
elif [[ -d ${found} ]]; then
-   elog "Building using saved config directory ${found}"
+   elog "Building using saved config directory \"${found}\""
local dest=${PWD}
pushd "${found}" > /dev/null
treecopy . "${dest}" || die "Failed to restore ${found} to $1"
@@ -147,7 +147,7 @@ restore_config() {
die "Reading config files failed"
fi
ewarn "No saved config to restore - please remove 
USE=savedconfig or"
-   ewarn "provide a configuration file in 
${PORTAGE_CONFIGROOT}/etc/portage/savedconfig/${CATEGORY}/${PN}"
+   ewarn "provide a configuration file in 
${PORTAGE_CONFIGROOT%/}/etc/portage/savedconfig/${CATEGORY}/${PN}"
ewarn "Your config file(s) will not be used this time"
fi
 }
-- 
2.22.0

[gentoo-dev] [PATCH 3/3] savedconfig.eclass: Only check config file candidate once

[Thomas Deutschmann]

Due to the injection of $CTARGET and $CHOST in file path
we could end up with an already checked config file candidate
if $CTARGET or $CHOST isn't used.

This commit will make sure that we don't check the same file twice.

Signed-off-by: Thomas Deutschmann 
---
 eclass/savedconfig.eclass | 12 
 1 file changed, 8 insertions(+), 4 deletions(-)

diff --git a/eclass/savedconfig.eclass b/eclass/savedconfig.eclass
index 5c6fd228269c..11e82f21fa4a 100644
--- a/eclass/savedconfig.eclass
+++ b/eclass/savedconfig.eclass
@@ -113,20 +113,24 @@ restore_config() {
 
use savedconfig || return
 
-   local found check configfile
+   local found check checked configfile
local base=${PORTAGE_CONFIGROOT%/}/etc/portage/savedconfig
for check in {${CATEGORY}/${PF},${CATEGORY}/${P},${CATEGORY}/${PN}}; do
-   configfile=${base}/${CTARGET}/${check}
-   [[ -r ${configfile} ]] || configfile=${base}/${CHOST}/${check}
+   configfile=${base}/${CTARGET:+"${CTARGET}/"}${check}
+   [[ -r ${configfile} ]] || 
configfile=${base}/${CHOST:+"${CHOST}/"}${check}
[[ -r ${configfile} ]] || configfile=${base}/${check}
-   einfo "Checking existence of ${configfile} ..."
+   [[ "${checked}" == *"${configfile} "* ]] && continue
+   einfo "Checking existence of \"${configfile}\" ..."
if [[ -r "${configfile}" ]] ; then
einfo "Found \"${configfile}\""
found=${configfile}
_SAVEDCONFIG_CONFIGURATION_FILE=${configfile#${base}/}
break
fi
+
+   checked+="${configfile} "
done
+
if [[ -f ${found} ]]; then
elog "Building using saved configfile \"${found}\""
if [ $# -gt 0 ]; then
-- 
2.22.0

[gentoo-dev] Re: [PATCH 1/3] savedconfig.eclass: Make save_config() re-use configuration file scheme used by restore_config()

[Thomas Deutschmann]

On 2019-08-03 15:31, Mike Gilbert wrote:
> The summary line on this patch is too long. GLEP 66 states it must be
> no longer than 69 characters.

v2 will have summary line <=69 characters, thanks.


-- 
Regards,
Thomas Deutschmann / Gentoo Linux Developer
C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] [PATCH 1/3] savedconfig.eclass: Make save_config() re-use configuration file scheme used by restore_config()

[Thomas Deutschmann]

On 2019-08-03 18:20, Ulrich Mueller wrote:
>>>>>> On Sat, 03 Aug 2019, Thomas Deutschmann wrote:
> 
>> +# @ECLASS-VARIABLE: _SAVEDCONFIG_CONFIGURATION_FILE
> 
> 31 chars? Seems excessive for a name of a private variable.

And? I'll keep that name for readability instead of finding an
abbreviation.


>> +# Restores the configuration saved ebuild previously potentially with user 
>> edits.
> 
> If have trouble understanding this sentence.

v2 will contain a better sentence.


>> +if [[ -r "${configfile}" ]] ; then
> 
> Quotes are not necessary here.

Not necessary but it won't hurt. I'd like to keep them for style. I.e. I
think it's better to always quote so you won't forget when it will
become critical.


-- 
Regards,
Thomas Deutschmann / Gentoo Linux Developer
C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5



signature.asc
Description: OpenPGP digital signature

[gentoo-dev] [PATCH v2 1/3] savedconfig.eclass: Re-use configuration file scheme

[Thomas Deutschmann]

From: Arfrever Frehtes Taifersar Arahesis 

Make save_config() re-use configuration file scheme used
by restore_config().

Fixes: https://bugs.gentoo.org/686348
Signed-off-by: Arfrever Frehtes Taifersar Arahesis 
Signed-off-by: Thomas Deutschmann 
---
 eclass/savedconfig.eclass | 40 ++-
 1 file changed, 27 insertions(+), 13 deletions(-)

diff --git a/eclass/savedconfig.eclass b/eclass/savedconfig.eclass
index e0b1953d56d0..f62a6055ffdb 100644
--- a/eclass/savedconfig.eclass
+++ b/eclass/savedconfig.eclass
@@ -38,6 +38,13 @@ case ${EAPI} in
*) die "EAPI=${EAPI:-0} is not supported" ;;
 esac
 
+# @ECLASS-VARIABLE: _SAVEDCONFIG_CONFIGURATION_FILE
+# @DEFAULT_UNSET
+# @INTERNAL
+# @DESCRIPTION:
+# Path of configuration file, relative to /etc/portage/savedconfig,
+# restored by restore_config() and saved by save_config().
+
 # @FUNCTION: save_config
 # @USAGE: 
 # @DESCRIPTION:
@@ -51,20 +58,26 @@ save_config() {
fi
[[ $# -eq 0 ]] && die "Usage: save_config "
 
-   local dest="/etc/portage/savedconfig/${CATEGORY}"
+   local configfile
+   if [[ -n ${_SAVEDCONFIG_CONFIGURATION_FILE} ]] ; then
+   
configfile="/etc/portage/savedconfig/${_SAVEDCONFIG_CONFIGURATION_FILE}"
+   else
+   configfile="/etc/portage/savedconfig/${CATEGORY}/${PF}"
+   fi
+
if [[ $# -eq 1 && -f $1 ]] ; then
-   # Just one file, so have the ${PF} be that config file
-   dodir "${dest}"
-   cp "$@" "${ED%/}/${dest}/${PF}" || die "failed to save $*"
+   # Just one file, so have the ${configfile} be that config file
+   dodir "${configfile%/*}"
+   cp "$@" "${ED%/}/${configfile}" || die "failed to save $*"
else
-   # A dir, or multiple files, so have the ${PF} be a dir
+   # A dir, or multiple files, so have the ${configfile} be a dir
# with all the saved stuff below it
-   dodir "${dest}/${PF}"
-   treecopy "$@" "${ED%/}/${dest}/${PF}" || die "failed to save $*"
+   dodir "${configfile}"
+   treecopy "$@" "${ED%/}/${configfile}" || die "failed to save $*"
fi
 
elog "Your configuration for ${CATEGORY}/${PF} has been saved in "
-   elog "/etc/portage/savedconfig/${CATEGORY}/${PF} for your editing 
pleasure."
+   elog "\"${configfile}\" for your editing pleasure."
elog "You can edit these files by hand and remerge this package with"
elog "USE=savedconfig to customise the configuration."
elog "You can rename this file/directory to one of the following for"
@@ -76,7 +89,7 @@ save_config() {
 # @FUNCTION: restore_config
 # @USAGE: 
 # @DESCRIPTION:
-# Restores the configuation saved ebuild previously potentially with user 
edits.
+# Restores the package's configuration file probably with user edits.
 # You can restore a single file or a whole bunch, just make sure you call
 # restore_config with all of the files to restore at the same time.
 #
@@ -107,10 +120,11 @@ restore_config() {
[[ -r ${configfile} ]] || configfile=${base}/${CHOST}/${check}
[[ -r ${configfile} ]] || configfile=${base}/${check}
einfo "Checking existence of ${configfile} ..."
-   if [[ -r "${configfile}" ]]; then
-   einfo "found ${configfile}"
-   found=${configfile};
-   break;
+   if [[ -r "${configfile}" ]] ; then
+   einfo "Found \"${configfile}\""
+   found=${configfile}
+   _SAVEDCONFIG_CONFIGURATION_FILE=${configfile#${base}/}
+   break
fi
done
if [[ -f ${found} ]]; then
-- 
2.22.0

[gentoo-dev] [PATCH v2 2/3] savedconfig.eclass: Always quote filename in output

[Thomas Deutschmann]

Signed-off-by: Thomas Deutschmann 
---
 eclass/savedconfig.eclass | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/eclass/savedconfig.eclass b/eclass/savedconfig.eclass
index f62a6055ffdb..1ea464271aff 100644
--- a/eclass/savedconfig.eclass
+++ b/eclass/savedconfig.eclass
@@ -128,14 +128,14 @@ restore_config() {
fi
done
if [[ -f ${found} ]]; then
-   elog "Building using saved configfile ${found}"
+   elog "Building using saved configfile \"${found}\""
if [ $# -gt 0 ]; then
cp -pPR "${found}" "$1" || die "Failed to restore 
${found} to $1"
else
die "need to know the restoration filename"
fi
elif [[ -d ${found} ]]; then
-   elog "Building using saved config directory ${found}"
+   elog "Building using saved config directory \"${found}\""
local dest=${PWD}
pushd "${found}" > /dev/null
treecopy . "${dest}" || die "Failed to restore ${found} to $1"
@@ -147,7 +147,7 @@ restore_config() {
die "Reading config files failed"
fi
ewarn "No saved config to restore - please remove 
USE=savedconfig or"
-   ewarn "provide a configuration file in 
${PORTAGE_CONFIGROOT}/etc/portage/savedconfig/${CATEGORY}/${PN}"
+   ewarn "provide a configuration file in 
${PORTAGE_CONFIGROOT%/}/etc/portage/savedconfig/${CATEGORY}/${PN}"
ewarn "Your config file(s) will not be used this time"
fi
 }
-- 
2.22.0

[gentoo-dev] [PATCH v2 3/3] savedconfig.eclass: Only check config file candidate once

[Thomas Deutschmann]

Due to the injection of $CTARGET and $CHOST in file path
we could end up with an already checked config file candidate
if $CTARGET or $CHOST isn't used.

This commit will make sure that we don't check the same file twice.

Signed-off-by: Thomas Deutschmann 
---
 eclass/savedconfig.eclass | 12 
 1 file changed, 8 insertions(+), 4 deletions(-)

diff --git a/eclass/savedconfig.eclass b/eclass/savedconfig.eclass
index 1ea464271aff..b2be715630af 100644
--- a/eclass/savedconfig.eclass
+++ b/eclass/savedconfig.eclass
@@ -113,20 +113,24 @@ restore_config() {
 
use savedconfig || return
 
-   local found check configfile
+   local found check checked configfile
local base=${PORTAGE_CONFIGROOT%/}/etc/portage/savedconfig
for check in {${CATEGORY}/${PF},${CATEGORY}/${P},${CATEGORY}/${PN}}; do
-   configfile=${base}/${CTARGET}/${check}
-   [[ -r ${configfile} ]] || configfile=${base}/${CHOST}/${check}
+   configfile=${base}/${CTARGET:+"${CTARGET}/"}${check}
+   [[ -r ${configfile} ]] || 
configfile=${base}/${CHOST:+"${CHOST}/"}${check}
[[ -r ${configfile} ]] || configfile=${base}/${check}
-   einfo "Checking existence of ${configfile} ..."
+   [[ "${checked}" == *"${configfile} "* ]] && continue
+   einfo "Checking existence of \"${configfile}\" ..."
if [[ -r "${configfile}" ]] ; then
einfo "Found \"${configfile}\""
found=${configfile}
_SAVEDCONFIG_CONFIGURATION_FILE=${configfile#${base}/}
break
fi
+
+   checked+="${configfile} "
done
+
if [[ -f ${found} ]]; then
elog "Building using saved configfile \"${found}\""
if [ $# -gt 0 ]; then
-- 
2.22.0

[gentoo-dev] [PATCH] mount-boot.eclass: Fix ro check

[Thomas Deutschmann]

Make sure we check only /boot mount and not any mount
containing '/boot'.

Closes: https://bugs.gentoo.org/691874
Signed-off-by: Thomas Deutschmann 
---
 eclass/mount-boot.eclass | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/eclass/mount-boot.eclass b/eclass/mount-boot.eclass
index 4d886c8d8475..938df6732f43 100644
--- a/eclass/mount-boot.eclass
+++ b/eclass/mount-boot.eclass
@@ -54,7 +54,7 @@ mount-boot_check_status() {
# note that /dev/BOOT is in the Gentoo default /etc/fstab file
local fstabstate=$(awk '!/^#|^[[:blank:]]+#|^\/dev\/BOOT/ {print $2}' 
/etc/fstab | egrep "^/boot$" )
local procstate=$(awk '$2 ~ /^\/boot$/ {print $2}' /proc/mounts)
-   local proc_ro=$(awk '{ print $2 " ," $4 "," }' /proc/mounts | sed -n 
'/\/boot .*,ro,/p')
+   local proc_ro=$(awk '{ print $2 " ," $4 "," }' /proc/mounts | sed -n 
'/^\/boot .*,ro,/p')
 
if [ -n "${fstabstate}" ] && [ -n "${procstate}" ] ; then
if [ -n "${proc_ro}" ] ; then
-- 
2.22.0

[gentoo-dev] Re: [PATCH] mount-boot.eclass: Fix ro check

[Thomas Deutschmann]

Hi,

now pushed,
https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=7840e73dde3ff715806aff61708f134479581d9c


-- 
Regards,
Thomas Deutschmann / Gentoo Linux Developer
C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] [RFC] package.deprecated to mark packages deprecated and report dependencies

[Thomas Deutschmann]

Hi,

I like the idea. This will allow the following change in workflow:

When you now want to last-rite app-misc/foo for example, you would
schedule a CI run. I.e. create a pull request against Gentoo repository
at GitHub containing your package.mask entry. When the results will be
available, you will start filling bugs against packages depending on the
package you want to get rid off. Once all depending packages are gone,
you will commit the mask. However, this process can take some time and
in theory someone could add a new dependency on your package in the
meanwhile...

Thanks to the new package.deprecated file we would have a check in real
time against current repository. And once all CI warnings are gone you
can commit the mask.


-- 
Regards,
Thomas Deutschmann / Gentoo Linux Developer
C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5



signature.asc
Description: OpenPGP digital signature

[gentoo-dev] [PATCH] autotools.eclass: drop outdated sys-devel/gettext blocker

[Thomas Deutschmann]

All 
Signed-off-by: Thomas Deutschmann 
---
 eclass/autotools.eclass | 5 +
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/eclass/autotools.eclass b/eclass/autotools.eclass
index 9143aa454d0d..9df0e1b93663 100644
--- a/eclass/autotools.eclass
+++ b/eclass/autotools.eclass
@@ -109,10 +109,7 @@ if [[ -n ${WANT_LIBTOOL} ]] ; then
export WANT_LIBTOOL
 fi
 
-# Force people (nicely) to upgrade to a newer version of gettext as
-# older ones are known to be crappy.  #496454
-AUTOTOOLS_DEPEND="!

[gentoo-dev] act-{user,group} & RDEPEND

[Thomas Deutschmann]

Hi,

most packages are putting acct-{user,group}/* dependencies into RDEPEND.

What about packages using tmpfiles eclass and installing tmpfiles which
will make use of acct-{user,group}/* depedencies?

I.e. dev-db/mysql-init-scripts will install
"/usr/lib/tmpfiles.d/mysql.conf" with the following content:

> d /var/run/mysqld 0755 mysql mysql -

The package is a requirement for all
dev-db/{mysql,mariadb,percona-server} packages because it will provide
runscript/services.

To be able to start your chosen database server right after
installation, we trigger tmpfiles service in pkg_postinst via
tmpfiles_process().

Therefore, mysql user and group provided by acct-{user,group}/mysql must
be merged *before* tmpfiles_process() will be called or
"/var/run/mysqld" will be created as root:root which will prevent your
favorite database server to start.

However, devmanual
(https://devmanual.gentoo.org/general-concepts/dependencies/) says:

> Items which are in RDEPEND but not DEPEND could in theory be merged
> after the target package. Portage does not currently do this.
So don't we have a conceptual problem here and are just lucky that
current used PMs don't do at the moment what specification will allow
them to do?

Moving to (B)DEPEND will address the problem for non-binary package
users only.


-- 
Regards,
Thomas Deutschmann / Gentoo Linux Developer
C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[Thomas Deutschmann]

Hi,

On 2019-09-04 20:59, Michał Górny wrote:
> Devmanual is pretty clear on the fact that *all* new eclasses require ml
>   ^^^
> review *before* committing:

I am also working on a new eclass so I looked up details regarding
what's needed to add a new eclass recently.

I must say that I disagree that it's *pretty* clear.

> Adding and Updating Eclasses
>
> Before committing a new eclass to the tree, it should be emailed
>^^
> to the gentoo-dev mailing list with a justification and a
> proposed implementation. Do not skip this step — sometimes a
> better implementation or an alternative which does not require a
> new eclass will be suggested.
>
> Before updating [...]
>
> The exceptions to this rule are per-package eclasses. For
> 
> example, the apache-2 eclass is only used by the www-servers/apache
> package, and thus does not typically require changes to be emailed
> for review.

In my case I am working on a new mysql eclass to outsource pkg_config
function which is shared at least between dev-db/mysql and
dev-db/percona-server (and maybe dev-db/mariadb).

For this new eclass I would say it's a "per-package" eclass and would
probably have skipped mailing list review, too.

If you want to make it clear, change "should" to "must" and maybe
clarify per-package exception and limit to update case if you believe
that really *all* *new* eclasses must be send to mailing list.


-- 
Regards,
Thomas Deutschmann / Gentoo Linux Developer
C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[Thomas Deutschmann]

On 2019-09-05 06:02, Michał Górny wrote:
>> In my case I am working on a new mysql eclass to outsource pkg_config
>> function which is shared at least between dev-db/mysql and
>> dev-db/percona-server (and maybe dev-db/mariadb).
>>
>> For this new eclass I would say it's a "per-package" eclass and would
>> probably have skipped mailing list review, too.
> 
> Everyone can skip as many paragraphs as they want, and then apply what's
> said later to something said way earlier.

Could you please stop adding any bad interpretation?

That was a serious question. For you, it's pretty clear. I am showing
you, that for me, it isn't pretty clear. When you believe I skipped
important lines in my quote please outline what I have missed and I will
take the blame.


>> If you want to make it clear, change "should" to "must" and maybe
>> clarify per-package exception and limit to update case if you believe
>> that really *all* *new* eclasses must be send to mailing list.
> 
> Submit a part.  This is a community effort.  Nitpicking and complaining
> doesn't make things better.  Fixing them does.

Sure, but at the moment *you* are the one who are saying it's a MUST. I
don't understand it that way and I am fine with my understanding that
per-package eclasses *should* but *must not* get reviewed through
mailing list. In other words I am asking you to show us where it's
written that *all* *new* eclasses *must* get reviewed through mailing
list. I cannot find something like that in current devmanual (the link
you showed).

Maybe I am still missing something after reading
https://devmanual.gentoo.org/eclass-writing/ 3 times...

In case I am not missing anything I suggested to improve devmanual in
case you believe this should be a hard requirement. Because at the
moment I don't believe it should be a hard requirement, *I* will not
propose any changes.


-- 
Regards,
Thomas Deutschmann / Gentoo Linux Developer
C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: eclass/

[Thomas Deutschmann]

On 2019-09-05 22:16, Michał Górny wrote:
>> But as per the way the dev manual is written, he arguably *is*
>> following policy.
>>
>> Stop taking the line of assuming he's trying to be belligerent. 
>
> He says explicitly that he is against fixing devmanual because he likes
> the way he can abuse it right now.

You are the only one adding _abuse_ here. Stop that, thanks. When I
replied to your mail I was just asking... nothing more. I don't
understand why you are reading so much into it.

But yes, I like the current exception for "per-package" eclasses like I
am concerned that a review requirement would cause a significant delay:

Back to my example, imagine we would move pkg_config to new mysql
eclass. If we would bump mysql/percona-server/mariadb package and will
receive bug reports later because upstream changed something causing
pkg_config to fail we would now have to propose a patch, wait 48
hours... i.e. package would be broken for ~72 hours just because of a
policy I don't reject in general (yes, I like reviews) but where I think
exceptions must be possible.

So for my understanding this is not about 'fixing' devmanual. It's about
*changing* devmanual which I *just* pointed out. But whoever will
propose changing devmanual should support such a change because he/she
will probably have to argue for that change. Something I cannot do when
I like status quo like I do currently or have concerns.


-- 
Regards,
Thomas Deutschmann / Gentoo Linux Developer
C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] [RFC] Using HTTPS mirrors only in thirdpartymirrors (when possible)

[Thomas Deutschmann]

Hi,

while I invested some time in the past updating thirdpartymirrors to add
HTTPS where possible too, I see no point in dropping non-HTTPS mirrors:

Just make sure that HTTPS mirrors are listed first.

From security point of view, we don't get anything from HTTPS because we
maintain and validate checksums for distfiles and thirdpartymirrors file
is only used for distfiles.


-- 
Regards,
Thomas Deutschmann / Gentoo Linux Developer
C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] [PATCH v3 1/1] kernel-2.eclass: Support move of genpatches tarballs from /space/distfiles-local to devspace

[Thomas Deutschmann]

On 2019-10-10 10:56, Ulrich Mueller wrote:
>>>>>> On Thu, 10 Oct 2019, Mike Pagano wrote:
> 
>> +   GENPATCHES_URI+=" ${use_cond_start}$(echo 
>> https://dev.gentoo.org/~{mpagano,whissi}/dist/genpatches/${tarball})${use_cond_end}"
> 
> The ~ should be backslash-escaped or quoted, otherwise it will be
> expanded if there's a user mpagano or whissi on the system. :-)

Just curious, are you sure? I think this is wrong:

Tilde expansion only happens when string to expand starts with "~" but
this is not the case here (string starts with "https...").

I also tried that code and it's working fine for me...


-- 
Regards,
Thomas Deutschmann / Gentoo Linux Developer
C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] RFC: Should the bot add PRs directly to TRACKER tickets?

[Thomas Deutschmann]

Hi,

I don't understand your mail or call to action, sorry :)

The bot looks for GLEP 66 tags using simple regex. The only purpose of
the bot is to link found contribution (in this case a pull request) to
bugs on b.g.o to inform assignee about contribution which happened
somewhere else in case assignee isn't using/following GitHub for example.

That's all.

Bot doesn't understand bug type and it would be overkill to make bot
understand bugs.

In the example bug, https://bugs.gentoo.org/683184, the problem was that
no individual bug per package was created. So people changing packages
to address the issue raised in tracker bug used that bug as reference.
In other words: The initial failure was that no individual bugs per
affected package was created...


-- 
Regards,
Thomas Deutschmann / Gentoo Linux Developer
C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5



signature.asc
Description: OpenPGP digital signature

[gentoo-dev] Last rites: net-misc/openssh-blacklist

[Thomas Deutschmann]

# Thomas Deutschmann  (2019-11-07)
# EAPI 0. It's been almost a decade since that openssl bug.
# Removal in 30 days.  Bug #697218.
net-misc/openssh-blacklist


-- 
Regards,
Thomas Deutschmann / Gentoo Linux Developer
C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Package up for grabs: sys-apps/lsb-release

[Thomas Deutschmann]

On 2019-11-07 18:57, Jeroen Roovers wrote:
> sys-apps/lsb-release - Linux Standard Base version query program
> 
> Low maintenance, but with six open bug reports.

base-system will take that package.


-- 
Regards,
Thomas Deutschmann / Gentoo Linux Developer
C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5



signature.asc
Description: OpenPGP digital signature

[gentoo-dev] RFC acct-{user,group} for nginx

[Thomas Deutschmann]

Most distributions are using www-data user and are sharing user between
www-servers packages. However, Gentoo, for historical reason(?) is using
apache for www-servers/apache and nginx for www-servers/nginx.

Therefore I am requesting uid and gid 82, both named "nginx", for
www-servers/nginx.


-- 
Regards,
Thomas Deutschmann / Gentoo Linux Developer
C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5



signature.asc
Description: OpenPGP digital signature