[gentoo-dev] package up for grabs: mail-filter/spambayes

[Thomas - LordVan - Raschbacher]

Hi.

I decided to either give up maintainership of spambayes (not that there
were any releases in the last 5+ years anyway).

Anyone interested? if not I'll change it to maintainer-needed (or maybe
just treeclean it .. not sure yet if anyone at all still cares - as far
as I could see no packages depend on it in the tree)

Regards
P.S.: if you're interested at least CC me directly please

-- 
Thomas Raschbacher
Gentoo Developer
https://keybase.io/lordvan

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

[Hans de Graaff]

On Mon, 2017-07-10 at 10:41 +0200, Paweł Hajdan, Jr. wrote:
> Hey folks,
> 
> If you'd like to help Gentoo stable be more up to date, please read
> on.
> 
> See
>  9.txt>
> for potential stabilization candidates (over 1000 of them).

Now that ruby has switched to use.stable.mask for newer ruby targets it
 is no longer needed to exclude it from the list.

Hans

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

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

[Brian Dolbec]

On Mon, 10 Jul 2017 15:41:04 +0200
Kristian Fiskerstrand  wrote:

> On 07/10/2017 03: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/
> >   
> 
> I might've read things too quickly, we're not talking a repoman check
> here?
> 

Yes, the warning would be a repoman check for version bumps, etc...

What he is talking about, is OT, and I want to automate with a buildbot
instance that can do automated testing for all python pkgs (to start
with) that have tests enabled in the ebuild.  I am also planning to
help with automatic version bumps for those pkgs as well.  If not
committed straight to the tree, then emailed as a patch to the
maintainers, perhaps in a pending repo/branch, bugzilla... TBD.


Oh, and I want to connect as many arch specific workers to it as well.

That should ease ebuild bumps, PYTHON_COMPAT and keywording
maintainence.

Once in place and operational, it should give the groundwork to add
other pkg types, not just python based pkgs.
-- 
Brian Dolbec 



pgpN7g2ENsI6V.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] Sets vs Meta ebuilds

[Walter Dnes]

  I have a script I've written for my own use.  It's not 100% polished,
but it does the job for me.  My "autodepclean" script runs
"emerge --pretend --depclean", and reformats the output into another
script, named "cleanscript", which contains a bunch of lines like...

emerge --depclean --verbose =fu-bar/xyz-1.2.3

  Before running "./cleanscript", I check it for problems.  Here's the
autodepclean script...

#!/bin/bash
# autodepclean script v 0.04 released under GPL v3 by Walter Dnes 2012/07/09
# Generates a file "cleanscript" to remove unused ebuilds, including
# buildtime-only dependancies.
#
# Warning; this script is still beta.  I recommend that you check the output
# in cleanscript before running it.
#
# With the arrival of "virtual/editor", the script now suggests removing
# app-editors/nano, which may not be what you want.  If you want to keep
# nano, put it into world
#
# version 0.03 disables the removal of gentoo-sources.  Your current kernel
# is not always the most recent one in /usr/src.
#
# version 0.04 adds "--verbose" to the "emerge --depclean".  This makes it
# easier to track down circular dependancies.
#
echo "#!/bin/bash" > cleanscript
echo "#" >> cleanscript
emerge --pretend --depclean |\
  grep -A1 "^ .*/" |\
  grep -v "^ \*" |\
  grep -v "^--" |\
  sed ":/: {
N
s:\n::
s/selected: /-/
s/^ /emerge --depclean --verbose =/
}" | grep -v "gentoo-sources" >> cleanscript
echo "revdep-rebuild" >> cleanscript
chmod 744 cleanscript

-- 
Walter Dnes 
I don't run "desktop environments"; I run useful applications

Re: [gentoo-dev] Native vs Scripting language for portage speed concerns was -> Sets vs Meta ebuilds

[Rich Freeman]

On Mon, Jul 10, 2017 at 9:29 PM, William L. Thomson Jr.
 wrote:
>
> I am aware in a way. Depends on how implemented. This has to hit
> package.env files. But what you see below comes from a dependency list.
> I have packages with even more deps.
>

If you want to cope with poor package maintenance practices you might
also need to scan the entire repository to find packages which had a
dependency added after the package in question was installed.  I
forget if portage does this currently - I do remember this being the
topic of a fair bit of debate a while back.  I'm pretty sure failing
to revbump when dependencies are changed is considered a QA issue for
this reason.

-- 
Rich

Re: [gentoo-dev] Native vs Scripting language for portage speed concerns was -> Sets vs Meta ebuilds

[William L. Thomson Jr.]

On Tue, 11 Jul 2017 02:23:56 +0100
Ciaran McCreesh  wrote:

> On Mon, 10 Jul 2017 18:14:23 -0700
> Raymond Jennings  wrote:
> > If I may ask, does anyone have any profiling information one way or
> > the other to shed light on the situation?  

There are profilers for python. Python devs can comment on such. I am
not sure about other things like looking for leaks etc. I was not able
to run python stuff through valgrind. At least I could not run
java-config through valgrind like I do with jem.

IMHO python all around is just not as robust and should not be used for
such purposes. There maybe ways to make it faster. For something with
the complexity, it should really be done in something more robust. Just
requires talent to make it such.

> Paludis does complete dependency and unused package tracking for
> everything by default. Any performance difficulties are
> implementation-related, not a fundamental problem.

I agree its a portage issue. Not saying anyone's code sucks or
discounting their efforts. Things do not have to be slow.

I mentioned this directly to some portage people in person a few years
ago during a meeting in Southern California... Around the time I put
jem on Github.

It is really hard to start over if/when that happens. Thus doing it
piece meal maybe easier. Though may still end up with spaghetti in the
end. Hopefully it runs fast and taste good :)

-- 
William L. Thomson Jr.


pgpPx38rQhqRU.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] Sets vs Meta ebuilds

[William L. Thomson Jr.]

On Tue, 11 Jul 2017 02:09:12 +0100
Ciaran McCreesh  wrote:

> On Tue, 11 Jul 2017 00:24:10 +0200
> Michał Górny  wrote:
> > William, I'm not sure if you're aware of how package managers work
> > but checking reverse dependencies of a package takes significant
> > amount of time. Changing -C to do that would be a serious
> > performance regression. Which would result in users requesting yet
> > another option to disable this.  
> 
> Eh, that's a Portage performance problem, not a package manager
> performance problem.

I do recall years ago paludis being much faster, and providing more
detailed information on package slots, archs, etc. In a graph like
output if I recall. It was super useful in package maintenance. It
really helped with cleaning things safely!

Last I checked in out ~year or so, It was just to difficult to get to
work with portage. Paludis has changed considerably. Seems you need to
change a system to work with it. Not as use along side of portage as it
was in the past. It would be nice to be able to compare it side by side
to portage. Though I know it has some different features.

Need to check out pkgcore. Though I am not the one complaining about
time. Just saying for those who are...

-- 
William L. Thomson Jr.


pgp78rFL5QpTN.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] Native vs Scripting language for portage speed concerns was -> Sets vs Meta ebuilds

[William L. Thomson Jr.]

On Mon, 10 Jul 2017 20:12:28 -0500
R0b0t1  wrote:

> On Mon, Jul 10, 2017 at 6:56 PM, William L. Thomson Jr.
>  wrote:
>>
> > IMHO anyone complaining about time taking for dependency resolution
> > etc. They should spend THEIR time writing stuff in a real native
> > language for speed.
> >
> > The difference I see with jem[1] vs java-config, is ridiculous.

> > If aspects of portage were done in C or C++, or maybe even Go. There
> > would be substantial performance improvements. The existing python
> > code can remain. Python can load and call functions from C/C++ DSO.
> > And vice versa, calling Python code from C/C++. I would say C vs
> > C++ but that is up to others.
> >  
> 
> https://wiki.gentoo.org/wiki/Q_applets
> 
> What you're suggesting is actually really hard, and the root of the
> problems tend to be graph traversals and path searches (for
> dependencies) not so much miscellaneous milliseconds spent in
> interpreter overhead.

I am aware in a way. Depends on how implemented. This has to hit
package.env files. But what you see below comes from a dependency list.
I have packages with even more deps.

jem --help

 Package Options:
  -d, --with-dependenciesInclude package dependencies in
--classpath and --library calls
  -p, --classpath=PACKAGE(s) Print entries in the environment classpath
for these packages

jem -d -p eclipse-jdt-core-4.6
/usr/share/ant-core/lib/ant.jar:/usr/share/ant-core/lib/ant-bootstrap.jar:/usr/share/ant-core/lib/ant-launcher.jar:/usr/share/eclipse-core-contenttype-4.6/lib/eclipse-core-contenttype.jar:/usr/share/eclipse-core-filesystem-4.6/lib/eclipse-core-filesystem.jar:/usr/share/eclipse-core-jobs-4.6/lib/eclipse-core-jobs.jar:/usr/share/eclipse-core-resources-4.6/lib/eclipse-core-resources.jar:/usr/share/eclipse-core-runtime-4.6/lib/eclipse-core-runtime.jar:/usr/share/eclipse-equinox-app-4.6/lib/eclipse-equinox-app.jar:/usr/share/eclipse-equinox-common-4.6/lib/eclipse-equinox-common.jar:/usr/share/eclipse-equinox-preferences-4.6/lib/eclipse-equinox-preferences.jar:/usr/share/eclipse-equinox-registry-4.6/lib/eclipse-equinox-registry.jar:/usr/share/eclipse-osgi-4.6/lib/eclipse-osgi.jar:/usr/share/eclipse-text-4.6/lib/eclipse-text.jar:/usr/share/osgi-core-api-6/lib/osgi-core-api.jar:/usr/share/eclipse-core-expressions-4.6/lib/eclipse-core-expressions.jar:/usr/share/osgi-compendium-6/lib/osgi-compendium.jar:/usr/share/eclipse-osgi-services-4.6/lib/eclipse-osgi-services.jar:/usr/share/osgi-annotation/lib/osgi-annotation.jar:/usr/share/felix-resolver/lib/felix-resolver.jar:/usr/share/eclipse-core-commands-4.6/lib/eclipse-core-commands.jar:/usr/share/icu4j-59/lib/icu4j.jar:/usr/share/glassfish-persistence/lib/glassfish-persistence.jar:/usr/share/osgi-foundation/lib/org.osgi.foundation.jar:/usr/share/tomcat-servlet-api-4.0/lib/el-api.jar:/usr/share/tomcat-servlet-api-4.0/lib/jsp-api.jar:/usr/share/tomcat-servlet-api-4.0/lib/servlet-api.jar:/usr/share/eclipse-jdt-core-4.6/lib/eclipse-jdt-core.jar

jem
real0m0.004s
user0m0.000s
sys 0m0.005s

java-config
real0m0.075s
user0m0.057s
sys 0m0.017s

On further runs of java-config
real0m0.121s
user0m0.105s
sys 0m0.017s

jem never exceeds 0m0.005s for any real, user, or sys

> Then again, I suppose there will be people on computers slow enough
> where the latter does make a difference.

arm? Laptops? Even if not speed, resources. But when its used for many
packages called over and over. It can start to add up little by little.
We can all use more time.

-- 
William L. Thomson Jr.


pgp8KTatcPSBN.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] Native vs Scripting language for portage speed concerns was -> Sets vs Meta ebuilds

[Ciaran McCreesh]

On Mon, 10 Jul 2017 18:14:23 -0700
Raymond Jennings  wrote:
> If I may ask, does anyone have any profiling information one way or
> the other to shed light on the situation?

Paludis does complete dependency and unused package tracking for
everything by default. Any performance difficulties are
implementation-related, not a fundamental problem.

-- 
Ciaran McCreesh

Re: [gentoo-dev] Native vs Scripting language for portage speed concerns was -> Sets vs Meta ebuilds

[Raymond Jennings]

If I may ask, does anyone have any profiling information one way or the
other to shed light on the situation?

On Mon, Jul 10, 2017 at 6:12 PM, R0b0t1  wrote:

> On Mon, Jul 10, 2017 at 6:56 PM, William L. Thomson Jr.
>  wrote:
> > On Mon, 10 Jul 2017 17:47:45 -0500
> > Gordon Pettey  wrote:
> >
> >> On Mon, Jul 10, 2017 at 5:24 PM, Michał Górny 
> >> wrote:
> >>
> >> > On pon, 2017-07-10 at 17:40 -0400, William L. Thomson Jr. wrote:
> >> > > Stop getting lost in the weeds
> >> > > You all are making this about -c vs -C. I am not talking about
> >> > > that!
> >> > >
> >> > > LET ME CLARIFY
> >> > >
> >> > > When using -C, portage SHOULD warn for dependencies like it does
> >> > > for profile and set packages, PERIOD. NOTHING to do with -c vs -C.
> >> > >
> >> > > When using -c the output should say in layman's terms,
> >> > > "Not removing package A because it is a dependency"
> >> >
> >> > William, I'm not sure if you're aware of how package managers work
> >> > but checking reverse dependencies of a package takes significant
> >> > amount of time.
> >>
> >>
> >> for x in $(eix -I --only-names); do time equery g $x > /dev/null; done
> >>
> >> The only single package on my system that took more than 2 seconds
> >> total time was gcc. The idea that that is too much time to add to
> >> emerge -c or -C, which in my experience already takes multiple
> >> seconds to run anyway is kind of silly.
> >
> > IMHO anyone complaining about time taking for dependency resolution
> > etc. They should spend THEIR time writing stuff in a real native
> > language for speed.
> >
> > The difference I see with jem[1] vs java-config, is ridiculous.
> > Sometimes I merge hundreds of java packages. All those milliseconds add
> > up. Not to mention resources, ram, CPU, and all drains your battery...
> >
> > If aspects of portage were done in C or C++, or maybe even Go. There
> > would be substantial performance improvements. The existing python code
> > can remain. Python can load and call functions from C/C++ DSO. And vice
> > versa, calling Python code from C/C++. I would say C vs C++ but that is
> > up to others.
> >
>
> https://wiki.gentoo.org/wiki/Q_applets
>
> What you're suggesting is actually really hard, and the root of the
> problems tend to be graph traversals and path searches (for
> dependencies) not so much miscellaneous milliseconds spent in
> interpreter overhead.
>
> Then again, I suppose there will be people on computers slow enough
> where the latter does make a difference.
>
> > Put my time where my mouth is... Well I did, its called jem. What is
> > jem? Its java-config ported to C. I would be looking to port more of
> > Gentoo's tools to C for longevity and speed. Not speed of development,
> > but speed for everyone else. Instead I am doing C for other projects.
> >
> > 1. https://github.com/Obsidian-StudiosInc/jem
> >
> > P.S.
> > jem does need a bit more work to replace java-config entirely. Its
> > designed to not be Gentoo specific. There is little interest from
> > Gentoo, much less outside. Thus its more a case study than anything
> > benefiting anyone including myself. I will further it as I have
> > interest and time permits. Still have a few more defects to address.
> >
>
>

Re: [gentoo-dev] Native vs Scripting language for portage speed concerns was -> Sets vs Meta ebuilds

[R0b0t1]

On Mon, Jul 10, 2017 at 6:56 PM, William L. Thomson Jr.
 wrote:
> On Mon, 10 Jul 2017 17:47:45 -0500
> Gordon Pettey  wrote:
>
>> On Mon, Jul 10, 2017 at 5:24 PM, Michał Górny 
>> wrote:
>>
>> > On pon, 2017-07-10 at 17:40 -0400, William L. Thomson Jr. wrote:
>> > > Stop getting lost in the weeds
>> > > You all are making this about -c vs -C. I am not talking about
>> > > that!
>> > >
>> > > LET ME CLARIFY
>> > >
>> > > When using -C, portage SHOULD warn for dependencies like it does
>> > > for profile and set packages, PERIOD. NOTHING to do with -c vs -C.
>> > >
>> > > When using -c the output should say in layman's terms,
>> > > "Not removing package A because it is a dependency"
>> >
>> > William, I'm not sure if you're aware of how package managers work
>> > but checking reverse dependencies of a package takes significant
>> > amount of time.
>>
>>
>> for x in $(eix -I --only-names); do time equery g $x > /dev/null; done
>>
>> The only single package on my system that took more than 2 seconds
>> total time was gcc. The idea that that is too much time to add to
>> emerge -c or -C, which in my experience already takes multiple
>> seconds to run anyway is kind of silly.
>
> IMHO anyone complaining about time taking for dependency resolution
> etc. They should spend THEIR time writing stuff in a real native
> language for speed.
>
> The difference I see with jem[1] vs java-config, is ridiculous.
> Sometimes I merge hundreds of java packages. All those milliseconds add
> up. Not to mention resources, ram, CPU, and all drains your battery...
>
> If aspects of portage were done in C or C++, or maybe even Go. There
> would be substantial performance improvements. The existing python code
> can remain. Python can load and call functions from C/C++ DSO. And vice
> versa, calling Python code from C/C++. I would say C vs C++ but that is
> up to others.
>

https://wiki.gentoo.org/wiki/Q_applets

What you're suggesting is actually really hard, and the root of the
problems tend to be graph traversals and path searches (for
dependencies) not so much miscellaneous milliseconds spent in
interpreter overhead.

Then again, I suppose there will be people on computers slow enough
where the latter does make a difference.

> Put my time where my mouth is... Well I did, its called jem. What is
> jem? Its java-config ported to C. I would be looking to port more of
> Gentoo's tools to C for longevity and speed. Not speed of development,
> but speed for everyone else. Instead I am doing C for other projects.
>
> 1. https://github.com/Obsidian-StudiosInc/jem
>
> P.S.
> jem does need a bit more work to replace java-config entirely. Its
> designed to not be Gentoo specific. There is little interest from
> Gentoo, much less outside. Thus its more a case study than anything
> benefiting anyone including myself. I will further it as I have
> interest and time permits. Still have a few more defects to address.
>

Re: [gentoo-dev] Sets vs Meta ebuilds

[Ciaran McCreesh]

On Mon, 10 Jul 2017 17:21:42 -0400
Ian Stakenvicius  wrote:
> On 10/07/17 04:47 PM, William L. Thomson Jr. wrote:
> > On Mon, 10 Jul 2017 15:36:11 -0500
> > Ben Kohler  wrote:  
> >>
> >> If you want dependencies checked, use the correct option which
> >> checks them.  This takes significantly longer than -C, as it's
> >> significantly more complex to check for.
> >>
> >> As far as I can tell, you are literally asking for -C to behave
> >> like -c, when you could just be using -c instead.  
> > 
> > No I simply want warnings like that exist for profiles and set
> > packages.
> > 
> > Also more information when attempting to remove a package that is
> > not removed.
> >   
> 
> OK, well, as Ben said it's not feasible to make -C act like -c due to
> the performance hit involved and due to the purpose of the command
> itself.

Have you profiled this? It shouldn't be slow if implemented correctly.

-- 
Ciaran McCreesh

Re: [gentoo-dev] Sets vs Meta ebuilds

[Ciaran McCreesh]

On Tue, 11 Jul 2017 00:24:10 +0200
Michał Górny  wrote:
> William, I'm not sure if you're aware of how package managers work but
> checking reverse dependencies of a package takes significant amount of
> time. Changing -C to do that would be a serious performance
> regression. Which would result in users requesting yet another option
> to disable this.

Eh, that's a Portage performance problem, not a package manager
performance problem.

-- 
Ciaran McCreesh

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

[Aaron Bauman]

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

Your efforts have not gone unnoticed from my perspective.  You were always the 
one to do the bulk of the work on most arches.

I don't believe that you going on a break will fix anything either.  The bottom 
line is that you cannot do it alone and maintain the state of stable tree that 
is expected by our users and fellow developers.

If you cannot accept that your work alone is not enough then I would ask you 
reevaluate the importance of those minor arches.  The facts are evident and 
they are a hinderance to the overall state of the distribution, in my opinion. 
There is more than just keywording and stabilization at stake here.  Security 
is a major factor as well.

Surely, you will be missed during your break and I hope you find some time to 
recuperate.  Thank you for all the work you have done and surely will do in 
the future.

-Aaron


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

Re: [gentoo-dev] Native vs Scripting language for portage speed concerns was -> Sets vs Meta ebuilds

[William L. Thomson Jr.]

On Mon, 10 Jul 2017 17:47:45 -0500
Gordon Pettey  wrote:

> On Mon, Jul 10, 2017 at 5:24 PM, Michał Górny 
> wrote:
> 
> > On pon, 2017-07-10 at 17:40 -0400, William L. Thomson Jr. wrote:
> > > Stop getting lost in the weeds
> > > You all are making this about -c vs -C. I am not talking about
> > > that!
> > >
> > > LET ME CLARIFY
> > >
> > > When using -C, portage SHOULD warn for dependencies like it does
> > > for profile and set packages, PERIOD. NOTHING to do with -c vs -C.
> > >
> > > When using -c the output should say in layman's terms,
> > > "Not removing package A because it is a dependency"
> >
> > William, I'm not sure if you're aware of how package managers work
> > but checking reverse dependencies of a package takes significant
> > amount of time.
> 
> 
> for x in $(eix -I --only-names); do time equery g $x > /dev/null; done
> 
> The only single package on my system that took more than 2 seconds
> total time was gcc. The idea that that is too much time to add to
> emerge -c or -C, which in my experience already takes multiple
> seconds to run anyway is kind of silly.

IMHO anyone complaining about time taking for dependency resolution
etc. They should spend THEIR time writing stuff in a real native
language for speed.

The difference I see with jem[1] vs java-config, is ridiculous.
Sometimes I merge hundreds of java packages. All those milliseconds add
up. Not to mention resources, ram, CPU, and all drains your battery...

If aspects of portage were done in C or C++, or maybe even Go. There
would be substantial performance improvements. The existing python code
can remain. Python can load and call functions from C/C++ DSO. And vice
versa, calling Python code from C/C++. I would say C vs C++ but that is
up to others.

Put my time where my mouth is... Well I did, its called jem. What is
jem? Its java-config ported to C. I would be looking to port more of
Gentoo's tools to C for longevity and speed. Not speed of development,
but speed for everyone else. Instead I am doing C for other projects.

1. https://github.com/Obsidian-StudiosInc/jem

P.S.
jem does need a bit more work to replace java-config entirely. Its
designed to not be Gentoo specific. There is little interest from
Gentoo, much less outside. Thus its more a case study than anything
benefiting anyone including myself. I will further it as I have
interest and time permits. Still have a few more defects to address.

-- 
William L. Thomson Jr.


pgpm9WoCEPEM4.pgp
Description: OpenPGP digital signature

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

[Andrew Savchenko]

On Mon, 10 Jul 2017 16:27:54 -0400 Rich Freeman wrote:
> On Mon, Jul 10, 2017 at 4:05 PM, M. J. Everitt  wrote:
> > This is why stabilisation, if not for individual package maintainers on
> > amd64, has become a joke, save for Ago's efforts, and recent efforts by
> > kensington to streamline the effort for the likes of ago with his bot,
> > and one or two other arch stabilisers (who I know exist, but not by name
> > or nick).
> 
> Sure.  If nobody is maintaining stable keywords on an arch, then there
> shouldn't be stable keywords on that arch, unless the stable keywords
> are used for a different purpose and maintainers are free to downgrade
> them at any time.

I'm confused, again. I can't find any official policy regarding
dekeywording packages from stable to testing.

Can developers remove packages from stable on whim or only on
certain conditions? Under what conditions exactly? Should arch
teams be notified on such actions? Or even requested permissions
from?

IMO a valid reason to remove from stable is arch team failure to
stabilize this package for a long time. But how long? Month, two,
half a year?

What to do with reverse dependencies? Should they be dropped to
~arch altogether with the package in question? Or should their
maintainers be given a warning before? How long to wait after?
One more month or two, another half a year?

Maybe I should move this discussion to the wg_stable ML, but
there are few people there and gentoo-dev has much wider coverage.

A well established arch -> ~arch policy should help to keep number
of stable packages sane and manageable for arch teams. A well
established policy of doing ~arch -> arch by devs themselves will
help to lower load on arch teams as well. So for everyone be happy
(arch teams by keeping them stable and manageable, devs by solving
stabilization requests in a sane time) we need good policies!

Best regards,
Andrew Savchenko


pgpGBPh8B9Gld.pgp
Description: PGP signature

Re: [gentoo-dev] Auto adding packages to world was -> Sets vs Meta ebuilds

[William L. Thomson Jr.]

On Mon, 10 Jul 2017 19:22:47 -0400
"William L. Thomson Jr."  wrote:
>
> That part does not require it to resolve deps. Just check world file,
> assuming its correct. Though could be thrown off if say gcc, or
> another was in the world file. I think the profile or set would catch
> that as it does now and generate a warning, regardless.

Speaking of gcc in the world file. I think portage should STOP adding
packages that are in the profile or a dep to world. If you merge a
package as part of a set, I am pretty sure it does not get recorded to
world, need to confirm, could be wrong.

A rule for portage could be;

 - If the package is not in world and already installed. Do not add the
   package to world. If you are re-emerging a package already
   installed. You do not have to use the -1 option. 

I have polluted so many world files with system packages and/or
dependencies I re-emerged directly without -1. Those IMHO should never
have been recorded to that file. They were brought in by other things.
Only things in my world should be packages merged directly, not from
profile, set, or a dep.

I will file a bug on that as well.

-- 
William L. Thomson Jr.


pgppvJ2qYUHfP.pgp
Description: OpenPGP digital signature

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

[Andrew Savchenko]

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?

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?

Best regards,
Andrew Savchenko


pgpYEUqvw0qvV.pgp
Description: PGP signature

Re: [gentoo-dev] Sets vs Meta ebuilds

[William L. Thomson Jr.]

On Mon, 10 Jul 2017 17:08:54 -0500
Ben Kohler  wrote:

> On Mon, Jul 10, 2017 at 4:42 PM, William L. Thomson Jr.
>  wrote:
> 
> >
> > If people understood, then saying use -c or -C makes no sense. It
> > does not address the lack of output from either I am talking about.
> >
> > --
> > William L. Thomson Jr.
> >
> I really thought I understood you in that you wanted true reverse
> dependencies calculated, to check against that, and warn for it. 

You are correct in that. Which the -c option already does. It just does
not tell you why it did not remove a package. When you add -v/verbose.
It shows you the deps, or some. But it does not tell you it will not
remove because those packages depend on it. Seems obvious, but if you
did not use -v/verbose. You do not see those deps, and just have to
assume. Even when the deps are shown. The user must assume the package
was not removed due to deps, because its not saying explicitly.

It is not changing anything with the -c option. Other than generating
some additional generic text for the user as part of its current output
and function. With package A being the one they are trying to remove.
The rest would be boiler plate

"Package ${PN} not removed due to dependencies"

> I  think that you are actually talking about a warning upon forced
> unmerge of anything not in /var/lib/portage/world, is that correct?

That is also correct. Its two fold.

 -  If using -c, the deps are known, or at least some, and takes time.
The output just needs to say will not remove because of deps. Not
specifically what deps. It could in theory stop on the first
encountered to save time, and only go further if -v is specified.
Which it may now I have not looked at the code.

 - If using -C it should at minimum check if the package is in
   world/user installed, and say something otherwise.

That part does not require it to resolve deps. Just check world file,
assuming its correct. Though could be thrown off if say gcc, or another
was in the world file. I think the profile or set would catch that as
it does now and generate a warning, regardless.

Now in the case of no world file, or something, they maybe revert back
to some of the behavior of -c. with -C. But I would think if no world
file, or packages in world. Then the user did not emerge anything or
nuked that file.

The -C option already seems to check say a profile and set file.
Otherwise how would it know that package was in either. Seems the same
could be done for a package not in either of those files, or world. To
warn, your removing a package you did not install.

I will file 2 bugs, that should be straight forward and clear.

-- 
William L. Thomson Jr.


pgpOj7xSdj0TL.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] Sets vs Meta ebuilds

[Michał Górny]

On pon, 2017-07-10 at 17:47 -0500, Gordon Pettey wrote:
> On Mon, Jul 10, 2017 at 5:24 PM, Michał Górny  wrote:
> 
> > On pon, 2017-07-10 at 17:40 -0400, William L. Thomson Jr. wrote:
> > > Stop getting lost in the weeds
> > > You all are making this about -c vs -C. I am not talking about that!
> > > 
> > > LET ME CLARIFY
> > > 
> > > When using -C, portage SHOULD warn for dependencies like it does for
> > > profile and set packages, PERIOD. NOTHING to do with -c vs -C.
> > > 
> > > When using -c the output should say in layman's terms,
> > > "Not removing package A because it is a dependency"
> > 
> > William, I'm not sure if you're aware of how package managers work but
> > checking reverse dependencies of a package takes significant amount of
> > time.
> 
> 
> for x in $(eix -I --only-names); do time equery g $x > /dev/null; done
> 
> The only single package on my system that took more than 2 seconds total
> time was gcc. The idea that that is too much time to add to emerge -c or
> -C, which in my experience already takes multiple seconds to run anyway is
> kind of silly.

What's even more 'kind of silly' is you claiming things to be kind of
silly based on wrong understand of what needs to be done and benchmarks
that are done using completely different tooling.

-- 
Best regards,
Michał Górny


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

Re: [gentoo-dev] Sets vs Meta ebuilds

[Gordon Pettey]

On Mon, Jul 10, 2017 at 5:24 PM, Michał Górny  wrote:

> On pon, 2017-07-10 at 17:40 -0400, William L. Thomson Jr. wrote:
> > Stop getting lost in the weeds
> > You all are making this about -c vs -C. I am not talking about that!
> >
> > LET ME CLARIFY
> >
> > When using -C, portage SHOULD warn for dependencies like it does for
> > profile and set packages, PERIOD. NOTHING to do with -c vs -C.
> >
> > When using -c the output should say in layman's terms,
> > "Not removing package A because it is a dependency"
>
> William, I'm not sure if you're aware of how package managers work but
> checking reverse dependencies of a package takes significant amount of
> time.


for x in $(eix -I --only-names); do time equery g $x > /dev/null; done

The only single package on my system that took more than 2 seconds total
time was gcc. The idea that that is too much time to add to emerge -c or
-C, which in my experience already takes multiple seconds to run anyway is
kind of silly.

Re: [gentoo-dev] Sets vs Meta ebuilds

[Michał Górny]

On pon, 2017-07-10 at 17:40 -0400, William L. Thomson Jr. wrote:
> Stop getting lost in the weeds
> You all are making this about -c vs -C. I am not talking about that!
> 
> LET ME CLARIFY
> 
> When using -C, portage SHOULD warn for dependencies like it does for
> profile and set packages, PERIOD. NOTHING to do with -c vs -C.
> 
> When using -c the output should say in layman's terms,
> "Not removing package A because it is a dependency" 
> 
> Again nothing to do with -c vs -C. So PLEASE stop with that!
> 
> Two things very straightforward and simple. No clue why others keep
> making this about a use -c vs -C. That does NOT change the lack of
> warnings or information I am speaking about for BOTH!
> 
> Amazing how things can be off tracked and miss the entire point. I do
> not care if you use -c or -C. BOTH lack the same warnings and
> information. That is what I am talking about.

William, I'm not sure if you're aware of how package managers work but
checking reverse dependencies of a package takes significant amount of
time. Changing -C to do that would be a serious performance regression.
Which would result in users requesting yet another option to disable
this.

I should also point out that these are Portage implementation specifics
that do not belong on this mailing list. The issues with Portage are
reported on bugs.gentoo.org, in the 'Portage Development' product. If
you have any problems with using Portage, please use the gentoo-user
mailing list or any other user-oriented media.

-- 
Best regards,
Michał Górny


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

Re: [gentoo-portage-dev] Leader election

[Manuel Rüger]

Voting for Zac as well

Am 9. Juli 2017 23:33:07 MESZ schrieb "Michał Górny" :
>On wto, 2017-07-04 at 13:02 -0700, Zac Medico wrote:
>> On 07/02/2017 12:02 PM, Brian Dolbec wrote:
>> > On Sun, 2 Jul 2017 11:28:09 -0700
>> > Brian Dolbec  wrote:
>> > 
>> > > On Sat, 24 Jun 2017 20:20:16 -0700
>> > > Brian Dolbec  wrote:
>> > > > On Sun, 18 Jun 2017 15:48:44 +0200
>> > > > Alexander Berntsen  wrote:
>> > > >   
>> > > > > Friends,
>> > > > > 
>> > > > > It's that time of year. We're having a leader election again,
>as
>> > > > > well as a general development meeting. The agenda will be
>updated
>> > > > > in more detail at:
>> > > > > https://wiki.gentoo.org/wiki/Project:Portage/Meetings
>> > > > > 
>> > > > > Please schedule a time at: http://whenisgood.net/portage
>> > > > > 
>> > > > > Thanks.
>> > > > > - -- 
>> > > > > Alexander
>> > > > > berna...@gentoo.org
>> > > > > https://secure.plaimi.net/~alexander
>> > > > >
>> > > > 
>> > > > I've picked Sunday, July 2 at 4:00 PM UTC
>> > > >   
>> > > We've decided (the members in attendance), to do the lead
>election via
>> > > email.
>> > > So, nominations are open from now to July 5, 2017.
>> > > Voting will be closed July 10, 2017, results posted here again.
>> > > - -- 
>> > > Brian Dolbec 
>> > 
>> > 
>> > I nominate Zac 
>> 
>> Thank you, I accept.
>> 
>> I also nominate Brian Dolbec and Alexander Berntsen.
>
>My vote goes for Zac as well.
>-- 
>Best regards,
>Michał Górny

Re: [gentoo-dev] Sets vs Meta ebuilds

[Ben Kohler]

On Mon, Jul 10, 2017 at 4:42 PM, William L. Thomson Jr. 
wrote:

>
> If people understood, then saying use -c or -C makes no sense. It does
> not address the lack of output from either I am talking about.
>
> --
> William L. Thomson Jr.
>
I really thought I understood you in that you wanted true reverse
dependencies calculated, to check against that, and warn for it.  I think
that you are actually talking about a warning upon forced unmerge of
anything not in /var/lib/portage/world, is that correct?

-Ben

Re: [gentoo-dev] Sets vs Meta ebuilds

[William L. Thomson Jr.]

On Mon, 10 Jul 2017 16:30:07 -0400
Rich Freeman  wrote:

> On Mon, Jul 10, 2017 at 4:27 PM, William L. Thomson Jr.
>  wrote:
> > On Mon, 10 Jul 2017 15:55:47 -0400
> > Rich Freeman  wrote:
> >  
> >>
> >> The --unmerge option is there to let people shoot themselves in the
> >> feet if they know what they're doing.  
> >
> > Not sure why anyone would have objection to such a warning like
> > exists for other things.  
> 
> I don't think I've seen anybody raise such an objection.

Then why are we talking -c vs -C, when BOTH need more output...
If there is no objection, why all the emails on -c vs -C?

Neither using -c nor -C addresses the issues I am mentioning with
either. Yet people keep on about those two things and missing the
actual point. Which you say there is no objection. Maybe there is no
understanding rather than objection.

If people understood, then saying use -c or -C makes no sense. It does
not address the lack of output from either I am talking about.

-- 
William L. Thomson Jr.


pgpcg5sIKTB6H.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] Sets vs Meta ebuilds

[William L. Thomson Jr.]

Stop getting lost in the weeds
You all are making this about -c vs -C. I am not talking about that!

LET ME CLARIFY

When using -C, portage SHOULD warn for dependencies like it does for
profile and set packages, PERIOD. NOTHING to do with -c vs -C.

When using -c the output should say in layman's terms,
"Not removing package A because it is a dependency" 

Again nothing to do with -c vs -C. So PLEASE stop with that!

Two things very straightforward and simple. No clue why others keep
making this about a use -c vs -C. That does NOT change the lack of
warnings or information I am speaking about for BOTH!

Amazing how things can be off tracked and miss the entire point. I do
not care if you use -c or -C. BOTH lack the same warnings and
information. That is what I am talking about.

-- 
William L. Thomson Jr.


pgpi_CzwT3CNO.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] Sets vs Meta ebuilds

[Ian Stakenvicius]

On 10/07/17 04:47 PM, William L. Thomson Jr. wrote:
> On Mon, 10 Jul 2017 15:36:11 -0500
> Ben Kohler  wrote:
>>
>> If you want dependencies checked, use the correct option which checks
>> them.  This takes significantly longer than -C, as it's significantly
>> more complex to check for.
>>
>> As far as I can tell, you are literally asking for -C to behave like
>> -c, when you could just be using -c instead.
> 
> No I simply want warnings like that exist for profiles and set packages.
> 
> Also more information when attempting to remove a package that is not
> removed.
> 

OK, well, as Ben said it's not feasible to make -C act like -c due to
the performance hit involved and due to the purpose of the command itself.

It likely is feasible and may well make sense to add a message to the
-c output that states that packages in the provided list aren't
removed because they are dependencies.  You should open up a bug for
that against portage and let the portage dev's sort it out.







signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Sets vs Meta ebuilds

[Rich Freeman]

On Mon, Jul 10, 2017 at 4:47 PM, William L. Thomson Jr.
 wrote:
> On Mon, 10 Jul 2017 15:36:11 -0500
> Ben Kohler  wrote:
>>
>> If you want dependencies checked, use the correct option which checks
>> them.  This takes significantly longer than -C, as it's significantly
>> more complex to check for.
>>
>> As far as I can tell, you are literally asking for -C to behave like
>> -c, when you could just be using -c instead.
>
> No I simply want warnings like that exist for profiles and set packages.
>
> Also more information when attempting to remove a package that is not
> removed.

Well, as was pointed out, doing that comes at a performance cost.
Would it not make sense to have an option to skip dependency checks
for use in scripts/etc where you know it is safe to do so?

-- 
Rich

Re: [gentoo-dev] Sets vs Meta ebuilds

[William L. Thomson Jr.]

On Mon, 10 Jul 2017 15:36:11 -0500
Ben Kohler  wrote:
>
> If you want dependencies checked, use the correct option which checks
> them.  This takes significantly longer than -C, as it's significantly
> more complex to check for.
> 
> As far as I can tell, you are literally asking for -C to behave like
> -c, when you could just be using -c instead.

No I simply want warnings like that exist for profiles and set packages.

Also more information when attempting to remove a package that is not
removed.

-- 
William L. Thomson Jr.


pgpt1MIMOOMfm.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] Sets vs Meta ebuilds

[Ben Kohler]

On Mon, Jul 10, 2017 at 3:27 PM, William L. Thomson Jr. 
wrote:

>
>
> Not sure why anyone would have objection to such a warning like exists
> for other things. Or providing more information to the user as to why a
> package was not removed, or should not be removed.
>
> --
> William L. Thomson Jr.
>
If you want dependencies checked, use the correct option which checks
them.  This takes significantly longer than -C, as it's significantly more
complex to check for.

As far as I can tell, you are literally asking for -C to behave like -c,
when you could just be using -c instead.

-Ben

Re: [gentoo-dev] Sets vs Meta ebuilds

[Rich Freeman]

On Mon, Jul 10, 2017 at 4:27 PM, William L. Thomson Jr.
 wrote:
> On Mon, 10 Jul 2017 15:55:47 -0400
> Rich Freeman  wrote:
>
>>
>> The --unmerge option is there to let people shoot themselves in the
>> feet if they know what they're doing.
>
> Not sure why anyone would have objection to such a warning like exists
> for other things.

I don't think I've seen anybody raise such an objection.

-- 
Rich

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

[Rich Freeman]

On Mon, Jul 10, 2017 at 4:05 PM, M. J. Everitt  wrote:
>
> I dunno where you've been lately, Rich, but for most devs, would-be
> devs, and observers .. there -are- no arch teams left .. just a few Arch
> devs, or arch 'people' ..

Obviously.

I was describing how the arch team process worked when there were arch teams.

The fact that most arch teams are fairly defunct is the reason that
stable keywords have steadily been dropped.

>
> This is why stabilisation, if not for individual package maintainers on
> amd64, has become a joke, save for Ago's efforts, and recent efforts by
> kensington to streamline the effort for the likes of ago with his bot,
> and one or two other arch stabilisers (who I know exist, but not by name
> or nick).

Sure.  If nobody is maintaining stable keywords on an arch, then there
shouldn't be stable keywords on that arch, unless the stable keywords
are used for a different purpose and maintainers are free to downgrade
them at any time.

>
> There is no, and has not been, in the time I've been involved with
> Gentoo, any "pact" or "contract" between arch teams/devs and maintainers
> whatsoever, anything is only ever done as a 'favour' or if someone
> nudges the AT after the appropriate bug has been filed.
>

As a formal documented arrangement, no "pact" or "contract" has ever
existed between arch teams and maintainers.

However, this is basically the implicit basis for the system and the
consequence of our documented policies, such as the policy that
maintainers may not remove the highest stable version of a package.
These policies make no sense unless arch teams are held to a standard
of timely stabilization.

There has never been a need to document such a "contract" because the
Council has been maintaining it all along.  When people complain that
an arch team is unresponsive, the Council removes stable support for
the arch.

I'm describing reality here, not written policies.

-- 
Rich

Re: [gentoo-dev] Sets vs Meta ebuilds

[William L. Thomson Jr.]

On Mon, 10 Jul 2017 15:55:47 -0400
Rich Freeman  wrote:

> On Mon, Jul 10, 2017 at 3:45 PM, William L. Thomson Jr.
>  wrote:
> > On Mon, 10 Jul 2017 14:39:00 -0500
> > Ben Kohler  wrote:  
> >>  
> >> > You aren't taking the time to read your own emerge output.  
> >
> > It always says that same generic message. If that is the case, then
> > why even have that option?  
> 
> The --unmerge option is there to let people shoot themselves in the
> feet if they know what they're doing.

Even then you get a warning for profile and set packages, and not for
dependent packages.

Not sure why anyone would have objection to such a warning like exists
for other things. Or providing more information to the user as to why a
package was not removed, or should not be removed.

-- 
William L. Thomson Jr.


pgpKDGzv060YD.pgp
Description: OpenPGP digital signature

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

[Kristian Fiskerstrand]

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)]

References:
[section 3.2 (Kernel)]
https://download.sumptuouscapital.com/gentoo/wg-stable/main.pdf

-- 
Kristian Fiskerstrand
OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3



signature.asc
Description: OpenPGP digital signature

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

[M. J. Everitt]

On 10/07/17 20:53, Rich Freeman wrote:
> On Mon, Jul 10, 2017 at 3:09 PM, Matt Turner  wrote:
>> For what it's worth, Jack Morgan was recently getting his sparc and
>> ia64 systems back up, but then decided to retire instead when he saw
>> all of the discussions about dropping the architectures he cares
>> about.
>>
> Honestly, I don't really get this sort of thing.  The reason arches
> get dropped is because they mark things stable that they can't keep up
> with.  If an arch never marked a package as stable nobody would be
> bothered.  If they only marked a few critical packages as stable and
> then kept up with them, again nobody would be bothered.  The conflict
> comes in when an arch team marks packages as stable, but then doesn't
> keep up with them.
>
> Marking a package as stable is a two-way commitment.  When an arch
> team marks a package as stable they make a promise to the maintainer
> to stabilize updates in a timely manner.  In return the maintainer
> promises to keep older versions around to suit the needs of the arch
> team for the short time it takes to do these stabilizations.
>
> When an arch team stabilizes something that they don't have time to
> maintain then they're making a promise they can't keep, and the deal
> breaks down.  Eventually the maintainers complain, and the council
> ends up revoking the right of the arch team to hold the maintainers to
> their side of the deal which has already been broken.
>
> There are no bad guys here.  There is just a certain amount of work it
> takes to make a stable arch viable, and it either happens or it
> doesn't.  Most people who use Gentoo are tinkerers by nature.  All
> things being equal we'd love to see every arch supported.  However,
> this requires discipline on the part of the arch team, because
> otherwise an arch that few people use starts impacting work for other
> arches that many more use as maintainers get buried in old bugs.
>
I dunno where you've been lately, Rich, but for most devs, would-be
devs, and observers .. there -are- no arch teams left .. just a few Arch
devs, or arch 'people' ..

This is why stabilisation, if not for individual package maintainers on
amd64, has become a joke, save for Ago's efforts, and recent efforts by
kensington to streamline the effort for the likes of ago with his bot,
and one or two other arch stabilisers (who I know exist, but not by name
or nick).

There is no, and has not been, in the time I've been involved with
Gentoo, any "pact" or "contract" between arch teams/devs and maintainers
whatsoever, anything is only ever done as a 'favour' or if someone
nudges the AT after the appropriate bug has been filed.

Keywording, unless for your own native arch, is a worse joke .. you have
to do it yourself .. there just aren't people with the less common
arches actively seeking packages out to keyword.

So, even for me, Thank You Ago for the packages you've kindly fixed
where I have nudged you, and also maekke on the few arm packages where
you have done the same. Your efforts are noted by some, pity not by others.



signature.asc
Description: OpenPGP digital signature

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

[Rich Freeman]

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.

-- 
Rich

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

[Andrew Savchenko]

Hi,

On Mon, 10 Jul 2017 13:49:40 -0400 Rich Freeman wrote:
> On Mon, Jul 10, 2017 at 1:22 PM, Agostino Sarubbo  wrote:
> >
> > Now, since I work on these arches just to help, i.e. I don't have any 
> > business
> > and I do non have any installation of those arches and the work I'm doing is
> > not appreciated at all I decided to stop for now.
> 
> I wouldn't say that your work is unappreciated.  However, when those
> are called "unmaintained" arches it reflects the fact that very few
> are contributing to them.  The nature of a linux distro is that one
> person could be working 24x7 with bleeding fingers and it would be
> like sticking a finger in a dike.  It takes more than one contributor
> (even a serious one) to make something like this viable.
> 
> > I will take a break also from amd64 and x86...let's see how things will
> > change.
> 
> I'm not sure I really see the connection but you're of course welcome
> to work on whatever you want to.  In the case of amd64 we already
> encourage individual package maintainers to stabilize their own
> packages, and I think this is much more sustainable than having an
> arch team do it.

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.

[1] https://devmanual.gentoo.org/keywording/index.html
[2] https://wiki.gentoo.org/wiki/GLEP:40

Best regards,
Andrew Savchenko


pgpZLjzLZyEkc.pgp
Description: PGP signature

Re: [gentoo-dev] Sets vs Meta ebuilds

[Rich Freeman]

On Mon, Jul 10, 2017 at 3:45 PM, William L. Thomson Jr.
 wrote:
> On Mon, 10 Jul 2017 14:39:00 -0500
> Ben Kohler  wrote:
>>
>> > You aren't taking the time to read your own emerge output.
>
> It always says that same generic message. If that is the case, then why
> even have that option?

The --unmerge option is there to let people shoot themselves in the
feet if they know what they're doing.  Anybody who uses it routinely
is going to get burned by it sooner or later.  It simply is not
intended for day-to-day-use.  I'd be all for renaming it to something
like --unsafe-unmerge and getting rid of the short abbreviation.

--depclean is the option people should be using day-to-day.

There are cases with blocks that portage doesn't handle correctly
where --unmerge is sometimes the simplest way around them.  Fortunate
this is rare these days.

-- 
Rich

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

[Rich Freeman]

On Mon, Jul 10, 2017 at 3:09 PM, Matt Turner  wrote:
>
> For what it's worth, Jack Morgan was recently getting his sparc and
> ia64 systems back up, but then decided to retire instead when he saw
> all of the discussions about dropping the architectures he cares
> about.
>

Honestly, I don't really get this sort of thing.  The reason arches
get dropped is because they mark things stable that they can't keep up
with.  If an arch never marked a package as stable nobody would be
bothered.  If they only marked a few critical packages as stable and
then kept up with them, again nobody would be bothered.  The conflict
comes in when an arch team marks packages as stable, but then doesn't
keep up with them.

Marking a package as stable is a two-way commitment.  When an arch
team marks a package as stable they make a promise to the maintainer
to stabilize updates in a timely manner.  In return the maintainer
promises to keep older versions around to suit the needs of the arch
team for the short time it takes to do these stabilizations.

When an arch team stabilizes something that they don't have time to
maintain then they're making a promise they can't keep, and the deal
breaks down.  Eventually the maintainers complain, and the council
ends up revoking the right of the arch team to hold the maintainers to
their side of the deal which has already been broken.

There are no bad guys here.  There is just a certain amount of work it
takes to make a stable arch viable, and it either happens or it
doesn't.  Most people who use Gentoo are tinkerers by nature.  All
things being equal we'd love to see every arch supported.  However,
this requires discipline on the part of the arch team, because
otherwise an arch that few people use starts impacting work for other
arches that many more use as maintainers get buried in old bugs.

-- 
Rich

Re: [gentoo-dev] Sets vs Meta ebuilds

[William L. Thomson Jr.]

On Mon, 10 Jul 2017 14:48:23 -0500
Ben Kohler  wrote:

> >
> >
> >  - The -c option should say why it will not remove.
> >
> >
> > --
> > William L. Thomson Jr.
> >
> It does, if you use the --verbose flag.  This is mentioned in your
> emerge output a few times.

It just shows the dep chain, not a reason or warning. I am saying it
just needs a warning. A reason why it did not remove. When not using
versbose/-v

Warning like
"Not removing package A as it is a dependency of another package"

This just shows the dep chain, no reason why. Its left to the user to
interpret, since not removed. Its needed by other stuff. But that is
not said explicitly.

# emerge -cav gcc

Calculating dependencies... done!
  sys-devel/gcc-6.3.0 pulled in by:
@system requires sys-devel/gcc
dev-db/mysql-5.6.36 requires >=sys-devel/gcc-3.4.6
media-libs/libmypaint-1.3.0 requires sys-devel/gcc:*[openmp]
media-libs/mesa-17.1.2 requires >=sys-devel/gcc-4.6
net-libs/webkit-gtk-2.4.11-r200 requires >=sys-devel/gcc-4.7
sys-devel/llvm-4.0.0-r2 requires >=sys-devel/gcc-3.0
sys-libs/glibc-2.24-r2 requires >=sys-devel/gcc-4.7

>>> No packages selected for removal by depclean
Packages installed:   1779
Packages in world:194
Packages in system:   257
Required packages:1779
Number removed:   0


This is worse and just needs a message, warning, as to why it was not
removed.

# emerge -pc gcc

Calculating dependencies... done!
>>> No packages selected for removal by depclean
>>> To see reverse dependencies, use --verbose
Packages installed:   1779
Packages in world:194
Packages in system:   257
Required packages:1779
Number to remove: 0


Either way, as I stated, if using -C, you get warnings with profiles
and sets, but not with deps. Deps should have a warning as well.

-- 
William L. Thomson Jr.


pgpLCnqsGksgh.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] Sets vs Meta ebuilds

[Ben Kohler]

>
>
>  - The -c option should say why it will not remove.
>
>
> --
> William L. Thomson Jr.
>
It does, if you use the --verbose flag.  This is mentioned in your emerge
output a few times.

-Ben

Re: [gentoo-dev] Sets vs Meta ebuilds

[William L. Thomson Jr.]

On Mon, 10 Jul 2017 14:39:00 -0500
Ben Kohler  wrote:
>
> > You aren't taking the time to read your own emerge output. 

It always says that same generic message. If that is the case, then why
even have that option? Why not default to that all the time? Why did
someone give that option + warning vs preventing it in the first place?

> Now, both of these recommend --pretend, but you can use --ask with
> it, for a safe unmerge that checks for reverse deps THEN allows you
> to continue only if it's safe.

It does not matter. I am showing you with -C it generates a warning on
profile and set packages. It does not generate any sort of warning for
deps or packages no in world.

It is the warnings that should exist.

> Try "emerge -cav gcc.

That shows what its pulled in. But no message saying it will not remove
because it is a dependency.

Again this is about informing the user. Both ways leave the user
wanting.

 - The -c option should say why it will not remove.
 - The -C option should warn like it does with profile packages

-- 
William L. Thomson Jr.


pgp5TMEgVbvWZ.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] Sets vs Meta ebuilds

[William L. Thomson Jr.]

On Mon, 10 Jul 2017 15:36:16 -0400
"William L. Thomson Jr."  wrote:
>
> !!! 'sys-devel/gcc' is part of your system profile.
> !!! Unmerging it may be damaging to your system.

When un-merging a package from a set, You get a similar warning. I
think this warning should also be generated for any package that is a
dependency. The user did not install that just like they did not
install directly the stuff in system or world. 

-- 
William L. Thomson Jr.


pgpj1ngGoccKq.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] Sets vs Meta ebuilds

[Ben Kohler]

On Mon, Jul 10, 2017 at 2:36 PM, William L. Thomson Jr. 
wrote:

> ...
> Calculating dependencies... done!
> >>> No packages selected for removal by depclean
> >>> To see reverse dependencies, use --verbose
> Packages installed:   1779
> Packages in world:194
> ...
>
# emerge -pC gcc
>  * This action can remove important packages! In order to be safer, use
>  * `emerge -pv --depclean ` to check for reverse dependencies
> before
>  * removing packages.
>
> ...
>
> You aren't taking the time to read your own emerge output.  Now, both of
these recommend --pretend, but you can use --ask with it, for a safe
unmerge that checks for reverse deps THEN allows you to continue only if
it's safe.

Try "emerge -cav gcc.

-Ben

Re: [gentoo-dev] Sets vs Meta ebuilds

[William L. Thomson Jr.]

On Mon, 10 Jul 2017 14:28:29 -0500
Ben Kohler  wrote:
>
>  Use -c rather than -C, like grknight suggested, and it will.

It does not remove, but does not say why either. Which a user may
likely proceed with using -C, as -c had no effect nor did it say why it
took no action.

# emerge -pc tomcat-servlet-api

Calculating dependencies... done!
>>> No packages selected for removal by depclean
>>> To see reverse dependencies, use --verbose
Packages installed:   1779
Packages in world:194
Packages in system:   257
Required packages:1779
Number to remove: 0

Even when using -C, you still get a warning. Which should happen for
deps just like it does system/world packages.

# emerge -pC gcc
 * This action can remove important packages! In order to be safer, use
 * `emerge -pv --depclean ` to check for reverse dependencies
before
 * removing packages.

>>> These are the packages that would be unmerged:


!!! 'sys-devel/gcc' is part of your system profile.
!!! Unmerging it may be damaging to your system.


 sys-devel/gcc
selected: 6.3.0
   protected: none
 omitted: none

All selected packages: =sys-devel/gcc-6.3.0

>>> 'Selected' packages are slated for removal.
>>> 'Protected' and 'omitted' packages will not be removed.



-- 
William L. Thomson Jr.


pgpikSlzOPh3U.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] Sets vs Meta ebuilds

[Ben Kohler]

On Mon, Jul 10, 2017 at 2:25 PM, William L. Thomson Jr. 
wrote:

> On Mon, 10 Jul 2017 15:15:35 -0400
> "William L. Thomson Jr."  wrote:
>
> > # emerge -pC tomcat-servlet-api
> >  * This action can remove important packages! In order to be safer,
> > use
> >  * `emerge -pv --depclean ` to check for reverse dependencies
> >before
> >  * removing packages.
>
> Rather than a message like the above. I think portage should generate a
> message/warning saying you are removing a package that is not in your
> world file. Which means you are removing a package you did not install
> directly. Just like if you were to remove a system package.
>
> That way people would know if they are removing something that is a
> dependency.
>
> --
> William L. Thomson Jr.
>

 Use -c rather than -C, like grknight suggested, and it will.

-Ben

Re: [gentoo-dev] Sets vs Meta ebuilds

[William L. Thomson Jr.]

On Mon, 10 Jul 2017 15:15:35 -0400
"William L. Thomson Jr."  wrote:

> # emerge -pC tomcat-servlet-api
>  * This action can remove important packages! In order to be safer,
> use
>  * `emerge -pv --depclean ` to check for reverse dependencies
>before
>  * removing packages.

Rather than a message like the above. I think portage should generate a
message/warning saying you are removing a package that is not in your
world file. Which means you are removing a package you did not install
directly. Just like if you were to remove a system package.

That way people would know if they are removing something that is a
dependency. 

--
William L. Thomson Jr.


pgpAw4WF9kSZ8.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] Sets vs Meta ebuilds

[William L. Thomson Jr.]

On Mon, 10 Jul 2017 15:07:37 -0400
Brian Evans  wrote:

> On 7/10/2017 2:59 PM, William L. Thomson Jr. wrote:
> > On Mon, 10 Jul 2017 00:43:11 -0400
> > "William L. Thomson Jr."  wrote:
> > I think portage should also warn on removing packages that came in
> > from another. If you are removing any dependency of another package.
> > 
> >   
> 
> Portage will refuse to remove a package if it is a dependency, but you
> have to change the invocation to be 'emerge -avc '.
> 
> Then it will be very verbose if something needs said package.

Nope, go try yourself. Remove any dep of another package that is not a
system package. You will not get any warnings but the generic one. It
does not know these are a dep and should not be removed. It is not
saying anything about that.

 These are brought in by 2 packages I have installed,
dev-java/tomcat-server and java-virtuals/servlet-api

# emerge -pC tomcat-servlet-api
 * This action can remove important packages! In order to be safer, use
 * `emerge -pv --depclean ` to check for reverse dependencies
   before
 * removing packages.

>>> These are the packages that would be unmerged:

 dev-java/tomcat-servlet-api
selected: 6.0.53 7.0.77 9.0.0_alpha22
   protected: none
 omitted: none

All selected packages: =dev-java/tomcat-servlet-api-6.0.53
 =dev-java/tomcat-servlet-api-7.0.77
 =dev-java/tomcat-servlet-api-9.0.0_alpha22

>>> 'Selected' packages are slated for removal.
>>> 'Protected' and 'omitted' packages will not be removed.

Which I just had as a result of doing that previously

!!! ERROR: No provider is available for servlet-api-2.5
   Please check your environment.
!!! ERROR: No provider is available for servlet-api-3.0
   Please check your environment.


-- 
William L. Thomson Jr.


pgpOTZDJEqJTG.pgp
Description: OpenPGP digital signature

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

[Matt Turner]

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

I'm really sorry to hear that, but I agree that the best way to for
people to realize how valuable you are is to take a step back and let
them see the hole left by your absence.

For what it's worth, Jack Morgan was recently getting his sparc and
ia64 systems back up, but then decided to retire instead when he saw
all of the discussions about dropping the architectures he cares
about.

Thank you for all of the work you've done.

Re: [gentoo-dev] Sets vs Meta ebuilds

[Brian Evans]

On 7/10/2017 2:59 PM, William L. Thomson Jr. wrote:
> On Mon, 10 Jul 2017 00:43:11 -0400
> "William L. Thomson Jr."  wrote:
> I think portage should also warn on removing packages that came in from
> another. If you are removing any dependency of another package.
> 
> 

Portage will refuse to remove a package if it is a dependency, but you
have to change the invocation to be 'emerge -avc '.

Then it will be very verbose if something needs said package.

Brian



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Sets vs Meta ebuilds

[William L. Thomson Jr.]

On Mon, 10 Jul 2017 00:43:11 -0400
"William L. Thomson Jr."  wrote:

> On Sun, 9 Jul 2017 21:37:11 -0400
> "Walter Dnes"  wrote:
> >
> >   "Fat-Finger" does happen once in while.  Removing the risk of it
> > happening in the first place is a lot more robust/bulletproof.  
> 
> There is nothing in place to stop you from removing gcc, or other
> system packages. Adding such to a set, removing them, then expecting
> the system to prevent you from doing that. Really does not make sense.
> You are creating the set. You are also ignoring warnings on un-emerge.
> That is several mistakes.
> 
> Either way, removing gcc as part of a set, or directly, or any other
> system package can happen regardless. There is nothing bullet proof.
> Nothing to stop you either way, except the warning.

Speaking of removing packages. If you remove a package that is a dep of
another, say a virtual or meta ebuild. You do not get ANY warnings. You
will just break that virtual or meta ebuild.

IF that same package was in a set. If you remove any package that is
part of a set. You will get a warning. If you add the set to your
system sets. It will say your removing  a package part of a set.

I think portage should also warn on removing packages that came in from
another. If you are removing any dependency of another package.


-- 
William L. Thomson Jr.


pgpjEI0mpc_KR.pgp
Description: OpenPGP digital signature

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

[Mike Pagano]

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


Agostino as far as this maintainer is concerned you are totally wrong.
:) 

Its my bad that you have no idea how much I appreciate you stablizing kernels. 
I submit
stablereqs and almost say out loud "Ago, please do your thing".

It's my bad if I've never thanked you but I *do* depend on you.

Thanks for the time you spend on my "stuff".

Mike



-- 
Mike Pagano
Gentoo Developer - Kernel Project
Gentoo Sources - Member
E-Mail : mpag...@gentoo.org
GnuPG FP   : EEE2 601D 0763 B60F 848C  9E14 3C33 C650 B576 E4E3
Public Key : http://pgp.mit.edu:11371/pks/lookup?search=0xB576E4E3=index

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

[Alexander Berntsen]

On 10/07/17 20:11, Jonas Stein wrote:
> It would be so motivating to see that many user are glad about a
> special package. One gets rarely feedback.

Interesting idea. We could have some (separate) portage-y helper tool
send a standardised email that could easily be filtered based on sender
and/or topic. 'emerge foo --thank' just thanks people, 'emerge foo
--thank="msg"' thanks people with a msg.

It's gimmicky and could be abused. But then again perhaps it wouldn't be
abused, and it would just be wholesome fun. Maybe someone would meet
their future lover via the thank-parametre.

What do you think?
-- 
Alexander
berna...@gentoo.org
https://secure.plaimi.net/~alexander



signature.asc
Description: OpenPGP digital signature

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

[Jonas Stein]

Hi Agostino,

at first I want to thank you for the many contributions.
There should be a "thank you" parameter in emerge for every installed
package.
It would be so motivating to see that many user are glad about a special
package. One gets rarely feedback.

I understand your decision and perhaps it is the best you can do at the
moment. It could motivate others to contribute too.
I am sure, that the discussion about the 'minor' arches status is no
criticism about you.
I am looking forward to see you back after the break.

Best,
Jonas

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

[Rich Freeman]

On Mon, Jul 10, 2017 at 1:22 PM, Agostino Sarubbo  wrote:
>
> Now, since I work on these arches just to help, i.e. I don't have any business
> and I do non have any installation of those arches and the work I'm doing is
> not appreciated at all I decided to stop for now.

I wouldn't say that your work is unappreciated.  However, when those
are called "unmaintained" arches it reflects the fact that very few
are contributing to them.  The nature of a linux distro is that one
person could be working 24x7 with bleeding fingers and it would be
like sticking a finger in a dike.  It takes more than one contributor
(even a serious one) to make something like this viable.

> I will take a break also from amd64 and x86...let's see how things will
> change.

I'm not sure I really see the connection but you're of course welcome
to work on whatever you want to.  In the case of amd64 we already
encourage individual package maintainers to stabilize their own
packages, and I think this is much more sustainable than having an
arch team do it.  Back when amd64 was exotic and a lot of packages
needed patching to work having a focused arch team to handle this made
a lot of sense - they owned the hardware and also were accustomed to
spotting type errors and so on.  These days upstream just works on
amd64 and everybody is using it.

I'm not diminishing your contributions in any way (which have always
been tremendous).  I'm just saying that a model that depends less on
heroics would benefit everybody.

-- 
Rich

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

[Kent Fredric]

On 11 Jul 2017 01:41, Kristian Fiskerstrand  wrote:
>
> On 07/10/2017 03: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/ 
> > 
>
> I might've read things too quickly, we're not talking a repoman check here? 

Not sure repoman is enough here.

But I'm just saying I see a growing number of problems that can only be 
detected by actually building the package, and can't be done with static 
analysis.

And then, some of those that can be addressed with repoman are annoying to 
solve with repoman, as you're tying your release cycle to repomans.

And what if your check needs external tools? Surely repoman would be a terrible 
place to put those dependencies
>
> -- 
> Kristian Fiskerstrand 
> OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net 
> fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 
>

--

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

[Alexis Ballier]

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

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

Thanks for your work. It is appreciated. I respect your decision that
your time might be better spent by not trying to artificially maintain
some arches alive when you're clearly the only one doing the work and
caring about them.

There's an annoying side effect of open source communities that I've
came to witness a lot: When you do your work too well, nobody feels the
need to help by contributing, and you're essentially left alone.


Alexis.

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

[Alexis Ballier]

On Mon, 10 Jul 2017 11:55:30 -0500
William Hubbs  wrote:

> On Mon, Jul 10, 2017 at 01:04:10PM +0200, Pacho Ramos wrote:
> > Hello
> > 
> > Looking to the list of packages still not supporting python 3.5:
> > https://qa-reports.gentoo.org/output/gpyutils/34-to-35.txt
> > 
> > and considering that we should even start testing python 3.6, I
> > think it would be nice if we could make portage to warn when
> > PYTHON_COMPAT value is not updated. It's really frustrating to
> > still see new ebuilds being added with obsolete values for
> > PYTHON_COMPAT and relying on a few people looking to update this.
> > This is also causing huge delays to migrate to newer python
> > versions and I think it's responsibility of the maintainer to
> > ensure his/her package is supported on newer versions or, at least,
> > have a bug and ping upstream for the cases they need further fixing.
> > 
> > Of course, this wouldn't be a fatal check preventing you from
> > committing a package with outdated PYTHON_COMPAT, it would be a
> > warning to remind you to update it as soon as possible.
> > 
> > Any issues on trying to go further into implementing this
> > warning?   
> 
> What about the situation where a package is not compatible with newer
> versions of python so does not need a PYTHON_COMPAT change?
> 
> I don't think you can assume PYTHON_COMPAT is outdated for a package
> just because it doesn't have the latest versions of python
> listed. The only time you can know for sure that it is outdated is if
> it lists a version of python that no longer exists in the tree.

Maybe we should add some - modifier to PYTHON_COMPAT, just like
keywords, indicating it has been tested to *not* work.
PYTHON_COMPAT=( python{2_7,3_4,3_5} -python_3_6 )

[gentoo-dev] taking a break from arches stabilization

[Agostino Sarubbo]

Hi all.

every time that I attach my tmux session to see what happens on irc, I always 
see the same discussion about the 'minor' arches status.
Since I joined gentoo(2011) I worked on all arches except hppa, I put more 
effort in amd64 and less where I saw other people work on it (arm,alpha)
But every time the magic phrase is that those arches are unmaintained.

Now, since I work on these arches just to help, i.e. I don't have any business 
and I do non have any installation of those arches and the work I'm doing is 
not appreciated at all I decided to stop for now.
If your dream is to put sparc and ia64 to ~arch, go ahead, I have no 
objections.
I will take a break also from amd64 and x86...let's see how things will 
change.

-- 
Agostino Sarubbo
Gentoo Linux Developer

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

[William Hubbs]

On Mon, Jul 10, 2017 at 01:04:10PM +0200, Pacho Ramos wrote:
> Hello
> 
> Looking to the list of packages still not supporting python 3.5:
> https://qa-reports.gentoo.org/output/gpyutils/34-to-35.txt
> 
> and considering that we should even start testing python 3.6, I think it would
> be nice if we could make portage to warn when PYTHON_COMPAT value is not
> updated. It's really frustrating to still see new ebuilds being added with
> obsolete values for PYTHON_COMPAT and relying on a few people looking to 
> update
> this. This is also causing huge delays to migrate to newer python versions 
> and I
> think it's responsibility of the maintainer to ensure his/her package is
> supported on newer versions or, at least, have a bug and ping upstream for the
> cases they need further fixing.
> 
> Of course, this wouldn't be a fatal check preventing you from committing a
> package with outdated PYTHON_COMPAT, it would be a warning to remind you to
> update it as soon as possible.
> 
> Any issues on trying to go further into implementing this warning? 

What about the situation where a package is not compatible with newer
versions of python so does not need a PYTHON_COMPAT change?

I don't think you can assume PYTHON_COMPAT is outdated for a package
just because it doesn't have the latest versions of python
listed. The only time you can know for sure that it is outdated is if it
lists a version of python that no longer exists in the tree.

William



signature.asc
Description: Digital signature

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

[M. J. Everitt]

On 10/07/17 12:43, Pacho Ramos wrote:
> El lun, 10-07-2017 a las 13:12 +0200, Kristian Fiskerstrand escribió:
>> On 07/10/2017 01:04 PM, Pacho Ramos wrote:
>>> Any issues on trying to go further into implementing this warning? 
>> Not an issue per se, but it should be pointed out that python 3.5 only
>> has a testing visibility, so this at the very least requires maintainers
>> to potentially have a separate testing chroot/VM to test when adding the
>> compat.
>>
> 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.
>
Is this something that could be aided any by the tinderbox'ing project?




signature.asc
Description: OpenPGP digital signature

[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.

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

[Rich Freeman]

On Mon, Jul 10, 2017 at 7:04 AM, Pacho Ramos  wrote:
>
> Looking to the list of packages still not supporting python 3.5:
> https://qa-reports.gentoo.org/output/gpyutils/34-to-35.txt
>

I realize a warning will address most of the issue, but when creating
lists like these it can be helpful to stick the maintainer names on
it, so that maintainers can just search for their name on the wall of
shame.  :)

>
> Any issues on trying to go further into implementing this warning?
>

I think warnings in repoman are a great idea.  If somebody maintains a
package that uses python but isn't seriously into python otherwise
they probably won't notice when new versions are available to be
tested/etc.  The only thing I would suggest is that the warning not be
triggered until the python team thinks the new version is ready for
testing/etc.  I'm not sure if they introduce masked versions into the
tree before things settle down or not.  If not then this is moot.

-- 
Rich

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

[Kristian Fiskerstrand]

On 07/10/2017 03: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/
> 

I might've read things too quickly, we're not talking a repoman check here?

-- 
Kristian Fiskerstrand
OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3



signature.asc
Description: OpenPGP digital signature

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

[Kent Fredric]

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.


pgpjIUlgPDDQ6.pgp
Description: OpenPGP digital signature

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

[Kent Fredric]

On Mon, 10 Jul 2017 10:41:11 +0200
"Paweł Hajdan, Jr."  wrote:

> Feedback about next steps would be welcome.
> 
> Paweł

I'd say hold of on anything Perlish unless strictly necessary. Trying
to keep the stable requests down to only what is *needed* for now
prioritizing for a future where Perl 5.26 can be stabilized.

Once we've got that target set whittled down, we might have time to
consider all the extra work associated with stabilizing the other stuff.


pgp2Ib5xYlWNx.pgp
Description: OpenPGP digital signature

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

[Pacho Ramos]

El lun, 10-07-2017 a las 13:12 +0200, Kristian Fiskerstrand escribió:
> On 07/10/2017 01:04 PM, Pacho Ramos wrote:
> > Any issues on trying to go further into implementing this warning? 
> 
> Not an issue per se, but it should be pointed out that python 3.5 only
> has a testing visibility, so this at the very least requires maintainers
> to potentially have a separate testing chroot/VM to test when adding the
> compat.
> 

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.

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

[Kristian Fiskerstrand]

On 07/10/2017 01:04 PM, Pacho Ramos wrote:
> Any issues on trying to go further into implementing this warning? 

Not an issue per se, but it should be pointed out that python 3.5 only
has a testing visibility, so this at the very least requires maintainers
to potentially have a separate testing chroot/VM to test when adding the
compat.

-- 
Kristian Fiskerstrand
OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3



signature.asc
Description: OpenPGP digital signature

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

[Pacho Ramos]

Hello

Looking to the list of packages still not supporting python 3.5:
https://qa-reports.gentoo.org/output/gpyutils/34-to-35.txt

and considering that we should even start testing python 3.6, I think it would
be nice if we could make portage to warn when PYTHON_COMPAT value is not
updated. It's really frustrating to still see new ebuilds being added with
obsolete values for PYTHON_COMPAT and relying on a few people looking to update
this. This is also causing huge delays to migrate to newer python versions and I
think it's responsibility of the maintainer to ensure his/her package is
supported on newer versions or, at least, have a bug and ping upstream for the
cases they need further fixing.

Of course, this wouldn't be a fatal check preventing you from committing a
package with outdated PYTHON_COMPAT, it would be a warning to remind you to
update it as soon as possible.

Any issues on trying to go further into implementing this warning? 

Thanks a lot

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

[M. J. Everitt]

On 10/07/17 09:41, 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ł
>
Looks great!

It would fit in well with the new stabilisation bot for pre-checking,
and the -grumpy project for a 'developer dashboard'.

Have you come across the -stable working group that was set up recently?

Best regards,
Michael.


signature.asc
Description: OpenPGP digital signature

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

[Michał Górny]

Dnia 10 lipca 2017 10:41:11 CEST, "Paweł Hajdan, Jr."  
napisał(a):
>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.

I might be looking wrong but it looks like lzip and lziprecover are listed 
twice.

>
>Paweł


-- 
Best regards,
Michał Górny (by phone)

[gentoo-dev] stabilization candidates, July 2017

[Paweł Hajdan , Jr .]

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ł



signature.asc
Description: OpenPGP digital signature