[gentoo-dev] Package up for grabs: app-portage/tatt

[Michael Palimaka]

app-portage/tatt is up for grabs as unfortunately I don't have time to 
look after it anymore.


There's two open bugs about the behaviour of the tool.

[gentoo-dev] Package up for grabs: app-forensics/rkhunter

[Michael Palimaka]

Feel free to pick it up if interested.

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

[Michael Palimaka]

# Michael Palimaka  (2020-12-13)
# Buggy. Uncooperative upstream.
# Masked for removal in 30 days.
x11-misc/albert

[gentoo-dev] Re: stable-bot is down. Temporary? Forever? Can we have a contacts page for it?

[Michael Palimaka]

On 10/8/19 7:21 AM, Andreas K. Huettel wrote:

In any case, since many people *do* rely on it, maybe we should declare it
official? [+]

And, if that's OK with both of you, move it onto infra hardware?

Happy to sponsor both for the next council meeting agenda.


[+] At some point the one remaining whiner doesnt count anymore.



In the past, infra has been understandably hesitant to take on new 
services due to staffing issues.


Additionally, I understand that the current infra design does not easily 
allow granular access control, preventing non-infra members from easily 
performing maintenance on individual services.


Has this situation changed? I doubt infra want to take responsibility 
for the bot, and I don't fancy the hassle of trying to find people to 
poke things on my behalf.

[gentoo-dev] Re: stable-bot is down. Temporary? Forever? Can we have a contacts page for it?

[Michael Palimaka]

On 10/4/19 5:32 AM, Robin H. Johnson wrote:

On Wed, Oct 02, 2019 at 08:43:44AM -0700, Matt Turner wrote:

On Thu, Sep 26, 2019 at 12:29 AM Sergei Trofimovich  wrote:


I noticed that stable-bot stopped marking bugs as verified for stbilization.
Example:

...

It looks like it is working now, but I think we really should know a few things:

(1) Who maintains it
(2) Where the code is
(3) and perhaps what happened to bring it down

It's a pretty important piece of infrastructure that we've come to
rely on, so it should be treated as such.

Can I take this opportunity to ask people to help populate the Service
Catalog?
https://wiki.gentoo.org/wiki/Project:Infrastructure/Service_Catalog



Is it appropriate to list services that are not managed by infra on this 
page?

[gentoo-dev] Re: stable-bot is down. Temporary? Forever? Can we have a contacts page for it?

[Michael Palimaka]

Sorry for the late reply here.

On 10/3/19 1:43 AM, Matt Turner wrote:

On Thu, Sep 26, 2019 at 12:29 AM Sergei Trofimovich  wrote:


I noticed that stable-bot stopped marking bugs as verified for stbilization.
Example:
 https://bugs.gentoo.org/695252

1. Is it gone forever and arch teams should stop relying on it's presence?


There was some temporary, unintentional breakage which regrettably I did 
not notice. Thanks to whissi for pinging me.



2. If not can the owner tweak it?


stable-bot has since returned to normal service.


3. Can we have a wiki page that describes the setup and who to send reports to?
Doc would be useful to run it locally, send bugs/enhancements, post current
status if it's known to be broken.


I agree, this is long overdue.


It looks like it is working now, but I think we really should know a few things:

(1) Who maintains it


That is me.


(2) Where the code is
Due to slacking on my part, the code currently just lives on my server. 
The intention has always been to clean it up and publish it with the 
client at https://github.com/kensington/bugbot.



(3) and perhaps what happened to bring it down
vixie-cron got last-rited and I neglected to configure its placement 
correctly.

[gentoo-dev] [PATCH] ssl-cert.eclass: allow EAPI=7

[Michael Palimaka]

---
 eclass/ssl-cert.eclass | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/eclass/ssl-cert.eclass b/eclass/ssl-cert.eclass
index b5b4250ef22..01783b75848 100644
--- a/eclass/ssl-cert.eclass
+++ b/eclass/ssl-cert.eclass
@@ -18,7 +18,7 @@ case "${EAPI:-0}" in
0)
die "${ECLASS}.eclass: EAPI=0 is not supported.  Please upgrade 
to EAPI >= 1."
;;
-   1|2|3|4|5|6)
+   1|2|3|4|5|6|7)
;;
*)
die "${ECLASS}.eclass: EAPI=${EAPI} is not supported yet."
-- 
2.21.0

[gentoo-dev] Re: [PATCH 1/2] acct-group/unrealircd: new group (495)

[Michael Palimaka]

On 8/4/19 10:36 PM, Hasan Calisir wrote:

Thank you.

FYI

https://wiki.gentoo.org/wiki/Project:Quality_Assurance/UID_GID_Assignment

439 ldap fixed id used in old packages
450 firebird fixed id used in old packages
495 gvm assignment requested
*496 strelaysrv acct-group/strelaysrv*
497 stdiscosrv acct-group/stdiscosrv
498 burp acct-group/burp
499 syncthing acct-group/syncthing


On 8/4/19 8:00 PM, Hasan ÇALIŞIR wrote:

I have a request waiting for "gvm" user on ID 495 ??

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


I have updated my local branch to use 496 instead.



Thanks! I'm clearly having a bad day today.

Local branch updated to *494*.

[gentoo-dev] Re: [PATCH 1/2] acct-group/unrealircd: new group (495)

[Michael Palimaka]

On 8/4/19 8:00 PM, Hasan ÇALIŞIR wrote:

I have a request waiting for "gvm" user on ID 495 ??

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


I have updated my local branch to use 496 instead.

[gentoo-dev] [PATCH 2/2] acct-user/unrealircd: new user (495)

[Michael Palimaka]

Package-Manager: Portage-2.3.69, Repoman-2.3.16
Signed-off-by: Michael Palimaka 
---
 acct-user/unrealircd/metadata.xml|  7 +++
 acct-user/unrealircd/unrealircd-0.ebuild | 11 +++
 2 files changed, 18 insertions(+)
 create mode 100644 acct-user/unrealircd/metadata.xml
 create mode 100644 acct-user/unrealircd/unrealircd-0.ebuild

diff --git a/acct-user/unrealircd/metadata.xml 
b/acct-user/unrealircd/metadata.xml
new file mode 100644
index 000..69570e84932
--- /dev/null
+++ b/acct-user/unrealircd/metadata.xml
@@ -0,0 +1,7 @@
+
+http://www.gentoo.org/dtd/metadata.dtd;>
+
+   
+   kensing...@gentoo.org
+   
+
diff --git a/acct-user/unrealircd/unrealircd-0.ebuild 
b/acct-user/unrealircd/unrealircd-0.ebuild
new file mode 100644
index 000..3fa0f9074b4
--- /dev/null
+++ b/acct-user/unrealircd/unrealircd-0.ebuild
@@ -0,0 +1,11 @@
+# Copyright 2019 Gentoo Authors
+# Distributed under the terms of the GNU General Public License v2
+
+EAPI=7
+
+inherit acct-user
+
+ACCT_USER_ID=495
+ACCT_USER_GROUPS=( unrealircd )
+
+acct-user_add_deps
-- 
2.21.0

[gentoo-dev] [PATCH 1/2] acct-group/unrealircd: new group (495)

[Michael Palimaka]

Package-Manager: Portage-2.3.69, Repoman-2.3.16
Signed-off-by: Michael Palimaka 
---
 acct-group/unrealircd/metadata.xml| 7 +++
 acct-group/unrealircd/unrealircd-0.ebuild | 8 
 2 files changed, 15 insertions(+)
 create mode 100644 acct-group/unrealircd/metadata.xml
 create mode 100644 acct-group/unrealircd/unrealircd-0.ebuild

diff --git a/acct-group/unrealircd/metadata.xml 
b/acct-group/unrealircd/metadata.xml
new file mode 100644
index 000..69570e84932
--- /dev/null
+++ b/acct-group/unrealircd/metadata.xml
@@ -0,0 +1,7 @@
+
+http://www.gentoo.org/dtd/metadata.dtd;>
+
+   
+   kensing...@gentoo.org
+   
+
diff --git a/acct-group/unrealircd/unrealircd-0.ebuild 
b/acct-group/unrealircd/unrealircd-0.ebuild
new file mode 100644
index 000..113279ff302
--- /dev/null
+++ b/acct-group/unrealircd/unrealircd-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=495
-- 
2.21.0

[gentoo-dev] Re: [PATCH] eclass/cmake-utils.eclass: restrict rpath hack to Prefix/rpath

[Michael Palimaka]

On 7/12/19 3:14 AM, hero...@gentoo.org wrote:

From: Benda Xu 

   Prefix/standalone does not need it.
---
  eclass/cmake-utils.eclass | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/eclass/cmake-utils.eclass b/eclass/cmake-utils.eclass
index ea1858e9735f..109b584afb39 100644
--- a/eclass/cmake-utils.eclass
+++ b/eclass/cmake-utils.eclass
@@ -612,7 +612,7 @@ cmake-utils_src_configure() {
fi
fi
  
-	if [[ ${EPREFIX} ]]; then

+   if use prefix-guest; then
cat >> "${build_rules}" <<- _EOF_ || die
# in Prefix we need rpath and must ensure cmake gets 
our default linker path
# right ... except for Darwin hosts



This seems to break non-prefix builds, as the prefix-guest USE flag will 
not exist.

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

[Michael Palimaka]

# Michael Palimaka  (07 Mar 2019)
# Fails to build with ffmpeg-4 (bug #673352). Dead upstream.
# Masked for removal in 30 days.
media-sound/karlyriceditor

[gentoo-dev] Mailing list moderation and community openness

[Michael Palimaka]

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

[gentoo-dev] Re: Packages up for grabs

[Michael Palimaka]

On 03/11/2018 12:12 AM, Pacho Ramos wrote:
> This packages are now up for grabs:
...
> net-irc/unrealircd

I can take this one.

[gentoo-dev] Last rites: media-video/qt-recordmydesktop

[Michael Palimaka]

# Michael Palimaka <kensing...@gentoo.org> (07 Mar 2018)
# Depends on deprecated Qt 4. Dead upstream.
# Masked for removal in 30 days. Bug #649116.
media-video/qt-recordmydesktop

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

[Michael Palimaka]

# Michael Palimaka <kensing...@gentoo.org> (07 Mar 2018)
# Depends on deprecated Qt 4. Dead upstream.
# Masked for removal in 30 days. Bug #644424.
media-gfx/qosmic

[gentoo-dev] Re: [PATCH] cmake-utils.eclass: Override CMAKE_INSTALL_{INFO,MAN}DIR

[Michael Palimaka]

On 03/02/2018 02:40 AM, Michał Górny wrote:
> Provide an explicit override for CMAKE_INSTALL_INFODIR
> and CMAKE_INSTALL_MANDIR to force Gentoo standards for those locations.
> This is needed for Gentoo/FreeBSD where CMake defaults to /usr/info
> and /usr/man; while PMS specifies /usr/share/info and /usr/share/man
> via econf & do* helpers.
> ---
>  eclass/cmake-utils.eclass | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/eclass/cmake-utils.eclass b/eclass/cmake-utils.eclass
> index b9f69a824b14..636927d66491 100644
> --- a/eclass/cmake-utils.eclass
> +++ b/eclass/cmake-utils.eclass
> @@ -602,6 +602,8 @@ cmake-utils_src_configure() {
>   SET (CMAKE_GENTOO_BUILD ON CACHE BOOL "Indicate Gentoo package 
> build")
>   SET (LIB_SUFFIX ${libdir/lib} CACHE STRING "library path 
> suffix" FORCE)
>   SET (CMAKE_INSTALL_LIBDIR ${libdir} CACHE PATH "Output 
> directory for libraries")
> + set (CMAKE_INSTALL_INFODIR "${EPREFIX}/usr/share/info" CACHE 
> PATH "")
> + set (CMAKE_INSTALL_MANDIR "${EPREFIX}/usr/share/man" CACHE PATH 
> "")
>   _EOF_
>   [[ "${NOCOLOR}" = true || "${NOCOLOR}" = yes ]] && echo 'SET 
> (CMAKE_COLOR_MAKEFILE OFF CACHE BOOL "pretty colors during make" FORCE)' >> 
> "${common_config}"
>  
> 

There was some discussion in the past about adding these (and some
others), but at that time it was postponed until EAPI 7 due to concerns
about breaking existing packages. What do you think about the risk?

[gentoo-dev] Re: [PATCH] cmake-utils.eclass: Extend ASM rules to ASM-ATT

[Michael Palimaka]

On 02/25/2018 08:06 PM, Michał Górny wrote:
> Some CMake projects use ASM-ATT rather than ASM, so extend our rule
> overrides to that.
> 
> Bug: https://bugs.gentoo.org/625844
> ---
>  eclass/cmake-utils.eclass | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/eclass/cmake-utils.eclass b/eclass/cmake-utils.eclass
> index b9f69a824b14..ef3f3c2607f8 100644
> --- a/eclass/cmake-utils.eclass
> +++ b/eclass/cmake-utils.eclass
> @@ -516,6 +516,7 @@ cmake-utils_src_configure() {
>   fi
>   cat > "${build_rules}" <<- _EOF_ || die
>   SET (CMAKE_ASM_COMPILE_OBJECT "  
> ${includes} ${CPPFLAGS}  -o  -c " CACHE STRING "ASM 
> compile command" FORCE)
> + SET (CMAKE_ASM-ATT_COMPILE_OBJECT " 
>  ${includes} ${CPPFLAGS}  -o  -c " CACHE 
> STRING "ASM compile command" FORCE)
>   SET (CMAKE_C_COMPILE_OBJECT "  
> ${includes} ${CPPFLAGS}  -o  -c " CACHE STRING "C 
> compile command" FORCE)
>   SET (CMAKE_CXX_COMPILE_OBJECT "  
> ${includes} ${CPPFLAGS}  -o  -c " CACHE STRING "C++ 
> compile command" FORCE)
>   SET (CMAKE_Fortran_COMPILE_OBJECT " 
>  ${includes} ${FCFLAGS}  -o  -c " CACHE 
> STRING "Fortran compile command" FORCE)
> @@ -531,6 +532,7 @@ cmake-utils_src_configure() {
>   local toolchain_file=${BUILD_DIR}/gentoo_toolchain.cmake
>   cat > ${toolchain_file} <<- _EOF_ || die
>   SET (CMAKE_ASM_COMPILER "${myCC/ /;}")
> + SET (CMAKE_ASM-ATT_COMPILER "${myCC/ /;}")
>   SET (CMAKE_C_COMPILER "${myCC/ /;}")
>   SET (CMAKE_CXX_COMPILER "${myCXX/ /;}")
>   SET (CMAKE_Fortran_COMPILER "${myFC/ /;}")
> @@ -609,6 +611,7 @@ cmake-utils_src_configure() {
>   if [[ ${CMAKE_BUILD_TYPE} != Gentoo && ${EAPI} != 5 ]]; then
>   cat >> ${common_config} <<- _EOF_ || die
>   SET (CMAKE_ASM_FLAGS_${CMAKE_BUILD_TYPE^^} "" CACHE 
> STRING "")
> + SET (CMAKE_ASM-ATT_FLAGS_${CMAKE_BUILD_TYPE^^} "" CACHE 
> STRING "")
>   SET (CMAKE_C_FLAGS_${CMAKE_BUILD_TYPE^^} "" CACHE 
> STRING "")
>   SET (CMAKE_CXX_FLAGS_${CMAKE_BUILD_TYPE^^} "" CACHE 
> STRING "")
>   SET (CMAKE_Fortran_FLAGS_${CMAKE_BUILD_TYPE^^} "" CACHE 
> STRING "")
> 

LGTM

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

[Michael Palimaka]

# Michael Palimaka <kensing...@gentoo.org> (22 Feb 2018)
# Plugin for removed package media-sound/amarok. Dead upstream.
# Depends on vulnerable gstreamer:0.10.
# Masked for removal in 30 days. Bug #629184.
media-sound/moodbar

[gentoo-dev] Re: Lastrite: app-crypt/monkeysign

[Michael Palimaka]

On 02/12/2018 08:59 AM, Kristian Fiskerstrand wrote:
> # Kristian Fiskerstrand  (11 Feb 2018)
> # Lastrite: app-crypt/monkeysign . Please use caff from
> # app-crypt/signing-party instead. Removal in 30 days.
> # Bug: #647352
> app-crypt/monkeysign
> 

What's the reason for the removal?

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

[Michael Palimaka]

# Michael Palimamka  (11 Feb 2018
# Fails to build (bug #538400). Requires dead Qt 4 (bug #637014).
# Dead upstream. Masked for removal in 30 days.
media-sound/lastfmplayer

[gentoo-dev] Last rites: media-video/qx11grab

[Michael Palimaka]

# Michael Palimaka <kensing...@gentoo.org> (25 Jan 2018)
# Requires dead Qt 4. Dead upstream.
# Masked for removal in 30 days. Bug #644532.
media-video/qx11grab

[gentoo-dev] Re: News Item: Portage Dynamic Deps

[Michael Palimaka]

On 01/24/2018 12:15 AM, Michael Orlitzky wrote:
> On 01/23/2018 07:40 AM, Michael Palimaka wrote:
>>>
>>> Did you come up with a solution how to handle eclass-generated dependency 
>>> changes then?
>>
>> No.
>>
>> Bug #641346 was filed for clarification about this, but it just got
>> closed without answering the question or consulting anyone.
>>
>> Now, every time we want to make a minor change we need to revbump half
>> the tree due to a change that has been forced mostly by people not
>> actually involved in any actual ebuild maintenance.
> 
> You could always set "--dynamic-deps y" on your machine, and ignore the
> breakage caused to end users (i.e. the situation last week).

You mean the breakage caused by changing default options without any
consultation or notification?

[gentoo-dev] Re: News Item: Portage Dynamic Deps

[Michael Palimaka]

On 01/22/2018 09:28 PM, Andreas K. Huettel wrote:
> Am Montag, 22. Januar 2018, 08:01:08 CET schrieb Zac Medico:
>>
>> According to Gentoo policy, future ebuild dependency changes need to be
>> accompanied by a revision bump in order to trigger rebuilds for users.
>> Therefore, you should only need to use --changed-deps=y for a single
>> deep @world update. After that, if you encounter installed packages with
>> outdated dependencies in a future deep @world update, then you should
>> report it as a bug.
> 
> Did you come up with a solution how to handle eclass-generated dependency 
> changes then?

No.

Bug #641346 was filed for clarification about this, but it just got
closed without answering the question or consulting anyone.

Now, every time we want to make a minor change we need to revbump half
the tree due to a change that has been forced mostly by people not
actually involved in any actual ebuild maintenance.

[gentoo-dev] Re: Deleting old news items

[Michael Palimaka]

On 01/03/2018 11:13 AM, Alec Warner wrote:
> Problem:
> 
> New stages have numerous news items listed that are likely not relevant,
> but are shown due to limitations in the filtering in NEWS items. E.g. on
> a recent stage3:
> 
> nspawntest / # eselect news list
> News items:
>   [1]   N  2013-09-27  Separate /usr on Linux requires initramfs
>   [2]   N  2014-06-15  GCC 4.8.3 defaults to -fstack-protector
>   [3]   N  2014-10-26  GCC 4.7 Introduced the New C++11 ABI 
>   [4]   N  2015-02-02  New portage plug-in sync system
>   [5]   N  2015-07-25  Python 3.4 enabled by default
>   [6]   N  2015-08-13  OpenSSH 7.0 disables ssh-dss keys by default
>   [7]   N  2015-10-22  GCC 5 Defaults to the New C++11 ABI
>   [8]   N  2016-06-19  L10N USE_EXPAND variable replacing LINGUAS
>   [9]   N  2017-11-30  New 17.0 profiles in the Gentoo repository
> 
> Many of these are always displayed. For example:
> 
> https://gitweb.gentoo.org/data/gentoo-news.git/tree/2015-02-04-portage-sync-changes/2015-02-04-portage-sync-changes.en.txt
> 
> has "Display-If-Installed: sys-apps/portage" and will be displayed on
> nearly every Gentoo machine. While relevant in 2015; I'm skeptical that
> its relevant today. I am also considering explicit changes in the
> filtering directives to resolve this in the future.
> 
> Glep42 states:
> 
> ---
> News Item Removal
> 
> News items can be removed (by removing the news file from the main tree)
> when they are no longer relevant, if they are made obsolete by a future
> news item or after a long period of time. This is the same as the method
> used for updates entries.
> ---
> 
> I suggest we delete all entries prior to 2016. Git keeps history
> forever, so folks can gander at the old entries on gitweb.gentoo.org
> :
> 
> https://gitweb.gentoo.org/data/gentoo-news.git/tree/
> 
> -A

I strongly support this idea. I've tried to push this several times in
the past however was met with some resistance from several teams.

[gentoo-dev] Last rites: sci-calculators/qalculator, x11-misc/basqet, x11-misc/okindd

[Michael Palimaka]

# Michael Palimaka <kensing...@gentoo.org> (22 Dec 2017)
# Dead upstream. Requires dead Qt 4.
# Masked for removal in 30 days.
sci-calculators/qalculator

# Michael Palimaka <kensing...@gentoo.org> (22 Dec 2017)
# Dead upstream. Requires dead Qt 4.
# Masked for removal in 30 days.
x11-misc/basqet

# Michael Palimaka <kensing...@gentoo.org> (22 Dec 2017)
# Dead upstream. Requires dead Qt 4.
# Masked for removal in 30 days.
x11-misc/okindd

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

[Michael Palimaka]

# Michael Palimaka <kensing...@gentoo.org> (22 Dec 2017)
# Dead upstream. Requires dead Qt 4.
# Masked for removal in 30 days.
x11-misc/qsynergy

[gentoo-dev] Last rites: app-editors/znotes

[Michael Palimaka]

# Michael Palimaka <kensing...@gentoo.org> (22 Dec 2017)
# Dead upstream. Requires dead Qt 4.
# Masked for removal in 30 days.
app-editors/znotes

[gentoo-dev] Last rites: net-ftp/oneclickftp

[Michael Palimaka]

# Michael Palimaka <kensing...@gentoo.org> (07 Dec 2017)
# Dead upstream. Requires dead Qt4.
# Masked for removal in 30 days. Bug #640138.
net-ftp/oneclickftp

[gentoo-dev] Last rites: dev-vcs/qct

[Michael Palimaka]

# Michael Palimaka <kensing...@gentoo.org> (07 Dec 2017)
# Dead upstream. Requires dead Qt4.
# Masked for removal in 30 days. Bug #640138.
dev-vcs/qct

[gentoo-dev] Last rites: dev-vcs/qsvn

[Michael Palimaka]

# Michael Palimaka <kensing...@gentoo.org> (02 Dec 2017)
# Depends on dead Qt 4. Dead upstream.
# Masked for removal in 30 days. Bug #639252.
dev-vcs/qsvn

[gentoo-dev] Re: cmake + ninja vs autotools

[Michael Palimaka]

On 11/16/2017 02:27 PM, William L. Thomson Jr. wrote:
> It maybe worth considering switching the default generator in the
> cmake-utils.eclass from the default of emake to ninja.
> 
> - : ${CMAKE_MAKEFILE_GENERATOR:=emake}
> + : ${CMAKE_MAKEFILE_GENERATOR:=ninja}
> 
> For those with cmake ebuilds you can test this out now via 
> 
> CMAKE_MAKEFILE_GENERATOR="ninja"
> inherit cmake-utils

If testing this, please use : ${CMAKE_MAKEFILE_GENERATOR:=ninja} in
ebuilds unless the emake generator is explicitly known not to work. This
will preserve user choice if they want to avoid ninja for some reason.

[gentoo-dev] Last rites: media-sound/lastfm-desktop

[Michael Palimaka]

# Michael Palimaka <kensing...@gentoo.org> (01 Oct 2017)
# Fails to build (bug #622632). Requires dead and vulnerable qtwebkit4
# (bug #620710). Masked for removal in 30 days.
media-sound/lastfm-desktop

[gentoo-dev] Last rites: net-misc/dnetstats

[Michael Palimaka]

# Michael Palimaka <kensing...@gentoo.org> (30 Sep 2017)
# Depends on dead qt4. Dead upstream.
# Masked for removal in 30 days.
net-misc/dnetstats

[gentoo-dev] Last rites: app-office/qcharselect

[Michael Palimaka]

# Michael Palimaka <kensing...@gentoo.org> (30 Sep 2017)
# Depends on dead qt4. Dead upstream.
# Masked for removal in 30 days.
app-office/qcharselect

[gentoo-dev] Last rites: kde-misc/konstruktor

[Michael Palimaka]

# Michael Palimaka <kensing...@gentoo.org> (26 Sep 2017)
# Requires dead Qt 4. Dead upstream.
# Masked for removal in 30 days.
kde-misc/konstruktor

[gentoo-dev] Last rites: kde-misc/kookie

[Michael Palimaka]

# Michael Palimaka <kensing...@gentoo.org> (26 Sep 2017)
# Requires dead Qt 4. Dead upstream.
# Masked for removal in 30 days.
kde-misc/kookie

[gentoo-dev] Last rites: media-libs/herqq

[Michael Palimaka]

# Michael Palimaka <kensing...@gentoo.org> (21 Sep 2017)
# Requires dead Qt 4. Dead upstream.
# Masked for removal in 30 days.
media-libs/herqq

[gentoo-dev] Last rites: app-editors/qwriter, dev-util/kscope, dev-util/monkeystudio, dev-util/universalindentgui

[Michael Palimaka]

# Michael Palimaka <kensing...@gentoo.org> (11 Sep 2017)
# Requires dead Qt 4. Dead upstream. Fails to build with new
x11-libs/qscintilla.
# Masked for removal in 30 days. Bug #628224.
app-editors/qwriter

# Michael Palimaka <kensing...@gentoo.org> (11 Sep 2017)
# Requires dead Qt 4. Dead upstream. Fails to build with new
x11-libs/qscintilla.
# Masked for removal in 30 days. Bug #628228.
dev-util/kscope

# Michael Palimaka <kensing...@gentoo.org> (11 Sep 2017)
# Requires dead Qt 4. Dead upstream. Fails to build with new
x11-libs/qscintilla.
# Masked for removal in 30 days. Bug #628230.
dev-util/monkeystudio

# Michael Palimaka <kensing...@gentoo.org> (11 Sep 2017)
# Requires dead Qt 4. Dead upstream. Fails to build with new
x11-libs/qscintilla.
# Masked for removal in 30 days. Bug #628234.
dev-util/universalindentgui

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

[Michael Palimaka]

# Michael Palimaka <kensing...@gentoo.org> (09 Sep 2017)
# Requires dead Qt 4. Dead upstream.
# Masked for removal in 30 days.
app-text/kding

[gentoo-dev] Last rites: sys-process/procexp

[Michael Palimaka]

# Michael Palimaka <kensing...@gentoo.org> (09 Sep 2017)
# Requires dead Qt 4. Dead upstream. Unmaintained.
# Masked for removal in 30 days.
sys-process/procexp

[gentoo-dev] Last rites: x11-apps/python-whiteboard

[Michael Palimaka]

# Michael Palimaka <kensing...@gentoo.org> (09 Sep 2017)
# Requires dead Qt 4. Dead upstream. Unmaintained.
# Masked for removal in 30 days.
x11-apps/python-whiteboard

[gentoo-dev] Last rites: dev-qt/qtphonon

[Michael Palimaka]

# Michael Palimaka <kensing...@gentoo.org> (03 Sep 2017)
# Dead upstream. Use media-libs/phonon instead.
# Masked for removal in 30 days. Bug #629144.
dev-qt/qtphonon

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

[Michael Palimaka]

# Michael Palimaka <kensing...@gentoo.org> (27 Aug 2017)
# Requires deprecated Qt/KDE4. Dead upstream. Use kde-apps/spectacle
instead.
# Masked for removal in 30 days.
media-gfx/kgrab

[gentoo-dev] Last rites: kde-misc/colibri

[Michael Palimaka]

# Michael Palimaka <kensing...@gentoo.org> (27 Aug 2017)
# Doesn't work with Plasma 5. Dead upstream.
# Masked for removal in 30 days.
kde-misc/colibri

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

[Michael Palimaka]

# Michael Palimaka <kensing...@gentoo.org> (27 Aug 2017)
# Doesn't work anymore. Dead upstream.
# Masked for removal in 30 days.
media-gfx/kflickr

[gentoo-dev] Re: Revisions for USE flag changes

[Michael Palimaka]

On 08/12/2017 08:29 PM, Rich Freeman wrote:
> On Sat, Aug 12, 2017 at 5:57 AM, Michael Orlitzky  wrote:
>> On 08/12/2017 03:03 AM, Michał Górny wrote:
>>>
>>> Please provide some examples of recent in-place USE changes that benefit
>>> from revbumps.
>>>
>>
>> There is no single example. Things only get simpler if *all* USE changes
>> come with a new revision.
>>
> This policy change would make my life easier, because for big packages
> it would encourage maintainers to not make IUSE changes until they do
> revbumps, which would save me a build.  I'm running on relatively old
> hardware at this point so these rebuilds actually do cost me quite a
> bit of time.  I'm not sure that not using --changed-use is a great
> option though as it will make it that much harder to keep things
> consistent when I do modify my package.use/make.conf.
> 

At least now you have the option to run without --changed-use if you
want. If inline IUSE changes are completely banned, you will definitely
see more pointless rebuilds on your old hardware. In my experience most
developers make a change when there's a change to be made, and don't
"save up" changes until some arbitrary delta is reached. We've already
an increase in revbumps like this in other areas where inline changes
are being discouraged.

[gentoo-dev] Re: Revisions for USE flag changes

[Michael Palimaka]

On 08/12/2017 08:16 PM, Michael Orlitzky wrote:
> On 08/12/2017 12:22 AM, Michael Palimaka wrote:
>>
>>> Q. But what if I maintain firefox, and I need to change  IUSE?
>>>
>>>   If the IUSE change isn't important, just make the new revision in a
>>>   branch and wait to commit it later when there are more changes
>>>   piled up. If it is important (like if its default value changes
>>>   RDEPEND), then it would have required a revision anyway.
>>
>> Please stop trying to force workflows on people. Using that same logic,
>> I can make the IUSE change in-place and it would be propagated in the
>> next version bump.
>>
> 
> I'm not trying to force anything on anyone, I'm just asking for
> feedback. If it turns out to be a stupid idea, then so be it.
> 
> If it's understood that you can make IUSE changes but that they'll only
> be propagated on the next version bump, then there would be no problem.
> But we're about to document a policy that says it's OK to do things that
> wouldn't normally be OK, because --changed-use is there to save us:
> 
>   The examples of changes that can be done without a revision bump are:
> 
> ...
> 
> * adding a new USE flag or removing an existing one (since change
>   in USE flags is going to trigger --changed-use rebuild),
> 
> If developers operate under that assumption and if you don't use
> --changed-use, you're going to run into problems eventually.

--changed-use is an optional flag and portage works just as well without
it. Please provide examples of such problems.

> 
> 
>>>   * emerge runs a bit faster.
>>
>> Why will it run faster?
> 
> The developer now indicates that IUSE has changed, so portage doesn't
> have to figure it out on its own.

Please provide some numbers to back up this claim. Even if we assume
portage will run faster because we can remove --changed-use (which we
can't, because as pointed out in other posts we still need this flag),
surely any time savings gained there will be lost by pointless rebuilds?

[gentoo-dev] Re: Revisions for USE flag changes

[Michael Palimaka]

On 08/12/2017 09:50 AM, Michael Orlitzky wrote:
> Q. But what about the rebuilds?
> 
>   For most packages, the rebuilds simply don't matter. Unless you're
>   the maintainer of libreoffice, firefox, chromium, etc. -- just do the
>   revision and forget about the (quick) rebuilds.

I really wish people would stop trotting out this false argument. Not
everyone has the latest and greatest hardware. Rebuilds have a real cost
to end users and as such we should use them wisely.

>   We tell everyone to use --changed-use and --newuse if they want
>   things to work, so they were probably going to rebuild anyway.

Who tells everyone to use these flags and where? I never use these flags
day-to-day, only if I need that specific functionality for that reason

> Q. But what if I maintain firefox, and I need to change  IUSE?
> 
>   If the IUSE change isn't important, just make the new revision in a
>   branch and wait to commit it later when there are more changes
>   piled up. If it is important (like if its default value changes
>   RDEPEND), then it would have required a revision anyway.

Please stop trying to force workflows on people. Using that same logic,
I can make the IUSE change in-place and it would be propagated in the
next version bump.

> Q. But I work on a team, and we can't all work in different branches.
> 
>   If you work on a massive package and if you're collaborating with
>   others regularly, you can commit the new ebuild masked. This is
>   annoying, but is an extremely rare combination of circumstances.

Again, let's not try and tell teams which workflow works best for them.

> == tl;dr ==
> 
> We would be better off with respect to IUSE changes and revisions if we
> deleted the --changed-use and --newuse flags right now, and just
> required developers to revbump when changing IUSE.
> 
> Package managers get simpler, documentation gets simpler, the user
> interface gets simpler, and behavior becomes more uniform and predictable.
> 
> Please let me know what you think.

I disagree with this change because your proposed benefits don't hold up:

>   * We can delete all of the PM code for --changed-use and --newuse and
> friends.

As pointed out by Brian, we still need at least --changed-use even if
IUSE changes in-place are banned.

>   * The documentation becomes much simpler: revbump if IUSE changes.

We should base our policies around the cost / benefit of said policy,
not how many or few words we need to write in the devmanual about it.

>   * Users can omit --newuse and --changed-use from their lives.

They already can.

>   * All package managers now handle IUSE changes properly.

If you want to see consistent behaviour in how package manages handle
IUSE, I suggest sending patches for PMS. I don't see any problem in
portage/paludis/pkgcore handling things differently. That is the point
of having different package managers, after all.

>   * emerge runs a bit faster.

Why will it run faster?

[gentoo-dev] Re: Gentoo QA Help

[Michael Palimaka]

On 08/11/2017 12:30 AM, Michael Mair-Keimberger wrote:
> Hi Gentoo Team,
> 
> As some of you may noticed i started to clean up some old patches in the
> gentoo portage tree. I did so already a while ago, and like before I'm
> using a small script in order to identify unused patches.

I just wanted to say thank-you for all your work on this. I certainly
appreciate how much cleaner the tree is from your 1000+ commits, and I'm
sure others do to.

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

[Michael Palimaka]

On 08/05/2017 12:37 AM, 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?
> 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?

These two are still maintained by KDE team, they just got masked
(without asking by the way...) because they depend on plymouth.

[gentoo-dev] Re: [RFC] Future of gentoo's stable and unstable trees: what are your thoughts?

[Michael Palimaka]

On 07/25/2017 05:22 PM, Dirkjan Ochtman wrote:
> First, the assumption in our processes seems to be that many or
> important bugs will be due to architecture-specific differences, and I
> wonder if that assumption really holds up. Do arch testers for a smaller
> arch often find problems that were not noticed on one of the larger
> arches? With the languages and tools that we have today, it seems like
> for many of our packages, bugs due to architectural differences
> represent a minority of the problems we found. In this case, the whole
> idea of per-arch stabilization does not really make sense, and doing
> away with that idea could drastically shortcut our process.

This would be really interesting to know.

> Second, I believe a lot of the value in our stable tree comes *just*
> from the requirement that stabilization is only requested after 30 days
> without major bugs/changes in the unstable tree. Assuming there are
> enough users of a package on unstable, that means important bugs can be
> shaken out before a version hits stable. This could mean that
> potentially, even if we inverted our entire model to say we
> "automatically" stabilize after a 30-day period without major bugs, we
> hit most of the value of the stable tree with again drastically reduced
> pain/work.

The 30 day waiting period is useful for smoking out major upstream bugs,
but can't replace stabilisation integration testing. For example,
package foobar may build fine in ~arch but fails in stable because it
needs a newer libbaz.

[gentoo-dev] Re: [RFC] Future of gentoo's stable and unstable trees: what are your thoughts?

[Michael Palimaka]

On 07/25/2017 07:22 AM, Sergei Trofimovich wrote:
> 2. Q: How to make arch testing faster and easier?
> 
>A: - KEYWORDREQ/STABLEREQ bugs not marked as "runtime testing
> required" will be automatically tested and keyworded.
> 
> [handwave] automated tinderbox setup would help a lot
> to now upfront what fails to built, fails tests.

I've had similar thoughts about this and have already been working on
some tooling for this.

We would need to establish exactly what criteria must be met for an
automated test to be considered as successful.

Here's a sample report that my tool produces:
https://dev.gentoo.org/~kensington/tinderbox/sys-apps/dbus/dbus-1.6.18-r1/df017e14-bd68-47e2-9738-554e7ba1cf10.html

In this case, would it be enough that it builds and tests pass? What
about the QA issues? Do we need someone to review them to determine if
they should block stabilisation, or if they're even a regression or not?

[gentoo-dev] Re: [RFC pre-GLEP] Gentoo Git Workflow

[Michael Palimaka]

On 07/25/2017 06:05 PM, Michał Górny wrote:
> Hi, everyone.
> 
> There have been multiple attempts at grasping this but none so far
> resulted in something official and indisputable. At the same time, we
> end having to point our users at semi-official guides which change
> in unpredictable ways.
> 
> Here's the current draft:
> https://wiki.gentoo.org/wiki/User:MGorny/GLEP:Git

This looks really nice, thanks for working on it.

> * When doing a minor change to a large number of packages, it is
> reasonable to do so in a single commit. However, when doing a major
> change (e.g. a version bump), it is better to split commits on package
> boundaries.

In some cases we do prefer to make major changes on a set of related
package all in one commit. For example, we always bump the 240+ KDE
Applications collection together because that's how it's released.

> ===Commit messages===
> A standard git commit message consists of three parts, in order: a
> summary line, an optional body and an optional set of tags. The parts
> are separated by a single empty line.
> 
> The summary line is included in the short logs (git log --
> oneline, gitweb, GitHub, mail subject) and therefore should
> provide a short yet accurate description of the change. The summary line
> starts with a logical unit name, followed by a colon, a space and a
> short description of the most important changes. If a bug is associated
> with a change, then it should be included in the summary line as
> #nn or likewise. The summary line must not exceed 69
> characters, and must not be wrapped.

Does a bug # really need to always be in the summary line? It can eat
valuable characters and tags which are pretty popular are equally valid IMO.

> ** Bug: https://bugs.gentoo.org/NN; — to
> reference a bug,
> ** Closes: https://github.com/gentoo/gentoo/pull/ ki>; — to automatically close a GitHub pull request,
> ** Fixes: https://bugs.gentoo.org/NN; —
> to indicate a fixed bug,

grepping the git log shows that 'Gentoo-bug' is much more common than
plain 'Bug'. 'Fixes' is hardly used at all, and I think it's a bit
confusing to use this for bugs as well as commits.

> a few branches on the repository, and did not maintain them. The Infra
> had to query the developers about the state of the branches and clean
> them up.

Should 'The Infra' be 'The Infra team' or just 'Infra'?

> Gentoo developers are still frequently using Gentoo-Bug tag,
> sometimes followed by Gentoo-Bug-URL. Using both
> simultaneously is meaningless (they are redundant), and using the former
> has no advantages over using the classic #nn form in the
> summary or the body.

I agree that using both is redundant, but I don't agree with
discouraging or banning the use of 'Gentoo-bug'. If someone prefers to
use it so it sits nicely with the other tags why stop them?

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

[Michael Palimaka]

On 07/12/2017 07:26 AM, Kristian Fiskerstrand wrote:> That presumes that
the maintainer is the one calling for the
> stabilization, and it is not an automated procedure simply due to 30
> days in ~arch. In this particular case, look for the number of bug
> reports filed in Gentoo for the issue.

All of the past automated stabilisation request initiatives did look for
open bugs against a package before filing any request.

> 
> But the main risk is certainly not built testing, it is breaking
> operational live stable systems.

I'm not sure exactly what you mean by this. Build testing is a process
and not a risk. When ebuilds are moved to stable, there's risk of
breakage at both build time and runtime.

Most runtime issues will either be known by the maintainer (who can then
block the stabilisation) or smoked out during the usual ~arch waiting
period.

Build time issues are more tricky. One of the reasons we have arch
testers is to ensure that something that built fine in ~arch will still
build fine on an otherwise stable system.

I've encountered a number of ebuilds marked stable that failed to build
on an all-stable system but built fine on an all-testing system. I've
never encountered a single ebuild that failed to run correctly on an
all-stable system but ran fine on an all-testing system.

I don't think it's practical to demand detailed runtime testing by an
arch tester for every stabilisation request (which we know doesn't
happen in practice anyway). There's also many packages where it may be
prudent to do more than just build testing.

I think the answer lies somewhere in the middle. We need to recognise
that we have very limited arch testing resources and focus them where it
will have the most impact. We have a "runtime testing required" field on
stable bugs now - let's use it, and let's be smart about it. Looking at
the current open bugs, I see some good examples where runtime testing
was requested (eg. sys-devel/gcc-config) and some examples where I
really question what value we get from an arch tester's time (eg.
app-text/htmldoc).

> Nowhere was it claimed that the arc
> testers are responsible for it, but it certainly doesn't coincide, at
> any point, with "The main risk of breakage of a package moving from
> testing to stable is always at build time anyway."
In a previous post you stated:
> currently gnupg 2.1.21 scdaemon bug will
> happily sign a third party public keyblock's UID using signature subkey
> on smartcard, which results in useless signature that doesn't have any
> effect, but the application builds fine.
>
> This means gnupg 2.1.21 is not a candidate for stabilization, but it
certainly builds fine.

If it's not a stable candidate then why do you use this as an example
against build testing-based stabilisations? If there are known issues it
should never reach the arch teams in the first place.

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

[Michael Palimaka]

On 07/12/2017 12:25 AM, James Le Cuirot wrote:
> On Tue, 11 Jul 2017 16:15:51 +0200
> Kristian Fiskerstrand <k...@gentoo.org> wrote:
> 
>> On 07/11/2017 04:13 PM, Kristian Fiskerstrand wrote:
>>> On 07/11/2017 03:47 PM, Michael Palimaka wrote:  
>>>> The main risk of breakage of a package moving from testing to
>>>> stable is always at build time anyway.  
>>>
>>> citation needed
>>>   
>>
>> Anecdotal evidence against, currently gnupg 2.1.21 scdaemon bug will
>> happily sign a third party public keyblock's UID using signature
>> subkey on smartcard, which results in useless signature that doesn't
>> have any effect, but the application builds fine.
>>
>> This means gnupg 2.1.21 is not a candidate for stabilization, but it
>> certainly builds fine.
> 
> This is a good opportunity to remind ourselves what stable means. Are
> we referring exclusively to our packaging or are upstream issues taken
> into account too? 30 days seems like a reasonable time for any upstream
> issues to be reported. Unfortunately security issues mean that new
> releases sometimes get stabilised immediately. Ideally these releases
> would carry just the security fixes but that isn't always the case.
> 

I think we should consider both our packaging as well as upstream
issues, and I agree that for most packages 30 days in ~arch is enough
time to smoke out upstream issues.

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

[Michael Palimaka]

On 07/12/2017 12:15 AM, Kristian Fiskerstrand wrote:
> On 07/11/2017 04:13 PM, Kristian Fiskerstrand wrote:
>> On 07/11/2017 03:47 PM, Michael Palimaka wrote:
>>> The main risk of breakage of a package moving from testing to
>>> stable is always at build time anyway.
>>
>> citation needed
>>
> 
> Anecdotal evidence against, currently gnupg 2.1.21 scdaemon bug will
> happily sign a third party public keyblock's UID using signature subkey
> on smartcard, which results in useless signature that doesn't have any
> effect, but the application builds fine.
> 
> This means gnupg 2.1.21 is not a candidate for stabilization, but it
> certainly builds fine.
> 

Stop trolling - you know perfectly well that this sort of issue would
never ever be caught during arch testing. Nor should it be - it's called
*arch* testing for a reason.

Ensuring that a package's functionality is of merchantable quality is
the maintainer's responsibility (that's you!).

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

[Michael Palimaka]

On 07/12/2017 12:13 AM, Kristian Fiskerstrand wrote:
> On 07/11/2017 03:47 PM, Michael Palimaka wrote:
>> The main risk of breakage of a package moving from testing to
>> stable is always at build time anyway.
> 
> citation needed
> 

Based on my experience doing package testing in stabilisation work. Feel
free to provide citations (or complete sentences) to the contrary.

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

[Michael Palimaka]

On 07/11/2017 11:06 PM, Rich Freeman wrote:
> On Tue, Jul 11, 2017 at 8:59 AM, Michael Palimaka <kensing...@gentoo.org> 
> wrote:
>> On 07/11/2017 09:29 AM, Andrew Savchenko wrote:
>>>
>>> Even if such stabilization is allowed, there are unanswered
>>> questions here:
>>> - is following seciton 4.1 from wg recommendations is sufficient?
>>> - should developer test each stabilization candidate on an
>>> up-to-date stable setup?
>>
>> The guidelines from that document are ripped straight out of the
>> devmanual and are a good starting point but rather generic. You can find
>> some more detailed suggestions on things to consider while testing on
>> the wiki: https://wiki.gentoo.org/wiki/Package_testing
>>
> 
> I think that in practice arch teams don't do have the stuff on that
> wiki page.  Maybe some people do, but back when I was an amd64 AT I
> don't think anybody went testing multiple USE combinations for a
> typical package.

Everything on that page is deliberately a suggestion only, and not
necessarily specific to stabilisation testing.

In the end, we've never been able to reach any consensus on what exactly
an arch tester should do. Personally, I think we should just switch to
fully-automated, build-only testing for stabilistions unless the
maintainer opts otherwise (something that largely happens in practice
already). The main risk of breakage of a package moving from testing to
stable is always at build time anyway.

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

[Michael Palimaka]

On 07/11/2017 09:29 AM, Andrew Savchenko wrote:
> On Mon, 10 Jul 2017 22:17:34 +0200 Kristian Fiskerstrand wrote:
>> On 07/10/2017 10:02 PM, Rich Freeman wrote:
>>> On Mon, Jul 10, 2017 at 3:57 PM, Andrew Savchenko  
>>> wrote:

 On Mon, 10 Jul 2017 13:49:40 -0400 Rich Freeman wrote:

> In the case of amd64 we already
> encourage individual package maintainers to stabilize their own
> packages

 Huh? Have our rules changed? As per devmanual[1] and GLEP 40[2]
 stabilization must be carried out by arch teams, unless a special
 arrangement is done between a developer and a team.

>>>
>>> The docs are probably out of date - I'm not sure if the policy is
>>> documented anywhere.  However it has been a fairly longstanding policy
>>> at this point that amd64 allows individual maintainers to stabilize
>>> their own packages.
>>>
>>
>> We looked after it for wg-stable (which died out as a result of rather
>> low participation, maybe it should be rebooted if people feel like
>> discussing this again), there isn't any authoritative policy allowing
>> it, GLEP:40 explicitly removes the possibility to do it for x86. That
>> said, for a number of packages maintainer stabilization can likely make
>> sense, the opposite view is four-eyes principle, it is always good to
>> have someone else build-test etc, but this is greatly helped by
>> tinderboxing efforts (thanks toralf) etc. So one likely output if
>> wg-stable is to come up with something would be a replacement GLEP for
>> 40 that matches the current state, and also kernel auto-stabiliation (as
>> discussed in [section 3.2 (Kernel)]
> 
> So, am I understanding this correctly that right now a package
> stabilization by maintainer without explicit permit from an arch
> team will be the violation of active and approved policies?

As Rich pointed out, amd64 team has long allowed maintainers to perform
their own stabilisations. I've asked x86 team about this in the past,
and they too were OK with maintainer stabilisations.

It would be nice to improve documentation of this, but it is certainly
not a policy violation just because some ancient document was never updated.

> Despite the maintainer-driven stabilization seems to be "a fairly
> longstanding policy" I'm reluctant to do such stabilization myself,
> because anyone may point out later that such action is a violation
> of the written policies and I will have nothing to defend me.
> 
> Even if such stabilization is allowed, there are unanswered
> questions here:
> - is following seciton 4.1 from wg recommendations is sufficient?
> - should developer test each stabilization candidate on an
> up-to-date stable setup?

The guidelines from that document are ripped straight out of the
devmanual and are a good starting point but rather generic. You can find
some more detailed suggestions on things to consider while testing on
the wiki: https://wiki.gentoo.org/wiki/Package_testing

[gentoo-dev] Re: stabilization candidates, July 2017

[Michael Palimaka]

On 07/10/2017 06:41 PM, Paweł Hajdan, Jr. wrote:
> Hey folks,
> 
> If you'd like to help Gentoo stable be more up to date, please read on.
> 
> See
> 
> for potential stabilization candidates (over 1000 of them).
> 
> These are automatically checked to pass repoman, and bugzilla is also
> checked for bugs. Only ebuilds not modified in last 30 days are considered.
> 
> Feel free to check out 
> for the script(s) which generate this. It's a project I've been working
> on throughout 2011-2014, and might now work more on it.
> 
> Feedback about next steps would be welcome.
> 
> Paweł
> 

This worked really well in the past - I hope you decide to continue this
great work.

I have two suggestions:

1. Put out a call for updated blacklist requests. This will help avoid
(a) whinging from the vocal minority who are terribly offended by this
sort of thing, and (b) unnecessary requests for sets of packages that
are managed in bulk eg. certain kde and qt categories

2. Please update the bug filing script to use the new bugzilla
components and package list fields - these are now essential to getting
prompt service from arch teams

[gentoo-dev] Re: About adding a *warning* to remind maintainers to check for new PYTHON_COMPAT values

[Michael Palimaka]

On 07/10/2017 11:35 PM, Kent Fredric wrote:
> On Mon, 10 Jul 2017 13:43:43 +0200
> Pacho Ramos  wrote:
> 
>> Yes, but it's similar as the cases when we need to fix our packages
>> to work with a newer library they depend on. In this case it would be
>> even easier as we can have multiple python versions and switch to the
>> newer one for testing while going back to the stable one (if
>> preferred) later.
>>
> 
> I'm starting to think we need a collection of QA scripts in a repo
> somewhere, optimized for symlinking into /etc/portage/hooks/install/
> 
> And make it standard practice for:
> 
> - Gentoo Devs to have those scripts
> - Tinderboxers' to have those scripts
> 
> That's going to be the only way we can get these warnings in ways
> *developers* will see them, but: 
> 
> 1. Won't needlessly clutter stable users systems
> 2. Won't produce loads of ebuild bumps that do waves of metadata
> updates for things that don't affect end users.
> 
> Presently the only things *like* this require hard-coded QA logic into
> portage itself, which, while useful, pulls us back to the whole problem
> where it might affect users, and becomes tightly coupled to portage's
> release cycle.
> 
> We could however make things simpler, and have a package that installs
> these QA hacks into the hooks dir for us, and then it would be a matter
> of simply installing them via opt-in
In addition to the checks that are bundled, Portage already natively
supports custom post-install QA checks in:

* /usr/local/lib/install-qa-check.d
* /usr/lib/install-qa-check.d
* $REPO/metadata/install-qa-check.d

It's just a matter of someone writing and shipping them. I've been very
slowly preparing a collection based on the common type of tinderboxing
bugs that are filed and porting parts of lintian, but I haven't finished
yet.

[gentoo-dev] Re: Sets vs Meta ebuilds

[Michael Palimaka]

On 07/08/2017 02:48 AM, NP-Hardass wrote:
> On 07/07/2017 12:32 PM, William L. Thomson Jr. wrote:
>> I have been playing with some package sets and I like the concept of
>> sets quite a lot. However there is one big drawback. You cannot use a
>> package set in a profile. Or at least I do not think you can. I have
>> looked into it a bit and does not seem like it is possible.
>>
>> I know I can create a meta ebuild and use it like a package set. I
>> think it would be useful to have package sets be able to be used in a
>> profile like meta ebuilds. It would likely reduce the need or use of
>> meta packages. Not sure if there is any benefit to that approach over a
>> set.
>>
>> I think sets have benefits over meta packages. This was the most
>> comprehensive document on sets, benefits, uses, etc. Other than the
>> general docs on the wiki.
>> https://makuro.wordpress.com/2010/12/12/intro-to-portage-sets/
>>
>> I  would really like to be able to use package sets in profiles. I
>> think of use and benefit to others as well.
>>
> 
> There is actually a huge functional difference between the two that you
> are missing here.  A meta package defines its dependencies in full
> dependency syntax.  This means you can specify versions, USE flag
> dependencies, make packages dependent on USE flags, etc.  A package set
> is just a list of packages (potentially constrained by version.  TTBOMK,
> there is no inclusion of any USE flag functionality in sets.
> Additionally, let's say you have a more complicated dependency like || (
> A B ),  I don't think there is a way to describe that in a package set
> at all.

Bug #272488[0] proposed a PROPERTIES="set" feature to combine the power
of sets with the flexibility of ebuilds.

1: https://bugs.gentoo.org/show_bug.cgi?id=272488

[gentoo-dev] Last rites: app-office/calligra-l10n

[Michael Palimaka]

# Michael Palimaka <kensing...@gentoo.org> (06 Jul 2017)
# Obsolete. l10n is now included in app-office/calligra:5.
# Masked for removal in 30 days. Exported to kde-sunset overlay.
app-office/calligra-l10n

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

[Michael Palimaka]

# Michael Palimaka <kensing...@gentoo.org> (01 Jul 2017)
# Depends on vulnerable qtwebkit:4. Dead upstream.
# Masked for removal in 30 days. Bug #620836.
media-gfx/picturewall

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

[Michael Palimaka]

# Michael Palimaka <kensing...@gentoo.org> (01 Jul 2017)
# Depends on vulnerable qtwebkit:4. Dead upstream.
# Masked for removal in 30 days. Bug #620704.
media-gfx/smile

[gentoo-dev] Last rites: kde-misc/semantik

[Michael Palimaka]

# Michael Palimaka <kensing...@gentoo.org> (01 Jul 2017)
# Depends on vulnerable qtwebkit:4. Dead upstream.
# Masked for removal in 30 days. Bug #620700.
kde-misc/semantik

[gentoo-dev] Last rites: app-cdr/acetoneiso

[Michael Palimaka]

# Michael Palimaka <kensing...@gentoo.org> (01 Jul 2017)
# Depends on vulnerable qtwebkit:4. Dead upstream.
# Masked for removal in 30 days. Bug #620688.
app-cdr/acetoneiso

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

[Michael Palimaka]

# Michael Palimamka  (18 Jun 2017)
# Fails to build with uncoming stable Qt 5.7. Dead upstream.
# Masked for removal in 30 days. Bug #603564.
media-sound/ams

[gentoo-dev] Re: Gentoo Council 2017 / 2018 election

[Michael Palimaka]

On 06/17/2017 03:56 AM, Alice Ferrazzi wrote:
> I nominate:
> 
> blueness
> gokturk
> maffblaster
> kensington
> mrueg
> Soap
> mgorny
> 
> -- 
> アリス フェッラッツィ
> Alice Ferrazzi
> 
> Gentoo Kernel Project Leader
> Mail: Alice Ferrazzi >
> PGP: 2E4E 0856 461C 0585 1336 F496 5621 A6B2 8638 781A

Thanks, but I decline.

[gentoo-dev] Last rites: www-client/qtweb

[Michael Palimaka]

# Michael Palimaka <kensing...@gentoo.org> (04 Jun 2017)
# Relies on obsolete and vulerable qtwebkit version. Dead upstream.
# Masked for removal in 30 days. Bug #620758.
www-client/qtweb

[gentoo-dev] Last rites: sci-mathematics/freemat

[Michael Palimaka]

# Michael Palimaka <kensing...@gentoo.org> (04 Jun 2017)
# Relies on obsolete and vulerable qtwebkit version. Dead upstream.
# Masked for removal in 30 days. Bug #620752.
sci-mathematics/freemat

[gentoo-dev] Last rites: app-editors/vim-qt

[Michael Palimaka]

# Michael Palimaka <kensing...@gentoo.org> (23 Apr 2017)
# Doesn't work with any in-tree versions of vim. Inactive upstream.
# Bug 607136. Masked for removal in 30 days.
app-editors/vim-qt

[gentoo-dev] Last rites: net-misc/apt-proxy

[Michael Palimaka]

# Michael Palimaka <kensing...@gentoo.org> (18 Mar 2017)
# Broken. Dead upstream. Unmaintained.
# Masked for removal in 30 days.
net-misc/apt-proxy

[gentoo-dev] Last rites: gnome-extra/zeitgeist-datasources

[Michael Palimaka]

# Michael Palimaka <kensing...@gentoo.org> (18 Mar 2017)
# Broken. Dead upstream. Unmaintained.
# Masked for removal in 30 days. Bug #604836.
gnome-extra/zeitgeist-datasources

[gentoo-dev] Last rites: net-p2p/phxd

[Michael Palimaka]

# Michael Palimaka <kensing...@gentoo.org> (18 Mar 2017)
# Fails to run. Ancient. Unmaintained. Dead upstream.
# Masked for removal in 30 days. Bug #605120.
net-p2p/phxd

[gentoo-dev] Last rites: dev-scheme/schoca

[Michael Palimaka]

# Michael Palimaka <kensing...@gentoo.org> (11 Mar 2017)
# Fails to build. Dead upstream.
# Masked for removal in 30 days. Bug #592184.
dev-scheme/schoca

[gentoo-dev] Packages up for grabs

[Michael Palimaka]

Due to a retiring proxied maintainer, these packages are now up for grabs:

dev-python/python-gammu
net-irc/inspircd

[gentoo-dev] Last rites: x11-misc/oroborus-desklaunch

[Michael Palimaka]

# Michael Palimaka <kensing...@gentoo.org> (03 Mar 2017)
# Segfaults at runtime. Dead upstream. Unmaintained.
# Masked for removal in 30 days. Bug #611406.
x11-misc/oroborus-desklaunch

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

[Michael Palimaka]

# Michael Palimaka <kensing...@gentoo.org> (22 Feb 2017)
# Fails to build. Dead upstream.
# Masked for removal in 30 days. Bug #520890.
x11-misc/xrmap

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

[Michael Palimaka]

# Michael Palimaka <kensing...@gentoo.org> (19 Feb 2017)
# Doesn't work. Dead upstream. Unmaintained.
# Masked for removal on 30 days. Bug #609754.
x11-misc/bbappconf

[gentoo-dev] Last rites: x11-terms/valaterm

[Michael Palimaka]

# Michael Palimaka <kensing...@gentoo.org> (18 Feb 2017)
# Dead upstream. Relies on vala slot. Unmaintained. Bug #601346.
# Masked for removal in 30 days.
x11-terms/valaterm

[gentoo-dev] Last rites: sys-fs/udisks-glue

[Michael Palimaka]

# Michael Palimaka <kensing...@gentoo.org> (18 Feb 2017)
# Dead upstream. Relies on dead udisks:0. Bug #601356.
# Masked for removal in 30 days.
sys-fs/udisks-glue

[gentoo-dev] Last rites: dev-util/weblint

[Michael Palimaka]

# Michael Palimaka <kensing...@gentoo.org> (18 Feb 2017)
# Fails at runtime. Dead upstream. Unmaintained. Bug #602008.
# Masked for removal in 30 days.
dev-util/weblint

[gentoo-dev] Last rites: net-news/blam and dev-dotnet/webkit-sharp

[Michael Palimaka]

# Michael Palimaka <kensing...@gentoo.org> (18 Feb 2017)
# Requires a dead and vulnerable webkit-gtk version. Bug #608602.
# Masked for removal in 30 days.
dev-dotnet/webkit-sharp
net-news/blam

[gentoo-dev] Last rites: net-ftp/bareftp

[Michael Palimaka]

# Michael Palimaka <kensing...@gentoo.org> (18 Feb 2017)
# Fails to build. Bug #608940. Masked for removal in 30 days.
net-ftp/bareftp

[gentoo-dev] Last rites: media-libs/FusionSound

[Michael Palimaka]

# Michael Palimaka <kensing...@gentoo.org> (18 Feb 2017)
# Fails to build. Use dev-libs/DirectFB[fusionsound] instead.
# Bug #602674, 543728, 542000, 456770. Masked for removal in 30 days.
media-libs/FusionSound

[gentoo-dev] Last rites: media-libs/iulib

[Michael Palimaka]

# Michael Palimaka <kensing...@gentoo.org> (12 Feb 2017)
# Build failures. Dead upstream. No revdeps. Unmaintained.
# Masked for removal in 30 days. Bug #594826 and 597872.
media-libs/iulib

[gentoo-dev] Last rites: sys-power/cpudyn

[Michael Palimaka]

# Michael Palimaka <kensing...@gentoo.org> (12 Feb 2017)
# Dead upstream. Unmaintained. Problems with multicode CPUs.
# Masked for removal in 30 days.
sys-power/cpudyn

[gentoo-dev] Last rites: games-arcade/mari0 and games-action/openlierox

[Michael Palimaka]

# Michael Palimaka <kensing...@gentoo.org> (12 Feb 2017)
# Potential licensing issues. Masked for removal in 30 days.
# Bug 608954 and 609052
games-arcade/mari0
games-action/openlierox

[gentoo-dev] Last rites: dev-libs/safestr and dev-libs/xxl

[Michael Palimaka]

# Michael Palimaka <kensing...@gentoo.org> (02 Feb 2017)
# Upstream missing. Ancient. Unmaintained. No revdeps.
# Masked for removal in 30 days.
dev-libs/safestr
dev-libs/xxl

[gentoo-dev] Re: News item review: python-exec 2.3 reclaims python* symlinks

[Michael Palimaka]

On 21/01/17 20:49, Michał Górny wrote:
> Please review the following news item. It was requested by users.
> Preferably I'd like to commit it today.
> 
>  --
> 
> Title: python-exec 2.3 reclaims python* symlinks
> Author: Michał Górny 
> Content-Type: text/plain
> Posted: 2017-01-21
> Revision: 1
> News-Item-Format: 1.0
> Display-If-Installed:  Display-If-Installed:  
> The new versions of python-exec (2.3 and newer) are reclaiming multiple
> Python-related symlinks in /usr/bin, most notably /usr/bin/python*. This
> may result in your package manager reporting file collisions.
> 
> The respective symlinks were previously either unowned and created
> dynamically by app-eselect/eselect-python, or installed by it. From now
> on, all Python-related symlinks are installed and handled
> by python-exec. This ensures that they respect the python-exec
> configuration files and variables consistently with regular Python
> packages, and improves their reliability.
> 
> If you are using FEATURES=collision-protect, Portage will reject
> the upgrade. If this is the case, please temporarily switch to
> FEATURES=protect-owned for the upgrade.
> 
> If you are using FEATURES=protect-owned, Portage will verbosely warn
> about the file collisions but will proceed with the upgrade once
> determining no replaced files are owned. Please disregard the warning.
> 
> The potentially colliding files are:
> 
>  * /usr/bin/2to3
>  * /usr/bin/pydoc
>  * /usr/bin/python
>  * /usr/bin/python2
>  * /usr/bin/python3
>  * /usr/bin/python-config
> 
> For more information on python-exec, please see:
> https://wiki.gentoo.org/wiki/Project:Python/python-exec
> 
> 

Thanks for writing this, looks good.

[gentoo-dev] Last rites: media-video/flumotion:

[Michael Palimaka]

# Michael Palimaka <kensing...@gentoo.org> (18 Jan 2017)
# Relies on dead gstreamer:0.10. Dead upstream.
# Masked for removal in 30 days. Bug #603270.
media-video/flumotion

[gentoo-dev] Last rites: app-admin/filebeat-bin

[Michael Palimaka]

# Michael Palimaka <kensing...@gentoo.org> (18 Jan 2017)
# Obsolete. Use app-admin/filebeat instead.
app-admin/filebeat-bin

[gentoo-dev] Last rites: app-cdr/k9copy

[Michael Palimaka]

# Michael Palimaka <kensing...@gentoo.org> (18 Jan 2017)
# Fails to build with ffmpeg-3. Dead upstream.
# Masked for remvoal in 30 days.
app-cdr/k9copy

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

[Michael Palimaka]

# Michael Palimaka <kensing...@gentoo.org> (18 Jan 2017)
# Obsolete - now a native feature in Plasma 5.8
# Masked for removal in 30 days
x11-misc/ksuperkey

[gentoo-dev] Re: Commit signing for metadata/* repos

[Michael Palimaka]

On 08/01/17 08:24, Luis Ressel wrote:
> Hello,
> 
> there are some additional git repositories which need to be added to
> metadata/ subdirectories to make the 'gentoo' git repository usable
> for /usr/portage. Specifically, those are dtd, glsa, news and
> xml-schema.
> 
> It'd be great if developers could sign their commits in these repos,
> too. (I don't really care about dtd and xml-schema, but for the other
> two, I think this would make much sense.)
> 
> Currently, it looks like commits to xml-schema aren't signed at all,
> all commits to glsa are signed, and commits to the other two repos are
> partly signed.

I agree, and think we should enforce this with a server-side hook the
same way we do for gentoo.git.

It could also be interesting to see the bot commits in
repo/sync/gentoo.git signed.

[gentoo-dev] Re: The changes about the stabilization process

[Michael Palimaka]

On 04/01/17 12:57, Andrew Savchenko wrote:
> Hi all,
> 
> On Sun, 25 Dec 2016 22:55:27 +0300 Andrew Savchenko wrote:
> [...]
>> Another question: do we steel need to set STABLEREQ keyword for
>> stabilization bugs? Since we now have a dedicated Stabilization
>> component, STABLEREQ looks redundant.
> 
> Ping here.
> 
> Best regards,
> Andrew Savchenko
> 

With the changes, STABLEREQ and KEYWORDREQ indeed become redundant.

That said, it's entirely possible some arch team members are relying on
these keywords for old saved searches etc. With so many people working
in isolation, it's difficult to know who is doing what.

[gentoo-dev] Re: The changes about the stabilization process

[Michael Palimaka]

On 29/12/16 03:49, Michael Palimaka wrote:
> On 28/12/16 20:57, Ulrich Mueller wrote:
>>>>>>> On Sun, 25 Dec 2016, Agostino Sarubbo wrote:
>>
>>> with the great and awesome work of Michael Palimaka (kensington) and
>>> the support of the wg-stable, for the stabilization process, some
>>> changes on our bugzilla have been done.
>>
>> Thank you for the great work.
>>
>>> [...]
>>
>>> When you will choose one of those, you will see two new fields:
>>> - Atoms to stabilize
>>
>> Can you please avoid reintroducing the term "atom" there, when we are
>> trying to get rid of it elsewhere [1]? Note that PMS doesn't define
>> the term [2].
> 
> Any suggestions for improved text? Ideally it would be
> stabilisation/keywording agnostic as the same field is used in both
> components.
> 
> 

ago suggested "Packages list" or "Package list" - thoughts?