Re: [DNG] Devuan Jessie 1.0.0 stable release candidate

2017-04-21 Thread Martin Steigerwald 
Dear Veteran Unix Admins, dear Devuan developers and testers,

Veteran Unix Admins - 21.04.17, 18:14:
> Once again the Veteran Unix Admins salute you!
> 
> Our April 2017 gift to you is the long-awaited release of Devuan
> Jessie stable release candidate (1.0.0-RC). If all goes as planned,
> this will be our first Devuan stable release and our first long term
> support (LTS) release as well.

Thank you. I am seriously impressed.

I think there were many who tought you might not make it. But you did. You 
showed the perseverance to actually finish the release candidate.

You made a distro based on Debian which can be run without Systemd, providing 
choice.

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

Re: [DNG] Devuan Jessie 1.0.0 stable release candidate

2017-04-21 Thread Emiliano Marini 
Great work!!

On Fri, Apr 21, 2017 at 4:30 PM, Svante Signell 
wrote:

> On Fri, 2017-04-21 at 18:14 +0200, Veteran Unix Admins wrote:
> > Dear Init Freedom Lovers,
> >
> > Once again the Veteran Unix Admins salute you!
> >
> > Our April 2017 gift to you is the long-awaited release of Devuan
> > Jessie stable release candidate (1.0.0-RC). If all goes as planned,
> > this will be our first Devuan stable release and our first long term
> > support (LTS) release as well.
>
> Good work :) Thanks to all of you involved. I'll definitely try to be a
> (more active) contributor to the ascii and ceres releases.
>
> Thanks a lot again. More of my boxes will be moved from Debian to
> Devuan in due time. Keep up the good work!
> ___
> 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-21 Thread karl 
Enrico Weigelt:
> 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,

a, If you have that impression, then why daemonize() which sounds as
   the same thing ?

b, No it isn't. That's why the -f, which is nice to have when debugging.

> and there might be some need for anyone doing something these.

The any other thing I can think of is running in the foreground and
"logging" to stdout/stderr, and possible being able to receive
commands via stdin.

> 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 ...).

 if (do_daemon) { daemon(0,0); }

isn't much code to justify a lib entry, so what else is there in it to 
lure a daemon writer to use it ?

> That '-f' switch would be in
> the lib in a different form, eg. via env variables.

Yes, it's messier to pick just the -f from argc/argv in a lib than
calling getenv().

> 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.
...

Well, that's fine, but replaceing -f and daemon() with your entry 
doesn't seem worth it. Maybe it's better to write up some
"best practices" ?

> 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.

Then perhaps it's better to make it easier to use "standard"
command line options, and put that in a lib. E.g. a few funcs. that
parses argc/argv according to some data, extracts values, puts in
default values, prints error messages, usage text or version
strings without all the usual mess with option handling.

> > 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.

I think it is more fruitful in that case to write a lib that unifies the
command line, then environment and the config file handling, and make
it easy for the daemon writer to use it. In that kind of lib, you could
include default options for things like to daemon or not, uid/gid,
and where to log things.

I, as a daemon writer can see the value in having that handling defaulted
to some lib, and by it you can introduce default handling for -f and 
--uid/--gid, so a possible monitor can set that what it to whatever it
wants.

Also of value could be a lib that unifies logging, or rather removes the
distinction between logging to syslog(), to a file or to stdout/stderr;
possible with default callback for SIGHUP to reopen/rotate log file.

You have to introduce what you want the other way around.

> > 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.

Yes, and as a intermittent daemon writer, I try to understand why I
should use it. If I cannot find any reason then maybe we should think
of something better.

> 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.

There are two things,
1, the monitor needs
2, the (possible monitored) process/daemon needs

To a daemon writer, point 1 is simply uninteresting. To get point 1
satisfied, you have to provide something that first and formost
fulfill point 2, and by providing for point 2, you in your lib, can
introduce things that makes it easier for the monitor.

So, instead of your proposal, I propose a lib that streamlines the
dull tasks of option/env/config_file, logging, and possible sign

Re: [DNG] Devuan Jessie 1.0.0 stable release candidate

2017-04-21 Thread Svante Signell 
On Fri, 2017-04-21 at 18:14 +0200, Veteran Unix Admins wrote:
> Dear Init Freedom Lovers,
> 
> Once again the Veteran Unix Admins salute you!
> 
> Our April 2017 gift to you is the long-awaited release of Devuan
> Jessie stable release candidate (1.0.0-RC). If all goes as planned,
> this will be our first Devuan stable release and our first long term
> support (LTS) release as well.

Good work :) Thanks to all of you involved. I'll definitely try to be a
(more active) contributor to the ascii and ceres releases.

Thanks a lot again. More of my boxes will be moved from Debian to
Devuan in due time. Keep up the good work!
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Devuan Jessie 1.0.0 stable release candidate

2017-04-21 Thread Don Wright 
Veteran Unix Admins wrote:
>Our April 2017 gift to you is the long-awaited release of Devuan
>Jessie stable release candidate (1.0.0-RC). If all goes as planned,
>this will be our first Devuan stable release and our first long term
>support (LTS) release as well.

\o/ dance-dance-dance \o/ -- Thanks for much hard work.

I see https://devuan.org still shows the old devuan_jessie_beta.torrent
(no longer working) instead of a new .torrent pointing to the RC. The
empty installer-iso/ is sure to get questions as well, as it is
mentioned in the README. 

By the way, http://mirror.math.princeton.edu/pub/devuan/ (listed on
https://devuan.org, not listed on
https://devuan.org/os/mirrors/files.devuan.org) doesn't have the
README.txt files at present.

There is a similar but incomplete list at https://devuan.org/os/mirrors.
Should this link to the same file?

Hope you have a fun weekend anyway.

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

[DNG] Devuan Jessie 1.0.0 stable release candidate

2017-04-21 Thread Veteran Unix Admins 
Dear Init Freedom Lovers,

Once again the Veteran Unix Admins salute you!

Our April 2017 gift to you is the long-awaited release of Devuan
Jessie stable release candidate (1.0.0-RC). If all goes as planned,
this will be our first Devuan stable release and our first long term
support (LTS) release as well.

Two and a half years have passed since our initial Debianfork
declaration (https://devuan.org/os/debian-fork/) and not even one year
since our first beta release
(http://www.linuxjournal.com/content/devuan-beta-release).

This Devuan Jessie release candidate is as close as we can get to a
"long term support" universal base distribution free from systemd, in
the original spirit of Debian.

The final Devuan Jessie release will follow shortly and then we will
turn our attention to "Ascii", the current testing branch.

We wish to thank all of you for the incredible support given to this
development effort, and for engaging in the process of making Devuan a
useful and reliable base distro, as well as a pleasant, cooperative
community.


# What has improved in Devuan Jessie

The wifi autodetection problems present in the beta release series
have been fixed.

The problem that prevented samba from installing has been fixed.

Devuan now directly provides different base distribution flavours:
desktop-live (finally the purpy experience), embedded, minimal-live
and installer-iso.

Devuan's Simple Distro Kit (SDK) is rapidly approaching maturity, with
a full set of scripts and documentation to roll your own Devuan-based
distro in any flavor.  (https://dev1galaxy.org/viewtopic.php?id=551)

The Refracta scripts are now included in Devuan, which makes it easy
to toast a new live distro from the state of a running one.

Devuan's infrastructure is now powered by the 'debbugs' bug tracking
system originally written by Ian Jackson, and the 'reportbug' tool
works as expected.

Package maintenance has been demystified and partially automated with
d1h - the Devuan packaging helper
(https://dev1galaxy.org/viewtopic.php?id=549) - which simplifies the
task of interacting with the Devuan continuous integration pipeline
and makes it easier for developers to package their projects for
Devuan correctly. Please consider rolling up your sleeves and joining
the development team!

ARM support has improved: Devuan now provides base SD card images for
11 different hardware platforms: raspi1, raspi2, raspi3, chromeacer,
chromeveyron, cubieboard2, cubietruck, lime2, micro, N900,
odroidxu. When applicable (sunxi boards) ARM images are powered by
mainline 4.10.y Linux kernels.

# Downloads

Official Devuan images are distributed via the website
(https://files.devuan.org/devuan_jessie_rc/)

To ease the load on our bandwidth we kindly ask you to use one of the
following mirrors:

- http://mirror.leaseweb.com/devuan
- http://devuan.ksx4system.net
- http://tux.rainside.sk/devuan
- http://nluug.nl/pub/os/Linux/distr/devuan
- http://devuan.c3l.lu
- http://neo900.files.dev-1.org
- http://devuan.4isp.it
- http://mirror.math.princeton.edu/pub/devuan/
- http://devuan.mirror.k0nsl.org/
- ftp://mirror.leaseweb.com/devuan
- ftp://ftp.nluug.nl/pub/os/Linux/distr/devuan

All files offered for download come with their SHA256 hash to check
the integrity (either in the SHA256SUMS or in the .sha files) and with
a cryptographic signature made using GnuPG by one of the Devuan
developers in charge of the build, included as .asc file.

An understanding of Devuan's script-friendly file naming scheme and
directory structure will help you find what you
need. (https://devuan.org/os/filenaming)

# Related projects

Here is a short list of projects which use Devuan as a base OS for
their research and development:

Dowse - the IoT awareness Hub which won the ISOC NL Innovation prize
2016 is based on Devuan and just released its 1.0 beta:
https://dowse.eu

DECODE - An R&D project on data sovereignty and blockchain technology
financed with 5M EUR by the EU Commission is based on Devuan:
http://decocodeproject.eu

heads - a live distro focused on privacy, security, and freedoms,
experimenting with Devuan Ascii, and having a workshop @
http://2017.rmll.info: https://heads.dyne.org

## Distributions based on Devuan

In chronological order of appearance:

- Gnuinos  (linux-libre 100% free, GNU review pending)
- Refracta 
- Exe GNU/Linux 
- Nelum-dev1 
- Star 
- heads  (linux-libre 100% free, GNU review pending)
- good-life-linux 
- Crowz 

# Upgrade

Devuan can be adopted as a flawless upgrade path from both Debian
Wheezy and Jessie. This is a main goal for the Devuan Jessie stable
release and has proven to be a very stable operation every time it has
been p

Re: [DNG] apulse in experimental

2017-04-21 Thread ael 
On Fri, Apr 21, 2017 at 09:28:34AM +1000, Royal Ozma of Oz wrote:
> 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"

> > >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 really should have checked that, but the man pages for mplayer & mpv
are so long, I fear that I have never managed to get through
everything :-) It looks as if mpv has similar options.

Thanks for finding this.

But I do wonder whether there are other programs that will seek
some pulseaudio libary before alsa without such overrides, in which
case there might be problems.

ael

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

Re: [DNG] apulse in experimental

2017-04-21 Thread KatolaZ 
On Thu, Apr 20, 2017 at 10:19:35PM -0400, Hendrik Boom wrote:
> On Fri, Apr 21, 2017 at 10:55:57AM +1000, Ozi Traveller wrote:
> > Hi KatolaZ
> > 
> > Yes it works in Jessie!
> > 
> > Thanks
> > 
> > Ozi
> > 
> > On Fri, Apr 21, 2017 at 6:42 AM, KatolaZ  wrote:
> > 
> > > 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.
> 
> But if it's not going to be in Jessie, perhaps it could be backported 
> to Jessie? 
> 

Hi Hendrik,

yes, it definitely could.

HND

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-21 Thread Hendrik Boom 
On Fri, Apr 21, 2017 at 10:55:57AM +1000, Ozi Traveller wrote:
> Hi KatolaZ
> 
> Yes it works in Jessie!
> 
> Thanks
> 
> Ozi
> 
> On Fri, Apr 21, 2017 at 6:42 AM, KatolaZ  wrote:
> 
> > 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.

But if it's not going to be in Jessie, perhaps it could be backported 
to Jessie? 

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