[gentoo-dev] Last rites: net-misc/dnetstats
# Michael Palimaka (30 Sep 2017) # Depends on dead qt4. Dead upstream. # Masked for removal in 30 days. net-misc/dnetstats
[gentoo-dev] Last rites: app-office/qcharselect
# Michael Palimaka (30 Sep 2017) # Depends on dead qt4. Dead upstream. # Masked for removal in 30 days. app-office/qcharselect
Re: [gentoo-dev] Providing a `service` scripts that speaks OpenRC and systemd
On Thu, Sep 28, 2017 at 04:27:31PM -0500, 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: service `foo' does not exist
Ridiculous! We need to develop one universal standard that covers
everyone's use cases. https://xkcd.com/927/
But if you insist, why not just set up a short bash script called
"service" rather than monkeying with every init system's internals?
#!/bin/bash
if [[ ]] ; then
systemctl ${2} ${1}
elif [[ ]] ; then
/etc/init.d/${1} ${2}
elif [[ ]] ; then
else
echo "ERROR: Unsupported init system; 'service' call failed"
fi
This can handle a large number of different inits, with as many "elif"
lines as you care to add. But, how do we reliably detect the currently
running init system? Are there running processes, or entries in /sys/
or /proc/ or /dev that are unique to to each init system?
--
Walter Dnes
I don't run "desktop environments"; I run useful applications
Re: [gentoo-dev] Providing a `service` scripts that speaks OpenRC and systemd
On 09/29/2017 04:53 AM, Rich Freeman wrote: > On Thu, Sep 28, 2017 at 11:32 PM, Ulrich Mueller wrote: >>> 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 sysvinit and systemd via >>> init-system-helpers CentOS/Fedora: provides support for systemd via >>> initscripts OpenSUSE: has a working service binary for systemd >>> (according to #suse) >> >> There is "eselect rc" which could be easily extended to support >> systemd. Patches are welcome. :) >> > > ++ > > Honestly, I could see the argument for having a generic "service" > command because that is what everybody else does, but there is little > point in arguing about the name of the file when nobody has bothered > to write it yet. > > If somebody writes such a tool and it proves useful, we can always > have the discussion about refactoring. > > To minimize list replies I'll tackle one of Duncan's points - he was > debating whether you really need this vs just using systemctl. The > obvious use case is scripts that are intended to support multiple init > systems - it makes far more sense to put the logic to figure out which > one to run in one place than many. If the runit users want to add > their own logic they could. IMO it would be potentially useful, even > if you and I don't personally have much use for it. > > That said, the sorts of people most likely to benefit probably don't > use Gentoo in the first place. > > In any case, arguing over whether it is useful is putting the cart > before the horse. It doesn't matter if it is useful if nobody bothers > to build it. If nobody has that much of an itch to scratch then how > useful could it be? > Great points. It'll be much easier to decide on something when/if there is something concrete to work with. There isn't much stopping a package from making it into Gentoo. If there is demand, it'll be written. -- Daniel Campbell - Gentoo Developer, Trustee, Treasurer OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Providing a `service` scripts that speaks OpenRC and systemd
On Thu, Sep 28, 2017 at 11:32 PM, Ulrich Mueller wrote: >> 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 sysvinit and systemd via >> init-system-helpers CentOS/Fedora: provides support for systemd via >> initscripts OpenSUSE: has a working service binary for systemd >> (according to #suse) > > There is "eselect rc" which could be easily extended to support > systemd. Patches are welcome. :) > ++ Honestly, I could see the argument for having a generic "service" command because that is what everybody else does, but there is little point in arguing about the name of the file when nobody has bothered to write it yet. If somebody writes such a tool and it proves useful, we can always have the discussion about refactoring. To minimize list replies I'll tackle one of Duncan's points - he was debating whether you really need this vs just using systemctl. The obvious use case is scripts that are intended to support multiple init systems - it makes far more sense to put the logic to figure out which one to run in one place than many. If the runit users want to add their own logic they could. IMO it would be potentially useful, even if you and I don't personally have much use for it. That said, the sorts of people most likely to benefit probably don't use Gentoo in the first place. In any case, arguing over whether it is useful is putting the cart before the horse. It doesn't matter if it is useful if nobody bothers to build it. If nobody has that much of an itch to scratch then how useful could it be? -- Rich
Re: [gentoo-dev] Re: sys-libs/ncurses: erronious deletion of *.dll.a files; possibly other packages affected
Dnia 29 września 2017 11:29:03 CEST, Michael Haubenwallner
napisał(a):
>On 09/29/2017 10:33 AM, Marty E. Plummer wrote:
>> On Fri, Sep 29, 2017 at 08:29:07AM +, Michael Haubenwallner
>wrote:
>>> On 09/29/2017 03:36 AM, Marty E. Plummer wrote:
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 explicit fix in sys-libs/ncurses and other
>ebuilds
>> that may require it.
>
> I think the solution here is to remove those overly broad "find
> -delete" statements and replace them with something safer.
>
> Ideally the build system(s) would be patched to not compile static
> libs in the first place.
>
> If that's not possible, perhaps an eclass function could be
>created to
> safely remove static libs.
>
Honestly I already have a pr up that fixes this particular
>package's
issue, fairly simple fix https://github.com/gentoo/gentoo/pull/5734
--- a/sys-libs/ncurses/ncurses-6.0-r1.ebuild
+++ b/sys-libs/ncurses/ncurses-6.0-r1.ebuild
@@ -241,7 +241,8 @@ multilib_src_install() {
# Provide a link for -lcurses.
ln -sf libncurses$(get_libname)
>"${ED}"/usr/$(get_libdir)/libcurses$(get_libname) || die
fi
- use static-libs || find "${ED}"/usr/ -name '*.a' -delete
+ # don't delete '*.dll.a', needed for linking #631468
+ use static-libs || find "${ED}"/usr/ -name '*.a' ! -name
>'*.dll.a' -delete
>>>
>>> In prefix overlay we have this version:
>>>
>>> use static-libs || find "${ED}"/usr/ -name '*.a' -not -name
>"*$(get_libname)" -delete
>>>
>> Won't work here, as $(get_libname) returns .dll in this case, which
>is
>> why the symlinking is busted
>
>Indeed! Although I do believe get_libname should return the
>(dynamically) linkable file
>name rather than the dynamically loadable one, because a build system's
>target often is
>the dynamically linkable file, creating the loadable as side effect.
>Note that only COFF
>based systems (AIX, Windows) may distinguish (dynamically) linkable and
>loadable files.
Why not add a separate function to avoid this ambiguity?
>
>Additionally (although unused in Prefix), AIX allows for one single
>file libN.a containing
>Shared Objects, which can be statically linked too!
>
>And for winnt I've yet to decide the value for $(get_libname) as the
>Import Library:
>Candidates are ".so", ".dll.a", ".dll.lib" - as I do support all of
>them in the msvc
>wrapper ("parity") to reduce the need of patching various build systems
>for now...
>
>So probably the real safe one here is (in case get_libname may return
>".a"):
>
>use static-libs || find "${ED}"/usr/ -name '*.a' -not -name '*.dll.a'
>-not -name "*$(get_libname)" -delete
>
>OR: Really have some function prune_static_libs to remove library files
>serving as
>Static Library only - neither as Import Library nor Shared Library:
>Implemented
>for some platforms to ignore the file name but inspect the content
>instead.
>
>Remember: This is (related but) different from prune_libtool_libs,
>which suggests the find "${D}" -name '*.la' -delete alternative only.
>
>/haubi/
--
Best regards,
Michał Górny (by phone)
[gentoo-dev] Re: Providing a `service` scripts that speaks OpenRC and systemd
Harald Weiner posted on Fri, 29 Sep 2017 04:47:35 +0200 as excerpted: > 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 instructions they're following is actually >> appropriate to the situation and the environment they're working in? > > Well, I think I understand what you want to say but actually your > argument sounds a little bit strange. > Gentoo is about choice, right? So a Gentoo user has the ability to > choose between OpenRC or SystemD init systems (by the way, many thanks > to the Gentoo developers for making this possible). But some > developer(s) might provide a package with a wrapper tool so that instead > of manual "translation" to your init system, you can just use type $ > service start And some users might want to use this package. > So I do not see the problem, as long as nobody forces you to use the > service tool. Actually, it adds a new choice for users: Either they use > the service-tool or they invoke their init system commands as they have > always done. That's not far from what I said, I don't oppose a separate "service" package, I simply don't see the need. But a want isn't a need, which is where your "choice" argument comes in. =:^) As long as it doesn't get added to @system or become a hard dep (direct or indirect) of something in @system, and preferably doesn't become a hard dep of anything, tho a USE-controlled dep is fine. Because that would turn the choice argument on its head, which is what I'm afraid of. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
[gentoo-dev] Re: sys-libs/ncurses: erronious deletion of *.dll.a files; possibly other packages affected
On 09/29/2017 10:33 AM, Marty E. Plummer wrote:
> On Fri, Sep 29, 2017 at 08:29:07AM +, Michael Haubenwallner wrote:
>> On 09/29/2017 03:36 AM, Marty E. Plummer wrote:
>>> 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 explicit fix in sys-libs/ncurses and other ebuilds
> that may require it.
I think the solution here is to remove those overly broad "find
-delete" statements and replace them with something safer.
Ideally the build system(s) would be patched to not compile static
libs in the first place.
If that's not possible, perhaps an eclass function could be created to
safely remove static libs.
>>> Honestly I already have a pr up that fixes this particular package's
>>> issue, fairly simple fix https://github.com/gentoo/gentoo/pull/5734
>>>
>>> --- a/sys-libs/ncurses/ncurses-6.0-r1.ebuild
>>> +++ b/sys-libs/ncurses/ncurses-6.0-r1.ebuild
>>> @@ -241,7 +241,8 @@ multilib_src_install() {
>>> # Provide a link for -lcurses.
>>> ln -sf libncurses$(get_libname)
>>> "${ED}"/usr/$(get_libdir)/libcurses$(get_libname) || die
>>> fi
>>> - use static-libs || find "${ED}"/usr/ -name '*.a' -delete
>>> + # don't delete '*.dll.a', needed for linking #631468
>>> + use static-libs || find "${ED}"/usr/ -name '*.a' ! -name '*.dll.a'
>>> -delete
>>
>> In prefix overlay we have this version:
>>
>> use static-libs || find "${ED}"/usr/ -name '*.a' -not -name
>> "*$(get_libname)" -delete
>>
> Won't work here, as $(get_libname) returns .dll in this case, which is
> why the symlinking is busted
Indeed! Although I do believe get_libname should return the (dynamically)
linkable file
name rather than the dynamically loadable one, because a build system's target
often is
the dynamically linkable file, creating the loadable as side effect. Note that
only COFF
based systems (AIX, Windows) may distinguish (dynamically) linkable and
loadable files.
Additionally (although unused in Prefix), AIX allows for one single file libN.a
containing
Shared Objects, which can be statically linked too!
And for winnt I've yet to decide the value for $(get_libname) as the Import
Library:
Candidates are ".so", ".dll.a", ".dll.lib" - as I do support all of them in the
msvc
wrapper ("parity") to reduce the need of patching various build systems for
now...
So probably the real safe one here is (in case get_libname may return ".a"):
use static-libs || find "${ED}"/usr/ -name '*.a' -not -name '*.dll.a' -not
-name "*$(get_libname)" -delete
OR: Really have some function prune_static_libs to remove library files serving
as
Static Library only - neither as Import Library nor Shared Library: Implemented
for some platforms to ignore the file name but inspect the content instead.
Remember: This is (related but) different from prune_libtool_libs,
which suggests the find "${D}" -name '*.la' -delete alternative only.
/haubi/
[gentoo-dev] Re: sys-libs/ncurses: erronious deletion of *.dll.a files; possibly other packages affected
On Fri, Sep 29, 2017 at 08:29:07AM +, Michael Haubenwallner wrote:
> On 09/29/2017 03:36 AM, Marty E. Plummer wrote:
> > 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 explicit fix in sys-libs/ncurses and other ebuilds
> >>> that may require it.
> >>
> >> I think the solution here is to remove those overly broad "find
> >> -delete" statements and replace them with something safer.
> >>
> >> Ideally the build system(s) would be patched to not compile static
> >> libs in the first place.
> >>
> >> If that's not possible, perhaps an eclass function could be created to
> >> safely remove static libs.
> >>
> > Honestly I already have a pr up that fixes this particular package's
> > issue, fairly simple fix https://github.com/gentoo/gentoo/pull/5734
> >
> > --- a/sys-libs/ncurses/ncurses-6.0-r1.ebuild
> > +++ b/sys-libs/ncurses/ncurses-6.0-r1.ebuild
> > @@ -241,7 +241,8 @@ multilib_src_install() {
> > # Provide a link for -lcurses.
> > ln -sf libncurses$(get_libname)
> > "${ED}"/usr/$(get_libdir)/libcurses$(get_libname) || die
> > fi
> > - use static-libs || find "${ED}"/usr/ -name '*.a' -delete
> > + # don't delete '*.dll.a', needed for linking #631468
> > + use static-libs || find "${ED}"/usr/ -name '*.a' ! -name '*.dll.a'
> > -delete
>
> In prefix overlay we have this version:
>
> use static-libs || find "${ED}"/usr/ -name '*.a' -not -name
> "*$(get_libname)" -delete
>
> /haubi/
Won't work here, as $(get_libname) returns .dll in this case, which is
why the symlinking is busted
[gentoo-dev] Re: sys-libs/ncurses: erronious deletion of *.dll.a files; possibly other packages affected
On 09/29/2017 03:36 AM, Marty E. Plummer wrote:
> 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 explicit fix in sys-libs/ncurses and other ebuilds
>>> that may require it.
>>
>> I think the solution here is to remove those overly broad "find
>> -delete" statements and replace them with something safer.
>>
>> Ideally the build system(s) would be patched to not compile static
>> libs in the first place.
>>
>> If that's not possible, perhaps an eclass function could be created to
>> safely remove static libs.
>>
> Honestly I already have a pr up that fixes this particular package's
> issue, fairly simple fix https://github.com/gentoo/gentoo/pull/5734
>
> --- a/sys-libs/ncurses/ncurses-6.0-r1.ebuild
> +++ b/sys-libs/ncurses/ncurses-6.0-r1.ebuild
> @@ -241,7 +241,8 @@ multilib_src_install() {
> # Provide a link for -lcurses.
> ln -sf libncurses$(get_libname)
> "${ED}"/usr/$(get_libdir)/libcurses$(get_libname) || die
> fi
> - use static-libs || find "${ED}"/usr/ -name '*.a' -delete
> + # don't delete '*.dll.a', needed for linking #631468
> + use static-libs || find "${ED}"/usr/ -name '*.a' ! -name '*.dll.a'
> -delete
In prefix overlay we have this version:
use static-libs || find "${ED}"/usr/ -name '*.a' -not -name "*$(get_libname)"
-delete
/haubi/
