Re: [gentoo-dev] [RFC v2] News item: OpenSSH 8.2_p1 running sshd breakage

2020-02-19 Thread Joonas Niilola

On 2/19/20 11:32 PM, Patrick McLean wrote:
> Title: OpenSSH 8.2_p1 running sshd breakage
> Author: Patrick McLean 
> Posted: 2020-02-21
> Revision: 1
> News-Item-Format: 2.0
> Display-If-Installed: 
> If sshd is running, and a system is upgraded from  to >=net-misc/openssh-8.2_p1, any new ssh connection will fail until sshd is
> restarted.
>
> Before restarting sshd, it is *strongly* recommended that you test your
> configuraton with the following command (as root):
> sshd -t
>
> If your system is booted with openrc, use this command  (as root) 

double space (inconsistent with similar sentence below)


> to restart sshd:
> rc-service sshd --nodeps restart
>
> If your system is booted with systemd, use this command (as root)
> to restart sshd:
> systemctl restart sshd
>
> If you are using systemd socket activation for sshd, then no action is
> required.
>
> WARNING: On systemd booted machines with PAM disabled, this command
>  will terminate all currently open ssh connections. It is *strongly*
>  recommended that you validate your configuration before restarting
>  sshd.
>
This is pretty much just nitpicking, but

https://www.gentoo.org/glep/glep-0042.html#news-item-body

"The text body should be wrapped at 72 characters. No fancy formatting
or tab characters should be used — the news item may be being displayed
directly to a terminal. Paragraphs should be separated by a blank line."

The 72 char limit breaks 4 times.


LGTM.


-- juippis




signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] [RFC v2] News item: OpenSSH 8.2_p1 running sshd breakage

2020-02-19 Thread Ulrich Mueller
> On Wed, 19 Feb 2020, Patrick McLean wrote:

> If sshd is running, and a system is upgraded from  to >=net-misc/openssh-8.2_p1, any new ssh connection will fail until sshd is
> restarted.

The ebuild currently has this warning:
ewarn "After upgrading to openssh-8.2p1 please restart sshd, otherwise you"
ewarn "will not be able to establish new sessions. Restarting sshd over a ssh"
ewarn "connection is generally safe."

Which IMHO is clearer than the introductory paragraph above.
Especially, I would suggest the last sentence to be included in the news
item.



Re: [gentoo-dev] [RFC v2] News item: OpenSSH 8.2_p1 running sshd breakage

2020-02-19 Thread Haelwenn (lanodan) Monnier
[2020-02-19 13:32:01-0800] Patrick McLean:
> Title: OpenSSH 8.2_p1 running sshd breakage
> Author: Patrick McLean 
> Posted: 2020-02-21
> Revision: 1
> News-Item-Format: 2.0
> Display-If-Installed:  
> If sshd is running, and a system is upgraded from  to >=net-misc/openssh-8.2_p1, any new ssh connection will fail until sshd is
> restarted.
> 
> Before restarting sshd, it is *strongly* recommended that you test your
> configuraton with the following command (as root):
> sshd -t

Typo: s/configuraton/configuration/

> 
> If your system is booted with openrc, use this command  (as root) 
> to restart sshd:
> rc-service sshd --nodeps restart
> 
> If your system is booted with systemd, use this command (as root)
> to restart sshd:
> systemctl restart sshd
> 
> If you are using systemd socket activation for sshd, then no action is
> required.
> 
> WARNING: On systemd booted machines with PAM disabled, this command
>  will terminate all currently open ssh connections. It is *strongly*
>  recommended that you validate your configuration before restarting
>  sshd.
> 



[gentoo-dev] [RFC v2] News item: OpenSSH 8.2_p1 running sshd breakage

2020-02-19 Thread Patrick McLean
Title: OpenSSH 8.2_p1 running sshd breakage
Author: Patrick McLean 
Posted: 2020-02-21
Revision: 1
News-Item-Format: 2.0
Display-If-Installed: =net-misc/openssh-8.2_p1, any new ssh connection will fail until sshd is
restarted.

Before restarting sshd, it is *strongly* recommended that you test your
configuraton with the following command (as root):
sshd -t

If your system is booted with openrc, use this command  (as root) 
to restart sshd:
rc-service sshd --nodeps restart

If your system is booted with systemd, use this command (as root)
to restart sshd:
systemctl restart sshd

If you are using systemd socket activation for sshd, then no action is
required.

WARNING: On systemd booted machines with PAM disabled, this command
 will terminate all currently open ssh connections. It is *strongly*
 recommended that you validate your configuration before restarting
 sshd.



Re: [gentoo-dev] [RFC] News item: OpenSSH 8.2_p1 running sshd breakage

2020-02-19 Thread Michael Jones
On Wed, Feb 19, 2020 at 3:00 PM Mike Gilbert  wrote:

> On Wed, Feb 19, 2020 at 3:41 PM Michael Jones  wrote:
> >
> > How does this effect systemd's socket activation?
> >
> > E.g. The systemd sshd.socket unit file.
>
> Please avoid top-posting.
>
> When socket-activated, a separate instance of sshd is spawned for each
> connection. I don't think any action is needed in that case.
>
>
Consider listing this situation in the news post.


Re: [gentoo-dev] [RFC] News item: OpenSSH 8.2_p1 running sshd breakage

2020-02-19 Thread William Hubbs
On Wed, Feb 19, 2020 at 12:02:51PM -0800, Patrick McLean wrote:
> Title: OpenSSH 8.2_p1 running sshd breakage
> Author: Patrick McLean 
> Posted: 2020-02-21
> Revision: 1
> News-Item-Format: 2.0
> Display-If-Installed:  
> If sshd is running, and a system is upgraded from  to >=net-misc/openssh-8.2_p1, any new ssh connection will fail until sshd is
> restarted.
> 
> Before restarting sshd, it is *strongly* recommended that you test your
> configuraton with the following command (as root):
> sshd -t
> 
> If your system is booted with openrc, use this command  (as root) 
> to restart sshd:
> /etc/init.d/sshd restart

A better choice would be:

rc-service sshd --nodeps restart

William



signature.asc
Description: Digital signature


Re: [gentoo-dev] [RFC] News item: OpenSSH 8.2_p1 running sshd breakage

2020-02-19 Thread Mike Gilbert
On Wed, Feb 19, 2020 at 3:41 PM Michael Jones  wrote:
>
> How does this effect systemd's socket activation?
>
> E.g. The systemd sshd.socket unit file.

Please avoid top-posting.

When socket-activated, a separate instance of sshd is spawned for each
connection. I don't think any action is needed in that case.



Re: [gentoo-dev] [RFC] News item: OpenSSH 8.2_p1 running sshd breakage

2020-02-19 Thread Michael Jones
How does this effect systemd's socket activation?

E.g. The systemd sshd.socket unit file.

On Wed, Feb 19, 2020 at 2:12 PM Mike Gilbert  wrote:

> On Wed, Feb 19, 2020 at 3:02 PM Patrick McLean 
> wrote:
> >
> > Title: OpenSSH 8.2_p1 running sshd breakage
> > Author: Patrick McLean 
> > Posted: 2020-02-21
> > Revision: 1
> > News-Item-Format: 2.0
> > Display-If-Installed:  >
> > If sshd is running, and a system is upgraded from
>  > to >=net-misc/openssh-8.2_p1, any new ssh connection will fail until
> sshd is
> > restarted.
> >
> > Before restarting sshd, it is *strongly* recommended that you test your
> > configuraton with the following command (as root):
> > sshd -t
> >
> > If your system is booted with openrc, use this command  (as root)
> > to restart sshd:
> > /etc/init.d/sshd restart
> >
> > If your system is booted with systemd, use this command (as root)
> > to restart sshd:
> > systemctl restart sshd
> >
> > WARNING: On systemd booted machines, this command will terminate all
> currently
> >  open ssh connections, it is *strongly* reccommended that you
> validate
> >  your configuration before restarting sshd.
> >
>
> Existing connections are only terminated if the pam_systemd module is
> not enabled. This might happen if the user has disabled USE=pam on
> sys-apps/systemd, or if they have modified the system pam stack to
> exclude pam_systemd.
>
> Maybe change the warning to this:
>
> WARNING: On systemd booted machines with PAM disabled, this command
> will terminate all currently open ssh connections. It is *strongly*
> recommended that you validate your configuration before restarting
> sshd.
>
>


Re: [gentoo-dev] [RFC] News item: OpenSSH 8.2_p1 running sshd breakage

2020-02-19 Thread Mike Gilbert
On Wed, Feb 19, 2020 at 3:02 PM Patrick McLean  wrote:
>
> Title: OpenSSH 8.2_p1 running sshd breakage
> Author: Patrick McLean 
> Posted: 2020-02-21
> Revision: 1
> News-Item-Format: 2.0
> Display-If-Installed: 
> If sshd is running, and a system is upgraded from  to >=net-misc/openssh-8.2_p1, any new ssh connection will fail until sshd is
> restarted.
>
> Before restarting sshd, it is *strongly* recommended that you test your
> configuraton with the following command (as root):
> sshd -t
>
> If your system is booted with openrc, use this command  (as root)
> to restart sshd:
> /etc/init.d/sshd restart
>
> If your system is booted with systemd, use this command (as root)
> to restart sshd:
> systemctl restart sshd
>
> WARNING: On systemd booted machines, this command will terminate all currently
>  open ssh connections, it is *strongly* reccommended that you validate
>  your configuration before restarting sshd.
>

Existing connections are only terminated if the pam_systemd module is
not enabled. This might happen if the user has disabled USE=pam on
sys-apps/systemd, or if they have modified the system pam stack to
exclude pam_systemd.

Maybe change the warning to this:

WARNING: On systemd booted machines with PAM disabled, this command
will terminate all currently open ssh connections. It is *strongly*
recommended that you validate your configuration before restarting
sshd.



[gentoo-dev] [RFC] News item: OpenSSH 8.2_p1 running sshd breakage

2020-02-19 Thread Patrick McLean
Title: OpenSSH 8.2_p1 running sshd breakage
Author: Patrick McLean 
Posted: 2020-02-21
Revision: 1
News-Item-Format: 2.0
Display-If-Installed: =net-misc/openssh-8.2_p1, any new ssh connection will fail until sshd is
restarted.

Before restarting sshd, it is *strongly* recommended that you test your
configuraton with the following command (as root):
sshd -t

If your system is booted with openrc, use this command  (as root) 
to restart sshd:
/etc/init.d/sshd restart

If your system is booted with systemd, use this command (as root)
to restart sshd:
systemctl restart sshd

WARNING: On systemd booted machines, this command will terminate all currently
 open ssh connections, it is *strongly* reccommended that you validate
 your configuration before restarting sshd.



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

2020-02-19 Thread Andreas Sturmlechner
# Andreas Sturmlechner  (2020-02-19)
# Last release in 2011, py2-only, blocks dev-python/pygtk removal, bug #708102
# There are plenty other image viewers to choose from.
# Masked for removal in 30 days.
media-gfx/mirage





[gentoo-dev] Last-rites: gnome-extra/nautilus-dropbox

2020-02-19 Thread Andreas Sturmlechner
# Andreas Sturmlechner  (2020-02-19)
# No maintainer, py2-only, blocks dev-python/pygtk removal, needs version bump
# See bugs #546024, #706486. Masked for removal in 30 days.
gnome-extra/nautilus-dropbox





[gentoo-dev] Last-rites: x11-misc/driconf

2020-02-19 Thread Andreas Sturmlechner
# Andreas Sturmlechner  (2020-02-19)
# Last release in 2006, py2-only, blocks dev-python/pygtk removal, bug #708134
# Masked for removal in 30 days.
x11-misc/driconf





Re: [gentoo-dev] [PATCH v2 1/4] eclass/go-module: add support for building based on go.sum

2020-02-19 Thread William Hubbs
On Wed, Feb 19, 2020 at 09:20:13AM -0600, William Hubbs wrote:
> On Wed, Feb 19, 2020 at 07:36:27AM +, Robin H. Johnson wrote:
> > On Tue, Feb 18, 2020 at 11:46:45PM -0600, William Hubbs wrote:
> > > > -# If it does not have a vendor directory, you should use the EGO_VENDOR
> > > > +# Alternatively, older versions of this eclass used the EGO_VENDOR
> > > >  # variable and the go-module_vendor_uris function as shown in the
> > > >  # example below to handle dependencies.
> > > I think we can remove the example with EGO_VENDOR and
> > > go-module_vendor_uris; we really don't want people to continue following
> > > that example.
> > I tried to handle more cases here, but now I'm wondering if it would be
> > cleaner just to put all of new way into a distinct eclass, and sunset
> > the old eclass entirely. I found unforeseen interactions, see below.
> > 
> > > > +# S="${WORKDIR}/${MY_P}"
> > > The default setting of S should be fine for most ebuilds, so I don't
> > > think we need this in the example.
> > I'd copied it, but yes in this case.
> > 
> > > 
> > > > +# go-module_set_globals
> > > > +#
> > > > +# SRC_URI="https://github.com/example/${PN}/archive/v${PV}.tar.gz -> 
> > > > ${P}.tar.gz
> > > > +# ${EGO_SUM_SRC_URI}"
> > > > +#
> > > > +# LICENSE="some-license ${EGO_SUM_LICENSES}"
> > > > +#
> > > > +# src_unpack() {
> > > > +#  unpack ${P}.tar.gz
> > > > +#  go-module_src_unpack
> > > > +# }
> > >  I don't think I would put an src_unpack() in the example.
> > This is one of the unforeseen interactions.
> > The go.sum unpack only applies special handling to distfiles that it
> > knows about. It does NOT process any other distfiles at all.
> > 
> > EAPI8 or future Portage improvements might have annotations to disable
> > any automatic unpacking for specific distfiles, which would resolve this
> > issue.
> > 
> > Hence, you need to explicitly unpack any distfiles that are NOT part of
> > the go.sum dependencies. There are some ebuilds that do unpack & rename
> > in src_unpack already, so they need extra care as well.
> > 
> > The EGO_VENDOR src_unpack unpacked EVERYTHING, so it didn't have this
> > issue.

It used filtering to decide what to unpack where, so I think we can use
the same idea.  Look at this patch to what is in the tree currently.

Look at this patch. Part of it is just comments, but I think this could
work if module_files is populated correctly.

diff --git a/eclass/go-module.eclass b/eclass/go-module.eclass
index 80ff2902b3a..3e0091a0d25 100644
--- a/eclass/go-module.eclass
+++ b/eclass/go-module.eclass
@@ -113,7 +113,8 @@ go-module_vendor_uris() {
 # ${EGO_VENDOR} to ${S}/vendor.
 go-module_src_unpack() {
debug-print-function ${FUNCNAME} "$@"
-   local f hash import line repo tarball vendor_tarballs x
+   local f hash import line repo tarball module_files vendor_tarballs x
+   module_files=()
vendor_tarballs=()
for line in "${EGO_VENDOR[@]}"; do
read -r import hash repo x <<< "${line}"
@@ -125,9 +126,15 @@ go-module_src_unpack() {
: "${repo:=${import}}"
vendor_tarballs+=("${repo//\//-}-${hash}.tar.gz")
done
+   # populate module_files with the files we do not want to unpack
+   # based on EGO_SUM
+
+   # unpack the appropriate files from $A
for f in $A; do
[[ -n ${vendor_tarballs[*]} ]] && has "$f" 
"${vendor_tarballs[@]}" &&
continue
+   [[ -n ${module_files[*]} ]] && has "$f" "${module_files[@]}" &&
+   continue
unpack "$f"
done
 


signature.asc
Description: Digital signature


[gentoo-dev] Last-rites: net-wireless/wifi-radar

2020-02-19 Thread Andreas Sturmlechner
# Andreas Sturmlechner  (2020-02-19)
# Last commit in 2015, py2-only, blocks dev-python/pygtk removal, bug #710170
# Masked for removal in 30 days.
net-wireless/wifi-radar





Re: [gentoo-dev] [PATCH v2 1/4] eclass/go-module: add support for building based on go.sum

2020-02-19 Thread William Hubbs
On Wed, Feb 19, 2020 at 07:36:27AM +, Robin H. Johnson wrote:
> On Tue, Feb 18, 2020 at 11:46:45PM -0600, William Hubbs wrote:
> > > -# If it does not have a vendor directory, you should use the EGO_VENDOR
> > > +# Alternatively, older versions of this eclass used the EGO_VENDOR
> > >  # variable and the go-module_vendor_uris function as shown in the
> > >  # example below to handle dependencies.
> > I think we can remove the example with EGO_VENDOR and
> > go-module_vendor_uris; we really don't want people to continue following
> > that example.
> I tried to handle more cases here, but now I'm wondering if it would be
> cleaner just to put all of new way into a distinct eclass, and sunset
> the old eclass entirely. I found unforeseen interactions, see below.
> 
> > > +# S="${WORKDIR}/${MY_P}"
> > The default setting of S should be fine for most ebuilds, so I don't
> > think we need this in the example.
> I'd copied it, but yes in this case.
> 
> > 
> > > +# go-module_set_globals
> > > +#
> > > +# SRC_URI="https://github.com/example/${PN}/archive/v${PV}.tar.gz -> 
> > > ${P}.tar.gz
> > > +#   ${EGO_SUM_SRC_URI}"
> > > +#
> > > +# LICENSE="some-license ${EGO_SUM_LICENSES}"
> > > +#
> > > +# src_unpack() {
> > > +#unpack ${P}.tar.gz
> > > +#go-module_src_unpack
> > > +# }
> >  I don't think I would put an src_unpack() in the example.
> This is one of the unforeseen interactions.
> The go.sum unpack only applies special handling to distfiles that it
> knows about. It does NOT process any other distfiles at all.
> 
> EAPI8 or future Portage improvements might have annotations to disable
> any automatic unpacking for specific distfiles, which would resolve this
> issue.
> 
> Hence, you need to explicitly unpack any distfiles that are NOT part of
> the go.sum dependencies. There are some ebuilds that do unpack & rename
> in src_unpack already, so they need extra care as well.
> 
> The EGO_VENDOR src_unpack unpacked EVERYTHING, so it didn't have this
> issue.

I will look at that in a bit and comment on it.

> 
> > 
> > > +# The extra metadata keys accepted at this time are:
> > > +# - license: for dependencies built into the final runtime, the value 
> > > field is
> > > +#   a comma seperated list of Gentoo licenses to apply to the LICENSE 
> > > variable, 
> > > +#
> > There are two lines for each module in go.sum, the one with /go.mod as a
> > suffix to the version and the one without. We do not need both right?
> This is not entirely correct, and it's the warnings from golang upstream
> about some hidden complexity in the /go.mod that lead me to list both of
> them.
> 
> If we intend to verify the h1: in future, then we need to list all
> /go.mod entries explicitly, so have somewhere to put the h1: hash.
> If you're verifying the h1: hash, you must verify it on the
> {version}.mod ALWAYS, and if the {version}.zip is present, then also on
> that file (otherwise it could sneak in some evil metadata via the
> {version}.mod).
> 
> If we omit h1: entirely, then we can get away with listing ONE line in
> EGO_SUM for each dependency.
> - If it contains /go.mod, it will fetch ONLY the {version}.mod file.
> - If it does not contain /go.mod, it will fetch the {version}.mod file
>   AND the {version}.zip file
 
If Go itself does that verification during the build, do we need to do
it also?

> > > +# @EXAMPLE:
> > > +# # github.com/BurntSushi/toml is a build-time only dep
> > > +# # github.com/aybabtme/rgbterm is a runtime dep, annotated with licenses
> > 
> > I'm not sure we can distinguish between buildtime only and runtime deps.
> The 'golicense' tool will take a Golang binary and print out all of the
> Golang modules that got linked into it. I consider those to be the
> runtime deps in this case.
> 
> > > +# @ECLASS-VARIABLE: _GOMODULE_GOPROXY_BASEURI
> ...
> > > +# This variable should NOT be present in user-level configuration e.g.
> > > +# /etc/portage/make.conf, as it will violate metadata immutability!
> > > +: "${_GOMODULE_GOPROXY_BASEURI:=mirror://goproxy/}"
> > 
> > If this isn't supposed to be in user-level configuration, where should
> > it be set?
> Maybe I'll just prefix it with 'readonly' and force the value for now.
> 
> > >  # @FUNCTION: go-module_src_unpack
> > >  # @DESCRIPTION:
> > > +# Extract & configure Go modules for consumpations.
> > > +# - Modules listed in EGO_SUM are configured as a local GOPROXY via 
> > > symlinks (fast!)
> > > +# - Modules listed in EGO_VENDOR are extracted to "${S}/vendor" (slow)
> > > +#
> > > +# This function does NOT unpack the base distfile of a Go-based package.
> > > +# While the entries in EGO_SUM will be listed in ${A}, they should NOT be
> > > +# unpacked, Go will directly consume the files, including zips.
> > > +go-module_src_unpack() {
> > 
> > If possible, this function should unpack the base distfile. That would
> > keep us from having to write src_unpack for every go ebuild that uses
> > the eclass.
> That's fine 

[gentoo-dev] Last-rites: app-misc/pysmssend

2020-02-19 Thread Andreas Sturmlechner
# Andreas Sturmlechner  (2020-02-19)
# Dead upstream, py2-only. Masked for removal in 30 days.
app-misc/pysmssend





[gentoo-dev] Last-rites: app-mobilephone/pysms

2020-02-19 Thread Andreas Sturmlechner
# Andreas Sturmlechner  (2020-02-19)
# Last release in 2007, py2-only, blocks dev-python/pygtk removal,
# Masked for removal in 30 days.
app-mobilephone/pysms





[gentoo-dev] Last-rites: media-sound/pympd

2020-02-19 Thread Andreas Sturmlechner
# Andreas Sturmlechner  (2020-02-19)
# Last release and commit in 2007, py2-only, blocks dev-python/pygtk removal,
# bugs #678656, #707632. Masked for removal in 30 days.
media-sound/pympd





[gentoo-dev] Last-rites: media-sound/volti

2020-02-19 Thread Andreas Sturmlechner
# Andreas Sturmlechner  (2020-02-19)
# No more revdeps, abandoned upstream, broken by current dbus-python, py2-only,
# blocks dev-python/pygtk removal, bug #626374. Masked for removal in 30 days.
media-sound/volti