Re: [gentoo-dev] [RFC] CC-ARCHES keyword on Bugzilla

2020-04-13 Thread Aaron Bauman



On April 13, 2020 1:17:50 PM EDT, "Michał Górny"  wrote:
>Hi,
>
>One of the goals behind NATTkA was to make keywording/stabilization
>easier.  Right now it's mostly possible to file the most common
>requests
>without having to copy keywords everywhere.  Still, there's a need to
>CC
>arches which isn't exactly the most convenient part.
>
>I was thinking how to make NATTkA help with that.  After considering
>a few options, I'd like to push forward the following proposition:
>let's
>add a 'CC-ARCHES' keyword to Bugzilla.  If a bug is marked with that
>keyword and passes sanity check, NATTkA will automatically CC all
>relevant arch teams (based on keyword list).
>
>What do you think?

Wonderful! Please do it. 
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.



[gentoo-dev] Re: [PATCH] meson.eclass: update the example to use modern helper functions

2020-04-13 Thread Mike Gilbert
On Mon, Apr 13, 2020 at 5:48 PM Marek Szuba  wrote:
>
> We have now got meson_use and meson_feature yet the example still
> used usex.
>
> Signed-off-by: Marek Szuba 

Reviewed-by: Mike Gilbert 



[gentoo-dev] [PATCH] meson.eclass: update the example to use modern helper functions

2020-04-13 Thread Marek Szuba
We have now got meson_use and meson_feature yet the example still
used usex.

Signed-off-by: Marek Szuba 
---
 eclass/meson.eclass | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/eclass/meson.eclass b/eclass/meson.eclass
index 0932a7ed427..2bd1dc01760 100644
--- a/eclass/meson.eclass
+++ b/eclass/meson.eclass
@@ -23,9 +23,9 @@
 #
 # src_configure() {
 #  local emesonargs=(
-#  -Dqt4=$(usex qt4 true false)
-#  -Dthreads=$(usex threads true false)
-#  -Dtiff=$(usex tiff true false)
+#  $(meson_use qt4)
+#  $(meson_feature threads)
+#  $(meson_use bindist official_branding)
 #  )
 #  meson_src_configure
 # }
-- 
2.24.1




Re: [gentoo-dev] [RFC] CC-ARCHES keyword on Bugzilla

2020-04-13 Thread Andreas K . Hüttel
> let's
> add a 'CC-ARCHES' keyword to Bugzilla.  If a bug is marked with that
> keyword and passes sanity check, NATTkA will automatically CC all
> relevant arch teams (based on keyword list).
> 
> What do you think?

Sounds great. Do it! :)

-- 
Andreas K. Hüttel
dilfri...@gentoo.org
Gentoo Linux developer 
(council, qa, toolchain, base-system, perl, libreoffice)

signature.asc
Description: This is a digitally signed message part.


Re: [gentoo-dev] [PATCH v3 6/9] glep-0072: Combine and amend description of states

2020-04-13 Thread Andreas K . Hüttel
> > [Maybe someone who actually does slow-arch work should speak up. Anyone
> > out
> > there still reading g-dev?]
> 
> I'm lost.  The original definition said that this state is for arches
> that use stable only on subset of packages needed for stage building.
> Why would people file streqs for other packages then?

Shrug. I'm not going to fight here for anything. 

Just my experience after some arches lost stable status was that these arch 
people still wanted to get CC'ed in stabilization requests. If only to keep 
track.

-- 
Andreas K. Hüttel
dilfri...@gentoo.org
Gentoo Linux developer 
(council, qa, toolchain, base-system, perl, libreoffice)

signature.asc
Description: This is a digitally signed message part.


Re: [gentoo-dev] [RFC] CC-ARCHES keyword on Bugzilla

2020-04-13 Thread David Seifert
On Mon, 2020-04-13 at 19:17 +0200, Michał Górny wrote:
> Hi,
> 
> One of the goals behind NATTkA was to make keywording/stabilization
> easier.  Right now it's mostly possible to file the most common requests
> without having to copy keywords everywhere.  Still, there's a need to CC
> arches which isn't exactly the most convenient part.
> 
> I was thinking how to make NATTkA help with that.  After considering
> a few options, I'd like to push forward the following proposition: let's
> add a 'CC-ARCHES' keyword to Bugzilla.  If a bug is marked with that
> keyword and passes sanity check, NATTkA will automatically CC all
> relevant arch teams (based on keyword list).
> 
> What do you think?
> 

Yes, and simplifies the workflow a lot!




Re: [gentoo-dev] [PATCH v3 6/9] glep-0072: Combine and amend description of states

2020-04-13 Thread Michał Górny
On Mon, 2020-04-13 at 21:39 +0300, Andreas K. Hüttel wrote:
> > +Transitional architectures are generally listed after stable architectures,
> > +possibly mixed with testing.  Developers are not expected to file
> > stabilization +requests.
> 
> I'm still claiming that it would be more useful to have the stable requests 
> for transitional arches, even if we explicitly state that they can't block 
> anything. 
> 
> Otherwise these arches will never be able to get out of the transitional hole.
> 
> [Maybe someone who actually does slow-arch work should speak up. Anyone out 
> there still reading g-dev?]
> 

I'm lost.  The original definition said that this state is for arches
that use stable only on subset of packages needed for stage building. 
Why would people file streqs for other packages then?

-- 
Best regards,
Michał Górny



signature.asc
Description: This is a digitally signed message part


Re: [gentoo-dev] [PATCH v3 6/9] glep-0072: Combine and amend description of states

2020-04-13 Thread Andreas K . Hüttel
> +Transitional architectures are generally listed after stable architectures,
> +possibly mixed with testing.  Developers are not expected to file
> stabilization +requests.

I'm still claiming that it would be more useful to have the stable requests 
for transitional arches, even if we explicitly state that they can't block 
anything. 

Otherwise these arches will never be able to get out of the transitional hole.

[Maybe someone who actually does slow-arch work should speak up. Anyone out 
there still reading g-dev?]

-- 
Andreas K. Hüttel
dilfri...@gentoo.org
Gentoo Linux developer 
(council, qa, toolchain, base-system, perl, libreoffice)

signature.asc
Description: This is a digitally signed message part.


Re: [gentoo-dev] Re: [gentoo-dev-announce] [RFC] New global USE flag 'speech'

2020-04-13 Thread Gordon Pettey
On Mon, Apr 13, 2020 at 1:13 PM Andreas Sturmlechner 
wrote:

> On Monday, 13 April 2020 18:01:42 CEST Michał Górny wrote:
> > I see one package using 'tts'.
>
> These should switch to 'speech', imo:
> app-i18n/translate-shell[tts] - Enable text-to-speech support
>

I would strongly disagree. TTS has a very clear meaning. All of the listed
cases are explicitly enabling text to speech conversion. They are not
enabling speech input, and they are not enabling speech output without text
input.


Re: [gentoo-dev] Re: [gentoo-dev-announce] [RFC] New global USE flag 'speech'

2020-04-13 Thread Andreas Sturmlechner
On Monday, 13 April 2020 18:01:42 CEST Michał Górny wrote:
> On Mon, 2020-04-13 at 16:52 +0200, Andreas Sturmlechner wrote:
> > Used by 7 packages.
> > 
> > Description: "Enable text-to-speech support"
> 
> I see one package using 'tts'.
> 
> There are also USE=speech uses that aren't clear whether they do match
> or not.  If not, we should rename them to use something else.

All existing users of speech (outside of KDE proj) are probably fine or would 
benefit from a better description anyway:

app-accessibility/brltty - 'speech support'
games-engines/scummvm - enable text-to-speech support through ...
gnustep-base/gnustep-gui - Audio support using app-accessibility/flite
media-sound/mumble - Enable text-to-speech support in Mumble.
net-im/kadu - Enables speech module
net-misc/eventd - Enable plugin for Text-To-Speech support
net-wireless/kismet - Audio support using app-accessibility/flite

There is some inconsistent existing use wrt 'espeak' and 'flite' - both are 
imo fine when used to refer to the specific implementation, as in:

app-accessibility/speech-dispatcher
app-text/stardict
media-video/ffmpeg

These should switch to 'speech', imo:
media-sound/mangler[espeak] - Text to speech engine
app-i18n/translate-shell[tts] - Enable text-to-speech support


signature.asc
Description: This is a digitally signed message part.


Re: [gentoo-dev] [RFC] New global USE flag 'feedback' -> 'telemetry'?

2020-04-13 Thread Andreas Sturmlechner
On Monday, 13 April 2020 19:43:07 CEST Michał Górny wrote:
> On Mon, 2020-04-13 at 19:41 +0200, Andreas Sturmlechner wrote:
> > Less generic, if we could keep this thread about $Subject, would be
> > 'telemetry'. Less positive also, but not as likely to be used for
> > different
> > purpose in the future.
> 
> Why not call it 'spyware'?  ;-)
> 
> /me hides

It probably had to come up but imo the way they are implementing it is fine.

https://community.kde.org/Policies/Telemetry_Policy

Since it is Opt-In feature the flag would be even safe to enable by default.


signature.asc
Description: This is a digitally signed message part.


Re: [gentoo-dev] [RFC] New global USE flag 'feedback' -> 'telemetry'?

2020-04-13 Thread Michał Górny
On Mon, 2020-04-13 at 19:41 +0200, Andreas Sturmlechner wrote:
> On Monday, 13 April 2020 17:01:37 CEST Michael Orlitzky wrote:
> > On 4/13/20 10:58 AM, Andreas Sturmlechner wrote:
> > > Going to be used by 10 packages.
> > > 
> > > Description: "Send anonymized usage information to upstream so they can
> > > better understand our users"
> > 
> > These are all really generic words that might be used by other
> > (non-QT/KDE) packages to mean totally different things.
> 
> Less generic, if we could keep this thread about $Subject, would be 
> 'telemetry'. Less positive also, but not as likely to be used for different 
> purpose in the future.

Why not call it 'spyware'?  ;-)

/me hides

-- 
Best regards,
Michał Górny



signature.asc
Description: This is a digitally signed message part


Re: [gentoo-dev] [RFC] New global USE flag 'feedback' -> 'telemetry'?

2020-04-13 Thread Andreas Sturmlechner
On Monday, 13 April 2020 17:01:37 CEST Michael Orlitzky wrote:
> On 4/13/20 10:58 AM, Andreas Sturmlechner wrote:
> > Going to be used by 10 packages.
> > 
> > Description: "Send anonymized usage information to upstream so they can
> > better understand our users"
> 
> These are all really generic words that might be used by other
> (non-QT/KDE) packages to mean totally different things.

Less generic, if we could keep this thread about $Subject, would be 
'telemetry'. Less positive also, but not as likely to be used for different 
purpose in the future.

signature.asc
Description: This is a digitally signed message part.


Re: [gentoo-dev] [RFC] New global USE flag 'share' -> 'sendto'?

2020-04-13 Thread Andreas Sturmlechner
On Monday, 13 April 2020 19:14:32 CEST Michał Górny wrote:
> On Mon, 2020-04-13 at 18:22 +0200, Andreas Sturmlechner wrote:
> > On Monday, 13 April 2020 18:11:46 CEST Michał Górny wrote:
> > > On Mon, 2020-04-13 at 18:09 +0200, Andreas Sturmlechner wrote:
> > > > "Enable support to share content with other devices or using online
> > > > services"
> > > 
> > > Isn't that roughly equivalent to USE=sendto and possibly more names for
> > > the same concept?
> > 
> > Sounds about right. USE="sendto" currently has gnome-base/nautilus as only
> > user?
> > 
> > Existing user of USE="share" outside of KDE proj:
> > mate-extra/caja-extensions - Add an extension to support sharing files.
> > 
> > Possible other candidates?
> > app-admin/keepassxc[keeshare] - "Enable KeeShare sharing integration"
> > 
> > I didn't find other examples.
> 
> It's a feature that's hard to name.  To be honest, I don't like naming
> it 'share' -- it makes me think of /usr/share, not 'sharing files'.

I am fine with switching to IUSE="sendto" - as a use flag this is less generic 
and prone to future misuse, but still broad enough to fit the description.

signature.asc
Description: This is a digitally signed message part.


Re: [gentoo-dev] [RFC] CC-ARCHES keyword on Bugzilla

2020-04-13 Thread Mike Gilbert
On Mon, Apr 13, 2020 at 1:17 PM Michał Górny  wrote:
>
> Hi,
>
> One of the goals behind NATTkA was to make keywording/stabilization
> easier.  Right now it's mostly possible to file the most common requests
> without having to copy keywords everywhere.  Still, there's a need to CC
> arches which isn't exactly the most convenient part.
>
> I was thinking how to make NATTkA help with that.  After considering
> a few options, I'd like to push forward the following proposition: let's
> add a 'CC-ARCHES' keyword to Bugzilla.  If a bug is marked with that
> keyword and passes sanity check, NATTkA will automatically CC all
> relevant arch teams (based on keyword list).
>
> What do you think?

Sounds good to me.



Re: [gentoo-dev] [RFC] CC-ARCHES keyword on Bugzilla

2020-04-13 Thread Matt Turner
On Mon, Apr 13, 2020 at 10:18 AM Michał Górny  wrote:
>
> Hi,
>
> One of the goals behind NATTkA was to make keywording/stabilization
> easier.  Right now it's mostly possible to file the most common requests
> without having to copy keywords everywhere.  Still, there's a need to CC
> arches which isn't exactly the most convenient part.
>
> I was thinking how to make NATTkA help with that.  After considering
> a few options, I'd like to push forward the following proposition: let's
> add a 'CC-ARCHES' keyword to Bugzilla.  If a bug is marked with that
> keyword and passes sanity check, NATTkA will automatically CC all
> relevant arch teams (based on keyword list).
>
> What do you think?

I like it.



[gentoo-dev] [RFC] CC-ARCHES keyword on Bugzilla

2020-04-13 Thread Michał Górny
Hi,

One of the goals behind NATTkA was to make keywording/stabilization
easier.  Right now it's mostly possible to file the most common requests
without having to copy keywords everywhere.  Still, there's a need to CC
arches which isn't exactly the most convenient part.

I was thinking how to make NATTkA help with that.  After considering
a few options, I'd like to push forward the following proposition: let's
add a 'CC-ARCHES' keyword to Bugzilla.  If a bug is marked with that
keyword and passes sanity check, NATTkA will automatically CC all
relevant arch teams (based on keyword list).

What do you think?

-- 
Best regards,
Michał Górny



signature.asc
Description: This is a digitally signed message part


Re: [gentoo-dev] [RFC] New global USE flag 'share'

2020-04-13 Thread Michał Górny
On Mon, 2020-04-13 at 18:22 +0200, Andreas Sturmlechner wrote:
> On Monday, 13 April 2020 18:11:46 CEST Michał Górny wrote:
> > On Mon, 2020-04-13 at 18:09 +0200, Andreas Sturmlechner wrote:
> > > "Enable support to share content with other devices or using online
> > > services"
> > Isn't that roughly equivalent to USE=sendto and possibly more names for
> > the same concept?
> 
> Sounds about right. USE="sendto" currently has gnome-base/nautilus as only 
> user?
> 
> Existing user of USE="share" outside of KDE proj:
> mate-extra/caja-extensions - Add an extension to support sharing files.
> 
> Possible other candidates?
> app-admin/keepassxc[keeshare] - "Enable KeeShare sharing integration"
> 
> I didn't find other examples.

It's a feature that's hard to name.  To be honest, I don't like naming
it 'share' -- it makes me think of /usr/share, not 'sharing files'.

-- 
Best regards,
Michał Górny



signature.asc
Description: This is a digitally signed message part


Re: [gentoo-dev] [RFC] News Item v3: Desktop profile switching USE default to elogind

2020-04-13 Thread Andreas Sturmlechner
After some feedback in #gentoo-desktop:


On Monday, 13 April 2020 15:19:28 CEST Andreas Sturmlechner wrote:
> Migration is easy, but if run from within a consolekit session that session
> may become broken.

Migration is easy, but any existing consolekit session will be broken, and 
elogind will only begin to work on relogin.

> Optional, but recommended in case of trouble such as missing reboot/shutdown
> capabilities in the DM:

s/DM/display manager/ (first use of the term here, using abbrev. afterwards)

> For users of startx instead of one of the supported DMs, do not forget to
> update ~/.xinitrc accordingly (ck-launch-session is gone without
> replacement).

For users of ~/.xinitrc instead of one of the supported DMs, do not forget to 
update accordingly (ck-launch-session is gone without replacement).


signature.asc
Description: This is a digitally signed message part.


Re: [gentoo-dev] [RFC] New global USE flag 'share'

2020-04-13 Thread Andreas Sturmlechner
On Monday, 13 April 2020 18:11:46 CEST Michał Górny wrote:
> On Mon, 2020-04-13 at 18:09 +0200, Andreas Sturmlechner wrote:
> > "Enable support to share content with other devices or using online
> > services"
> Isn't that roughly equivalent to USE=sendto and possibly more names for
> the same concept?

Sounds about right. USE="sendto" currently has gnome-base/nautilus as only 
user?

Existing user of USE="share" outside of KDE proj:
mate-extra/caja-extensions - Add an extension to support sharing files.

Possible other candidates?
app-admin/keepassxc[keeshare] - "Enable KeeShare sharing integration"

I didn't find other examples.

signature.asc
Description: This is a digitally signed message part.


Re: [gentoo-dev] [RFC] New global USE flag 'share'

2020-04-13 Thread Michał Górny
On Mon, 2020-04-13 at 18:09 +0200, Andreas Sturmlechner wrote:
> On Monday, 13 April 2020 18:00:21 CEST Michał Górny wrote:
> > On Mon, 2020-04-13 at 16:53 +0200, Andreas Sturmlechner wrote:
> > > Used by 8 packages.
> > > 
> > > Description: "Enable support for a share menu using kde-frameworks/
> > > purpose"
> > 
> > This seems like a very narrow definition of feature that sounds broader
> > but is defined in such a way that I'm not sure what the author means
> > and lists a package that seems to have no real connection with
> > the feature in question.
> 
> You're right. A more general description:
> 
> "Enable support to share content with other devices or using online services"

Isn't that roughly equivalent to USE=sendto and possibly more names for
the same concept?

-- 
Best regards,
Michał Górny



signature.asc
Description: This is a digitally signed message part


Re: [gentoo-dev] [RFC] New global USE flag 'share'

2020-04-13 Thread Andreas Sturmlechner
On Monday, 13 April 2020 18:00:21 CEST Michał Górny wrote:
> On Mon, 2020-04-13 at 16:53 +0200, Andreas Sturmlechner wrote:
> > Used by 8 packages.
> > 
> > Description: "Enable support for a share menu using kde-frameworks/
> > purpose"
> 
> This seems like a very narrow definition of feature that sounds broader
> but is defined in such a way that I'm not sure what the author means
> and lists a package that seems to have no real connection with
> the feature in question.

You're right. A more general description:

"Enable support to share content with other devices or using online services"

signature.asc
Description: This is a digitally signed message part.


[gentoo-dev] Re: [gentoo-dev-announce] [RFC] New global USE flag 'speech'

2020-04-13 Thread Michał Górny
On Mon, 2020-04-13 at 16:52 +0200, Andreas Sturmlechner wrote:
> Used by 7 packages.
> 
> Description: "Enable text-to-speech support"

I see one package using 'tts'.

There are also USE=speech uses that aren't clear whether they do match
or not.  If not, we should rename them to use something else.

-- 
Best regards,
Michał Górny



signature.asc
Description: This is a digitally signed message part


Re: [gentoo-dev] [RFC] New global USE flag 'share'

2020-04-13 Thread Michał Górny
On Mon, 2020-04-13 at 16:53 +0200, Andreas Sturmlechner wrote:
> Used by 8 packages.
> 
> Description: "Enable support for a share menu using kde-frameworks/
> purpose"

This seems like a very narrow definition of feature that sounds broader
but is defined in such a way that I'm not sure what the author means
and lists a package that seems to have no real connection with
the feature in question.

-- 
Best regards,
Michał Górny



signature.asc
Description: This is a digitally signed message part


Re: [gentoo-dev] [RFC] New global USE flag 'feedback'

2020-04-13 Thread Michael Orlitzky
On 4/13/20 10:58 AM, Andreas Sturmlechner wrote:
> Going to be used by 10 packages.
> 
> Description: "Send anonymized usage information to upstream so they can 
> better 
> understand our users"
> 

These are all really generic words that might be used by other
(non-QT/KDE) packages to mean totally different things. IMO it would be
better to use names like qt-designer, plasma-activities, etc.



[gentoo-dev] [RFC] New global USE flag 'feedback'

2020-04-13 Thread Andreas Sturmlechner
Going to be used by 10 packages.

Description: "Send anonymized usage information to upstream so they can better 
understand our users"

signature.asc
Description: This is a digitally signed message part.


[gentoo-dev] [RFC] New global USE flag 'activities'

2020-04-13 Thread Andreas Sturmlechner
Used by 10 packages.

Description: "Enable KDE Plasma Activities integration via kde-
frameworks/kactivities"

signature.asc
Description: This is a digitally signed message part.


[gentoo-dev] [RFC] New global USE flag 'share'

2020-04-13 Thread Andreas Sturmlechner
Used by 8 packages.

Description: "Enable support for a share menu using kde-frameworks/
purpose"

signature.asc
Description: This is a digitally signed message part.


[gentoo-dev] [RFC] New global USE flag 'speech'

2020-04-13 Thread Andreas Sturmlechner
Used by 7 packages.

Description: "Enable text-to-speech support"

signature.asc
Description: This is a digitally signed message part.


[gentoo-dev] [RFC] New global USE flag 'designer'

2020-04-13 Thread Andreas Sturmlechner
Used by 23 packages.

Description: "Build plugins for dev-qt/designer"

signature.asc
Description: This is a digitally signed message part.


Re: [gentoo-dev] [RFC] News Item v3: Desktop profile switching USE default to elogind

2020-04-13 Thread Andreas Sturmlechner
On Monday, 13 April 2020 15:19:28 CEST Andreas Sturmlechner wrote:
> ConsoleKit2 is unmaintained upstream for almost two years [2].

s/almost/more than/

...bringing that news item up to date.

signature.asc
Description: This is a digitally signed message part.


[gentoo-dev] [RFC] News Item v3: Desktop profile switching USE default to elogind

2020-04-13 Thread Andreas Sturmlechner
One last RFC before this will be implemented. News will be displayed to anyone 
having sys-auth/consolekit installed.


Title: Desktop profile switching USE default to elogind
Author: Andreas Sturmlechner 
Posted: 2020-04-13
Revision: 1
News-Item-Format: 2.0
Display-If-Installed: sys-auth/consolekit

Modern desktop environments make use of PAM session tracking for users, login 
sessions and seats. [1] The most user-visible part of that is device and file 
permissions management and reboot/shutdown handling without superuser rights.

Users with systemd can stop reading here and continue with their daily 
routine.

ConsoleKit2 is unmaintained upstream for almost two years [2]. There are many 
longstanding bugs and papercuts with consumers that aren't being fixed, not 
least because these code paths receive very little testing.

Enter the elogind project [3], which is a standalone logind implementation 
based on systemd code, currently maintained by a fellow Gentoo user. We have 
had sys-auth/elogind available in Gentoo since the beginning of 2017, and 
meanwhile it has gained support [4] in KDE Plasma, Gnome [5], Cinnamon, MATE 
and Xfce, as well as most other former consolekit consumers.

Consequently, the desktop profile is switching away from consolekit to 
elogind. Users of sys-auth/consolekit who selected a different profile should 
consider doing the same. A guide is available [6]. Migration is easy, but if 
run from within a consolekit session that session may become broken.

Rely either on the profile, or set USE="elogind -consolekit" in make.conf 
yourself. Make sure there is no consolekit debris in /etc/portage/package.use:

# grep -R consolekit /etc/portage/package.use

Rebuild all affected consumers and remove sys-auth/consolekit:

# emerge --ask --changed-use --deep @world
# emerge --depclean consolekit

Optional, but recommended in case of trouble such as missing reboot/shutdown 
capabilities in the DM:

# rc-update add elogind boot

For users of startx instead of one of the supported DMs, do not forget to 
update ~/.xinitrc accordingly (ck-launch-session is gone without replacement).

PS: Subsequently, this will lead to the last-riting of sys-power/pm-utils [7]
which is dead even longer than the original ConsoleKit(1) project. KDE Plasma 
users sticking with sys-auth/consolekit are then going to lose suspend from 
GUI without superuser rights.

[1] https://wiki.gentoo.org/wiki/ConsoleKit
[2] https://github.com/ConsoleKit2/ConsoleKit2
[3] https://github.com/elogind/elogind/blob/master/README.md
[4] https://bugs.gentoo.org/show_bug.cgi?id=elogind-support
[5] https://blogs.gentoo.org/leio/2019/03/26/gnome-3-30/
[6] https://wiki.gentoo.org/wiki/Elogind
[7] https://bugs.gentoo.org/659616


signature.asc
Description: This is a digitally signed message part.


[gentoo-dev] Last rites: ruby24-only packages

2020-04-13 Thread Hans de Graaff
# Hans de Graaff  (2020-04-13)
# ruby24-only packages. Ruby 2.4 is EOL and will be masked for removal
# shortly. These packages either have newer ruby25 slots available, or
# are no longer maintained and have no reverse dependencies. Masked
# for removal in 30 days.
dev-ruby/activeldap:4
dev-ruby/bones
dev-ruby/github_api
dev-ruby/http:0.8
dev-ruby/http-form_data:0.8
dev-ruby/rack-test:0.6
dev-ruby/rails-deprecated_sanitizer
dev-ruby/riel
dev-ruby/shoulda-matchers:0
dev-ruby/vcr:1
dev-ruby/webmock:2


signature.asc
Description: This is a digitally signed message part


[gentoo-dev] Last rites: sci-biology/bioruby and dev-ruby/libxml

2020-04-13 Thread Hans de Graaff
# Hans de Graaff  (2020-04-13)
# dev-ruby/libxml is ruby24-only and has known
# bugs. sci-biology/bioruby depends on this. It looks like there is a
# new version upstream that may not depend on libxml, but this
# requires a dedicated maintainer to test and sort out. Masked for
# removal in 30 days.
dev-ruby/libxml
sci-biology/bioruby


signature.asc
Description: This is a digitally signed message part


Re: [gentoo-dev] Package up for grabs: dev-libs/ppl

2020-04-13 Thread Michael Orlitzky
On 4/13/20 4:55 AM, Sergei Trofimovich wrote:
> Single fresh test failure bug: https://bugs.gentoo.org/717258.

I took it, there are some known arch-specific test failures on the
upstream bug tracker that I'll try to temporarily patch out.



Re: [gentoo-dev] keywording workflow

2020-04-13 Thread Rich Freeman
On Mon, Apr 13, 2020 at 4:12 AM Michał Górny  wrote:
>
> An example workflow is to:
>

Just picking this to reply to though this is more of a general comment
on the two recent keywords threads.

I get that this is Gentoo and we don't want to dictate how people do
things.  However, I feel like this is an area where we'd actually
benefit from more direction.

It seems like we're trying to support more different workflows for
doing keywording/etc than we even have developers doing keywording in
the first place.  It seems like we probably have 5 people at any time
doing actual arch testing but we're maintaining a lot of legacy
code/etc to support 487 ways of going about arch testing because we
don't want to upset somebody who probably doesn't actually do any arch
testing.  At the same time, we have no idea how the 5 people doing the
actual work are actually doing their work, so we can't reliably ensure
that their workflows don't break other than by making sure that we
don't accidentally break any legacy behavior in any way.

What I don't want to do is start a conversation where 27 devs
(including myself) try to tell the people doing a lot of keywording
work how to do their work.  What I would love to see is the people who
actually do keywording share how they actually go about it in
practice, and then maybe try to document some kind of best practice
around this and put it in the devmanual or in a GLEP or something.
Then we can give that workflow more of a first-class support in our
tooling and maybe worry less about others.

I know I was completely taken by surprise by the idea that most
keywording is done using tools these days, and that STABLEREQ isn't
supposed to be a thing now.  Not that these are bad things, but it
seems to have been organic and not really formally transitioned.  The
devmanual no longer mentions the bugzilla keywords, but it also
doesn't mention the bugzilla components and I didn't realize that you
couldn't just turn an existing bug into a stable request just by
adding STABLEREQ and copying arches.  Obviously now I know but my
point is more that it seems like this whole area would benefit from
some kind of suggested workflow.

Heck, this thread is also the first time I think I've seen "pkgcheck
scan --commit" mentioned as a thing.  I see that it was blogged about
a few months ago, but I've stopped following planet Gentoo since
Google reader died.  Maybe we need a planet Gentoo mailing list or
something.

I guess my point is that there seem to be a lot of improved workflows
out there, and we'd probably benefit from them being pointed out a bit
more and mainstreamed.  Those maintaining these tools would probably
benefit as well if more people were using them as intended and they
didn't have to maintain as much legacy compatibility simply because
many don't realize there is a better way...

-- 
Rich



Re: [gentoo-dev] [PATCH v3 6/9] glep-0072: Combine and amend description of states

2020-04-13 Thread Michał Górny
On Mon, 2020-04-13 at 11:02 +0200, Ulrich Mueller wrote:
> > > > > > On Mon, 13 Apr 2020, Michał Górny wrote:
> > -When a profile of an architecture arch is tested, then repoman checks
> > -consistency of the dependency tree for ``arch`` and for ``~arch`` 
> > separately.
> > +Stable means that the architecture is actively maintaning stable keywords.
>   ^^
> Typo. Sorry for not noticing earlier.
> 

Fixed locally.  I suppose there's no need to send v4 for that.

-- 
Best regards,
Michał Górny



signature.asc
Description: This is a digitally signed message part


Re: [gentoo-dev] [PATCH v3 6/9] glep-0072: Combine and amend description of states

2020-04-13 Thread Ulrich Mueller
> On Mon, 13 Apr 2020, Michał Górny wrote:

> -When a profile of an architecture arch is tested, then repoman checks
> -consistency of the dependency tree for ``arch`` and for ``~arch`` separately.
> +Stable means that the architecture is actively maintaning stable keywords.
  ^^
Typo. Sorry for not noticing earlier.

> +When dependency graphs of packages with stable keywords are tested, they
> +are tested separately for ``arch`` and ``~arch`` systems.


signature.asc
Description: PGP signature


[gentoo-dev] Package up for grabs: dev-libs/ppl

2020-04-13 Thread Sergei Trofimovich
Single fresh test failure bug: https://bugs.gentoo.org/717258.

commit f054fd75ab013787e2c65438998067de00de04e5
Author: Sergei Trofimovich 
Date:   Mon Apr 13 09:52:03 2020 +0100

dev-libs/ppl: drop toolchain from maintainers

gcc's graphite does not use dev-libs/ppl for loop
optimizations for a while.

-- 

  Sergei



[gentoo-dev] [PATCH v3 8/9] glep-0072: Move 'overlays' to spec, and change behavior

2020-04-13 Thread Michał Górny
Change the handling of slave repositories to the usual notion of 'slave
overrides master'.

Signed-off-by: Michał Górny 
---
 glep-0072.rst | 22 ++
 1 file changed, 14 insertions(+), 8 deletions(-)

diff --git a/glep-0072.rst b/glep-0072.rst
index 9ad8b61..68b8e91 100644
--- a/glep-0072.rst
+++ b/glep-0072.rst
@@ -150,6 +150,20 @@ Testing means that the architecture does not use stable 
keywords at all.
 Presence of such keywords is considered an error.  Consistency is tested
 only for ``~arch``.
 
+arches.desc in slave repositories
+-
+
+If ``arches.desc`` is present in several repositories, then each file affects
+packages in the repository in question.  If the file does not specify a value
+for given arch, the value from the master repository is used.  However, using
+it in multiple repositories is discouraged.
+
+Note that the stability status override affects only packages in the slave
+repository and their direct dependencies.  If an arch is set to ``testing``,
+then master repositories are still permitted to use stable keywords.  If it is
+set to ``stable``, then missing stable keywords in dependencies from the master
+repository will cause dependency graph inconsistency.
+
 
 Backwards Compatibility
 ===
@@ -178,14 +192,6 @@ to determine a list of stable arches shall fall back to 
the current method
 of determining stable arches by scanning profiles.desc for stable profiles.
 
 
-arches.desc in overlays
-===
-
-If arches.desc is present in several repositories, then the strictest setting
-for an architecture wins. Using arches.desc outside the gentoo (or
-alternative) master repository however is discouraged.
-
-
 Copyright
 =
 
-- 
2.26.0




[gentoo-dev] [PATCH v3 6/9] glep-0072: Combine and amend description of states

2020-04-13 Thread Michał Górny
Provide a combined description for every status that explains what it
means, how it's used by linting tools and how it affects stabilization
requests.

Signed-off-by: Michał Górny 
---
 glep-0072.rst | 46 +++---
 1 file changed, 19 insertions(+), 27 deletions(-)

diff --git a/glep-0072.rst b/glep-0072.rst
index 33a9578..d3afaef 100644
--- a/glep-0072.rst
+++ b/glep-0072.rst
@@ -112,49 +112,41 @@ On introduction, the setting will be ``stable`` for all 
architectures using
 stable keywords, and ``testing`` for those that do not (``alpha``, ``mips``,
 ``riscv``, Prefix profiles at the moment).
 
-Meaning of the values for repoman
--
+Meaning of the values
+-
 stable
 ~~
-When a profile of an architecture arch is tested, then repoman checks
-consistency of the dependency tree for ``arch`` and for ``~arch`` separately.
+Stable means that the architecture is actively maintaning stable keywords.
+When dependency graphs of packages with stable keywords are tested, they
+are tested separately for ``arch`` and ``~arch`` systems.
 
-Which profiles of the architecture are tested is still controlled
-by profiles.desc (and ``-d`` / ``-e`` switches).
+Stable architectures are listed first in keyword-relevant contexts 
(``eshowkw``,
+Bugzilla) and developers are expected to file stabilization requests on these
+arches.
 
 This is the current behaviour and shall be the default if nothing is specified
 for an architecture.
 
 transitional
 
-When a profile of an architecture is tested, then repoman treats ``arch``
-in ebuilds as ``~arch``, and tests consistency only for ``~arch``.
+Transitional means that the architecture does not maintain a consistent stable
+dependency graph but uses stable keywords on some packages.  When dependency
+graphs of packages with stable keywords are tested, they are tested only
+for ``~arch`` systems, i.e. stable keywords are ignored.
 
-Which profiles of the arch are tested is still controlled by profiles.desc
-(and ``-d`` / ``-e`` switches).
+Transitional architectures are generally listed after stable architectures,
+possibly mixed with testing.  Developers are not expected to file stabilization
+requests.
 
-A new switch for repoman may be provided to temporarily upgrade
+A new switch for linting tools may be provided to temporarily upgrade
 an architecture from ``transitional`` to ``stable`` status (for architecture
 team work).
 
 testing
 ~~~
-When a profile of an architecture is tested, then repoman treats ``arch``
-as an error and aborts. Consistency is only tested for ``~arch``.
-
-Which profiles of the arch are tested is still controlled by profiles.desc
-(and ``-d`` / ``-e`` switches).
-
-Meaning of the values for other tools
--
-
-All architectures with the value ``stable`` are considered as stable
-architectures, in the sense that
-
-- they require stabilization requests on bugzilla, which are handled
-  by an arch team
-- they may, e.g., be listed first by tools such as eshowkw
-- and similar, to the discretion of tool authors
+Testing means that the architecture does not use stable keywords at all.
+Presence of such keywords is considered an error.  Consistency is tested
+only for ``~arch``.
 
 
 Backwards Compatibility
-- 
2.26.0




[gentoo-dev] [PATCH v3 9/9] glep-0072: Update metadata

2020-04-13 Thread Michał Górny
Signed-off-by: Michał Górny 
---
 glep-0072.rst | 22 --
 1 file changed, 8 insertions(+), 14 deletions(-)

diff --git a/glep-0072.rst b/glep-0072.rst
index 68b8e91..548ba95 100644
--- a/glep-0072.rst
+++ b/glep-0072.rst
@@ -1,23 +1,17 @@
 ---
 GLEP: 72
 Title: Architecture stability status file
-Author: Andreas K. Hüttel 
+Author: Andreas K. Hüttel ,
+Michał Górny 
 Type: Standards Track
-Status: Deferred
+Status: Draft
 Version: 1
 Created: 2017-05-06
-Last-Modified: 2019-06-10
-Post-History: 2017-05-06
+Last-Modified: 2020-04-12
+Post-History: 2017-05-06, 2020-04-10
 Content-Type: text/x-rst
 ---
 
-Status
-==
-
-Marked as deferred by GLEP editor Ulrich Müller on 2019-06-10, due to
-inactivity.
-
-
 Abstract
 
 
@@ -195,6 +189,6 @@ of determining stable arches by scanning profiles.desc for 
stable profiles.
 Copyright
 =
 
-This work is licensed under the Creative Commons Attribution-ShareAlike 3.0
-Unported License.  To view a copy of this license, visit
-https://creativecommons.org/licenses/by-sa/3.0/.
+This work is licensed under the Creative Commons Attribution-ShareAlike 4.0
+International License. To view a copy of this license, visit
+https://creativecommons.org/licenses/by-sa/4.0/.
-- 
2.26.0




[gentoo-dev] [PATCH v3 5/9] glep-0072: Update initial values

2020-04-13 Thread Michał Górny
I'm not aware of any profiles that should be set to 'degraded', so let's
focus on the immediate problem of stable/testing.  It will also probably
make sense to wait before we start using the third state.

Signed-off-by: Michał Górny 
---
 glep-0072.rst | 7 +++
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/glep-0072.rst b/glep-0072.rst
index acc5da7..33a9578 100644
--- a/glep-0072.rst
+++ b/glep-0072.rst
@@ -108,10 +108,9 @@ An example arches.desc file might look as follows::
 Initial value in the gentoo repository
 --
 
-On introduction, the setting will be ``stable`` for all stable architectures,
-``transitional`` for all architectures where "inofficial" stable keywords are
-maintained and are present in the repository by the arch teams (sh, s390,
-...), and ``testing`` everywhere else.
+On introduction, the setting will be ``stable`` for all architectures using
+stable keywords, and ``testing`` for those that do not (``alpha``, ``mips``,
+``riscv``, Prefix profiles at the moment).
 
 Meaning of the values for repoman
 -
-- 
2.26.0




[gentoo-dev] [PATCH v3 7/9] glep-0072: Explicitly cover file not existing case

2020-04-13 Thread Michał Górny
Signed-off-by: Michał Górny 
---
 glep-0072.rst | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/glep-0072.rst b/glep-0072.rst
index d3afaef..9ad8b61 100644
--- a/glep-0072.rst
+++ b/glep-0072.rst
@@ -96,6 +96,8 @@ whitespace-separated columns:
 
 Additional columns are ignored to allow for future revisions of this document.
 
+If the file does not exist, it is treated as if it were empty.
+
 An example arches.desc file might look as follows::
 
 # Example arches.desc file
-- 
2.26.0




[gentoo-dev] [PATCH v3 4/9] glep-0072: Remove weird third column from example

2020-04-13 Thread Michał Górny
While it should technically be ignored, I don't think it's a good idea
to encourage developers using it for their own purposes.

Signed-off-by: Michał Górny 
---
 glep-0072.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/glep-0072.rst b/glep-0072.rst
index 5be7941..acc5da7 100644
--- a/glep-0072.rst
+++ b/glep-0072.rst
@@ -103,7 +103,7 @@ An example arches.desc file might look as follows::
 x86 stable# not for long
 
 sparc   transitional
-m68ktesting   outdated
+m68ktesting
 
 Initial value in the gentoo repository
 --
-- 
2.26.0




[gentoo-dev] [PATCH v3 3/9] glep-0072: Use 'testing' for pure ~arch

2020-04-13 Thread Michał Górny
'Testing' has generally nicer meaning than 'unstable'.

Signed-off-by: Michał Górny 
---
 glep-0072.rst | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/glep-0072.rst b/glep-0072.rst
index 1e906d2..5be7941 100644
--- a/glep-0072.rst
+++ b/glep-0072.rst
@@ -92,7 +92,7 @@ whitespace-separated columns:
 
 - first column: architecture name (keyword)
 - second column: one of the three values ``stable``, ``transitional``,
-  ``unstable``
+  ``testing``
 
 Additional columns are ignored to allow for future revisions of this document.
 
@@ -103,7 +103,7 @@ An example arches.desc file might look as follows::
 x86 stable# not for long
 
 sparc   transitional
-m68kunstable  outdated
+m68ktesting   outdated
 
 Initial value in the gentoo repository
 --
@@ -111,7 +111,7 @@ Initial value in the gentoo repository
 On introduction, the setting will be ``stable`` for all stable architectures,
 ``transitional`` for all architectures where "inofficial" stable keywords are
 maintained and are present in the repository by the arch teams (sh, s390,
-...), and ``unstable`` everywhere else.
+...), and ``testing`` everywhere else.
 
 Meaning of the values for repoman
 -
@@ -138,8 +138,8 @@ A new switch for repoman may be provided to temporarily 
upgrade
 an architecture from ``transitional`` to ``stable`` status (for architecture
 team work).
 
-unstable
-
+testing
+~~~
 When a profile of an architecture is tested, then repoman treats ``arch``
 as an error and aborts. Consistency is only tested for ``~arch``.
 
-- 
2.26.0




[gentoo-dev] [PATCH v3 2/9] glep-0072: Rename bad depgraph state to 'transitional'

2020-04-13 Thread Michał Górny
In Gentoo terms, 'testing' and 'unstable' are mostly synonymous,
so using the two names for different purposes is confusing.  Use
'transitional' instead.

Signed-off-by: Michał Górny 
---
 glep-0072.rst | 25 +
 1 file changed, 13 insertions(+), 12 deletions(-)

diff --git a/glep-0072.rst b/glep-0072.rst
index 0a9914b..1e906d2 100644
--- a/glep-0072.rst
+++ b/glep-0072.rst
@@ -56,7 +56,7 @@ a) An architecture loses its stable status (imagine c128), but
about a broken stable dependency tree. If we do that, repoman does however
also not check ~c128 consistency, meaning that the ~c128 dependency tree
will soon be broken as well due to negligence.  Given arches.conf as
-   described below, one could set the architecture c128 to "testing" status
+   described below, one could set the architecture c128 to "transitional" 
status
and keep stable profiles. This results in stable keywords being ignored,
but consistency of the ~c128 dependency tree is still enforced.
 
@@ -66,7 +66,7 @@ b) An architecture prepares for becoming a stable 
architecture (think arm64).
as the stable dependency tree is not complete yet, the profiles need to be
set to dev/exp, and again this brings the danger of the ~arm64 dependency
tree getting inadvertently broken. Again the combination of setting the
-   architecture to "testing" in arches.desc and profiles to stable helps.
+   architecture to "transitional" in arches.desc and profiles to stable helps.
 
 Finally, at the moment the "semi-official" algorithm to figure out if an
 architecture is stable in the colloquial sense (e.g., requires stabilization
@@ -91,7 +91,8 @@ are ignored.  Every blank line is ignored. Otherwise the file 
consists of two
 whitespace-separated columns:
 
 - first column: architecture name (keyword)
-- second column: one of the three values ``stable``, ``testing``, ``unstable``
+- second column: one of the three values ``stable``, ``transitional``,
+  ``unstable``
 
 Additional columns are ignored to allow for future revisions of this document.
 
@@ -99,16 +100,16 @@ An example arches.desc file might look as follows::
 
 # Example arches.desc file
 amd64   stable
-x86 stable # not for long
+x86 stable# not for long
 
-mipstesting
-m68kunstable   outdated
+sparc   transitional
+m68kunstable  outdated
 
 Initial value in the gentoo repository
 --
 
 On introduction, the setting will be ``stable`` for all stable architectures,
-``testing`` for all architectures where "inofficial" stable keywords are
+``transitional`` for all architectures where "inofficial" stable keywords are
 maintained and are present in the repository by the arch teams (sh, s390,
 ...), and ``unstable`` everywhere else.
 
@@ -125,8 +126,8 @@ by profiles.desc (and ``-d`` / ``-e`` switches).
 This is the current behaviour and shall be the default if nothing is specified
 for an architecture.
 
-testing
-~~~
+transitional
+
 When a profile of an architecture is tested, then repoman treats ``arch``
 in ebuilds as ``~arch``, and tests consistency only for ``~arch``.
 
@@ -134,8 +135,8 @@ Which profiles of the arch are tested is still controlled 
by profiles.desc
 (and ``-d`` / ``-e`` switches).
 
 A new switch for repoman may be provided to temporarily upgrade
-an architecture from ``testing`` to ``stable`` status (for architecture team
-work).
+an architecture from ``transitional`` to ``stable`` status (for architecture
+team work).
 
 unstable
 
@@ -170,7 +171,7 @@ arches.desc present and old system
 Utilities ignore the unknown file.
 
 Repoman and other tools may emit surplus dependency errors when profiles are
-checked on arches that are ``testing`` (they check the consistency
+checked on arches that are ``transitional`` (they check the consistency
 of the stable tree alone, which may fail, since ``arch`` is supposed to be
 treated like ``~arch``). This affects only development work and can be fixed
 by updating repoman.
-- 
2.26.0




[gentoo-dev] [PATCH v3 0/9] GLEP 72 (arches.desc) revival

2020-04-13 Thread Michał Górny
Hi,

Changes in v3:
- fixed commit message
- updated license

Michał Górny (9):
  glep-0072: Remove redundant 'broken' status
  glep-0072: Rename bad depgraph state to 'transitional'
  glep-0072: Use 'testing' for pure ~arch
  glep-0072: Remove weird third column from example
  glep-0072: Update initial values
  glep-0072: Combine and amend description of states
  glep-0072: Explicitly cover file not existing case
  glep-0072: Move 'overlays' to spec, and change behavior
  glep-0072: Update metadata

 glep-0072.rst | 126 +++---
 1 file changed, 57 insertions(+), 69 deletions(-)

-- 
2.26.0




[gentoo-dev] [PATCH v3 1/9] glep-0072: Remove redundant 'broken' status

2020-04-13 Thread Michał Górny
This is really no different from marking the profiles exp, and there
seems no value in having this controlled in two places.

Signed-off-by: Michał Górny 
---
 glep-0072.rst | 8 +---
 1 file changed, 1 insertion(+), 7 deletions(-)

diff --git a/glep-0072.rst b/glep-0072.rst
index 61f9c16..0a9914b 100644
--- a/glep-0072.rst
+++ b/glep-0072.rst
@@ -91,8 +91,7 @@ are ignored.  Every blank line is ignored. Otherwise the file 
consists of two
 whitespace-separated columns:
 
 - first column: architecture name (keyword)
-- second column: one of the four values ``stable``, ``testing``, ``unstable``,
-  ``broken``
+- second column: one of the three values ``stable``, ``testing``, ``unstable``
 
 Additional columns are ignored to allow for future revisions of this document.
 
@@ -146,11 +145,6 @@ as an error and aborts. Consistency is only tested for 
``~arch``.
 Which profiles of the arch are tested is still controlled by profiles.desc
 (and ``-d`` / ``-e`` switches).
 
-broken
-~~
-Repoman is not testing any profiles of this architecture, irrespective
-of the settings in profiles.desc.
-
 Meaning of the values for other tools
 -
 
-- 
2.26.0




[gentoo-dev] Re: [gentoo-dev-announce] Package up for grabs: dev-lang/coffee-script

2020-04-13 Thread Ulrich Mueller
> On Sat, 11 Apr 2020, Michael Orlitzky wrote:

> NB: why are we still requiring a  comment in
> 2020 to indicate that a package is maintainer-needed? That information
> is already present in and easily retrievable from the XML. If you're
> grepping XML, you're doing it wrong. Use e.g. "xmllint --xpath" instead.

Arguably the mistake is in using XML, in the first place. :)

Ulrich


signature.asc
Description: PGP signature


Re: [gentoo-dev] [PATCH v2 9/9] glep-0072: Update metadata

2020-04-13 Thread Ulrich Mueller
Also update the license to "Creative Commons Attribution-ShareAlike 4.0
International", please.


signature.asc
Description: PGP signature


Re: [gentoo-dev] [PATCH v2 2/9] glep-0072: Rename bad depgraph state to 'degraded'

2020-04-13 Thread Ulrich Mueller
> On Sun, 12 Apr 2020, Michał Górny wrote:

> glep-0072: Rename bad depgraph state to 'degraded'
   
> 
> In Gentoo terms, 'testing' and 'unstable' are mostly synonymous,
> so using the two names for different purposes is confusing.  Use
> 'degraded' instead.
   

Update the commit message as well.


signature.asc
Description: PGP signature


[gentoo-dev] Changes in keywording: more convenient package lists

2020-04-13 Thread Michał Górny
Hello,

TL;DR: nattka has new 'commit' and 'resolve' commands, package lists for
keywordreqs accept any atoms, both kwreq and streq accept '*' (= all
previous) and '^' (= same as above) in keywords.


As I've announced earlier, NATTkA has been deployed as a replacement for
stable-bot.  I'm sure most of you have already seen some new bug spam,
including some flip-flops for which I am sorry.  I am still busy fixing
(and sometimes introducing) various bugs, on the level of 2-3 releases
a day but I'm getting close to finishing the basic TODO.


Changes to package list
===
The most important late changes are introduction in two convenience
measures.  Firstly, for keywording bugs you can now use any package
dependency syntax:

  dev-python/pytest
   tag and have sanity-check automatically add
it to bugs if all packages fit.

-- 
Best regards,
Michał Górny



signature.asc
Description: This is a digitally signed message part