On 05/03/2016 11:27 PM, Austin English wrote:
> Hi there,
>
> I've been working on the transition from #!/sbin/runscript to
> #!/sbin/openrc-run [1], by starting on the maintainer-needed packages.
> That's done (aside from some stabilizations needed, but I'll deal with that
> latter). The trouble i
On 18/05/16 07:43, Michał Górny wrote:
> On Wed, 18 May 2016 04:07:07 +0100
> "M. J. Everitt" wrote:
>
>> 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
On Wed, 18 May 2016 04:07:07 +0100
"M. J. Everitt" wrote:
> 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 t
> On Wed, 18 May 2016, 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 which 3 are redundant and simply re-codif
On Mon, 02 May 2016 18:06:44 +0200 Maciej Mrozowski wrote:
> Hello,
>
> General advise: do not convert ebuilds inheriting cmake-utils to EAPI 6
> unless
> you know what you are doing (you are fully aware of eclass behaviour removed
> with https://bugs.gentoo.org/show_bug.cgi?id=514384).
>
> Ba
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 which 3 are redun
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
KENTNL - https://metac
> 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 EA
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
https://dev.gentoo.or
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 language, if possible. But the
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 exceptions and issues an
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. Debian has a similar p
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 could provide CI test
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:
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.
This is an update of a patch I posted earlier. More info on GitHub -
https://github.com/gentoo/gentoo/pull/1481.
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
>> upstream-provided test suites. IMHO, src_test() wou
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 maintainter-provided tests yo
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 basic functionality of the merge
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 provided by upstream, and
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 merged
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, and using the portage plugin system. Th
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 upstream. My point is that
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" and in contrast t
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 testing
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
> >> also annotate that somehow so I don't waste hours running a
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 gives zero signal on whether I should add the
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
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 in the stabilization
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 provided by upstream, and d
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 package
> that has been merged
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.
>> This is getting ridiculous to the poin
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 could
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 handled, and dangerous
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 ema
35 matches
Mail list logo
