Re: [gentoo-dev] The future of virtual/mysql and virtual/libmysqlclient

[Robin H. Johnson]

On Tue, Feb 13, 2018 at 09:32:32PM -0500, Brian Evans wrote:
> I have a plan I would like some eyes on...
> 
> I want to gradually *BAN* the use of virtual/mysql and
> virtual/libmysqlclient as dependencies.
Overall I agree, but there's some slight concerns I have.

> To accomplish this, force dev-db/mysql-connector-c to be the only souce
> of libmysqlclient.so.
>
> Packages that choose to support  libmariadb.so instead can include a
> libmariadb USE to hook up to dev-db/mariadb-connector-c that will be
> introduced (and they can live side-by-side).  The motivation for this
> could be licensing with libmariadb being LGPL instead of GPL.  This is
> similar to ffmpeg/libav, except the libraries can co-exist.
Have all the concerns about using slightly different libmysqlclient.so
builds been resolved? Esp for pre-built binaries (I don't know if there
are any left in the tree).

> The current providers of virtual/mysql would get a new USE flag that is
> MASKED for all users for the transition period and pull in the lib
> package(s) when that USE is disabled.
> 
> virtual/mysql would become a server reference for USERS only.  It would
> be a QA warning violation to depend directly on virtual/mysql as it can
> live anywhere.
This part worries me slightly. I do understand that mysql-embedded is
retired entirely, but apps that spun up their own local mysqld instance
would still be affected this this change.

-- 
Robin Hugh Johnson
Gentoo Linux: Dev, Infra Lead, Foundation Treasurer
E-Mail   : robb...@gentoo.org
GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
GnuPG FP : 7D0B3CEB E9B85B1F 825BCECF EE05E6F6 A48F6136


signature.asc
Description: Digital signature

[gentoo-dev] The future of virtual/mysql and virtual/libmysqlclient

[Brian Evans]

I have a plan I would like some eyes on...

I want to gradually *BAN* the use of virtual/mysql and
virtual/libmysqlclient as dependencies.

To accomplish this, force dev-db/mysql-connector-c to be the only souce
of libmysqlclient.so.

Packages that choose to support  libmariadb.so instead can include a
libmariadb USE to hook up to dev-db/mariadb-connector-c that will be
introduced (and they can live side-by-side).  The motivation for this
could be licensing with libmariadb being LGPL instead of GPL.  This is
similar to ffmpeg/libav, except the libraries can co-exist.

The current providers of virtual/mysql would get a new USE flag that is
MASKED for all users for the transition period and pull in the lib
package(s) when that USE is disabled.

virtual/mysql would become a server reference for USERS only.  It would
be a QA warning violation to depend directly on virtual/mysql as it can
live anywhere.

virtual/libmysqlclient would be last-rite as it doesn't work as intended

That about sums it up.

Brian
MySQL team lead



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] newsitem: baselayout 2.5 changes (round 2)

[Peter Stuge]

William Hubbs wrote:
> The first change is that ROOTPATH is no longer set. This means all of
> the *sbin directories will be added to the default path for all users
> instead of just the root user.

Maybe add a sentence about why this is changing or even neccessary,
to avoid perception of weakened security.


//Peter

[gentoo-dev] Re: [gentoo-project] rfc: council members and appeals

[Ulrich Mueller]

> On Tue, 13 Feb 2018, Ulrich Mueller wrote:

> [about QA's role]

Sorry, I didn't spend attention to the fact that the message I was
replying to was in the wrong list. Please continue in gentoo-project
where this thread belongs.


pgp8a3bnmBxzU.pgp
Description: PGP signature

[gentoo-dev] Re: [gentoo-project] rfc: council members and appeals

[Ulrich Mueller]

> On Tue, 13 Feb 2018, Chí-Thanh Christopher Nguyễn wrote:

> Dean Stephens schrieb:
>>> QA and Comrel are special in that they can take disciplinary
>>> action against non-members, which there is no recourse against
>>> except appeal to the Council.
>>> 
>> At the very least: QA, Comrel, IRC ops (in every project specific
>> channel), planet/universe, forums, and wiki.

> Council, QA and Comrel are effectively the governing bodies of
> Gentoo, enacting and/or enforcing project-wide policy on their own
> accord. The others that you mention have only direct power in a very
> limited area.

At least for QA this is quite an oversimplified description of the
team's role. Quoting GLEP 48, first bullet point of the specification:
"The QA team's purpose is to provide cross-team assistance in keeping
the tree in a good state. This is done primarily by finding and
pointing out issues to maintainers and, where necessary, taking direct
action."

The latter is meant in the sense of direct action to the tree (and
even then, overriding maintainers is not the default). The QA team
doesn't have the power to take any direct disciplinary action against
developers.

Theoretically, in the case of continuing breakage caused by a dev, QA
could ask ComRel to have that dev's commit access suspended. I cannot
remember any case where such a measure was taken (correct me if I am
wrong).

So, it appears that QA has teeth but need not use them. ;)

Ulrich


pgpOPB9l6BwRS.pgp
Description: PGP signature

[gentoo-dev] Gentoo has been accepted as a Google Summer of Code 2018 mentoring organization

[Alice Ferrazzi]

Hello everyone,

Gentoo has been accepted into the Google Summer of Code 2018!

Mentors:
If you want to mentor some projects on Gentoo GSoC 2018 please add
yourself here [1] as soon as possible, is important!.
Someone from the Gentoo GSoC team will contact you back, as soon as possible.

Students:
If you are a student and want to spend your summer on Gentoo projects
and having fun writing code, you can start discussing ideas in the
#gentoo-soc IRC Freenode channel [2].
You can find some ideas example here [3], but of course could be also
something different.
Just remember that we strongly recommend that you work with a
potential mentor to develop your idea before proposing it formally.
Don’t waste any time because there’s typically some polishing which
needs to occur before the deadline (March 28th)

I can assure you that Gentoo GSoC is really fun and a great experience
for improving yourself.
It is also useful for making yourself known in the Gentoo community.
Contributing to the Gentoo GSoC will be contributing to Gentoo, a
bleeding edge distribution, considered by many to be for experts and
with near-unlimited adaptability.

If you require any further information, please do not hesitate to
contact us [4] or check the Gentoo GSoC 2018 wiki page [5].

[1] https://wiki.gentoo.org/wiki/Google_Summer_of_Code/2018/Mentors
[2] http://webchat.freenode.net/?channels=gentoo-soc
[3] https://wiki.gentoo.org/wiki/Google_Summer_of_Code/2018/Ideas
[4] soc-ment...@gentoo.org
[5] https://wiki.gentoo.org/wiki/Google_Summer_of_Code/2018

-- 
Thanks,
Alice Ferrazzi

Gentoo Kernel Project Leader
Gentoo Foundation Vice-Secretary
Gentoo Google Summer of Code Administrator
Mail: Alice Ferrazzi 
PGP: 2E4E 0856 461C 0585 1336 F496 5621 A6B2 8638 781A

Re: [gentoo-dev] Re: [gentoo-project] rfc: council members and appeals

[M. J. Everitt]

On 13/02/18 20:57, Rich Freeman wrote:
> On Tue, Feb 13, 2018 at 3:53 PM, Chí-Thanh Christopher Nguyễn
>  wrote:
>> Dean Stephens schrieb:
>>
 Suppose that the council decides to accept an appeal from comrel. Is it
 a conflict of interest for a member of the council who is also a member
 of comrel to vote in the appeal? If it isn't, it is at least a pretty
 strong perception that it is.

>>> Why? How? Exactly what sort of conflicting interest is supposed to be
>>> present?
>> I think in Comrel vs. Council is not a conflict of interest, but rather
>> throwing the appeals process off balance. Can you expect someone to neutrally
>> review material and actions (question the authenticity of evidence, identify
>> potential misconduct, etc.) that they themselves used to build the case
>> against the reprimanded?
>>
> I hope that Comrel does not consider it their main duty to build cases
> against community members.  They're supposed to investigate, mediate,
> and take action if necessary.  They aren't prosecutors.
>
Do you have evidence either to support or contradict your case? TIA...



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Re: [gentoo-project] rfc: council members and appeals

[Rich Freeman]

On Tue, Feb 13, 2018 at 3:53 PM, Chí-Thanh Christopher Nguyễn
 wrote:
> Dean Stephens schrieb:
>
>>> Suppose that the council decides to accept an appeal from comrel. Is it
>>> a conflict of interest for a member of the council who is also a member
>>> of comrel to vote in the appeal? If it isn't, it is at least a pretty
>>> strong perception that it is.
>>>
>> Why? How? Exactly what sort of conflicting interest is supposed to be
>> present?
>
> I think in Comrel vs. Council is not a conflict of interest, but rather
> throwing the appeals process off balance. Can you expect someone to neutrally
> review material and actions (question the authenticity of evidence, identify
> potential misconduct, etc.) that they themselves used to build the case
> against the reprimanded?
>

I hope that Comrel does not consider it their main duty to build cases
against community members.  They're supposed to investigate, mediate,
and take action if necessary.  They aren't prosecutors.

-- 
Rich

[gentoo-dev] Re: [gentoo-project] rfc: council members and appeals

[Chí-Thanh Christopher Nguyễn]

Ulrich Mueller schrieb:

> Don't vote for that person then? Why would we need a general rule
> restricting voters from electing any specific candidate?

For the same reason why governing bodies sometimes restrict accumulation of
mandates (and have term limits etc.). Of course the electorate can just vote
for another person, but that is not the point.

In the case of Gentoo, if one body is supposed to supervise the other,
holding positions in both can lead to problems. While this may be ok if one
of them is small and limited in scope, the more powerful both are the more
problematic it gets.


Best regards,
Chí-Thanh Christopher Nguyễn

[gentoo-dev] Re: [gentoo-project] rfc: council members and appeals

[Chí-Thanh Christopher Nguyễn]

Dean Stephens schrieb:

>> Suppose that the council decides to accept an appeal from comrel. Is it
>> a conflict of interest for a member of the council who is also a member
>> of comrel to vote in the appeal? If it isn't, it is at least a pretty
>> strong perception that it is.
>>
> Why? How? Exactly what sort of conflicting interest is supposed to be
> present?

I think in Comrel vs. Council is not a conflict of interest, but rather
throwing the appeals process off balance. Can you expect someone to neutrally
review material and actions (question the authenticity of evidence, identify
potential misconduct, etc.) that they themselves used to build the case
against the reprimanded?

Best regards,
Chí-Thanh Christopher Nguyễn

[gentoo-dev] Re: [gentoo-project] rfc: council members and appeals

[Chí-Thanh Christopher Nguyễn]

Dean Stephens schrieb:
>> QA and Comrel are special in that they can take disciplinary action against
>> non-members, which there is no recourse against except appeal to the Council.
>>
> At the very least: QA, Comrel, IRC ops (in every project specific
> channel), planet/universe, forums, and wiki.

Council, QA and Comrel are effectively the governing bodies of Gentoo,
enacting and/or enforcing project-wide policy on their own accord. The others
that you mention have only direct power in a very limited area.


Best regards,
Chí-Thanh Christopher Nguyễn

[gentoo-dev] Re: SAT-based dependency solver: request for test cases

[Martin Vaeth]

Michael Lienhardt  wrote:
> the criteria list you gave (maybe it's in the PMS)

I doubt that it is in PMS, and IMHO it also does not belong there:
As long as the result configuration is valid (no collisions
or unresolvable loops) all should be equally fine from the
viewpoint of PMS: It is in the responsibility of the package
manager and its configuration to determine correctly what the
_user_ actually wants.

>   - in criteria a., there could be an ambiguity between what I call a package
> (e.g., 'app-editors/nano-2.9.3') and a package group (e.g.,
> 'app-editors/nano')

This is what already Michał has oberved: In my list, I had completely
forgotten to refer to versions ('app-editors/nano-2.9.3') and had only
packages ('app-editors/nano') in mind.
(I think "version" vs. "package" is the usual terminology in gentoo;
there are also "slots" which in a sense might be considered as
different packages, although perhaps with a different "penalty")

> is the criteria about package group (i.e., are version changes allowed)?

Version upgrades should even be preferred over remaining with the version.
OTOH, version downgrades are perhaps even worse than using a different package
(opinions might differ for the latter).

>   - similarly in criteria b.: is this criteria valid across versions
> (i.e., when changing version, the USE-flag change should be minimal)

Cf. the next point: The USE-flag change compared to user configuration
(package.use etc.) should be minimal.

>   - just to be sure, the "less keyword and mask change" criteria is at the
> top of the list?

Yes. Only "illegal" configurations (colliding packages or unresolvable
dependency loops of uninstalled packages) should weight stronger:
If possible at all, the user's choice should always be preferred,
and changes to the configuration should only be suggested if no other
solution exists (and probably the number of suggested changes should
be minimal in a sense).

Re: [gentoo-dev] Re: SAT-based dependency solver: request for test cases

[Michael Lienhardt]

Thanks a lot for this list!

You are totally right, simply translating the dependencies into SAT constraints 
and feeding them to a solver returns in most cases a very bad, totally useless 
solution.
However, nowadays many solvers support solution optimization, i.e., you can 
specify an ordered list of criteria you want to maximize/minimize, exactly like 
you did.
I already implemented the minimal status difference and the minimal 
installation size criteria, and the solutions I get are already acceptable/good.

I wasn't aware of the criteria list you gave (maybe it's in the PMS), so thank 
you very much, this is a big help :)
I have few questions about these criteria:
 - in criteria a., there could be an ambiguity between what I call a package 
(e.g., 'app-editors/nano-2.9.3') and a package group (e.g., 
'app-editors/nano'): is the criteria about package group (i.e., are version 
changes allowed)?
 - similarly in criteria b.: is this criteria valid across versions (i.e., when 
changing version, the USE-flag change should be minimal), across slots (i.e., 
two installed versions of the same package group should have a minimal USE flag 
difference)?
   If yes, what if package.use specifies very different USE flags for two 
versions of the same package group?
 - does the "prefer new version" criteria go between a. and b.?


b. Similarly, the number of USE-flag changes necessary to achieve this
aim should be minimized.
(You didn't tell whether your solver already supports such changes,
but when it is finished, it definitely should.)


Yes, my solver supports USE-flag, keyword and mask changes (it is currently 
oblivious of licenses, but supporting them should just be a technical/time 
consuming effort).
Due to keywords and mask changes, the "prefer new version" criteria needs to be after 
criteria "less keyword and mask change".
 - just to be sure, the "less keyword and mask change" criteria is at the top 
of the list?

Best regards,
Michael Lienhardt

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

[Kristian Fiskerstrand]

On 02/13/2018 11:47 AM, Michael Palimaka wrote:
> On 02/12/2018 08:59 AM, Kristian Fiskerstrand wrote:
>> # Kristian Fiskerstrand  (11 Feb 2018)
>> # Lastrite: app-crypt/monkeysign . Please use caff from
>> # app-crypt/signing-party instead. Removal in 30 days.
>> # Bug: #647352
>> app-crypt/monkeysign
>>
> 
> What's the reason for the removal?
> 

Very little upstream activity and not expected to be anything happening
with it soon, and some breakages etc that should be fixed for it to be
used. I'm not using it, and rather dropping it than putting it in the
ever-growing pile of maintainer needed. Feel free to take it if you want
it though.

-- 
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] Re: SAT-based dependency solver: request for test cases

[Martin Vaeth]

Michał Górny  wrote:
>> 
>> d. In || ( ... ) clauses the left-most packages should be preserved.

s/preserved/preferred/

> you've missed the most important point: we want to prefer
> the newest version, whenever possible
> ;-).

Yes, you are right: I had thought only about packages, not about versions.
Of course, a version upgrade within the same slot should have a
negative penalty. I am already not sure how upgrades with slot
changes should be treated. And then there are subslots...
The list is probably still not exhaustive and - as already mentioned -
the penalties are certainly a topic of discussion (and even more of
trial and error: which works best in practice).

Anyway, I think that it would be a huge improvement over the current
(portage's) solver if one could formulate such a list explicitly in
some specified format, and then one abstract algorithm takes care to
find the best solution according to the specified penalties:
If I understand it correctly, all these rules are currently hard-coded
into the algorithm by using various hacks in backtracking steps,
finding of a solution is convoluted with determining the order, etc.
One would obtain a solver which not only is "provably" correct,
but also much easier to maintain and to tweak (e.g. if one realizes
that certain penalties were not cleverly chosen).

This would also provide the possibility for much richer user configuration.
An example which immediately come to mind is "weak-masking" of packages
or versions ("use it or upgrade only if no alternative is available").
Theoretically, one could then even endow the entries of package.mask
with a penalty number.

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

[M. J. Everitt]

On 13/02/18 10:47, Michael Palimaka wrote:
> On 02/12/2018 08:59 AM, Kristian Fiskerstrand wrote:
>> # Kristian Fiskerstrand  (11 Feb 2018)
>> # Lastrite: app-crypt/monkeysign . Please use caff from
>> # app-crypt/signing-party instead. Removal in 30 days.
>> # Bug: #647352
>> app-crypt/monkeysign
>>
> What's the reason for the removal?
>
Wait, there have to be reasons for removal now?! 

The only good last-rites messages I've ever seen from from jstein where
there is indeed a good traceable path as to why the dev feels that the
package is "beyond repair". Otherwise it does seem like a lot of cases
of "can't be bothered with this any more, lets kill it off". Correct me
if I'm wrong, by all means ...



signature.asc
Description: OpenPGP digital signature

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

[Michael Palimaka]

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

What's the reason for the removal?

Re: [gentoo-dev] Re: SAT-based dependency solver: request for test cases

[Michał Górny]

W dniu wto, 13.02.2018 o godzinie 07∶49 +, użytkownik Martin Vaeth
napisał:
> Michael Lienhardt  wrote:
> > 
> > ad-hoc fixes and tweaks that can hardly be encoded into SAT constraints.
> 
> The main difficulty which I see is that one does not want only _some_
> solution, but among all solutions one which optimizes certain quantities.
> So it seems to me that a discrete optimization under constraints
> is required instead of a pure SAT solver (although formally, of course,
> such an optimization problem can be reduced to SAT, I do not know whether
> you went the road):
> 
> a. The number of packages which change their status (from installed to
> uninstalled or vice versa) should be minimal.
> 
> b. Similarly, the number of USE-flag changes necessary to achieve this
> aim should be minimized.
> (You didn't tell whether your solver already supports such changes,
> but when it is finished, it definitely should.)
> 
> Hopefully in near future, there will be a second class of USE-flags
> whose change is "cheap" which should be excluded from this minimization
> restriction:
> https://bugs.gentoo.org/show_bug.cgi?id=424283
> I think the main reason why nobody dared to implement them yet
> (although almost everybody wants them) are exactly these implications
> on the current solver in portage which nobody dares to change anymore
> seriously.
> 
> c. A solution with dependency loops should be avoided if possible
> (which is why currently the PDEPEND hacks do exist: To tell the solver
> which loops are not a problem.)
> 
> d. In || ( ... ) clauses the left-most packages should be preserved.
> There are similar (and more difficult) rules for REQUIRED_USE.
> 
> e. Last but not least: The preferences are ordered a > b > c > d
> (A dependency loop of uninstalled packages should probably have even
> higher priority than a).
> Additionally the change installed -> uninstalled should be less
> "expensive" than the change uninstalled -> installed.
> The correct weighting of the quantities should probably be a matter
> of discussion (or preferrably even user-customizable), and preferrably
> should not depend only on the number of packages but also on other
> customizable quantities (e.g. the package size).
> 

Thank you for listing this. However, I think you've missed the most
important point: we want to prefer the newest version, whenever possible
;-).

-- 
Best regards,
Michał Górny