Re: [gentoo-dev] Proposal for enhancement to PMS/EAPI7+

> On Wed, 18 May 2016, M J Everitt wrote: > My idea thus, was inspired by the simple bash DOCS+= ( ) statement, > that would allow you to append files/folders to the installdocs > list, assuming that DOCS was pre-populated with an existing set of > files. Obviously the status quo is set for

Re: [gentoo-dev] Proposal for enhancement to PMS/EAPI7+

On 18 May 2016 at 17:40, Ulrich Mueller wrote: > Only two lines. Do you think this is untidy? It only becomes untidy where you don't already have a src_install. Then it becomes 4 lines. 4 lines of which 3 are redundant and simply re-codify existing behaviour. -- Kent

Re: [gentoo-dev] Proposal for enhancement to PMS/EAPI7+

On Wed, May 18, 2016 at 05:44:28PM +1200, Kent Fredric wrote: > On 18 May 2016 at 17:40, Ulrich Mueller wrote: > > Only two lines. Do you think this is untidy? > > > It only becomes untidy where you don't already have a src_install. > > Then it becomes 4 lines. > > 4 lines of

Re: [gentoo-dev] Gentoo Overlays project needs you!

I am willing to help 2016-05-17 12:35 GMT+05:00 Aaron Bauman : > I am willing to help. > > On May 17, 2016 3:36:18 PM GMT+09:00, "Michał Górny" > wrote: >> >> Hello, everyone. >> >> It seems that I'm the only person doing Overlays project work these days. >>

Re: [gentoo-dev] Gentoo Overlays project needs you!

On 05/17/2016 08:36 AM, Michał Górny wrote: > Hello, everyone. > > It seems that I'm the only person doing Overlays project work these days. > This is getting ridiculous to the point of users mailing me when I'm away and > requests are not handled, and dangerous to the point of me missing an

Re: [gentoo-dev] Proposal for changes for the next EAPI version

For normal users we wouldn't. But currently, arch-testers need to make a judgement call on what to test when a stable-req bug is filed. Tests run in src_test are provided by upstream, and does not guarantee that a package that has been merged will actually run on the system. If the maintainer

Re: [gentoo-dev] Proposal for changes for the next EAPI version

On 17 May 2016 at 19:37, Pallav Agarwal wrote: > For normal users we wouldn't. But currently, arch-testers need to make a > judgement call on what to test when a stable-req bug is filed. Tests run in > src_test are provided by upstream, and does not guarantee that a

Re: [gentoo-dev] Gentoo Overlays project needs you!

I am willing to help. On May 17, 2016 3:36:18 PM GMT+09:00, "Michał Górny" wrote: >Hello, everyone. > >It seems that I'm the only person doing Overlays project work these >days. This is getting ridiculous to the point of users mailing me when >I'm away and requests are not

Re: [gentoo-dev] Proposal for changes for the next EAPI version

Hi! On Tue, 17 May 2016, Kent Fredric wrote: > On 17 May 2016 at 19:37, Pallav Agarwal wrote: > > For normal users we wouldn't. But currently, arch-testers need to make a > > judgement call on what to test when a stable-req bug is filed. Tests run in > > src_test are

Re: [gentoo-dev] Proposal for changes for the next EAPI version

On 17 May 2016 at 20:46, Tobias Klausmann wrote: > And as for my pet peeve, tests that are known to fail, can we > also annotate that somehow so I don't waste hours running a test > suite that gives zero signal on whether I should add the stable > keyword? Even a one-line hin

Re: [gentoo-dev] Proposal for changes for the next EAPI version

Hi, You are right, of course. The target is to standardize something that would encourage maintainers to actually provide non-upstream scripts to test packages. At the same time, it should be possible to use those scripts for automated testing without human interference. Even if they are provided

Re: [gentoo-dev] Proposal for changes for the next EAPI version

On Tue, May 17, 2016 at 5:15 AM, Kent Fredric wrote: > On 17 May 2016 at 20:46, Tobias Klausmann wrote: >> And as for my pet peeve, tests that are known to fail, can we >> also annotate that somehow so I don't waste hours running a test >> suite that

Re: [gentoo-dev] Proposal for changes for the next EAPI version

On Tue, May 17, 2016 at 4:27 PM, Rich Freeman wrote: > On Tue, May 17, 2016 at 5:15 AM, Kent Fredric > wrote: > > On 17 May 2016 at 20:46, Tobias Klausmann wrote: > >> And as for my pet peeve, tests that are known to fail, can we >

Re: [gentoo-dev] Proposal for changes for the next EAPI version

On 05/17/2016 06:01 AM, Pallav Agarwal wrote: > Hi, > You are right, of course. > The target is to standardize something that would encourage maintainers > to actually provide non-upstream scripts to test packages. At the same > time, it should be possible to use those scripts for automated

[gentoo-portage-dev] [PATCH] pym/portage/util/locale.py: add a C module to check locale

From: "Anthony G. Basile" The current method to check for the system locale is to use python's ctype.util.find_library() to construct a full library path to the system libc.so which is then passed to ctypes.CDLL(). However, this gets bogged down in implementation dependant

Re: [gentoo-dev] Proposal for changes for the next EAPI version

On Tue, May 17, 2016 at 7:25 AM, Pallav Agarwal wrote: > Because we are already expecting an arch tester to conduct tests for the > package. And knowing what to test is something I expect to come more > easily from the maintainer. > It would come even more easily from

Re: [gentoo-portage-dev] [PATCH] pym/portage/util/locale.py: add a C module to check locale

On 5/17/16 8:47 AM, Anthony G. Basile wrote: > From: "Anthony G. Basile" > > The current method to check for the system locale is to use python's > ctype.util.find_library() to construct a full library path to the > system libc.so which is then passed to ctypes.CDLL().

Re: [gentoo-dev] NEW: split portage/repoman releases now in the tree

On Tue, 17 May 2016 08:50:25 +0200 Marcin Mirosław wrote: > W dniu 16.05.2016 o 10:45, Dirkjan Ochtman pisze: > > On Mon, May 16, 2016 at 3:39 AM, Brian Dolbec > > wrote: > >> repoman-2.3.0_rc1 is the stage2 rewrite code. The checks are now > >> modular,

Re: [gentoo-dev] Proposal for changes for the next EAPI version

On Tue, 17 May 2016 07:26:03 -0400 Michael Orlitzky wrote: > We already have "emerge --config" which is expected to be run after > the install process has completed, so I don't think that this is too > much of a stretch. Maybe call the phase "pkg_test" analogous to > "pkg_config"

Re: [gentoo-portage-dev] [PATCH] dblink: add locks for parallel-install with blockers (bug 576888)

On Mon, 16 May 2016 12:20:00 -0700 Zac Medico wrote: > On 03/14/2016 11:36 AM, Brian Dolbec wrote: > > On Mon, 14 Mar 2016 11:26:23 +0100 > > Alexander Berntsen wrote: > > > >> -BEGIN PGP SIGNED MESSAGE- > >> Hash: SHA512 > > > >> I can't

Re: [gentoo-dev] Proposal for changes for the next EAPI version

On Tue, 17 May 2016 15:53:34 +0200 "M.B." wrote: > Am 17.05.2016 um 09:37 schrieb Pallav Agarwal: > > For normal users we wouldn't. But currently, arch-testers need to > > make a judgement call on what to test when a stable-req bug is > > filed. Tests run in src_test are

Re: [gentoo-portage-dev] [PATCH] pym/portage/util/locale.py: add a C module to check locale

On Tue, 17 May 2016 09:02:55 -0400 "Anthony G. Basile" wrote: > On 5/17/16 8:47 AM, Anthony G. Basile wrote: > > From: "Anthony G. Basile" > > > > The current method to check for the system locale is to use python's > > ctype.util.find_library()

Re: [gentoo-portage-dev] [PATCH] pym/portage/util/locale.py: add a C module to check locale

On 5/17/16 9:38 AM, Brian Dolbec wrote: > On Tue, 17 May 2016 09:02:55 -0400 > "Anthony G. Basile" wrote: > >> On 5/17/16 8:47 AM, Anthony G. Basile wrote: >>> From: "Anthony G. Basile" >>> >>> The current method to check for the system locale is

Re: [gentoo-dev] Proposal for changes for the next EAPI version

Am 17.05.2016 um 09:37 schrieb Pallav Agarwal: > For normal users we wouldn't. But currently, arch-testers need to make a > judgement call on what to test when a stable-req bug is filed. Tests run in > src_test are provided by upstream, and does not guarantee that a package > that has been

Re: [gentoo-dev] Proposal for changes for the next EAPI version

On 17 May 2016 at 08:34, Luis Ressel wrote: > > Automated post-merge tests sound kinda dangerous to me. And I don't > think there's any stipulation about src_test() only running > upstream-provided test suites. IMHO, src_test() would be a good place > for most of the

Re: [gentoo-dev] Proposal for changes for the next EAPI version

On Tue, 17 May 2016 13:07:43 +0530 Pallav Agarwal wrote: > Tests run in src_test are provided by upstream, and does not > guarantee that a package that has been merged will actually run on > the system. If the maintainer could add a couple small scripts to > check

Re: [gentoo-dev] eclass/vdr-plugin-2.eclass EAPI=6 changes, plz review

Dnia 16 maja 2016 11:39:23 CEST, Joerg Bornkessel napisał(a): >Hallo, >after my last commit disaster, >i bring my changes to review before i break some things again. > >- Added changes to make it work with eapi=6 >- removed some unneeded code parts (never they was used in

[gentoo-dev] Gentoo Overlays project needs you!

Hello, everyone. It seems that I'm the only person doing Overlays project work these days. This is getting ridiculous to the point of users mailing me when I'm away and requests are not handled, and dangerous to the point of me missing an email meaning the request won't be handled. For this

Re: [gentoo-dev] NEW: split portage/repoman releases now in the tree

W dniu 16.05.2016 o 10:45, Dirkjan Ochtman pisze: > On Mon, May 16, 2016 at 3:39 AM, Brian Dolbec wrote: >> repoman-2.3.0_rc1 is the stage2 rewrite code. The checks are now >> modular, and using the portage plugin system. The system is not yet >> fully plug and play. Those

Re: [gentoo-dev] Gentoo Overlays project needs you!

On May 17, 2016 8:45 AM, "Michał Górny" wrote: > For this reason, I would like to ask others to join the Overlays effort. Sign me up, let's see what happens. Cheers, Dirkjan

Re: [gentoo-dev] Proposal for changes for the next EAPI version

On Tue, May 17, 2016 at 12:05 PM, Sébastien Fabbro wrote: > On 17 May 2016 at 08:34, Luis Ressel wrote: > >> >> Automated post-merge tests sound kinda dangerous to me. And I don't >> think there's any stipulation about src_test() only running >>

Re: [gentoo-portage-dev] [PATCH] pym/portage/util/locale.py: add a C module to check locale

On 5/17/16 8:47 AM, Anthony G. Basile wrote: > + > + try: > + from portage_c_check_locale import _c_check_locale > + (ret, msg) = _c_check_locale() > + except ImportError: > + writemsg_level("!!! Unable to import portage_c_check_locale\n", > +

[gentoo-portage-dev] suggestion for qa-check verbosity

Good evening, please consider merging this patchset. It includes: - brief documentation of the install-qa-check.d mechanism in portage.5 - implementation of the noisy-qa option for FEATURES - implementation of the __noisy_qa() function - use of the __noisy_qa() function to make existing default

[gentoo-dev] [PATCH] cmake-utils.eclass: rewrite `_ninjaopts_from_makeopts()`

This is an update of a patch I posted earlier. More info on GitHub - https://github.com/gentoo/gentoo/pull/1481.

[gentoo-dev] Automated stabilization - openQA

Based on the "[gentoo-dev] Proposal for changes for the next EAPI version" thread, it looks like this idea is slowly coming real so I'd like to know if someone considered https://openqa.opensuse.org/ to prevent the wheel being re-invented again.

[gentoo-dev] Re: [RFC] Enable CMAKE_WARN_UNUSED_CLI by default in cmake-utils for EAPI>=6

On Monday 02 of May 2016 18:13:38 you wrote: > On Monday 02 of May 2016 18:06:44 you wrote: > > Unfortunately there is common misconception, also among developers, that > > it's sufficient to simply replace "${cmake-utils_use_with foo)" with > > "-DWITH_foo=ON" etc. > > Obvious errata, should be:

Re: [gentoo-dev] Proposal for changes for the next EAPI version

On 18 May 2016 at 04:05, Sébastien Fabbro wrote: > Basically CI for ebuilds: it could be implemented as a script living > in the package directory, something like a .travis.yml in the GitHub > repositories or may be an EAPI change. Debian has a similar project > [1]. Upstream

Re: [gentoo-dev] Proposal for changes for the next EAPI version

On 18/05/16 01:14, Kent Fredric wrote: > On 18 May 2016 at 04:05, Sébastien Fabbro wrote: >> Basically CI for ebuilds: it could be implemented as a script living >> in the package directory, something like a .travis.yml in the GitHub >> repositories or may be an EAPI change.

Re: [gentoo-dev] Proposal for changes for the next EAPI version

On 18 May 2016 at 12:35, M. J. Everitt wrote: > Yes, whilst that's a special case, it would be desirable to collaborate > with another maintainer/team/project to devise a test schedule that was > independent from the target language, if possible. But there will always > be

Re: [gentoo-dev] Proposal for changes for the next EAPI version

On 18/05/16 01:44, Kent Fredric wrote: > On 18 May 2016 at 12:35, M. J. Everitt wrote: >> Yes, whilst that's a special case, it would be desirable to collaborate >> with another maintainer/team/project to devise a test schedule that was >> independent from the target

[gentoo-dev] Proposal for enhancement to PMS/EAPI7+

I've just been party to a discussion over in the Proxy Maintainers channel .. and the subject of correct ways to install documentation popped up. It seems to me rather quirky, that there is no middle ground in (for example) EAPI6 to have the default documentation installed per