Re: [gentoo-dev] News item for Radicale upgrade

[Ulrich Mueller]

> On Fri, 30 Mar 2018, Christopher Head wrote:

> Title: Radicale 2 requires pre-install migration
> Author: Christopher Head 
> Posted: 2018-03-30
> Revision: 2

Please start with Revision 1 here. The revision should be increased
only when an item is updated after publishing.

> News-Item-Format: 2.0
> Display-If-Installed:  [...]

Ulrich


pgpXsN454fxGX.pgp
Description: PGP signature

[gentoo-dev] last rites: dev-scheme/ikarus

[Andreas K. Huettel]

# Andreas K. Hüttel  (30 Mar 2018)
# Fails to build (bug 408463). EAPI=3 (bug 648452).
# Masked for removal in 30 days.
dev-scheme/ikarus


-- 
Andreas K. Hüttel
dilfri...@gentoo.org
Gentoo Linux developer
(council, toolchain, perl, libreoffice, comrel)

signature.asc
Description: This is a digitally signed message part.

[gentoo-dev] Last rites: media-plugins/gst-plugins-mad:1.0

[Mart Raudsepp]

# Mart Raudsepp  (30 Mar 2018)
# GStreamer mp3 decoder plugin based on libmad is removed with gstreamer-1.12.
# media-plugins/gst-plugins-mpg123 is the suggested replacement.
# Masked for removal in 30 days. Bug 631128
media-plugins/gst-plugins-mad:1.0

signature.asc
Description: This is a digitally signed message part

Re: [gentoo-dev] News item for Radicale upgrade

[Christopher Head]

Hello,
After much discussion on the pull request
, reviewers and I have
concluded with a new pkg_pretend message, which I would like to use as
the new news message as well. As before, I ask that the committer of
that merge request adjust the posted date in this news item and add it
to the news repo when accepting the PR. Thanks!

Title: Radicale 2 requires pre-install migration
Author: Christopher Head 
Posted: 2018-03-30
Revision: 2
News-Item-Format: 2.0
Display-If-Installed: http://radicale.org/1to2/
If you do a custom migration, please ensure the database is cleaned out
of /var/lib/radicale, including the hidden .props file.
-- 
Christopher Head


pgpmwdLDP2kml.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] Re : Modification proposal for user/group creation when ROOT!="/"

[James Le Cuirot]

On Fri, 30 Mar 2018 20:47:20 +0100
James Le Cuirot  wrote:

> On Fri, 30 Mar 2018 20:23:49 +0100
> James Le Cuirot  wrote:
> 
> > I did just have a lightbulb moment though. I've been playing with
> > unshare recently and I wondered if we could leverage it here.
> > 
> >   $ sudo unshare -m /bin/sh -c "mount --bind /mnt/somewhere/etc /etc && 
> > groupadd foo"
> >   groupadd: Cannot determine your user name.  
> 
> Aha! I was trying to do this against an NFS share for a system with a
> different architecture. If I use a local mount with a compatible
> architecture, it actually does work. I'll explore this some more.

Figured it out! The system I was doing this against has an ancient
glibc (long story) with an old nsswitch.conf. I replaced this file with
a newer one and it all started working. Do you agree this could be the
way forwards?

-- 
James Le Cuirot (chewi)
Gentoo Linux Developer


pgpXQVm8fnITq.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] Re : Modification proposal for user/group creation when ROOT!="/"

[James Le Cuirot]

On Fri, 30 Mar 2018 20:23:49 +0100
James Le Cuirot  wrote:

> I did just have a lightbulb moment though. I've been playing with
> unshare recently and I wondered if we could leverage it here.
> 
>   $ sudo unshare -m /bin/sh -c "mount --bind /mnt/somewhere/etc /etc && 
> groupadd foo"
>   groupadd: Cannot determine your user name.

Aha! I was trying to do this against an NFS share for a system with a
different architecture. If I use a local mount with a compatible
architecture, it actually does work. I'll explore this some more.

-- 
James Le Cuirot (chewi)
Gentoo Linux Developer


pgpi6lGElLSy7.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] Re : Modification proposal for user/group creation when ROOT!="/"

[James Le Cuirot]

On Fri, 30 Mar 2018 18:52:18 + (UTC)
Farid BENAMROUCHE  wrote:

> Yes, two years ago I've posted here to notify you about the creattion of 
> users and groups when using "ROOT=".
> As a reminder, if you currently emerge a package to a specific rootfs folder, 
> some packages will actually not create the user and groups correctly inside 
> this rootfs.
> It will also not check for the existance of the user/group inside of the 
> rootfs.
> Everytime, it will check "/".
> 
> This very old gentoo issue (I have to find again the GLEP talking about this 
> issue).
> 
> The solution is not possible without changing the behaviour of the tools used 
> by portage. For example, portage is using shadow in most systems (and shadow 
> is using the glibc).

Hi,

I have an interest this and was one of the early commenters in bug
#541406. I made my own suggestions about how this might work. Your
solution is cleaner in that it doesn't require modifying the users in
the / system but it does require significant changes to tools,
eclasses, and ebuilds so I'm on the fence about it.

I did just have a lightbulb moment though. I've been playing with
unshare recently and I wondered if we could leverage it here. First I
tried this.

  $ sudo unshare -m /bin/sh -c "mount --bind /mnt/somewhere/etc/group 
/etc/group && groupadd foo"
  groupadd: failure while writing changes to /etc/group

It is possible to bind mount individual files but it doesn't work here
because it tries to rename /etc/group to made a backup. Next I tried
the whole directory but it gives a strange error.

  $ sudo unshare -m /bin/sh -c "mount --bind /mnt/somewhere/etc /etc && 
groupadd foo"
  groupadd: Cannot determine your user name.

This reveals more.

  $ sudo unshare -m /bin/sh -c "id && mount --bind /mnt/utilite/mnt/moi/etc 
/etc && id"
  uid=0(root) gid=0(root) 
groups=0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel),11(floppy),20(dialout),26(tape),27(video)
  uid=0 gid=0 groups=0,1,2,3,4,6,10,11,20,26,27

I'm not sure why the IDs break like this and strace doesn't make it any
clearer. This seems like a route worth pursuing though because you
could create a bunch of wrappers for useradd, groupadd, chown and so on
and it would then all work transparently, even when not using the
eclass functions.

Regards,
-- 
James Le Cuirot (chewi)
Gentoo Linux Developer


pgp5TAk9z0pkh.pgp
Description: OpenPGP digital signature

[gentoo-dev] Re : Modification proposal for user/group creation when ROOT!="/"

[Farid BENAMROUCHE]

Hi all,

Already two years
Yes, two years ago I've posted here to notify you about the creattion of users 
and groups when using "ROOT=".
As a reminder, if you currently emerge a package to a specific rootfs folder, 
some packages will actually not create the user and groups correctly inside 
this rootfs.
It will also not check for the existance of the user/group inside of the rootfs.
Everytime, it will check "/".

This very old gentoo issue (I have to find again the GLEP talking about this 
issue).

The solution is not possible without changing the behaviour of the tools used 
by portage. For example, portage is using shadow in most systems (and shadow is 
using the glibc).

I've submited a patch first to shadow upstream team to avec this feature, using 
a new argument (--prefix) to tools like usemod,useradd etc
You can create users in any rootfs you want, no need to be root (except if you 
local pam configuration requires it)

This is unfortunately not enough for gentoo: some packages are relying on 
chaonw directly. So I've added some wrappers (same as the current enewuser etc 
functions)
This enable people to build embedded systems rootfs from scratch, using a 
complete gentoo.
Some packages must be updated in order to behave properly in that case (replace 
chown with echown for example)
As a failsafe, I'm only triggering the new behavior in case ROOT env var is not 
"/" (and I think (I have to check) that if the command fails, it will fallback 
to the old behavior in case the --prefix argument is not implemented (incorrect 
shadow version for example)

This requires in that case a new EAPI I think. Just tell me what to do, where, 
and I will submit the proposal

I'm using the modifications for 2 years now.


Limitations: 
- selinux is not supported (ie: you will still use the system's selinux.). 
- Also, this only works with gentoo systems using the shadow package (the exact 
version will depend on when the new release will be done).
- Last one: I only tested on a linux configuration


Cheers



En date de : Mar 24.5.16, Farid BENAMROUCHE  a écrit :

 Objet: Modification proposal for user/group creation when ROOT!="/"
 À: gentoo-dev@lists.gentoo.org
 Date: Mardi 24 mai 2016, 21h00
 
 Hi all,
 
 Currently there is an old known
 limitation when using ROOT= option to install a package in a
 folder: user/groups are created in the host filesystem, not
 the target root filesystem.
 
 So I've pushed some modifications to
 the upstream shadow repo.
 Basically, I've added a --prefix option
 to user{add,mod,del} and group{add,mod,del}
 This option does the same as --root
 option, but whithout a chroot (so compatible when cross
 compiling)
 You can see more details (and the
 limitation of my implementation) in the shadow github repo:
 https://github.com/shadow-maint/shadow/issues/18
 
 
 Now, for the gentoo part, I do have a
 working solution that I've pushed in the following
 bugzilla:
 https://bugs.gentoo.org/show_bug.cgi?id=541406
 
 A new user.eclass file with modified
 enewuser,enewgroup and egetent that all supports ${ROOT}
 option via --prefix in shadow utilities.
 For now I've only added this option for
 linux.
 
 However, I've encountered some
 unexpected issues: some ebuilds are using direct calls to
 chown and fowners. Both are not compatible with ${ROOT}...
 
 To solve this, I've created 2 new calls
 in user.eclass: echown and efowners.
 The only thing the new functions are
 doing is to get the uid/gid from the correct passwd/group
 files from ${ROOT} using the modified egetent function and
 pass that to the native chown/fowners...
 
 For example, in sys-power/nut we can
 find:
 chown nut:nut ${ROOT}/var/lib/nut
 
 This should be changed to
 echown nut:nut ${ROOT}/var/lib/nut
 
 Same to fowners.
 If the modification is not done, either
 the ebuild will fail because the nut user does not exists in
 the host, or the incorrect uid will be user in ${ROOT}
 
 The solution is not perfect, but at
 least better than what we have today, and totally usable I
 believe.
 
 I've uploaded the patches for lighttpd
 and nut, plus my patch for user.eclass for review in this
 bug... we do have time until upstream shadow team reviews
 and commits my modifications (at least).
 
 Side note: it's a bit complicated to
 know when to add ${ROOT} and when not in a ebuild... For
 example, chown needs ${ROOT} but fowners must not!...
 Side note 2: maybe I should add a
 verification to check if useradd/groupadd supports my new
 --prefix solution, and fallback to original behavior if
 not?
 
 Tests: I've compiled a full working
 system with my above solution, and it works. (cross
 compilation in a dedicated target root path)
 
 Regards,
 Farid
 

Re: [gentoo-dev] Getting glibc-2.26 stable (reminder)

[Andreas K. Huettel]

Am Freitag, 30. März 2018, 19:15:16 CEST schrieb Andreas K. Huettel:
> 
> Hey all,
> 
> now that upstream has already released glibc-2.27, we should think about
> getting glibc-2.26 stable soon. That, however, means work for all of us.
> 

And, as this seems to be a frequently asked question: My plan is to re-add 
keywords to 2.27 once the stable request for 2.26 has arches in cc. 


-- 
Andreas K. Hüttel
dilfri...@gentoo.org
Gentoo Linux developer
(council, toolchain, perl, libreoffice, comrel)

signature.asc
Description: This is a digitally signed message part.

[gentoo-dev] Getting glibc-2.26 stable (reminder)

[Andreas K. Huettel]

Re-sending this as a reminder...

-

Hey all, 

now that upstream has already released glibc-2.27, we should think about 
getting glibc-2.26 stable soon. That, however, means work for all of us.

Typical problems:

* Build failures because xlocale.h is gone
  https://bugs.gentoo.org/638010
  Fix: include locale.h instead

* Build failures, undefined reference to 'minor' / 'major'
  https://bugs.gentoo.org/575232
  Fix: additionally include sys/sysmacros.h
  No, we can't delay this further; the inclusion is (finally) 
  also upstream gone in 2.28. Everything we fix now will for
  sure save us trouble later.

* Build failures because of missing rpc support in glibc
  https://bugs.gentoo.org/381391
  See the following wiki page for information:
  https://wiki.gentoo.org/wiki/Project:Toolchain/RPC_implementation

* Build failures because of missing NIS support
  After fixing rpc support, add a dependency on net-libs/libnsl
  (unconditionally).

* Some internal type definitions have changed, which may lead
  to more obscure build problems (rare).

Please test and fix bugs!!! 

If you want to update your otherwise stable system, please
keyword the following (otherwise you'll get blockers):

~sys-libs/glibc-2.26
=net-libs/libnsl-1*
=net-libs/rpcsvc-proto-1*

Feel free to try emerging sys-libs/glibc with FEATURES=test 
(that takes a while). On amd64/x86, nearly all of the ~4000 tests succeed; I 
know of the following problems:
* elf/tst-prelink-cmp fails, still needs analysis
* only with gcc-7.3.0, six tests math/test-?float128* fail (with my CFLAGS)
  This is a gcc regression (miscompilation of truncf128), already submitted
  upstream.
In any case, I think this still looks nice:
Summary of test results:
  7 FAIL
   4109 PASS
 11 UNSUPPORTED
 29 XFAIL
  2 XPASS
Other arches may show more test failures; please file separate bugs per arch;
see https://bugs.gentoo.org/634988#c1 for what is needed for a useful report.

Stabilization tracker (fresh and largely yet empty): 
https://bugs.gentoo.org/show_bug.cgi?id=glibc-2.26-stable

General issue tracker: 
https://bugs.gentoo.org/show_bug.cgi?id=glibc-2.26

Cheers, 
Andreas

-- 
Andreas K. Hüttel
dilfri...@gentoo.org
Gentoo Linux developer
(council, toolchain, perl, libreoffice, comrel)


signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: app-portage/repoman/

[Zac Medico]

On 03/30/2018 08:16 AM, William Hubbs wrote:
> On Fri, Mar 30, 2018 at 12:42:09PM +0200, Michał Górny wrote:
>> Dnia 30 marca 2018 11:01:33 CEST, Zac Medico  napisał(a):
>>> On 03/30/2018 01:42 AM, Michał Górny wrote:
 Dnia 30 marca 2018 09:07:03 CEST, Zac Medico 
>>> napisał(a):
> On 03/29/2018 10:20 PM, Michał Górny wrote:
>> Dnia 30 marca 2018 06:30:14 CEST, Zac Medico 
> napisał(a):
>>> commit: 3f04d4d93d00afa5242a0c9459487c9eea7e9a6f
>>> Author: Zac Medico  gentoo  org>
>>> AuthorDate: Fri Mar 30 04:18:05 2018 +
>>> Commit: Zac Medico  gentoo  org>
>>> CommitDate: Fri Mar 30 04:30:05 2018 +
>>> URL:   
>>> https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=3f04d4d9
>>>
>>> app-portage/repoman: version bump to 2.3.8
>>>
>>> This release adds support for plugin module systems.
>>>
>>> See:
> https://wiki.gentoo.org/wiki/Project:Portage/Repoman-Module-specs
>>> Package-Manager: Portage-2.3.27_p1, Repoman-2.3.8
>>
>> Please revert this immediately. This was never finished, had open
> concerns that were never addressed and the added Gentoo repository
> files were never subject to proper RFC/review that was requested.
>
> I've disabled this feature by default, and hidden it behind an
> --experimental-repository-modules= option.

 That isn't going to work for me. Given that the yml files were added
>>> to repository without prior discussion, and contrary to the promises
>>> given by Portage team such discussion hasn't been started before
>>> merging the changes to master, I'd like to request removing all those
>>> files and not reintroducing them until Portage team specifies their
>>> format and brings it to open discussion.
>>>
>>> Yeah I agree that the format really needs a proper specification. I've
>>> gone ahead and removed them:
>>>
>>> https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=f62e76a1e0202dcf55faa2b0fd9b21a1cd184dc8
>>
>> Thanks. I hope this will let us start with a clean slate towards making a 
>> good format.
> 
> If there is some distro policy that this repoman enhancement violated,
> that's fine and I would like to know about it, but I'm not aware of it.

The format is definitely not fully baked, and will likely change, so I
think it's better to wait for it to mature some more.

> If there isn't, as far as I know, there is no reason for it to be
> blocked.

This is not really blocking anything, people can go ahead and use the
repoman --experimental-repository-modules=y option, even add it to
REPOMAN_DEFAULT_OPTS, and it will just work.
-- 
Thanks,
Zac



signature.asc
Description: OpenPGP digital signature

[gentoo-dev] Last-rites: kde-apps/kholidays, kde-apps/kscd, kde-apps/kde4-l10n

[Andreas Sturmlechner]

# Andreas Sturmlechner  (30 Mar 2018)
# Package moved to kde-frameworks. Masked for removal in 30 days.
kde-apps/kholidays

# Andreas Sturmlechner  (30 Mar 2018)
# Depends on deprecated Qt4, no revdeps left.
# Masked for removal in 30 days.
kde-apps/kscd
kde-apps/kde4-l10n

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: app-portage/repoman/

[William Hubbs]

On Fri, Mar 30, 2018 at 12:42:09PM +0200, Michał Górny wrote:
> Dnia 30 marca 2018 11:01:33 CEST, Zac Medico  napisał(a):
> >On 03/30/2018 01:42 AM, Michał Górny wrote:
> >> Dnia 30 marca 2018 09:07:03 CEST, Zac Medico 
> >napisał(a):
> >>> On 03/29/2018 10:20 PM, Michał Górny wrote:
>  Dnia 30 marca 2018 06:30:14 CEST, Zac Medico 
> >>> napisał(a):
> > commit: 3f04d4d93d00afa5242a0c9459487c9eea7e9a6f
> > Author: Zac Medico  gentoo  org>
> > AuthorDate: Fri Mar 30 04:18:05 2018 +
> > Commit: Zac Medico  gentoo  org>
> > CommitDate: Fri Mar 30 04:30:05 2018 +
> > URL:   
> > https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=3f04d4d9
> >
> > app-portage/repoman: version bump to 2.3.8
> >
> > This release adds support for plugin module systems.
> >
> > See:
> >>> https://wiki.gentoo.org/wiki/Project:Portage/Repoman-Module-specs
> > Package-Manager: Portage-2.3.27_p1, Repoman-2.3.8
> 
>  Please revert this immediately. This was never finished, had open
> >>> concerns that were never addressed and the added Gentoo repository
> >>> files were never subject to proper RFC/review that was requested.
> >>>
> >>> I've disabled this feature by default, and hidden it behind an
> >>> --experimental-repository-modules= option.
> >> 
> >> That isn't going to work for me. Given that the yml files were added
> >to repository without prior discussion, and contrary to the promises
> >given by Portage team such discussion hasn't been started before
> >merging the changes to master, I'd like to request removing all those
> >files and not reintroducing them until Portage team specifies their
> >format and brings it to open discussion.
> >
> >Yeah I agree that the format really needs a proper specification. I've
> >gone ahead and removed them:
> >
> >https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=f62e76a1e0202dcf55faa2b0fd9b21a1cd184dc8
> 
> Thanks. I hope this will let us start with a clean slate towards making a 
> good format.

If there is some distro policy that this repoman enhancement violated,
that's fine and I would like to know about it, but I'm not aware of it.

If there isn't, as far as I know, there is no reason for it to be
blocked.

Thanks,

William



signature.asc
Description: Digital signature

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: app-portage/repoman/

[Michał Górny]

Dnia 30 marca 2018 11:01:33 CEST, Zac Medico  napisał(a):
>On 03/30/2018 01:42 AM, Michał Górny wrote:
>> Dnia 30 marca 2018 09:07:03 CEST, Zac Medico 
>napisał(a):
>>> On 03/29/2018 10:20 PM, Michał Górny wrote:
 Dnia 30 marca 2018 06:30:14 CEST, Zac Medico 
>>> napisał(a):
> commit: 3f04d4d93d00afa5242a0c9459487c9eea7e9a6f
> Author: Zac Medico  gentoo  org>
> AuthorDate: Fri Mar 30 04:18:05 2018 +
> Commit: Zac Medico  gentoo  org>
> CommitDate: Fri Mar 30 04:30:05 2018 +
> URL:   
> https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=3f04d4d9
>
> app-portage/repoman: version bump to 2.3.8
>
> This release adds support for plugin module systems.
>
> See:
>>> https://wiki.gentoo.org/wiki/Project:Portage/Repoman-Module-specs
> Package-Manager: Portage-2.3.27_p1, Repoman-2.3.8

 Please revert this immediately. This was never finished, had open
>>> concerns that were never addressed and the added Gentoo repository
>>> files were never subject to proper RFC/review that was requested.
>>>
>>> I've disabled this feature by default, and hidden it behind an
>>> --experimental-repository-modules= option.
>> 
>> That isn't going to work for me. Given that the yml files were added
>to repository without prior discussion, and contrary to the promises
>given by Portage team such discussion hasn't been started before
>merging the changes to master, I'd like to request removing all those
>files and not reintroducing them until Portage team specifies their
>format and brings it to open discussion.
>
>Yeah I agree that the format really needs a proper specification. I've
>gone ahead and removed them:
>
>https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=f62e76a1e0202dcf55faa2b0fd9b21a1cd184dc8

Thanks. I hope this will let us start with a clean slate towards making a good 
format.


-- 
Best regards,
Michał Górny (by phone)

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: app-portage/repoman/

[Zac Medico]

On 03/30/2018 01:42 AM, Michał Górny wrote:
> Dnia 30 marca 2018 09:07:03 CEST, Zac Medico  napisał(a):
>> On 03/29/2018 10:20 PM, Michał Górny wrote:
>>> Dnia 30 marca 2018 06:30:14 CEST, Zac Medico 
>> napisał(a):
 commit: 3f04d4d93d00afa5242a0c9459487c9eea7e9a6f
 Author: Zac Medico  gentoo  org>
 AuthorDate: Fri Mar 30 04:18:05 2018 +
 Commit: Zac Medico  gentoo  org>
 CommitDate: Fri Mar 30 04:30:05 2018 +
 URL:   
 https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=3f04d4d9

 app-portage/repoman: version bump to 2.3.8

 This release adds support for plugin module systems.

 See:
>> https://wiki.gentoo.org/wiki/Project:Portage/Repoman-Module-specs
 Package-Manager: Portage-2.3.27_p1, Repoman-2.3.8
>>>
>>> Please revert this immediately. This was never finished, had open
>> concerns that were never addressed and the added Gentoo repository
>> files were never subject to proper RFC/review that was requested.
>>
>> I've disabled this feature by default, and hidden it behind an
>> --experimental-repository-modules= option.
> 
> That isn't going to work for me. Given that the yml files were added to 
> repository without prior discussion, and contrary to the promises given by 
> Portage team such discussion hasn't been started before merging the changes 
> to master, I'd like to request removing all those files and not reintroducing 
> them until Portage team specifies their format and brings it to open 
> discussion.

Yeah I agree that the format really needs a proper specification. I've
gone ahead and removed them:

https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=f62e76a1e0202dcf55faa2b0fd9b21a1cd184dc8
-- 
Thanks,
Zac



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: app-portage/repoman/

[Michał Górny]

Dnia 30 marca 2018 09:07:03 CEST, Zac Medico  napisał(a):
>On 03/29/2018 10:20 PM, Michał Górny wrote:
>> Dnia 30 marca 2018 06:30:14 CEST, Zac Medico 
>napisał(a):
>>> commit: 3f04d4d93d00afa5242a0c9459487c9eea7e9a6f
>>> Author: Zac Medico  gentoo  org>
>>> AuthorDate: Fri Mar 30 04:18:05 2018 +
>>> Commit: Zac Medico  gentoo  org>
>>> CommitDate: Fri Mar 30 04:30:05 2018 +
>>> URL:   
>>> https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=3f04d4d9
>>>
>>> app-portage/repoman: version bump to 2.3.8
>>>
>>> This release adds support for plugin module systems.
>>>
>>> See:
>https://wiki.gentoo.org/wiki/Project:Portage/Repoman-Module-specs
>>> Package-Manager: Portage-2.3.27_p1, Repoman-2.3.8
>> 
>> Please revert this immediately. This was never finished, had open
>concerns that were never addressed and the added Gentoo repository
>files were never subject to proper RFC/review that was requested.
>
>I've disabled this feature by default, and hidden it behind an
>--experimental-repository-modules= option.

That isn't going to work for me. Given that the yml files were added to 
repository without prior discussion, and contrary to the promises given by 
Portage team such discussion hasn't been started before merging the changes to 
master, I'd like to request removing all those files and not reintroducing them 
until Portage team specifies their format and brings it to open discussion.


-- 
Best regards,
Michał Górny (by phone)

[gentoo-dev] Re: [gentoo-commits] repo/gentoo:master commit in: app-portage/repoman/

[Zac Medico]

On 03/29/2018 10:20 PM, Michał Górny wrote:
> Dnia 30 marca 2018 06:30:14 CEST, Zac Medico  napisał(a):
>> commit: 3f04d4d93d00afa5242a0c9459487c9eea7e9a6f
>> Author: Zac Medico  gentoo  org>
>> AuthorDate: Fri Mar 30 04:18:05 2018 +
>> Commit: Zac Medico  gentoo  org>
>> CommitDate: Fri Mar 30 04:30:05 2018 +
>> URL:   
>> https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=3f04d4d9
>>
>> app-portage/repoman: version bump to 2.3.8
>>
>> This release adds support for plugin module systems.
>>
>> See: https://wiki.gentoo.org/wiki/Project:Portage/Repoman-Module-specs
>> Package-Manager: Portage-2.3.27_p1, Repoman-2.3.8
> 
> Please revert this immediately. This was never finished, had open concerns 
> that were never addressed and the added Gentoo repository files were never 
> subject to proper RFC/review that was requested.

I've disabled this feature by default, and hidden it behind an
--experimental-repository-modules= option.
-- 
Thanks,
Zac



signature.asc
Description: OpenPGP digital signature