Re: [DNG] apulse in experimental

2017-04-20 Thread Ozi Traveller 
Hi KatolaZ

Yes it works in Jessie!

Thanks

Ozi

On Fri, Apr 21, 2017 at 6:42 AM, KatolaZ  wrote:

> On Fri, Apr 21, 2017 at 06:04:31AM +1000, Ozi Traveller wrote:
> > Hi KatolaZ
> >
> > How long before apulse hits stable?
> >
>
> Hi Ozi,
>
> the apulse package will never "hit stable", if by stable you mean
> Devuan Jessie. Devuan Jessie will only have packages which are already
> present in Debian Jessie, with matching versions, with all the systemd
> dependencies removed. All the development will happen starting from
> ascii.
>
> My guess is that, if everything goes well, apulse will transit to
> unstable at some point, and then percolate down to ascii, if and when
> it will be ready for ascii, as any other new package that enters
> Devuan.
>
> Nevertheless, you can already install the version of apulse present in
> the experimental repo. It has been tested in Devuan jessie ;)
>
> My2Cents
>
> KatolaZ
>
> --
> [ ~.,_  Enzo Nicosia aka KatolaZ - GLUGCT -- Freaknet Medialab  ]
> [ "+.  katolaz [at] freaknet.org --- katolaz [at] yahoo.it  ]
> [   @)   http://kalos.mine.nu ---  Devuan GNU + Linux User  ]
> [ @@)  http://maths.qmul.ac.uk/~vnicosia --  GPG: 0B5F062F  ]
> [ (@@@)  Twitter: @KatolaZ - skype: katolaz -- github: KatolaZ  ]
>
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] apulse in experimental

2017-04-20 Thread Royal Ozma of Oz 

I think that there is a workaround for mplayer to force it to use ALSA:

It can be made by adding the file "~/.mplayer/config" with these lines:

# Write your default config options here!
ao="alsa"
softvol="true"
volume="15"

The final two lines are optional, but should be considered to prevent 
mplayer from maxing out the hardware volume controls & blasting the 
headphones.
Now, need someone to port bluetooth-alsa on the recent bluez to work 
without needing pulseaudio or buying a suitable third party USB dongle.



On 04/19/2017 08:40 PM, ael wrote:

On Wed, Apr 19, 2017 at 01:22:52AM +0100, KatolaZ wrote:

Dear Devuaners,

just to let you know that a .deb package for apulse is now available
in experimental (except for armel: I am working on that). Just add the
repo:

   deb http://packages.devuan.org/devuan/ experimental main

Good, but has anything been done to make it compatible with mpv,
mplayer (etc)? They seem to dynamically link to libpulse-simple.so
which results in a disasterous degradation in performance rendering them
pretty much useless.

I am not sure how or why these programs are selecting libpulse-simple.so
.

As of now, installing apulse breaks these programs.

ael


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng


--
David E. Down
The Regal Faery Monarch
The Serene Royal Highness Ozma of Oz.
(etc)

--- INSERT BTC CODE ---
13CNSC1k3C4kQXWGdxAqWo93HD8UZ1kS51

--- INSERT GEEK CODE ---
javascript:void(document.onmousedown=null);void(document.onmouseup=null);void(document.onclick=null);void(document.oncontextmenu=null);void(document.onselectstart=null);

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] apulse in experimental

2017-04-20 Thread Ozi Traveller 
Awesome thanks Ismael!

Ozi

On Fri, Apr 21, 2017 at 6:29 AM, Ismael L. Donis Garcia 
wrote:

> - Original Message - From: Ozi Traveller
>> To: hal
>> Cc: dng
>> Sent: Thursday, April 20, 2017 4:04 PM
>> Subject: Re: [DNG] apulse in experimental
>>
>>
>> Hi KatolaZ
>>
>>
>> How long before apulse hits stable?
>>
>>
>> Ozi
>>
>>
>> On Thu, Apr 20, 2017 at 8:29 PM, hal  wrote:
>>
>> KatolaZ wrote on 04/18/2017 07:22 PM:
>>
>>> Dear Devuaners,
>>>
>>> just to let you know that a .deb package for apulse is now available
>>> in experimental (except for armel: I am working on that). Just add the
>>> repo:
>>>
>> 
>>
>>
>> It's working great! Thank you sooo much!
>> ___
>> Dng mailing list
>> Dng@lists.dyne.org
>> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
>>
>
>
> I do not think so much about stable as on testing that very soon for
> Debian will be stable.
>
> Best regards
> 
> | ISMAEL |
> 
>
>
> ___
> Dng mailing list
> Dng@lists.dyne.org
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
>
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] apulse in experimental

2017-04-20 Thread KatolaZ 
On Fri, Apr 21, 2017 at 06:04:31AM +1000, Ozi Traveller wrote:
> Hi KatolaZ
> 
> How long before apulse hits stable?
> 

Hi Ozi,

the apulse package will never "hit stable", if by stable you mean
Devuan Jessie. Devuan Jessie will only have packages which are already
present in Debian Jessie, with matching versions, with all the systemd
dependencies removed. All the development will happen starting from
ascii.

My guess is that, if everything goes well, apulse will transit to
unstable at some point, and then percolate down to ascii, if and when
it will be ready for ascii, as any other new package that enters
Devuan.

Nevertheless, you can already install the version of apulse present in
the experimental repo. It has been tested in Devuan jessie ;)

My2Cents

KatolaZ

-- 
[ ~.,_  Enzo Nicosia aka KatolaZ - GLUGCT -- Freaknet Medialab  ]  
[ "+.  katolaz [at] freaknet.org --- katolaz [at] yahoo.it  ]
[   @)   http://kalos.mine.nu ---  Devuan GNU + Linux User  ]
[ @@)  http://maths.qmul.ac.uk/~vnicosia --  GPG: 0B5F062F  ] 
[ (@@@)  Twitter: @KatolaZ - skype: katolaz -- github: KatolaZ  ]


signature.asc
Description: Digital signature
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] apulse in experimental

2017-04-20 Thread Ismael L. Donis Garcia 
- Original Message - 
From: Ozi Traveller

To: hal
Cc: dng
Sent: Thursday, April 20, 2017 4:04 PM
Subject: Re: [DNG] apulse in experimental


Hi KatolaZ


How long before apulse hits stable?


Ozi


On Thu, Apr 20, 2017 at 8:29 PM, hal  wrote:

KatolaZ wrote on 04/18/2017 07:22 PM:

Dear Devuaners,

just to let you know that a .deb package for apulse is now available
in experimental (except for armel: I am working on that). Just add the
repo:




It's working great! Thank you sooo much!
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng



I do not think so much about stable as on testing that very soon for Debian 
will be stable.


Best regards

| ISMAEL |



___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] apulse in experimental

2017-04-20 Thread Ozi Traveller 
Hi KatolaZ

How long before apulse hits stable?

Ozi

On Thu, Apr 20, 2017 at 8:29 PM, hal  wrote:

> KatolaZ wrote on 04/18/2017 07:22 PM:
> > Dear Devuaners,
> >
> > just to let you know that a .deb package for apulse is now available
> > in experimental (except for armel: I am working on that). Just add the
> > repo:
> 
>
>
> It's working great! Thank you sooo much!
> ___
> Dng mailing list
> Dng@lists.dyne.org
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
>
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] tiny service state api [WAS: Fwd: init system agnosticism]

2017-04-20 Thread Enrico Weigelt, metux IT consult 
On 18.04.2017 12:21, Alessandro Selli wrote:

>   Again, as far as I understood what Enrico Weigelt wrote, the monitor
> does not want to know the user:group the daemons runs under, it needs to
> *set* them to the appropriate values when it launches the daemon to have
> them reflect config file settings or local policies.

Right. In that case, srvmgt_droppriv() would essentially do nothing
(execpt perhaps some logging note).

OTOH, we might have situations where the daemon needs to do some root
operations first (eg. opening privileged sockets) before dropping privs.
In that case the monitor/init can pass the target uid:gid via env, so
it doesn't need to be configured within the application.

>   Again, the relevant info is supposed to be set in config files.  The
> user:group the daemon must run under is not up to the daemon itself,
> they are set in config files, either the deamon's or the monitor's.

Exactly. My approach also gives the choice of passing that from the
init/monitor, even if the application needs to to the setuid() stuff
itself.

At that point we can consolidate all these individual assignments from
dozens of separate configfiles to one place, somewhere within the init
system / service monitor (which ever the operator might have chosen).
In the end, the application doesn't even care about that anymore.

> Again: if you do not want to take advantage of the monitor's policing
> capabilities, don't use them.

Exactly. And ease deployment and configuration for both cases, I'm
just proposing to move these things out of individual applications and
consolidate them in one point (the library). If one doesn't want any
monitor, then he'll just install a minimalistic version, which wouldn't
be much more than dummies or thin wrappers around things like daemon().
Anybody can choose his preferred implementation easily, w/o ever
recompiling or even patching.


--mtx
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] tiny service state api [WAS: Fwd: init system agnosticism]

2017-04-20 Thread Enrico Weigelt, metux IT consult 
On 18.04.2017 14:46, k...@aspodata.se wrote:

> Why srvmgt_daemonize(), use -f and daemon() and you'd be fine in
> either camp, end case.

I've had the impression that daemon() wasnt't good idea for everybody,
and there might be some need for anyone doing something these. So I
proposed to move that out to some library, which the operator easily
replace, w/o touching the application itself. (patching up libc to their
needs isn't quite what operators do ...). That '-f' switch would be in
the lib in a different form, eg. via env variables.

My goal here is not voting for any particular way of daemonizing,
service monitoring, etc, but just to provide an abstraction layer, so
all that stuff can be moved out of the individual application.

All the srvmgt_daemonize() call tells is that after that point the
process will be daemonized - whatever that *actually* means in the
exact setup (which is up to the operator's choice). This is *only* for
the usecase where an service wants to have a straight line at all
(eg. before that it might print out error messages to stdout).
Those who don't need that at all, probably just run in foreground
and delegate daemonizing to the caller (monitor, start-stop-daemon,
etc, etc, etc)

Certainly, everybody can implement the '-f' switch on his own (and it
shouldn't be so difficult), but all of that repeated work (and the
operator's work of reading manpages to find out which exact parameters
he has to pass to an individual program to switch it on/off), could
be saved if there was a single point for that. If you (as a service
author) don't wanna use that, it's still your decision.

> Why srvmgt_droppriv(), either accept that the process set's it itself
> or force it to some uid:gid, what is it more to it ?

It could even detect (eg. via env variables) whether it's already suid'd
and then not even try and fail, it could fetch the target uid/gid from
env, instead of having it's own (application specific) config or cmdline
options. Again, consolidating repeated code into one place. Nothing
more, nothing less. Similiar to srvmgt_daemonize(), it's only meant for
cases where the service can't be started with the final uid/gid in the
first place.

> Why srvmgt_report_state(), just do a normal query to the process and
> you'll know if it is ready to serve you or not, 

There might be cases when the process being alive doesn't necessarily
mean it's ready to serve (usually it takes *some* time). By the call,
the application can tell it to the outside world (however the actual
signalling might happen, and who might listen).

NOTE: I'm just proposing an *API*, *not* an particular implementation.

All I wanna get is that individual applications have an API (and ABI)
to do these things w/o ever having to care whatever init system,
service monitor, etc, there might or might not be. And the actual
implementation shall be replacable w/o ever recompiling applications.



--mtx
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] tiny service state api [WAS: Fwd: init system agnosticism]

2017-04-20 Thread Enrico Weigelt, metux IT consult 
On 18.04.2017 15:15, Arnt Gulbrandsen wrote:

> There's hypothetical stuff, what if service x needs service y. Well,
> what if it does. Should it demand that y be running at every moment and
> on the same host? DOES it demand that?

nfs daemons (plural) need portmap.

many years ago, I've patched portmap to be fully stateless (directly
maintains the table in some state files), so it can even be started
on per-request basis. no idea whether my patches ever went into
mainline ...

> This isn't a good thing to spend effort on. The trend today is towards
> services that require only an OS absolutely. 

In general a good idea (unless they don't duplicate so dozens of things
over and over again). But there're still services out there that have
those constraints - and somehow we gotta cope w/ that.

Of course, often it's just bad sw architecture - just like most of the
stuff that distros have to cope with. We could start w/ dist patches ...


--mtx
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] tiny service state api [WAS: Fwd: init system agnosticism]

2017-04-20 Thread Enrico Weigelt, metux IT consult 
On 18.04.2017 16:08, Alessandro Selli wrote:

Hi folks,

seems that things got a bit overheated here ...

>   Where did Enrico Weigelt write the monitor should get it's child PID
> from the process itself?  This subthread started from these lines:
> 
>>> * srvmgt_droppriv(...)
>>>   --> drop root privileges (if we are still root)
>>>   --> several versions, eg. with fetching the target uid/gid from env
>> Given the pid, it isn't that hard for a monitor to find the uid/gid of 
>> the process, why has this have to go through the monitor ?

Perhaps I should clarify this a bit:

This library functions just shall drop privileges if the process is
still running as root - and therefore might fetch the target uid/gid
from environment (defined by start script, monitor, etc), instead of
fetching from it's own config file. It's just implementing common
repeated stuff in once central place and giving it a uniform interface.
As that library would be provided by $whatever_initsystem, any further
customizations would be done *there* instead of individual applications.

The whole thing only applies to services which *need* to be started as
root, instead of directly under the final uid/gid. (whether such things
are good design at all is a whole different discussion).

> «All daemons detach from the control terminal. The monitor and the
> daemon must coordinate each other about who's doing the detach to avoid
> launch time failures.»

ACK. That's why I would put the code that does all (on the daemon side)
into a separate library, which can be customized to whatever init/
monitor system the operator might choose, and the daemon itself doesn't
need to be touched (not even recompiled) anymore.

In that scenario, each init system (distro) package would provide an
implementation of that library - all of them share the same API/ABI,
so they can be easily replaced, w/o ever having to rebuild any daemon.

> Daemons should behave the same no matter under what monitor they are
> running under, they are not to care about this.

ACK. But there are some points where they potentially need to care
about, eg. who does the actual dataching (unfortunately, there isn't
any ultimate standard) - and I'd like to get rid of individual
per-daemon configuration (in both daemon and monitor) and delegate that
part to a library. The operator (or the init system package maintainer)
is free to put in the appropriate implementation.


--mtx

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] ..timelessness and pricelessness, was: tiny service state api [WAS: Fwd: init system agnosticism]

2017-04-20 Thread Ron 
On Thu, 20 Apr 2017 13:12:07 +0200
Didier Kryn  wrote:

> >> ... I was also been ironic on Aspo, as many times he can
> >> only counter another person's ideas asking "What if 
> >> cannot be trusted?", as if this constitutes a valid argument against  

> > ..."anything new that cannot fail", such as airport security,
> > airliner safety, anti-missile defense, ballot machines, etc...
> > ..if you wanna push some new kinda bling, you must be able to
> > credibly answer such timeless and priceless questions... ;o)

>   These are serious concerns which involve various aspects of security.
> If you need a response of your system within a  given delay and 
> with high security, then I think you should avoid any OS at all and 
> rather program FPGAs.
>   In several cases you mentionned, like ballot, crashing the system 
> is not a big deal; which matters is to not deliver a wrong result. 
> Better crash than give a wrong result.

In other words, always fail safe.
 
Cheers,
 
Ron.
-- 
  The world really isn't any worse.
 It's just that the news coverage is so much better.

   -- http://www.olgiati-in-paraguay.org --
 
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] apulse in experimental

2017-04-20 Thread hal 
KatolaZ wrote on 04/18/2017 07:22 PM:
> Dear Devuaners,
> 
> just to let you know that a .deb package for apulse is now available
> in experimental (except for armel: I am working on that). Just add the
> repo:



It's working great! Thank you sooo much!
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng