> On Thu, 28 Sep 2017, Austin English wrote:
> Talking with Whubbs about it, I found that our service script only
> supports OpenRC, via rc-service. I looked around, and from what I
> can tell, most distros ship a service tool for all supported init
> systems. I.e., Debian/Ubuntu: supports sys
Austin English wrote:
> (Note: serious discussion, please take systemd trolling elsewhere).
>
> While having the pleasure of working with some proprietary software
> recently, I was asked to run `service foo restart`, and was surprised to
> see:
> foobar ~ # service foo restart
> * service: servic
Duncan posted on 09/29/17 2:08 AM as excerpted:
> Or are we going to replace rm, and fdisk, and gdisk, and cfdisk, and
> cgdisk, and who knows how many other binaries, with "safe" alternatives,
> because some gentooer couldn't be bothered to think for a moment whether
> a command in some instr
On Thu, Sep 28, 2017 at 07:35:20PM +, Mike Gilbert wrote:
> On Wed, Sep 20, 2017 at 10:01 PM, Marty E. Plummer
> wrote:
> > arfrever suggests I send a mail here, as there are other packages which
> > may be affected by this issue and perhaps a more generalized fix is
> > required instead of an
Austin English posted on Thu, 28 Sep 2017 16:27:31 -0500 as excerpted:
> (Note: serious discussion, please take systemd trolling elsewhere).
>
> While having the pleasure of working with some proprietary software
> recently, I was asked to run `service foo restart`, and was surprised to
> see:
>
(Note: serious discussion, please take systemd trolling elsewhere).
While having the pleasure of working with some proprietary software
recently, I was asked to run `service foo restart`, and was surprised to
see:
foobar ~ # service foo restart
* service: service `foo' does not exist
Since `syst
On Wed, Sep 20, 2017 at 10:01 PM, Marty E. Plummer
wrote:
> arfrever suggests I send a mail here, as there are other packages which
> may be affected by this issue and perhaps a more generalized fix is
> required instead of an explicit fix in sys-libs/ncurses and other ebuilds
> that may require i
On Thu, Sep 28, 2017 at 10:43 AM, Ian Stakenvicius wrote:
> On 28/09/17 10:23 AM, Thomas Deutschmann wrote:
>> Hi,
>>
>> sounds like we should convert to prune_libtool_files usage from
>> ltprune.eclass.
>>
>> However, the eclass says
>>
>>> # Discouraged. Whenever possible, please use much simple
On Thu, Sep 28, 2017 at 10:23 AM, Thomas Deutschmann wrote:
> Hi,
>
> sounds like we should convert to prune_libtool_files usage from
> ltprune.eclass.
>
> However, the eclass says
>
>> # Discouraged. Whenever possible, please use much simpler:
>> # find "${D}" -name '*.la' -delete || die
>
> So t
On 28/09/17 10:23 AM, Thomas Deutschmann wrote:
> Hi,
>
> sounds like we should convert to prune_libtool_files usage from
> ltprune.eclass.
>
> However, the eclass says
>
>> # Discouraged. Whenever possible, please use much simpler:
>> # find "${D}" -name '*.la' -delete || die
>
> So this would
Hi,
sounds like we should convert to prune_libtool_files usage from
ltprune.eclass.
However, the eclass says
> # Discouraged. Whenever possible, please use much simpler:
> # find "${D}" -name '*.la' -delete || die
So this would need clarification.
--
Regards,
Thomas
signature.asc
Descript
11 matches
Mail list logo
