Re: [gentoo-dev] glibc 2.23 and willfully breaking stuff

[Mike Frysinger]

On 19 Apr 2016 04:21, Mart Raudsepp wrote:
> Ühel kenal päeval, E, 18.04.2016 kell 12:38, kirjutas Mike Frysinger:
> > On 16 Apr 2016 09:23, Patrick Lauer wrote:
> > > So why on earth are we applying a random patch that upstream is not
> > > using
> > 
> > not everyone uses glibc, and glibc *is* moving in this
> > direction.  Gentoo
> > is simply accelerating the change ... otherwise glibc will take
> > longer to do the actual migration.
> 
> You don't need to break everyone's ~arch for dubious glibc benefits,
> which could be done by a p.masked version and a tinderbox run.
> I am not your tinderbox dummy having to waste time on this to maintain
> my own ~arch stuff.

i waited until the known bugs died down.  i don't have access to a
tinderbox system myself.

> > packages failing to build under glibc already
> > fail to build in other environments.
> 
> That is simply not true

except for the part where it is.  highlighting one system where it's
working for you doesn't mean all systems behave that way.  there's even
an autoconf macro specifically to deal with this and has been for years.
they wouldn't have written & deployed it for fun.

> at least not to the extent you make it sound.

not today, but as i said, we want to move multiple libraries (at least
glibc, uClibc, musl, and bionic) in that direction.  the current behavior
violates the POSIX standard.

> Why are all the concerns raised at e.g
> https://bugs.freedesktop.org/show_bug.cgi?id=94231 not resolved then?

what exactly are you expecting here ?  i'm not an X.org dev.  i can't
fix code in that project for them.  all the questions posed have been
answered in the bug.  it's merely waiting for them to actually commit
code.

> Over there you even told you won't be including this patch in Gentoo,
> but get it trickled in from upstream once they judge it as good to go.

no idea where you're getting reading this.  i never said that.

> Instead you go ahead and unmask this without removing the gentoo
> specific sysmacros header removal, knowing FULLY WELL that you break
> ~arch for a lot of things

again, no.  read what i actually said, and read the actual bug open on
the topic.  most of the packages i was aware of were fixed, and there
were only like 2 or 3 left assigned to projects/devs who are not me.
once things moved into ~arch, we started getting more bug reports, not
before.

> Even todays git of man-pages tells that including sys/types.h is
> sufficient and the correct thing to do to get makedev/major/minor.

and we've already been discussing fixing that.
-mike


signature.asc
Description: Digital signature

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: dev-qt/qtmultimedia/

[M. J. Everitt]

On 18/04/16 16:47, Michał Górny wrote:
> This is invalid. Replacing invalid package names with other invalid
> names is no fix. It is ugly Gentoo-style hackery which proves that
> developers prefer trying randomly changing something until QA check
> doesn't trigger over reading the documentation. As a result, now
> a number packages with visible QA issues have been turned into a number
> of packages with QA issues that aren't caught by the schema due to
> regexp limitations.
>
> Please go over all the packages you've touched and fix the silent
> issues you introduced. I can't afford to waste more time writing more
> complex QA checks that are going to cover all the ways Gentoo
> developers can screw up such a simple thing as package *name*.
>
I can't help but want to write .. "If you want a job doing ... "

+1 monp.





signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] glibc 2.23 and willfully breaking stuff

[Mart Raudsepp]

Ühel kenal päeval, E, 18.04.2016 kell 12:38, kirjutas Mike Frysinger:
> On 16 Apr 2016 09:23, Patrick Lauer wrote:
> > So why on earth are we applying a random patch that upstream is not
> > using
> 
> not everyone uses glibc, and glibc *is* moving in this
> direction.  Gentoo
> is simply accelerating the change ... otherwise glibc will take
> longer to
> do the actual migration.

You don't need to break everyone's ~arch for dubious glibc benefits,
which could be done by a p.masked version and a tinderbox run.
I am not your tinderbox dummy having to waste time on this to maintain
my own ~arch stuff.

> packages failing to build under glibc already
> fail to build in other environments.

That is simply not true, at least not to the extent you make it sound.
We have FreeBSD prefix ourselves seemingly building just fine, X.org
stuff build everywhere UNTIL you apply this currently gentoo specific
patch, etc.

> > *and* unleashing it on ~arch without any of the usual precautions
> > like masking the package until some of the issues have been smoked
> > out?
> 
> it was masked for a while, some bugs were fixed, but no new ones were
> really being found.  so in the absence of data showing a problem,
> unmasking is normal.
> -mike

Why are all the concerns raised at e.g
https://bugs.freedesktop.org/show_bug.cgi?id=94231 not resolved then?
Over there you even told you won't be including this patch in Gentoo,
but get it trickled in from upstream once they judge it as good to go.

Instead you go ahead and unmask this without removing the gentoo
specific sysmacros header removal, knowing FULLY WELL that you break
~arch for a lot of things (just even based on that libdrm bug, merely
breaking every single ~arch gentoo GUI installation in existence), as
any simple test would show you, or a tinderbox run would blow up
immediately. This is glibc ~arch here, not some little independent tool
or not widely used library where ~arch breakage is acceptable.

If you wanted to flush out packages breaking, you could simply locally
compiled stuff and immediately see a ton of stuff, asked someone to do
a tinderbox run, or whatever. Yet it doesn't help much, because
upstreams can be resisting to changing anything, because the
documentation in man-pages tells them they are doing everything
correctly already.
Even todays git of man-pages tells that including sys/types.h is
sufficient and the correct thing to do to get makedev/major/minor. You
are breaking this with a Gentoo specific patch, this is really a NO-NO.

I really appreciate your system packages gruntwork, but please please
start to consider with others and be a little bit more conservative
about such stuff for ~arch, especially when it's Gentoo specific.


A heavily disgruntled Gentoo ~arch maintainer unable to do his job due to 
others adding breakages he shouldn't care about,
Mart Raudsepp

[gentoo-dev] Re: Migrate to Phabricator

[Michael Palimaka]

On 18/04/16 21:44, Jonas Jelten wrote:
> Ohai!
> 
> Phabricator is a fun adventure game: http://phabricator.org/
> 
> It provides a tightly coupled set of project management tools.
> https://phacility.com/phabricator/
> 
> Many bigger projects (e.g. blender, mediawiki, ...) started using
> phabricator, it could also be very beneficial for gentoo.
> 
> https://secure.phabricator.com/w/usage/companies/
> https://secure.phabricator.com/w/usage/not/
> 
> Wikimedia elaborates about the migration:
> 
> https://blogs.gnome.org/aklapper/2014/12/17/welcome-phabricator/
> https://www.mediawiki.org/wiki/Phabricator/versus_Bugzilla
> 
> https://wiki.blender.org/index.php/Dev:Doc/Tools/Phabricator/Migration
> 
> Migrating would contradict the apparent goal of integrating github more
> tightly, but still we could consider to use Phabricator instead,
> especially to dump bugzilla.
> 
> If we come to the conclusion we are a really serious business, we must
> set up the "Serious Business Edition", for the most serious businesses.
> 
> Still, I hope we can go with the Awesome Edition :P
> 
> Cheers,
> JJ
> 

I have previously setup an instance of Phabricator (and prior to that,
Review Board), but sadly there was absolutely zero interest in both.

Re: [gentoo-portage-dev] [PATCH] Colorize packages in user sets (bug 577720)

[Zac Medico]

On 04/18/2016 01:14 PM, Adam Mills wrote:
> Thanks for all the feedback so far. I probably should have just filed
> the bug
> and left it at that, but I'm committed now.
> 
> I've done my best to incorporate all of the suggestions here, and
> submitted a
> new patch rev 3. I have a few questions about details I'm pretty sure still
> need improvement:
> 
> 1) In order to build the InternalPackageSet only once, I used the
>   _DisplayConfig target_root, instead of using pkg.root in the check_sets
>   method. I'm not sure of the pkg.root purpose, but if there can be
> different
>   roots, the InternalPackageSet would have to be created for each package.
>   If that's the case, it could be moved to the check_sets method, and
> created
>   for each package.

You should create the InternalPackageSet for each root, since each root
has its own package sets.

> 2) I added the new InternalPackageSet as a new member of the _DisplayConfig
>   class. Let me know if there's somewhere more appropriate, especially
> after
>   the feedback from #1.

I guess that's fine, since we're not using it anywhere else.

> 3) Is there a better method available for merging PackageSets?

Yes, you should add all of the atoms to it at once, because each update
calls _updateAtomMap which is expensive. For example, use something like
this:

user_sets =
InternalPackageSet(initial_atoms=itertools.chain.from_iterable(pkgset.getAtoms()
for pkgset in pkgsets if pkgset.user_set))
-- 
Thanks,
Zac

Re: [gentoo-portage-dev] [PATCH] Colorize packages in user sets (bug 577720)

[Adam Mills]

Thanks for all the feedback so far. I probably should have just filed 
the bug

and left it at that, but I'm committed now.

I've done my best to incorporate all of the suggestions here, and 
submitted a
new patch rev 3. I have a few questions about details I'm pretty sure 
still

need improvement:

1) In order to build the InternalPackageSet only once, I used the
  _DisplayConfig target_root, instead of using pkg.root in the 
check_sets
  method. I'm not sure of the pkg.root purpose, but if there can be 
different
  roots, the InternalPackageSet would have to be created for each 
package.
  If that's the case, it could be moved to the check_sets method, and 
created

  for each package.

2) I added the new InternalPackageSet as a new member of the 
_DisplayConfig
  class. Let me know if there's somewhere more appropriate, especially 
after

  the feedback from #1.

3) Is there a better method available for merging PackageSets?

Thanks,
Adam

[gentoo-portage-dev] [PATCH v3] Colorize packages in user sets (bug 577720)

[Adam Mills]

Three new settings were added to /etc/portage/color.map:
PKG_MERGE_USER_SET, PKG_BINARY_MERGE_USER_SET, and
PKG_NOMERGE_USER_SET. These colors are applied when the package is
selected from a set in /etc/portage/sets/

X-Gentoo-bug: 577720
X-Gentoo-bug-url: https://bugs.gentoo.org/show_bug.cgi?id=577720
---
[PATCH v3] Updates based on feedback from IRC meeting
[PATCH v2] Simplification of check_sets ref Alexander Berntsen's feedback

 cnf/sets/portage.conf  |  1 +
 doc/config/sets.docbook|  4 +++-
 man/color.map.5| 11 ++
 man/portage.5  |  1 +
 pym/_emerge/resolver/output.py | 25 +++---
 pym/_emerge/resolver/output_helpers.py | 15 ++---
 pym/portage/_sets/__init__.py  |  8 +++
 pym/portage/_sets/base.py  |  1 +
 pym/portage/output.py  | 39 ++
 9 files changed, 75 insertions(+), 30 deletions(-)

diff --git a/cnf/sets/portage.conf b/cnf/sets/portage.conf
index ac282d9..e990620 100644
--- a/cnf/sets/portage.conf
+++ b/cnf/sets/portage.conf
@@ -49,6 +49,7 @@ class = portage.sets.files.StaticFileSet
 multiset = true
 directory =  %(PORTAGE_CONFIGROOT)setc/portage/sets
 world-candidate = True
+user-set = True
 
 # Set to rebuild all packages that need a preserved lib that only remains due
 # to FEATURES=preserve-libs
diff --git a/doc/config/sets.docbook b/doc/config/sets.docbook
index 749b775..02135d6 100644
--- a/doc/config/sets.docbook
+++ b/doc/config/sets.docbook
@@ -57,6 +57,8 @@
is missing)
world-candidate, 
which determines if
given package should be added to the 
world set
+   user-set, which 
determines if
+   given package should be colorized as a user 
set


Some handler classes might require additional options 
for their configuration,
@@ -93,7 +95,7 @@
but to indicate that the section should generate 
multiple sets it's
also necessary to set the multiset 
option to 
true. The 
world-candidate
-   option also supported like with 
+   and user-set options are also 
supported like with
single sets (they'll apply to all sets generated by the 
section).


diff --git a/man/color.map.5 b/man/color.map.5
index 5543628..39f23f7 100644
--- a/man/color.map.5
+++ b/man/color.map.5
@@ -46,6 +46,9 @@ Defines color used for satisfied blockers.
 \fBPKG_MERGE\fR = \fI"darkgreen"\fR
 Defines color used for packages planned to be merged.
 .TP
+\fBPKG_MERGE_USER_SET\fR = \fI"darkgreen"\fR
+Defines color used for packages planned to be merged from a user defined set.
+.TP
 \fBPKG_MERGE_SYSTEM\fR = \fI"darkgreen"\fR
 Defines color used for system packages planned to be merged.
 .TP
@@ -55,6 +58,10 @@ Defines color used for world packages planned to be merged.
 \fBPKG_BINARY_MERGE\fR = \fI"purple"\fR
 Defines color used for packages planned to be merged using a binary package.
 .TP
+\fBPKG_BINARY_MERGE_USER_SET\fR = \fI"purple"\fR
+Defines color used for packages planned to be merged using a binary package
+from a user defined set.
+.TP
 \fBPKG_BINARY_MERGE_SYSTEM\fR = \fI"purple"\fR
 Defines color used for system packages planned to be merged using a binary
 package.
@@ -66,6 +73,10 @@ package.
 \fBPKG_NOMERGE\fR = \fI"darkblue"\fR
 Defines color used for packages not planned to be merged.
 .TP
+\fBPKG_NOMERGE_USER_SET\fR = \fI"darkblue"\fR
+Defines color used for packages not planned to be merged from a user defined
+set.
+.TP
 \fBPKG_NOMERGE_SYSTEM\fR = \fI"darkblue"\fR
 Defines color used for system packages not planned to be merged.
 .TP
diff --git a/man/portage.5 b/man/portage.5
index 7c2a8f7..3cc1f07 100644
--- a/man/portage.5
+++ b/man/portage.5
@@ -1114,6 +1114,7 @@ class = portage.sets.files.StaticFileSet
 multiset = true
 directory =  %(PORTAGE_CONFIGROOT)setc/portage/sets
 world-candidate = True
+user-set = True
 
 [module-rebuild]
 class = portage.sets.dbapi.OwnerSet
diff --git a/pym/_emerge/resolver/output.py b/pym/_emerge/resolver/output.py
index 400617d..89670d3 100644
--- a/pym/_emerge/resolver/output.py
+++ b/pym/_emerge/resolver/output.py
@@ -271,6 +271,8 @@ class Display(object):
return 
colorize("PKG_BINARY_MERGE_SYSTEM", pkg_str)
elif pkg_info.world:
return 
colorize("PKG_BINARY_MERGE_WORLD", pkg_str)
+   elif pkg_info.user_set:
+   return 
colorize("PKG_BINARY_MERGE_USER_SET", pkg_str)
else:
return 

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: dev-db/mysql/

[Michał Górny]

On Mon, 18 Apr 2016 13:45:31 -0400
Brian Evans  wrote:

> On 4/18/2016 1:38 PM, Michał Górny wrote:
> > On Mon, 18 Apr 2016 13:31:08 -0400
> > Brian Evans  wrote:
> >   
> >> The point of this entry is to assign bugs when a certain condition
> >> exists.  The person/project is not responsible otherwise.  
> > 
> > It's GLEP 68. restrict="" must be EAPI 0 which means no USE
> > dependencies.
> >   
> 
> This defeats the purpose of how a number packages were using this
> field.. so we go backwards in time and remove all such maintainers.
> 
> Sounds like a wonderfully thought out plan.

Is it my fault that people do random things without reading the docs?
You are free to improve stuff. My concern was documenting the status
quo. You had time to state your concerns.

Feel free to follow the proper procedure for enhancements. Please don't
forget to cover how machine readers are supposed to use the USE
dependency on bug reports.

-- 
Best regards,
Michał Górny



pgpCjkODfbt0s.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: dev-db/mysql/

[Brian Evans]

On 4/18/2016 1:38 PM, Michał Górny wrote:
> On Mon, 18 Apr 2016 13:31:08 -0400
> Brian Evans  wrote:
> 
>> The point of this entry is to assign bugs when a certain condition
>> exists.  The person/project is not responsible otherwise.
> 
> It's GLEP 68. restrict="" must be EAPI 0 which means no USE
> dependencies.
> 

This defeats the purpose of how a number packages were using this
field.. so we go backwards in time and remove all such maintainers.

Sounds like a wonderfully thought out plan.

Brian



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: dev-db/mysql/

[Michał Górny]

On Mon, 18 Apr 2016 13:31:08 -0400
Brian Evans  wrote:

> On 4/18/2016 11:34 AM, Michał Górny wrote:
> > On Mon, 18 Apr 2016 08:13:33 + (UTC)
> > "Patrice Clement"  wrote:
> >   
> >> commit: 912a9f1e2ed5717a7669861b4978dfaf868c5ae7
> >> Author: Patrice Clement  gentoo  org>
> >> AuthorDate: Mon Apr 18 06:33:40 2016 +
> >> Commit: Patrice Clement  gentoo  org>
> >> CommitDate: Mon Apr 18 07:57:59 2016 +
> >> URL:https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=912a9f1e
> >>
> >> dev-db/mysql: Fix metadata.xml file.
> >>
> >> Package-Manager: portage-2.2.26
> >>
> >>  dev-db/mysql/metadata.xml | 4 ++--
> >>  1 file changed, 2 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/dev-db/mysql/metadata.xml b/dev-db/mysql/metadata.xml
> >> index 422ac80..538f21e 100644
> >> --- a/dev-db/mysql/metadata.xml
> >> +++ b/dev-db/mysql/metadata.xml
> >> @@ -1,11 +1,11 @@
> >>  
> >>  http://www.gentoo.org/dtd/metadata.dtd;>
> >>  
> >> -  
> 
> Why was the restrict removed?
> 
> GLEP 67 does not remove the restrictions either:
> 
> "The package metadata description is fully self-sufficient for bug
> assignment. The order in which  elements occur (after
> applying restrictions) indicates the chain of responsibility. A bug is
> assigned to the first maintainer, while all the remaining maintainers
> are CC-ed."
> 
> The point of this entry is to assign bugs when a certain condition
> exists.  The person/project is not responsible otherwise.

It's GLEP 68. restrict="" must be EAPI 0 which means no USE
dependencies.

-- 
Best regards,
Michał Górny



pgpZxmeMohvJu.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: dev-db/mysql/

[Brian Evans]

On 4/18/2016 11:34 AM, Michał Górny wrote:
> On Mon, 18 Apr 2016 08:13:33 + (UTC)
> "Patrice Clement"  wrote:
> 
>> commit: 912a9f1e2ed5717a7669861b4978dfaf868c5ae7
>> Author: Patrice Clement  gentoo  org>
>> AuthorDate: Mon Apr 18 06:33:40 2016 +
>> Commit: Patrice Clement  gentoo  org>
>> CommitDate: Mon Apr 18 07:57:59 2016 +
>> URL:https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=912a9f1e
>>
>> dev-db/mysql: Fix metadata.xml file.
>>
>> Package-Manager: portage-2.2.26
>>
>>  dev-db/mysql/metadata.xml | 4 ++--
>>  1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/dev-db/mysql/metadata.xml b/dev-db/mysql/metadata.xml
>> index 422ac80..538f21e 100644
>> --- a/dev-db/mysql/metadata.xml
>> +++ b/dev-db/mysql/metadata.xml
>> @@ -1,11 +1,11 @@
>>  
>>  http://www.gentoo.org/dtd/metadata.dtd;>
>>  
>> -

Why was the restrict removed?

GLEP 67 does not remove the restrictions either:

"The package metadata description is fully self-sufficient for bug
assignment. The order in which  elements occur (after
applying restrictions) indicates the chain of responsibility. A bug is
assigned to the first maintainer, while all the remaining maintainers
are CC-ed."

The point of this entry is to assign bugs when a certain condition
exists.  The person/project is not responsible otherwise.

Brian



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] glibc 2.23 and willfully breaking stuff

[Mike Frysinger]

On 16 Apr 2016 09:23, Patrick Lauer wrote:
> So why on earth are we applying a random patch that upstream is not
> using

not everyone uses glibc, and glibc *is* moving in this direction.  Gentoo
is simply accelerating the change ... otherwise glibc will take longer to
do the actual migration.  packages failing to build under glibc already
fail to build in other environments.

> *and* unleashing it on ~arch without any of the usual precautions
> like masking the package until some of the issues have been smoked out?

it was masked for a while, some bugs were fixed, but no new ones were
really being found.  so in the absence of data showing a problem,
unmasking is normal.
-mike


signature.asc
Description: Digital signature

Re: [gentoo-dev] Migrate to Phabricator

[Michał Górny]

On Mon, 18 Apr 2016 13:44:00 +0200
Jonas Jelten  wrote:

> Phabricator is a fun adventure game: http://phabricator.org/
> 
> It provides a tightly coupled set of project management tools.
> https://phacility.com/phabricator/
> 
> Many bigger projects (e.g. blender, mediawiki, ...) started using
> phabricator, it could also be very beneficial for gentoo.
> 
> https://secure.phabricator.com/w/usage/companies/
> https://secure.phabricator.com/w/usage/not/
> 
> Wikimedia elaborates about the migration:
> 
> https://blogs.gnome.org/aklapper/2014/12/17/welcome-phabricator/
> https://www.mediawiki.org/wiki/Phabricator/versus_Bugzilla
> 
> https://wiki.blender.org/index.php/Dev:Doc/Tools/Phabricator/Migration
> 
> Migrating would contradict the apparent goal of integrating github more
> tightly, but still we could consider to use Phabricator instead,
> especially to dump bugzilla.
> 
> If we come to the conclusion we are a really serious business, we must
> set up the "Serious Business Edition", for the most serious businesses.
> 
> Still, I hope we can go with the Awesome Edition :P

This has been suggested already, and if I recall correctly, someone
even set up an instance for testing. Others have already explained to
you most of the 'big' problems with phabricator which make it pretty
much a useless pseudo-enterprise toy.

And before this diverts into discussion about another toy: I'd like
appreciate if we really considered tools that can be better, not worse.
I can agree that our Bugzilla is quite slow for some reason. Still, it
is reasonably fast.

Most of the tools suggested so far are either terribly slow by
themselves (poor design), terribly buggy (error conditions don't happen
after all, do they?), can't handle big git repositories such as our
(become terribly slow) and/or are completely unmaintainable.

Now, if you can find a good tool that is feature-par with Bugzilla, is
fast even under load (no, PHP is not), can handle errors gracefully, is
accessible (like, works without JavaScript enabled), is maintainable
and -- after all -- has some real advantage over what we have now,
please speak of it.

As a side note, few things that are not advantages:

* performing magic operations based on commit messages (which make
  commit messages reliant on software used, and likely breaking any
  other software used in the future),

* software committing to the repository for us (security reasons,
  commit signing etc.).

-- 
Best regards,
Michał Górny



pgpC_31rnt7ir.pgp
Description: OpenPGP digital signature

[gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: media-gfx/freewrl/

[Michał Górny]

On Mon, 18 Apr 2016 08:13:34 + (UTC)
"Patrice Clement"  wrote:

> commit: b6f6ee40596c7a17fbd4bf9a37d0f1c0a1e98e49
> Author: Patrice Clement  gentoo  org>
> AuthorDate: Mon Apr 18 06:48:33 2016 +
> Commit: Patrice Clement  gentoo  org>
> CommitDate: Mon Apr 18 07:58:35 2016 +
> URL:https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=b6f6ee40
> 
> media-gfx/freewrl: Fix metadata.xml file.
> 
> Package-Manager: portage-2.2.26
> 
>  media-gfx/freewrl/metadata.xml | 2 --
>  1 file changed, 2 deletions(-)
> 
> diff --git a/media-gfx/freewrl/metadata.xml b/media-gfx/freewrl/metadata.xml
> index bf65869..7c9a304 100644
> --- a/media-gfx/freewrl/metadata.xml
> +++ b/media-gfx/freewrl/metadata.xml
> @@ -12,8 +12,6 @@ support for rendering.  When developing your 3D world or 
> model, you can program
>  X3D Shaders Component, put your model exactly where you want them with the 
> Geospatial Component, or just 
>  throw triangles to the screen as Extrusions, IndexedFaceSets, TriangleSets, 
> Circle2D, Disk2D, Spheres, Boxes, 
>  Cubes; the list goes on and on.  With royalty free open standards, your 
> models will continue to render, year after year. 
> -=media-gfx/freewrl-1.22* uses traditional OpenGL calls, while 
> =media-gfx/freewrl-2 uses 
> -"shaders" and requires hardware capable of at least OpenGL-2.0 or OpenGL-ES.
>  
>   
>   Enable glew extensions

Unless I'm missing something, you've removed one sentence and provided
no replacement.

-- 
Best regards,
Michał Górny



pgpHaqrKbzcOl.pgp
Description: OpenPGP digital signature

[gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: media-libs/libopenshot/

[Michał Górny]

On Mon, 18 Apr 2016 08:13:34 + (UTC)
"Patrice Clement"  wrote:

> commit: dbc8fee7ab7851d6d9e236b85d22e7db5690ebb9
> Author: Patrice Clement  gentoo  org>
> AuthorDate: Mon Apr 18 06:54:23 2016 +
> Commit: Patrice Clement  gentoo  org>
> CommitDate: Mon Apr 18 07:58:39 2016 +
> URL:https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=dbc8fee7
> 
> media-libs/libopenshot: Fix metadata.xml file.
> 
> Package-Manager: portage-2.2.26
> 
>  media-libs/libopenshot/metadata.xml | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/media-libs/libopenshot/metadata.xml 
> b/media-libs/libopenshot/metadata.xml
> index 6d948f2..ab0b2d8 100644
> --- a/media-libs/libopenshot/metadata.xml
> +++ b/media-libs/libopenshot/metadata.xml
> @@ -13,7 +13,6 @@
>   
>   libopenshot
>   OpenShot/libopenshot
> - 
> https://github.com/OpenShot/libopenshot/issues
> - https://bugs.launchpad.net/libopenshot/+bugs
> + https://github.com/OpenShot/libopenshot/issues 
> https://bugs.launchpad.net/libopenshot/+bugs

This is invalid. Again you abuse limitation of QA checks to commit
invalid data. I guess it's really hard to imagine that if the schema
disallows multiple values, it is no so that people can pretend that
multiple URLs are a single URL.

>   
>  
> 



-- 
Best regards,
Michał Górny



pgpdjg8O4Y9xV.pgp
Description: OpenPGP digital signature

[gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: dev-qt/qtmultimedia/

[Michał Górny]

On Mon, 18 Apr 2016 08:13:34 + (UTC)
"Patrice Clement"  wrote:

> commit: d43acba31bb5d4f07e59479cd5728abc9367a9ca
> Author: Patrice Clement  gentoo  org>
> AuthorDate: Mon Apr 18 06:46:09 2016 +
> Commit: Patrice Clement  gentoo  org>
> CommitDate: Mon Apr 18 07:58:25 2016 +
> URL:https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=d43acba3
> 
> dev-qt/qtmultimedia: Fix metadata.xml file.
> 
> Package-Manager: portage-2.2.26
> 
>  dev-qt/qtmultimedia/metadata.xml | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/dev-qt/qtmultimedia/metadata.xml 
> b/dev-qt/qtmultimedia/metadata.xml
> index c0d6a4e..ab0a181 100644
> --- a/dev-qt/qtmultimedia/metadata.xml
> +++ b/dev-qt/qtmultimedia/metadata.xml
> @@ -9,8 +9,8 @@
>   Add support for exceptions - like 
> catching them
>   inside the event loop (recommended by upstream)
>   Enable EGL/GLES2 integration
> - Enable audio support via 
> media-libs/gstreamer:1.0
> - Enable audio support via 
> media-libs/gstreamer:0.10
> + Enable audio support via 
> media-libs/gstreamer-1.0
> + Enable audio support via 
> media-libs/gstreamer-0.10

This is invalid. Replacing invalid package names with other invalid
names is no fix. It is ugly Gentoo-style hackery which proves that
developers prefer trying randomly changing something until QA check
doesn't trigger over reading the documentation. As a result, now
a number packages with visible QA issues have been turned into a number
of packages with QA issues that aren't caught by the schema due to
regexp limitations.

Please go over all the packages you've touched and fix the silent
issues you introduced. I can't afford to waste more time writing more
complex QA checks that are going to cover all the ways Gentoo
developers can screw up such a simple thing as package *name*.

>   Build QML/QtQuick bindings and imports
>   Build the QtMultimediaWidgets module
>   
> 



-- 
Best regards,
Michał Górny



pgpGfbp5ofwKA.pgp
Description: OpenPGP digital signature

[gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: dev-db/mysql/

[Michał Górny]

On Mon, 18 Apr 2016 08:13:33 + (UTC)
"Patrice Clement"  wrote:

> commit: 912a9f1e2ed5717a7669861b4978dfaf868c5ae7
> Author: Patrice Clement  gentoo  org>
> AuthorDate: Mon Apr 18 06:33:40 2016 +
> Commit: Patrice Clement  gentoo  org>
> CommitDate: Mon Apr 18 07:57:59 2016 +
> URL:https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=912a9f1e
> 
> dev-db/mysql: Fix metadata.xml file.
> 
> Package-Manager: portage-2.2.26
> 
>  dev-db/mysql/metadata.xml | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/dev-db/mysql/metadata.xml b/dev-db/mysql/metadata.xml
> index 422ac80..538f21e 100644
> --- a/dev-db/mysql/metadata.xml
> +++ b/dev-db/mysql/metadata.xml
> @@ -1,11 +1,11 @@
>  
>  http://www.gentoo.org/dtd/metadata.dtd;>
>  
> -
> + 
>  hasuf...@gentoo.org
>  Libressl issues. Only assign if it's a direct Libressl 
> issue. Do not directly assign for anything else.
>
> -
> +  
>  mysql-b...@gentoo.org
>  MySQL
>

Thanks for the effort but could you please try to use consistent
indentation? 'git diff' is your friend.

-- 
Best regards,
Michał Górny



pgpWYJPFl9ENp.pgp
Description: OpenPGP digital signature

[gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: kde-base/kdeplasma-addons/

[Michał Górny]

On Mon, 18 Apr 2016 09:43:55 + (UTC)
"Patrice Clement"  wrote:

> commit: d527fc60dac82d4785fca1cca30c1aecbc7506b7
> Author: Patrice Clement  gentoo  org>
> AuthorDate: Mon Apr 18 09:12:02 2016 +
> Commit: Patrice Clement  gentoo  org>
> CommitDate: Mon Apr 18 09:28:28 2016 +
> URL:https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=d527fc60
> 
> kde-base/kdeplasma-addons: Fix metadata.xml file.
> 
> Package-Manager: portage-2.2.26
> 
>  kde-base/kdeplasma-addons/metadata.xml | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/kde-base/kdeplasma-addons/metadata.xml 
> b/kde-base/kdeplasma-addons/metadata.xml
> index 6227ce7..eab69b3 100644
> --- a/kde-base/kdeplasma-addons/metadata.xml
> +++ b/kde-base/kdeplasma-addons/metadata.xml
> @@ -9,7 +9,7 @@
>   Enable support for 
> dev-libs/libattica
>   Use ibus input method via 
> app-i18n/ibus
>   Enable Desktop Globe wallpaper using 
> kde-base/marble
> - Build Mandelbrot wallpaper plugin using 
> dev-cpp/eigen-2
> + Build Mandelbrot wallpaper plugin using 
> dev-cpp/eigen using SLOT 2

dev-cpp/eigen:2 was the form suggested in the GLEP.

>   Use fcitx input method via 
> app-i18n/fcitx
>   Enable JSON support via 
> dev-libs/qjson
>   KDE PIM integration via 
> kde-apps/kdepimlibs

-- 
Best regards,
Michał Górny



pgpp__YxIptdL.pgp
Description: OpenPGP digital signature

[gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: dev-games/mygui/

[Michał Górny]

On Mon, 18 Apr 2016 08:13:34 + (UTC)
"Patrice Clement"  wrote:

> commit: 4f2477ca1ab07969bae57e7b47e8b7a5ba9a6050
> Author: Patrice Clement  gentoo  org>
> AuthorDate: Mon Apr 18 06:35:31 2016 +
> Commit: Patrice Clement  gentoo  org>
> CommitDate: Mon Apr 18 07:58:13 2016 +
> URL:https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=4f2477ca
> 
> dev-games/mygui: Fix metadata.xml file.
> 
> Package-Manager: portage-2.2.26
> 
>  dev-games/mygui/metadata.xml | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/dev-games/mygui/metadata.xml b/dev-games/mygui/metadata.xml
> index 3dd4abc..a86d180 100644
> --- a/dev-games/mygui/metadata.xml
> +++ b/dev-games/mygui/metadata.xml
> @@ -9,7 +9,6 @@
>   
>   alt...@list.ru
>   Evmenov Georgiy
> - CC on bugs

You're discarding important information here. This also has been
covered in the GLEP. The suggested solution is to copy the person into
downstream maintainers with appropriate explanatory description (like
'upstream developer wishing to be CC-ed on bugs').

>   
>   
> http://redmine.mygui.info/repositories/entry/mygui/tags/MyGUI3.2/ChangeLog.txt
>   
> https://sourceforge.net/tracker/?group_id=193706atid=946487



-- 
Best regards,
Michał Górny



pgpMQllaRtG5k.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] Migrate to Phabricator

[Michael Orlitzky]

On 04/18/2016 09:44 AM, Kent Fredric wrote:
> 
> Two trends struck out at me, and assuming everything mentioned ( or
> linked in the related GHC entry[0] ) is still true:
> 

They are. Most of the Haskell standard library is still undocumented. If
anyone thinks Phabricator is a good idea, go document one of the
functions in the "base" package (part of GHC) and then see how you feel.

Re: [gentoo-dev] Migrate to Phabricator

[Kent Fredric]

On 19 April 2016 at 01:19, Kristian Fiskerstrand  wrote:
> References:
> [0]
> https://archives.gentoo.org/gentoo-dev/message/f74961c953d5ffedd1af9a67fdda6407


Based on the comments in this thread, I'd say I was not entirely
unfounded in being pessimistic.

Two trends struck out at me, and assuming everything mentioned ( or
linked in the related GHC entry[0] ) is still true:

- Anything that requires the use of the `arc` tool is a big "no" from me.
- And the indications are you need to use "specific magic" in commit
messages in order to make it "work", which is another big "no" from
me.


[0] https://ghc.haskell.org/trac/ghc/wiki/WhyNotPhabricator

-- 
Kent

KENTNL - https://metacpan.org/author/KENTNL

Re: [gentoo-dev] Migrate to Phabricator

[Guilherme Amadio]

Hello,

On Mon, Apr 18, 2016 at 01:44:00PM +0200, Jonas Jelten wrote:
> Ohai!
> 
> Phabricator is a fun adventure game: http://phabricator.org/
> It provides a tightly coupled set of project management tools.
> 
> Many bigger projects (e.g. blender, mediawiki, ...) started using
> phabricator, it could also be very beneficial for gentoo.

The website lists "Companies probably using Phabricator", which not a
very good for transmitting trust.

We've just been through major migrations: moving to git, website
migration, etc. We should not forget all the work that has been put into
making the current system work for Gentoo, and I have to say, I think that
our new website looks really nice, gitweb looks great too, and we have a
really large history of bugs on bugzilla, that also has a Gentoo theme.
Migrating to something else would be a huge undertaking. That's why,
even though I use and like Atlassian tools, I never proposed a migration
to JIRA, bitbucket and other tools. If others would like moving to
something else, I believe that Atlassian tools are more attractive.
Yes, they are a proprietary company, but they do offer free licenses for
open source projects that could be hosted on Gentoo Infra.

https://www.atlassian.com/software/views/open-source-license-request

That said, I'm not saying we should move to Atlassian tools, just that
it's probably a better option than Phabricator, if such a big migration
happens. I think that what we have now is already pretty good.

> Migrating would contradict the apparent goal of integrating github more
> tightly, but still we could consider to use Phabricator instead,
> especially to dump bugzilla.

While I'm not particularly against integrating more tightly with GitHub,
there is no such goal in Gentoo as far as I can tell. As much as I like
GitHub, I do understand the concerns of others about making GitHub
essential. It has been blocked before in certain regions of the world,
and that's not good for us, regardless of the free vs proprietary
debate. I don't think that GitHub is evil or anything, but GitHub is a
nice place for extras, to interact with the user community, receive
patches, etc. It should not replace our own infra.

Cheers,
—Guilherme

Re: [gentoo-dev] Migrate to Phabricator

[Jonas Jelten]

On 2016-04-18 15:10, Kent Fredric wrote:
> On 18 April 2016 at 23:44, Jonas Jelten  wrote:
>> especially to dump bugzilla.
> 
> Dumping bugzilla at this time would be a regression really. "Lets just
> discard millions of bugs and their history and important context" is
> not really an option for a web accessible opensource project with lots
> of inbound links, some of which are stashed in git commit messages,
> and are essentially unfixable.

I was more thinking of a migration so all tickets and all history is
preserved of course. One could even implement a redirector that still
accepts the bugzilla links but forwards to the migrated new ticket.

> 
>> It provides a tightly coupled set of project management tools. 
>> https://phacility.com/phabricator/
> 
> I tend to find "tightly coupled" a synonym for "fragile" and "Inflexible".
> 
> If there was a way for somebody to informally set up a phabricator
> instance in a non-committal manner
> that could be used merely for review purposes, that'd be nice.

I'm pretty sure that works. As far as I understood the setup, one can
disable any component without being fragile. I'm not sure what you mean
by inflexible, I'm just guessing that each tool does what it promises
and can interact with others nicely, and you just pick those you want.

Of course the wiki/documentation module is not useable for us as we have
the mediawiki.

We can enable more and more components over time, starting with the code
review thingy first if it works out.

> 
> But "lets change to this cool new thing because its cool" is something
> that doesn't resonate with me.
> 
> To 'Change' It has to be _proven_ useful for our usecases, and
> _proven_ to be _better_ than what we have, not dubious, tenuous and
> relatively unknown.
> 
> I'd want to be personally comfortable with using it before I ever
> voted in favour of gentoo changing to it.
> 
> And I'd expect all other devs to require that same high standard.

Agree'd. The first step might be setting up an instance that can somehow
sync all the status from ongoing work. Then people can play around and
try whether it fits their workflows.
However I'm not sure how comfortable and easy this is to accomplish.

> 
> Also: I Hold defacto reservations about anything written in PHP, due
> to both personal history with PHP, and the significant number of PHP
> projects with both atrocious code and glaring security defects.

That is a point, not sure if bugzilla does any better though ;)
Still, I can't say how good their code is, I've just used the result and
it was impressing.


>
> So I would want to be sure that not only is it better than what we
> have, but it is _at least_ as secure as what we have, and I'd want to
> be assured that the development team of Phabricator are competent and
> its not just yet-another-fly-by-night product.

If blender and wikimedia switched to it, it might actually have some
benefits. Which should not mean we follow blindly, but we should
consider its usability bonus.

> 
> 
>> Migrating would contradict the apparent goal of integrating github more 
>> tightly,
> 
> I have no idea where this "apparent goal" came from: "tight" github
> integration is not and has never been "on the table".
> 
> Github is purely a voluntary auxiliary process intended to allow
> people to augment their workflow in semi-useful ways, and then, some
> of the things github provides is harmful ( Githubs inability to handle
> rebased pulls makes people do horrible long merge commits )
> 
> Its been repeatedly stated that Github must never be "Relied upon" in
> a mandatory way, because it is inherently proprietary and usurps all
> the authority that Gentoo infra have, and puts the Gentoo organisation
> at Githubs mercy, and this would be entirely unconscionable as the
> "only pathway".
> 

I'm fully aware of that, what I'm trying to say is that many of github's
features are present in phabricator, which would make us more
independent again. Which does not mean I hate github and wanna leave it
etc, just that phabricator can give us another, self-hosted contribution
plattform.




signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Migrate to Phabricator

[Kristian Fiskerstrand]

On 04/18/2016 03:10 PM, Kent Fredric wrote:
> On 18 April 2016 at 23:44, Jonas Jelten  wrote:
>> especially to dump bugzilla.
> 



> If there was a way for somebody to informally set up a phabricator 
> instance in a non-committal manner that could be used merely for
> review purposes, that'd be nice.

Indeed, kensington already did some experimentation on this this a
while back[0], but I'm not sure what what lessons were learned from it.

My personal 2c is that there is a very big difference between a
read-only review tool and something more deeply integrates when
considering security.

References:
[0]
https://archives.gentoo.org/gentoo-dev/message/f74961c953d5ffedd1af9a67fdda6407
-- 
Kristian Fiskerstrand
OpenPGP certificate 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] Migrate to Phabricator

[Kent Fredric]

On 18 April 2016 at 23:44, Jonas Jelten  wrote:
> especially to dump bugzilla.

Dumping bugzilla at this time would be a regression really. "Lets just
discard millions of bugs and their history and important context" is
not really an option for a web accessible opensource project with lots
of inbound links, some of which are stashed in git commit messages,
and are essentially unfixable.

> It provides a tightly coupled set of project management tools. 
> https://phacility.com/phabricator/

I tend to find "tightly coupled" a synonym for "fragile" and "Inflexible".

If there was a way for somebody to informally set up a phabricator
instance in a non-committal manner
that could be used merely for review purposes, that'd be nice.

But "lets change to this cool new thing because its cool" is something
that doesn't resonate with me.

To 'Change' It has to be _proven_ useful for our usecases, and
_proven_ to be _better_ than what we have, not dubious, tenuous and
relatively unknown.

I'd want to be personally comfortable with using it before I ever
voted in favour of gentoo changing to it.

And I'd expect all other devs to require that same high standard.

Also: I Hold defacto reservations about anything written in PHP, due
to both personal history with PHP, and the significant number of PHP
projects with both atrocious code and glaring security defects.

So I would want to be sure that not only is it better than what we
have, but it is _at least_ as secure as what we have, and I'd want to
be assured that the development team of Phabricator are competent and
its not just yet-another-fly-by-night product.


> Migrating would contradict the apparent goal of integrating github more 
> tightly,

I have no idea where this "apparent goal" came from: "tight" github
integration is not and has never been "on the table".

Github is purely a voluntary auxiliary process intended to allow
people to augment their workflow in semi-useful ways, and then, some
of the things github provides is harmful ( Githubs inability to handle
rebased pulls makes people do horrible long merge commits )

Its been repeatedly stated that Github must never be "Relied upon" in
a mandatory way, because it is inherently proprietary and usurps all
the authority that Gentoo infra have, and puts the Gentoo organisation
at Githubs mercy, and this would be entirely unconscionable as the
"only pathway".

-- 
Kent

KENTNL - https://metacpan.org/author/KENTNL

[gentoo-dev] Migrate to Phabricator

[Jonas Jelten]

Ohai!

Phabricator is a fun adventure game: http://phabricator.org/

It provides a tightly coupled set of project management tools.
https://phacility.com/phabricator/

Many bigger projects (e.g. blender, mediawiki, ...) started using
phabricator, it could also be very beneficial for gentoo.

https://secure.phabricator.com/w/usage/companies/
https://secure.phabricator.com/w/usage/not/

Wikimedia elaborates about the migration:

https://blogs.gnome.org/aklapper/2014/12/17/welcome-phabricator/
https://www.mediawiki.org/wiki/Phabricator/versus_Bugzilla

https://wiki.blender.org/index.php/Dev:Doc/Tools/Phabricator/Migration

Migrating would contradict the apparent goal of integrating github more
tightly, but still we could consider to use Phabricator instead,
especially to dump bugzilla.

If we come to the conclusion we are a really serious business, we must
set up the "Serious Business Edition", for the most serious businesses.

Still, I hope we can go with the Awesome Edition :P

Cheers,
JJ



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-portage-dev] [PATCH] Colorize packages in user sets (bug 577720)

[Alexander Berntsen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 20/03/16 15:33, Adam Mills wrote:
> + def isUserSet(self): +  return False +
Furthermore, this makes no sense and needs to go.

- -- 
Alexander
berna...@gentoo.org
https://secure.plaimi.net/~alexander
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCgAGBQJXFH22AAoJENQqWdRUGk8Bjx0P/22kcx+y/MulWUDHl31kIKoG
T1WqdW4dqDv/1xGCFvpAQWX8w04cHRs2AxzKWdWNWqDi53LAAHaRMX/8VhxoV/3Y
zQtZfeT7CFfX5Mtn5NLVG5C6/Xvemo2NjKSQqF76TH+CUUVDCr1lP73kned/vwV4
Hj4JNgrQamsMpzdsmU/UvyHClh9rvLwulc3+7vIaaY9UB5wUDsVJfs7MwtO0xEau
7YnAv6gvm501JDxrFyzes8524ghPBsQmoVLaDTpEl+ilF+k3qEdJ8vZJ7bth+FUC
qvjpjI4hZf09SBI6z5MfnXTepyjL8iqV4+l28jjm3JWDMYVrKCbjGAnMllUH3bZD
gYQBCKzqCsdwgA3THHESMJnHGxcmMymaBbqUzqYobvPjNSgsdPOmG9bNoZxlbVJu
TMtNuHQQKxkn7/UeEHvCE6XGPcLLzGD7fxYlj18LyXfbI8LnZAK9bcX45jK3dWGp
LCp/S0M9fgox1wkUWy8TU7DFwM5MQ9q9ZmmfhaAuPS37Zt08TiUf6HEz8R21y24/
eanNTHPrL18CqFkBRrXqBFLIFuYF+fUH+wEZ6gWVBUxTj/IH/U4PnlKRFlwbFP9o
Txs9VETI10Z2vilAUwyhP3uQa4pfsGH6RDkUFKFJt3TPPneOPKlNh7VFeQP23EMk
TtowE5+ZvgYh5e/juBxU
=eHbc
-END PGP SIGNATURE-