Re: [gentoo-dev] Some packages up for grabs
On 12/12/2012 05:54 PM, Michael Weber wrote: > On 12/12/2012 06:21 PM, Matthew Thode wrote: >> I'll take net-misc/radvd > Welcome, co-maintainer ;-) > > > ya, I say you in the metadata :P -- -- Matthew Thode (prometheanfire) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Some packages up for grabs
On 12/12/2012 06:21 PM, Matthew Thode wrote: > I'll take net-misc/radvd Welcome, co-maintainer ;-) -- Michael Weber Gentoo Developer
Re: [gentoo-dev] Permission to add a dummy package in tree
On Wed, Dec 12, 2012 at 7:38 PM, Diego Elio Pettenò wrote: > On 12/12/2012 19:07, Theo Chatzimichos wrote: >> It would be preferred to move that package in tree though. > > I don't like it. Please use an overlay to test this kind of stuff, thanks. Thank you all for the feedback, I won't proceed. Theo
Re: [gentoo-dev] Permission to add a dummy package in tree
On Wed, Dec 12, 2012 at 1:17 PM, Theo Chatzimichos wrote: > If there are more dummy packages then a separate category seems good > idea (and thanks for that), but if mine is the only case then i don't > see a reason for that I'd prefer to not see a bunch of these, but having a single dummy package in portage doesn't really seem like a bad thing. Diego suggested using an overlay instead. If you don't want to deal with overlay logic another option might be to just make a replica of the whole tree and host that somewhere else and just point to it for syncing. Then you can do anything you want to anything in the "tree." Rich
Re: [gentoo-dev] Permission to add a dummy package in tree
On 12/12/2012 19:07, Theo Chatzimichos wrote: > It would be preferred to move that package in tree though. I don't like it. Please use an overlay to test this kind of stuff, thanks. -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
Re: [gentoo-dev] Permission to add a dummy package in tree
On Wed, 12 Dec 2012 19:17:32 +0100 Theo Chatzimichos wrote: > On Wed, Dec 12, 2012 at 7:14 PM, Michał Górny wrote: > > On Wed, 12 Dec 2012 19:07:09 +0100 > > Theo Chatzimichos wrote: > > > >> these days I am working on a puppet module for portage. For testing I > >> have created a dummy package which can be found here [1]. The package > >> installs files based on useflags, and it comes in stable, testing and > >> hardmasked versions, plus it has some useflag changes between > >> versions. With this package I can make sure that the puppet provider > >> does its various operations fine. I'm about to start writing unit > >> tests for that provider, and I would like to use that package for the > >> testing. It would be preferred to move that package in tree though. > >> Since the ebuilds are useless for everybody else, and maybe violate > >> policy about the stable tree, I'd like to know if there are any > >> objections to move it to tree. If there are none, I'll move it in one > >> month > >> > >> [1] https://github.com/gentoo-el/overlay/tree/master/app-misc/dummy > > > > To be honest, I don't mind having dummy packages in the tree. I would > > be happy to convert gentoopm sometime to use them instead of relying on > > random packages to match its criteria. > > > > However, I'd rather see them in a special category, and preferably > > prefixed with 'gentoo-' to make it least possible for any kind of name > > collisions. > > > > -- > > Best regards, > > Michał Górny > > > If there are more dummy packages then a separate category seems good > idea (and thanks for that), but if mine is the only case then i don't > see a reason for that Well, my main goal here is to clearly keep the package split from 'meaningful' packages. So if I listed app-misc/ for no good reason, I shall not see this package. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] Permission to add a dummy package in tree
On Wed, Dec 12, 2012 at 7:14 PM, Michał Górny wrote: > On Wed, 12 Dec 2012 19:07:09 +0100 > Theo Chatzimichos wrote: > >> these days I am working on a puppet module for portage. For testing I >> have created a dummy package which can be found here [1]. The package >> installs files based on useflags, and it comes in stable, testing and >> hardmasked versions, plus it has some useflag changes between >> versions. With this package I can make sure that the puppet provider >> does its various operations fine. I'm about to start writing unit >> tests for that provider, and I would like to use that package for the >> testing. It would be preferred to move that package in tree though. >> Since the ebuilds are useless for everybody else, and maybe violate >> policy about the stable tree, I'd like to know if there are any >> objections to move it to tree. If there are none, I'll move it in one >> month >> >> [1] https://github.com/gentoo-el/overlay/tree/master/app-misc/dummy > > To be honest, I don't mind having dummy packages in the tree. I would > be happy to convert gentoopm sometime to use them instead of relying on > random packages to match its criteria. > > However, I'd rather see them in a special category, and preferably > prefixed with 'gentoo-' to make it least possible for any kind of name > collisions. > > -- > Best regards, > Michał Górny If there are more dummy packages then a separate category seems good idea (and thanks for that), but if mine is the only case then i don't see a reason for that Theo
Re: [gentoo-dev] Permission to add a dummy package in tree
On Wed, 12 Dec 2012 19:07:09 +0100 Theo Chatzimichos wrote: > these days I am working on a puppet module for portage. For testing I > have created a dummy package which can be found here [1]. The package > installs files based on useflags, and it comes in stable, testing and > hardmasked versions, plus it has some useflag changes between > versions. With this package I can make sure that the puppet provider > does its various operations fine. I'm about to start writing unit > tests for that provider, and I would like to use that package for the > testing. It would be preferred to move that package in tree though. > Since the ebuilds are useless for everybody else, and maybe violate > policy about the stable tree, I'd like to know if there are any > objections to move it to tree. If there are none, I'll move it in one > month > > [1] https://github.com/gentoo-el/overlay/tree/master/app-misc/dummy To be honest, I don't mind having dummy packages in the tree. I would be happy to convert gentoopm sometime to use them instead of relying on random packages to match its criteria. However, I'd rather see them in a special category, and preferably prefixed with 'gentoo-' to make it least possible for any kind of name collisions. -- Best regards, Michał Górny signature.asc Description: PGP signature
[gentoo-dev] Permission to add a dummy package in tree
Hello, these days I am working on a puppet module for portage. For testing I have created a dummy package which can be found here [1]. The package installs files based on useflags, and it comes in stable, testing and hardmasked versions, plus it has some useflag changes between versions. With this package I can make sure that the puppet provider does its various operations fine. I'm about to start writing unit tests for that provider, and I would like to use that package for the testing. It would be preferred to move that package in tree though. Since the ebuilds are useless for everybody else, and maybe violate policy about the stable tree, I'd like to know if there are any objections to move it to tree. If there are none, I'll move it in one month [1] https://github.com/gentoo-el/overlay/tree/master/app-misc/dummy Theo
Re: [gentoo-dev] Some packages up for grabs
On 12/01/2012 03:59 AM, Wolfram Schlich wrote: > Hi! > > Feel free to take care of the following packages that I used to > maintain a while ago but don't anymore due to change of interest: > > - RAID controller utils: > > sys-block/afacli (older Adaptec) > sys-block/dellmgr (older Dell-branded LSI MegaRAID) > sys-block/hpacucli(HP/Compaq Smart Array) > sys-block/lsiutil (LSI MegaRAID) > sys-block/megacli (LSI MegaRAID) > sys-block/megactl (LSI MegaRAID) > sys-block/megamgr (LSI MegaRAID) > sys-block/megarc (LSI MegaRAID) > sys-block/tw_cli (3ware) > > - Other packages: > > app-arch/afio > app-misc/digitemp > app-text/utrac > dev-db/maatkit > dev-db/mysql-proxy > dev-libs/cyberjack > dev-util/sel > media-gfx/dcraw > net-analyzer/nmbscan > net-analyzer/portbunny > net-dns/fpdns > net-misc/radvd > net-misc/wol > sys-block/spindown > sys-fs/inotify-tools > sys-fs/owfs > sys-process/fcron > > If you're interested in any of these, just contact me directly. > > Thanks! > > Cheers, > Wolfram > I'll take net-misc/radvd -- -- Matthew Thode (prometheanfire) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Some packages up for grabs
* Diego Elio Pettenò [2012-12-01 21:31]: > On 01/12/2012 01:59, Wolfram Schlich wrote: > > - RAID controller utils: > > Maybe we should add sysadmin herd as fallback for these? +1 from me. Anyone from the sysadmin herd speaking up (for or against it)? :) > > sys-block/hpacucli (HP/Compaq Smart Array) > > This one I can help with in the immediate future since I have a couple > of servers needing it at work. > > > sys-process/fcron > > This one I'll take care of (I'm already in metadata). Great! :) Cheers, Wolfram
Re: [gentoo-dev] Some packages up for grabs
Hey Jesus! * Jesus Rivero (Neurogeek) [2012-12-01 15:43]: > On Dec 1, 2012 5:01 AM, "Wolfram Schlich" wrote: > > > > Hi! > > > > Feel free to take care of the following packages that I used to > > maintain a while ago but don't anymore due to change of interest: > > > > sys-block/tw_cli(3ware) > > dev-db/mysql-proxy > > [...] > > I'll take these. Great, thanks :) Cheers, Wolfram
Re: [gentoo-dev] Getting EAPI 5 *use.stable.mask to work in gx86?
On 12/12/2012 01:32 AM, Michał Górny wrote: > On Tue, 11 Dec 2012 16:44:25 -0800 > Zac Medico wrote: > >> On 12/11/2012 01:45 PM, Michał Górny wrote: >>> On Mon, 10 Dec 2012 22:35:07 -0800 >>> Zac Medico wrote: >>> On 12/10/2012 01:27 PM, Michał Górny wrote: > 1) duplicate most of the major profiles. Make an EAPI 5-enabled wrapper > profiles which will provide the *use.stable.mask files. Require users > to migrate to those profiles after getting an EAPI 5 capable package > manager (how?). Possibly mask the relevant flags completely in other > profiles. I think this is the obvious solution. You can make users migrate by adding "deprecated" files to the old profiles. >>> >>> To be honest, I don't see much benefit from it compared to not having >>> the *stable.use.mask files at all and just adding separate stable >>> profiles. >> >> The main use case for *use.stable.mask that I'm aware of is that it's >> handy for masking flags to pass repoman checks. For example, >> sys-apps/portage could use it for the pypy1_9 flag. Otherwise, we have >> to mask that flag for a given portage version before we can add stable >> keywords. > > Yes, and having 'stable' and 'unstable' profiles will work just > the same. Except for the fact that it will be a bit cleaner, not require > EAPI=5 at all and probably make arch testing a bit easier for a few > people. Sounds good to me. -- Thanks, Zac
Re: [gentoo-dev] Getting EAPI 5 *use.stable.mask to work in gx86?
On Tue, 11 Dec 2012 16:44:25 -0800 Zac Medico wrote: > On 12/11/2012 01:45 PM, Michał Górny wrote: > > On Mon, 10 Dec 2012 22:35:07 -0800 > > Zac Medico wrote: > > > >> On 12/10/2012 01:27 PM, Michał Górny wrote: > >>> 1) duplicate most of the major profiles. Make an EAPI 5-enabled wrapper > >>> profiles which will provide the *use.stable.mask files. Require users > >>> to migrate to those profiles after getting an EAPI 5 capable package > >>> manager (how?). Possibly mask the relevant flags completely in other > >>> profiles. > >> > >> I think this is the obvious solution. You can make users migrate by > >> adding "deprecated" files to the old profiles. > > > > To be honest, I don't see much benefit from it compared to not having > > the *stable.use.mask files at all and just adding separate stable > > profiles. > > The main use case for *use.stable.mask that I'm aware of is that it's > handy for masking flags to pass repoman checks. For example, > sys-apps/portage could use it for the pypy1_9 flag. Otherwise, we have > to mask that flag for a given portage version before we can add stable > keywords. Yes, and having 'stable' and 'unstable' profiles will work just the same. Except for the fact that it will be a bit cleaner, not require EAPI=5 at all and probably make arch testing a bit easier for a few people. -- Best regards, Michał Górny signature.asc Description: PGP signature
