Re: [gentoo-dev] Last rites: net-dns/pdnsd

[Lars Wendler]

On Mon, 13 Dec 2021 20:46:40 +0300 Andrew Savchenko wrote:

>On Mon, 13 Dec 2021 09:34:46 +0100 Lars Wendler wrote:
>> On Sun, 12 Dec 2021 13:35:20 +0300 Andrew Savchenko wrote:
>> 
>> >On Tue, 7 Dec 2021 15:33:34 +0100 Lars Wendler wrote:
>> >> Fails to build with recent kernel headers (bug #801688).
>> >> Upstream is gone for a long time. Masked for removal in 30 days.
>> >> Users should switch over to net-dns/dnsmasq which provides similar
>> >> features.
>> >
>> >Depending on usage profile net-dns/unbound may be a better
>> >replacement. For me a killer feature of pdnsd was the persistent
>> >dns cache, which is very useful on mobile devices. Dnsmasq doesn't
>> >have one, but unbound now has.
>> >
>> >Best regards,
>> >Andrew Savchenko
>> 
>> Feel free to extend the mask message.
>> Although I'm considering to cancel the last rite now that a patch has
>> been submitted to bug #801688.
>
>Yes, keeping package would be the best option since patch is
>available: it has many diverse uses.
>
>Best regards,
>Andrew Savchenko

Last-rite has been canceled:

https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=7ce35657f269c3b7016e8940ad36e59cf06e12a4

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


Cheers
-- 
Lars Wendler
Gentoo package maintainer
GPG: 21CC CF02 4586 0A07 ED93  9F68 498F E765 960E 9B39


pgpo4Jf9AQkl8.pgp
Description: Digitale Signatur von OpenPGP

Re: [gentoo-dev] Last rites: net-dns/pdnsd

[Lars Wendler]

On Sun, 12 Dec 2021 13:35:20 +0300 Andrew Savchenko wrote:

>On Tue, 7 Dec 2021 15:33:34 +0100 Lars Wendler wrote:
>> Fails to build with recent kernel headers (bug #801688).
>> Upstream is gone for a long time. Masked for removal in 30 days.
>> Users should switch over to net-dns/dnsmasq which provides similar
>> features.
>
>Depending on usage profile net-dns/unbound may be a better
>replacement. For me a killer feature of pdnsd was the persistent
>dns cache, which is very useful on mobile devices. Dnsmasq doesn't
>have one, but unbound now has.
>
>Best regards,
>Andrew Savchenko

Feel free to extend the mask message.
Although I'm considering to cancel the last rite now that a patch has
been submitted to bug #801688.

Cheers
Lars
-- 
Lars Wendler
Gentoo package maintainer
GPG: 21CC CF02 4586 0A07 ED93  9F68 498F E765 960E 9B39


pgpn7PJtyS4h8.pgp
Description: Digitale Signatur von OpenPGP

[gentoo-dev] Last rites: net-dns/pdnsd

[Lars Wendler]

Fails to build with recent kernel headers (bug #801688).
Upstream is gone for a long time. Masked for removal in 30 days.
Users should switch over to net-dns/dnsmasq which provides similar
features.

-- 
Lars Wendler
Gentoo package maintainer
GPG: 21CC CF02 4586 0A07 ED93  9F68 498F E765 960E 9B39


pgpnRzt8VNH8e.pgp
Description: Digitale Signatur von OpenPGP

Re: [gentoo-dev] Last rites: media-sound/clementine

[Lars Wendler]

On Mon, 6 Dec 2021 23:56:10 + Alexey Sokolov wrote:

>24.11.2021 11:33, Lars Wendler пишет:
>> No real development since Q1 2020. Last release from 2016.
>> Users should switch over to media-sound/strawberry which is an
>> actively developed fork.
>> Masked for removal in 30 days.
>> 
>> 
>
>I've tried strawberry, but it's unusable [1]. At least until bugs are 
>fixed, can it be unmasked? I can take maintainership if needed.
>
>[1] https://github.com/strawberrymusicplayer/strawberry/issues/849
>

Saying that it's "unusable" is quite a misleading claim when in fact
only keyboard shortcuts do not work...

-- 
Lars Wendler
Gentoo package maintainer
GPG: 21CC CF02 4586 0A07 ED93  9F68 498F E765 960E 9B39


pgpZV044N87Yd.pgp
Description: Digitale Signatur von OpenPGP

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

[Lars Wendler]

No real development since Q1 2020. Last release from 2016.
Users should switch over to media-sound/strawberry which is an actively
developed fork.
Masked for removal in 30 days.


-- 
Lars Wendler
Gentoo package maintainer
GPG: 21CC CF02 4586 0A07 ED93  9F68 498F E765 960E 9B39


pgpRURZrDQaTs.pgp
Description: Digitale Signatur von OpenPGP

[gentoo-dev] Packages up for grabs

[Lars Wendler]

Hi,

the following packages are up for grabs:

app-emulation/sen (3 open bugs)
dev-python/flexmock
sys-process/nmon (2 open bugs)
x11-wm/i3


Cheers
-- 
Lars Wendler
Gentoo package maintainer
GPG: 21CC CF02 4586 0A07 ED93  9F68 498F E765 960E 9B39


pgpWcw9hwsTLL.pgp
Description: Digitale Signatur von OpenPGP

Re: [gentoo-dev] News item: breaking change to app-misc/mc user-configuration handling

[Lars Wendler]

Hi Marek,

thank you very much for wqriting this up. I highly appreciate this.

On Mon, 16 Aug 2021 16:15:06 +0100 Marek Szuba wrote:

>Title: >=app-misc/mc-4.8.27 to drop support for ~/.mc
>Author: Marek Szuba 
>Posted: 2021-08-19
>Revision: 1
>News-Item-Format: 2.0
>Display-If-Installed: app-misc/mc
>
>app-misc/mc versions between 4.8.1 and 4.8.26, inclusive, would look
>for their user configuration in two possible places:
>
>  * if built with USE=-xdg, only the legacy directory ~/.mc is used;
>
>  * if built with USE=xdg, mc uses appropriate XDG user directories
>(e.g. ~/.config/mc, ~/.local/share/mc) if present and attempts
>to automatically migrate the contents of ~/.mc otherwise.
>
>However, starting with version 4.8.27 Midnight Commander will use _only
>XDG user directories_ for its configuration and no longer automatically
>migrate the contents of ~/.mc. For more information, see:
>
> https://midnight-commander.org/wiki/NEWS-4.8.27
> https://midnight-commander.org/ticket/3682
>
>For everyone who currently uses app-misc/mc[-xdg], or has not started
>mc for so long that it hasn't had a chance to migrate its
>configuration, upgrading to 4.8.27 or newer will result in Midnight
>Commander effectively reverting to default user configuration. In
>order to prevent this from happening, make sure automatic migration is
>available:
>
> echo 'app-misc/mc' >> /etc/portage/package.use

I suppose that should be:

  echo 'app-misc/mc xdg' >> /etc/portage/package.use

> emerge --oneshot 
>and have every user on your system with ~/.mc present run mc at least

run mc _and_ mcedit once

>once prior to the version upgrade.
>
>No action is required of everyone currently using app-misc/mc

s/of/for/  ?

>with USE=xdg enabled.
>

Cheers
Lars
-- 
Lars Wendler
Gentoo package maintainer
GPG: 21CC CF02 4586 0A07 ED93  9F68 498F E765 960E 9B39


pgpI6NKivAcy0.pgp
Description: Digitale Signatur von OpenPGP

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

[Lars Wendler]

Hi Michał,

On Thu, 12 Aug 2021 14:53:33 +0200 Michał Górny wrote:

>Hello, everyone.
>
>TL;DR: I'd like to propose that stabilizations are done via blockers of
>security bugs instead of security bugs themselves, i.e. as any other
>stabilizations.
>
>
>Right now we're often performing security-related stabilizations via
>security bugs. This has a few problems, that are:
>
>1. Stabilization-related activity causes unnecessary mail to the widely
>subscribed security alias. That is, subscribed people get notified of
>package list changes, NATTkA results, every arch doing its work.
>However, in reality the security team only cares about stabilization
>being started, stalled or finished -- and for that, getting the usual
>'dependent bug added/closed' mail should be sufficient.
>
>2. NATTkA has no good way of distinguishing irrelevant security bugs
>from security bugs where something went wrong (and NATTkA doesn't use
>persistent state by design). The most important problem is that --
>unlike regular stablereqs -- security bugs aren't supposed to be closed
>after stabilization. It can't really distinguish a security bug 'left
>open' from a security bug with incorrect package list.
>
>3. Proxied maintainers without editbugs can't actually CC arches on
>security bugs since the bugs are assigned to security@.
>
>
>To resolve these problems going forward and establish consistent
>behavior in the future, I'd like to propose to disable 'package list'
>fields on security bugs and instead expect regular stabilization bugs
>to be used (and made block the security bugs) for stabilizations.
>While I understand that filing additional bugs might be cumbersome for
>some people, I don't think it's such a herculean effort to outweigh
>the problems solved.

Indeed, filing stablereq bugs is not really that big of a deal.

>In the end, consistency is a good thing and we've introduced a
>dedicated stabilization category to reduce the spread of stabilization
>bugs all around the place.
>
>WDYT?
>

I like this proposal and fully support it. Thanks for bringing it up.

Cheers
-- 
Lars Wendler
Gentoo package maintainer
GPG: 21CC CF02 4586 0A07 ED93  9F68 498F E765 960E 9B39


pgpd28bN2WpgH.pgp
Description: Digitale Signatur von OpenPGP

Re: [gentoo-dev] News item: sys-libs/db old SLOT removal

[Lars Wendler]

Hi Thomas,

On Fri, 28 May 2021 15:13:41 +0200 Thomas Deutschmann wrote:

>On 2021-05-27 00:41, David Seifert wrote:
>> Furthermore, the Gentoo Base System Team has decided to consider
>> sys-libs/db a deprecated database backend.
>
>Uh? When did that happen?

We've discussed this at length in #gentoo-base and nobody complained.

> While there is no development happening 
>anymore in old versions, 5.3 is feature complete, stable and a good 
>choice for small setups like a postfix setup with the need for a few 
>lookup tables. It's offering features you don't find anywhere else.
>
>As long as 5.3 keeps building... there shouldn't be any need to kill
>it. It's not even blocking anything because it has no deps.

Well, it's abandoned by upstream so potential bugs will never get fixed
officially. Perhaps if some distros decide to continue maintenance of
the source code we can consider keeping the package but I don't see that
happen...

>> Other distros such as Fedora have started a gradual phase-out of
>> Berkeley DB too, given Oracle's strong-armed approach to community
>> input and their arguably hostile switch to the AGPLv3
>> (https://fedoraproject.org/wiki/Changes/Libdb_deprecated).
>> Furthermore, Oracle is known to remove critical features from BDB in
>> patch releases, such as the removal of the client-server
>> architecture and the SQL API between 18.1.32 and 18.1.40.
>
>This paragraph doesn't belong into a news item.

I think this should belong into the news item in order to explain our
rationale behind this decision.


Kind regards
-- 
Lars Wendler
Gentoo package maintainer
GPG: 21CC CF02 4586 0A07 ED93  9F68 498F E765 960E 9B39


pgp335SIFC_4x.pgp
Description: Digitale Signatur von OpenPGP

[gentoo-dev] (resent) [PATCH] eclass: Support dev-util/samurai

[Lars Wendler]

From: orbea 

Signed-off-by: Lars Wendler 
---
 eclass/cmake.eclass   | 22 --
 eclass/meson.eclass   |  4 ++--
 eclass/ninja-utils.eclass | 37 +++--
 3 files changed, 45 insertions(+), 18 deletions(-)

diff --git a/eclass/cmake.eclass b/eclass/cmake.eclass
index 4bd09459ea6..935ee1d8c81 100644
--- a/eclass/cmake.eclass
+++ b/eclass/cmake.eclass
@@ -52,9 +52,9 @@ _CMAKE_ECLASS=1
 # @DEFAULT_UNSET
 # @DESCRIPTION:
 # Specify a makefile generator to be used by cmake.
-# At this point only "emake" and "ninja" are supported.
-# The default is set to "ninja".
-: ${CMAKE_MAKEFILE_GENERATOR:=ninja}
+# At this point only "emake", "eninja" and "ninja" are supported.
+# The default is set to "eninja".
+: ${CMAKE_MAKEFILE_GENERATOR:=eninja}
 
 # @ECLASS-VARIABLE: CMAKE_REMOVE_MODULES_LIST
 # @DESCRIPTION:
@@ -117,8 +117,8 @@ case ${CMAKE_MAKEFILE_GENERATOR} in
emake)
BDEPEND="sys-devel/make"
;;
-   ninja)
-   BDEPEND="dev-util/ninja"
+   eninja|ninja)
+   BDEPEND="|| ( dev-util/ninja dev-util/samurai )"
;;
*)
eerror "Unknown value for \${CMAKE_MAKEFILE_GENERATOR}"
@@ -335,13 +335,6 @@ cmake_src_prepare() {
die "FATAL: Unable to find CMakeLists.txt"
fi
 
-   # if ninja is enabled but not installed, the build could fail
-   # this could happen if ninja is manually enabled (eg. make.conf) but 
not installed
-   if [[ ${CMAKE_MAKEFILE_GENERATOR} == ninja ]] && ! has_version -b 
dev-util/ninja; then
-   eerror "CMAKE_MAKEFILE_GENERATOR is set to ninja, but ninja is 
not installed."
-   die "Please install dev-util/ninja or unset 
CMAKE_MAKEFILE_GENERATOR."
-   fi
-
local modules_list
if [[ $(declare -p CMAKE_REMOVE_MODULES_LIST) == "declare -a"* ]]; then
modules_list=( "${CMAKE_REMOVE_MODULES_LIST[@]}" )
@@ -534,7 +527,7 @@ cmake_src_configure() {
 
local generator_name
case ${CMAKE_MAKEFILE_GENERATOR} in
-   ninja) generator_name="Ninja" ;;
+   eninja|ninja) generator_name="Ninja" ;;
emake) generator_name="Unix Makefiles" ;;
esac
 
@@ -592,8 +585,9 @@ cmake_build() {
*) emake VERBOSE=1 "$@" ;;
esac
;;
-   ninja)
+   eninja|ninja)
[[ -e build.ninja ]] || die "build.ninja not found. 
Error during configure stage."
+   CMAKE_MAKEFILE_GENERATOR=eninja
eninja "$@"
;;
esac
diff --git a/eclass/meson.eclass b/eclass/meson.eclass
index d0ce5adb355..ea02402aa83 100644
--- a/eclass/meson.eclass
+++ b/eclass/meson.eclass
@@ -1,4 +1,4 @@
-# Copyright 2017-2020 Gentoo Authors
+# Copyright 2017-2021 Gentoo Authors
 # Distributed under the terms of the GNU General Public License v2
 
 # @ECLASS: meson.eclass
@@ -55,7 +55,7 @@ if [[ -z ${_MESON_ECLASS} ]]; then
 _MESON_ECLASS=1
 
 MESON_DEPEND=">=dev-util/meson-0.54.0
-   >=dev-util/ninja-1.8.2
+   || ( >=dev-util/ninja-1.8.2 dev-util/samurai )
dev-util/meson-format-array
 "
 
diff --git a/eclass/ninja-utils.eclass b/eclass/ninja-utils.eclass
index ca8d67191dc..5008564dabf 100644
--- a/eclass/ninja-utils.eclass
+++ b/eclass/ninja-utils.eclass
@@ -1,4 +1,4 @@
-# Copyright 1999-2018 Gentoo Foundation
+# Copyright 1999-2021 Gentoo Authors
 # Distributed under the terms of the GNU General Public License v2
 
 # @ECLASS: ninja-utils.eclass
@@ -27,6 +27,15 @@ case ${EAPI:-0} in
*) die "EAPI=${EAPI} is not yet supported" ;;
 esac
 
+# @ECLASS-VARIABLE: NINJA
+# @PRE_INHERIT
+# @DEFAULT_UNSET
+# @DESCRIPTION:
+# Specify a compatible ninja implementation to be used by eninja.
+# At this point only "ninja" and "samu" are supported.
+# The default is set to "ninja".
+: ${NINJA:=ninja}
+
 # @ECLASS-VARIABLE: NINJAOPTS
 # @DEFAULT_UNSET
 # @DESCRIPTION:
@@ -36,6 +45,30 @@ esac
 
 inherit multiprocessing
 
+_ninja_to_use() {
+   case "${NINJA}" in
+   ninja)
+   local ninja=dev-util/${NINJA}
+   ;;
+   samu)
+   local ninja=dev-util/samurai
+   ;;
+   *)
+   eerror "Unknown value for \${NINJA}"
+   die "Value ${NINJA} is not supported"
+   ;;
+   esac
+
+   # if ninja or samurai are enabled but not installed, the build could 
fail
+   # this could happen if they are manu

[gentoo-dev] [PATCH] eclass: Support dev-util/samurai

[Lars Wendler]

From: orbea 

Signed-off-by: Lars Wendler 
---
 eclass/cmake.eclass   | 10 +-
 eclass/meson.eclass   |  4 ++--
 eclass/ninja-utils.eclass | 35 +--
 3 files changed, 40 insertions(+), 9 deletions(-)

diff --git a/eclass/cmake.eclass b/eclass/cmake.eclass
index 4bd09459ea6..c0c22394a31 100644
--- a/eclass/cmake.eclass
+++ b/eclass/cmake.eclass
@@ -118,7 +118,7 @@ case ${CMAKE_MAKEFILE_GENERATOR} in
BDEPEND="sys-devel/make"
;;
ninja)
-   BDEPEND="dev-util/ninja"
+   BDEPEND="|| ( dev-util/ninja dev-util/samurai )"
;;
*)
eerror "Unknown value for \${CMAKE_MAKEFILE_GENERATOR}"
@@ -337,9 +337,9 @@ cmake_src_prepare() {
 
# if ninja is enabled but not installed, the build could fail
# this could happen if ninja is manually enabled (eg. make.conf) but 
not installed
-   if [[ ${CMAKE_MAKEFILE_GENERATOR} == ninja ]] && ! has_version -b 
dev-util/ninja; then
-   eerror "CMAKE_MAKEFILE_GENERATOR is set to ninja, but ninja is 
not installed."
-   die "Please install dev-util/ninja or unset 
CMAKE_MAKEFILE_GENERATOR."
+   if [[ ${CMAKE_MAKEFILE_GENERATOR} == ninja ]] && ! has_version -b 
dev-util/ninja && ! has_version -b dev-util/samurai; then
+   eerror "CMAKE_MAKEFILE_GENERATOR is set to ninja, but neither 
ninja or samurai are installed."
+   die "Please install dev-util/ninja, dev-util/samurai or unset 
CMAKE_MAKEFILE_GENERATOR."
fi
 
local modules_list
@@ -653,7 +653,7 @@ cmake_src_install() {
 
_cmake_check_build_dir
pushd "${BUILD_DIR}" > /dev/null || die
-   DESTDIR="${D}" ${CMAKE_MAKEFILE_GENERATOR} install "$@" ||
+   DESTDIR="${D}" eninja install "$@" ||
die "died running ${CMAKE_MAKEFILE_GENERATOR} install"
popd > /dev/null || die
 
diff --git a/eclass/meson.eclass b/eclass/meson.eclass
index d0ce5adb355..ea02402aa83 100644
--- a/eclass/meson.eclass
+++ b/eclass/meson.eclass
@@ -1,4 +1,4 @@
-# Copyright 2017-2020 Gentoo Authors
+# Copyright 2017-2021 Gentoo Authors
 # Distributed under the terms of the GNU General Public License v2
 
 # @ECLASS: meson.eclass
@@ -55,7 +55,7 @@ if [[ -z ${_MESON_ECLASS} ]]; then
 _MESON_ECLASS=1
 
 MESON_DEPEND=">=dev-util/meson-0.54.0
-   >=dev-util/ninja-1.8.2
+   || ( >=dev-util/ninja-1.8.2 dev-util/samurai )
dev-util/meson-format-array
 "
 
diff --git a/eclass/ninja-utils.eclass b/eclass/ninja-utils.eclass
index ca8d67191dc..3b23d4c002a 100644
--- a/eclass/ninja-utils.eclass
+++ b/eclass/ninja-utils.eclass
@@ -1,4 +1,4 @@
-# Copyright 1999-2018 Gentoo Foundation
+# Copyright 1999-2021 Gentoo Authors
 # Distributed under the terms of the GNU General Public License v2
 
 # @ECLASS: ninja-utils.eclass
@@ -27,6 +27,15 @@ case ${EAPI:-0} in
*) die "EAPI=${EAPI} is not yet supported" ;;
 esac
 
+# @ECLASS-VARIABLE: NINJA
+# @PRE_INHERIT
+# @DEFAULT_UNSET
+# @DESCRIPTION:
+# Specify a compatible ninja implementation to be used by eninja.
+# At this point only "ninja" and "samu" are supported.
+# The default is set to "ninja".
+: ${NINJA:=ninja}
+
 # @ECLASS-VARIABLE: NINJAOPTS
 # @DEFAULT_UNSET
 # @DESCRIPTION:
@@ -36,6 +45,28 @@ esac
 
 inherit multiprocessing
 
+_ninja_to_use() {
+   case "${NINJA}" in
+   ninja)
+   local ninja=dev-util/${NINJA}
+   ;;
+   samu)
+   local ninja=dev-util/samurai
+   ;;
+   *)
+   eerror "Unknown value for \${NINJA}"
+   die "Value ${NINJA} is not supported"
+   ;;
+   esac
+
+   if ! has_version -b $ninja; then
+   eerror "Value ${NINJA} for \${NINJA} is not installed"
+   die "Please install $ninja"
+   fi
+
+   echo ${NINJA}
+}
+
 # @FUNCTION: eninja
 # @USAGE: [...]
 # @DESCRIPTION:
@@ -49,7 +80,7 @@ eninja() {
if [[ -z ${NINJAOPTS+set} ]]; then
NINJAOPTS="-j$(makeopts_jobs) -l$(makeopts_loadavg 
"${MAKEOPTS}" 0)"
fi
-   set -- ninja -v ${NINJAOPTS} "$@"
+   set -- "$(_ninja_to_use)" -v ${NINJAOPTS} "$@"
echo "$@" >&2
"$@" || die "${nonfatal_args[@]}" "${*} failed"
 }
-- 
2.31.1

Re: [gentoo-dev] Two package up for grabs

[Lars Wendler]

On Tue, 23 Mar 2021 12:31:22 +0100 Lars Wendler wrote:

>Hi community,
>
>already quite a while ago, base-system team had decided to no longer
>maintain the following packages:
>
>  sys-fs/reiser4progs (up to date, 3 open bug reports)
>  sys-libs/libaal (required by reiser4progs, no open bug reports)
>
>From those three open bug reports against reiser4progs, two are from
>2013/2014 so they most likely can be closed as OBSOLETE.
>If you are interested in maintaining these packages, just replace
>base-system with you name in metadata.xml and reassign the open bug
>reports to you.
>In case nobody picks the package up in the following seven days, I will
>drop both packages to maintainer-needed.
>
>Thanks and kind regards

I dropped these two packages to maintainer-needed.

Cheers
-- 
Lars Wendler
Gentoo package maintainer
GPG: 21CC CF02 4586 0A07 ED93  9F68 498F E765 960E 9B39


pgpUn55iKBRbl.pgp
Description: Digitale Signatur von OpenPGP

[gentoo-dev] Two package up for grabs

[Lars Wendler]

Hi community,

already quite a while ago, base-system team had decided to no longer
maintain the following packages:

  sys-fs/reiser4progs (up to date, 3 open bug reports)
  sys-libs/libaal (required by reiser4progs, no open bug reports)

From those three open bug reports against reiser4progs, two are from
2013/2014 so they most likely can be closed as OBSOLETE.
If you are interested in maintaining these packages, just replace
base-system with you name in metadata.xml and reassign the open bug
reports to you.
In case nobody picks the package up in the following seven days, I will
drop both packages to maintainer-needed.

Thanks and kind regards
-- 
Lars Wendler
Gentoo package maintainer
GPG: 21CC CF02 4586 0A07 ED93  9F68 498F E765 960E 9B39


pgph4FbK38d2s.pgp
Description: Digitale Signatur von OpenPGP

Re: [gentoo-dev] timezone configuration - why copying, not symlinking /etc/localtime ?

[Lars Wendler]

On Mon, 22 Mar 2021 09:59:11 +0100 Andreas Sturmlechner wrote:

>On Sonntag, 21. März 2021 08:58:34 CET James Le Cuirot wrote:
>> How about making emerge --config dynamic, copying if it's on a
>> different partition and symlinking if it's not? You can't accurately
>> determine the use of an initramfs but at least this is closer to what
>> we want.
>
>We will not be able to carry the revert for Qt5Core forever. I suspect
>it will be gone with Qt6, and then all we can do is ewarn users that
>their clock will be broken if their localtime is not a symlink.
>
>Keeping it as a file would mean convincing upstream(s) that the
>symlink is a systemd-ism, not a standard.
>
>Regards

With enough motivation we can carry that revert for a very long time. I
know that because I still carry reverts in my udev packages from when
it was devoured by systemd.

-- 
Lars Wendler
Gentoo package maintainer
GPG: 21CC CF02 4586 0A07 ED93  9F68 498F E765 960E 9B39


pgpAZvyBvjeAP.pgp
Description: Digitale Signatur von OpenPGP

Re: [gentoo-dev] New project: binhost

[Lars Wendler]

On Wed, 10 Feb 2021 19:57:48 +0200 Andreas K. Hüttel wrote:

>Hi all, 
>
>I'm announcing a new project here - "binhost"
>
>"The Gentoo Binhost project aims to provide readily installable,
>precompiled packages for a subset of configurations, via central
>binary package hosting. Currently we are still in the conceptual
>planning stage. "
>
>https://wiki.gentoo.org/wiki/Project:Binhost
>
>If you're interested in helping out, feel free to add yourself on the
>wiki page.
>
>Note that I see actually *building* the packages not as the central
>point of the project (that could be e.g. a side effect of a
>tinderbox). I'm more concerned about
>* what configurations should we use
>* what portage features are still needed or need improvements (e.g.
>binpkg signing and verification)
>* how should hosting look like
>* and how we can test this on a limited scale before it goes "into
>production"
>* ...
>
>Comments, ideas, flamebaits? :D
>
>Cheers, 
>Andreas
>

It would be great to improve portage speed with handling binpkgs. I
already have my own binhost for a couple of Gentoo systems and even
though these systems don't have to compile anything themselves,
installing ~100 to ~200 binpkgs takes way more than an hour of
installation time. Arch Linux' pacman only takes a fraction of this
time for the very same task.
I know that I compare apples with pears here but even reducing the
current portage time by 50% would be a huge improvement.

Cheers

-- 
Lars Wendler
Gentoo package maintainer
GPG: 21CC CF02 4586 0A07 ED93  9F68 498F E765 960E 9B39


pgpjVA9jqqLPQ.pgp
Description: Digitale Signatur von OpenPGP

Re: [gentoo-dev] [RFC] Dealing with global /usr/bin/libtool use vs CC/CXX etc.

[Lars Wendler]

On Mon, 11 Jan 2021 18:36:31 + Peter Stuge wrote:

>Jaco Kroon wrote:
>> > I can think of two ways of solving it:
>> >
>> > 1. We could patch system-installed libtool to respect environment
>> >
>> > 2. We could regenerate libtool and force local instance of libtool
>> > in the packages needing it.  
>> 
>> 3.  Have it always use some fixed compiler somewhere (ie, compile it
>>  
>
>4. Make gcc-config regenerate libtool, otherwise as 2.
>
>
>//Peter
>

5.) Try to replace GNU libtool with sys-devel/slibtool

slibtool is aimed to be a drop-in replacement although at the current
state it still has a couple of hiccups. I've created a tracker bug at
[1] to track all issues arising from using slibtool instead of GNU
libtool.

Cheers
Lars

[1] https://bugs.gentoo.org/765709
-- 
Lars Wendler
Gentoo package maintainer
GPG: 21CC CF02 4586 0A07 ED93  9F68 498F E765 960E 9B39


pgpC2GthIfa8f.pgp
Description: Digitale Signatur von OpenPGP

Re: [gentoo-dev] Packages & projects up for grabs due to jer's retirement

[Lars Wendler]

On Tue, 03 Nov 2020 22:32:11 +0100 Michał Górny wrote:

>Hi.
>
>The following projects have no members right now:
>
>https://wiki.gentoo.org/wiki/Project:Debian_Tools
>
>Additionally, the following packages are looking for a new maintainer:
>

I'll take these:

>app-admin/whowatch
>net-ftp/lftp
>net-misc/putty


And I am interested in these as well in case nobody else takes them:

>net-dns/libidn
>net-dns/libidn2
>net-misc/youtube-dl
>x11-libs/libvdpau
>x11-misc/vdpauinfo


Cheers
Lars
-- 
Lars Wendler
Gentoo package maintainer
GPG: 21CC CF02 4586 0A07 ED93  9F68 498F E765 960E 9B39


pgpThwcHLJdTA.pgp
Description: Digitale Signatur von OpenPGP

Re: [gentoo-dev] Python 2 cleanup update

[Lars Wendler]

Hi folks,

On Sun, 27 Sep 2020 19:45:22 +0200 Michał Górny wrote:

>Hello, everyone.
>
>TL;DR: we're nearing the total annihilation of Python 2 software
>in Gentoo.  Most users could safely disable py2 USE flags today.
>Python 2 vulns have been patched recently, the interpreter and a few
>packages using Python at build time (with no deps) will stay.  Should
>we change PYTHON_TARGETS now, or wait some more and just annihilate
>the py2 flag from all packages?
>
>
>Long version:
>
>We're reached the point where the majority of packages relying on py2
>have either been ported to py3, removed or masked for removal.
>As a result, I've been able to eliminate python2_7 target from the vast
>majority of dev-python/* packages.  On their next system upgrade, our
>users are going to notice most of Python 2.7 modules gone from their
>systems.
>
>However, because of their reverse dependencies a few packages can't
>lose their py2.7-iness, and therefore are going to block depcleaning
>Python 2.7 for now.  These include old versions of setuptools, numpy,
>pillow, as well as all versions of cython, nose, pykerberos, pyyaml
>and their dependencies.  The major blockers for them are:
>
>- dev-lang/gdl (py entirely optional but the package itself is
>seriously broken)
>
>- dev-db/mongodb (py3 version was just stabilized, need to decide how
>to clean old versions up)
>
>- games-engines/renpy (no py3 version yet)
>
>- media-tv/kodi (py3 version in alpha)
>
>We plan to have these packages fixed or removed by the deadline. 
>
>
>However, we already know that there are some packages that use Python 2
>at build time and that will keep requiring it past the deadline.
>The initial list includes:
>
>- dev-python/pypy* (TODO: need to figure bootstrap out)
>
>- dev-lang/spidermonkey, www-client/seamonkey, www-client/firefox...
>(thank you, Mozilla)

I've already talked to seamonkey upstream about this and I was told
that they will shift to python3 with seamonkey-2.57 release (which will
be the followup release to the 2.53.x series) but they could not tell
me even an approximate release date.
seamonkey upstream only has loose bindings to Mozilla (they still use
Mozilla's bugzilla but their development repos are now on gitlab) and
their man-power is quite low so I do not expect 2.57 releases before
the year 2021. I hope we can keep dev-lang/python:2.7 for the time
being.

>- www-client/chromium, dev-qt/qtwebengine... (thank you, Google)
>
>Sadly, the big corps are too busy improving their spying functionality
>and creating NIH programming languages to take care of such minor
>matters as cleaning up.
>
>The general rule is that py2.7 may remain in packages that use it
>at build time only (i.e. don't install anything depending on Python)
>and have no dependencies on Python packages (i.e. don't require any
>other packages to install py2.7 modules).  Or to put it otherwise,
>python-r1 and python-single-r1 will lose py2.7 support entirely, while
>python-any-r1 will retain minimal support without dependencies.
>
>
>This also implies that we're going to keep Python 2.7 itself for as
>long as necessary, and patch it if possible.  I should take this
>opportunity to remind you that it's quite possible that the
>interpreter itself has unknown vulnerabilities.  Only recently I've
>backported two sec fixes from Python 3 which no other distribution
>(including the one promising paid support for Python 2 for next years)
>or upstream (including all these boasting that they're going to
>maintain Python 2 themselves) has even noticed (to the best of my
>knowledge).
>
>
>An open question is whether we should remove python2_7 from
>PYTHON_TARGETS now.  If we do that, it will permit the vast majority of
>Gentoo users to depclean Python 2.7 today, independently of how long
>the maintainer of renpy is going to block it, with only a few users
>having to enable the flag manually.  However, doing this makes sense
>only if we're really going to delay the impeding doom long.
>
>I will probably prepare an updated news item for Python 2.7 removal,
>to replace the one from February with the updated plan, current
>information and helpful tips.
>
>
>Finally, I would like to thank all the helpful package maintainers,
>arch teams and other developers who have made this possible.
>


Cheers
-- 
Lars Wendler
Gentoo package maintainer
GPG: 21CC CF02 4586 0A07 ED93  9F68 498F E765 960E 9B39


pgpmIfQK493qK.pgp
Description: Digitale Signatur von OpenPGP

Re: [gentoo-dev] IPython 7.17 drops Python 3.6 support AKA upgrade reminder

[Lars Wendler]

On Sat, 01 Aug 2020 12:19:13 +0200 Michał Górny wrote:

>On Sat, 2020-08-01 at 06:15 -0400, Rich Freeman wrote:
>> On Sat, Aug 1, 2020 at 3:29 AM Michał Górny 
>> wrote:
>> > I would like to take this as an opportunity to remind you to port
>> > your packages to Python 3.7 and 3.8.  According to our timeline
>> > [1], packages that are not ported by the end of the year are going
>> > to be last rited. We would also like to switch to 3.8 in December.
>> > 
>> > [1]
>> > https://wiki.gentoo.org/wiki/Project:Python/Implementations#Implementation_support_timeline
>> 
>> So, has anybody given thought to publishing a list of packages that
>> still need to be updated, including their maintainers?
>> 
>> Or perhaps filing bugs?
>> 
>> Or is the plan to go ahead and watching nothing happen for the next
>> few months, then start masking hundreds of packages, and then watch
>> devs scramble to fix problems they didn't realize existed?
>> 
>
>Or perhaps you'd like to help out instead of wasting your own
>and everybody else's time on talking?
>

Honestly... seeing such replies from you or knowing that you do not
hesitate to hit other devs with your full QA deputy power once they
dare to touch python packages is not motivating in any way to even
consider helping you.

Have a nice day...
-- 
Lars Wendler
Gentoo package maintainer
GPG: 21CC CF02 4586 0A07 ED93  9F68 498F E765 960E 9B39


pgpp3XGWb__M7.pgp
Description: Digitale Signatur von OpenPGP

Re: [gentoo-dev] Graphics Project disbanded [pkgs up for grabs]

[Lars Wendler]

On Sun, 07 Jun 2020 02:05:56 +0300 Andreas K. Hüttel wrote:

>OK so if you really want to go through with this then I'll take these.
>
>> media-gfx/album
>> media-gfx/enblend
>> media-gfx/exiv2
>> media-gfx/gphoto2
>> media-gfx/hugin
>> media-gfx/imagemagick
>> media-gfx/jpeg2ps
>> media-gfx/jhead
>> media-gfx/luminance-hdr
>> media-gfx/pngquant
>> media-libs/lensfun
>> media-libs/libgphoto2
>
>That said, I think the basic action is in this case pretty
>unproductive. We now have a large number of central libraries
>maintainer-needed (libpng, jpeg, tiff, ...) which would really merit a
>team...
>
>

Just for the record, media-libs/libpng belongs to base-system team for
years. I do not even remember it ever belonged to graphics team.
So it's obviously not up for grabs :)

Cheers
Lars

-- 
Lars Wendler
Gentoo package maintainer
GPG: 21CC CF02 4586 0A07 ED93  9F68 498F E765 960E 9B39


pgpVM0tuzLE2x.pgp
Description: Digitale Signatur von OpenPGP

Re: [gentoo-dev] RFC: Gentoo Identity Provider

[Lars Wendler]

On Wed, 20 May 2020 00:21:37 -0700 Alec Warner wrote:

>On Tue, May 19, 2020 at 1:23 AM Lars Wendler 
>wrote:
>
>> Hi Alec,
>>
>> On Mon, 18 May 2020 18:42:24 -0700 Alec Warner wrote:
>>
>> >TL;DR: What if we launched id.gentoo.org, an identity provider that
>> >provides authentication for Gentoo properties? Basically, 1
>> >username / password for wiki, bugs, email, forums, and any other
>> >http service[0][1].
>> >
>> >Today Gentoo has numerous systems that mostly work in a segmented
>> >way.
>> >
>> > - To connect to hosts, we use ssh keys.
>> > - Git is authenticated via ssh keys.
>> > - Email uses LDAP passwords.
>> > - Bugzilla has its own identities, with their own passwords.
>> > - Wiki is separate, with its own passwords.
>> > - Forums are separate.
>> > - Infra has an additional 4 systems that use separate credentials.
>> >
>> >Some applications support 2FA (such as wiki.)
>> >Some applications do not support 2FA.
>> >Applications that require 2FA have a configuration for each app, so
>> >you have N configurations.
>> >
>> >If we configured id.gentoo.org you would have 1 identity across all
>> >gentoo properties.
>> >
>> >Is this a thing people are interested in?
>> >
>> >[0] It's unlikely operations for git via ssh would change in this
>> >rollout. [1] Its unclear if the scope is "gentoo developers" or "any
>> >community member." The former have LDAP accounts and @gentoo.org
>> >email addresses and so we can manage them easily; managing 1000s of
>> >other accounts in the IDP remains to be seem.
>>
>> In case 2FA won't be mandatory I find this a good idea.
>>
>
>2FA is definitely a reason to deploy software like keycloak, but in the
>first rollout I don't expect to enforce 2FA. Ideally we would deploy
>the U2F support in keycloak and then, similar to our earlier program,
>offer discounted or free u2f devices for Gentoo developers; this would
>likely be on a 1-2 year timeframe.
>
>Is there some reason you don't want to use 2FA?
>
>-A

Well, I haven't found any 2FA solution that isn't a PITA to use.
Especially Nitrokey is not easily useable for 2FA. And having some OTP
or U2F software on my mobile phone is a no-go.
I know about the value of 2FA and I use it in some places but I find it
not being the perfect solution for everything. 

>>
>> Kind regards
>> --
>> Lars Wendler
>> Gentoo package maintainer
>> GPG: 21CC CF02 4586 0A07 ED93  9F68 498F E765 960E 9B39
>>


Cheers
-- 
Lars Wendler
Gentoo package maintainer
GPG: 21CC CF02 4586 0A07 ED93  9F68 498F E765 960E 9B39


pgpuB4K6yaZYS.pgp
Description: Digitale Signatur von OpenPGP

Re: [gentoo-dev] RFC: Gentoo Identity Provider

[Lars Wendler]

Hi Alec,

On Mon, 18 May 2020 18:42:24 -0700 Alec Warner wrote:

>TL;DR: What if we launched id.gentoo.org, an identity provider that
>provides authentication for Gentoo properties? Basically, 1 username /
>password for wiki, bugs, email, forums, and any other http
>service[0][1].
>
>Today Gentoo has numerous systems that mostly work in a segmented way.
>
> - To connect to hosts, we use ssh keys.
> - Git is authenticated via ssh keys.
> - Email uses LDAP passwords.
> - Bugzilla has its own identities, with their own passwords.
> - Wiki is separate, with its own passwords.
> - Forums are separate.
> - Infra has an additional 4 systems that use separate credentials.
>
>Some applications support 2FA (such as wiki.)
>Some applications do not support 2FA.
>Applications that require 2FA have a configuration for each app, so you
>have N configurations.
>
>If we configured id.gentoo.org you would have 1 identity across all
>gentoo properties.
>
>Is this a thing people are interested in?
>
>[0] It's unlikely operations for git via ssh would change in this
>rollout. [1] Its unclear if the scope is "gentoo developers" or "any
>community member." The former have LDAP accounts and @gentoo.org email
>addresses and so we can manage them easily; managing 1000s of other
>accounts in the IDP remains to be seem.

In case 2FA won't be mandatory I find this a good idea.

Kind regards
-- 
Lars Wendler
Gentoo package maintainer
GPG: 21CC CF02 4586 0A07 ED93  9F68 498F E765 960E 9B39


pgpL2XtvxjHG4.pgp
Description: Digitale Signatur von OpenPGP

[gentoo-dev] forthcoming app-admin/sudo-1.9.0 - time to place your feature requests now!

[Lars Wendler]

Hi list,

sudo-1.9.0 is around the corner. Right now 1.9.0_rc2 is available and
provides new python bindings as well as a sudo_logsrvd. If you are
interested in the latter feature, add

  =app-admin/sudo-1.9.0_rc* **

to your /etc/portage/package.accept_keywords and give the release
candidate a try. Unfortunately due to lack of time I haven't added an
openrc init script for the logsrvd to the package left alone the python
support because that requires messing with our huge python eclasses
which I always feel overwhelmed in using them. So for now I've disabled
building of python bindings in the rc ebuild but I'd love to see
patches for adding thorough python support through our python
eclass(es) to the ebuild.
I'd also appreciate if people could provide openrc init scripts for the
logsrvd as well as systemd unit files.

Having a brand new feature release soon to come, this is also the
perfect time for users to request possibly missing features for our
sudo ebuild. So if you think the new version could also benefit from
some feature our current sudo ebuilds don't have, feel free to speak up
now.

Thanks
Lars (Gentoo base-system team lead)

-- 
Lars Wendler
Gentoo package maintainer
GPG: 21CC CF02 4586 0A07 ED93  9F68 498F E765 960E 9B39


pgpCG0FmZWUWN.pgp
Description: Digitale Signatur von OpenPGP

Re: [gentoo-dev] Re: [gentoo-dev-announce] Last rites: sci-astronomy/celestia

[Lars Wendler]

On Wed, 22 Jan 2020 22:48:22 +0100 Pacho Ramos wrote:

>El mié, 22-01-2020 a las 10:18 +0100, Lars Wendler escribió:
>> On Wed, 22 Jan 2020 00:56:48 +0100 David Seifert wrote:
>> 
>> > # David Seifert  (2020-01-21)
>> > # All released versions depend on EOL gtkglext, no revdeps.
>> > # Bug #644334, #694834. Removal in 30 days.
>> > sci-astronomy/celestia
>> 
>> I've adjusted the mask to not cover the live ebuild. I am still
>> actively maintaining it and the live ebuild already dropped gtkglext
>> dependency. Once a new release was rolled I will add that to Gentoo.
>> The old releases can go. They're way too old and even don't run
>> anymore with recent nvidia display drivers.
>> 
>> Lars
>> 
>
>Why not provide a git snapshot? At least in Mageia they are relying in
>one snapshot from the end of Dec 2019 
>
>Thanks

Hi Pacho,

once I recover from being sick I can do that.

Cheers
Lars

-- 
Lars Wendler
Gentoo package maintainer
GPG: 21CC CF02 4586 0A07 ED93  9F68 498F E765 960E 9B39


pgpgmSwTnO6NJ.pgp
Description: Digitale Signatur von OpenPGP

[gentoo-dev] Re: [gentoo-dev-announce] Last rites: sci-astronomy/celestia

[Lars Wendler]

On Wed, 22 Jan 2020 00:56:48 +0100 David Seifert wrote:

># David Seifert  (2020-01-21)
># All released versions depend on EOL gtkglext, no revdeps.
># Bug #644334, #694834. Removal in 30 days.
>sci-astronomy/celestia

I've adjusted the mask to not cover the live ebuild. I am still
actively maintaining it and the live ebuild already dropped gtkglext
dependency. Once a new release was rolled I will add that to Gentoo.
The old releases can go. They're way too old and even don't run
anymore with recent nvidia display drivers.

Lars

-- 
Lars Wendler
Gentoo package maintainer
GPG: 21CC CF02 4586 0A07 ED93  9F68 498F E765 960E 9B39


pgpWFeujn3Qre.pgp
Description: Digitale Signatur von OpenPGP

Re: [gentoo-dev] crypto@ packages up for grabs

[Lars Wendler]

On Thu, 9 Jan 2020 09:50:29 +0100 Kristian Fiskerstrand wrote:

>On 09.01.2020 09:09, Lars Wendler wrote:
>> On Thu, 9 Jan 2020 00:16:13 +0300 Mikle Kolyada wrote:
>> 
>>> These are up for grabs due to the crypto@ project being disbanded.
>>>
>...
>
>> 
>> I've taken these… but I'd appreciate it if someone wants to
>> co-maintain them with me.
>
>I can join on
>>> app-crypt/gpgme
>>> dev-libs/libassuan
>>> dev-libs/libgpg-error
>>> dev-libs/libksba
>

That would be great. Please do.

Lars

-- 
Lars Wendler
Gentoo package maintainer
GPG: 21CC CF02 4586 0A07 ED93  9F68 498F E765 960E 9B39


pgpBqhl9B3I2w.pgp
Description: Digitale Signatur von OpenPGP

Re: [gentoo-dev] crypto@ packages up for grabs

[Lars Wendler]

On Thu, 9 Jan 2020 00:16:13 +0300 Mikle Kolyada wrote:

>These are up for grabs due to the crypto@ project being disbanded.
>
>app-crypt/gpa
>app-crypt/gpgme
>dev-libs/libassuan
>dev-libs/libgpg-error
>dev-libs/libksba
>dev-libs/libp11
>sys-auth/pam_p11

I've taken these… but I'd appreciate it if someone wants to
co-maintain them with me.

Lars

-- 
Lars Wendler
Gentoo package maintainer
GPG: 21CC CF02 4586 0A07 ED93  9F68 498F E765 960E 9B39


pgpONVC2RGjOD.pgp
Description: Digitale Signatur von OpenPGP

Re: [gentoo-dev] crypto@ packages up for grabs

[Lars Wendler]

On Thu, 9 Jan 2020 00:16:13 +0300 Mikle Kolyada wrote:

>These are up for grabs due to the crypto@ project being disbanded.
>
>dev-libs/libtasn1
>dev-libs/nettle

Since base-system already took net-libs/gnutls before this grab mail was
sent, we also took libtasn1 and nettle because gnutls (R)DEPENDs on
both.

Lars

-- 
Lars Wendler
Gentoo package maintainer
GPG: 21CC CF02 4586 0A07 ED93  9F68 498F E765 960E 9B39


pgp6KHFvX489y.pgp
Description: Digitale Signatur von OpenPGP

[gentoo-dev] Packages up for grabs

[Lars Wendler]

Hi,

I need to reduce my package count a bit so here are some packages I
wish to no longer maintain:


app-mobilephone/heimdall
dev-util/appdata-tools
dev-vcs/mercurial
dev-vcs/subversion
dev-vcs/tortoisehg
net-libs/libotr
net-misc/fatrat
net-wireless/gobi_loader


If you want to take over maintenance, just replace my email address and
name with yours in the metadata file.
Otherwise I will drop the packages to maintainer-needed in about a week
after I've sent this mail.

Cheers
Lars

-- 
Lars Wendler
Gentoo package maintainer
GPG: 21CC CF02 4586 0A07 ED93  9F68 498F E765 960E 9B39


pgpgezNZPAI24.pgp
Description: Digitale Signatur von OpenPGP

[gentoo-dev] RFC: UID/GID assignment for cron (16)

[Lars Wendler]

I would like to reserve UID/GID 16 for cron which is being used by
sys-process/cronie

This is the historical UID/GID for cron user in Gentoo.
Arch is using UID/GID 22 while Fedora does not have such a user/group.

You can find the commits (among others) for possible review here:
https://github.com/Polynomial-C/gentoo/commits/accts-cronie

-- 
Lars Wendler
Gentoo package maintainer
GPG: 21CC CF02 4586 0A07 ED93  9F68 498F E765 960E 9B39


pgpm9Iwg6tq7o.pgp
Description: Digitale Signatur von OpenPGP

[gentoo-dev] RFC: GID assignment for crontab (44)

[Lars Wendler]

I would like to reserve GID 44 for crontab which is being used by
sys-process/cronie. That group does neither exist in Arch nor in
Fedora, so I took the liberty to choose one GID that I can memorize
easily :)

You can find the commit (among others) for possible review here:
https://github.com/Polynomial-C/gentoo/commits/accts-cronie

-- 
Lars Wendler
Gentoo package maintainer
GPG: 21CC CF02 4586 0A07 ED93  9F68 498F E765 960E 9B39


pgpiyaoJqZxnF.pgp
Description: Digitale Signatur von OpenPGP

Re: [gentoo-dev] RFC: UID/GID assignment for apache (81)

[Lars Wendler]

On Tue, 13 Aug 2019 14:43:11 -0400 Michael Orlitzky wrote:

>On 8/13/19 2:30 PM, Lars Wendler wrote:
>> 
>> If we leave ACCT_USER_HOME empty HOME will be set to
>> /dev/null for apache user. I don't know if this is what we want.
>I'm not 100% sure either, but it's pretty likely that if an unwritable
>root-owned home directory would work, then so would /dev/null.
>
>(It works fine on our web servers, but nothing is actually running as
>"apache" on them.)
>

I'm not really sure what the impact might be. I have only one single
apache installation and that is a productive one. I do not want to mess
with that installation.

Lars

-- 
Lars Wendler
Gentoo package maintainer
GPG: 21CC CF02 4586 0A07 ED93  9F68 498F E765 960E 9B39


pgpuXDFFFkNsa.pgp
Description: Digitale Signatur von OpenPGP

Re: [gentoo-dev] RFC: UID/GID assignment for apache (81)

[Lars Wendler]

On Tue, 13 Aug 2019 14:21:29 -0400 Michael Orlitzky wrote:

>On 8/13/19 1:53 PM, Lars Wendler wrote:
>> 
>> thanks for the review. I've force-pushed the acct-user/apache commit
>> with ACCT_USER_HOME_OWNER being set to root:root.
>> 
>
>Is there any benefit to
>
>  ACCT_USER_HOME=/var/www
>  ACCT_USER_HOME_OWNER=root:root
>
>versus
>
>  keepdir /var/www
>
>in the eclass?

If we leave ACCT_USER_HOME empty HOME will be set to
/dev/null for apache user. I don't know if this is what we want.

>I think root:root is correct for /var/www, but setting it explicitly
>will clobber any existing permissions that the administrator or other
>packages have set. For example, if my web developers have write access
>to /var/www via group membership, then when I install acct-user/apache,
>/var/www will get set back to root:root with mode 755 and they'll be
>locked out temporarily.
>

Lars

-- 
Lars Wendler
Gentoo package maintainer
GPG: 21CC CF02 4586 0A07 ED93  9F68 498F E765 960E 9B39




pgpBT1OmrG_18.pgp
Description: Digitale Signatur von OpenPGP

Re: [gentoo-dev] RFC: UID/GID assignment for apache (81)

[Lars Wendler]

Hi Michael,

On Tue, 13 Aug 2019 13:39:34 -0400 Michael Orlitzky wrote:

>On 8/13/19 1:14 PM, Lars Wendler wrote:
>> I would like to reserve UID/GID 81 for apache (www-servers/apache).
>> 
>> This is the historical UID/GID for apache user in Gentoo.
>> Fedora and RedHat use UID/GID 48. Arch Linux has no
>> "apache" user but a "http" user with UID/GID 33 (which is already
>> reserved in Gentoo).
>> 
>> Here are the commits for possible review:
>> https://github.com/Polynomial-C/gentoo/commits/accts-apache
>> 
>
>By setting /var/www as apache's home directory, we're going to wind up
>with /var/www being owned by apache:root. That's not quite right, for a
>couple reasons:
>
>  * The anonymous website user shouldn't be able to delete the entire
>web hierarchy using e.g. a wordpress exploit.
>
>  * Every other web server wants to share /var/www, too.
>
>For example, www-servers/cherokee wants /var/www to be the home
>directory for the cherokee user, as does www-servers/ocsigenserver.
>Hiawatha stores stuff under /var/www/hiawatha, and just about everybody
>uses /var/www/localhost for the default vhost.
>
>Thinking ahead -- would anything bad happen if we left the home
>directory at its default? I don't think our default apache config needs
>to own /var/www for any reason, but I'm not certain.
>

thanks for the review. I've force-pushed the acct-user/apache commit
with ACCT_USER_HOME_OWNER being set to root:root.

Lars
-- 
Lars Wendler
Gentoo package maintainer
GPG: 21CC CF02 4586 0A07 ED93  9F68 498F E765 960E 9B39


pgpxFTpbrWbP2.pgp
Description: Digitale Signatur von OpenPGP

[gentoo-dev] RFC: UID/GID assignment for apache (81)

[Lars Wendler]

I would like to reserve UID/GID 81 for apache (www-servers/apache).

This is the historical UID/GID for apache user in Gentoo.
Fedora and RedHat use UID/GID 48. Arch Linux has no
"apache" user but a "http" user with UID/GID 33 (which is already
reserved in Gentoo).

Here are the commits for possible review:
https://github.com/Polynomial-C/gentoo/commits/accts-apache

-- 
Lars Wendler
Gentoo package maintainer
GPG: 21CC CF02 4586 0A07 ED93  9F68 498F E765 960E 9B39


pgpwEDbny_POL.pgp
Description: Digitale Signatur von OpenPGP

[gentoo-dev] RFC: UID/GID assignment for pdnsd (184)

[Lars Wendler]

I would like to reserve UID/GID 184 for pdnsd (net-dns/pdnsd).

This is the same ID used by Arch Linux.

Here are the commits for possible review:
https://github.com/Polynomial-C/gentoo/commits/accts-pdnsd
-- 
Lars Wendler
Gentoo package maintainer
GPG: 21CC CF02 4586 0A07 ED93  9F68 498F E765 960E 9B39


pgp3NUwZtiLGx.pgp
Description: Digitale Signatur von OpenPGP

[gentoo-dev] RFC: UID/GID assignment for nsd (223)

[Lars Wendler]

I would like to reserve UID/GID 223 for nsd (net-dns/nsd).

Neither Arch Linux nor Fedora nor RedHat claim that UID/GID.

Here are the commits for possible review:
https://github.com/Polynomial-C/gentoo/commits/accts-nsd
-- 
Lars Wendler
Gentoo package maintainer
GPG: 21CC CF02 4586 0A07 ED93  9F68 498F E765 960E 9B39


pgpQCWhjdsgMN.pgp
Description: Digitale Signatur von OpenPGP

[gentoo-dev] RFC: UID/GID assignment for murmurd (122)

[Lars Wendler]

I would like to reserve UID/GID 122 for murmurd (media-sound/murmur).

This is the same ID used by Arch Linux.

-- 
Lars Wendler
Gentoo package maintainer
GPG: 21CC CF02 4586 0A07 ED93  9F68 498F E765 960E 9B39


pgpEco463JumM.pgp
Description: Digitale Signatur von OpenPGP

[gentoo-dev] RFC: UID/GID assignment for msmtpd (222)

[Lars Wendler]

I would like to reserve UID/GID 222 for msmtpd (mail-mta/msmtp).

Neither Arch Linux nor Fedora nor RedHat claim that UID/GID.

-- 
Lars Wendler
Gentoo package maintainer
GPG: 21CC CF02 4586 0A07 ED93  9F68 498F E765 960E 9B39


pgp21YdmDozUH.pgp
Description: Digitale Signatur von OpenPGP

[gentoo-dev] RFC: UID/GID assignment for gkrellmd (221)

[Lars Wendler]

I would like to reserve UID/GID 221 for gkrellmd (app-admin/gkrellm).

Neither Arch Linux nor Fedora nor RedHat claim that UID/GID.

-- 
Lars Wendler
Gentoo package maintainer
GPG: 21CC CF02 4586 0A07 ED93  9F68 498F E765 960E 9B39


pgpTMOp86BRjk.pgp
Description: Digitale Signatur von OpenPGP

[gentoo-dev] RFC: UID/GID assignment for uptimed (220)

[Lars Wendler]

I would like to reserve UID/GID 220 for uptimed (app-misc/uptimed).

Neither Arch Linux nor Fedora nor RedHat claim that UID/GID.

-- 
Lars Wendler
Gentoo package maintainer
GPG: 21CC CF02 4586 0A07 ED93  9F68 498F E765 960E 9B39


pgpj_flJvoCv0.pgp
Description: Digitale Signatur von OpenPGP

Re: [gentoo-dev] [PATCH] acct-group/uptimed: Synced GID with uptimed user's UID

[Lars Wendler]

On Tue, 06 Aug 2019 19:01:42 +0200 Ulrich Mueller wrote:

>>>>>> On Tue, 06 Aug 2019, Lars Wendler wrote:
> 
>> -ACCT_GROUP_ID=210
>> +ACCT_GROUP_ID=103
>
>Note that 103 will collide with Arch's "minio" user and group. We have
>that package too, as net-fs/minio.
>
>Ulrich

Alright... screw these patches, I am going to write RFCs like the one
for polkitd from Mike.

Lars

-- 
Lars Wendler
Gentoo package maintainer
GPG: 21CC CF02 4586 0A07 ED93  9F68 498F E765 960E 9B39


pgpnutt48YGmu.pgp
Description: Digitale Signatur von OpenPGP

Re: [gentoo-dev] [PATCH 1/4] acct-group/gkrellmd: Initial commit

[Lars Wendler]

On Tue, 06 Aug 2019 19:04:14 +0200 Ulrich Mueller wrote:

>>>>>> On Tue, 06 Aug 2019, Lars Wendler wrote:  
>
>> +ACCT_GROUP_ID=104  
>
>Collides with Arch's nm-openconnect (which we have as
>net-vpn/networkmanager-openconnect).

Alright... screw these patches, I am going to write RFCs like the one
for polkitd from Mike.

Lars

-- 
Lars Wendler
Gentoo package maintainer
GPG: 21CC CF02 4586 0A07 ED93  9F68 498F E765 960E 9B39


pgpT6KTiGS3Es.pgp
Description: Digitale Signatur von OpenPGP

[gentoo-dev] [PATCH 4/4] app-admin/gkrellm: Synced live ebuild

[Lars Wendler]

Package-Manager: Portage-2.3.71, Repoman-2.3.17
Signed-off-by: Lars Wendler 
---
 app-admin/gkrellm/gkrellm-.ebuild | 9 +++--
 1 file changed, 3 insertions(+), 6 deletions(-)

diff --git a/app-admin/gkrellm/gkrellm-.ebuild 
b/app-admin/gkrellm/gkrellm-.ebuild
index d205ffcda8a..c54518d2636 100644
--- a/app-admin/gkrellm/gkrellm-.ebuild
+++ b/app-admin/gkrellm/gkrellm-.ebuild
@@ -3,7 +3,7 @@
 
 EAPI=7
 
-inherit desktop multilib user systemd toolchain-funcs
+inherit desktop multilib systemd toolchain-funcs
 
 MY_P="${P/_/-}"
 
@@ -21,6 +21,8 @@ SLOT="2"
 IUSE="gnutls hddtemp libressl lm_sensors nls ntlm ssl kernel_FreeBSD X"
 
 RDEPEND="
+   acct-group/gkrellmd
+   acct-user/gkrellmd
dev-libs/glib:2
hddtemp? ( app-admin/hddtemp )
ssl? (
@@ -143,8 +145,3 @@ src_install() {
 
einstalldocs
 }
-
-pkg_preinst() {
-   enewgroup gkrellmd
-   enewuser gkrellmd -1 -1 -1 gkrellmd
-}
-- 
2.23.0.rc1

[gentoo-dev] [PATCH 3/4] app-admin/gkrellm: Revbump replacing user eclass

[Lars Wendler]

with gkrellmd group/user packages.

Package-Manager: Portage-2.3.71, Repoman-2.3.17
Signed-off-by: Lars Wendler 
---
 app-admin/gkrellm/gkrellm-2.3.11-r1.ebuild | 147 +
 1 file changed, 147 insertions(+)
 create mode 100644 app-admin/gkrellm/gkrellm-2.3.11-r1.ebuild

diff --git a/app-admin/gkrellm/gkrellm-2.3.11-r1.ebuild 
b/app-admin/gkrellm/gkrellm-2.3.11-r1.ebuild
new file mode 100644
index 000..c54518d2636
--- /dev/null
+++ b/app-admin/gkrellm/gkrellm-2.3.11-r1.ebuild
@@ -0,0 +1,147 @@
+# Copyright 1999-2019 Gentoo Authors
+# Distributed under the terms of the GNU General Public License v2
+
+EAPI=7
+
+inherit desktop multilib systemd toolchain-funcs
+
+MY_P="${P/_/-}"
+
+DESCRIPTION="Single process stack of various system monitors"
+HOMEPAGE="http://www.gkrellm.net/;
+if [[ "${PV}" ==  ]] ; then
+   inherit git-r3
+   EGIT_REPO_URI="https://git.srcbox.net/gkrellm;
+else
+   SRC_URI="http://gkrellm.srcbox.net/${MY_P}.tar.bz2;
+   KEYWORDS="~alpha ~amd64 ~arm ~arm64 ~hppa ~ia64 ~mips ~ppc ~ppc64 
~sparc ~x86 ~x86-fbsd ~amd64-linux ~x86-linux"
+fi
+LICENSE="GPL-3"
+SLOT="2"
+IUSE="gnutls hddtemp libressl lm_sensors nls ntlm ssl kernel_FreeBSD X"
+
+RDEPEND="
+   acct-group/gkrellmd
+   acct-user/gkrellmd
+   dev-libs/glib:2
+   hddtemp? ( app-admin/hddtemp )
+   ssl? (
+   gnutls? ( net-libs/gnutls )
+   !gnutls? (
+   !libressl? ( dev-libs/openssl:0= )
+   libressl? ( dev-libs/libressl:0= )
+   )
+   )
+   lm_sensors? ( sys-apps/lm_sensors:= )
+   nls? ( virtual/libintl )
+   ntlm? ( net-libs/libntlm )
+   X? (
+   x11-libs/gdk-pixbuf
+   x11-libs/gtk+:2
+   x11-libs/libICE
+   x11-libs/libSM
+   x11-libs/libX11
+   x11-libs/pango
+   )"
+DEPEND="${RDEPEND}
+   nls? ( sys-devel/gettext )"
+
+BDEPEND="
+   virtual/pkgconfig
+"
+
+PATCHES=(
+   "${FILESDIR}"/${PN}-2.3.5-config.patch
+   "${FILESDIR}"/${PN}-2.3.5-width.patch
+   "${FILESDIR}"/${PN}-2.3.5-sansfont.patch
+)
+
+S="${WORKDIR}/${MY_P}"
+
+DOCS=( Changelog CREDITS README )
+
+pkg_pretend() {
+   if use gnutls && ! use ssl ; then
+   ewarn "You have enabled the \"gnutls\" USE flag but not the 
\"ssl\" USE flag."
+   ewarn "No ssl backend will be built!"
+   fi
+}
+
+pkg_setup() {
+   TARGET=
+   use kernel_FreeBSD && TARGET="freebsd"
+}
+
+src_prepare() {
+   sed -e 's:-O2 ::' \
+   -e 's:override CC:CFLAGS:' \
+   -e 's:-L/usr/X11R6/lib::' \
+   -i */Makefile || die "sed Makefile(s) failed"
+
+   sed -e "s:/usr/lib:${EPREFIX}/usr/$(get_libdir):" \
+   -e "s:/usr/local/lib:${EPREFIX}/usr/local/$(get_libdir):" \
+   -i src/${PN}.h || die "sed ${PN}.h failed"
+
+   default
+}
+
+src_compile() {
+   if use X ; then
+   emake \
+   ${TARGET} \
+   CC="$(tc-getCC)" \
+   STRIP="" \
+   INSTALLROOT="${EPREFIX}/usr" \
+   INCLUDEDIR="${EPREFIX}/usr/include/gkrellm2" \
+   LOCALEDIR="${EPREFIX}/usr/share/locale" \
+   $(usex nls "" "enable_nls=0") \
+   $(usex lm_sensors "" "without-libsensors=yes") \
+   $(usex ntlm "" "without-ntlm=yes") \
+   $(usex ssl $(usex gnutls 'without-ssl=yes' 
'without-gnutls=yes') 'without-ssl=yes without-gnutls=yes')
+   else
+   cd server || die
+   emake \
+   ${TARGET} \
+   CC="$(tc-getCC)" \
+   LINK_FLAGS="$LDFLAGS -Wl,-E" \
+   STRIP="" \
+   $(usex nls "" "enable_nls=0") \
+   $(usex lm_sensors "" "without-libsensors=yes")
+   fi
+}
+
+src_install() {
+   if use X ; then
+   emake \
+   install${TARGET:+_}${TARGET} \
+   $(usex nls "" "enable_nls=0") \
+   STRIP="" \
+   INSTALLDIR="${ED}/usr/bin" \
+   INCLUDEDIR="${ED}/usr/include" \
+   LOCALEDIR="${ED}/usr/share/locale" \
+   PKGCONFIGDIR="${ED}/usr/$(get_libdir)/pkgconfig"

[gentoo-dev] [PATCH 2/4] acct-user/gkrellmd: Initial commit

[Lars Wendler]

Package-Manager: Portage-2.3.71, Repoman-2.3.17
Signed-off-by: Lars Wendler 
---
 acct-user/gkrellmd/gkrellmd-0.ebuild | 12 
 acct-user/gkrellmd/metadata.xml  |  8 
 2 files changed, 20 insertions(+)
 create mode 100644 acct-user/gkrellmd/gkrellmd-0.ebuild
 create mode 100644 acct-user/gkrellmd/metadata.xml

diff --git a/acct-user/gkrellmd/gkrellmd-0.ebuild 
b/acct-user/gkrellmd/gkrellmd-0.ebuild
new file mode 100644
index 000..0d6692d9820
--- /dev/null
+++ b/acct-user/gkrellmd/gkrellmd-0.ebuild
@@ -0,0 +1,12 @@
+# Copyright 2019 Gentoo Authors
+# Distributed under the terms of the GNU General Public License v2
+
+EAPI=7
+
+inherit acct-user
+
+DESCRIPTION="user for man page viewer"
+ACCT_USER_ID=104
+ACCT_USER_GROUPS=( gkrellmd )
+
+acct-user_add_deps
diff --git a/acct-user/gkrellmd/metadata.xml b/acct-user/gkrellmd/metadata.xml
new file mode 100644
index 000..95aa13f6c5e
--- /dev/null
+++ b/acct-user/gkrellmd/metadata.xml
@@ -0,0 +1,8 @@
+
+http://www.gentoo.org/dtd/metadata.dtd;>
+
+   
+   polynomia...@gentoo.org
+       Lars Wendler
+   
+
-- 
2.23.0.rc1

[gentoo-dev] [PATCH 1/4] acct-group/gkrellmd: Initial commit

[Lars Wendler]

Package-Manager: Portage-2.3.71, Repoman-2.3.17
Signed-off-by: Lars Wendler 
---
 acct-group/gkrellmd/gkrellmd-0.ebuild | 8 
 acct-group/gkrellmd/metadata.xml  | 8 
 2 files changed, 16 insertions(+)
 create mode 100644 acct-group/gkrellmd/gkrellmd-0.ebuild
 create mode 100644 acct-group/gkrellmd/metadata.xml

diff --git a/acct-group/gkrellmd/gkrellmd-0.ebuild 
b/acct-group/gkrellmd/gkrellmd-0.ebuild
new file mode 100644
index 000..bf075cf3184
--- /dev/null
+++ b/acct-group/gkrellmd/gkrellmd-0.ebuild
@@ -0,0 +1,8 @@
+# Copyright 2019 Gentoo Authors
+# Distributed under the terms of the GNU General Public License v2
+
+EAPI=7
+
+inherit acct-group
+
+ACCT_GROUP_ID=104
diff --git a/acct-group/gkrellmd/metadata.xml b/acct-group/gkrellmd/metadata.xml
new file mode 100644
index 000..95aa13f6c5e
--- /dev/null
+++ b/acct-group/gkrellmd/metadata.xml
@@ -0,0 +1,8 @@
+
+http://www.gentoo.org/dtd/metadata.dtd;>
+
+   
+   polynomia...@gentoo.org
+   Lars Wendler
+   
+
-- 
2.23.0.rc1

[gentoo-dev] [PATCH] acct-group/uptimed: Synced GID with uptimed user's UID

[Lars Wendler]

Package-Manager: Portage-2.3.71, Repoman-2.3.17
Signed-off-by: Lars Wendler 
---
 acct-group/uptimed/uptimed-0.ebuild | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/acct-group/uptimed/uptimed-0.ebuild 
b/acct-group/uptimed/uptimed-0.ebuild
index eb3672ba65e..952c350399c 100644
--- a/acct-group/uptimed/uptimed-0.ebuild
+++ b/acct-group/uptimed/uptimed-0.ebuild
@@ -5,4 +5,4 @@ EAPI=7
 
 inherit acct-group
 
-ACCT_GROUP_ID=210
+ACCT_GROUP_ID=103
-- 
2.23.0.rc1

Re: [gentoo-dev] [PATCH 2/3] acct-user/uptimed: Initial commit

[Lars Wendler]

On Tue, 06 Aug 2019 16:22:18 +0200 Michał Górny wrote:

>On Tue, 2019-08-06 at 16:19 +0200, Lars Wendler wrote:
>> Package-Manager: Portage-2.3.71, Repoman-2.3.17
>> Signed-off-by: Lars Wendler 
>> ---
>>  acct-user/uptimed/metadata.xml |  8 
>>  acct-user/uptimed/uptimed-0.ebuild | 12 
>>  2 files changed, 20 insertions(+)
>>  create mode 100644 acct-user/uptimed/metadata.xml
>>  create mode 100644 acct-user/uptimed/uptimed-0.ebuild
>> 
>> diff --git a/acct-user/uptimed/metadata.xml
>> b/acct-user/uptimed/metadata.xml new file mode 100644
>> index 000..c7be278b645
>> --- /dev/null
>> +++ b/acct-user/uptimed/metadata.xml
>> @@ -0,0 +1,8 @@
>> +
>> +> "http://www.gentoo.org/dtd/metadata.dtd;> +
>> +  
>> +polynomia...@gentoo.org
>> +Lars Wendler
>> +  
>> +
>> diff --git a/acct-user/uptimed/uptimed-0.ebuild
>> b/acct-user/uptimed/uptimed-0.ebuild new file mode 100644
>> index 000..d0b6431a114
>> --- /dev/null
>> +++ b/acct-user/uptimed/uptimed-0.ebuild
>> @@ -0,0 +1,12 @@
>> +# Copyright 2019 Gentoo Authors
>> +# Distributed under the terms of the GNU General Public License v2
>> +
>> +EAPI=7
>> +
>> +inherit acct-user
>> +
>> +DESCRIPTION="user for uptime daemon"
>> +ACCT_USER_ID=103  
>
>Any reason to use disjoint UID/GID?

No explicit reason. They were never being joined on any of my systems
so I thought that's no big deal.
Is that mandatory?

>> +ACCT_USER_GROUPS=( uptimed )
>> +
>> +acct-user_add_deps  
>



-- 
Lars Wendler
Gentoo package maintainer
GPG: 21CC CF02 4586 0A07 ED93  9F68 498F E765 960E 9B39


pgpq1eo0j6DY9.pgp
Description: Digitale Signatur von OpenPGP

Re: [gentoo-dev] [PATCH 2/3] acct-user/uptimed: Initial commit

[Lars Wendler]

On Tue, 06 Aug 2019 16:22:18 +0200 Michał Górny wrote:

>On Tue, 2019-08-06 at 16:19 +0200, Lars Wendler wrote:
>> Package-Manager: Portage-2.3.71, Repoman-2.3.17
>> Signed-off-by: Lars Wendler 
>> ---
>>  acct-user/uptimed/metadata.xml |  8 
>>  acct-user/uptimed/uptimed-0.ebuild | 12 
>>  2 files changed, 20 insertions(+)
>>  create mode 100644 acct-user/uptimed/metadata.xml
>>  create mode 100644 acct-user/uptimed/uptimed-0.ebuild
>> 
>> diff --git a/acct-user/uptimed/metadata.xml
>> b/acct-user/uptimed/metadata.xml new file mode 100644
>> index 000..c7be278b645
>> --- /dev/null
>> +++ b/acct-user/uptimed/metadata.xml
>> @@ -0,0 +1,8 @@
>> +
>> +> "http://www.gentoo.org/dtd/metadata.dtd;> +
>> +  
>> +polynomia...@gentoo.org
>> +Lars Wendler
>> +  
>> +
>> diff --git a/acct-user/uptimed/uptimed-0.ebuild
>> b/acct-user/uptimed/uptimed-0.ebuild new file mode 100644
>> index 000..d0b6431a114
>> --- /dev/null
>> +++ b/acct-user/uptimed/uptimed-0.ebuild
>> @@ -0,0 +1,12 @@
>> +# Copyright 2019 Gentoo Authors
>> +# Distributed under the terms of the GNU General Public License v2
>> +
>> +EAPI=7
>> +
>> +inherit acct-user
>> +
>> +DESCRIPTION="user for uptime daemon"
>> +ACCT_USER_ID=103
>
>Any reason to use disjoint UID/GID?

Thanks for reviewing :)

No explicit reason. They were never being joined on any of my systems
so I thought that's no big deal.
Is that mandatory?

>> +ACCT_USER_GROUPS=( uptimed )
>> +
>> +acct-user_add_deps
>

Cheers
Lars

-- 
Lars Wendler
Gentoo package maintainer
GPG: 21CC CF02 4586 0A07 ED93  9F68 498F E765 960E 9B39


pgphG3Sy99XvD.pgp
Description: Digitale Signatur von OpenPGP

[gentoo-dev] [PATCH 3/3] app-misc/uptimed: Revbump replacing user eclass

[Lars Wendler]

with uptimed group/user packages.
Also bump to EAPI-7

Package-Manager: Portage-2.3.71, Repoman-2.3.17
Signed-off-by: Lars Wendler 
---
 app-misc/uptimed/uptimed-0.4.1-r2.ebuild | 60 
 1 file changed, 60 insertions(+)
 create mode 100644 app-misc/uptimed/uptimed-0.4.1-r2.ebuild

diff --git a/app-misc/uptimed/uptimed-0.4.1-r2.ebuild 
b/app-misc/uptimed/uptimed-0.4.1-r2.ebuild
new file mode 100644
index 000..02322685333
--- /dev/null
+++ b/app-misc/uptimed/uptimed-0.4.1-r2.ebuild
@@ -0,0 +1,60 @@
+# Copyright 1999-2019 Gentoo Authors
+# Distributed under the terms of the GNU General Public License v2
+
+EAPI=7
+
+inherit autotools systemd
+
+DESCRIPTION="System uptime record daemon that keeps track of your highest 
uptimes"
+HOMEPAGE="https://github.com/rpodgorny/uptimed/;
+SRC_URI="https://github.com/rpodgorny/uptimed/archive/v${PV}.tar.gz -> 
${P}.tar.gz"
+
+LICENSE="GPL-2"
+SLOT="0"
+KEYWORDS="~alpha ~amd64 ~arm ~hppa ~mips ~ppc ~ppc64 ~sparc ~x86 ~x86-fbsd"
+IUSE="static-libs"
+
+RDEPEND="
+   acct-group/uptimed
+   acct-user/uptimed
+"
+DEPEND="${RDEPEND}"
+
+src_prepare() {
+   default
+   # fix configure.ac for >=automake-1.13 (bug #467582)
+   sed 's@AM_CONFIG_HEADER@AC_CONFIG_HEADERS@' -i configure.ac || die
+   eautoreconf
+}
+
+src_configure() {
+   econf $(use_enable static-libs static)
+}
+
+src_install() {
+   local DOCS=( ChangeLog README.md TODO AUTHORS CREDITS INSTALL.cgi 
sample-cgi/* )
+   default
+   find "${ED}" -type f -name '*.la' -delete || die
+
+   local spooldir="/var/spool/${PN}"
+   keepdir ${spooldir}
+   fowners uptimed:uptimed ${spooldir}
+
+   newinitd "${FILESDIR}"/${PN}.init-r1 uptimed
+   systemd_dounit "${FILESDIR}/${PN}.service"
+}
+
+pkg_postinst() {
+   local spooldir="/var/spool/${PN}"
+   if [[ -d "${spooldir}" ]] ; then
+   einfo "Fixing permissions in ${spooldir}"
+   find ${spooldir} -type f -links 1 \
+   \( -name records -o -name records.old \) \
+   | xargs --no-run-if-empty chown uptimed:uptimed || die
+   fi
+   echo
+   elog "Start uptimed with '/etc/init.d/uptimed start' (for openRC)"
+   elog "or systemctl start uptimed (for systemd)"
+   elog "To view your uptime records, use the command 'uprecords'."
+   echo
+}
-- 
2.23.0.rc1

[gentoo-dev] [PATCH 2/3] acct-user/uptimed: Initial commit

[Lars Wendler]

Package-Manager: Portage-2.3.71, Repoman-2.3.17
Signed-off-by: Lars Wendler 
---
 acct-user/uptimed/metadata.xml |  8 
 acct-user/uptimed/uptimed-0.ebuild | 12 
 2 files changed, 20 insertions(+)
 create mode 100644 acct-user/uptimed/metadata.xml
 create mode 100644 acct-user/uptimed/uptimed-0.ebuild

diff --git a/acct-user/uptimed/metadata.xml b/acct-user/uptimed/metadata.xml
new file mode 100644
index 000..c7be278b645
--- /dev/null
+++ b/acct-user/uptimed/metadata.xml
@@ -0,0 +1,8 @@
+
+http://www.gentoo.org/dtd/metadata.dtd;>
+
+  
+polynomia...@gentoo.org
+    Lars Wendler
+  
+
diff --git a/acct-user/uptimed/uptimed-0.ebuild 
b/acct-user/uptimed/uptimed-0.ebuild
new file mode 100644
index 000..d0b6431a114
--- /dev/null
+++ b/acct-user/uptimed/uptimed-0.ebuild
@@ -0,0 +1,12 @@
+# Copyright 2019 Gentoo Authors
+# Distributed under the terms of the GNU General Public License v2
+
+EAPI=7
+
+inherit acct-user
+
+DESCRIPTION="user for uptime daemon"
+ACCT_USER_ID=103
+ACCT_USER_GROUPS=( uptimed )
+
+acct-user_add_deps
-- 
2.23.0.rc1

[gentoo-dev] [PATCH 1/3] acct-group/uptimed: Inital commit

[Lars Wendler]

Package-Manager: Portage-2.3.71, Repoman-2.3.17
Signed-off-by: Lars Wendler 
---
 acct-group/uptimed/metadata.xml | 8 
 acct-group/uptimed/uptimed-0.ebuild | 8 
 2 files changed, 16 insertions(+)
 create mode 100644 acct-group/uptimed/metadata.xml
 create mode 100644 acct-group/uptimed/uptimed-0.ebuild

diff --git a/acct-group/uptimed/metadata.xml b/acct-group/uptimed/metadata.xml
new file mode 100644
index 000..95aa13f6c5e
--- /dev/null
+++ b/acct-group/uptimed/metadata.xml
@@ -0,0 +1,8 @@
+
+http://www.gentoo.org/dtd/metadata.dtd;>
+
+   
+   polynomia...@gentoo.org
+   Lars Wendler
+   
+
diff --git a/acct-group/uptimed/uptimed-0.ebuild 
b/acct-group/uptimed/uptimed-0.ebuild
new file mode 100644
index 000..eb3672ba65e
--- /dev/null
+++ b/acct-group/uptimed/uptimed-0.ebuild
@@ -0,0 +1,8 @@
+# Copyright 2019 Gentoo Authors
+# Distributed under the terms of the GNU General Public License v2
+
+EAPI=7
+
+inherit acct-group
+
+ACCT_GROUP_ID=210
-- 
2.23.0.rc1

[gentoo-dev] Current status with openssl-1.1

[Lars Wendler]

Hello dear Gentoo Devs,

this is somewhat written out of frustration so please bear with me ;)

CCing crypto@ in case they can provide some valuable input to the
topic. If not, sorry guys for wasting your time.

As you might have noticed, although being published back in August
2016, we still have openssl-1.1 in package.mask due to the numerous
build issues we still have with various packages[1] that uses openssl.

"Why is that so?" do I hear you asking. "Debian already switched over
to openssl-1.1 for months already".

Well... the did not entirely switch yet. There are still packages that
are being compiled/linked against openssl-1.0 in Debian because their
respective upstreams refuse to collaborate.

The most prominent example is openssh[2] which also is the reason that
this topic gives me so much frustration. They simply refuse to add
compatibility code for openssl-1.1 because openssl upstream did such a
silly move with making lots of interfaces opaque and make openssl-1.1
mostly incompatible with code written against older openssl versions.

This and the fact that you can build openssl-1.1 with three different
API versions (0.9.8, 1.0.0 and 1.1.0) makes it exceptionally hard for
openssl consumers to migrate their code to openssl-1.1.

openssh upstream even raised the idea to simply focus crypto support in
their software on libressl which I personally think is a really bad
move. But coming from the same people (openssh and libressl are both
developed by OpenBSD people), it's no big surprise this idea came up at
some point.

So, basically openssl is the last big showstopper for openssl-1.1 to
get out of p.mask. There are some inofficial patches floating around in
the WWW but each one of them has some issues and they all are not
really small in size.
Last time I checked, the most complete (but still to some degree
broken) patch had 2800+ LOC and was 80K in size. This is definitely
nothing I want to maintain as downstream, left aside the fact that
openssh should not be messed with lightly regarding security
implications.

My biggest concern right now is that openssh might still block
openssl-1.1.1 once that got released. openssl-1.1.1 provides TLSv1.3
which is something we should provide to our users as soon as possible
and is also targeted as next LTS release.



[1] https://bugs.gentoo.org/592438
[2] https://bugs.gentoo.org/592578

-- 
Lars Wendler
Gentoo package maintainer
GPG: 21CC CF02 4586 0A07 ED93  9F68 498F E765 960E 9B39


pgpfxryrsqsgo.pgp
Description: Digitale Signatur von OpenPGP

[gentoo-dev] Package up for grabs

[Lars Wendler]

Hi list,

I'd like to give up maintenance of 

  dev-libs/libratbag

due to the software now depending on libsystemd[1] which I do not have
the tiniest interest to infect my systems with.

Unfortunately upstream refuses to make libsystemd optional because they
don't wanna use dbus directly but rather prefer a useless additional
layer for that (libsystemd).

If nobody picks it up I either gonna put it on maintainer-needed in
about 30 days or (if QA prefers that) lastrite it entirely.

Kind regards
Lars

[1] https://github.com/libratbag/libratbag/issues/239


-- 
Lars Wendler
Gentoo package maintainer
GPG: 21CC CF02 4586 0A07 ED93  9F68 498F E765 960E 9B39


pgpEIVSzHon2f.pgp
Description: Digitale Signatur von OpenPGP

Re: [gentoo-dev] berkdb and gdbm in global USE defaults

[Lars Wendler]

On Sat, 7 Apr 2018 14:16:33 -0500 William Hubbs wrote:

>On Sat, Apr 07, 2018 at 02:55:53PM -0400, Michael Orlitzky wrote:
>> On 04/07/2018 02:44 PM, William Hubbs wrote:  
>> > 
>> > I'm with floppym on this one. Is there a specific reason we enable
>> > them globally?  
>> 
>> It's a relic from before we had IUSE defaults.
>> 
>>   
>> > Since there has been so little discussion on this thread, I will
>> > start looking at what I need to do to remove these use flags from
>> > the profiles.  
>> 
>> There's probably a few packages that will need IUSE defaults to avoid
>> breakage, and everyone else should get fair warning before the flags
>> are turned off by default.  
>
>There is the case of packages that optionally use a db back end,
>and I would argue that those may not need iuse defaults.
>
>It could also be argued that having one backend enabled globally is
>good for consistency, but that would end up leading down a bikeshed
>path that I'm not sure we should go down. I'm just not sure it makes
>sense to enable more than one of these backends globally.
>
>Thoughts?
>
>William
>

Considering the questionable license situation with latest sys-libs/db
releases (AGPL), I'd say we should prefer gdbm over berkdb in case we
want to keep one db backend default enabled.
IIRC Fedora is even trying to entirely getting rid of berkdb.

Lars

-- 
Lars Wendler
Gentoo package maintainer
GPG: 21CC CF02 4586 0A07 ED93  9F68 498F E765 960E 9B39


pgpZtUTHcE5fW.pgp
Description: Digitale Signatur von OpenPGP

Re: [gentoo-dev] Mailing list moderation and community openness

[Lars Wendler]

On Tue, 20 Mar 2018 23:17:52 +1100 Michael Palimaka wrote:

>I see that in bug #650964[1] Council is pushing forward again with
>implementing user whitelisting on this mailing list (ie. anyone that is
>not "approved" will have their mail rejected).
>
>Could someone please explain how this doesn't directly contradict the
>core tenets of an open and inclusive community?
>
>1: https://bugs.gentoo.org/650964
>

+1

This is ridiculous and council should be ashamed of this decision.

-- 
Lars Wendler
Gentoo package maintainer
GPG: 21CC CF02 4586 0A07 ED93  9F68 498F E765 960E 9B39


pgp8dhy4aanHN.pgp
Description: Digitale Signatur von OpenPGP

Re: [gentoo-dev] Packages up for grabs

[Lars Wendler]

On Tue, 13 Mar 2018 12:58:10 +0100 Pacho Ramos wrote:

>net-wireless/hostapd

In case nobody else wants to take it I can do. But I'm a mere user of
the package and don't know anything about its internals. So it would be
very basic/low maintenance from me.

Lars
-- 
Lars Wendler
Gentoo package maintainer
GPG: 21CC CF02 4586 0A07 ED93  9F68 498F E765 960E 9B39


pgpxACrFmV1id.pgp
Description: Digitale Signatur von OpenPGP

Re: [gentoo-dev] Managing updates on many identical Gentoo systems

[Lars Wendler]

Hi Anthony,

On Thu, 18 Jan 2018 06:46:53 -0500 Anthony G. Basile wrote:

>Hi everyone,
>
>I'm trying to design an update system for many identical Gentoo
>systems.
> Using a binhost is obvious, but there are still problems with this
>approach.
>
>Unless there's some magic I don't know about (and this is why I'm
>sending this email) each machine still needs to have the portage tree
>installed locally (1.5 GB) or somehow mounted by a network filesystem
>(which is not practical if the machines are not on a local network).
>Furthermore, each machine would have to run emerge locally to do the
>calculation of what packages need updating.
>
>This procedure is redundant because each machine is housing the same
>data and doing the same dependence-tree calculation.  It should be
>possible to do this calculation on a centralized binhost and simply
>communicate the update information to the remote machines.  They would
>then only have to download the .tbz2's and install them, keeping a tidy
>/var/db/pkg.  Thus they avoid having to house the portage tree and
>burning cpu cycles that just calculate redundant information.
>
>I'm inspired here by OpenBSD's pkg_add which doesn't require all of
>ports to be installed, and mender which is a
>
>Any ideas?
>

well, I never did anything like that but regarding the dependency
calculation... how about something like

emerge -1OKanv $(qlist -CISq)

(--oneshot --nodeps --usepkgonly --ask --noreplace --verbose)

which simply omits dependency calculations, only takes into account
available binary packages and doesn't replace same versions?
Of course this requires all installed packages really being available as
binpkgs.
Since all the installations are the same, as long as you provide a sane
set of binpkgs, dependency calculation should not matter anyway.
The only issue I can think of is that a system might become broken if
the update gets interrupted before all packages have been updated.

Kind regards

-- 
Lars Wendler
Gentoo package maintainer
GPG: 21CC CF02 4586 0A07 ED93  9F68 498F E765 960E 9B39


pgpBmwpubwc8w.pgp
Description: Digitale Signatur von OpenPGP

Re: [gentoo-dev] Upcoming posting restrictions on the gentoo-dev mailing list

[Lars Wendler]

On Thu, 11 Jan 2018 10:03:54 +0300 Eray Aslan wrote:

>On Wed, Jan 10, 2018 at 08:55:11AM +0100, Lars Wendler wrote:
>> Seems we're turning into an elitist club or something...   
>
>Elitist seems too kind a word.  Knee-jerk reaction, petty vendetta,
>impulsive emotional reaction comes to mind - instead of articulating
>and implementing a vision for the distribution, principled action,
>making all devs work together towards the goals that have been set.
>Not day to day reactions and bad ones at that.  Council is failing its
>one main task - it prolly has been for some time, this one also fails
>"first, do no harm" test.

A german term comes to my mind which applies perfectly to this:
"Blinder Aktionismus" which roughly translates to "blind actionism".

>Mind you they are not harming willingly.  I am pretty sure they are all
>well intentioned.  They, as a group, just do not have, I dont know, the
>vision, the experience, the personality to lead a distro.
>
>We need a change as otherwise I am afraid the future is not bright.  I
>think with this last straw I lost faith in the current setup.  Death by
>a committee.  Yey.
>

I'm totally baffled that few people seem to know how to filter trolls
out of their inboxes.
In the past such trolls were treated with a "plonk" and all was good.
But nowadays everything has to be ruled somehow.
Ah well, it's only a disservice to our users. Nothing the council needs
to worry about as they seem to have forgotten that they once were users
as well...


-- 
Lars Wendler
Gentoo package maintainer
GPG: 21CC CF02 4586 0A07 ED93  9F68 498F E765 960E 9B39


pgpQsMGd7Cdiy.pgp
Description: Digitale Signatur von OpenPGP

Re: [gentoo-dev] Re: Upcoming posting restrictions on the gentoo-dev mailing list

[Lars Wendler]

Hi Gordon,

On Wed, 10 Jan 2018 23:37:39 -0600 Gordon Pettey wrote:

>On Wed, Jan 10, 2018 at 10:22 PM, Duncan <1i5t5.dun...@cox.net> wrote:
>> Andreas K. Huettel posted on Thu, 11 Jan 2018 02:12:47 +0100 as
>> excerpted: 
>>> Am Mittwoch, 10. Januar 2018, 18:16:33 CET schrieb Vincent-Xavier
>>> JUMEL:  
>>>> Le 2018-01-10 10:53, Michał Górny a écrit :  
>>>> > Last I checked, Gentoo was a Linux distribution. However, some
>>>> > people prefer to turn it into open discussion forum that has
>>>> > nothing to do with making a distribution.  
>>>>
>>>> No it has. Giving power to a subset of users, denying interaction
>>>> with future contributors unless they enroll is the eaxct way to
>>>> kill Gentoo as a community !  
>>>
>>> We wouldn't have needed to go this far if not for a few outside
>>> trolls who
>>> * keep pushing their personal agenda in endless threads,
>>> * confuse their own inability to contribute with being a mistreated
>>> underdog,
>>> * and keep commenting opinionated on technical things they
>>> plainly have no clue about (while whining when are told they sprout
>>> bulls##t).
>>>
>>> We do not have a problem with "future contributors". I wager those
>>> will rather increase in numbers once the list spam is gone.  
>>
>>
>> This has been my biggest concern about the whole thing:
>>
>> Are we going to be nipping future devs in the bud because there's
>> now too many hoops to jump thru too early, and it's simply not worth
>> the trouble when they can (and will) go elsewhere where it's easier,
>>
>> OR
>>
>> Are we going to be lowering the unwelcoming noise, confusion and
>> name- calling threshold and making the community more welcoming for
>> those who have a serious interest, clearing out some of the stuff
>> that could otherwise discourage them.
>>
>>
>> It's pretty clear that council believes it's the latter, at least to
>> the degree that they're willing to try it for a time, effectively a
>> wager of sorts, but I don't believe anyone can honestly say what the
>> real effect one way or the other will be until it /is/ tried.
>>
>>
>> Personally, my viewpoint is that while over the last year or so there
>> were some 1-2 level frustrating posters on a 5-point scale, it's
>> nothing compared to the level-4 (direct name calling, just short of
>> physical threats that justify getting the law involved) stuff that
>> I've seen on this list in the some-years-distant past.  In my mind,
>> unquestionably that level-4 stuff required action, and it was taken.
>>
>> The recent stuff seems so much milder in comparison that IMO it's
>> hard to see what the hubbub is all about, but there's certainly an
>> argument to be made that the previous experience simply desensitized
>> our detection meters, and that were it not for that, the recent
>> stuff would seem rather more shocking and horrible than it does, and
>> that even if it's /less/ horrible, it's horrible /enough/ that it
>> remains unacceptable in a civilized society, and if we /do/ accept
>> it, we're effectively pushing others that won't, out.  
>
>Given the quantity of relevant problem-mail that came from
>@gentoo.org, maybe the glass house dwellers should be careful where
>they aim their stones. I considered taking the dev quiz and everything
>instead of just posting a few ebuilds on bugzilla years ago, but the
>elitist, as Alex labelled it, voices from @gentoo.org are what made me
>decide not to, and my decision keeps getting reinforced. That
>impression has been there for years, and it's not getting better by
>this.
>

very sad you got that impression. And unfortunately, I cannot even
wholeheartedly deny that this is true.
Given the fact that we are severely understaffed when it comes to
active developers, I hope you will reconsider your decision at some
point and start doing the quizzes.

Kind regards

-- 
Lars Wendler
Gentoo package maintainer
GPG: 21CC CF02 4586 0A07 ED93  9F68 498F E765 960E 9B39


pgpFHcQ4Bo_xI.pgp
Description: Digitale Signatur von OpenPGP

Re: [gentoo-dev] Upcoming posting restrictions on the gentoo-dev mailing list

[Lars Wendler]

On Wed, 10 Jan 2018 08:48:56 +0300 Eray Aslan wrote:

>On Tue, Jan 09, 2018 at 10:20:56PM +0100, Andreas K. Huettel wrote:
>> * Posting to the list will only be possible to Gentoo developers and
>>   whitelisted additional participants.  
>
>This is so contrary to what I and I thought Gentoo stands for:
>openness, transparency, inclusiveness even when these require a rather
>thick skin and result in high noise.  It's a price worth paying.
>
>I guess I should a) pay more attention to council elections b) consider
>the idea that the whole council thing as it stands now is just not
>working.
>

Wow. I couldn't have said it better. 
Seems we're turning into an elitist club or something... 
I wonder how many users we're going to loose on this one. Well done
council :-(

-- 
Lars Wendler
Gentoo package maintainer
GPG: 21CC CF02 4586 0A07 ED93  9F68 498F E765 960E 9B39


pgpp26P9mjsBM.pgp
Description: Digitale Signatur von OpenPGP

Re: [gentoo-dev] Projects up for grabs: cron, m68k

[Lars Wendler]

Am Wed, 20 Dec 2017 18:02:22 +0100
schrieb Michał Górny :

> Hello, everyone.
> 
> Due to prolonged inactivity of Mike Frysinger (vapier), the following
> projects have had effectively no members for 6 months already:
> 
> https://wiki.gentoo.org/wiki/Project:Cron
> 
>   sys-process/anacron [m]
>   sys-process/at

sys-process/at is lacking the [m]

>   sys-process/bcron
>   sys-process/cronbase
>   sys-process/cronie [m]
>   sys-process/dcron
>   sys-process/fcron [m]
>   sys-process/vixie-cron
>   virtual/cron
> 
> https://wiki.gentoo.org/wiki/Project:M68k
> 
>   sys-apps/zorroutils [m]
>   sys-fs/atari-fdisk
> 
> The packages listed with '[m]' have other maintainers. The remaining
> packages are solely maintained by the listed projects.
> 
> If you are interested in helping out with some of those packages,
> please consider joining the appropriate project and/or co-maintaining
> the individual packages.
> 
> If the projects see no activity within the next month, I will disband
> them and move the appropriate packages to maintainer-needed.
> 

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

[Lars Wendler]

Am Sun, 17 Dec 2017 13:40:35 -0500
schrieb Mike Gilbert :

> On Sun, Dec 17, 2017 at 1:39 PM, Mike Gilbert 
> wrote:
> > On Sun, Dec 17, 2017 at 8:21 AM, Michał Górny 
> > wrote:  
> >> Hello, everyone.
> >>
> >> It's my pleasure to announce that with a majority vote the QA team
> >> has accepted a new policy. The accepted wording is:
> >>
> >>   Total size of 'files' subdirectory of a package should not be
> >> larger than 32 KiB. If the package needs more auxiliary files,
> >> they should be put into SRC_URI e.g. via tarballs.
> >>
> >> (the total size being computed as a sum of apparent file sizes)
> >>
> >> The relevant policy vote is finishing at bug #633758 [1]. The CI
> >> reports [2] were updated to report packages whose 'files'
> >> directories exceed 64 KiB, to avoid adding many new warnings at
> >> once. The limit will be lowered down to 32 KiB as packages are
> >> fixed to comply with the new policy.
> >>
> >> At the same time, I would like to explicitly remind developers that
> >> the spirit of the policy is 'do not let "files" grow large', not
> >> 'make sure you're one byte less than 32769.' Do not argue that
> >> your package exceeds the limit only by few bytes -- even if it
> >> gets close to the limit, then it means it's way too large.  
> >
> > I just want to voice my opinion on this: as a developer, this policy
> > is a royal pain in the ass.
> >
> > I would ask the council to please increase this limit to at least
> > 100 KiB, preferably more.  
> 
> Please substitute "QA team" for "council" in the above message.
> Thanks.
> 

I second this request for the exact same reason.

Lars

Re: [gentoo-dev] sys-boot/plymouth needs major fixes/maintainer

[Lars Wendler]

On Fri, 04 Aug 2017 17:37:15 +0300 Mart Raudsepp wrote:

>On R, 2017-08-04 at 14:23 +, Lucas Ramage wrote:
>> I am looking into this for openrc. I copied it over to my personal
>> overlay.  
>
>Ok, how about I mark myself as maintainer then and add you as co
>-maintainer for OpenRC aspects, and you can e-mail me fixes for openrc
>or otherwise?

Last time I checked, plymouth-0.9.x had a hard requirement for systemd
to work. From what I remember, making 0.9.x versions work with openrc
might become a hard to solve task.

>sys-boot/plymouth-openrc-plugin is involved in that OpenRC support too
>still, right?
>
>I'm not sure about
>kde-plasma/breeze-plymouth
>kde-plasma/plymouth-kcm
>do you use KDE/Plasma to care for those too?
>
>

Lars

-- 
Lars Wendler
Gentoo package maintainer
GPG: 21CC CF02 4586 0A07 ED93  9F68 498F E765 960E 9B39


pgpgPTkgVmXwH.pgp
Description: Digitale Signatur von OpenPGP

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

[Lars Wendler]

On Mon, 10 Jul 2017 19:22:20 +0200 Agostino Sarubbo wrote:

>Hi all.
>
>every time that I attach my tmux session to see what happens on irc, I
>always see the same discussion about the 'minor' arches status.
>Since I joined gentoo(2011) I worked on all arches except hppa, I put
>more effort in amd64 and less where I saw other people work on it
>(arm,alpha) But every time the magic phrase is that those arches are
>unmaintained.
>
>Now, since I work on these arches just to help, i.e. I don't have any
>business and I do non have any installation of those arches and the
>work I'm doing is not appreciated at all I decided to stop for now.
>If your dream is to put sparc and ia64 to ~arch, go ahead, I have no 
>objections.
>I will take a break also from amd64 and x86...let's see how things
>will change.
>

Hi Agostino,

this is very sad news but I'm not really surprised about your
decision. It seems like every arch except amd64 and to some point
arm(64) seems to be the target of massive vilification.

On behalf of base-system team let me thank you for your awesome
stabilization work. I hope you will return at some point when your
frustration level has sufficiently decreased.

Kind regards
Lars

-- 
Lars Wendler
Gentoo package maintainer
GPG: 21CC CF02 4586 0A07 ED93  9F68 498F E765 960E 9B39


pgpatNBwwwG4t.pgp
Description: Digitale Signatur von OpenPGP

Re: [gentoo-dev] Bugzilla package list editing

[Lars Wendler]

Hi,

On Tue, 2 May 2017 13:05:38 +0200 Chí-Thanh Christopher Nguyễn wrote:

>Paweł Hajdan, Jr. schrieb:
>
>>>> Please stop editing package lists when you are not the maintainer
>>>> and arches are already CCed.  
>>> +1
>>>
>>> Please stop it.
>>> And yes that's also true for arch team members.
>>>
>>> Package list is maintainer territory.  
>> Curious, what are the reasons and what changes people make that they
>> shouldn't?
>>
>> I'm wondering if there's some solution to these issues (maybe better
>> documentation, or an alternative way of accomplishing what these
>> people try to do).  
>
>As dilfridge pur jer in CC, I guess that some of jer's changes to bugs 
>were not welcomed by maintainers.
>
>One recent example of non-maintainer activity in the package list
>field is bug 613104, where he just removed the entire package list
>(and then marked the bug WONTFIX).
>Also very common is that he changes fully qualified package names
>(which is the correct syntax per [1]) into fully qualified package
>atoms (which is the legacy syntax). Bug 616260 is one such example.

I must admit that I did the same (changing full package names to full
package atoms). IIRC when these package lists were introduced this was
the only valid syntax and stable bot complained if it was not a package
atom.

>Best regards,
>Chí-Thanh Christopher Nguyễn
>
>[1] https://bugs.gentoo.org/page.cgi?id=fields.html
>

Kind regards
Lars

-- 
Lars Wendler
Gentoo package maintainer
GPG: 21CC CF02 4586 0A07 ED93  9F68 498F E765 960E 9B39


pgp4jLNV_asn2.pgp
Description: Digitale Signatur von OpenPGP

Re: [gentoo-dev] [PATCH] xorg-2.eclass: Enable verbose build logs.

[Lars Wendler]

Hi,

On Sat,  4 Mar 2017 11:13:08 -0800 Matt Turner wrote:

>From: Agostino Sarubbo <a...@gentoo.org>
>
>Bug: https://bugs.gentoo.org/458000
>---
> eclass/xorg-2.eclass | 6 ++
> 1 file changed, 6 insertions(+)
>
>diff --git a/eclass/xorg-2.eclass b/eclass/xorg-2.eclass
>index 1af1705..fe44658 100644
>--- a/eclass/xorg-2.eclass
>+++ b/eclass/xorg-2.eclass
>@@ -472,9 +472,15 @@ xorg-2_src_configure() {
>   local selective_werror="--disable-selective-werror"
>   fi
> 
>+  # Check if package supports a verbose build
>+  if grep -q -s "disable-silent-rules"
>${ECONF_SOURCE:-.}/configure; then
>+  local no_silent="--disable-silent-rules"
>+  fi
>+
>   local myeconfargs=(
>   ${dep_track}
>   ${selective_werror}
>+  ${no_silent}
>   ${FONT_OPTIONS}
>   "${xorgconfadd[@]}"
>   )

very unlikely scenario but what happens if configure does not provide
"disable-silent-rules" but "${no_silent} was defined somewhere in the
environment?

Lars
-- 
Lars Wendler
Gentoo package maintainer
GPG: 21CC CF02 4586 0A07 ED93  9F68 498F E765 960E 9B39

Attention! New gpg key! See
https://www.gentoofan.org/blog/index.php?/archives/9-New-gpg-keys.html


pgpIK0ozg8wio.pgp
Description: Digitale Signatur von OpenPGP

Re: [gentoo-dev] Removal of CVS headers

[Lars Wendler]

On Sun, 26 Feb 2017 23:30:25 +0100 Michał Górny wrote:

>W dniu 26.02.2017, nie o godzinie 21∶16 +0100, użytkownik Lars Wendler
>napisał:
>> On Sun, 26 Feb 2017 19:59:19 + Robin H. Johnson wrote:
>>   
>> > On Sat, Feb 25, 2017 at 03:05:09PM +0100, Ulrich Mueller wrote:  
>> > > As the council has decided in its 2014-10-14 meeting (and
>> > > confirmed again in the 2016-11-13 meeting), CVS headers should
>> > > be removed after the migration to Git.
>> > 
>> > The 2014-10-14 meeting did NOT specify what CVS headers were in
>> > question, and it was later decided that this was $Header$, not
>> > $Id$. 
>> > > Until recently, this was blocked by repoman still checking for
>> > > the $Id$ line. The latter is now fixed in the stable repoman
>> > > version.
>> > > 
>> > > Therefore, I am going to remove the remaining CVS headers
>> > > throughout the tree (except for patches, of course) in two days
>> > > from now.
>> > 
>> > This was also discussed in August 2015:
>> > Subject: 'Infra plans regarding $Id$ - official answer...'
>> > https://archives.gentoo.org/gentoo-dev/message/d01ce943a9f9404c454c26bdb7efdf0e
>> > 
>> > $Id$ is used by Git as well, and I was a strong advocate that
>> > expansion of $Id$ should be ENABLED in the rsync exports, because
>> > it allowed tracing what version of a file was actually in use.
>> > 
>> > In the case of Git, $Id$ expands to the blob hash, which can be
>> > traced to a commit trivially, and several of the council members
>> > in the 2015 thread did agree it was useful in that format (but I
>> > see no formal vote was ever taken).
>> >   
>> 
>> And that's exactly for what I use the $Id$ header.
>> I am completely against removal of this header line. It does _not_ do
>> any harm and I don't understand why people want it to be removed so
>> badly.
>> Now QA again wants to do a questionable action _without_ any approval
>> from neither infra nor council. Sorry guys but this is not how things
>> work. The official answer from infra regarding $Id$ gives enough good
>> examples why this header line should be kept.
>> This $Id$ header line is the only way how I can safely keep official
>> ebuilds and ebuilds from my overlay in sync. I don't like getting my
>> workflows sabotaged and I consider this a pure act of sabotage...
>> 
>> How about QA finally starts acting on useful issues or at least do
>> actions that make sense?  
>
>How about you give some respect to your fellow developers who simply
>try to do stuff to improve Gentoo, instead of attributing malice and
>taking it as personal attack on you?

Wow, getting that from the perhaps most rude dev with the least
amount of social skills we might have currently...
Everytime I think you can't do worse you prove me wrong...

>As far as I'm concerned, we could tell as well that the Council decided
>on header removal, then Infra went rogue and replaced the header with
>another one, and now it claims that the decision was about $Header$
>and not $Id$. Does that sound nice to you? Does it motivate you to work
>more on Gentoo?

Nice conspiracy plot... here, have a tin hat.

>Of course, we can dispute that Infra might one day actually start
>expanding $Id$. And not break random files in the process. And not
>break Manifest thickening and signing in the process.
>

No real need to do that expansion for everybody. Just keep the $Id$
header field for those who want to make use of git's ident attribute
feature.

-- 
Lars Wendler
Gentoo package maintainer
GPG: 21CC CF02 4586 0A07 ED93  9F68 498F E765 960E 9B39

Attention! New gpg key! See
https://www.gentoofan.org/blog/index.php?/archives/9-New-gpg-keys.html


pgp8WPRCrYCRc.pgp
Description: Digitale Signatur von OpenPGP

Re: [gentoo-dev] Removal of CVS headers

[Lars Wendler]

On Sun, 26 Feb 2017 16:42:59 -0500 Mike Gilbert wrote:

>On Sun, Feb 26, 2017 at 4:16 PM, Lars Wendler
><polynomia...@gentoo.org> wrote:
>> On Sun, 26 Feb 2017 22:07:48 +0100 Ulrich Mueller wrote:
>>  
>>>>>>>> On Sun, 26 Feb 2017, Robin H Johnson wrote:  
>>>  
>>>> The 2014-10-14 meeting did NOT specify what CVS headers were in
>>>> question, and it was later decided that this was $Header$, not
>>>> $Id$.  
>>>
>>>When and by whom was that decided? The unanimous council decision was
>>>to remove "CVS headers" and the obvious understanding is that this
>>>includes all Header, Id, Date, and so on. Quoting the actual agenda
>>>item (which was submitted by another infra member, BTW):
>>>
>>># 3. CVS Headers
>>>#
>>># The hateful thing. We could supposedly somehow fill them in rsync
>>># but that's complex and very dangerous (think of all the broken
>>>patch # files currently in gx86). I think we should kill them.
>>>#
>>># And while at it, I think it'd be good to actually remove most of
>>># them from our files -- changing header templates and so on. While
>>># not strictly useful, it decreases the size of the repo a bit and
>>># avoids any future nightmares :).
>>>
>>>Then in the summary of the 2016-11-13 council meeting we have this:
>>>
>>>- Bug 579460 "please make repoman ignore a missing "# $Id$" header
>>>line":
>>>  Implemented in repoman-2.3.0, but not yet in stable. Once this is
>>>  done, CVS headers can be removed as per 2014-10-14 council
>>> decision.
>>>
>>>Note that it explicitly mentions $Id$, and until today nobody had
>>>raised any objections against its revoval.  
>>
>> Well, here is my objection now. And it seems like nobody at the
>> council seems to have understood the intention of this $Id$ header in
>> git.
>> See https://git-scm.com/docs/gitattributes and search for "ident".
>>  
>>>> This was also discussed in August 2015:
>>>> Subject: 'Infra plans regarding $Id$ - official answer...'
>>>> https://archives.gentoo.org/gentoo-dev/message/d01ce943a9f9404c454c26bdb7efdf0e
>>>>   
>>>  
>>>> $Id$ is used by Git as well, and I was a strong advocate that
>>>> expansion of $Id$ should be ENABLED in the rsync exports, because
>>>> it allowed tracing what version of a file was actually in use.  
>>>
>>>I don't see any expansion of $Id$ in rsync as of today, 18 months
>>>after the Git conversion. If it wasn't missed for 18 months, one can
>>>hardly claim that it would be an important feature.
>>>
>>>Also I suspect that it is too late to enable it now, because it will
>>>potentially break patches that have been added after the conversion
>>>to Git.  
>>
>> There is no need to enable it by default. But it is a very nice way
>> to verify ebuild changes if being enabled locally on a git clone of
>> the tree. Ever since portage was migrated to git I had this line in
>> my .git/info/attributes file on my dev box:
>>
>> *.ebuild ident
>>
>> This is a very useful feature and should not be removed only because
>> council was told that it's a mere CVS migration cruft. It is not!  
>
>If this is about keeping ebuilds in your overlay in sync, you could
>alternatively use the output of git ls-tree to keep track of changes
>using the same blob ids.

This is not the same. git's ident mechanism doesn't use the commit blob
hash but creates a hash from the file's content. And as I am not using
VCS for my overlay, git ls-tree is no useful replacement solution here.

>It may not be as immediately convenient for you, but it would
>ultimately be more reliable in the long run; there are already several
>ebuilds in the gentoo repo that are missing the $Id$ header. Even if
>we restore the repoman check, I'm sure they will creep in.

Which then could be a perfect opportunity for QA to finally do
something useful.

-- 
Lars Wendler
Gentoo package maintainer
GPG: 21CC CF02 4586 0A07 ED93  9F68 498F E765 960E 9B39

Attention! New gpg key! See
https://www.gentoofan.org/blog/index.php?/archives/9-New-gpg-keys.html


pgpIk_Z6QkF3c.pgp
Description: Digitale Signatur von OpenPGP

Re: [gentoo-dev] Removal of CVS headers

[Lars Wendler]

On Sun, 26 Feb 2017 22:07:48 +0100 Ulrich Mueller wrote:

>>>>>> On Sun, 26 Feb 2017, Robin H Johnson wrote:  
>
>> The 2014-10-14 meeting did NOT specify what CVS headers were in
>> question, and it was later decided that this was $Header$, not
>> $Id$.  
>
>When and by whom was that decided? The unanimous council decision was
>to remove "CVS headers" and the obvious understanding is that this
>includes all Header, Id, Date, and so on. Quoting the actual agenda
>item (which was submitted by another infra member, BTW):
>
># 3. CVS Headers
>#
># The hateful thing. We could supposedly somehow fill them in rsync
># but that's complex and very dangerous (think of all the broken patch
># files currently in gx86). I think we should kill them.
>#
># And while at it, I think it'd be good to actually remove most of
># them from our files -- changing header templates and so on. While
># not strictly useful, it decreases the size of the repo a bit and
># avoids any future nightmares :).
>
>Then in the summary of the 2016-11-13 council meeting we have this:
>
>- Bug 579460 "please make repoman ignore a missing "# $Id$" header
>line":
>  Implemented in repoman-2.3.0, but not yet in stable. Once this is
>  done, CVS headers can be removed as per 2014-10-14 council decision.
>
>Note that it explicitly mentions $Id$, and until today nobody had
>raised any objections against its revoval.

Well, here is my objection now. And it seems like nobody at the
council seems to have understood the intention of this $Id$ header in
git.
See https://git-scm.com/docs/gitattributes and search for "ident".

>> This was also discussed in August 2015:
>> Subject: 'Infra plans regarding $Id$ - official answer...'
>> https://archives.gentoo.org/gentoo-dev/message/d01ce943a9f9404c454c26bdb7efdf0e
>>   
>
>> $Id$ is used by Git as well, and I was a strong advocate that
>> expansion of $Id$ should be ENABLED in the rsync exports, because it
>> allowed tracing what version of a file was actually in use.  
>
>I don't see any expansion of $Id$ in rsync as of today, 18 months
>after the Git conversion. If it wasn't missed for 18 months, one can
>hardly claim that it would be an important feature.
>
>Also I suspect that it is too late to enable it now, because it will
>potentially break patches that have been added after the conversion to
>Git.

There is no need to enable it by default. But it is a very nice way to
verify ebuild changes if being enabled locally on a git clone of the
tree. Ever since portage was migrated to git I had this line in
my .git/info/attributes file on my dev box:

*.ebuild ident

This is a very useful feature and should not be removed only because
council was told that it's a mere CVS migration cruft. It is not!

-- 
Lars Wendler
Gentoo package maintainer
GPG: 21CC CF02 4586 0A07 ED93  9F68 498F E765 960E 9B39

Attention! New gpg key! See
https://www.gentoofan.org/blog/index.php?/archives/9-New-gpg-keys.html


pgpBNWn6sTwOy.pgp
Description: Digitale Signatur von OpenPGP

Re: [gentoo-dev] Removal of CVS headers

[Lars Wendler]

On Sun, 26 Feb 2017 15:32:56 -0500 Rich Freeman wrote:

>On Sun, Feb 26, 2017 at 3:27 PM, Lars Wendler
><polynomia...@gentoo.org> wrote:
>> On Sun, 26 Feb 2017 21:24:38 +0100 Andreas K. Huettel wrote:
>>  
>>>Am Sonntag, 26. Februar 2017, 21:16:28 CET schrieb Lars Wendler:  
>>>> I am completely against removal of this header line. It does _not_
>>>> do any harm and I don't understand why people want it to be
>>>> removed so badly.
>>>> Now QA again wants to do a questionable action _without_ any
>>>> approval from neither infra nor council.  
>>>[snip]
>>>
>>>October 2014 council meeting:
>>>
>>>Can we drop CVS headers post-migration?
>>>Aye: blueness, creffett (proxy for ulm), dberkholz, dilfridge,
>>>radhermit, rich0, williamh
>>>  
>>
>> $Id$ is _NOT_ the CVS header.
>>  
>
>Do we really need to put it on the Council agenda just so that the
>same group of people can approve it again?
>

Yes please. I'd like to raise my concerns if this is really the only
way to keep this header.

-- 
Lars Wendler
Gentoo package maintainer
GPG: 21CC CF02 4586 0A07 ED93  9F68 498F E765 960E 9B39

Attention! New gpg key! See
https://www.gentoofan.org/blog/index.php?/archives/9-New-gpg-keys.html


pgp0Mxy1KfT5m.pgp
Description: Digitale Signatur von OpenPGP

Re: [gentoo-dev] Removal of CVS headers

[Lars Wendler]

On Sun, 26 Feb 2017 21:24:38 +0100 Andreas K. Huettel wrote:

>Am Sonntag, 26. Februar 2017, 21:16:28 CET schrieb Lars Wendler:
>> I am completely against removal of this header line. It does _not_ do
>> any harm and I don't understand why people want it to be removed so
>> badly.
>> Now QA again wants to do a questionable action _without_ any approval
>> from neither infra nor council.  
>[snip]
>
>October 2014 council meeting:
>
>Can we drop CVS headers post-migration?
>Aye: blueness, creffett (proxy for ulm), dberkholz, dilfridge,
>radhermit, rich0, williamh 
>
>
>
>

$Id$ is _NOT_ the CVS header.

-- 
Lars Wendler
Gentoo package maintainer
GPG: 21CC CF02 4586 0A07 ED93  9F68 498F E765 960E 9B39

Attention! New gpg key! See
https://www.gentoofan.org/blog/index.php?/archives/9-New-gpg-keys.html


pgpL6ISAlDEuc.pgp
Description: Digitale Signatur von OpenPGP

Re: [gentoo-dev] Removal of CVS headers

[Lars Wendler]

On Sun, 26 Feb 2017 19:59:19 + Robin H. Johnson wrote:

>On Sat, Feb 25, 2017 at 03:05:09PM +0100, Ulrich Mueller wrote:
>> As the council has decided in its 2014-10-14 meeting (and confirmed
>> again in the 2016-11-13 meeting), CVS headers should be removed after
>> the migration to Git.  
>The 2014-10-14 meeting did NOT specify what CVS headers were in
>question, and it was later decided that this was $Header$, not $Id$.
>
>> Until recently, this was blocked by repoman still checking for the
>> $Id$ line. The latter is now fixed in the stable repoman version.
>> 
>> Therefore, I am going to remove the remaining CVS headers throughout
>> the tree (except for patches, of course) in two days from now.  
>This was also discussed in August 2015:
>Subject: 'Infra plans regarding $Id$ - official answer...'
>https://archives.gentoo.org/gentoo-dev/message/d01ce943a9f9404c454c26bdb7efdf0e
>
>$Id$ is used by Git as well, and I was a strong advocate that expansion
>of $Id$ should be ENABLED in the rsync exports, because it allowed
>tracing what version of a file was actually in use.
>
>In the case of Git, $Id$ expands to the blob hash, which can be traced
>to a commit trivially, and several of the council members in the 2015
>thread did agree it was useful in that format (but I see no formal vote
>was ever taken).
>

And that's exactly for what I use the $Id$ header.
I am completely against removal of this header line. It does _not_ do
any harm and I don't understand why people want it to be removed so
badly.
Now QA again wants to do a questionable action _without_ any approval
from neither infra nor council. Sorry guys but this is not how things
work. The official answer from infra regarding $Id$ gives enough good
examples why this header line should be kept.
This $Id$ header line is the only way how I can safely keep official
ebuilds and ebuilds from my overlay in sync. I don't like getting my
workflows sabotaged and I consider this a pure act of sabotage...

How about QA finally starts acting on useful issues or at least do
actions that make sense?

-- 
Lars Wendler
Gentoo package maintainer
GPG: 21CC CF02 4586 0A07 ED93  9F68 498F E765 960E 9B39

Attention! New gpg key! See
https://www.gentoofan.org/blog/index.php?/archives/9-New-gpg-keys.html


pgpXlAc1_vLo2.pgp
Description: Digitale Signatur von OpenPGP

Re: [gentoo-dev] rfc: moving OpenRC to a meson-based build

[Lars Wendler]

On Fri, 3 Feb 2017 10:32:30 +0100 Kristian Fiskerstrand wrote:

>On 02/03/2017 10:10 AM, Benda Xu wrote:
>> William Hubbs <willi...@gentoo.org> writes:
>>   
>>> I have been looking at the meson build system [1] [2], and I like
>>> what I see.
>>>
>>> I have opened an issue on OpenRC's github wrt migrating OpenRC to
>>> the meson build system [3].
>>>
>>> As I said on the bug, the downside is the addition of py3 and ninja
>>> as build time dependencies, but I think the upside (a build system
>>> where we don't have to worry about parallel make issues or
>>> portability) outweighs that.
>>>
>>> What do folks think here?  
>> 
>> I would discourage it.  Making OpenRC build-depend on python
>> introduces unnecessary complexity that will undermine the
>> portability of OpenRC sooner or later.
>> 
>> After all OpenRC is a small program easy to build with a hand-written
>> Makefile.
>> 
>> Parallel make issues?  No problem let's just solve it.
>> 
>> 
>> Please, keep it simple.  
>
>I'm adding my support to this sentiment
>
>

+1

-- 
Lars Wendler
Gentoo package maintainer
GPG: 21CC CF02 4586 0A07 ED93  9F68 498F E765 960E 9B39

Attention! New gpg key! See
https://www.gentoofan.org/blog/index.php?/archives/9-New-gpg-keys.html


pgpEkZOYA01EV.pgp
Description: Digitale Signatur von OpenPGP

[gentoo-dev] virtualbox packages will get its hardened support removed within one week.

[Lars Wendler]

Hello all,

due to some really ugly circumstances I will remove hardened support
and all hardened related patches from virtualbox packages within one
week unless some Gentoo dev steps up and starts maintaining the
hardended support in those virtualbox packages.
I never used hardened myself and do not have the intention to do so
just for a single group of packages I maintain.
It turns out that the hardened patches for virtualbox packages tend to
break every other new virtualbox release and I don't think it's fair
for our hardened users to pretend those packages work on a hardened
environment when they in fact more often do not.

I know this might upset a couple of devs and users but I have to draw a
line somewhere and I decided I draw it here.

Lars

-- 
Lars Wendler
Gentoo package maintainer
GPG: 21CC CF02 4586 0A07 ED93  9F68 498F E765 960E 9B39

Attention! New gpg key! See
https://www.gentoofan.org/blog/index.php?/archives/9-New-gpg-keys.html


pgpxPM7AbVuJu.pgp
Description: Digitale Signatur von OpenPGP

Re: [gentoo-dev] Packages up for grabs due to retirement

[Lars Wendler]

Hi,

On Tue, 3 Jan 2017 16:00:52 +0700 (+07) gro...@gentoo.org wrote:

>On Mon, 2 Jan 2017, Brian Evans wrote:
>> IMO, this one should be given last-rites as upstream is dead and it
>> heavily depends on wireless-tools and WEXT.  

this is plain wrong. Upstream is not dead, just not very active anymore.

>I use it on 2 notebooks. It works fine, and is (from my point of view)
>the most convenient tool to control ethernet and wifi connections on a 
>notebook. Why lastrite it when it works?
>
>Andrey
>

Lars

-- 
Lars Wendler
Gentoo package maintainer
GPG: 21CC CF02 4586 0A07 ED93  9F68 498F E765 960E 9B39

Attention! New gpg key! See
https://www.gentoofan.org/blog/index.php?/archives/9-New-gpg-keys.html


pgpETeGr0Dl2V.pgp
Description: Digitale Signatur von OpenPGP

Re: [gentoo-dev] Packages up for grabs due to retirement

[Lars Wendler]

Hi Thomas,

On Sat, 31 Dec 2016 22:54:28 +0100 Thomas Kahle wrote:

>Hi,
>
>I will retire, so here are my remaining packages. 

Sad day seeing another dev leaving :-(

>net-misc/wicd

I can take this one if nobody else is interested in it.


>Cheers,
>Thomas
>
>

I wish you all the best and if you ever feel the urge, please come
back :)

Kind regards
Lars

-- 
Lars Wendler
Gentoo package maintainer
GPG: 21CC CF02 4586 0A07 ED93  9F68 498F E765 960E 9B39

Attention! New gpg key! See
https://www.gentoofan.org/blog/index.php?/archives/9-New-gpg-keys.html


pgpYMZWnXUb25.pgp
Description: Digitale Signatur von OpenPGP

[gentoo-dev] bash-4.4 - call for testers

[Lars Wendler]

Hi,

bash-4.4/readline-7.0 have been released and are available in Gentoo
already although they are still being package.masked.

This is a call for testers. If you feel brave enough, please give
bash-4.4 a shot and report all problems you might have with it.

Add the following to you package.unmask file/directory:

  =app-shells/bash-4.4*
  =sys-libs/readline-7.0*

and emerge both packages. Once readline-7.0 has been installed you
most likely need to run

  emerge -v @preserved-rebuild

in order to get all readline reverse deps being built against new
readline. Reporting those packages in our bug tracker [1] would be
helpful.
In case you encounter a real bug in bash or readline please report them
to our bug tracker [1] as well. 
If you just seem to have successfully installed bash and found no
problems after a while of testing, I'd like to know about it here on the
list. This would help me determining when this bash version can be
removed from package.mask.
Perhaps we even consider stabilizing bash-4.4 a bit sooner now that
there's a security bug [2] that requires bash-4.4 for the fix.

Thanks in advance.

[1] https://bugs.gentoo.org
[2] https://bugs.gentoo.org/594496
-- 
Lars Wendler
Gentoo package maintainer
GPG: 21CC CF02 4586 0A07 ED93  9F68 498F E765 960E 9B39

Attention! New gpg key! See
https://www.gentoofan.org/blog/index.php?/archives/9-New-gpg-keys.html


pgpSdxnpG76aR.pgp
Description: Digitale Signatur von OpenPGP

[gentoo-dev] Last rites: sys-block/eject

[Lars Wendler]

Dead upstream since 2013. Superseded by eject from sys-apps/util-linux.

Slated for removal in 30 days.

-- 
Lars Wendler
Gentoo package maintainer
GPG: 21CC CF02 4586 0A07 ED93  9F68 498F E765 960E 9B39

Attention! New gpg key! See
https://www.gentoofan.org/blog/index.php?/archives/9-New-gpg-keys.html


pgpacC2d8Ws1q.pgp
Description: Digitale Signatur von OpenPGP

Re: [gentoo-dev] base-system needs developers who care

[Lars Wendler]

On Tue, 23 Aug 2016 20:08:30 -0400 Anthony G. Basile wrote:

>On 8/23/16 8:03 PM, Lars Wendler wrote:
>> I have some kind of interest for these packages:  
>
>Lars, maybe once we get some names we should get a meeting of
>base-system together and coordinate our efforts.  In particular, I
>mostly have interest in those packages that make up @system for the
>stages I build.
>

Guys, I'd like to take the opportunity to "revive" the #gentoo-base IRC
channel for coordination between base-system developers. 
Perhaps "revive" is not the appropriate word considering that the
channel never stopped to exist but rather became extinct.

Opinions?

Furthermore what about the devs currently being listed in base-system
team but stopped taking care of the team's packages for years?

Oh, and to all new team members:
Please keep in mind to *not* use EAPI-6 for base-system packages yet, so
we can retain a somewhat stable upgrade path even for very old systems.


Kind regards
Lars
-- 
Lars Wendler
Gentoo package maintainer
GPG: 21CC CF02 4586 0A07 ED93  9F68 498F E765 960E 9B39

Attention! New gpg key! See
https://www.gentoofan.org/blog/index.php?/archives/9-New-gpg-keys.html


pgpt6JCNU2Zft.pgp
Description: Digitale Signatur von OpenPGP

[gentoo-dev] Package up for grabs

[Lars Wendler]

This package is now up for grabs:
net-irc/rbot

-- 
Lars Wendler
Gentoo package maintainer
GPG: 21CC CF02 4586 0A07 ED93  9F68 498F E765 960E 9B39

Attention! New gpg key! See
https://www.gentoofan.org/blog/index.php?/archives/9-New-gpg-keys.html


pgpfOxyZA4prL.pgp
Description: Digitale Signatur von OpenPGP

Re: [gentoo-dev] base-system needs developers who care

[Lars Wendler]

On Tue, 23 Aug 2016 23:17:58 + Robin H. Johnson wrote:

>Over the years, the base-system package herd has grown in size. Today
>it comprises 320 packages, of which 61 of those have more than one
>maintainer. The packages with more than one maintainer I'm only
>concerned about if the other maintainer is also very busy or not
>available.
>
>Some of these packages are very niche, and while they continue to work,
>they could use a bit more attention than they get presently (you might
>only hear about them when they break and never when they work). 
>
>They are generally NOT broken and in need of tree-cleaning, but are
>just lacking forward momentum (not a few bugs are reasonable upstream
>bugs or feature improvements). Many were once shiny and had lots of
>people that cared, but that dwindled as they become mundane and just
>expected to work.
>
>General increase in the number of developers in base-system would not
>be a bad outcome from this email either ;-).
>
>Some of this is from stuff I know needs eyeballs, and others are where
>the package seems to have more than a few old bugs open.
>
>Packages in need of review & tweaks or just more eyeballs
>--
>app-admin/sudo (upstream?)
>app-admin/sysklogd- (upstream?)
>app-shells/bash (upstream?)
>dev-util/strace (upstream?)
>net-dialup/ppp
>net-firewall/iptables
>net-fs/nfs-utils (upstream?)
>net-misc/dhcpcd (upstream?)
>net-misc/dhcp (upstream?)
>net-misc/ntp (upstream?)
>net-misc/openssh 
>net-nds/rpcbind
>sys-apps/baselayout
>sys-apps/coreutils (upstream?)
>sys-apps/kbd (upstream?)
>sys-block/aoetools
>sys-block/iscsitarget
>sys-block/open-iscsi
>sys-block/thin-provisioning-tools
>sys-block/vblade
>sys-fs/lvm2 (mostly in regards to genkernel interaction)
>sys-fs/multipath-tools
>sys-fs/quota
>

I have some kind of interest for these packages:

app-admin/sudo
app-admin/sysklogd
app-shells/bash
net-dialup/ppp
net-firewall/iptables
net-misc/dhcpcd
net-misc/dhcp
net-misc/ntp
net-misc/openssh 
sys-apps/coreutils
sys-apps/kbd

But I think I cannot maintain all of them alone. So yeah, fresh
(active!) blood in base-system would be nice.

Kind regards
Lars

-- 
Lars Wendler
Gentoo package maintainer
GPG: 21CC CF02 4586 0A07 ED93  9F68 498F E765 960E 9B39

Attention! New gpg key! See
https://www.gentoofan.org/blog/index.php?/archives/9-New-gpg-keys.html


pgpukSXcsG7PA.pgp
Description: Digitale Signatur von OpenPGP

Re: [gentoo-dev] Developers, please work on underlinking issues!

[Lars Wendler]

On Thu, 18 Aug 2016 13:43:42 +0300 Andrew Savchenko wrote:

>Hi,
>
>On Wed, 17 Aug 2016 22:37:42 +0200 Michał Górny wrote:
>[...]
>> That said, I'd really like for Gentoo to be able to finally switch to
>> ld.gold by default.  
>
>It still has problems with kernel or kernel modules here and there.
>
>Also from my experience gold demands more memory on linking large
>binaries, thus it it unsuitable for low-memory setups.
>
>While gold indeed has its benefits, it is still too immature to
>become system default.

And as long as I keep reading such statements I won't use ld.gold
anywhere on my (dev-)systems. A linker IMHO is a far too crucial
toolchain component to blindly play around with.

>Best regards,
>Andrew Savchenko

Cheers
Lars

-- 
Lars Wendler
Gentoo package maintainer
GPG: 21CC CF02 4586 0A07 ED93  9F68 498F E765 960E 9B39

Attention! New gpg key! See
https://www.gentoofan.org/blog/index.php?/archives/9-New-gpg-keys.html


pgpQ0Dl2uKltV.pgp
Description: Digitale Signatur von OpenPGP

Re: [gentoo-dev] Electron external dependencies

[Lars Wendler]

On Wed, 17 Aug 2016 19:27:40 +0300 Alexander Revin wrote:

>Hello,
>
>Is there any plan to make electron more modular package? Right now it
>builds its own protobuf, mesa and v8 (and maybe much more). These
>packages do exist in a tree, maybe it's possible to reuse them?
>
>Regards,
>Alex

Hi Alex,

I suggest you open a bug about this in our bugzilla [1].

Use something like "dev-util/electron uses bundled libs" as subject and
describe the issue briefly.

Thanks.

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

-- 
Lars Wendler
Gentoo package maintainer
GPG: 21CC CF02 4586 0A07 ED93  9F68 498F E765 960E 9B39

Attention! New gpg key! See
https://www.gentoofan.org/blog/index.php?/archives/9-New-gpg-keys.html


pgpi4js7gcwAH.pgp
Description: Digitale Signatur von OpenPGP

Re: [gentoo-dev] Packages up for grabs

[Lars Wendler]

On Sat, 06 Aug 2016 13:36:54 +0200 Pacho Ramos wrote:

>This packages are now up for grabs:
>app-admin/keepassx
>media-sound/mumble
>media-sound/murmur
>
>

I gonna take all three packages.

-- 
Lars Wendler
Gentoo package maintainer
GPG: 21CC CF02 4586 0A07 ED93  9F68 498F E765 960E 9B39

Attention! New gpg key! See
https://www.gentoofan.org/blog/index.php?/archives/9-New-gpg-keys.html


pgpy1KQr1by5T.pgp
Description: Digitale Signatur von OpenPGP

Re: [gentoo-dev] Package up for grabs

[Lars Wendler]

On Sat, 28 May 2016 11:30:44 +0200 Pacho Ramos wrote:

>Because of maintainer retiring the following packages are up for grabs:
>app-admin/hwreport
>app-admin/tmpwatch
>app-misc/gramps
>app-portage/g-ctan
>net-misc/icaclient
>virtual/pager
>
>

I can take net-misc/icaclient as I need it for work.

Cheers
Lars

-- 
Lars Wendler
Gentoo package maintainer
GPG: 21CC CF02 4586 0A07 ED93  9F68 498F E765 960E 9B39

Attention! New gpg key! See
https://www.gentoofan.org/blog/index.php?/archives/9-New-gpg-keys.html


pgpL340DbFp9e.pgp
Description: Digitale Signatur von OpenPGP

Re: [gentoo-dev] Re: CVS headers in ebuilds

[Lars Wendler]

On Sat, 9 Apr 2016 12:12:44 +0200 Ole Reifschneider wrote:

>On Tue, Apr 05, 2016 at 12:30:15AM -0400, Jonathan Callen wrote:
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA512
>>
>> On 04/04/2016 02:58 AM, Lars Wendler wrote:  
>> > On Sun, 3 Apr 2016 22:57:42 +0200 Ulrich Mueller wrote:
>> >  
>> >> Does anyone still use the CVS $Id$ keywords that are in all
>> >> ebuilds' headers, or are they being expanded anywhere? Or is
>> >> there any other reason why they should be kept?
>> >>
>> >> In fact, the council had already voted to drop them in its
>> >> 20141014 meeting:
>> >>
>> >> Can we drop CVS headers post-migration? Aye: blueness, creffett
>> >> (proxy for ulm), dberkholz, dilfridge, radhermit, rich0, williamh
>> >>
>> >>
>> >> Ulrich  
>> >
>> > Yes, I still use these lines to check for ebuild changes between
>> > portage and my personal overlay. So please keep this line.
>> >
>> > Thanks.
>> >
>> > Lars
>> >  
>>
>> I do the same (after enabling expansion in .git/info/attributes on
>> just "*.ebuild", I can even get a quick diff of what changed in
>> gentoo.git to update my overlay).
>>  
>
>Sounds cool. Can you please explain in more detail how you do this?
>
>Ole
>

Enable the ident feature for *.ebuild files in git:

  $ cat ~/gentoo/.git/info/attributes
  *.ebuild ident

Now re-checkout every ebuild you wanna track. 

  $ git checkout -- ~/gentoo/www-client/seamonkey/seamonkey-2.40.ebuild

Once you have done that those ebuilds will have some hash in the $Id$
field:

  $ grep '$Id' ~/gentoo/www-client/seamonkey/seamonkey-2.40.ebuild
  # $Id: 5ecd7709c6c8a316d9f005b4e4a0a54da81eb048 $

The same hash is in each corresponding ebuild in my personal overlay as
well. Occasionally I run a script to compare ebuilds from my overlay
with the one from the git tree. When the hash is different something in
the gentoo ebuild has changed and I can decide if I want to apply these
changes to ebuilds in my overlay as well.

I hope this brief explanation is sufficient.

Kind regards
Lars

-- 
Lars Wendler
Gentoo package maintainer
GPG: 21CC CF02 4586 0A07 ED93  9F68 498F E765 960E 9B39

Attention! New gpg key! See (self signed server cert for now)
http://www.gentoofan.org/blog/index.php?/archives/9-New-gpg-keys.html


pgpjQtsVSDtLY.pgp
Description: Digitale Signatur von OpenPGP

Re: [gentoo-dev] CVS headers in ebuilds

[Lars Wendler]

On Sun, 3 Apr 2016 22:57:42 +0200 Ulrich Mueller wrote:

>Does anyone still use the CVS $Id$ keywords that are in all ebuilds'
>headers, or are they being expanded anywhere? Or is there any other
>reason why they should be kept?
>
>In fact, the council had already voted to drop them in its 20141014
>meeting:
>
>   Can we drop CVS headers post-migration?
>   Aye: blueness, creffett (proxy for ulm), dberkholz, dilfridge,
>   radhermit, rich0, williamh 
>
>Ulrich

Yes, I still use these lines to check for ebuild changes between
portage and my personal overlay. So please keep this line.

Thanks.

Lars

-- 
Lars Wendler
Gentoo package maintainer
GPG: 21CC CF02 4586 0A07 ED93  9F68 498F E765 960E 9B39

Attention! New gpg key! See (self signed server cert for now)
http://www.gentoofan.org/blog/index.php?/archives/9-New-gpg-keys.html


pgpclkVFNS3fO.pgp
Description: Digitale Signatur von OpenPGP

Re: [gentoo-dev] Packages up for grab

[Lars Wendler]

On Thu, 31 Mar 2016 12:21:08 +0100 Tony Vroon wrote:

>On 31/03/16 12:17, Alexey Shvetsov wrote:
>> net-libs/libmbim
>> net-libs/libqmi
>> sys-apps/gptfdisk  

Please don't remove me from gptfdisk when you add yourself. I am still
interested in the package and have no plans to drop myself as
maintainer :)

>These are of interest. I'll take them.
>
>Regards,
>Tony V.
>
>
>



-- 
Lars Wendler
Gentoo package maintainer
GPG: 21CC CF02 4586 0A07 ED93  9F68 498F E765 960E 9B39

Attention! New gpg key! See (self signed server cert for now)
http://www.gentoofan.org/blog/index.php?/archives/9-New-gpg-keys.html


pgpEGuGQu8Ww1.pgp
Description: Digitale Signatur von OpenPGP

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

[Lars Wendler]

On Sun, 14 Feb 2016 13:10:07 +0100 Patrick Lauer wrote:

>On 02/09/2016 01:17 PM, Rich Freeman wrote:
>> On Tue, Feb 9, 2016 at 3:43 AM, Kent Fredric <kentfred...@gmail.com>
>> wrote: 
>>> And a lot of Gentoo is surprisingly simple: Like our use of bash
>>> scripts for recipies to build things, like using rsync to
>>> deploy/relay not just those recipies, but security notices and
>>> news items, which are themselves reasonably simple formats.  
>> Well, one thing about Gentoo that certainly isn't simple is our
>> init.d scripts.
>>
>> Compare this:
>> http://pastebin.com/sSDtpF4t  
>More stable link:
>https://gitweb.gentoo.org/proj/apache.git/tree/2.4/init/apache2.initd
>>
>> With this:
>> http://pastebin.com/Lfn8r7qP  
>More stable link:
>https://gitweb.gentoo.org/repo/gentoo.git/tree/www-servers/apache/files/apache2.2.service
>> Systemd does the job in 10% of the code (and half of it is a
>> comment), and doesn't implement its own service polling and killer
>> script during shutdown independently for every service (not that
>> every init.d script even does this - most of them will just leave
>> orphans behind, and systemd will catch orphans that even the lengthy
>> init.d script for apache misses).
>>  
>Right, that's a bad comparison.
>
>The equivalent OpenRC init script is:
>
>```
>#!/sbin/runscript
>command="/usr/sbin/apache2"
>command_args="${APACHE2_OPTS}"
>description_reload="A graceful restart advises the children to exit
>after the current request and reloads the configuration."
>
>stop() {
>$command $APACHE2_OPTS -k graceful-stop
>}
>reload() {
>$command $APACHE2_OPTS -k graceful
>}
>```
>So that's almost exactly the same (modulo braces and newlines). There's
>no equivalent for PrivateTmp, and we ignore the extra data in
>/etc/tmpfiles.d (for creating runtime dirs). Which is bad, but that's
>another rant ;)
>
>Just that the current initscript does a lot more, and ... uhm ... why
>is the systemd unit sourcing /etc/conf.d/apache2 ?

Becasue I don't give a damn about systemd and nobody cared to send
patches yet.

>(Oh, and dependencies, but those just slow down startup )
>
>So if you compile the equivalent naive init script there's not much
>difference, and the initial argument falls on its face and disappears.
>
>I'm getting tired of having this argument :)
>

-- 
Lars Wendler
Gentoo package maintainer
GPG: 21CC CF02 4586 0A07 ED93  9F68 498F E765 960E 9B39

Attention! New gpg key! See (self signed server cert for now)
http://www.gentoofan.org/blog/index.php?/archives/9-New-gpg-keys.html


pgpcf9zp1NjJS.pgp
Description: Digitale Signatur von OpenPGP

Re: [gentoo-dev] Herd likely up for grabs: kernel-misc

[Lars Wendler]

Hi guys,

On Wed, 20 Jan 2016 13:40:04 -0500 Mike Frysinger wrote:

>On 20 Jan 2016 12:39, Rich Freeman wrote:
>> On Wed, Jan 20, 2016 at 12:34 PM, Mike Frysinger <vap...@gentoo.org>
>> wrote:  
>> > On 18 Jan 2016 00:57, Joshua Kinard wrote:  
>> >> On 01/17/2016 14:57, Michał Górny wrote:  
>> >> > sys-apps/kexec-tools :  
>> >>
>> >> Better suited for base-system, maybe?
>> >>  
>> >> > sys-fs/jfsutils  :  
>> >>
>> >> Definitely base-system, as xfsprogs is already maintained by
>> >> them.  
>> >
>> > sounds fine for both.  generally fs tools probably should live
>> > under base-system for consistency.  
>> 
>> Nothing wrong with consistency, but I'd prefer a package to be placed
>> under the base-system project because the base-system project members
>> intend to maintain it.  I don't want to see packages placed into
>> projects simply because they're similar to other packages in those
>> projects if it means they'll just be neglected.
>> 
>> I have no idea which is the case here.  If the base-system
>> maintainers want to maintain these two packages, have at it!  If
>> not, leave it as maintainer-needed.  
>
>if base-system@ isn't going to maintain it, we'll punt it from the herd
>-mike

well, I already added myself as maintainer of sys-fs/jfsutils and I
happen to be a base-system maintainer. So goal already reached :)

Kind regards
Lars

-- 
Lars Wendler
Gentoo package maintainer
GPG: 21CC CF02 4586 0A07 ED93  9F68 498F E765 960E 9B39

Attention! New gpg key! See (self signed server cert for now)
http://www.gentoofan.org/blog/index.php?/archives/9-New-gpg-keys.html


pgpzZ8_9nS1tr.pgp
Description: Digitale Signatur von OpenPGP

Re: [gentoo-dev] Herd up for grabs: net-dialup

[Lars Wendler]

Hi Mike,

On Wed, 20 Jan 2016 12:32:02 -0500 Mike Frysinger wrote:

>On 17 Jan 2016 21:57, Lars Wendler wrote:
>> I am going to take the following packages:
>> 
>> net-dialup/mingetty
>> net-dialup/ppp
>> net-dialup/rp-pppoe
>> 
>> I think that I might not be the perfect maintainer for these packages
>> (especially for ppp) so if anyone else wants to maintain these, feel
>> free to add yourself as well.  
>
>how about moving those to base-system@ ?

Sounds good. I already added myself to the packages, so please don't
just replace me yet.

>for the low level serial ones, we can move them to embedded since they
>get way more use there nowadays than w/dialup modems.
>app-misc/ckermit
>net-dialup/lrzsz
>net-dialup/minicom
>net-dialup/picocom
>net-dialup/xc
>-mike

Kind regards
Lars

-- 
Lars Wendler
Gentoo package maintainer
GPG: 21CC CF02 4586 0A07 ED93  9F68 498F E765 960E 9B39

Attention! New gpg key! See (self signed server cert for now)
http://www.gentoofan.org/blog/index.php?/archives/9-New-gpg-keys.html


pgpvzBs59BVNV.pgp
Description: Digitale Signatur von OpenPGP

Re: [gentoo-dev] Re: News item: Upgrading Apache from 2.2 to 2.4

[Lars Wendler]

Hi Dirkjan,

make it part of the news item please.

Kind regards
Lars

On Wed, 20 Jan 2016 13:16:19 +0100 Dirkjan Ochtman wrote:

>On Wed, Jan 13, 2016 at 6:13 PM, Dirkjan Ochtman <d...@gentoo.org>
>wrote:
>> After what feels like ages, we're just about ready to stabilize
>> apache-2.4. Since this is a major upgrade that in many cases require
>> configuration changes, we wanted to do a news item. After some
>> discussion with Lars (Poly-C), here's an initial attempt at a
>> draft.  
>
>I'm currently attempting this upgrade on a stable system I run. It
>mostly just works, although I run into trouble when trying to load
>modules that are not part of www-server/apache (e.g. mod_wsgi). I
>resolved this by reemerging all packages listed in `equery b
>/usr/lib/apache2/modules/*`, but maybe there's a different way? Should
>this be in an elog message, or part of the news item?
>
>Cheers,
>
>Dirkjan
>



-- 
Lars Wendler
Gentoo package maintainer
GPG: 21CC CF02 4586 0A07 ED93  9F68 498F E765 960E 9B39

Attention! New gpg key! See (self signed server cert for now)
http://www.gentoofan.org/blog/index.php?/archives/9-New-gpg-keys.html


pgpHvwXWc7nfa.pgp
Description: Digitale Signatur von OpenPGP

Re: [gentoo-dev] Herd likely up for grabs: net-im

[Lars Wendler]

Hello list,

I am going to take these packages:

net-libs/libotr
x11-plugins/pidgin-otr

Kind regards
Lars


On Sun, 17 Jan 2016 21:15:04 +0100 Michał Górny wrote:

>Hello, everyone.
>
>The current maintainers of net-im herd so far haven't replied to
>our queries (mrueg has withdrawn his project proposal). If we don't get
>any reply in a week, we will be disbanding it and looking for new
>maintainers for its packages.
>
>Is anyone interested in keeping the herd as a whole and maintaining all
>of its packages? If nobody replies till 2016-01-24, the herd will be
>automatically disbanded and I will be sending a complete list of
>packages needing maintainers.
>
>Packages currently in herd along with their other maintainers:
>
>app-accessibility/pidgin-festival : accessibility
>dev-libs/iksemel : 
>dev-tcltk/tktray : tcltk
>net-im/ayttm : 
>net-im/climm : 
>net-im/corebird  : proxy-maintainers,
>thatsly...@gmail.com, markparie...@gmail.com
>net-im/cpop  : net-im/ejabberd  : 
>net-im/gajim : aidecoe@
>net-im/gg-transport  : 
>net-im/jabber-base   : chainsaw@
>net-im/jabberd2  : 
>net-im/kadu  : reavertm@
>net-im/licq  : polynomial-c@
>net-im/mcabber   : wschlich@
>net-im/mu-conference : 
>net-im/openfire  : slyfox@
>net-im/pidgin: polynomial-c@
>net-im/psi   : proxy-maintainers, nik...@gmx.us
>net-im/psimedia  : proxy-maintainers, nik...@gmx.us
>net-im/pyaim-t   : proxy-maintainers, volk...@gmail.com
>net-im/pyicq-t   : 
>net-im/reaim : 
>net-im/sendxmpp  : 
>net-im/simpserver-bin: 
>net-im/telepathy-mission-control : gnome
>net-im/tkabber   : 
>net-im/ysm   : 
>net-irc/telepathy-idle   : gnome
>net-libs/gloox   : 
>net-libs/libgadu : reavertm@
>net-libs/libotr  : 
>net-libs/libyahoo2   : 
>x11-plugins/guifications : 
>x11-plugins/pidgin-birthday-reminder : hasufell@
>x11-plugins/pidgin-encryption : 
>x11-plugins/pidgin-extprefs  : 
>x11-plugins/pidgin-hotkeys   : 
>x11-plugins/pidgin-latex : 
>x11-plugins/pidgin-libnotify : 
>x11-plugins/pidgin-mpris : chainsaw@
>x11-plugins/pidgin-musictracker : 
>x11-plugins/pidgin-opensteamworks : hasufell@, mrueg@
>x11-plugins/pidgin-otr   : 
>x11-plugins/pidgin-rhythmbox : 
>x11-plugins/pidgin-sipe  : thev00d00@
>x11-plugins/pidgintex: 
>x11-plugins/purple-plugin_pack : 
>
>



-- 
Lars Wendler
Gentoo package maintainer
GPG: 21CC CF02 4586 0A07 ED93  9F68 498F E765 960E 9B39

Attention! New gpg key! See (self signed server cert for now)
http://www.gentoofan.org/blog/index.php?/archives/9-New-gpg-keys.html


pgpMiM3H8RDNT.pgp
Description: Digitale Signatur von OpenPGP

Re: [gentoo-dev] Herd up for grabs: net-dialup

[Lars Wendler]

Hi list,

I am going to take the following packages:

net-dialup/mingetty
net-dialup/ppp
net-dialup/rp-pppoe

I think that I might not be the perfect maintainer for these packages
(especially for ppp) so if anyone else wants to maintain these, feel
free to add yourself as well.

Kind regards
Lars


On Sat, 16 Jan 2016 18:30:01 +0100 Michał Górny wrote:

>Hello, everyone.
>
>The current maintainer(s) of net-dialup herd has decided that he's
>(they're) not interested in keeping it and would like the packages
>to be dropped to maintainer-needed.
>
>Is anyone interested in keeping the herd as-is and maintaining all
>packages in it? If I get no reply till 2016-01-24, I will effectively
>remove the herd and announce the packages that landed in maintainer-
>-needed as a result.
>
>Packages currently in herd, along with their other maintainers:
>
>net-dialup/accel-ppp : pinkbyte@
>net-dialup/capi4k-utils  : 
>net-dialup/capidivert: 
>net-dialup/capifwd   : 
>net-dialup/capisuite : 
>net-dialup/cistronradius : 
>net-dialup/cutecom   : 
>net-dialup/dial  : 
>net-dialup/diald : 
>net-dialup/drdsl : 
>net-dialup/dtrace: sbriesen@
>net-dialup/dwun  : 
>net-dialup/fbgetty   : 
>net-dialup/fcpci : 
>net-dialup/freeradius: 
>net-dialup/freeradius-client : 
>net-dialup/globespan-adsl: 
>net-dialup/gnuradius : 
>net-dialup/gtkterm   : 
>net-dialup/hcfpcimodem   : 
>net-dialup/isdn-firmware : 
>net-dialup/itund : 
>net-dialup/kpnadsl4linux : 
>net-dialup/linux-atm : 
>net-dialup/lrzsz : 
>net-dialup/mgetty: 
>net-dialup/mingetty  : 
>net-dialup/minicom   : 
>net-dialup/mwavem: 
>net-dialup/picocom   : flameeyes@
>net-dialup/ppp   : 
>net-dialup/pppconfig : 
>net-dialup/ppp-scripts   : 
>net-dialup/pptpclient: 
>net-dialup/pptpd : 
>net-dialup/qtwvdialer: 
>net-dialup/radiusclient  : 
>net-dialup/radiusclient-ng   : 
>net-dialup/rp-l2tp   : 
>net-dialup/rp-pppoe  : 
>net-dialup/sendpage  : 
>net-dialup/sercd : 
>net-dialup/speedtouch-usb: 
>net-dialup/tkvoice   : 
>net-dialup/ueagle4-atm   : 
>net-dialup/ueagle-atm: 
>net-dialup/wvdial: 
>net-dialup/xc: 
>net-dialup/xl2tpd: floppym@
>net-dns/pdnsd: polynomial-c@
>net-libs/libcapi : 
>net-libs/wvstreams   : 
>net-misc/capiisdnmon : 
>net-misc/hylafaxplus : mattm@
>net-misc/iaxmodem: 
>net-misc/termpkg : 
>www-apps/freeradius-dialupadmin : 
>



-- 
Lars Wendler
Gentoo package maintainer
GPG: 21CC CF02 4586 0A07 ED93  9F68 498F E765 960E 9B39

Attention! New gpg key! See (self signed server cert for now)
http://www.gentoofan.org/blog/index.php?/archives/9-New-gpg-keys.html


pgpdwCPsKEAjk.pgp
Description: Digitale Signatur von OpenPGP

Re: [gentoo-dev] Herd likely up for grabs: kernel-misc

[Lars Wendler]

Hello list,

I am going to take these packages:

sys-fs/jfsutils
sys-process/schedtool


Kind regards
Lars

On Sun, 17 Jan 2016 20:57:50 +0100 Michał Górny wrote:

>Hello, everyone.
>
>The current maintainers of kernel-misc herd so far haven't replied to
>our queries. If we don't get any reply in a week, we will be disbanding
>it and looking for new maintainers for its packages.
>
>Is anyone interested in keeping the herd as a whole and maintaining all
>of its packages? If nobody replies till 2016-01-24, the herd will be
>automatically disbanded and I will be sending a complete list of
>packages needing maintainers.
>
>Packages currently in herd along with their other maintainers:
>
>app-doc/linux-device-drivers : 
>app-misc/fdutils : 
>app-misc/zisofs-tools: 
>dev-libs/klibc   : 
>sys-apps/kexec-tools : 
>sys-devel/smatch : toolchain
>sys-devel/sparse : toolchain
>sys-fs/avfs  : proxy-maintainers, pete4...@comcast.net
>sys-fs/ecryptfs-utils: crypto
>sys-fs/fuse  : radhermit@
>sys-fs/jfsutils  : 
>sys-fs/lufis : 
>sys-fs/siefs : 
>sys-fs/sshfs-fuse: radhermit@
>sys-kernel/linux-docs: mpagano@
>sys-power/cpupower   : ssuominen@, floppym@
>sys-process/schedtool: 
>
>



-- 
Lars Wendler
Gentoo package maintainer
GPG: 21CC CF02 4586 0A07 ED93  9F68 498F E765 960E 9B39

Attention! New gpg key! See (self signed server cert for now)
http://www.gentoofan.org/blog/index.php?/archives/9-New-gpg-keys.html


pgp4OOB4GdMUn.pgp
Description: Digitale Signatur von OpenPGP

Re: [gentoo-dev] News item: Apache "-D PHP5" needs update to "-D PHP"

[Lars Wendler]

Hi Sebastian,

to be honest I was very upset when I first stumbled upon this problem.
And yes I only found about it when my apache webserver started to
deliver php source code instead of the real sites.
Doing such a change without getting in contact with me as apache
maintainer before the change was done is very... eh... impolite at best.

Kind regards
Lars

On Mon, 4 Jan 2016 01:26:28 +0100 Sebastian Pipping wrote:

>Hi!
>
>
>Better late then never.  Posting 72 hours from now the earliest as
>advised by GLEP 42.  Feedback welcome as usual.
>
>
>===
>Title: Apache "-D PHP5" needs update to "-D PHP"
>Author: Sebastian Pipping <sp...@gentoo.org>
>Content-Type: text/plain
>Posted: 2016-01-04
>Revision: 1
>News-Item-Format: 1.0
>Display-If-Installed: app-eselect/eselect-php[apache2]
>
>With >=app-eselect/eselect-php-0.8.1, to enable PHP support
>for Apache 2.x file /etc/conf.d/apache2 no longer
>needs to read
>
>  APACHE2_OPTS=". -D PHP5"
>
>but
>
>  APACHE2_OPTS=". -D PHP"
>
>, i.e. without "5" at the end.  This change is related to
>unification in context of the advent of PHP 7.x.
>
>With that change, guard "" in file
>/etc/apache2/modules.d/70_mod_php.conf
>has a chance to actually pull in PHP support.
>
>Without updating APACHE2_OPTS, websites could end up serving
>PHP code (include configuration files with passwords)
>unprocessed to website visitors!
>
>
>The origin of this news item is:
>https://bugs.gentoo.org/show_bug.cgi?id=569042
>===
>
>
>Best
>
>
>
>Sebastian
>



-- 
Lars Wendler
Gentoo package maintainer
GPG: 21CC CF02 4586 0A07 ED93  9F68 498F E765 960E 9B39

Attention! New gpg key! See (self signed server cert for now)
http://www.gentoofan.org/blog/index.php?/archives/9-New-gpg-keys.html


pgpbxIWSGPW86.pgp
Description: Digitale Signatur von OpenPGP

Re: [gentoo-dev] samba (and related) packages are in desperate need of help

[Lars Wendler]

On Wed, 2 Sep 2015 21:23:24 +0200 Paweł Hajdan, Jr. wrote:

>On 9/1/15 3:24 PM, Lars Wendler wrote:
>> * samba upstream is extremely uncooperative. Best example is that we
>>   still have some automagic dependencies [5] in samba's build system
>> and upstream is not very keen on fixing these.
>> 
>> [...]
>>
>> [5] https://bugs.gentoo.org/489748
>> https://bugs.gentoo.org/489770
>
>I don't see any references to upstream bug reports, and so no evidence
>of upstream being uncooperative.
>
>Are there any public links that you could share?

Sorry, I forgot about the mails I sent to samba upstream [1]

Regards
Lars

>Paweł
>
>

[1]
http://samba-technical.samba.narkive.com/9UGYmeiG/patch-samba-4-0-automagically-depends-on-dmapi-libdm-so

-- 
Lars Wendler
Gentoo package maintainer
GPG: 4DD8 C47C CDFA 5295 E1A6 3FC8 F696 74AB 981C A6FC


pgpWBWYgd1bxc.pgp
Description: Digitale Signatur von OpenPGP

Re: [gentoo-dev] samba (and related) packages are in desperate need of help

[Lars Wendler]

Hey all,

seems like I need to correct one of my previous said statements.
Please see below:

On Tue, 1 Sep 2015 15:24:05 +0200 Lars Wendler wrote:

>Hey community,
>
>for a way too long time Gentoo's samba packages lack the attention they
>would require to keep them top notch and as useful as possible for our
>users.
>
>The reason I started to take minimum care of our samba packages was
>because my former employer used Gentoo on his Linux server (guess
>why? :D) and as there were also samba servers among them I had slight
>interest in Gentoo's samba packages to be at least up to date on
>a security point of view.
>After I started work for my new employer this interest lowered even
>more and all I am doing right now is simple version bumps on all samba
>(and related) packages nobody else seems to take care of.
>The situation in Gentoo became even worse when upstream discontinued
>the 3.6.x series which still is the only samba version in Gentoo that
>is multilib capable.
>Given this fact I decided to unmask samba-4.0 and samba-4.1 series
>although both still suffering from two major problems:
>
>* Until now all samba-4 packages are not multilib ready [1]
>
>* samba-4 packages require heimdal, a kerberos implementation that
>  unfortunately cannot be installed in parallel with mit-krb5 package
>  [2]

This seems to be no longer true. I've added samba-4.2.4-r1 with
"system-mitkrb5" USE flag to portage today.

>So here comes a really seriously meant call for help:
>Gyus, if you _are_ interested in samba then please try to invest time
>and knowledge so we can make Gentoo's samba packages better.
>
>To be honest there are some trip wires that make solutions to the two
>above mentioned problems (and possibly others) a bit difficult:
>
>* samba upstream is extremely uncooperative. Best example is that we
>  still have some automagic dependencies [5] in samba's build system
> and upstream is not very keen on fixing these.

And the upstream reference [6]

>* samba (and related) packages are using waf as build system. One of
>  the most ugliest build systems I ever had the bad luck to be involved
>  with.
>
>* To make samba-4 (and related) packages multilib ready, we might need
>  to make python multilib ready first. I'm not sure this requirement is
>  still necessary - we should ask mgorny about this :)
>
>* We should really get heimdal and mit-krb5 packages in a shape where
>  we can install them in parallel [2]. Using the bundled heimdal from
>  samba is no valid option [3]

See above. Should no longer be a pressing requirement. Of course it
would still be nice to have.

>* Stabilization of samba-4 still needs to go a long road [4]
>
>
>Once again, we need your help so please help. If you are willing to do
>so and have no commit access, well... I have and as long as the
>contributions from any volunteer meet the Gentoo standards I am more
>than happy to commit any improvements as proxy maintainer. If they
>don't meet the standards, I'm quite sure we can work those issues out
>together.
>
>
>Kind regards
>Lars
>
>
>[1] https://bugs.gentoo.org/534432
>[2] https://bugs.gentoo.org/490872
>https://bugs.gentoo.org/542462
>[3] https://wiki.gentoo.org/wiki/Why_not_bundle_dependencies
>[4] https://bugs.gentoo.org/489762
>[5] https://bugs.gentoo.org/489748
>https://bugs.gentoo.org/489770
>
[6]
http://samba-technical.samba.narkive.com/9UGYmeiG/patch-samba-4-0-automagically-depends-on-dmapi-libdm-so

Kind regards
Lars

-- 
Lars Wendler
Gentoo package maintainer
GPG: 4DD8 C47C CDFA 5295 E1A6 3FC8 F696 74AB 981C A6FC


pgpbCrqntlReJ.pgp
Description: Digitale Signatur von OpenPGP