Re: [gentoo-portage-dev] Constraint-Based Dependency Solver: initial results
On 8/30/19 7:34 AM, michael.lienha...@laposte.net wrote: > - install the configuration computed by my solver (I am still unsure that > emerge --nodeps would be flexible enough, and maybe I will have to implement > my own planner) One problem with emerge --nodeps is that it does not resolve file collisions in cases where two packages block each other. Normally, such collisions are resolved by removing the files from the contents of the installed package (the installed package is ultimately unmerged in order to solve the blocker), but with --nodeps the blockers are simply discarded and emerge treats all file collisions as fatal. Another problem is that --nodeps eliminates the dependency information that's needed for scheduling parallel builds with emerge --jobs. -- Thanks, Zac signature.asc Description: OpenPGP digital signature
Re: [gentoo-portage-dev] Constraint-Based Dependency Solver: initial results
On 8/30/19 10:34 AM, michael.lienha...@laposte.net wrote: > > All comments/suggestions are welcomed. > Since no one else has said it yet (?), I think this approach is really cool and I'm glad someone is working on it. Modeling difficult computations as abstract optimization problems is a "hobby" of mine, and I think it will pay off if we can abstract away a big ugly part of the PM and try to swap it out for something more principled.
Re: [gentoo-dev] Re: stable-bot is down. Temporary? Forever? Can we have a contacts page for it?
On Tue, Oct 8, 2019 at 4:57 AM Michael Palimaka wrote: > On 10/8/19 7:21 AM, Andreas K. Huettel wrote: > > In any case, since many people *do* rely on it, maybe we should declare > it > > official? [+] > > > > And, if that's OK with both of you, move it onto infra hardware? > > > > Happy to sponsor both for the next council meeting agenda. > > > > > > [+] At some point the one remaining whiner doesnt count anymore. > > > > In the past, infra has been understandably hesitant to take on new > services due to staffing issues. > > Additionally, I understand that the current infra design does not easily > allow granular access control, preventing non-infra members from easily > performing maintenance on individual services. > > Has this situation changed? I doubt infra want to take responsibility > for the bot, and I don't fancy the hassle of trying to find people to > poke things on my behalf. > Things have not changed. We don't need to run the bot, we just need some clearer contact info for it IMHO. I don't think the reliability of the bot is really that different from official infra services, but it was unclear who owned it and so there was confusion; and I think the confusion is the key thing we are looking to resolve here. -A
Re: [gentoo-dev] Re: stable-bot is down. Temporary? Forever? Can we have a contacts page for it?
On Tue, Oct 8, 2019 at 7:57 AM Michael Palimaka wrote: > > On 10/8/19 7:21 AM, Andreas K. Huettel wrote: > > In any case, since many people *do* rely on it, maybe we should declare it > > official? [+] > > > > And, if that's OK with both of you, move it onto infra hardware? > > > > Happy to sponsor both for the next council meeting agenda. > > > > > > [+] At some point the one remaining whiner doesnt count anymore. > > > > In the past, infra has been understandably hesitant to take on new > services due to staffing issues. > > Additionally, I understand that the current infra design does not easily > allow granular access control, preventing non-infra members from easily > performing maintenance on individual services. > > Has this situation changed? I doubt infra want to take responsibility > for the bot, and I don't fancy the hassle of trying to find people to > poke things on my behalf. > IMO we should have a few tiers: 1. Absolutely core stuff that infra has to run (authentication, LDAP, maybe some services, etc). 2. Community-run stuff that is FOSS, with public config tracking (minus passwords/etc), and reasonably good docs. 3. Community-run stuff that is the wild west. IMO having a service catalog that includes all of this stuff is beneficial, with clear indications as to which tier each thing is in and who to contact with issues. Depending on #1-2 shouldn't really be a problem. #3 can be a playground for experimentation but shouldn't be something we really depend on for core workflow. To mitigate the risk of #2 we could have exercises to clone services following docs/etc. If anything #2 has the potential to be more reliable than #1 if it gets enough attention (though there is no reason our internal services couldn't also be made easy-to-replicate). I think the issue here is that we don't really have any standards for #2, but it is clear that this particular bot is intended to meet those requirements but doesn't quite do so today. I think this is a compromise that could help us focus our infra resources where they're needed most, with some separation of concerns. Ideally we should also make it possible via single-sign-on technologies to leverage infra's authentication services for stuff in tier 2, and maybe tier 3. Biggest risk is phishing if somebody spoofs a sign-on page. -- Rich
[gentoo-dev] Re: stable-bot is down. Temporary? Forever? Can we have a contacts page for it?
On 10/8/19 7:21 AM, Andreas K. Huettel wrote: In any case, since many people *do* rely on it, maybe we should declare it official? [+] And, if that's OK with both of you, move it onto infra hardware? Happy to sponsor both for the next council meeting agenda. [+] At some point the one remaining whiner doesnt count anymore. In the past, infra has been understandably hesitant to take on new services due to staffing issues. Additionally, I understand that the current infra design does not easily allow granular access control, preventing non-infra members from easily performing maintenance on individual services. Has this situation changed? I doubt infra want to take responsibility for the bot, and I don't fancy the hassle of trying to find people to poke things on my behalf.
[gentoo-dev] Re: [gentoo-dev-announce] Gentoo CI news: pkgcheck is now running truly parallel
Michał Górny writes: > Just a quick note: thanks to hard work of radhermit, the newest release > of pkgcheck features internal parallelization of checks. While it's not > perfect and there's still room for improvement (I mean, it could run > even faster!), it's a major step forward. > > This means that I've finally retired that ugly hack that split > categories into multiple groups and ran them in parallel. This means > that CI is no longer bound by the longest category (hello, media-libs/) > and can utilize all 32 cores instead of ~14. > > This also means that if you're planning to run tree-wide scans with > pkgcheck, you no longer have to employ huge hacks to make them faster. > You just run it normally! In your face, repoman! > > Once again, thanks to radhermit. His work on pkgcheck is astonishing, > and it's becoming a great tool for developers. A big round of applause to radhermit for the better QA tool! Thank you to all who contributed. Benda signature.asc Description: PGP signature