* [gentoo-dev] New Portage fork: sys-apps/portage-mgorny @ 2018-03-22 19:03 Michał Górny 2018-03-22 20:17 ` James Le Cuirot ` (2 more replies) 0 siblings, 3 replies; 42+ messages in thread From: Michał Górny @ 2018-03-22 19:03 UTC (permalink / raw To: gentoo-dev Hello, everyone. After 2+ years of repeating disagreements with Portage maintainer(s) I have finally decided to fork Portage. My little fork uses technical name of 'portage[mgorny]' [1] (to distinguish it from mainline Portage), and aims to focus on cleaning up code and adding useful features with less concern for infinite bug-by-bug compatibility. Detailed rationale in README [2]. Before installing ----------------- This is a bleeding-edge, strictness-first fork of Portage. It is intended for developers and power users mostly. Things will break. You will eventually be asked to remove files deprecated 5+ years ago. Developer mistakes will harm you (but someone needs to find them and report them!) Dynamic dependencies are off by default (following Council decision from 3.5yr ago). If you haven't rebuilt your system recently, you may need to use '--changed-deps' once. Afterwards, things should work fine unless developers screw up, and then you should report bugs. Only ~arch version at the moment. Installing ---------- To switch to my fork of Portage, just: emerge -vn sys-apps/portage-mgorny Note that you may need to: emerge --deselect sys-apps/portage app-portage/repoman (repoman is integrated back into Portage) You may also need to upgrade all revdeps of Portage since the newest versions were bumped with updated dependencies. Please note that due to misdesign, Portage will abort upon having to unmerge itself on first install. However, it is a harmless failure and portage[mgorny] will be installed already at the point, so upon restarting it will just finish cleaning up. Merge plan ---------- I do intend to regularly merge from mainline Portage, and preserve reasonable compatibility (especially in terms of API). I also plan to keep reasonably good commit quality as to make it easier for Portage developers to merge back. However, this is not my primary concern. Releases -------- I plan to make frequent releases. I'm planning to version the releases by sequential values of fourth version component from the last Portage release. For example, since the last Portage release is 2.3.24, I have just released portage-mgorny-2.3.24.1, the next release will be 2.3.24.2, etc. until Portage 2.3.25 is released. The releases are made against *git HEAD* and not respective Portage versions, i.e. 2.3.24.1 is [2.3.24 + changes in mainline + my changes]. The matching versions are mostly meant to make >= deps easier, i.e. you can reasonably assume portage-mgorny-2.3.24* will have all the new APIs of portage-2.3.24. The release notes [3] list any major changes I make. They do not list the respective changes in mainline Portage, sorry. Bugs, features and requests --------------------------- I'm open to your feedback, including things that were rejected by mainline Portage team. For best efficiency, please report bugs on GitHub [4] and/or open pull requests [5]. Enjoy! [1]:https://github.com/mgorny/portage [2]:https://github.com/mgorny/portage/blob/master/README [3]:https://github.com/mgorny/portage/releases [4]:https://github.com/mgorny/portage/issues [5]:https://github.com/mgorny/portage/pulls -- Best regards, Michał Górny ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [gentoo-dev] New Portage fork: sys-apps/portage-mgorny 2018-03-22 19:03 [gentoo-dev] New Portage fork: sys-apps/portage-mgorny Michał Górny @ 2018-03-22 20:17 ` James Le Cuirot 2018-03-22 20:27 ` Michał Górny ` (2 more replies) 2018-03-22 21:47 ` Consus 2018-05-19 15:53 ` Consus 2 siblings, 3 replies; 42+ messages in thread From: James Le Cuirot @ 2018-03-22 20:17 UTC (permalink / raw To: gentoo-dev [-- Attachment #1: Type: text/plain, Size: 992 bytes --] On Thu, 22 Mar 2018 20:03:46 +0100 Michał Górny <mgorny@gentoo.org> wrote: > After 2+ years of repeating disagreements with Portage maintainer(s) > I have finally decided to fork Portage. My little fork uses technical > name of 'portage[mgorny]' [1] (to distinguish it from mainline Portage), > and aims to focus on cleaning up code and adding useful features with > less concern for infinite bug-by-bug compatibility. I hope you will continue with our efforts to drive regular Portage forwards too. It's been a long road but also very productive. I notice that your fork cannot be installed at the same time as regular Portage. I think this will really hinder any interest in it. As Gentoo developers, we obviously have to make sure things work with the official package manager and that goes for you too. Would it be possible for them to coexist? I'm not saying I'll try it though, just making a suggestion. :) -- James Le Cuirot (chewi) Gentoo Linux Developer [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 981 bytes --] ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [gentoo-dev] New Portage fork: sys-apps/portage-mgorny 2018-03-22 20:17 ` James Le Cuirot @ 2018-03-22 20:27 ` Michał Górny 2018-03-22 20:31 ` Zac Medico 2018-03-23 1:01 ` Herb Miller Jr. 2 siblings, 0 replies; 42+ messages in thread From: Michał Górny @ 2018-03-22 20:27 UTC (permalink / raw To: gentoo-dev W dniu czw, 22.03.2018 o godzinie 20∶17 +0000, użytkownik James Le Cuirot napisał: > On Thu, 22 Mar 2018 20:03:46 +0100 > Michał Górny <mgorny@gentoo.org> wrote: > > > After 2+ years of repeating disagreements with Portage maintainer(s) > > I have finally decided to fork Portage. My little fork uses technical > > name of 'portage[mgorny]' [1] (to distinguish it from mainline Portage), > > and aims to focus on cleaning up code and adding useful features with > > less concern for infinite bug-by-bug compatibility. > > I hope you will continue with our efforts to drive regular Portage > forwards too. It's been a long road but also very productive. > > I notice that your fork cannot be installed at the same time as regular > Portage. I think this will really hinder any interest in it. Making them co-installable would require creating divergent packages and eventually making a huge mess of almost-identical-but-different Python modules. It's not worth the effort, especially that the two projects are not that divergent. > As > Gentoo developers, we obviously have to make sure things work with the > official package manager and that goes for you too. Would it be > possible for them to coexist? I'm not saying I'll try it though, just > making a suggestion. :) As Gentoo developers, we have have to make sure things work with *all* package managers. That's why we have standards and policies. Unlike mainline Portage, portage[mgorny] follows those policies strictly and therefore any ebuild that works with it should also work with mainline Portage. -- Best regards, Michał Górny ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [gentoo-dev] New Portage fork: sys-apps/portage-mgorny 2018-03-22 20:17 ` James Le Cuirot 2018-03-22 20:27 ` Michał Górny @ 2018-03-22 20:31 ` Zac Medico 2018-03-23 1:01 ` Herb Miller Jr. 2 siblings, 0 replies; 42+ messages in thread From: Zac Medico @ 2018-03-22 20:31 UTC (permalink / raw To: gentoo-dev, James Le Cuirot [-- Attachment #1.1: Type: text/plain, Size: 1226 bytes --] On 03/22/2018 01:17 PM, James Le Cuirot wrote: > On Thu, 22 Mar 2018 20:03:46 +0100 > Michał Górny <mgorny@gentoo.org> wrote: > >> After 2+ years of repeating disagreements with Portage maintainer(s) >> I have finally decided to fork Portage. My little fork uses technical >> name of 'portage[mgorny]' [1] (to distinguish it from mainline Portage), >> and aims to focus on cleaning up code and adding useful features with >> less concern for infinite bug-by-bug compatibility. > > I hope you will continue with our efforts to drive regular Portage > forwards too. It's been a long road but also very productive. > > I notice that your fork cannot be installed at the same time as regular > Portage. I think this will really hinder any interest in it. As > Gentoo developers, we obviously have to make sure things work with the > official package manager and that goes for you too. Would it be > possible for them to coexist? I'm not saying I'll try it though, just > making a suggestion. :) > You can probably use the PATH/PYTHONPATH approach described here as long as support for that has not been eliminated: https://wiki.gentoo.org/wiki/Project:Portage#Testing_Portage -- Thanks, Zac [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 224 bytes --] ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [gentoo-dev] New Portage fork: sys-apps/portage-mgorny 2018-03-22 20:17 ` James Le Cuirot 2018-03-22 20:27 ` Michał Górny 2018-03-22 20:31 ` Zac Medico @ 2018-03-23 1:01 ` Herb Miller Jr. 2018-03-23 8:28 ` Michał Górny 2 siblings, 1 reply; 42+ messages in thread From: Herb Miller Jr. @ 2018-03-23 1:01 UTC (permalink / raw To: gentoo-dev@lists.gentoo.org On 03/22/2018 04:17 PM, James Le Cuirot wrote: > On Thu, 22 Mar 2018 20:03:46 +0100 > Michał Górny <mgorny@gentoo.org> wrote: > >> After 2+ years of repeating disagreements with Portage maintainer(s) >> I have finally decided to fork Portage. My little fork uses technical >> name of 'portage[mgorny]' [1] (to distinguish it from mainline Portage), >> and aims to focus on cleaning up code and adding useful features with >> less concern for infinite bug-by-bug compatibility. > I hope you will continue with our efforts to drive regular Portage > forwards too. It's been a long road but also very productive. > > I notice that your fork cannot be installed at the same time as regular > Portage. I think this will really hinder any interest in it. As > Gentoo developers, we obviously have to make sure things work with the > official package manager and that goes for you too. Would it be > possible for them to coexist? I'm not saying I'll try it though, just > making a suggestion. :) > Seems to also be blocked by other management tools such as perl-cleaner and haskell-updater. I'd love to take it for a spin if you have any suggestions on how to navigate the blocks. https://paste.pound-python.org/show/VxWWAGW9PpPCS3L4Q6Z3/ ---- Herb Miller Jr. ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [gentoo-dev] New Portage fork: sys-apps/portage-mgorny 2018-03-23 1:01 ` Herb Miller Jr. @ 2018-03-23 8:28 ` Michał Górny 0 siblings, 0 replies; 42+ messages in thread From: Michał Górny @ 2018-03-23 8:28 UTC (permalink / raw To: gentoo-dev W dniu pią, 23.03.2018 o godzinie 01∶01 +0000, użytkownik Herb Miller Jr. napisał: > On 03/22/2018 04:17 PM, James Le Cuirot wrote: > > On Thu, 22 Mar 2018 20:03:46 +0100 > > Michał Górny <mgorny@gentoo.org> wrote: > > > > > After 2+ years of repeating disagreements with Portage maintainer(s) > > > I have finally decided to fork Portage. My little fork uses technical > > > name of 'portage[mgorny]' [1] (to distinguish it from mainline Portage), > > > and aims to focus on cleaning up code and adding useful features with > > > less concern for infinite bug-by-bug compatibility. > > > > I hope you will continue with our efforts to drive regular Portage > > forwards too. It's been a long road but also very productive. > > > > I notice that your fork cannot be installed at the same time as regular > > Portage. I think this will really hinder any interest in it. As > > Gentoo developers, we obviously have to make sure things work with the > > official package manager and that goes for you too. Would it be > > possible for them to coexist? I'm not saying I'll try it though, just > > making a suggestion. :) > > > > Seems to also be blocked by other management tools such as perl-cleaner > and haskell-updater. I'd love to take it for a spin if you have any > suggestions on how to navigate the blocks. > > https://paste.pound-python.org/show/VxWWAGW9PpPCS3L4Q6Z3/ > The instructions covered that. You need to upgrade those packages to -r1. -- Best regards, Michał Górny ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [gentoo-dev] New Portage fork: sys-apps/portage-mgorny 2018-03-22 19:03 [gentoo-dev] New Portage fork: sys-apps/portage-mgorny Michał Górny 2018-03-22 20:17 ` James Le Cuirot @ 2018-03-22 21:47 ` Consus 2018-03-22 22:06 ` Michał Górny 2018-05-19 15:53 ` Consus 2 siblings, 1 reply; 42+ messages in thread From: Consus @ 2018-03-22 21:47 UTC (permalink / raw To: gentoo-dev On 20:03 Thu 22 Mar, Michał Górny wrote: > Hello, everyone. > > After 2+ years of repeating disagreements with Portage maintainer(s) > I have finally decided to fork Portage. My little fork uses technical > name of 'portage[mgorny]' [1] (to distinguish it from mainline Portage), > and aims to focus on cleaning up code and adding useful features with > less concern for infinite bug-by-bug compatibility. > > Detailed rationale in README [2]. Do you have any roadmap? ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [gentoo-dev] New Portage fork: sys-apps/portage-mgorny 2018-03-22 21:47 ` Consus @ 2018-03-22 22:06 ` Michał Górny 2018-03-22 22:52 ` Geaaru 2018-03-23 11:25 ` [gentoo-dev] " Consus 0 siblings, 2 replies; 42+ messages in thread From: Michał Górny @ 2018-03-22 22:06 UTC (permalink / raw To: gentoo-dev W dniu pią, 23.03.2018 o godzinie 00∶47 +0300, użytkownik Consus napisał: > On 20:03 Thu 22 Mar, Michał Górny wrote: > > Hello, everyone. > > > > After 2+ years of repeating disagreements with Portage maintainer(s) > > I have finally decided to fork Portage. My little fork uses technical > > name of 'portage[mgorny]' [1] (to distinguish it from mainline Portage), > > and aims to focus on cleaning up code and adding useful features with > > less concern for infinite bug-by-bug compatibility. > > > > Detailed rationale in README [2]. > > Do you have any roadmap? > No. Just a few general ideas. It's Portage, so I don't expect anything major to be able to happen. -- Best regards, Michał Górny ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [gentoo-dev] New Portage fork: sys-apps/portage-mgorny 2018-03-22 22:06 ` Michał Górny @ 2018-03-22 22:52 ` Geaaru 2018-03-22 23:22 ` Zac Medico ` (3 more replies) 2018-03-23 11:25 ` [gentoo-dev] " Consus 1 sibling, 4 replies; 42+ messages in thread From: Geaaru @ 2018-03-22 22:52 UTC (permalink / raw To: gentoo-dev [-- Attachment #1: Type: text/plain, Size: 1630 bytes --] Hi, a bit out of topic (sorry in advance) but connect to eventually new portage feature... for both portage and your fork I think that could be interesting add an extension to PMS for define inside profiles or targets masking of packages of a particular repslository. Currently PMS doesn't permit this but have this feature could be help users to define our profiles under overlays. Something like this: sys-devel/gcc::gentoo Currently this is permitted only under /etc/portage but for distro based of gentoo or others use cases share our profiles directly under overlay could permit an easy and elegant way to share our customizations. Unlucky this break specifications but I think that could be a fine new feature. wdyt? My cent. G. On Thu, Mar 22, 2018, 23:06 Michał Górny <mgorny@gentoo.org> wrote: > W dniu pią, 23.03.2018 o godzinie 00∶47 +0300, użytkownik Consus > napisał: > > On 20:03 Thu 22 Mar, Michał Górny wrote: > > > Hello, everyone. > > > > > > After 2+ years of repeating disagreements with Portage maintainer(s) > > > I have finally decided to fork Portage. My little fork uses technical > > > name of 'portage[mgorny]' [1] (to distinguish it from mainline > Portage), > > > and aims to focus on cleaning up code and adding useful features with > > > less concern for infinite bug-by-bug compatibility. > > > > > > Detailed rationale in README [2]. > > > > Do you have any roadmap? > > > > No. Just a few general ideas. It's Portage, so I don't expect anything > major to be able to happen. > > -- > Best regards, > Michał Górny > > > [-- Attachment #2: Type: text/html, Size: 2389 bytes --] ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [gentoo-dev] New Portage fork: sys-apps/portage-mgorny 2018-03-22 22:52 ` Geaaru @ 2018-03-22 23:22 ` Zac Medico 2018-03-23 8:31 ` Michał Górny ` (2 subsequent siblings) 3 siblings, 0 replies; 42+ messages in thread From: Zac Medico @ 2018-03-22 23:22 UTC (permalink / raw To: gentoo-dev, Geaaru [-- Attachment #1.1: Type: text/plain, Size: 930 bytes --] On 03/22/2018 03:52 PM, Geaaru wrote: > Hi, > > a bit out of topic (sorry in advance) but connect to eventually new > portage feature... > > for both portage and your fork I think that could be interesting add an > extension to PMS for define inside profiles or targets masking of > packages of a particular repslository. Currently PMS doesn't permit this > but have this feature could be help users to define our profiles under > overlays. > > Something like this: > > sys-devel/gcc::gentoo > > Currently this is permitted only under /etc/portage but for distro based > of gentoo or others use cases share our profiles directly under overlay > could permit an easy and elegant way to share our customizations. > > Unlucky this break specifications but I think that could be a fine new > feature. > > wdyt? > > My cent. > > G. Bug filed: https://bugs.gentoo.org/651208 -- Thanks, Zac [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 224 bytes --] ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [gentoo-dev] New Portage fork: sys-apps/portage-mgorny 2018-03-22 22:52 ` Geaaru 2018-03-22 23:22 ` Zac Medico @ 2018-03-23 8:31 ` Michał Górny 2018-03-23 9:48 ` Ulrich Mueller 2018-03-25 10:13 ` Vadim A. Misbakh-Soloviov 3 siblings, 0 replies; 42+ messages in thread From: Michał Górny @ 2018-03-23 8:31 UTC (permalink / raw To: gentoo-dev W dniu czw, 22.03.2018 o godzinie 22∶52 +0000, użytkownik Geaaru napisał: > Hi, > > a bit out of topic (sorry in advance) but connect to eventually new portage > feature... > > for both portage and your fork I think that could be interesting add an > extension to PMS for define inside profiles or targets masking of packages > of a particular repslository. Currently PMS doesn't permit this but have > this feature could be help users to define our profiles under overlays. > > Something like this: > > sys-devel/gcc::gentoo > > Currently this is permitted only under /etc/portage but for distro based of > gentoo or others use cases share our profiles directly under overlay could > permit an easy and elegant way to share our customizations. > > Unlucky this break specifications but I think that could be a fine new > feature. > > wdyt? Nope. Diverging from the specification is entirely against the goal of this fork. However, if mainline Portage supports that in non-spec- breaking fashion, I'm going to merge it. -- Best regards, Michał Górny ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [gentoo-dev] New Portage fork: sys-apps/portage-mgorny 2018-03-22 22:52 ` Geaaru 2018-03-22 23:22 ` Zac Medico 2018-03-23 8:31 ` Michał Górny @ 2018-03-23 9:48 ` Ulrich Mueller 2018-03-23 10:18 ` Francesco Riosa 2018-03-23 10:38 ` Roy Bamford 2018-03-25 10:13 ` Vadim A. Misbakh-Soloviov 3 siblings, 2 replies; 42+ messages in thread From: Ulrich Mueller @ 2018-03-23 9:48 UTC (permalink / raw To: gentoo-dev [-- Attachment #1: Type: text/plain, Size: 846 bytes --] >>>>> On Thu, 22 Mar 2018, Geaaru wrote: > for both portage and your fork I think that could be interesting add > an extension to PMS for define inside profiles or targets masking of > packages of a particular repslository. Currently PMS doesn't permit > this but have this feature could be help users to define our > profiles under overlays. > Something like this: > sys-devel/gcc::gentoo Conceptually that makes no sense. sys-devel/gcc is the name of an upstream package, so what does it even mean to mask it in one repository but not in another? If it's the same package, then it should behave in the same way, regardless of the repository its ebuild it hosted in (or the package being installed, in which case it is no longer in an ebuild repository). If it is a different package however, then it should have a different name. Ulrich [-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --] ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [gentoo-dev] New Portage fork: sys-apps/portage-mgorny 2018-03-23 9:48 ` Ulrich Mueller @ 2018-03-23 10:18 ` Francesco Riosa 2018-03-23 10:38 ` Franz Fellner 2018-03-23 10:53 ` Ulrich Mueller 2018-03-23 10:38 ` Roy Bamford 1 sibling, 2 replies; 42+ messages in thread From: Francesco Riosa @ 2018-03-23 10:18 UTC (permalink / raw To: gentoo-dev, Ulrich Mueller [-- Attachment #1.1: Type: text/plain, Size: 1353 bytes --] Il 23/03/2018 10:48, Ulrich Mueller ha scritto: >>>>>> On Thu, 22 Mar 2018, Geaaru wrote: >> for both portage and your fork I think that could be interesting add >> an extension to PMS for define inside profiles or targets masking of >> packages of a particular repslository. Currently PMS doesn't permit >> this but have this feature could be help users to define our >> profiles under overlays. >> Something like this: >> sys-devel/gcc::gentoo > Conceptually that makes no sense. sys-devel/gcc is the name of an > upstream package, so what does it even mean to mask it in one > repository but not in another? If it's the same package, then it > should behave in the same way, regardless of the repository its ebuild > it hosted in (or the package being installed, in which case it is no > longer in an ebuild repository). > > If it is a different package however, then it should have a different > name. Sorry to say it bluntly but this make no sense at all, even changing a USE flag make the package behave wildly differently. Once we agree that an upstream (complex enough) package may have different incarnations two ebuilds from different maintainers may please differently the user. I'm not sure this choice belong to profiles but not because same upstream correspond to same files on filesystem. > > Ulrich [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --] ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [gentoo-dev] New Portage fork: sys-apps/portage-mgorny 2018-03-23 10:18 ` Francesco Riosa @ 2018-03-23 10:38 ` Franz Fellner 2018-03-23 10:53 ` Ulrich Mueller 1 sibling, 0 replies; 42+ messages in thread From: Franz Fellner @ 2018-03-23 10:38 UTC (permalink / raw To: gentoo-dev [-- Attachment #1: Type: text/plain, Size: 1697 bytes --] The dlang repository offers a gcc ebuild that adds the patchset to build the gdc. It's behind a USE-Flag. Still it is exactly the same as sys-devel/gcc::gentoo besides the additional feature. But I don't think the dlang repo should mask gcc::gentoo. 2018-03-23 12:18 GMT+02:00 Francesco Riosa <vivo75@gmail.com>: > > > Il 23/03/2018 10:48, Ulrich Mueller ha scritto: > >>>>>> On Thu, 22 Mar 2018, Geaaru wrote: > >> for both portage and your fork I think that could be interesting add > >> an extension to PMS for define inside profiles or targets masking of > >> packages of a particular repslository. Currently PMS doesn't permit > >> this but have this feature could be help users to define our > >> profiles under overlays. > >> Something like this: > >> sys-devel/gcc::gentoo > > Conceptually that makes no sense. sys-devel/gcc is the name of an > > upstream package, so what does it even mean to mask it in one > > repository but not in another? If it's the same package, then it > > should behave in the same way, regardless of the repository its ebuild > > it hosted in (or the package being installed, in which case it is no > > longer in an ebuild repository). > > > > If it is a different package however, then it should have a different > > name. > Sorry to say it bluntly but this make no sense at all, even changing a > USE flag make the package behave wildly differently. > Once we agree that an upstream (complex enough) package may have > different incarnations two ebuilds from different maintainers may please > differently the user. > I'm not sure this choice belong to profiles but not because same > upstream correspond to same files on filesystem. > > > > > Ulrich > > > [-- Attachment #2: Type: text/html, Size: 2241 bytes --] ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [gentoo-dev] New Portage fork: sys-apps/portage-mgorny 2018-03-23 10:18 ` Francesco Riosa 2018-03-23 10:38 ` Franz Fellner @ 2018-03-23 10:53 ` Ulrich Mueller 2018-03-24 7:02 ` Kent Fredric 1 sibling, 1 reply; 42+ messages in thread From: Ulrich Mueller @ 2018-03-23 10:53 UTC (permalink / raw To: gentoo-dev [-- Attachment #1: Type: text/plain, Size: 1203 bytes --] >>>>> On Fri, 23 Mar 2018, Francesco Riosa wrote: > Il 23/03/2018 10:48, Ulrich Mueller ha scritto: >> Conceptually that makes no sense. sys-devel/gcc is the name of an >> upstream package, so what does it even mean to mask it in one >> repository but not in another? If it's the same package, then it >> should behave in the same way, regardless of the repository its >> ebuild it hosted in (or the package being installed, in which case >> it is no longer in an ebuild repository). >> If it is a different package however, then it should have a >> different name. > Sorry to say it bluntly but this make no sense at all, even changing > a USE flag make the package behave wildly differently. Right, So you want USE dependencies, which we have. Nothing stops a package in an overlay from having additional USE flags. > Once we agree that an upstream (complex enough) package may have > different incarnations two ebuilds from different maintainers may > please differently the user. Still, masking is the wrong way to express such preferences. If you package.mask sys-devel/gcc then you say that something is wrong with that package. Which I believe is not what you want to express here. Ulrich [-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --] ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [gentoo-dev] New Portage fork: sys-apps/portage-mgorny 2018-03-23 10:53 ` Ulrich Mueller @ 2018-03-24 7:02 ` Kent Fredric 2018-03-24 8:02 ` Michał Górny 0 siblings, 1 reply; 42+ messages in thread From: Kent Fredric @ 2018-03-24 7:02 UTC (permalink / raw To: gentoo-dev [-- Attachment #1: Type: text/plain, Size: 1584 bytes --] On Fri, 23 Mar 2018 11:53:40 +0100 Ulrich Mueller <ulm@gentoo.org> wrote: > Still, masking is the wrong way to express such preferences. If you > package.mask sys-devel/gcc then you say that something is wrong with > that package. Which I believe is not what you want to express here. I might have a better usecase for adding masks from overlays. But its more for the usecase of "there isn't something wrong with that package", but the more frequent usecase of "Portage is stupid and so we have masks to coerce the right behaviour" For example, if I had an overlay that's sole purpose was to test/transition experimental versions of Perl, where the presumption was that by installing said overlay, that you wished to upgrade to that version of Perl, it might make sense to employ masks to prevent portage doing dumb things. And by "Dumb things", I mean some of the common problems I see where portage tries to solve a blocker by downgrading Perl.... Its much simpler to just author a blacklist of "Look, these are things that are known to be a mess, don't even consider installing them, with a nice description of why this is nonsense" Trying to achieve it by any other means simply tempts the problem to reappear in another form, because everything *other* than package.mask will have portage try to flip the USE flag to try to make it work, and end up with people needing --backtrack=1000 and having it still not work. package.mask is at least a "look, we know this is nonsense, don't even explore this line of reasoning" blunt instrument. [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [gentoo-dev] New Portage fork: sys-apps/portage-mgorny 2018-03-24 7:02 ` Kent Fredric @ 2018-03-24 8:02 ` Michał Górny 2018-03-24 9:01 ` Kent Fredric 0 siblings, 1 reply; 42+ messages in thread From: Michał Górny @ 2018-03-24 8:02 UTC (permalink / raw To: gentoo-dev W dniu sob, 24.03.2018 o godzinie 20∶02 +1300, użytkownik Kent Fredric napisał: > On Fri, 23 Mar 2018 11:53:40 +0100 > Ulrich Mueller <ulm@gentoo.org> wrote: > > > Still, masking is the wrong way to express such preferences. If you > > package.mask sys-devel/gcc then you say that something is wrong with > > that package. Which I believe is not what you want to express here. > > I might have a better usecase for adding masks from overlays. > > But its more for the usecase of "there isn't something wrong with that > package", but the more frequent usecase of "Portage is stupid and so we > have masks to coerce the right behaviour" > > For example, if I had an overlay that's sole purpose was to > test/transition experimental versions of Perl, where the presumption > was that by installing said overlay, that you wished to upgrade to that > version of Perl, it might make sense to employ masks to prevent portage > doing dumb things. > > And by "Dumb things", I mean some of the common problems I see where > portage tries to solve a blocker by downgrading Perl.... > > Its much simpler to just author a blacklist of "Look, these are things > that are known to be a mess, don't even consider installing them, with > a nice description of why this is nonsense" > > Trying to achieve it by any other means simply tempts the problem to > reappear in another form, because everything *other* than package.mask > will have portage try to flip the USE flag to try to make it work, and > end up with people needing --backtrack=1000 and having it still not > work. > > package.mask is at least a "look, we know this is nonsense, don't even > explore this line of reasoning" blunt instrument. ...except that it is also used to say 'this is experimental version, unmask at will' and Portage wants to unmask stuff for you anyway. Well, I mean the default configuration of Portage, not mine. -- Best regards, Michał Górny ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [gentoo-dev] New Portage fork: sys-apps/portage-mgorny 2018-03-24 8:02 ` Michał Górny @ 2018-03-24 9:01 ` Kent Fredric 2018-03-24 12:54 ` Rich Freeman 2018-03-24 18:27 ` Zac Medico 0 siblings, 2 replies; 42+ messages in thread From: Kent Fredric @ 2018-03-24 9:01 UTC (permalink / raw To: gentoo-dev [-- Attachment #1: Type: text/plain, Size: 581 bytes --] On Sat, 24 Mar 2018 09:02:20 +0100 Michał Górny <mgorny@gentoo.org> wrote: > ...except that it is also used to say 'this is experimental version, > unmask at will' and Portage wants to unmask stuff for you anyway. Well, > I mean the default configuration of Portage, not mine. Yeah, that default I find incredibly stupid tbh. Auto-unmask use works nicely. Autounmask for package.mask and accept_keywords is just madness I'd love to see stopped. Its right up on my list of "portage doing ultra dumb stuff? Turn this off". I have it turned off in my defaults. [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [gentoo-dev] New Portage fork: sys-apps/portage-mgorny 2018-03-24 9:01 ` Kent Fredric @ 2018-03-24 12:54 ` Rich Freeman 2018-03-24 18:27 ` Zac Medico 1 sibling, 0 replies; 42+ messages in thread From: Rich Freeman @ 2018-03-24 12:54 UTC (permalink / raw To: gentoo-dev On Sat, Mar 24, 2018 at 5:01 AM, Kent Fredric <kentnl@gentoo.org> wrote: > On Sat, 24 Mar 2018 09:02:20 +0100 > Michał Górny <mgorny@gentoo.org> wrote: > >> ...except that it is also used to say 'this is experimental version, >> unmask at will' and Portage wants to unmask stuff for you anyway. Well, >> I mean the default configuration of Portage, not mine. > > Yeah, that default I find incredibly stupid tbh. > > Auto-unmask use works nicely. Autounmask for package.mask and > accept_keywords is just madness I'd love to see stopped. > It can be useful, though obviously I review what is proposed before merging the config changes. I wouldn't put masks and keywords in the same bucket. A mask typically means that something is known to cause problems, while missing keywords typically just means that it isn't known to work yet. People running mixed-keywords will find themselves accepting keywords a fair bit. -- Rich ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [gentoo-dev] New Portage fork: sys-apps/portage-mgorny 2018-03-24 9:01 ` Kent Fredric 2018-03-24 12:54 ` Rich Freeman @ 2018-03-24 18:27 ` Zac Medico 2018-03-24 20:33 ` Kent Fredric 1 sibling, 1 reply; 42+ messages in thread From: Zac Medico @ 2018-03-24 18:27 UTC (permalink / raw To: gentoo-dev, Kent Fredric [-- Attachment #1.1: Type: text/plain, Size: 914 bytes --] On 03/24/2018 02:01 AM, Kent Fredric wrote: > On Sat, 24 Mar 2018 09:02:20 +0100 > Michał Górny <mgorny@gentoo.org> wrote: > >> ...except that it is also used to say 'this is experimental version, >> unmask at will' and Portage wants to unmask stuff for you anyway. Well, >> I mean the default configuration of Portage, not mine. > > Yeah, that default I find incredibly stupid tbh. > > Auto-unmask use works nicely. Autounmask for package.mask and > accept_keywords is just madness I'd love to see stopped. > > Its right up on my list of "portage doing ultra dumb stuff? Turn this > off". > > I have it turned off in my defaults. The defaults certainly do not work perfectly in all situations. However, there are a vast number of situations where using --autounmask-continue will make appropriate package.mask changes without the need for any user intervention. -- Thanks, Zac [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 224 bytes --] ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [gentoo-dev] New Portage fork: sys-apps/portage-mgorny 2018-03-24 18:27 ` Zac Medico @ 2018-03-24 20:33 ` Kent Fredric 2018-03-24 20:44 ` Zac Medico 0 siblings, 1 reply; 42+ messages in thread From: Kent Fredric @ 2018-03-24 20:33 UTC (permalink / raw To: gentoo-dev [-- Attachment #1: Type: text/plain, Size: 715 bytes --] On Sat, 24 Mar 2018 11:27:20 -0700 Zac Medico <zmedico@gentoo.org> wrote: > The defaults certainly do not work perfectly in all situations. However, > there are a vast number of situations where using --autounmask-continue > will make appropriate package.mask changes without the need for any user > intervention. Its really handy for use flags. Its really handy for mixed arch/~arch where it promotes arch to ~arch as needed. Its really really bad however to have a default of accepting ** and package.unmask as a primary go-to solution. That default gets people using broken openssl and experimental packages blindly without them ever having intended on getting into experimental waters. [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [gentoo-dev] New Portage fork: sys-apps/portage-mgorny 2018-03-24 20:33 ` Kent Fredric @ 2018-03-24 20:44 ` Zac Medico 2018-03-25 2:26 ` Kent Fredric 0 siblings, 1 reply; 42+ messages in thread From: Zac Medico @ 2018-03-24 20:44 UTC (permalink / raw To: gentoo-dev, Kent Fredric [-- Attachment #1.1: Type: text/plain, Size: 1014 bytes --] On 03/24/2018 01:33 PM, Kent Fredric wrote: > On Sat, 24 Mar 2018 11:27:20 -0700 > Zac Medico <zmedico@gentoo.org> wrote: > >> The defaults certainly do not work perfectly in all situations. However, >> there are a vast number of situations where using --autounmask-continue >> will make appropriate package.mask changes without the need for any user >> intervention. > > Its really handy for use flags. > > Its really handy for mixed arch/~arch where it promotes arch to ~arch as needed. > > Its really really bad however to have a default of accepting ** and > package.unmask as a primary go-to solution. That only happens when dependency satisfaction fails by normal means. > That default gets people using broken openssl and experimental packages > blindly without them ever having intended on getting into experimental > waters. If people can't be bothered to understand the meaning of package.mask and keywords changes, should they really be using Gentoo? -- Thanks, Zac [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 224 bytes --] ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [gentoo-dev] New Portage fork: sys-apps/portage-mgorny 2018-03-24 20:44 ` Zac Medico @ 2018-03-25 2:26 ` Kent Fredric 2018-03-25 4:43 ` Zac Medico 0 siblings, 1 reply; 42+ messages in thread From: Kent Fredric @ 2018-03-25 2:26 UTC (permalink / raw To: gentoo-dev [-- Attachment #1: Type: text/plain, Size: 1445 bytes --] On Sat, 24 Mar 2018 13:44:49 -0700 Zac Medico <zmedico@gentoo.org> wrote: > That only happens when dependency satisfaction fails by normal means. And when that happens, it is better to bail and go "Uh oh, something bad", not "oh, right, lets install something that will likely make things worse and additional work to fix" Its a regular occurrence that we have to tell people about this on #gentoo. > > > That default gets people using broken openssl and experimental > > packages blindly without them ever having intended on getting into > > experimental waters. > > If people can't be bothered to understand the meaning of package.mask > and keywords changes, should they really be using Gentoo? And its not *entirely* true that this is the case. Toralf used to complain portage couldn't find a resoultion and would try unmasking insane stuff in the process of tinderboxing. But lo and behold, by removing the ability to unmask ** and package.mask, he reported a significant improvement in the ability to test. "RTFM?" is a terrible response to "you have bad defaults that make things break" because that default is *only* useful to people who would consider using things that have *zero* expectation that they would work. And that is not any majority demographic of the Gentoo user base. Its not a useless feature, but its a feature that should only be enabled after reading the documentation. [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [gentoo-dev] New Portage fork: sys-apps/portage-mgorny 2018-03-25 2:26 ` Kent Fredric @ 2018-03-25 4:43 ` Zac Medico 2018-03-25 9:02 ` Kent Fredric 0 siblings, 1 reply; 42+ messages in thread From: Zac Medico @ 2018-03-25 4:43 UTC (permalink / raw To: gentoo-dev, Kent Fredric [-- Attachment #1.1: Type: text/plain, Size: 2490 bytes --] On 03/24/2018 07:26 PM, Kent Fredric wrote: > On Sat, 24 Mar 2018 13:44:49 -0700 > Zac Medico <zmedico@gentoo.org> wrote: > >> That only happens when dependency satisfaction fails by normal means. > > And when that happens, it is better to bail and go "Uh oh, something bad", > not "oh, right, lets install something that will likely make things > worse and additional work to fix" I don't think it's possible to have defaults that satisfy everyone. My hope that the --autounmask default will be helpful to some people, and I advise people to use --autounmask=n if it's not helpful. > Its a regular occurrence that we have to tell people about this on #gentoo. Normally, it emerge shows a message like the following when it creates package.mask or ** keywords changes: NOTE: The --autounmask-keep-masks option will prevent emerge from creating package.unmask or ** keyword changes. >>> That default gets people using broken openssl and experimental >>> packages blindly without them ever having intended on getting into >>> experimental waters. >> >> If people can't be bothered to understand the meaning of package.mask >> and keywords changes, should they really be using Gentoo? > > And its not *entirely* true that this is the case. Toralf used to > complain portage couldn't find a resoultion and would try unmasking > insane stuff in the process of tinderboxing. > > But lo and behold, by removing the ability to unmask ** and > package.mask, he reported a significant improvement in the ability to > test. That's great. I really don't expect the default to work well in every situation. > "RTFM?" is a terrible response to "you have bad defaults that make > things break" because that default is *only* useful to people who would > consider using things that have *zero* expectation that they would work. The --autounmask behavior only triggers when a dependency is encountered that cannot be satisfied by normal means. So, it means that the user is already using masked packages, or they have expressed a desire to install a masked package. > And that is not any majority demographic of the Gentoo user base. > > Its not a useless feature, but its a feature that should only be > enabled after reading the documentation. But if the majority demographic is as you describe, then they shouldn't be using anything having dependencies that require package.unmask or ** keywords changes. -- Thanks, Zac [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 224 bytes --] ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [gentoo-dev] New Portage fork: sys-apps/portage-mgorny 2018-03-25 4:43 ` Zac Medico @ 2018-03-25 9:02 ` Kent Fredric 2018-03-26 7:48 ` Zac Medico 0 siblings, 1 reply; 42+ messages in thread From: Kent Fredric @ 2018-03-25 9:02 UTC (permalink / raw To: gentoo-dev [-- Attachment #1: Type: text/plain, Size: 1578 bytes --] On Sat, 24 Mar 2018 21:43:41 -0700 Zac Medico <zmedico@gentoo.org> wrote: > But if the majority demographic is as you describe, then they shouldn't > be using anything having dependencies that require package.unmask or ** > keywords changes. Again, they *dont*, the problem is portage makes the mistake of thinking they do. This happens especially around virtuals where there is an existing problem of portage not doing the right thing when perl-core/* exists in some definition. I don't have details on hand to give you as to how this happens, but I've seen this happen often enough around packages *I maintain* and *I* can't explain why portage is trying to install it, only that --auto-unmask-keep-masks=y makes the problem mysteriously go away. The question for me is not "auto unmask is good" vs "autounmask is bad", autounmask is fine on its own and is very useful. Its the default of --autounmask-keep-masks=n that I find short on value. If anything, I suggest there needs to be an --autounmask-keep-masks=conditional, or something, that narrows the range of solutions portage will try and only attempt to unmask ** or package.mask in the following conditions: - An explicitly masked package/version is explicitly requested on the command line. - A package is a direct dependency of of the above - As above, but for the world file That is, assume the only reason for masked packages to be considered is: - The user in some way directly requested them - A logical consequence of the user directly requesting a masked package [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [gentoo-dev] New Portage fork: sys-apps/portage-mgorny 2018-03-25 9:02 ` Kent Fredric @ 2018-03-26 7:48 ` Zac Medico 0 siblings, 0 replies; 42+ messages in thread From: Zac Medico @ 2018-03-26 7:48 UTC (permalink / raw To: gentoo-dev, Kent Fredric [-- Attachment #1.1: Type: text/plain, Size: 2033 bytes --] On 03/25/2018 02:02 AM, Kent Fredric wrote: > On Sat, 24 Mar 2018 21:43:41 -0700 > Zac Medico <zmedico@gentoo.org> wrote: > >> But if the majority demographic is as you describe, then they shouldn't >> be using anything having dependencies that require package.unmask or ** >> keywords changes. > > Again, they *dont*, the problem is portage makes the mistake of > thinking they do. > > This happens especially around virtuals where there is an existing > problem of portage not doing the right thing when perl-core/* exists in > some definition. > > I don't have details on hand to give you as to how this happens, > but I've seen this happen often enough around packages *I maintain* and > *I* can't explain why portage is trying to install it, only that > --auto-unmask-keep-masks=y makes the problem mysteriously go away. An issue like that involving REQUIRED_USE has been reported, and today I've created a patch that corrects the problem: https://bugs.gentoo.org/622462 > The question for me is not "auto unmask is good" vs "autounmask is > bad", autounmask is fine on its own and is very useful. > > Its the default of --autounmask-keep-masks=n that I find short on value. > > If anything, I suggest there needs to be an > --autounmask-keep-masks=conditional, or something, that narrows the > range of solutions portage will try and only attempt to unmask ** or > package.mask in the following conditions: > > - An explicitly masked package/version is explicitly requested on the command line. > - A package is a direct dependency of of the above > - As above, but for the world file > > That is, assume the only reason for masked packages to be considered is: > - The user in some way directly requested them > - A logical consequence of the user directly requesting a masked package It's possible that bug 622462 is not the only way to trigger this problem. If anyone experiences a problem like this, then a bug report would be appreciated. -- Thanks, Zac [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 224 bytes --] ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [gentoo-dev] New Portage fork: sys-apps/portage-mgorny 2018-03-23 9:48 ` Ulrich Mueller 2018-03-23 10:18 ` Francesco Riosa @ 2018-03-23 10:38 ` Roy Bamford 2018-03-23 10:59 ` Ulrich Mueller 1 sibling, 1 reply; 42+ messages in thread From: Roy Bamford @ 2018-03-23 10:38 UTC (permalink / raw To: gentoo-dev [-- Attachment #1: Type: text/plain, Size: 1698 bytes --] On 2018.03.23 09:48, Ulrich Mueller wrote: > >>>>> On Thu, 22 Mar 2018, Geaaru wrote: > > > for both portage and your fork I think that could be interesting add > > an extension to PMS for define inside profiles or targets masking of > > packages of a particular repslository. Currently PMS doesn't permit > > this but have this feature could be help users to define our > > profiles under overlays. > > > Something like this: > > > sys-devel/gcc::gentoo > > Conceptually that makes no sense. sys-devel/gcc is the name of an > upstream package, so what does it even mean to mask it in one > repository but not in another? If it's the same package, then it > should behave in the same way, regardless of the repository its ebuild > it hosted in (or the package being installed, in which case it is no > longer in an ebuild repository). > > If it is a different package however, then it should have a different > name. > > Ulrich > Ulrich, That has just irritated me. The use case is sdlmame. !!! The following installed packages are masked: - games-emulation/sdlmame-0.195::Pi_aarch64 (masked by: package.mask) /usr/portage/profiles/package.mask: # Pacho Ramos <pacho@gentoo.org> (18 Mar 2018) # Fails to build (#634662), version bump long time pending (#596162). # Removal in a month. games-emulation/sdlmame is masked. I have a higher version in my overlay than the one in the tree and it gets masked too. Its not a problem to me as I know how to manage it. Its just untidy. With apologies to Pacho for citing his name in the worked example. -- Regards, Roy Bamford (Neddyseagoon) a member of elections gentoo-ops forum-mods [-- Attachment #2: Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [gentoo-dev] New Portage fork: sys-apps/portage-mgorny 2018-03-23 10:38 ` Roy Bamford @ 2018-03-23 10:59 ` Ulrich Mueller 2018-03-23 13:27 ` Rich Freeman 0 siblings, 1 reply; 42+ messages in thread From: Ulrich Mueller @ 2018-03-23 10:59 UTC (permalink / raw To: gentoo-dev [-- Attachment #1: Type: text/plain, Size: 420 bytes --] >>>>> On Fri, 23 Mar 2018, Roy Bamford wrote: > games-emulation/sdlmame is masked. I have a higher version in my > overlay than the one in the tree and it gets masked too. > Its not a problem to me as I know how to manage it. Its just untidy. You still don't need a repository specific mask for this. Version specific masking and unmasking is entirely sufficient to express that the higher version is fine. Ulrich [-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --] ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [gentoo-dev] New Portage fork: sys-apps/portage-mgorny 2018-03-23 10:59 ` Ulrich Mueller @ 2018-03-23 13:27 ` Rich Freeman 2018-03-23 14:25 ` Arve Barsnes 2018-03-23 17:44 ` Patrick McLean 0 siblings, 2 replies; 42+ messages in thread From: Rich Freeman @ 2018-03-23 13:27 UTC (permalink / raw To: gentoo-dev On Fri, Mar 23, 2018 at 6:59 AM, Ulrich Mueller <ulm@gentoo.org> wrote: >>>>>> On Fri, 23 Mar 2018, Roy Bamford wrote: > >> games-emulation/sdlmame is masked. I have a higher version in my >> overlay than the one in the tree and it gets masked too. >> Its not a problem to me as I know how to manage it. Its just untidy. > > You still don't need a repository specific mask for this. Version > specific masking and unmasking is entirely sufficient to express that > the higher version is fine. > I think it would be best to step back from terms like "masking" and focus more on the intended behavior. It sounds to me that one of the intended behaviors is to tell portage that for a particular package we want to ignore a particular repository entirely. Suppose for example an overlay contains misc/foo-3, and the main repo introduces misc/foo-4. Perhaps we want portage to stick with foo-3 from the overlay. However, if the overlay adds foo-4, or foo-4.1 we want this installed. A version mask would not really cover this use case. IMO this sounds like a useful feature. Having it in profiles could probably also be useful in some testing scenarios, such as when making changes to a large number of packages that are already in the main tree (think something analogous to a feature branch in git, where the master branch continues to advance). Perhaps I'm misunderstanding the intent here, but I would suggest that we describe the end goal in emails like these otherwise people focus on the implementation details first. -- Rich ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [gentoo-dev] New Portage fork: sys-apps/portage-mgorny 2018-03-23 13:27 ` Rich Freeman @ 2018-03-23 14:25 ` Arve Barsnes 2018-03-23 16:20 ` Geaaru 2018-03-23 16:23 ` Patrick Steinhardt 2018-03-23 17:44 ` Patrick McLean 1 sibling, 2 replies; 42+ messages in thread From: Arve Barsnes @ 2018-03-23 14:25 UTC (permalink / raw To: gentoo-dev On 23 March 2018 at 14:27, Rich Freeman <rich0@gentoo.org> wrote: > It sounds to me that one of the intended behaviors is to tell portage > that for a particular package we want to ignore a particular > repository entirely. Suppose for example an overlay contains > misc/foo-3, and the main repo introduces misc/foo-4. Perhaps we want > portage to stick with foo-3 from the overlay. However, if the overlay > adds foo-4, or foo-4.1 we want this installed. A version mask would > not really cover this use case. > > IMO this sounds like a useful feature. Having it in profiles could > probably also be useful in some testing scenarios, such as when making > changes to a large number of packages that are already in the main > tree (think something analogous to a feature branch in git, where the > master branch continues to advance). Unless I'm misunderstanding, this is possible already in package.mask? If the mask is not permanent (for testing, as you mention), would there be any benefit in having it in profile instead? Putting misc/foo::gentoo in package.mask works fine either way. Probably <misc/foo-4::gentoo works as well, for your scenario above. I use this for the opposite scenario, I have */*::overlay in package.mask, and unmask only a particular package in package.unmask, to avoid bringing in a lot of overlay packages without having a particular need. Arve ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [gentoo-dev] New Portage fork: sys-apps/portage-mgorny 2018-03-23 14:25 ` Arve Barsnes @ 2018-03-23 16:20 ` Geaaru 2018-03-23 16:23 ` Patrick Steinhardt 1 sibling, 0 replies; 42+ messages in thread From: Geaaru @ 2018-03-23 16:20 UTC (permalink / raw To: gentoo-dev Hi guys, sys-devel/gcc::repos is only an example but from my side it is a real example. Currently, Sabayon use our gcc ebuild so it is needed mask gentoo version for rebuild sabayon-stage3 and now it is only possible (like other packages) through file (from sabayon side): /etc/portage/package.mask/00-sabayon.package.mask My idea is permit to define this mask rules under sabayon overlay as profile and/or as targets. Interesting idea is opposite scenario propose by Barsnes about block overlay packages. Thank you to all for feedback about this proposal. G. On Fri, 2018-03-23 at 15:25 +0100, Arve Barsnes wrote: > On 23 March 2018 at 14:27, Rich Freeman <rich0@gentoo.org> wrote: > > It sounds to me that one of the intended behaviors is to tell > > portage > > that for a particular package we want to ignore a particular > > repository entirely. Suppose for example an overlay contains > > misc/foo-3, and the main repo introduces misc/foo-4. Perhaps we > > want > > portage to stick with foo-3 from the overlay. However, if the > > overlay > > adds foo-4, or foo-4.1 we want this installed. A version mask > > would > > not really cover this use case. > > > > IMO this sounds like a useful feature. Having it in profiles could > > probably also be useful in some testing scenarios, such as when > > making > > changes to a large number of packages that are already in the main > > tree (think something analogous to a feature branch in git, where > > the > > master branch continues to advance). > > Unless I'm misunderstanding, this is possible already in > package.mask? > If the mask is not permanent (for testing, as you mention), would > there be any benefit in having it in profile instead? > > Putting misc/foo::gentoo in package.mask works fine either way. > Probably <misc/foo-4::gentoo works as well, for your scenario above. > > I use this for the opposite scenario, I have */*::overlay in > package.mask, and unmask only a particular package in package.unmask, > to avoid bringing in a lot of overlay packages without having a > particular need. > > Arve > ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [gentoo-dev] New Portage fork: sys-apps/portage-mgorny 2018-03-23 14:25 ` Arve Barsnes 2018-03-23 16:20 ` Geaaru @ 2018-03-23 16:23 ` Patrick Steinhardt 2018-03-23 20:16 ` Georgy Yakovlev 1 sibling, 1 reply; 42+ messages in thread From: Patrick Steinhardt @ 2018-03-23 16:23 UTC (permalink / raw To: gentoo-dev [-- Attachment #1: Type: text/plain, Size: 2458 bytes --] On Fri, Mar 23, 2018 at 03:25:12PM +0100, Arve Barsnes wrote: > On 23 March 2018 at 14:27, Rich Freeman <rich0@gentoo.org> wrote: > > It sounds to me that one of the intended behaviors is to tell portage > > that for a particular package we want to ignore a particular > > repository entirely. Suppose for example an overlay contains > > misc/foo-3, and the main repo introduces misc/foo-4. Perhaps we want > > portage to stick with foo-3 from the overlay. However, if the overlay > > adds foo-4, or foo-4.1 we want this installed. A version mask would > > not really cover this use case. > > > > IMO this sounds like a useful feature. Having it in profiles could > > probably also be useful in some testing scenarios, such as when making > > changes to a large number of packages that are already in the main > > tree (think something analogous to a feature branch in git, where the > > master branch continues to advance). > > Unless I'm misunderstanding, this is possible already in package.mask? > If the mask is not permanent (for testing, as you mention), would > there be any benefit in having it in profile instead? > > Putting misc/foo::gentoo in package.mask works fine either way. > Probably <misc/foo-4::gentoo works as well, for your scenario above. > > I use this for the opposite scenario, I have */*::overlay in > package.mask, and unmask only a particular package in package.unmask, > to avoid bringing in a lot of overlay packages without having a > particular need. > > Arve This wouldn't help the maintainers of overlays, though, and puts the burden on the user. One scenario where masks maintained in overlays would be useful is the musl overlay, which carries patches to various packages to have them compile with musl libc. Obviously, I always want to use packages provided by the musl overlay in case the same package from the Gentoo tree has build failures. Even if the Gentoo-provided package gets updated, I'll still want to use the older version from the musl tree, as the build errors are likely to still exist. If overlays were able to ignore packages from other repositories, the musl overlay could simply mask out packages from the Gentoo repository which are known to not compile on musl-based systems. Like this, the user does not have to maintain these masks manually, but they are already managed at a central place and updated with the musl repository. Patrick [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [gentoo-dev] New Portage fork: sys-apps/portage-mgorny 2018-03-23 16:23 ` Patrick Steinhardt @ 2018-03-23 20:16 ` Georgy Yakovlev 0 siblings, 0 replies; 42+ messages in thread From: Georgy Yakovlev @ 2018-03-23 20:16 UTC (permalink / raw To: gentoo-dev On Fri, 2018-03-23 at 16:23 +0000, Patrick Steinhardt wrote: > This wouldn't help the maintainers of overlays, though, and puts > the burden on the user. One scenario where masks maintained in > overlays would be useful is the musl overlay, which carries > patches to various packages to have them compile with musl libc. > Obviously, I always want to use packages provided by the musl > overlay in case the same package from the Gentoo tree has build > failures. Even if the Gentoo-provided package gets updated, I'll > still want to use the older version from the musl tree, as the > build errors are likely to still exist. > > If overlays were able to ignore packages from other repositories, > the musl overlay could simply mask out packages from the Gentoo > repository which are known to not compile on musl-based systems. > Like this, the user does not have to maintain these masks > manually, but they are already managed at a central place and > updated with the musl repository. > > Patrick It's currently possible to do with a sort-of-automated script in /etc/portage/repo.postsync.d i asked[1] ::musl about that and they do not want that. the script provided the issue is just an example, it should check which repo was just synced, also it does not care about versions, it just masks the versionless atom, there are no any sanity checks. it's just proof of concept. But I find it useful on my underpowered APU system which runs musl. I just want to avoid build failures, as each build takes a LOT of time. I would not run that on a workstation, I'd better bump instead and port the patches/ebuilds. running ::musl is an active commitment, and it often requires intervention and those should be contributed back if possible. [1]https://github.com/gentoo/musl/issues/110 -- Georgy ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [gentoo-dev] New Portage fork: sys-apps/portage-mgorny 2018-03-23 13:27 ` Rich Freeman 2018-03-23 14:25 ` Arve Barsnes @ 2018-03-23 17:44 ` Patrick McLean 2018-03-26 16:48 ` Thomas Deutschmann 1 sibling, 1 reply; 42+ messages in thread From: Patrick McLean @ 2018-03-23 17:44 UTC (permalink / raw To: gentoo-dev On 2018-03-23 06:27 AM, Rich Freeman wrote: > On Fri, Mar 23, 2018 at 6:59 AM, Ulrich Mueller <ulm@gentoo.org> wrote: >>>>>>> On Fri, 23 Mar 2018, Roy Bamford wrote: >> >>> games-emulation/sdlmame is masked. I have a higher version in my >>> overlay than the one in the tree and it gets masked too. >>> Its not a problem to me as I know how to manage it. Its just untidy. >> >> You still don't need a repository specific mask for this. Version >> specific masking and unmasking is entirely sufficient to express that >> the higher version is fine. >> > > It sounds to me that one of the intended behaviors is to tell portage > that for a particular package we want to ignore a particular > repository entirely. Suppose for example an overlay contains > misc/foo-3, and the main repo introduces misc/foo-4. Perhaps we want > portage to stick with foo-3 from the overlay. However, if the overlay > adds foo-4, or foo-4.1 we want this installed. A version mask would > not really cover this use case. > > IMO this sounds like a useful feature. Having it in profiles could > probably also be useful in some testing scenarios, such as when making > changes to a large number of packages that are already in the main > tree (think something analogous to a feature branch in git, where the > master branch continues to advance).> > Perhaps I'm misunderstanding the intent here, but I would suggest that > we describe the end goal in emails like these otherwise people focus > on the implementation details first. > Having the ability to specify a repository in atoms in profile is very useful to people who have large overlays and make heavy use of profiles. At my (and zmedico's) employer we use Gentoo heavily (all of our servers run it), and have a few large internal overlays and hundreds of internal profiles. There are packages in upstream Gentoo that we maintain an internal fork of, and it would be extremely useful if we could mask the ::gentoo version of something so a version bump does not cause it to be installed instead of our forked version. To address ulm's comments, we want our internal fork to satisfy dependencies in ::gentoo for the package without having to fork dozens of ebuilds. Generally the forks are just for minor changes that do not break dependency compatibility, but do something that we need for whatever reason. In case there are questions about why we have hundreds of profiles, we use profile to define machine roles. Each internal machine type or role has a profile in one of our internal repositories. This allows us to manipulate USE flags, packages etc in each machine type with a fair bit of fine-grained control. Adding repository support to profile atoms will give us even more control, and having fine grained control over what we have on our servers is the main reason we run Gentoo. ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [gentoo-dev] New Portage fork: sys-apps/portage-mgorny 2018-03-23 17:44 ` Patrick McLean @ 2018-03-26 16:48 ` Thomas Deutschmann 2018-03-26 18:36 ` Zac Medico 0 siblings, 1 reply; 42+ messages in thread From: Thomas Deutschmann @ 2018-03-26 16:48 UTC (permalink / raw To: gentoo-dev [-- Attachment #1.1: Type: text/plain, Size: 850 bytes --] On 2018-03-23 18:44, Patrick McLean wrote: > At my (and zmedico's) employer we use Gentoo heavily (all of our servers > run it), and have a few large internal overlays and hundreds of internal > profiles. There are packages in upstream Gentoo that we maintain an > internal fork of, and it would be extremely useful if we could mask the > ::gentoo version of something so a version bump does not cause it to be > installed instead of our forked version. I have the same need, but it works for me: I have several packages in /etc/portage/package.mask directory with content like <cat>/<pkg>::gentoo to make sure the package from Gentoo repository isn't used. But I guess you are talking about a different thing? -- Regards, Thomas Deutschmann / Gentoo Linux Developer C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5 [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 981 bytes --] ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [gentoo-dev] New Portage fork: sys-apps/portage-mgorny 2018-03-26 16:48 ` Thomas Deutschmann @ 2018-03-26 18:36 ` Zac Medico 0 siblings, 0 replies; 42+ messages in thread From: Zac Medico @ 2018-03-26 18:36 UTC (permalink / raw To: gentoo-dev, Thomas Deutschmann [-- Attachment #1.1: Type: text/plain, Size: 1071 bytes --] On 03/26/2018 09:48 AM, Thomas Deutschmann wrote: > On 2018-03-23 18:44, Patrick McLean wrote: >> At my (and zmedico's) employer we use Gentoo heavily (all of our servers >> run it), and have a few large internal overlays and hundreds of internal >> profiles. There are packages in upstream Gentoo that we maintain an >> internal fork of, and it would be extremely useful if we could mask the >> ::gentoo version of something so a version bump does not cause it to be >> installed instead of our forked version. > > I have the same need, but it works for me: I have several packages in > /etc/portage/package.mask directory with content like > > <cat>/<pkg>::gentoo > > to make sure the package from Gentoo repository isn't used. > > But I guess you are talking about a different thing? The issue is that people are using profiles hosted in repositories other than gentoo, complete with profiles.desc entries (eselect profile supports this), and they would like to have the ability to use ::repo atoms in these profiles. -- Thanks, Zac [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 224 bytes --] ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [gentoo-dev] New Portage fork: sys-apps/portage-mgorny 2018-03-22 22:52 ` Geaaru ` (2 preceding siblings ...) 2018-03-23 9:48 ` Ulrich Mueller @ 2018-03-25 10:13 ` Vadim A. Misbakh-Soloviov 2018-03-28 4:42 ` [gentoo-dev] " Duncan 3 siblings, 1 reply; 42+ messages in thread From: Vadim A. Misbakh-Soloviov @ 2018-03-25 10:13 UTC (permalink / raw To: gentoo-dev Well, in *my* opinion, in turn, having possibility to {R,}DEPEND on package from exact repo is much and much more needed functionality. Say, I have pkg2 in my repo, that depends on pkg1, which is in my repo too. Then, I (or user) add other repo having pkg1 too. Or, say, gentoo maintainers bump pkg1 to a newer version (while I'm slacking a bit). And my pkg1 is a bit different from gentoo's (let it be patchset, or, say, lua.eclass support for lua overlay). So, that changes results in random unexpected behaviour as blocks, runtime breakage and so on. And renaming all the packages to not collide with gentoo/other repos naming is, well, not an option, I think. Or, another example: I making pkg4 in my repo1, which depends on pkg3 from repo2 (where I 100% sure it fits all the requirements and the patchsets), while pkg3 in ::gentoo doesn't (and it can even have a bug about that opened for a century already). Currently, it is no way to say "only dep-pkg from that exact repo is 100% works as expected", so there is still the chance, that someday pkg4 would fail to build because suddenly pkg3 was reinstalled from another "incompatible" repo... And, honestly, current ways to resolve that issue (adding dummy-useflags, copy_here&rename, and so on) looks as very dirty hacks. ^ permalink raw reply [flat|nested] 42+ messages in thread
* [gentoo-dev] Re: New Portage fork: sys-apps/portage-mgorny 2018-03-25 10:13 ` Vadim A. Misbakh-Soloviov @ 2018-03-28 4:42 ` Duncan 0 siblings, 0 replies; 42+ messages in thread From: Duncan @ 2018-03-28 4:42 UTC (permalink / raw To: gentoo-dev Vadim A. Misbakh-Soloviov posted on Sun, 25 Mar 2018 17:13:28 +0700 as excerpted: > Well, in *my* opinion, in turn, having possibility to {R,}DEPEND on > package from exact repo is much and much more needed functionality. > > Say, I have pkg2 in my repo, that depends on pkg1, which is in my repo > too. Then, I (or user) add other repo having pkg1 too. Or, say, gentoo > maintainers bump pkg1 to a newer version (while I'm slacking a bit). > And my pkg1 is a bit different from gentoo's (let it be patchset, or, > say, lua.eclass support for lua overlay). > > So, that changes results in random unexpected behaviour as blocks, > runtime breakage and so on. > Currently, it is no way to say "only dep-pkg from that exact repo is > 100% works as expected", so there is still the chance, that someday pkg4 > would fail to build because suddenly pkg3 was reinstalled from another > "incompatible" repo... > And, honestly, current ways to resolve that issue (adding > dummy-useflags, copy_here&rename, and so on) looks as very dirty hacks. [Note that while the following is written using second-person "you", nothing personal or accusatory intended. I simply started with second person and then realized half way thru that because it was written in second person it could be taken as offensive, which wasn't my intent, but didn't want to go back and adjust the whole thing to detached third-party viewpoint just to keep the technical point I had already made, so I chose the disclaimer method instead. And as a second disclaimer, please see the last paragraph; maybe I'm missing the obvious...] Actually, I'd argue that the problem as described is well within what USE flags are designed for, and that using a USE flag in this case makes /perfect/ sense. Consider the description above: * pkg2 deps on pkg1, both of which are in your repo. * But your pkg1 is different in some way, custom patch set, say, or lua eclass support from its overlay. * Your pkg2 deps on that difference. Seems a perfect match for USE flag deps to me. Make your pkg2 dep on pkg1 conditional on a USE flag added to pkg1 when you changed it from what's likely to appear in gentoo or another overlay, making that change in behavior conditional on the USE flag and setting it up so flag-missing behavior is -flag. Problem solved. That creates an optional change in behavior toggled by a USE flag, and makes some other package dependent on that option by depending on that USE flag. Isn't that exactly what USE flags and USE flag deps are /supposed/ to do? Of course that pre-supposes that you want to go to all the work of doing it /correctly/ and making your change fully optional and togglable by individual per-package USE flags and deps that fit the individual cases, instead of taking the hacky shortcut of simply hard-coding your copy to do it your way, but "dummy USE flags" that do nothing but control the repo, because the behavior is hardcoded instead of setup via actually togglable USE flag aren't any more hacky than that hard-coding that makes them required in the first place. It's really just part of the same hack, and if you're satisfied with the hacky hardcoded shortcut, it seems you should be satisfied with the hacky USE flag to make it work because you hardcoded the behavior as a shortcut instead of making it properly togglable, as well. But if you /do/ want to simply take the expedient route and do hacks such as hardcoding choices (hey, I've taken the hardcoded behavior shortcut myself a few times) etc, and you're doing it pretty much globally, affecting many otherwise independent things thru the entire overlay, then it would seem to me that the most efficient method would be to simply do the fake-flag (call it overlayname-hardcoded or some such, obviously replacing overlayname as appropriate) hack by policy, adding it to your global USE flag settings in make.conf, and to every package as soon as you add it to your overlay. Then you can depend on the flag as necessary, without having to worry about what it does in an individual package. Tho even that's actually pretty comparable to how users work with global USE flags. And if it's named overlayname-hardcoded or similar, you /are/ actually describing the USE flag, and how you're using it in the deps, reasonably accurately, even if there's no actual option to turn it off in the packages in your overlay. ... Tho it's quite possible there's holes in this argument that I'm simply not seeing, thus making my posting as much or more about asking others to point out the holes I can't see, so I /can/ see them, as it is about attempting to convince anyone of the correctness of my viewpoint as I'm posting it. Sure I could be wrong, but if I am, please point it out so I can see it too! =:^) -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [gentoo-dev] New Portage fork: sys-apps/portage-mgorny 2018-03-22 22:06 ` Michał Górny 2018-03-22 22:52 ` Geaaru @ 2018-03-23 11:25 ` Consus 1 sibling, 0 replies; 42+ messages in thread From: Consus @ 2018-03-23 11:25 UTC (permalink / raw To: gentoo-dev On 23:06 Thu 22 Mar, Michał Górny wrote: > No. Just a few general ideas. It's Portage, so I don't expect anything > major to be able to happen. Is it possible to slowly migrate parts of sys-apps/portage to portage-utils? I really like portage-utils's approach to make things easier and modular. Also it's damn fast. ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [gentoo-dev] New Portage fork: sys-apps/portage-mgorny 2018-03-22 19:03 [gentoo-dev] New Portage fork: sys-apps/portage-mgorny Michał Górny 2018-03-22 20:17 ` James Le Cuirot 2018-03-22 21:47 ` Consus @ 2018-05-19 15:53 ` Consus 2018-05-22 20:35 ` Michał Górny 2 siblings, 1 reply; 42+ messages in thread From: Consus @ 2018-05-19 15:53 UTC (permalink / raw To: gentoo-dev Okay, this https://github.com/mgorny/portage-mgorny/issues/15 is a goddamn piece of sanity that Portage requires for a long time and and it worth some $20 donations. Where to send moneyz? ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [gentoo-dev] New Portage fork: sys-apps/portage-mgorny 2018-05-19 15:53 ` Consus @ 2018-05-22 20:35 ` Michał Górny 2018-05-28 2:45 ` Richard Yao 0 siblings, 1 reply; 42+ messages in thread From: Michał Górny @ 2018-05-22 20:35 UTC (permalink / raw To: gentoo-dev W dniu sob, 19.05.2018 o godzinie 18∶53 +0300, użytkownik Consus napisał: > Okay, this > > https://github.com/mgorny/portage-mgorny/issues/15 > > is a goddamn piece of sanity that Portage requires for a long time and > and it worth some $20 donations. Where to send moneyz? > Thanks. However, this really isn't something that deserves money. I'm pretty sure you'll find a better use for it. -- Best regards, Michał Górny ^ permalink raw reply [flat|nested] 42+ messages in thread
* Re: [gentoo-dev] New Portage fork: sys-apps/portage-mgorny 2018-05-22 20:35 ` Michał Górny @ 2018-05-28 2:45 ` Richard Yao 0 siblings, 0 replies; 42+ messages in thread From: Richard Yao @ 2018-05-28 2:45 UTC (permalink / raw To: gentoo-dev > On May 22, 2018, at 4:35 PM, Michał Górny <mgorny@gentoo.org> wrote: > > W dniu sob, 19.05.2018 o godzinie 18∶53 +0300, użytkownik Consus > napisał: >> Okay, this >> >> https://github.com/mgorny/portage-mgorny/issues/15 >> >> is a goddamn piece of sanity that Portage requires for a long time and >> and it worth some $20 donations. Where to send moneyz? >> > > Thanks. However, this really isn't something that deserves money. I'm > pretty sure you'll find a better use for it. I suggest that you make an amazon wishlist and let people buy you things from there. Put some books on it that would be useful for development. > > -- > Best regards, > Michał Górny > > ^ permalink raw reply [flat|nested] 42+ messages in thread
end of thread, other threads:[~2018-05-28 2:45 UTC | newest] Thread overview: 42+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2018-03-22 19:03 [gentoo-dev] New Portage fork: sys-apps/portage-mgorny Michał Górny 2018-03-22 20:17 ` James Le Cuirot 2018-03-22 20:27 ` Michał Górny 2018-03-22 20:31 ` Zac Medico 2018-03-23 1:01 ` Herb Miller Jr. 2018-03-23 8:28 ` Michał Górny 2018-03-22 21:47 ` Consus 2018-03-22 22:06 ` Michał Górny 2018-03-22 22:52 ` Geaaru 2018-03-22 23:22 ` Zac Medico 2018-03-23 8:31 ` Michał Górny 2018-03-23 9:48 ` Ulrich Mueller 2018-03-23 10:18 ` Francesco Riosa 2018-03-23 10:38 ` Franz Fellner 2018-03-23 10:53 ` Ulrich Mueller 2018-03-24 7:02 ` Kent Fredric 2018-03-24 8:02 ` Michał Górny 2018-03-24 9:01 ` Kent Fredric 2018-03-24 12:54 ` Rich Freeman 2018-03-24 18:27 ` Zac Medico 2018-03-24 20:33 ` Kent Fredric 2018-03-24 20:44 ` Zac Medico 2018-03-25 2:26 ` Kent Fredric 2018-03-25 4:43 ` Zac Medico 2018-03-25 9:02 ` Kent Fredric 2018-03-26 7:48 ` Zac Medico 2018-03-23 10:38 ` Roy Bamford 2018-03-23 10:59 ` Ulrich Mueller 2018-03-23 13:27 ` Rich Freeman 2018-03-23 14:25 ` Arve Barsnes 2018-03-23 16:20 ` Geaaru 2018-03-23 16:23 ` Patrick Steinhardt 2018-03-23 20:16 ` Georgy Yakovlev 2018-03-23 17:44 ` Patrick McLean 2018-03-26 16:48 ` Thomas Deutschmann 2018-03-26 18:36 ` Zac Medico 2018-03-25 10:13 ` Vadim A. Misbakh-Soloviov 2018-03-28 4:42 ` [gentoo-dev] " Duncan 2018-03-23 11:25 ` [gentoo-dev] " Consus 2018-05-19 15:53 ` Consus 2018-05-22 20:35 ` Michał Górny 2018-05-28 2:45 ` Richard Yao
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox