Re: [DNG] Packaging Vdev
On 05/03/16 14:31, aitor_czr wrote: > Hi Daniel, Didier > >> Le 14/03/2016 00:07, Daniel Reurich a Ć©crit : >>> > I'd suggest using a version like: >>> > 0.1.jude+>> > >>> > That way when Jude does switch to versioned releases we can assume his >>> > version scheme easily assuming that he starts with > 0.1. > > Something like this? > > 0.1.20160314+1deb1 > > I was purposing something like this: > > 0.1.d5d965-jessie1 > Isn't this one of the typical use-cases of the "epoch" field in debian version strings? https://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Version Sorry if I repeat something that has been mentioned already, I didn't follow the whole thread. -- Mat signature.asc Description: OpenPGP digital signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Apparently Jessie has runit
On 21/01/16 11:20, Simon Hobson wrote: > Daniel Reurich wrote: > >> perhaps doing the same thing as init-system-helpers dh_systemd package >> to add support for runit into each respective package. > > That's the logical way to do it - the init script(s) should be part of the > package. The downside of that is the requirement for every package maintainer > (team) to understand and support multiple init systems - or for someone > supporting an init system to become a maintainer on lots of packages. Indeed this is a much better way, and it also guarantees that init scripts remain in sync as packages receive updates. -- Mat signature.asc Description: OpenPGP digital signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Apparently Jessie has runit
On 20/01/16 20:57, Steve Litt wrote:
> People aren't completely alone on run scripts: I can give them any run
> scripts I'm using. Also, Runit run scripts are *nothing* like sysvinit
> or OpenRC init scripts: Most are five lines or less, few are over 10
> lines.
As I mentioned before, I run quite a bunch of Debian servers (wheezy and
jessie) with runit as both process supervisor and init system. To
simplify deployment I wrote small debian packages for my run scripts.
It's definitely not production ready, but it's been working for me for
years.
My packages work by diverting the original /etc/init.d/XX script and
replacing it with a link to /usr/bin/sv, so it's plugs in quite nicely
in debian (i.e. you can still call /etc/init.d/XX {start|stop}).
If anyone want to have a look at a possible way of integrating runit
with debian and experiment with it, I have an apt repository[1] and the
sources online[2].
[1] https://parad0x.org/apt/
[2] https://parad0x.org/git/debian-run/
I'm not sure that this kind of packaging is the way forward for devuan
though, it can be heavy to have to maintain sysv startup scripts and run
scripts for all services. I'd love to have a discussion on supporting
multiple init systems at some point (after stable is released).
PS: watch out with the runit-init package, it's a bit brutal/broken,
since it replaces /sbin/{reboot|halt|shutdown} with runit equivalents,
it's tricky to do a clean initial reboot after the package is installed
when the system still runs from sysvinit. I'll fix this when I get the time.
Cheers,
--
Mat
signature.asc
Description: OpenPGP digital signature
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] int essid_alloc is causing valgrind to report a series of errors
Is there a reason why you need to write such a wrapper around calloc()?
It adds very little since calloc already sets errno. Plus it's a rather
unnatural construct for an allocator to return the allocated buffer this
way.
if ((err = essid_alloc(len, &buf)) != 0)
handle_error(err);
if (!(buf = calloc(1, len)))
handle_error(errno);
I didn't follow the discussion, just looking at this code without context.
On 14/10/15 15:37, Edward Bartolo wrote:
> Dear All,
>
> The problem according to my logic seems to be result is used in a
> branch control expression before it is initialised. However, I am
> emailing this to have other opinions.
>
>
> int essid_alloc(
> size_t length,
> char ** result
> ) {
> char * tmp;
>
> if(length==0 || !result)
> return EINVAL;
>
> tmp = (char *) calloc(length, 1);
>
> if(!tmp)
> return ENOMEM;
>
> *result = tmp;
>
> return 0;
> }
--
Mat
signature.asc
Description: OpenPGP digital signature
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] startup scripts (was dng@lists.dyne.org)
On 18/07/15 12:42, Fred DC wrote: > On 18/07/2015 10:49, Laurent Bercot wrote: >> >> Believe me, providing sysv-rc compatibility when you're working on >> a supervision suite is no small feat: the paradigm is very different, >> >> . If it was easy, we would have provided compatibility packages >> long ago, and supervision would already rule the world (with a gentle, >> good hand). >> > > I am not saying that runit is better as s6 - all I want to point out is > that debian runit, until recently, intergrates fairly well with sysv-rc. > > Yes, the supervised services do need their own service-framework with > their own scripts. For me (as a simple user) the hard nut to crack was > to write stubs and a script which during a debian-update translate the > inet-calls to sv-calls without insserv telling me to take a hike. I solved this issue by diverting the original package's startup script and replacing it with a symlink to /usr/bin/sv in the postinst's scripts. As an example here is the postinst script of my nginx-run package: http://parad0x.org/git/debian-run/nginx-run/tree/debian/postinst I also patched insserv to recognise and ignore symlinks to /usr/bin/sv to make this work nicely. The patch is here: http://parad0x.org/git/debian-run/insserv/ Native support for alternative init systems would hopefully obsolete the need for these kind of tweaks, but in the meantime they make for a very smooth integration of runnit with debian. I haven't tried s6 yet, but it's on my bucket list. -- Mat ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Proposed defaults changes
On 15/07/15 02:59, Franco Lanza wrote: > More than the already know switch from gnome to xcfe4 as the default > desktop and the oblovious change to sysvinit instead of systemd, i would > to propose some other default changes in the standard install: > > nano -> vim I think that one of the objective of the standard install is to keep it as simple and small as possible. Installing vim from the minimal install pulls something like 30M of extra stuff. I don't think that this is acceptable, think of embedded systems or containers that probably don't even need a text editor at all. The minimal install already comes with both nano and vim-tiny. Honestly I don't understand nano, it's probably the first thing that I purge from a fresh install, but I can also understand that some people aren't comfortable with vi, especially unix newcomers. I'm happy with the current situation (nano + vim-tiny) in the default install, it's still small, satisfies the immediate post-install needs of most users, and all packages are just one apt-get away anyway. > exim -> postfix Again, what's the difference in size? What are the requirements for a default mail server? I believe that the default mta is something that you don't necessarily want, per se, but gets pulled when some other package needs an mta. Probably in that case the mta would only be rquired to deliver local mails (think of cron) and send mails via a relay. I believe it should be something small and simple. If you want a real mta, then you'd install the one that you actually want to use, not the default. I've never used exim so I don't know how does it fit with this line of reasoning, but there are others like dma that look like good candidates to me. -- Mat ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] bummer
On 06/07/15 16:05, Stanley Webb wrote: > I wish I never installed Jessie, I wish I could reinstall Wheezy. > Could Devuan, set up wheezy repos till your first stable release? The wheezy repos are still online and will be for a while (depending on the LTS team). Use debootstrap or multistrap. https://wiki.debian.org/Debootstrap -- Mat ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Packages aren't the only path to alternate inits
On 18/06/15 13:47, Didier Kryn wrote: > > [...] > >> I wonder if now is the time to start separating out the init specific >> configuration files, initscripts or service files, libraries and >> binaries out into separate packages so that any particular init can be >> supported without treading on the toes of others. The only issue I >> can see with this is the dependency chain can get a bit hairy. >> >> I expect the dependency chain should be something like: >> depends on: init, -sysv-init | -epoch-init | >> -systemd-init | -openrc-init | -upstart-init >> >> And if each of those -*-init packages depended on their >> respective init system, and each of those init systems provide the >> virtual package "init" (as is the case in Debian and Devuan Jessie), >> then apt should be able to work out that when installing that >> because sysvinit-core is the package providing init that it must also >> install -sysv-init in order to satisfy the dependency. The >> problem is whether changing init systems would result in pulling in >> the new -*-init dependency required for the new init system. >> >> Thoughts?? >> > > This is the normal way of implementing this kind of multiple > alternative dependencies in Debian, AFAIU. The only reason I did not > advocate this before is that it would bring in a bunch of new packages > each containing only one small file. But this might not be a big deal > after all, considering it solves the problem completely, allows to get > rid of the irritating systemd service files, and treats all other init > systems equally. > > I support this idea. > Didier I've been using something similar with runit for years: one debian package for each service that contains only the run scripts, some dependency statements, and compatibility scripts for a clean integration with debian (essentially dropping replacement for traditional sysvinit scripts in /etc/init.d/). I generally use sysvinit+runit on servers, but recently I started Šµxperimenting with runit as init replacement and it's been a smooth ride so far. I've got packages for that as well but they've not really been tested much (not on production servers). My packages were meant only for my personal use but I'm slowly cleaning up the whole thing and putting it online so it could be useful to other people (pushed by the systemd cabale): git sources: http://parad0x.org/git/debian-run/ apt repository: http://parad0x.org/apt/ So in general I think that this approach - moving init system specific things out of the main package and providing one package per init system - is a good way of supporting multiple init systems. For instance: openssh-server - the ssh daemon, stripped of its startup script openssh-server-sysv- the traditional sysvinit startup scripts openssh-server-run - startup scripts for runit openssh-server-epoch - startup scripts for epoch openssh-server-openrc - startup scripts for OpenRC openssh-server-systemd - why not? etc.. It isn't so much work really if it's done in a systematic way. Most of the work went in the postinst/prerm scripts to stop/start the service, and remove/restore the traditional sysv init file: things that wouldn't be necessary if the service package was stripped of the sysv scripts. I know that supporting multiple init systems isn't on the priority list for devuan, but in the longer term I think it would be a nice feature. -- Mat -- Mat signature.asc Description: OpenPGP digital signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
