Re: [gentoo-dev] Last rites: sys-apps/hwids

2021-12-24 Thread John Helmert III
On Sat, Dec 25, 2021 at 01:51:36AM -0500, Philip Webb wrote:
> 211224 Mike Gilbert wrote:
> > # Mike Gilbert  (2021-12-24)
> > # Replaced by sys-apps/hwdata. Removal on 2021-01-23.
> > sys-apps/hwids
> 
> It seems to be a requirement for my system :
> 
>   root:515 ~> emerge -cpv hwids
> Calculating dependencies... done!
> sys-apps/hwids-20210613-r1 pulled in by:
>   sys-apps/pciutils-3.7.0 requires sys-apps/hwids
>   sys-apps/usbutils-014 requires sys-apps/hwids
>   sys-fs/udev-249.6 requires >=sys-apps/hwids-20140304[udev]
>   x11-libs/libpciaccess-0.16 requires sys-apps/hwids
> 
>   root:512 ~> eix hwids
> [U] sys-apps/hwids
> Available versions: 20210613-r2 ***l {+net +pci systemd +udev 
> +usb}
> Installed versions: 20210613-r1([2021-09-25 15:57:37])(udev usb -net -pci 
> -systemd)
> 
>   root:513 ~> eix hwdata
> [I] sys-apps/hwdata
> Available versions:  0.353^t ~0.354^t
> Installed versions:  0.353^t([2021-12-11 22:30:38])
>
> Am I missing something ?

Yes, you seem to be missing the (perhaps not so) recent commits to the
tree which prepared the tree for the removal of sys-apps/hwids. Please
try syncing and doing a world update then checking again.

signature.asc
Description: PGP signature


[gentoo-dev] [PATCH] mount-boot.eclass: support EAPI 8

2021-12-12 Thread John Helmert III
Signed-off-by: John Helmert III 
---
 eclass/mount-boot.eclass | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/eclass/mount-boot.eclass b/eclass/mount-boot.eclass
index 2b07160231a6..3111d9dcb9b5 100644
--- a/eclass/mount-boot.eclass
+++ b/eclass/mount-boot.eclass
@@ -4,7 +4,7 @@
 # @ECLASS: mount-boot.eclass
 # @MAINTAINER:
 # base-sys...@gentoo.org
-# @SUPPORTED_EAPIS: 6 7
+# @SUPPORTED_EAPIS: 6 7 8
 # @BLURB: functions for packages that install files into /boot
 # @DESCRIPTION:
 # This eclass is really only useful for bootloaders.
@@ -14,7 +14,7 @@
 # error if it can't.  It does nothing if /boot isn't a separate partition.
 
 case ${EAPI:-0} in
-   6|7) ;;
+   6|7|8) ;;
*) die "${ECLASS}: EAPI ${EAPI:-0} not supported" ;;
 esac
 
-- 
2.34.1




[gentoo-dev] Re: Aisha's packages up for grabs

2021-11-21 Thread John Helmert III
On Sun, Nov 21, 2021 at 08:59:57AM +0200, Joonas Niilola wrote:
> Hey,
> 
> the following are up for grabs:
> 
> acct-group/greetd
> acct-user/greetd
> gui-libs/greetd

I'll take these. Very happy to comaintain if anyone else is
interested, of course.

signature.asc
Description: PGP signature


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

2021-11-12 Thread John Helmert III
# John Helmert III  (2021-11-13)
# Unmaintained in Gentoo, open security bug, many unfixed otther
# bugs. Removal on 2021-12-13, bug #764719.
mail-client/cone


signature.asc
Description: PGP signature


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

2021-11-11 Thread John Helmert III
# John Helmert III  (2021-11-12)
# Unfixed code execution bug, unmaintained in Gentoo.
# Removal on 2021-11-11, bugs #672352, #794511.
www-apps/websvn


signature.asc
Description: PGP signature


[gentoo-dev] Last rites: app-emulation/firecracker

2021-11-11 Thread John Helmert III
# John Helmert III  (2021-11-11)
# Unmaintained and vulnerable.
# Removal on 2021-12-11. Bugs #735978, #794907
app-emulation/firecracker

signature.asc
Description: PGP signature


Re: [gentoo-dev] You currently cannot smoothly upgrade a 4 months old Gentoo system

2021-11-03 Thread John Helmert III
On Thu, Nov 04, 2021 at 12:09:28AM +, Sam James wrote:
> On 4 Nov 2021, at 00:02, Sam James  wrote:
> >> On 3 Nov 2021, at 23:53, Aaron Bauman  wrote:
> >> Is that where the policy belongs?
> >> If so, shouldn't the council update it based on their decisions?
> >> "patches are welcome" doesn't fit every scenario.
> > Got to agree here. If there's a gap in the documentation,
> > let's file a bug -- irrespective of if someone is going to give
> > a patch.
> > Just commenting this on the ML means it'll get lost
> > and we'll forget about it...
> 
> Filed https://bugs.gentoo.org/821553. Please
> feel free to clarify it.

Thank you! Many of us apparently have differing interpretations of the
policy (and it's somewhat hidden), so a clear policy in an obvious
place will be a huge improvement!

signature.asc
Description: PGP signature


Re: [gentoo-dev] You currently cannot smoothly upgrade a 4 months old Gentoo system

2021-11-03 Thread John Helmert III
On Wed, Nov 03, 2021 at 05:51:49PM +0100, Thomas Deutschmann wrote:
> On 2021-11-03 17:44, John Helmert III wrote:
> >> | Upgrade path for old systems
> >> | 
> >> | Vote (unanimous): The ebuild tree must provide an upgrade path to a
> >> | stable system that hasn't been updated for one year.
> > Does "upgrade path" imply a simple world upgrade is all that should be
> > necessary to upgrade the system? I wouldn't interpret it this way.
> 
> Could you please share your interpretation? I wonder how you can agree 
> on an upgrade path but still require manually hacking to get a system 
> up-to-date. That is basically the definition of "upgrade path"...

Sure. An "upgrade path" to me sounds like not just a world update, but
also includes other stuff that might be necessary to get a system
fully updated, like temporarily setting PYTHON_TARGETS to upgrade a
package.

A system without an upgrade path would seem to be a system where there
is no way to upgrade it without reinstalling, which you seem to be
asserting is the case for this system.

13:36 <@Whissi> Nice. Due to some people rushing to EAPI8 and remove old 
ebuilds they broke the guarantee to update systems at least once a year again. 
Congratulations! http://dpaste.com/AD87YKY62
13:36 <+sam_> your issue is to do with python targets changing: 
PYTHON_TARGETS="python3_8" emerge -v1 portage should work
13:37 <@Whissi> As you can see, it doesn't work.
13:37 <+sam_> that's not what you ran though?
13:37 <+sam_> see 
https://wiki.gentoo.org/wiki/User:Sam/Portage_help/Upgrading_Portage#Solution
13:37 <@Whissi> http://dpaste.com/7RYRJD72H
13:38 <+sam_> you're not forcing the old PYTHON_TARGETS?
13:39 <@Whissi> No, http://dpaste.com/7V727USW4
13:39 <+sam_> but i'm saying you should
13:39 <+sam_> (not that you should _have_ to)
13:39 <+sam_> temporarily do it once on the command line
13:39 <+sam_> it is enough to get portage upgraded
13:39 <+sam_> we do it often in #gentoo

Based on this snippet from #gentoo-mozilla, it does seem like there is
a way forward for this system.

signature.asc
Description: PGP signature


Re: [gentoo-dev] You currently cannot smoothly upgrade a 4 months old Gentoo system

2021-11-03 Thread John Helmert III
On Wed, Nov 03, 2021 at 05:34:16PM +0100, Ulrich Mueller wrote:
> > On Wed, 03 Nov 2021, Rich Freeman wrote:
> 
> > On Wed, Nov 3, 2021 at 11:03 AM Thomas Deutschmann  
> > wrote:
> >> 
> >> This is not about finding solution to upgrade the system (in this case
> >> it was enough to force PYTHON_TARGETS=python3_8 for portage). This is
> >> about raising awareness that Gentoo is a rolling distribution and that
> >> we guarantee users to be able to upgrade their system when they do world
> >> upgrades just once a year (remember: in my case the last world upgrade
> >> is just 4 months old!). If they cannot upgrade their system without
> >> manual intervention, we failed to do our job.
> 
> > Do we have this "guarantee" documented somewhere?  I thought I've
> > heard six months tossed around.  You say one year.  It seems
> > reasonable to have some sort of guideline like this and try to stick
> > with it, at least for @system.
> 
> We do. Summary of 2009-11-09 Council meeting:
> 
> | https://projects.gentoo.org/council/meeting-logs/20091109-summary.txt
> |
> | Upgrade path for old systems
> | 
> | Vote (unanimous): The ebuild tree must provide an upgrade path to a
> | stable system that hasn't been updated for one year.

Does "upgrade path" imply a simple world upgrade is all that should be
necessary to upgrade the system? I wouldn't interpret it this way.

> | Action: leio will start a discussion on gentoo-dev on if and how to
> | support upgrading systems that are outdated more than a year.




signature.asc
Description: PGP signature


Re: [gentoo-dev] [PATCH] 2021-10-27-upgrade-to-net-news_rssguard-4_0: add news item

2021-10-27 Thread John Helmert III
On Wed, Oct 27, 2021 at 10:53:10AM +0500, Anna Vyalkova wrote:
> Signed-off-by: Anna Vyalkova 
> ---
> Related to this version bump and unmask:
> https://archives.gentoo.org/gentoo-proxy-maint/message/d86352b4ebad8c4ddd14fcd8ce37162f
> 
>  ...27-upgrade-to-net-news_rssguard-4_0.en.txt | 29 +++
>  1 file changed, 29 insertions(+)
>  create mode 100644 
> 2021-10-27-upgrade-to-net-news_rssguard-4_0/2021-10-27-upgrade-to-net-news_rssguard-4_0.en.txt
> 
> diff --git 
> a/2021-10-27-upgrade-to-net-news_rssguard-4_0/2021-10-27-upgrade-to-net-news_rssguard-4_0.en.txt
>  
> b/2021-10-27-upgrade-to-net-news_rssguard-4_0/2021-10-27-upgrade-to-net-news_rssguard-4_0.en.txt
> new file mode 100644
> index 000..35971f0
> --- /dev/null
> +++ 
> b/2021-10-27-upgrade-to-net-news_rssguard-4_0/2021-10-27-upgrade-to-net-news_rssguard-4_0.en.txt
> @@ -0,0 +1,29 @@
> +Title: net-news/rssguard-4.0 upgrade
> +Author: Anna Vyalkova 
> +Posted: 2021-10-27
> +Revision: 1
> +News-Item-Format: 2.0
> +Display-If-Installed: =rssguard-4.0 due to when they sync.

> +
> +RSS Guard database files created by RSS Guard version 3.9.x are
> +incompatible with RSS Guard version 4.0 or later [0].
> +
> +Configuration file (config.ini) is fully backwards compatible according
> +to the upstream. You can save it (File -> Backup settings) before an
> +upgrade and restore it later (File -> Restore settings).
> +
> +There is no reliable way to automate the database format conversion, so
> +action from the user is required before an upgrade can take place.
> +
> +The first option would be to export your feeds as an OMPL file
> +(Accounts -> Export feeds) before an upgrade and import them later
> +(Account -> Import feeds).
> +
> +The second option would be to manually update your database.db file to
> +4.x.x format following a guide by the upstream developer [1].
> +
> +Keep in mind that application data directory has been renamed from
> +"~/.config/RSS Guard" to "~/.config/RSS Guard 4".
> +
> +[0] https://github.com/martinrotter/rssguard/releases/tag/4.0.0
> +[1] 
> https://github.com/martinrotter/rssguard/blob/master/resources/docs/Documentation.md#migratt
> -- 
> 2.33.1
> 
> 


signature.asc
Description: PGP signature


Re: [gentoo-dev] [RFC] Removing separate "security supported" arch list

2021-10-27 Thread John Helmert III
On Thu, Oct 21, 2021 at 10:05:20AM +0200, Michał Górny wrote:
> Hello,
> 
> Splitting from the discussion in [1] (moving more arhitectures to
> ~arch), I'd like to propose that we remove the "security supported"
> architecture list from [2] and instead level security support with
> the general architecture support in Gentoo, e.g. by having all
> architectures with stable profiles be "security supported".

This will better align the written policy with what actually happens
in reality, so I'm all for it! Thanks for bringing this up.

signature.asc
Description: PGP signature


Re: [gentoo-dev] [RFC] Moving more architectures to ~arch only

2021-10-17 Thread John Helmert III
On Mon, Oct 18, 2021 at 02:25:47AM +0200, Thomas Deutschmann wrote:
> On 2021-10-14 15:40, Marek Szuba wrote:
> > WDYT?
>
> Could you please elaborate what you are expecting from this change?
>
> I.e. will this solve any problem (please name it)? Will it allow us to
> move forward where we are blocked at the moment (please name it)?

A security bug, for example, is currently blocked for almost a month
waiting for hppa stabilization [1], and this isn't the first time
we've had to wait for a "slower" arch on a security bug.

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

signature.asc
Description: PGP signature


Re: [gentoo-dev] Stabilization Detached from Security Bugs

2021-08-27 Thread John Helmert III
On Fri, Aug 27, 2021 at 08:58:35AM +0200, Michał Górny wrote:
> On Thu, 2021-08-26 at 19:11 -0500, John Helmert III wrote:
> > In the past, stabilization for security bugs would be handled directly
> > in that security bug. After some discussion on the gentoo-dev mailing
> > list [1], there was some consensus on modifying this workflow to
> > separate stabilization from security bugs. Going forward, separate bugs
> > should be filed for security stabilizations and then the security bug
> > will have a dependency on its stabilization bug.
> 
> Great!  I can make the field invisible on security bugs when you've
> confirmed that all pending stabilizations are finished.  Or without
> that, if you prefer ;-).

Sure! But let's at least wait until we're done with the pending security
bugs which have CC-ARCHES [1], just to keep churn (and work for us)
a bit lower.

[1] 
https://bugs.gentoo.org/buglist.cgi?email1=security%40gentoo.org_to1=1=substring=keywords_id=5758333=substring_format=advanced=---=CC-ARCHES


signature.asc
Description: PGP signature


[gentoo-dev] Stabilization Detached from Security Bugs

2021-08-26 Thread John Helmert III
Hi all,

In the past, stabilization for security bugs would be handled directly
in that security bug. After some discussion on the gentoo-dev mailing
list [1], there was some consensus on modifying this workflow to
separate stabilization from security bugs. Going forward, separate bugs
should be filed for security stabilizations and then the security bug
will have a dependency on its stabilization bug.

Thanks!

[1] 
https://archives.gentoo.org/gentoo-dev/message/72d1747bb087c0317e492177c9653cc3


signature.asc
Description: PGP signature


Re: [gentoo-dev] [PATCH 1/1] kernel-2.eclass: Add cpio dependency

2021-08-23 Thread John Helmert III
On Mon, Aug 23, 2021 at 06:55:57PM -0400, Mike wrote:
> Add cpio dependency to kernel-2.eclass
> 
> Bug: https://bugs.gentoo.org/731666
> 
> Signed-off-by: Mike Pagano 
> ---
>  eclass/kernel-2.eclass | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/eclass/kernel-2.eclass b/eclass/kernel-2.eclass
> index e3d556f2b..83d173d77 100644
> --- a/eclass/kernel-2.eclass
> +++ b/eclass/kernel-2.eclass
> @@ -586,6 +586,7 @@ if [[ ${ETYPE} == sources ]]; then
>   dev-lang/perl
>   sys-devel/bc
>   sys-devel/bison
> + app-arch/cpio

Any reason to not keep the dependencies sorted?


signature.asc
Description: PGP signature


Re: [gentoo-dev] [RFC] Decoupling stabilization from security bugs

2021-08-12 Thread John Helmert III
The benefits definitely seem to outweigh the added work here, sounds
good to me!


signature.asc
Description: PGP signature


[gentoo-dev] Last rites: app-portage/{deltup,getdelta}

2021-07-25 Thread John Helmert III
# John Helmert III  (2021-07-26)
# Open security bug, service backing it seems to be dead, making these
# packages useless. Old EAPIs. Removal on 2021-08-26. Bug #630814
app-portage/getdelta
app-portage/deltup


signature.asc
Description: PGP signature


[gentoo-dev] Last rites: app-text/lout

2021-07-25 Thread John Helmert III
# John Helmert III  (2021-07-26)
# Maintained needed, open security bug, uninterested upstream.
# No revdeps. Removal on 2021-08-26. Bug #752408.
app-text/lout


signature.asc
Description: PGP signature


Re: [gentoo-dev] Package up for grabs: dev-python/imread

2021-07-23 Thread John Helmert III
On Fri, Jul 23, 2021 at 07:42:48PM +0200, Dennis Lamm wrote:
> Hello,
> 
> Package up for grabs due to to no consumer in 3dprint project and other
> portage package:
> dev-python/imread
> 
> It has 1 open bug and a version bump pending according to Repology.
> 
> IMHO: this should be removed from portage.

Why? If you think so, why not do it?


signature.asc
Description: PGP signature


Re: [gentoo-dev] [PATCH v2] bash-completion-r1.eclass: Add EAPI 8 support

2021-07-16 Thread John Helmert III
On Fri, Jul 16, 2021 at 05:33:24PM +0200, Michał Górny wrote:
> Signed-off-by: Michał Górny 
> ---
>  eclass/bash-completion-r1.eclass | 13 +
>  1 file changed, 9 insertions(+), 4 deletions(-)
> 
> diff --git a/eclass/bash-completion-r1.eclass 
> b/eclass/bash-completion-r1.eclass
> index 80f2d5fcd32a..783ba5a85bd2 100644
> --- a/eclass/bash-completion-r1.eclass
> +++ b/eclass/bash-completion-r1.eclass
> @@ -1,138 +1,143 @@
>  # Copyright 1999-2021 Gentoo Authors
>  # Distributed under the terms of the GNU General Public License v2
>  
>  # @ECLASS: bash-completion-r1.eclass
>  # @MAINTAINER:
>  # mgo...@gentoo.org
> -# @SUPPORTED_EAPIS: 0 1 2 3 4 5 6 7
> +# @SUPPORTED_EAPIS: 0 1 2 3 4 5 6 7 8
>  # @BLURB: A few quick functions to install bash-completion files
>  # @EXAMPLE:
>  #
>  # @CODE
> -# EAPI=5
> +# EAPI=8
>  #
>  # src_configure() {
>  #econf \
>  #--with-bash-completion-dir="$(get_bashcompdir)"
>  # }
>  #
>  # src_install() {
>  #default
>  #
>  #newbashcomp contrib/${PN}.bash-completion ${PN}
>  # }
>  # @CODE
>  
> +if [[ ! ${_BASH_COMPLETION_R1_ECLASS} ]]; then
> +
>  inherit toolchain-funcs
>  
>  case ${EAPI:-0} in
> - 0|1|2|3|4|5|6|7) ;;
> - *) die "EAPI ${EAPI} unsupported (yet)."
> + 5|6|7|8) ;;
> + *) die "EAPI ${EAPI} unsupported."
>  esac

SUPPORTED_EAPIS has 0-8, but die on EAPI<5?

>  
>  # @FUNCTION: _bash-completion-r1_get_bashdir
>  # @INTERNAL
>  # @DESCRIPTION:
>  # First argument is name of the string in bash-completion.pc
>  # Second argument is the fallback directory if the string is not found
>  # @EXAMPLE:
>  # _bash-completion-r1_get_bashdir completionsdir /usr/share/bash-completion
>  _bash-completion-r1_get_bashdir() {
>   debug-print-function ${FUNCNAME} "${@}"
>  
>   if $(tc-getPKG_CONFIG) --exists bash-completion &>/dev/null; then
>   local path
>   path=$($(tc-getPKG_CONFIG) --variable="${1}" bash-completion) 
> || die
>   # we need to return unprefixed, so strip from what pkg-config 
> returns
>   # to us, bug #477692
>   echo "${path#${EPREFIX}}"
>   else
>   echo "${2}"
>   fi
>  }
>  
>  # @FUNCTION: _bash-completion-r1_get_bashcompdir
>  # @INTERNAL
>  # @DESCRIPTION:
>  # Get unprefixed bash-completion completions directory.
>  _bash-completion-r1_get_bashcompdir() {
>   debug-print-function ${FUNCNAME} "${@}"
>  
>   _bash-completion-r1_get_bashdir completionsdir 
> /usr/share/bash-completion/completions
>  }
>  
>  # @FUNCTION: _bash-completion-r1_get_helpersdir
>  # @INTERNAL
>  # @DESCRIPTION:
>  # Get unprefixed bash-completion helpers directory.
>  _bash-completion-r1_get_bashhelpersdir() {
>   debug-print-function ${FUNCNAME} "${@}"
>  
>   _bash-completion-r1_get_bashdir helpersdir 
> /usr/share/bash-completion/helpers
>  }
>  
>  # @FUNCTION: get_bashcompdir
>  # @DESCRIPTION:
>  # Get the bash-completion completions directory.
>  get_bashcompdir() {
>   debug-print-function ${FUNCNAME} "${@}"
>  
>   echo "${EPREFIX}$(_bash-completion-r1_get_bashcompdir)"
>  }
>  
>  # @FUNCTION: get_bashhelpersdir
>  # @INTERNAL
>  # @DESCRIPTION:
>  # Get the bash-completion helpers directory.
>  get_bashhelpersdir() {
>   debug-print-function ${FUNCNAME} "${@}"
>  
>   echo "${EPREFIX}$(_bash-completion-r1_get_bashhelpersdir)"
>  }
>  
>  # @FUNCTION: dobashcomp
>  # @USAGE:  [...]
>  # @DESCRIPTION:
>  # Install bash-completion files passed as args. Has EAPI-dependent failure
>  # behavior (like doins).
>  dobashcomp() {
>   debug-print-function ${FUNCNAME} "${@}"
>  
>   (
>   insopts -m 0644
>   insinto "$(_bash-completion-r1_get_bashcompdir)"
>   doins "${@}"
>   )
>  }
>  
>  # @FUNCTION: newbashcomp
>  # @USAGE:  
>  # @DESCRIPTION:
>  # Install bash-completion file under a new name. Has EAPI-dependent failure
>  # behavior (like newins).
>  newbashcomp() {
>   debug-print-function ${FUNCNAME} "${@}"
>  
>   (
>   insopts -m 0644
>   insinto "$(_bash-completion-r1_get_bashcompdir)"
>   newins "${@}"
>   )
>  }
>  
>  # @FUNCTION: bashcomp_alias
>  # @USAGE:  ...
>  # @DESCRIPTION:
>  # Alias  completion to one or more commands (es).
>  bashcomp_alias() {
>   debug-print-function ${FUNCNAME} "${@}"
>  
>   [[ ${#} -lt 2 ]] && die "Usage: ${FUNCNAME}  ..."
>   local base=${1} f
>   shift
>  
>   for f; do
>   dosym "${base}" "$(_bash-completion-r1_get_bashcompdir)/${f}" \
>   || return
>   done
>  }
> +
> +_BASH_COMPLETION_R1_ECLASS=1
> +fi
> -- 
> 2.32.0
> 
> 


signature.asc
Description: PGP signature


[gentoo-dev] Last rites: net-proxy/polipo

2021-07-14 Thread John Helmert III
# John Helmert III  (2021-07-14)
# Dead upstream, unfixed security issue.
# Removal on 2021-08-13.  Bugs #755896, #781467.
net-proxy/polipo


signature.asc
Description: PGP signature


[gentoo-dev] Last rites: net-misc/netkit-rsh

2021-06-19 Thread John Helmert III
# John Helmert III  (2021-06-19)
# Unmaintained, open security bug.
# Removal on 2021-07-19.  Bug #717794.
net-misc/netkit-rsh


signature.asc
Description: PGP signature


Re: [gentoo-dev] [pre-GLEP] Repository configuration file (layout.conf)

2021-05-20 Thread John Helmert III
On Wed, May 19, 2021 at 02:32:27PM +0200, Michał Górny wrote:
> Hi,
> 
> Please review the pre-GLEP inlined below.  Its purpose is to formally
> define the format of layout.conf.  It's pretty much inevitable these
> days, so we should specify it.  However, it doesn't really fit into PMS,
> and other formats (Manifests, metadata.xml) are already defined
> in GLEPs, so this just follows suit.
> 
> Pre-GLEP follows.
> 
> ---
> GLEP: 
> Title: Repository configuration file (layout.conf)
> Author: Michał Górny 
> Type: Standards Track
> Status: Draft
> Version: 1.0
> Created: 2021-05-19
> Last-Modified: 2021-05-19
> Post-History: 2021-05-19
> Content-Type: text/x-rst
> ---
> 
> Abstract
> 
> 
> The ``metadata/layout.conf`` file format is specified as used by Portage
> and PkgCore.  A standard set of configuration keys is described

I can't speak for pkgcore but I can't find anywhere this capitalization
scheme is used. Internally and in its docs it seems 'Pkgcore' is used at
the beginning of sentences, but generally 'pkgcore' is used.

> including the keys currently used in the Gentoo repository.
> 
> 
> Motivation
> ==
> 
> The ``metadata/layout.conf`` file was first added to the Gentoo
> repository in Oct 2011, to facilitate setting of hashes used
> in Manifest2 files.  In Mar 2012, it was used to indicate the transition
> to the new ``md5-dict`` cache format.  In Jul 2013, it started being
> used to indicate the repository's masters and effectively became
> obligatory for all repositories.
> 
> Today, ``layout.conf`` is used for various repository configuration
> knobs that can be expressed as simple values and therefore
> do not justify adding new files to the repository.  This primarily
> involves the configuration of development tools but also includes a few
> keys relevant to the behavior of the package manager.
> 
> However, ``layout.conf`` is currently not covered by any formal
> specification.  The PMS neglects its existence entirely, and the keys
> used are roughly defined by their first use of Portage or PkgCore.
> This GLEP aims to overcome this by providing a formal specification
> for the file, as well as an up-to-date list of permitted configuration
> keys.
> 
> 
> Specification
> =
> 
> layout.conf file format
> ---
> 
> Every ebuild repository must contain a ``metadata/layout.conf`` file.
> The file uses a line-oriented text format.  Lines starting with ``#``
> represent comments and are ignored, as are lines consisting entirely
> of whitespace.  The remaining lines must contain a key followed
> by equals sign (``=``), followed by a (possibly empty) value.  Each of

"...followed by zero or more space separated values" would be better I
think. Currently it reads like only one value is allowed.

> these elements can be surrounded by additional whitespace that
> is stripped.
> 
> 
> Configuration keys
> --
> 
> The ``layout.conf`` file must contain the ``masters`` key.  Other keys
> listed in this specification are entirely optional.  The package
> managers may choose to implement a subset of listed keys.  Unknown keys
> must be ignored.
> 
> The following keys are currently defined:
> 
> masters = 
>   Specifies the master repositories of this repository.  For stand-alone
>   repositories, this must be set to an empty value.  Otherwise, it can
>   list one or more repositories, separated by spaces.  This key must
>   be specified.
> 
> manifest-hashes = 
>   Specifies the list of hashes that should be used for new distfiles
>   in the Manifest files.  The development tools may create a subset
>   of the specified hashes if it is not updating the checksums for
>   the specified distfile, or does not support the hash in question.
>   The hash names are specified in GLEP 74.  [#GLEP74]_  The default
>   set of hashes is implementation-defined.
> 
> manifest-required-hashes = 
>   Specifies the list of hashes that must be used in Manifest files.
>   The development tools must support all the hashes listed there,
>   and update distfile checksums to use these hashes (refetching
>   if necessary).  This must be a subset of manifest-hashes.  If not
>   specified, all hashes from manifest-hashes (or the default set)
>   are considered required.
> 
> use-manifests = ``strict``, ``true`` or ``false``
>   Indicates the policy for creating and using Manifest files.  If set
>   to ``strict``, Manifest files are created and files are required to
>   match digests found in Manifests.  If set to ``true``, Manifests
>   are created but digest mismatches are ignored.  If set to ``false``,
>   Manifests are not used at all.  The default is ``strict``.
> 
> update-changelog = ``true`` or ``false``
>   Indicates whether the development tools should write ChangeLog files.
>   The default is ``false``.
> 
> cache-formats = 
>   Specifies one or more cache formats used by the repository.
>   The currently defined values are ``pms`` for the original 

[gentoo-dev] Re: Packages up for grabs: innoextract, emech, tigervnc, urxvtconfig

2021-02-21 Thread John Helmert III
On Sun, Feb 21, 2021 at 03:54:39PM +0200, Joonas Niilola wrote:
> Hey,
> 
> here are some packages up-for-grabs due to retirement of their maintainers.
> b = bugs open, v = version bump available.
> 
> app-arch/innoextract
> net-irc/emech (b)
> net-misc/tigervnc (b)

Note that this one has a pretty serious bug in Gentoo (it's masked) [0]
and that seems to be blocked by an upstream bug [1].

[0] https://bugs.gentoo.org/746227
[1] https://github.com/TigerVNC/tigervnc/issues/1208

> x11-misc/urxvtconfig (b)
> 


signature.asc
Description: PGP signature


Re: [gentoo-dev] GTK:2 EOL and incoming migration to GTK:3

2021-02-08 Thread John Helmert III
On Mon, Feb 08, 2021 at 02:59:45PM +, Peter Stuge wrote:
> Hanno Böck wrote:
> > > "It does mean, however, that GTK 2 has reached the end of its life. 
> > > We will do one final 2.x release in the coming days, and we encourage
> > > everybody to port their GTK 2 applications to GTK 3 or 4."
> > 
> > I read that as there will be one more gtk2 release and none after that.
> > 
> > This seems to imply:
> > * When there's a security flaw in gtk2 there won't be a fix from
> >   upstream.
> > * When there's an incompatibility with new infrastructure (e.g. new gcc
> >   version / new glibc / changing API of libraries gtk depends on) there
> >   will be no updates from upstream.
> > 
> > This means in all those instances maintainers will have to get patches
> > from somewhere. We'll likely end up with some form of
> > gtk-2.x-r[largenumber] with a large patchset at some point.
> > Maintaining that will be an increasing burden.
> > 
> > No urgency, but a sign to slowly move off gtk2.
> 
> Until there's a relevant flaw that will remain unfixed or there is
> significant incompatibility with infrastructure (recurse my argument)
> no signs actually exist.

Waiting until such a problem pops up and bites everyone before doing
anything about it doesn't sound like a good way to handle it.

> 
> Assuming that there will be a significant maintenance burden which
> affects all uses doesn't seem rational - hence my question.
> 
> The blog post shouldn't be misunderstood. The intended audience seems
> to be application developers, encouraging them to port applications,
> not so much distributions.

If an application never ports, do you expect the distribution to
maintain that package ad infinitum?

> 
> Distributions quite often overlook that they wield much power, and
> thus also have much responsibility.
> 
> Of course, GTK maintainers in Gentoo choose what to work on, and have
> made many (only?) excellent choices.
> 
> I'm merely pleading for rational choices based on actual problems.
> 
> 
> //Peter
> 


signature.asc
Description: PGP signature


Re: [gentoo-dev] [RFC] Discontinuing LibreSSL support?

2020-12-29 Thread John Helmert III
On Tue, Dec 29, 2020 at 02:57:12PM +0100, m1027 wrote:
> > > On 29 Dec 2020, at 09:13, Marcel Schilling
> > >  wrote:
> > > 
> > > I just want to comment that I switched to LibreSSL on several
> > > Gentoo systems years ago and never had any major issues.  I run
> > > both desktop and server systems with LibreSSL, based on X and
> > > Wayland. The only issues I ran into is a slight lag of the
> > > overlay behind the main tree so once in a while I had to mask a
> > > new version of some package for a week or so.
> 
> Let me just come back on the different views here:
> 
> @marcel: Exactly the same here. Smoothly running libressl on dozens
> of systems here, from embedded to ryzen servers, even on Gnome
> desktops. At least from the libressl *user's* perspective.
> 
> sam:
> 
> > TL;DR: [...libressl patches are...] just crippling functionality.
> 
> @sam: From the perspective of libressl maintainers I have had a hard
> time reading this thread ;-) to learn that even security is supposed
> to be an issue with libressl today!? Aren't these crippling patches
> sometimes even helpful (see some apache patches) to crop unreliable
> extra features? I might be wrong here. Actually I'd prefer something
> 'boring' and stable on ssl over new features...
> 
> Well, I cannot judge on the security issues in depth. From a short
> internet scan I don't see recent libressl issues but e.g. this one
> on openssl, https://www.openssl.org/news/vulnerabilities.html, only
> three weeks ago.

That particular vulnerability (CVE-2020-1971) affects both libressl and 
openssl, and
Gentoo has bugs for both.

https://bugs.gentoo.org/759079
https://bugs.gentoo.org/759175

The openssl bug has been fixed, but the libressl bug remains open,
despite both being opened within two days of each (and now existing
for several weeks).


signature.asc
Description: PGP signature


Re: [gentoo-dev] [PATCH] profiles/targets/desktop: Do not enable ldap USE flag by default

2020-09-10 Thread John Helmert III
On Thu, Sep 10, 2020 at 11:59:31AM +0300, Mikle Kolyada wrote:
> 
> On 10.09.2020 08:35, Hans de Graaff wrote:
> > On Wed, 2020-09-09 at 13:35 +0300, Mikle Kolyada wrote:
> >> Closes: https://bugs.gentoo.org/741380
> > Could you provide a rationale for removing this? The bug only has a
> > single anecdotal report of a user who can run a desktop without it. I'm
> > not sure if that is reason enough to remove this. I guess we won't be
> > able to figure out easily how many of our desktop profile users are
> > actually using LDAP, but changing this may cause surprises and I'm not
> > sure if that's warranted.
> >
> > Hans
> 
> 
> Hi.
> 
> It is dictated by common sense.
> 
> I barely can imagine a case where you need ldap support in each and 
> every package you install.
> 
> This should rather be per-package enabled as something non-trivial.

Maybe this change should be introduced with a news item just to help
limit surprises?


signature.asc
Description: PGP signature


Re: [gentoo-dev] Crypto/GPG-related packages up for grabs

2020-09-07 Thread John Helmert III
On Mon, Sep 07, 2020 at 07:44:33PM +0200, Michał Górny wrote:
> Hi,
> 
> The following packages are up for grabs due to their maintainer being
> MIA.
> 
> acct-group/monkeysphere
> acct-user/monkeysphere
> app-crypt/ekeyd
> app-crypt/monkeysphere
> app-crypt/nasty
> app-crypt/pinentry
> app-eselect/eselect-pinentry
> dev-libs/libgcrypt
> dev-libs/npth
> net-misc/sks
> www-apps/ampache

Note that ampache is currency masked for removal:

# Sam James  (2020-08-30)
# Serious security vulns, outdated.
# bug 699834. Removal in 30 days.
www-apps/ampache

https://bugs.gentoo.org/699834

> 
> -- 
> Best regards,
> Michał Górny
> 




signature.asc
Description: PGP signature


Re: [gentoo-dev] Bug #733802, USE 'scp' now defaults to off in net-misc/openssh

2020-07-25 Thread John Helmert III
On Sat, Jul 25, 2020 at 08:05:14PM -0400, Rich Freeman wrote:
> On Sat, Jul 25, 2020 at 7:40 PM Joshua Kinard  wrote:
> >
> > This seems like something that needs a news entry, or
> > at least a "heads up" on the mailing list?
> 
> Definitely not a "heads up" on the mailing list - that is not an
> appropriate way to communicate anything to users - not even devs are
> required to read this list.
> 
> The two appropriate ways to communicate something like this are
> einfo/ewarn/etc or news.  Never hurts to use news.  Ideally I'd point
> to a substitute, and I'd suggest one myself if I were aware of one...

Just to have this information here for easy access, this is upstream's
response from that bug's URL [1]. They recommend "rsync or something else":

The scp command is a historical protocol (called rcp) which relies
upon that style of argument passing and encounters expansion
problems. It has proven very difficult to add "security" to the scp
model. All attempts to "detect" and "prevent" anomalous argument
transfers stand a great chance of breaking existing workflows. Yes,
we recognize it the situation sucks. But we don't want to break the
easy patterns people use scp for, until there is a commonplace
replacement. People should use rsync or something else instead if
they are concerned.

[1] https://github.com/cpandya2909/CVE-2020-15778/


signature.asc
Description: PGP signature


Re: [gentoo-dev] Last-rites: dev-util/cutter

2020-07-24 Thread John Helmert III
On Fri, Jul 24, 2020 at 02:06:56PM +0300, Joonas Niilola wrote:
> # Unmaintained in Gentoo, broken, multiple bugs open.
> # Removal in ~30 days. #733324

Hi, I've opened a PR to take this. The newest version fixes the build
issue present with the version we have in-tree and it seems that like
most (if not all) of the open bugs have been obsoleted.

https://github.com/gentoo/gentoo/pull/16806


signature.asc
Description: PGP signature


Re: [gentoo-dev] */*: Mask Py2 only packages

2020-06-25 Thread John Helmert III
On Thu, Jun 25, 2020 at 07:32:04AM -0400, Michael Orlitzky wrote:
> On 2020-06-24 16:08, Michał Górny wrote:
> > 
> > $ git grep -l mgo...@gentoo.org '**/metadata.xml' | cut -d/ -f1-2 |
> > xargs gpy-py2 2>/dev/null
> > 
> 
> The big problem with this is that it misses any aliases (like graphics@)
> that you're a member of. But let's golf; this is POSIX sh, doesn't use
> grep to parse XML, and takes the maintainer's email address as an argument:
> 
> REPO=/var/db/repos/gentoo
> XPATH="/pkgmetadata/maintainer/email[normalize-space(text()) = '${1}']"
> 
> find -L "${REPO}" \
>   -mindepth 3 \
>   -maxdepth 3 \
>   -name 'metadata.xml' \
>   -exec sh -c "
> for f in \"\${@}\"; do
>   xmllint --xpath \"${XPATH}\" \"\${f}\" >/dev/null 2>&1 && \
> echo \"\$(dirname -- \"\${f}\")\" | sed \"s:${REPO%/}/::\"
> done
>   " - {} +
> 

We can instead avoid parsing XML at all if we're not averse to using
`pquery`, and we can avoid the limitation of scanning the entire tree
for a single name/email by outputting the maintainers for all of the
problematic packages at once (in this case, packages output by
`gpy-py2`) in a greppable format. Not sure why pquery doesn't see
maintainers for things like automake:1.9, so this implementation is
imperfect, but here:

REPO=/var/db/repos/gentoo

for pkg in $(gpy-py2 -r "${REPO}"); do
maint=$(pquery ${pkg} --one-attr maintainers | tail -1)
if [[ ${maint} ]]; then
echo "${pkg}: ${maint}"
else
echo "${pkg}: maintainer-needed"
fi
done


signature.asc
Description: PGP signature


Re: [gentoo-dev] [RFC] Anti-spam for goose

2020-05-22 Thread John Helmert III
On Fri, May 22, 2020 at 12:53:03PM -0700, Brian Dolbec wrote:
> We cannot exclude overlays which will have cat/pkg not in the main
> gentoo repo.  So, we should not excludea submission that includes a few
> of these.

To avoid this problem, even if imperfectly, it should be possible to
track what repository a given package is installed from and then check
its validity based on a list of valid packages for a given overlay.


signature.asc
Description: PGP signature


Re: [gentoo-dev] News item v2: Python 3.7 to become the default target

2020-04-21 Thread John Helmert III
On Tue, Apr 21, 2020 at 07:56:16AM +0200, Michał Górny wrote:
> Display-If-Installed: dev-lang/python:3.6
> 
> On 2020-05-06 (or later), Python 3.7 will replace Python 3.6 as one
> of the default Python targets for Gentoo systems.  The new default
> values will be:
> 
> PYTHON_TARGETS="python2_7 python3_7"
> PYTHON_SINGLE_TARGET="python3_7"

It might be prudent to also show this for python:3.7 in case anyone has
already rebuilt their system with these flags to let them know these
flags are the new defaults and can be removed from their configs.


signature.asc
Description: PGP signature