Re: [gentoo-dev] The future of virtual/mysql and virtual/libmysqlclient
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
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)
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
> 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
> 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
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
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
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
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
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
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
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
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
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
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
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
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
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