Re: start-stop-daemon for user processes
On Sat, Jun 02, 2007 at 10:56:37PM -0600, Warren Turkal wrote: > On Saturday 02 June 2007 21:45, Russ Allbery wrote: > > Take a look at runit. ?It's quite a bit like daemontools without the weird > > licensing. > > Runit doesn't appear to be useful for non-system tasks, like starting jackd > and restarting it if it dies (i.e. on suspend/resume). It is, see http://smarden.org/runit/faq.html#userservices http://smarden.org/runit/faq.html#user Regards, Gerrit. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
binNUMUs - all-depends-any
Hi, I know that the git-core package doesn't support binNMUs, and AFAIK there's no convenient way to change that, as it builds arch: all package that depend on the specific arch: any package. http://bugs.debian.org/423041 Loosening the dependencies as suggested in http://wiki.debian.org/binNMU isn't a good solution, as it can lead to http://bugs.debian.org/425494 Can I register the package as non-binNMUable anywhere?, it needs a sourceful upload anyway. http://bugs.debian.org/430128 Thanks, Gerrit. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: binNUMUs - all-depends-any
On Sat, Jun 23, 2007 at 11:31:49AM +0200, Marc 'HE' Brockschmidt wrote:
> Gerrit Pape <[EMAIL PROTECTED]> writes:
> > Hi, I know that the git-core package doesn't support binNMUs, and AFAIK
> > there's no convenient way to change that, as it builds arch: all package
> > that depend on the specific arch: any package.
> >
> > http://bugs.debian.org/423041
> >
> > Loosening the dependencies as suggested in http://wiki.debian.org/binNMU
> > isn't a good solution, as it can lead to
> >
> > http://bugs.debian.org/425494
>
> Is there a reason why a set of dependencies that only allow package
> versions based on the same upstream version to be installed wouldn't
> work? [1]
> [1] For a package foo-bar, this would mean that deps should be like
> foo-bar (>= 1.2.3), foo-bar (<< 1.2.4~) (or something similiar)
That'd work. I was hoping, with the increased usage of binNMUs, there's
something more convenient than changing debian/control by hand. I'll
now go with
Depends: git-core (>> ${source:Upstream-Version}, git-core (<<
${source:Upstream-Version}-.)
I think.
Regards, Gerrit.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#457318: ITP: qmail -- a secure, reliable, efficient, simple message transfer agent
Hi, packages are available through http://smarden.org/pape/Debian/sid.html Regards, Gerrit. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#500176: This bug is still around and release-critical
On Thu, Oct 09, 2008 at 09:07:00AM +0200, martin f krafft wrote: > also sprach Pierre Habouzit <[EMAIL PROTECTED]> [2008.10.08.1054 +0200]: > > FWIW I've upgraded a machine to replace pdnsd with unbound, it hit that > > bug of course. > [...] > > I don't think this is too hard to ask from someone that is installing > > multiple DNS softwares on the same machine. A bit more user friendly > > steps could help, but well... > > I agree that #500176 needs a more generic solution, but I can't > think of any right now. It would be good to have this as a release > goal. One thing I was thinking of was port-xyz virtual packages, but > that already doesn't work with DNS... Maybe http://thread.gmane.org/gmane.linux.debian.devel.general/87792/focus=88198 Regards, Gerrit. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
qmail and related packages in NEW
Hi, I'm quite surprised how the inclusion of qmail and related packages into sid is handled, or rather not handled, by the ftpmasters. Within a time-frame of six months I received exactly one rejection mail in response to two uploads of the packages, a reply to the rejection mail, and three mails asking about the progress because nothing happened. http://smarden.org/pape/Debian/sid.html#nonprogress Mon, 28 Apr 2008: uploaded packages to ftp-master. Tue, 03 Jun 2008: no response, asking for progress. Tue, 17 Jun 2008: no response, asking again. Sun, 06 Jul 2008: received this REJECT email. Mon, 01 Sep 2008: uploaded updated packages to NEW, and sent a reply. Tue, 11 Nov 2008: no response, asking for progress. Thu, 20 Nov 2008: no response. Today: still no response. Lacking any response, I can only guess what the reason for the delay is. >From my point of view this reason is questionable, and I stated so in my response to the reject mail. Receiving no response within eight weeks tells me that discussing doesn't work. On Mon, Sep 01, 2008 at 10:36:07PM +, Gerrit Pape wrote: > On Sun, Jul 06, 2008 at 02:19:30PM +, Joerg Jaspert wrote: > > Aside from these technical - and possibly fixable - problems, we (as > > in the ftpteam) have discussed the issue, and we are all of the > > opinion that qmail should die, and not receive support from Debian. As > > such we *STRONGLY* ask you to reconsider uploading those packages. > > > > Qmail is dead upstream and requires a whole set of patches to even > > begin to work in the manner expected of a modern MTA. Given this, the > > fact that this means there is also no upstream security support, and > > the fact that Debian already contains at least three reasonable MTAs, > > we see no need to add qmail to the archive. So - please reconsider if > > it really helps Debian to have those packages. Also feel free to start > > a public discussion on debian-devel@lists.debian.org about the issue, > > including any relevant information from this email, in order to gather > > opinions from other project members. > > We all know, I guess, that there's lots of different opinions on the > quality and usability of qmail. There're people thinking like you, and > other people, including me, that have a different opinion. I respect > your opinion, please respect ours too. You're free to not install/use > the packages. I've been contacted by several people since I announced > my intention to package qmail, speaking in favor of the inclusion into > Debian. > > A public discussion already took place > http://thread.gmane.org/gmane.linux.debian.devel.wnpp/69292/ > > I think your advise to start a discussion to gather support for the > packages is backwards. Debian is about free software and users, the > qmail packages are free software, and users request the inclusion into > Debian. If you are interested in not having qmail in Debian, you are > free to start a public discussion to find supporters for your position, > I guess you'll get some objections too. I've no idea where yet another thread on this list should take us. To me the situation is clear. There's a user base for these packages, and a Debian developer ready to maintain them. I count at least three Debian developers speaking in favor of the inclusion, I've been approached by several users asking me to make my unofficial packages officially available in Debian, another Debian developer has a package depending on qmail in the NEW queue. In my opinion, ftpmasters should reject packages on grounds of Debian policy or (maybe) the Debian body. If they wish a permanent rejection of qmail and related packages, they should try to find that consensus within Debian, and, if successful, add that decision to http://www.debian.org/devel/wnpp/unable-to-package Can you advise me on how to get out of that dilemma? Thanks, Gerrit. See http://bugs.debian.org/457318 http://smarden.org/pape/Debian/sid.html#nonprogress http://ftp-master.debian.org/new.html http://thread.gmane.org/gmane.linux.debian.devel.wnpp/69292/ for all the details. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: qmail and related packages in NEW
On Mon, Dec 01, 2008 at 03:33:43PM +0100, Florian Weimer wrote: > * Joerg Jaspert: > > First - the packaging is nowhere near the standard Debian aspires to in the > > archive: > > > > Qmail is an MTA and as such should follow Debian Policy (for example Section > > 11.6). It's therefore not a very good start that an MTA package needs > > additional packages (qmail-run) installed to perform the minimal tasks > > required of mail-transport-agent, and yet another package (fastforward) to > > support /etc/aliases. > > Yuck. I wasn't aware of that. So the security discussion was kind of > a red herring, after all. Hi, how exactly is that a policy violation? Please see the answer to that paragraph in my reply (including full quote) to the rejection mail http://lists.debian.org/debian-wnpp/2008/09/msg00055.html On Mon, Sep 01, 2008 at 10:36:07PM +, Gerrit Pape wrote: > Hmm, the MTA package actually is qmail-run, as can be read from the > README.Debian's in the qmail-run and qmail packages. And qmail-run > needs the qmail package, which provides the qmail programs and queue > structure, as well as the fastforward package, which provides support > for the /etc/aliases database. I can't see anything wrong with this, to > the contrary, the modularity of the packages provides more flexibility, > e.g.: > > o users can install the qmail package without the qmail-run package to >configure qmail as MTA manually, next to another MTA package already >installed on the system > o users can install the qmail package without the qmail-run package if >they wish to use some programs from the qmail package, e.g. >qmail-popup and qmail-pop3d, and wish to have a different default >MTA installed, such as postfix > o users can disable the /etc/aliases support, and switch to a different >alias handling if they like; the package providing the /etc/aliases >database support can then be removed from the system I still think this is a good thing, providing valuable flexibility to the users. What problem do you see? Is it that the packages are modularised, and not a single monolithic qmail package? Is it the name?, should the 'qmail-run' MTA package named 'qmail', and the current 'qmail' package 'qmail-core' or so? BTW, I maintain several packages in the Debian archive already that do just the same, a package containing the programs, and a separate package that provides the service. So I can happily run bincimap next to dovecot, and twoftpd next to some other ftp server, on the same machine. Users repeatedly request such thing, e.g. http://lists.debian.org/debian-devel/2005/08/msg01308.html I know about that opinion http://lists.debian.org/debian-devel/2005/08/msg01329.html but actually nothing came up within three years http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=500176 Regards, Gerrit. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: qmail and related packages in NEW
On Fri, Nov 28, 2008 at 08:51:01PM +0100, Neil Williams wrote: > On Fri, 28 Nov 2008 18:12:42 + > Gerrit Pape <[EMAIL PROTECTED]> wrote: > > Lacking any response, I can only guess what the reason for the delay > > is. > > IMHO, the response has been given and your replies have not provided > sufficient grounds to change the response. Personally, I think that is > entirely fair. > > > >From my point of view this reason is questionable, and I stated so > > >in my > > response to the reject mail. Receiving no response within eight weeks > > tells me that discussing doesn't work. > > Discussions only work when new information is available. Rehashing the > same points in the hope that repetition wins the day is just boring. Hi, surely new information was made available, see my reply to the rejection mail http://lists.debian.org/debian-wnpp/2008/09/msg00055.html Additionally to addressing technical issues, I took the advise from ftpmasters and reconsidered re-uploading the packages. After two months, and receiving several mails from users asking about the progress of the inclusion into Debian main after qmail was placed into the public domain, I re-read some public mails like http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=457318#35 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=457318#50 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=457318#111 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=457318#121 http://lists.debian.org/debian-wnpp/2008/03/msg00149.html http://lists.debian.org/debian-publicity/2008/07/msg3.html This made me think there're people interested in having the packages included, so here we are. > > On Mon, Sep 01, 2008 at 10:36:07PM +, Gerrit Pape wrote: > > > On Sun, Jul 06, 2008 at 02:19:30PM +, Joerg Jaspert wrote: > > > > Aside from these technical - and possibly fixable - problems, we > > > > (as in the ftpteam) have discussed the issue, and we are all of > > > > the opinion that qmail should die, and not receive support from > > > > Debian. As such we *STRONGLY* ask you to reconsider uploading > > > > those packages. > > > > > > > > Qmail is dead upstream and requires a whole set of patches to even > > > > begin to work in the manner expected of a modern MTA. Given > > > > this, the fact that this means there is also no upstream security > > > > support, and the fact that Debian already contains at least three > > > > reasonable MTAs, we see no need to add qmail to the archive. So - > > > > please reconsider if it really helps Debian to have those > > > > packages. Also feel free to start a public discussion on > > > > debian-devel@lists.debian.org about the issue, including any > > > > relevant information from this email, in order to gather opinions > > > > from other project members. > > To me, that sounds like a perfectly reasonable and calm response to > your original question. > > Packages that are dead upstream are always going to be a headache for > the security team and the release team. Bit rot is a constant source of > new bugs as all the packages around the dead one(s) continue to be > developed and improved. > > > > We all know, I guess, that there's lots of different opinions on the > > > quality and usability of qmail. There're people thinking like you, > > > and other people, including me, that have a different opinion. I > > > respect your opinion, please respect ours too. You're free to not > > > install/use the packages. I've been contacted by several people > > > since I announced my intention to package qmail, speaking in favor > > > of the inclusion into Debian. > There are always different opinions. What matters is whether there is > any new information to bring to the discussion. >From my experience, starting a discussion about what the ftpmasters wrote above leads to nowhere, so I refrained from doing so and talked about opinions. To me it's clear that upstream isn't dead, I see signs of him doing development on dnscurve for example. Also qmail has security support, not only that, it has a security guarantee. And it doesn't need a whole set of patches, I know that, I use my packages since years. Finally, the source package is netqmail, which is created by a team of valuable qmail contributors, maintained and supported by them. This information is included in debian/copyright and the README file. Regards, Gerrit. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#457318: qmail and related packages in NEW
On Tue, Dec 02, 2008 at 11:29:13AM +0100, Bjørn Mork wrote: > Gerrit Pape <[EMAIL PROTECTED]> writes: > > Hi, I'm quite surprised how the inclusion of qmail and related packages > > into sid is handled, or rather not handled, by the ftpmasters. > > I downloaded the netqmail source from http://dbn.smarden.org/sid/ and > looked briefly at it, to see if most of the well-known (some of the for > 10+ years!) bugs have been fixed. Unfortunately, it doesn't seem so. > The Debian packaging included surprisingly few patches, and the fixes > I tested still applies to the Debian package. e.g: > > [EMAIL PROTECTED]:/usr/local/mydebs/tmp/netqmail-1.06$ patch -p0 --dry-run < > ../patch-qmail-1.03-rfc2821.diff > patching file qmail-remote.c > [EMAIL PROTECTED]:/usr/local/mydebs/tmp/netqmail-1.06$ patch -p0 --dry-run < > ../patch-qmail-1.03-rfc1652.diff > patching file ./qmail-smtpd.c > Hunk #1 succeeded at 229 with fuzz 1. > To avoid having packages starting their Debian life with a long list of > serious and grave bugs, may I suggest that you take a look at > http://www.dt.e-technik.uni-dortmund.de/~ma/qmail-bugs.html [1] > and either include the patches or use the suggested workarounds? Sure, the two patches you mention might be considered for Debian. However, I wonder how two issues can be called a 'long list', and how these can be judged as severity grave or serious. Right now, upstream doesn't completely agree with Andree's list of bugs. Do you know how many people add accept_8bitmime to the default exim configuration, and for what reason? Do you know why any highest priority MX with the closest distance to the mail store should issue temporary errors on incoming connections permanently, and whether this is okay with the standards? I've yet to be pointed to a grave or serious bug in the packages pending in NEW, otherwise I see no reason why they shouldn't be processed and pass NEW. I completely agree with this well written post http://lists.debian.org/debian-devel/2008/12/msg00207.html Regards, Gerrit. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#457318: qmail and related packages in NEW
Hi, On Thu, Dec 04, 2008 at 11:05:31AM +0100, Florian Weimer wrote: > Out of curiosity, does netqmail fix at least the delayed bounce > problem? no, or maybe: not yet; they gave notice of including that, but nothing happened yet http://marc.info/?l=qmail&m=120275739720434&w=2 On Thu, Dec 04, 2008 at 11:44:41AM +0200, Kalle Kivimaa wrote: > Gerrit Pape <[EMAIL PROTECTED]> writes: > > I've yet to be pointed to a grave or serious bug in the packages pending > > in NEW, otherwise I see no reason why they shouldn't be processed and > > pass NEW. I completely agree with this well written post > > Does the package in NEW fix the well known backscatter spam issue? I > tried searching for the fix in the package but unfortunately failed. Not the default install. The package includes a patch though, and builds and provides additional smtpd and qmtpd replacements that reject unknown addresses in the SMTP connection, they're trivial to enable. I personally use mailfront instead of qmail-smtpd. mailfront, already available in Debian/main, has this functionality and can also act perfectly as a replacement. > If it doesn't, then IMO, at this day and age, a MTA sending > backscatter spam doesn't belong to Debian. I understand that opinion, and almost share it, after all I've configured my servers that way too. I'd prefer to have that changed upstream in netqmail, but am not strictly opposed to making that change for Debian explicitly. Why 'almost share it'? Rejecting in the SMTP connection also plays into the hands of spammers. They have some resources available to blast out data of unsolicited mails. Once an SMTP server rejects a recipient before DATA, the SMTP client doesn't need to transmit the data, and can immediately switch to another recipient, using the resources more efficiently. The more SMTP servers reject on RCPT, the more moves the load to other SMTP servers. So it might well be that those SMTP servers, that accept mail regardless of the existence of the recipient mailbox, take load off your server's spam processing, because they eat spammer's resources. Concerning the delayed delivery notifications, there's an efficient way to immediately reject those in the SMTP connection, see http://lists.debian.org/debian-isp/2004/09/msg00080.html Finally, just as not supporting VRFY, not rejecting in the SMTP conversation makes it harder for the spammers to sort out bad recipient addresses, and so to use their resources even more efficiently. That not necessarily needs to be true; it's theory, but in my opinion it's worth thinking about. Regards, Gerrit. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: non-root syslogd?
On Mon, Jul 07, 2003 at 02:59:35PM -0700, Mark Ferlatte wrote: > Has anyone investigated what would be necessary to get a non-root > syslogd working under Debian? It seems like this would be a good > thing, but obviously there have to be some tricky bits, else it would > have happened already. :) > Is this worth working on? Has anybody already done this? If you are interested, take a look at the socklog package, a replacement for sysklogd that already does this. It even uses separate uids for the listener process and the process writing logs to disk. Regards, Gerrit. -- Open projects at http://smarden.org/pape/.
Bug#215353: ITP: bincimap-run -- IMAP server for Maildir depositories
As an alternative to existing similar IMAP servers, Binc IMAP strives to be very easy to use, but robust, stable and secure. It aims at being absolutely compliant with the IMAP4rev1 protocol, and simple and modular in design, making it very easy for third parties to utilize the source code and enhance the product. . This package sets up the bincimaps service to listen on 0.0.0.0:993 using the ipsvd and runit package, and additionally provides a service directory to easily enable a bincimap service without SSL support. A bincimap package already is in the Debian archive, and currently enables an imaps service through inetd automatically. The package provides the virtual package 'imap-server', and conflicts with other packages providing 'imap-server'. This makes it rather difficult to have multiple imap servers installed on a system simultaneously, even though there are actually no namespace conflicts. The only conflict generally is that packages providing 'imap-server' listen on the same local socket. I intend to package bincimap-run to enable users to have the bincimap programs installed next to other imap servers on their systems, and so to run different imap servers on different local addresses if desired, without forcing the package management system. If not desired, the user can install the bincimap-run package that automatically sets up the imaps service. So when introducing the bincimap-run package, the bincimap package will change to not enable any service automatically, and will no longer provide/conflict with 'imap-server', but the new package will. I've already done this with the socklog and twoftpd packages, see these package sources for details if you're interested. Regards, Gerrit. signature.asc Description: Digital signature
Re: faster boot
On Mon, Oct 13, 2003 at 12:05:24PM +0200, Andrea Mennucc wrote: > there has been a lot of interest lately on tecniques to obtain a faster > boot; for example [...] > http://www.fefe.de/minit/ [...] > is anyone trying to implement the above in Debian? I've implemented the runit package, somewhat similar to minit, modeled on the daemontools' service management concept, and available in Debian sarge and sid: http://packages.debian.org/runit http://packages.debian.org/runit-run But it's not a drop-in replacement for sysvinit as it's not compatible with normal init scripts. You may be interested though. Regards, Gerrit. -- Open projects at http://smarden.org/pape/.
Re: faster boot
On Wed, Oct 15, 2003 at 11:12:26AM +0200, Erich Schubert wrote: > runit is okay, and it has debian packages already. What i didn't like > about runit is the "forest" of processes it creates. The output of > pstree is really fancy. ;-) Minit seems to be able to do most of this > without using that many processes. What's wrong with some more processes other than that you don't like it? The advantage of having separate tools for separate tasks is modularity: Most of the runit program also are useful for users, e.g. to reliably control long running processes and log the output, or to provide them their own personal service management. The modularity also enables you to replace single tools with alternative implementations, or complete different programs. Furthermore it keeps the process actually running as process number 1 as small as possible, and allows you to upgrade the other tools easily without rebooting, or re-execing the init process. Regards, Gerrit. -- Open projects at http://smarden.org/pape/.
Re: Re: faster boot
On Fri, Oct 17, 2003 at 11:53:18AM +0200, Erich Schubert wrote: > minit is already really small. All it does is running processes and > restarting them when they die. There seems to be little difference > between what i can do with minit and with multiple runsv. > And yes, i do know about shared memory. > I admit that runsvdir has some nice features - like something similar to > runlevels, but way easier to understand. > Just change the symlink to the new runlevel and it will terminate > services not in the new runlevel, while starting new services. Nice! > > But i don't see why i need that many processes: [...] As I already said in my last mail: modularity. Consider a multi-user server system, and you want to provide one or more users with their own personal service management. You can run additional instances of the runsvdir program under the uid and gid of the user as a service, so he can manage his own daemon processes with a guaranteed process state, logging, and supervision. Or use the runsv program to provide him with just a single service facility. On the other hand consider an embedded device, e.g. a kiosk system. You possibly don't want to use runsvdir and runsv at all, but run an X-server as the only service daemon on the system, running a gui application. If X exits the system shuts down. I could think of more scenarios. Each of the separated programs perform certain tasks: runit: clean process state, process 1 duties; runsvdir: privilege separation, service management, last-resort-log; runsv: user interface, supervision, logging. Running them in a process hierarchy makes it possible to recombine these features differently. I cannot see what's wrong with having some more processes running, very small ones which sleep most of the time. They don't hurt the system. Regards, Gerrit. -- Open projects at http://smarden.org/pape/.
Bug#457318: ITP: qmail -- a secure, reliable, efficient, simple message transfer agent
qmail is meant as a replacement for the entire sendmail-binmail system on typical Internet-connected UNIX hosts. See BLURB, BLURB2, BLURB3, and BLURB4 in /usr/share/doc/qmail/ for more detailed advertisements. See /usr/share/doc/qmail/PIC.* for some ``end-to-end'' pictures of mail flowing through the qmail system. See http://pobox.com/~djb/qmail.html for other qmail-related software and a pointer to the qmail mailing list. Other documentation: http://pobox.com/~djb/proto.html shows solutions to several Internet mail problems; many of these solutions are implemented in qmail. CHANGES and THANKS show how qmail has changed since it was first released; SECURITY, INTERNALS, THOUGHTS, and TODO record many of the qmail design decisions (found in /usr/share/doc/qmail/). License qmail is in the public domain There'll be the following binary packages: qmail, qmail-uid-gids, fastforward, dot-forward, qmail-run. The packages are derived from the unofficial ones available through http://smarden.org/pape/Debian/qmail.html Regards, Gerrit. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#458061: RFH: cfs -- Cryptographic Filesystem
Hi, I'm seeking help with the cfs Debian package, if you're interested, please see http://bugs.debian.org/src:cfs cfs is a nice package, written in 1992, updated 1997, and since without upstream. Chris Leishman maintained the package until I took it over in 2002, it's worth reading through the source in any case. I'm willing to share maintainership, and possibly hand over the package to another DD/DM after some time. Thanks, Gerrit. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#459778: ITP: tinydyndns -- pop-before-dyndns service using djbdns
tinydyndns is a simple but powerful dynamic DNS solution that uses djbdns. It cooperates with the djbdns package to publish dynamic IP addresses authenticated through POP connections. On successfully authenticated POP connections, the tinydyndns-update program manipulates tinydns' constant database "data.cdb" directly without rebuilding it; this makes the dynamic DNS solution use very few system resources. Using a POP service for authentication saves the work for installing special client software, since POP clients are available for every common network-aware operating system. To provide the DNS and POP service, tinydyndns cooperates with djbdns, qmail, and cvm. The package is available through http://smarden.org/tinydyndns/ I'm the upstream author, copyright is the 3-clause BSD license. Regards, Gerrit. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Standardisation of the name of the patching targets included in debian/rules.
On Sun, Feb 03, 2008 at 08:14:35PM +0100, Stefano Zacchiroli wrote: > On Sun, Feb 03, 2008 at 11:10:41AM +0100, Martin Quinson wrote: > > I find personnaly patch/unpatch more easy to understand, but YMMV... > > I think (hope) that no one will be able to find a reason why the two > target should *not* be called "patch" / "unpatch". They are IMO the only > 2 that people will be able to guess out of the blue. > > So please go for patch/unpatch. An unpatch target might be problematic. There're packages with patches that touch the upstream Makefile, and calling 'make unpatch' before 'make clean' can break things; of course the clean target can depend on patch, but this seems to complicate things. Why not simply do the unpatch in the clean target? This is what I use in packages I maintain: patch: deb-checkdir patch-stamp patch-stamp: for i in `ls -1 debian/diff/*.diff || :`; do \ patch -p1 <$$i || exit 1; \ done touch patch-stamp clean: deb-checkdir deb-checkuid $(MAKE) clean $(OPTS) test ! -e patch-stamp || \ for i in `ls -1r debian/diff/*.diff || :`; do patch -p1 -R <$$i; done rm -f patch-stamp [...] Regards, Gerrit. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#171253: ITP: libdjbdns -- DNS client library designed to replace the BIND res_*/dn_* library
Package: wnpp Severity: wishlist DNS client library designed to replace the old BIND res_*/dn_* library[0] High-level lookups: The dns library provides several easy-to-use DNS lookup routines: dns_ip4, dns_ip4_qualify, dns_name4, dns_mx, and dns_txt. dns_ip4_qualify supports the traditional configuration mechanisms for hostname rewriting: $LOCALDOMAIN, /etc/resolv.conf, and gethostname. It also supports a powerful new user-controlled rewriting mechanism. The functions that read /etc/resolv.conf automatically reread it every ten minutes, so system administrators don't have to kill long-running programs. Low-level lookups: The dns_domain_* and dns_packet_* functions make it easy to safely parse DNS packets. The dns_transmit_* functions send DNS queries of arbitrary types to arbitrary servers. These are the functions used in the dnscache program. License: Bernstein has put the .[ch] files (dns.h, dns_dfd.c, dns_domain.c, dns_dtda.c, dns_ip.c, dns_ipq.c, dns_mx.c, dns_name.c, dns_nd.c, dns_packet.c, dns_random.c, dns_rcip.c, dns_rcrw.c, dns_resolve.c, dns_sortip.c, dns_transmit.c, dns_txt.c) and all necessary lower-level .[ch] files into the public domain[1]. I do not plan to make any changes to those files, so Bernstein's djbdns security guarantee[2] applies. My additions to the package will be licensed under a BSD compatible license. Regards, Gerrit. [0] http://cr.yp.to/djbdns/blurb/library.html [1] http://cr.yp.to/djbdns/res-disaster.html [2] http://cr.yp.to/djbdns/guarantee.html pgpq6I8WAk5XI.pgp Description: PGP signature
Re: Fwd: Please confirm your message
On Sun, Dec 01, 2002 at 02:35:28PM +0100, Russell Coker wrote: > The people who run such stupid filters misunderstand the way the > Internet works. Maybe you should do a short research on the user of this mail handling program before saying such. > If you have to send an extra confirmation message every time you send > an email to someone you haven't communicated with before then it will > increase the number of messages required by at least 50%. That is an > unreasonable burden to place on other people. I wrote the software primarily for ezmlm mailing lists, please rethink your statement with this precondition. On Sun, Dec 01, 2002 at 08:47:04AM -0500, Michael Stone wrote: > Still too much. If someone initiates a communication, they should make > sure they can get the reply. Yes that's true. I usually do this. I'm not responsible for the Reply-To header in my message, the BTS mangled the headers and resent the message; and it still appears to be from me. I've set Mail-Followup-To correctly. I'm not interested in receiving private copies of mail in public discussions; I know where I post, and keep up with, in this case, the bug's history, and read debian-devel. I've noted that you two don't want to communicate with me, be it. On Sun, Dec 01, 2002 at 02:35:28PM +0100, Russell Coker wrote: > PS If a spam filter blocks a message about an NMU then don't complain > about not being warned... No. You receive a delivery notification, and you receive a bounce if the delivery fails. You know that your message didn't reach the recipient. On Sat, Nov 30, 2002 at 04:48:50PM +0100, Russell Coker wrote: > For reference, I will not reply to such a message, but I will consider > putting the entire domain in my spam filter if such messages continue. This is what could cause it. 'Stupid' content based spam filters delivering false positives to /dev/null. Neither the sender nor the recipient know about the delivery failure. Gerrit.
Re: Fwd: Please confirm your message
On Mon, Dec 02, 2002 at 04:58:48PM +0100, Russell Coker wrote: > Also there's the issue of two people having such filters trying to > communicate with each other. This, of course, is taken care of, see the documentation if you are interested. > NB You can't just white-list an address when you send mail to it as > often people don't use the same From: address to reply as they > advertise when soliciting email (think about [EMAIL PROTECTED] addresses > and vanity domains). Yes. But one can add a Reply-To header with a private mail address that doesn't require confirmation. On public discussions, one can add a Mail-Followup-To header to keep answers in the public where they belong imho. If there is open source, there should be open development, no need keep such things private. There are public discussion resources available for all of my open software. Gerrit.
Re: Fwd: Please confirm your message
On Mon, Dec 02, 2002 at 05:31:11PM +0100, Russell Coker wrote: > On Mon, 2 Dec 2002 17:18, Stephen Zander wrote: > > The above is based on the false premise that those who send spam are > > incapable of sending it with (forged) real email addresses. They > > already have lots of them to choose from. This is an existing and well known problem of the current internet mail infrastructure. Yes, envelope senders and headers can be forged. > Of course such a spam filter will stop such spam at the cost of doubly > spamming innocent people who have their addresses forged. Doubly? I cannot follow. > It's very anti-social, zero sum game stuff. Come on, no need to especially blame my mail handling program. In another mail you wrote, you don't deliver spam to /dev/null but bounce it. Where do you think the bounce will end up? Nothing else is doing my software, sending a bounce to the envelope sender; there is no difference. Gerrit.
Re: Fwd: Please confirm your message
On Mon, Dec 02, 2002 at 06:50:14PM +, Matthew Garrett wrote: > In order to avoid this, spammers merely have to use a forged from > address that will generate an automatic response. There's no shortage of > those. [EMAIL PROTECTED] springs to mind, and I have no doubt that > there are many others. The spammers can therefore trivially circumvent Autoresponders, bouncers, and other mail handling programs use the envelope sender address, not an address found in any header of the mail. I doubt that any abuse@ address replies to a bounce message. This is no problem. Gerrit.
Re: Fwd: Please confirm your message
On Mon, Dec 02, 2002 at 11:01:15AM -0500, H. S. Teoh wrote: > On Mon, Dec 02, 2002 at 04:39:30PM +0100, Jan Niehusmann wrote: > > Time will tell. I fear that some day, the only way to use email > > productively is to block all email with invalid sender adresses. And > > I don't know a way do valdiate a (not yet known) address but to try > > it and send a reply. If you combine that with some autoresponders > > on both ends, no human interaction would be needed, so annoyance > > should go down. > > But what if spammers set up autoresponders as well? Just a thought. They don't. Spammers don't have (or want to provide) the resources for mass bounce handling on there mass mailing. Also, they are not anonymous anymore when doing this, you then know who is responsible for the spam or who does provide the resources for spamming. It is _very_ unlikely that such will happen. Gerrit.
Re: Time to package simpleinit?
On Mon, Apr 28, 2003 at 03:43:25PM +0200, Joachim Breitner wrote: > I am really not trying to replace the sysvinit scheme as a default one, > and I don't think anybody else is. But having the option to use a > different one is a goal worth going for. You might be interested in the runit and runit-run packages. It's a different init system already available in Debian (sid/sarge), although it doesn't integrate well with the init script system, simply because it doesn't use init scripts. The split of the sysvinit package seems to make better integration more easy, also the update-rc.d, invoke-rc.d, and policy-rc.d interfaces, I appreciate this. I'm still developing the packages as time permits. Regards, Gerrit. -- Open projects at http://smarden.org/pape/.
Re: Bug#312660: ITP: shish -- the diet shell
On Thu, Jun 09, 2005 at 02:38:06PM +0200, Michael Prokop wrote: > * Package name: shish > Version : 0.7-pre3 > Upstream Author : Roman Senn <[EMAIL PROTECTED]> > * URL : http://www.blah.ch/shish/ > * License : GPL > Description : the diet shell > > shish is a shell language interpreter and an interactive command > line interpreter. > > This shell aims at being very small and doing its tasks in > efficient ways (and not through 100 abstraction layers), which > is mainly done by using the dietlibc and libowfat libraries. > > shish will be a POSIX compatible shell language interpreter > according to the IEEE P1003.2 Draft 11.2 by its 1.0 release. He, here's a challenge.. $ DEB_BUILD_OPTIONS=diet fakeroot apt-get source -b dash >/dev/null 2>&1 && ls -l dash-0.5.2/debian/dash/bin/dash && ldd $_ -rwxr-xr-x 1 pape pape 75080 Jun 10 07:59 dash-0.5.2/debian/dash/bin/dash not a dynamic executable Regards, Gerrit. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
diverting conffiles
On Tue, May 31, 2005 at 11:08:27PM +0200, Tollef Fog Heen wrote: > Be aware of the fact that diverting conffiles doesn't work. Hi, what exactly is the problem with diverting conffiles? Thanks, Gerrit. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Unnecessary "Conflicts" with imap-server packages
On Tue, Aug 23, 2005 at 12:32:15PM +0100, Edward wrote: > Is it necessary for the following packages to "Conflict" with the > virtual package "imap-server": > > bincimap-run > courier-imap > cyrus-imapd(*) > cyrus21-imapd (*) > dovecot-imapd > mailutils-imap4d (*) > uw-imapd (*) > > For example, I recently moved from "uw-imapd" to "dovecot-imapd", but > found it difficult to setup a testing environment where both IMAP > daemons were installed, as uw-imapd conflicted with imap-server, which > was provided by dovecot-imapd. > > Such testing is obviously necessary and it would be good if there was a > way in which it could be more easily supported! $ sed -ne '19,$p' , Fri, 17 Oct 2003 07:45:52 + $ Regards, Gerrit. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Unnecessary "Conflicts" with imap-server packages
On Thu, Aug 25, 2005 at 01:04:28PM +1000, Brian May wrote: > >>>>> "Gerrit" == Gerrit Pape <[EMAIL PROTECTED]> writes: > Gerrit> Gerrit> bincimap-run package provides the virtual package > Gerrit> ``imap-server'' and conflicts with other packages > Gerrit> providing ``imap-server''. This ensures that bincimap is > Gerrit> the only service that listens on the address 0.0.0.0:993 > Gerrit> on a system, and also satisfies packages that depend on a > Gerrit> running imap service. The bincimap package without the > Gerrit> bincimap-run package can be installed alongside other > Gerrit> imap-server packages on a system, e.g. to provide > Gerrit> different imap or imaps services on different addresses > Gerrit> simultaneously. > > So are you suggesting that every imap-server (for example) should be > split into two packages? > > Taken a step further this would include every server where multiple > implementations exist. I suggest to split all packages providing service(s) into one package containing the programs, documentation, examples, and one package setting up the default service(s) to be run automatically. See these threads http://lists.debian.org/debian-devel/2004/04/msg00080.html http://lists.debian.org/debian-devel/2004/02/msg01390.html I'm doing this for nearly all of the packages I maintain since years, works just fine. > Is this really a good idea? Yes, why not? It solves the OP's problem; it lets you install packages that provide a service without enabling the service automatically; it uses the dpkg dependency facility to show or solve conflicts; it adds flexibility, and avoids unnecessary conflicts. You might say it blows up the Packages file. Well, yes, but I don't think the scalability problem with the number of packages included in Debian should stop us developing good design choices, or adding new good quality packages to Debian. I'm confident the problem will be solved technically some day. Regards, Gerrit. -- Open projects at http://smarden.org/pape/. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Unnecessary "Conflicts" with imap-server packages
On Mon, Aug 29, 2005 at 07:06:34PM +1000, Hamish Moffatt wrote: > On Mon, Aug 29, 2005 at 07:55:31AM +0000, Gerrit Pape wrote: > > > Is this really a good idea? > > > > Yes, why not? It solves the OP's problem; it lets you install packages > > that provide a service without enabling the service automatically; it > > uses the dpkg dependency facility to show or solve conflicts; it adds > > flexibility, and avoids unnecessary conflicts. > > > > You might say it blows up the Packages file. Well, yes, but I don't > > think the scalability problem with the number of packages included in > > Debian should stop us developing good design choices, or adding new good > > quality packages to Debian. I'm confident the problem will be solved > > technically some day. > > It's solved now - edit configuration files! It's not essential that > everything can be configured by adding/removing packages. It's not essential to have everything configured through configuration files. I haven't heard any reason yet why splitting the packages would be a bad thing. And there's more advantages: it eases usage of different service managers than sysvinit and init scripts, support of a different init scheme can be done through an alternative package which 'provides' the default *-run package; same for services running under a superserver, and corresponding alternatives; it plays well with fully automated installs; it separates services from programs. Regards, Gerrit. -- Open projects at http://smarden.org/pape/. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Re: better init.d/* : who carres ?
On Wed, Sep 21, 2005 at 05:07:31AM -0400, Alfie Costa wrote:
> Russ Allbery <[EMAIL PROTECTED]> wrote:
> > I find constructs like ${string#*=} particularly difficult to read,
> > since they require that I remember what all the different punctuation
> > characters inside this sort of parameter expansion do. According to
> > the bash manual, there are sixteen of them, and I had to read the
> > description of ${parameter#word} three times before I completely
> > understood what it said.
> 1) The man page descriptions of these functions could probably be
> improved.
There shouldn't be any problems with
$ man dash
/%word
Regards, Gerrit.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#330029: ITP: runit-services -- a UNIX init scheme with service supervision (services)
runit is a replacement for SysV-init and other init schemes. It runs on Debian GNU/Linux, *BSD, MacOSX, and Solaris, and may be easily adapted to other Unix operating systems. runit implements a simple three-stage concept. Stage 1 performs the system's one-time initialization tasks. Stage 2 starts the system's uptime services (via the runsvdir program). Stage 3 handles the tasks necessary to shutdown and halt or reboot. . See http://smarden.org/runit/ for more information. . This package contains services directories for a collection of services available in Debian, to have them run under runit service supervision instead of sysvinit or through init.d scripts. Amongst other services, it includes service directories for apache, cron, dhclient, exim, gdm, postfix, squid, ssh. License is a 3-clause BSD. Regards, Gerrit. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: 2 ftpds packages conflicts
On Mon, Nov 06, 2006 at 11:34:14PM +0100, Sz?kelyi Szabolcs wrote: > can anyone tell why ftpds do conflict with each other and why httpds do > not? Actually the httpds should conflict too as they install listeners on 0.0.0.0:80. E.g.: With no httpd installed, install the apache package, apache will listen on 0.0.0.0:80; now install the thttpd package, it'll work fine, but no thttpd daemon will run afterwards, because it fails to bind to 0.0.0.0:80, see syslog; reboot the machine, and you'll be surprised to see the thttpd daemon run, and not apache, because thttpd gets started first. I still think this will fix such problems just fine: > >> http://lists.debian.org/debian-devel/2005/08/msg01314.html Regards, Gerrit. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: why dig ? I wanna use nslookup !
On Wed, May 02, 2001 at 01:27:56PM +0200, Paul Slootman wrote: > On Tue 01 May 2001, Marco d'Itri wrote: > > > nslookup is broken, please let it die its long-deserved death. > > What's broken about it, apart from the brokenness that's in the current > version about the verbose warnings and missing features (eg. ls) ? > AFAIK it does exactly what it was designed to do. This is like saying > "ed is broken, use emacs", while ed performs its task perfectly. > See http://cr.yp.to/djbdns/faq/tinydns.html#nslookup f.e. Gerrit. -- [EMAIL PROTECTED] innominate AG the linux architects tel: +49.30.308806-0 fax: -77 http://www.innominate.com
Re: why dig ? I wanna use nslookup !
On Wed, May 02, 2001 at 02:30:21PM +, Alexander Koch wrote: > On Wed, 2 May 2001 13:39:17 +0200, Gerrit Pape wrote: > > See http://cr.yp.to/djbdns/faq/tinydns.html#nslookup f.e. > > djbdns? you really mean it? yes. > *brrzzzap* > [2] Mutt has scoring abilities, right? djb sux, so... thanks > for the idea > What makes you reacting so blind and childish? This is not the topic of this thread, just notice that there are debian people running djbdns - relaxed, bind-free. Not having real djbdns (+co) packages in debian is a pity. Gerrit. -- [EMAIL PROTECTED] innominate AG the linux architects tel: +49.30.308806-0 fax: -77 http://www.innominate.com
Re: why dig ? I wanna use nslookup !
On Wed, May 02, 2001 at 04:02:33PM -0400, Jacob Kuntz wrote: > from the secret journal of Gerrit Pape ([EMAIL PROTECTED]): > > What makes you reacting so blind and childish? This is not the topic of this > > thread, just notice that there are debian people running djbdns - relaxed, > > bind-free. Not having real djbdns (+co) packages in debian is a pity. > > > > Closed-source software is even more of a pity. DJB's license (or lack there Uf, read the source, technical and library documentation at http://cr.yp.to/djbdns.html > of) makes it impossible to distribute binaries that aren't compiled by DJB Huh? http://cr.yp.to/distributors.html http://www.djbdns.org/ http://innominate.org/~pape/Debian/djbdns.html > I haven't been following this thread, but shouldn't it have ended or moved > to another list as soon as someone said "upstream?" > I am willing to stop or move this thread if wrong facts are clarified. Gerrit. -- [EMAIL PROTECTED] innominate AG the linux architects tel: +49.30.308806-0 fax: -77 http://www.innominate.com
Bug#514323: RFA: ezmlm-browse -- Web browser for ezmlm-idx archives
Hi, I'm looking for a new maintainer for the ezmlm-browse package. There's a new upstream version available. Description: Web browser for ezmlm-idx archives This is ezmlm-browse, a web interface for browsing ezmlm-idx (version 0.40 or later) archives. The default presentation is similar to that of the ezmlm-cgi archive browser that is part of ezmlm-idx, but with the addition of threaded subjects and online posting / replying. However, the output is completely template drive, so you can make it fit into your current web scheme. Tag: implemented-in::python, interface::web, network::client, protocol::http, role::program, web::browser, works-with::text, works-with-format::html Regards, Gerrit. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: not starting packages at boot
On Fri, Jan 21, 2005 at 12:09:42PM +0800, Dan Jacobson wrote: > Now that maintainers realized that one might like a package installed, > but perhaps only plans to use it unoften, it only makes sense for not > starting at boot to be offered as a friendly configuration option, > instead of needing some devious guerilla techniques to thwart the > packages starting. For packages I maintain that provide system services, I use another solution than making it a configuration option. The packages are split into a package providing the programs, and a -run package providing the service. Users that don't want the service to be enabled by default simply don't install the -run package. This additionally has an advantage concerning virtual packages representing a system service, such as ftp-server, mail-transport-agent, system-log-daemon, or imap-server. Here's the rationale from the bincimap-run package: $ sed -ne '18~1p' , Fri, 17 Oct 2003 07:45:52 + $ Regards, Gerrit. -- Open projects at http://smarden.org/pape/. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#302309: ITP: bcron -- Bruce's cron system
This is bcron, a new cron system designed with secure operations in mind. To do this, the system is divided into several separate programs, each responsible for a separate task, with strictly controlled communications between them. The user interface is a drop-in replacement for similar systems (such as vixie-cron), but the internals differ greatly. http://untroubled.org/bcron/ License is GPL2. There'll be two binary packages: bcron, containing the bcron programs and documentation, and bcron-run, setting up the bcron services, and providing, replacing, and conflicting with the default cron package. Regards, Gerrit. -- Open projects at http://smarden.org/pape/. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#302309: ITP: bcron -- Bruce's cron system
On Wed, Apr 06, 2005 at 05:47:44PM -0500, Steve Greenland wrote: > On 06-Apr-05, 14:45 (CDT), Gerrit Pape <[EMAIL PROTECTED]> wrote: > > There'll be two binary packages: bcron, containing the bcron programs > > and documentation, and bcron-run, setting up the bcron services, and > > providing, replacing, and conflicting with the default cron package. > > It looks like bcron messes with the permissions and structures of > /var/spool/cron/crontabs. Are you going to handling conversion between Yes, with bcron this directory and the files in it are all owned by a system user 'cron' and have restricted permissions. The bcron-run.postinst will take care of this when switching from cron to bcron. > the two (cron and bcron)? In particular, are you going to convert > *back* on removal of bcron-run? Or do you expect cron to clean it up on > re-install? (I can handle that, but I'd like to know the plan.) My plan was to file a wishlist bug against your cron package after preparing and testing a patch against its postinst. It would be nice if the cron package can handle the conversion back, I think; similar to how it adjusts permissions of /var/spool/cron/crontab/* on upgrade from << 3.0pl1-81. Thanks, Gerrit. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#302309: ITP: bcron -- Bruce's cron system
On Thu, Apr 07, 2005 at 07:35:25AM -0500, Steve Greenland wrote: > On 07-Apr-05, 06:40 (CDT), Marc Haber <[EMAIL PROTECTED]> wrote: > > On Wed, 6 Apr 2005 19:45:15 +0000, Gerrit Pape <[EMAIL PROTECTED]> > > wrote: > > >This is bcron, a new cron system designed with secure operations in mind. > > >To do this, the system is divided into several separate programs, each > > >responsible for a separate task, with strictly controlled communications > > >between them. The user interface is a drop-in replacement for similar > > >systems (such as vixie-cron), but the internals differ greatly. > > > > Is it a drop-in replacement for Debian's cron as well, which is quite > > a bit patched compared to plain vixie cron? > > Looking at the site, it appears to have the required functionality > (/etc/cron.d, etc.). One line item that is not yet supported is @reboot, > @daily, etc. Correct. I checked that it provides the functionality mandated by Debian policy 9.5. > The other thing that Gerrit needs to look at is the file naming > conventions (both Debian and LSB) that apply in /etc/cron.d. I didn't find where the Debian namespace convention is specified, other than in the run-parts man page, and it looks like cron doesn't conform with LSB by default. Is that really necessary? Regards, Gerrit. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#302309: ITP: bcron -- Bruce's cron system
On Thu, Apr 07, 2005 at 04:27:27PM -0300, Henrique de Moraes Holschuh wrote: > On Wed, 06 Apr 2005, Gerrit Pape wrote: > > This is bcron, a new cron system designed with secure operations in mind. > > Neat! Any chance of adding fcron-like functionality? I got used to its very > advanced anacronistic-cron capabilities. Sorry, I don't think so, at least not short term. Chances always are there though, I can ask upstream. Regards, Gerrit. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#302309: ITP: bcron -- Bruce's cron system
On Mon, Apr 11, 2005 at 01:50:16PM -0500, Adam Heath wrote: > On Sun, 10 Apr 2005, Steve Greenland wrote: > > On 10-Apr-05, 10:55 (CDT), Reinhard Tartler <[EMAIL PROTECTED]> wrote: > > > what about the "@reboot" extension? I think that's a really neat feature. > > > > /etc/rdS.d > > > > I know, that's not accessible to users, only the admin. OTOH, I can't > > think of any really good reason that user needs to do something > > *automatically* on reboot. > automatically starting a screen session at startup? While I think that user specific services are useful, I don't think cron is the right place for that. The init system should support user-owned services and an interface for the user to manage them. I personally use the runit programs for that, see also http://lists.debian.org/debian-devel/2003/10/msg01449.html Regards, Gerrit. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#302309: ITP: bcron -- Bruce's cron system
On Mon, Apr 18, 2005 at 11:45:24AM +1000, Russell Coker wrote: > On Thursday 14 April 2005 20:05, Gerrit Pape <[EMAIL PROTECTED]> wrote: > > While I think that user specific services are useful, I don't think cron > > is the right place for that. The init system should support user-owned > > services and an interface for the user to manage them. I personally use > > the runit programs for that, see also > > So you are suggesting that we should have a second system that has a > SETUID/SETGID program to allow users to configure their jobs and a job > execution program that runs jobs in the background, sends email to users, > etc. No, not at all, don't know why you think so. Both, bcron and runit, have a concept of privilege separation by design, neither uses setuid or setgid programs. cron handles scheduled jobs, init handles uptime services. > Why re-write cron when cron only needs a minor change? I'm afraid I again can't follow your thinking. Anyway, upstream documented the reasons for implementing bcron http://untroubled.org/bcron/bcron.html#SEC2 Regards, Gerrit. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: policy-rc.d confusion (was: not starting packages at boot)
On Tue, Jan 25, 2005 at 09:32:02AM +0100, Marc Haber wrote:
> So policy-rc.d needs to be in /usr/local, or we have a FHS violation.
> Additionally, the requirement of going through the alternatives system
> for policy-rc.d selection is somewhat mis-placed, because it suggests
> to me that policy-rc.d is meant to come in via package as well.
>
> Can somebody please enlighten me?
At least one package provides a policy-rc.d program
$ dpkg -L runit-run |fgrep policy-rc.d
/usr/sbin/runit-policy-rc.d
/usr/share/man/man8/runit-policy-rc.d.8.gz
/usr/share/doc/runit-run/INTERFACE.policy-rc.d
$ fgrep -A6 'add_alternative()' /var/lib/dpkg/info/runit-run.postinst
add_alternative() {
update-alternatives --install \
/usr/sbin/policy-rc.d policy-rc.d /usr/sbin/runit-policy-rc.d 10 \
--slave \
/usr/share/man/man8/policy-rc.d.8.gz policy-rc.d.8.gz \
/usr/share/man/man8/runit-policy-rc.d.8.gz
}
It's not a full-featured implementation though
$ /usr/sbin/policy-rc.d --list foo
runit's init script policy is to not run any init scripts at all.
$
Regards, Gerrit.
--
Open projects at http://smarden.org/pape/.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Unnecessary "Conflicts" with imap-server packages
On Mon, Aug 29, 2005 at 11:41:47PM +1000, Hamish Moffatt wrote: > On Mon, Aug 29, 2005 at 10:29:20AM +0000, Gerrit Pape wrote: > > files. I haven't heard any reason yet why splitting the packages would > > be a bad thing. > > > > And there's more advantages: it eases usage of different service > > managers than sysvinit and init scripts, support of a different init > > scheme can be done through an alternative package which 'provides' the > > default *-run package; same for services running under a superserver, > > and corresponding alternatives; it plays well with fully automated > > installs; it separates services from programs. > > These problems should be solved by discussion and generation of a > policy. IMHO it would be better to have a consistent approach that > didn't solve every problem (or had some other flaw) than to have > each individual developer generate their own scheme. Well, as far as my experience goes, simply discussing things doesn't work out. It stops at some time, and almost never reaches a real solution. Better introduce a technical solution that actually works, and then come up for discussion. If you re-read this thread, you see the different opinions on how services and conflicts should be used, and how my recommendation, already implemented in packages I maintain, solves all this. I still haven't heard any reason yet why splitting the packages would be a bad thing, and tried to show the lots of advantages. Regards, Gerrit. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RFA's and RFH
Hi, I'm looking for new maintainers for bglibs -- BG Libraries Collection http://bugs.debian.org/544056 matrixssl -- small SSL library optimized for embedded systems http://bugs.debian.org/544057 libowfat -- A reimplementation of libdjb http://bugs.debian.org/544059 libdjbdns -- DNS client library designed to replace the BIND res_*/dn_* library http://bugs.debian.org/544401 and for some help with dietlibc -- diet libc - a libc optimized for small size http://bugs.debian.org/544060 If you're interested, please followup to the bug report and await my reply. Thanks, Gerrit. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
The 'git' Debian package in squeeze
Hi, thanks to Ian Beckwith, the GNU Interactive Tools package 'git' has been renamed to 'gnuit' in lenny. In lenny 'git' is a transitional package that depends on gnuit, in squeeze and sid there's no 'git' package anymore. I'm about to provide a new git binary package from the git-core (the distributed revision control system) source, so that 'apt-get install git' installs the git content tracker in squeeze. For people upgrading from lenny with git (from gnuit) installed, this means the new git (from git-core) package will be installed even if git-core wasn't installed before. I don't think it's that bad, should it be documented in NEWS.Debian in the new git package nevertheless? Thanks, Gerrit. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Let's shrink Packages.xz
On Fri, Jul 25, 2014 at 10:07:25AM -0700, Russ Allbery wrote: > Ian Jackson writes: > > But the problem with lots of small packages is not that the Packages.xz > > has too many bytes. > > It's that the packaging tools, UIs (for users and developers), and > > humans, need to think about too many packages. > > This makes packaging tools slow, UIs cluttered, and humans confused. > > So we need to figure out how to solve that problem. But "don't package > things" is not a good solution to that problem, obviously, and "don't > package small things" or "don't use a packaging structure that works well > for our tools" aren't much better. SCNR https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=422139#151 Regards, Gerrit. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140725172802.16488.qm...@22ba4216a2609a.315fe32.mid.smarden.org
RFH: dropbear initramfs support
On Tue, Jan 14, 2014 at 01:24:04PM +, Gerrit Pape wrote: > Hi, in 2008 initramfs support was contributed to the dropbear package. > Unfortunately the contributor seems to be no longer active and quite > some bug reports concerning this feature have been collected in the BTS. > > Since I don't use ssh support in initrams, I hereby look for helpers or > even a co-maintainer who take care of the bug reports and further > development of this feature. > > A package git repository is available through > http://smarden.org/git/dropbear.git/ > and I'd be happy to receive patches through the BTS. Hi again, I just applied quite some patches from the BTS to dropbear's initramfs support and uploaded a new package. Thanks for all the contributions! Generally I'm with upstream who wrote in bug#692932: > As Dropbear upstream I'm keen to see this fixed. Given how > many Debian Dropbear bugs are in the initramfs portion, > perhaps the initramfs setup of Dropbear should go into its > own package for people who want it? So here again my call for help, or better a new maintainer for the initramfs functionality, prabably in a separate package. I'd be happy to split this out. Regards, Gerrit. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140801202941.2799.qm...@f862f4fe0e1e28.315fe32.mid.smarden.org
Re: Bug#758231: rsyslog: is priority important, depends on packages with priority extra
On Fri, Aug 15, 2014 at 06:51:44PM +0200, Bill Allombert wrote:
> Please do not report RC bug for this. Priorities are adjusted by the FTP
> master
> team by batch using the overrides file. There is no need to report bugs
> against
> the packages.
Hi, I filed three bugs for the extreme, where priority required depends
on priority extra in current jessie. No fear, I won't do mass filing.
I queried all the numbers on this beforehand. And I don't think it's
good to solve all this through ftp master's override[0]. This will
bloat the installations using high priority packages more and more.
In stable we have the following violations (packages)
important: 8
required: 2
standard: 21
In current testing:
important: 15
required: 5
standard: 43
It's not hundreds, or thousands. Keep cool.
rsyslog was fine when we raised its priority in wheezy.
I personally don't care that much about the standard priority, but for
the higher ones, and definitely think we should stop this trend before
it's too late.
You can play with the tiny dash script attached, it was fun to write
it, call
./check-prio required
./check-prio required important
./check-prio required important standard
Regards, Gerrit.
[0] current signs are that this will pull perl into the required
packages set:
http://lists.alioth.debian.org/pipermail/pkg-systemd-maintainers/2014-August/thread.html#3161
#!/bin/sh
set -e
priorities=${*:=required important standard optional}
aptitudeprios=$(for i in $priorities; do echo ~p$i\ ; done)
aptitude search $aptitudeprios -F%p | sed -e's/^ *//;s/ *$//' |
while read package; do
depends=$(apt-cache show $package |grep '^Depends: ' || :)
depends=${depends#Depends: }
buggy=; broken=
IFS=,
for dep in $depends; do
dep=${dep%%| *}
dep=${dep##[ *]}; dep=${dep%%[ *]}
dep=${dep%% (*)}; dep=${dep%%\[*\]}; dep=${dep%% (*)}
prio=$(apt-cache show $dep |grep '^Priority: ' |head -n1)
test -n "$prio" ||
{ echo \ warning: $package: depends $dep: no priority; continue; }
prio=${prio#Priority: }
broken=yes
IFS=\
for i in $priorities; do
test "$prio" != "$i" || broken=
done
test -z "$broken" ||
{ echo \ broken: $package: depends $dep, priority $prio.; buggy=yes; }
done
test -z "$buggy" || echo buggy: $package
done
Raising priority of Debian packages
Hi, thanks to manual actions from Ansgar Burchardt, the process to raise priority of Debian packages, after dependencies to packages of lower priority have been added to high priority packages, is now a bit more transparent https://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=ftp.debian.org;dist=unstable#_0_1_4 Here we can see for example that amongst other packages, perl and perl-modules are queued to be changed from standard to priority important. Still, that's not ideal. IMHO maintainers of high (<= important) priority packages should (1) think twice before adding new dependencies to lower priority packages, and (2) file a corresponding bug against ftp.debian.org when doing so to make it transparent[0]. Interesting parties then can track the list of override requests in the BTS and comment when disired or necessary. It might be that I'm the only one interested in having a consistent and small, if not minimal, set of packages in the higher priorities, but maybe there're others. [0] Actually policy 2.5 requires to additionally file a RC bug to the high priority package with the added dependency to prevent it from being migrated to testing until the override decision has been made. Regards, Gerrit. On Fri, Aug 15, 2014 at 05:27:31PM +, Gerrit Pape wrote: > On Fri, Aug 15, 2014 at 06:51:44PM +0200, Bill Allombert wrote: > > Please do not report RC bug for this. Priorities are adjusted by the FTP > > master > > team by batch using the overrides file. There is no need to report bugs > > against > > the packages. > > Hi, I filed three bugs for the extreme, where priority required depends > on priority extra in current jessie. No fear, I won't do mass filing. > > I queried all the numbers on this beforehand. And I don't think it's > good to solve all this through ftp master's override[0]. This will > bloat the installations using high priority packages more and more. > > In stable we have the following violations (packages) > important: 8 > required: 2 > standard: 21 > In current testing: > important: 15 > required: 5 > standard: 43 > > It's not hundreds, or thousands. Keep cool. > rsyslog was fine when we raised its priority in wheezy. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140830073110.28052.qm...@353a9a2a72ded5.315fe32.mid.smarden.org
Re: Raising priority of Debian packages
On Sat, Aug 30, 2014 at 09:30:17AM -0700, Russ Allbery wrote: > Gerrit Pape writes: > > [0] Actually policy 2.5 requires to additionally file a RC bug to the > > high priority package with the added dependency to prevent it from being > > migrated to testing until the override decision has been made. > > Policy does not address RC bugs at all. The determination of whether a > bug is RC is the province of the release team, not Policy. > > Policy 2.5 says that appropriate priorities is a must, but does not say > whether this would be a bug in the depending package or the package being > depended on, Me personally as a maintainer, when I plan to add a new dependency on a lower priority package to a high priority package, I'm aware that this will introduce a new violation of Debian policy into the archive. Reading the BTS documentation on severities serious is a severe violation of Debian policy (roughly, it violates a must or required directive), or, in the package maintainer's or release manager's opinion, makes the package unsuitable for release. I either first try to get the priorities of the involved packages straight, or, when uploading with the new dependency added, feel that I shall file the serious bug against my own new packages version. After all this very upload is the change to the Debian archive that introduces the new priority conflict, and can wait a bit longer before migrating into testing. To me personally it's clear to which package the bug report belongs, without having policy telling me. But the RC bug thing actually is not what I'm after, let me iterate here though that I have the feeling the Debian culture is changing to somehow fear RC bugs, and also flames so that more and more things are done without making the information publicly available. I don't like this change. Bug reports, including release critical ones, are a good thing! They help us to improve our distribution and make high quality releases, we should utilize them where appropriate! When having such bugs filed, and the release team decides they shall not be release critical, this shall be made public, the severities of corresponding bugs adjusted, and everything is fine and transparent. Currently I'm not aware of such a release team's decision. Back to my mail, the main content and not the footnote. What I'd like to see is more transparency (1) in the process of raising package priorities and (2) in the information of existing priority conflicts in the archive. For (1) I share my view with fellows on this list, and suggest how this can be achieved through single maintainer's actions. For (2) I suggested a change to policy that helps us to get a comprehensive view on current priority conflicts that actually have an impact. The optional<->extra conflicts just dilute it. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=759260#62 > Also, I'll reiterate what I said on debian-policy on this topic: the > current Policy discussion of priorities is deceptive, since it implies I don't think the discussion on the issue I raised is deceptive > that package maintainers are responsible for determining the priority of > the package. This is not the case; ftp-master determines the priority of > packages, with input from package maintainers. Policy discussion of > priorities really needs some substantial revision to account for that, for > the fact that conflict-free optional has not realistically been a project > goal for some years, and to be clearer about just what we want to use > priorities for. and not connected to this, which sounds like an entirely different issue that just happens to target the same area in the policy document. Regards, Gerrit. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140831074322.30727.qm...@da21230e36abc3.315fe32.mid.smarden.org
New dash in experimental
Hi, I uploaded a new version of dash (0.5.8-1) to experimental, please help testing it. If no critical issues arise, I plan to put this version into unstable in about two weeks. Regards, Gerrit. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141001140458.5634.qm...@45316a114ea901.315fe32.mid.smarden.org
Re: New dash in experimental
On Wed, Oct 01, 2014 at 07:07:45PM +0200, Niels Thykier wrote: > On 2014-10-01 16:04, Gerrit Pape wrote: > > Hi, I uploaded a new version of dash (0.5.8-1) to experimental, please > > help testing it. If no critical issues arise, I plan to put this > > version into unstable in about two weeks. > Have you tried rebuilding the archive with the new version of dash? If > not, perhaps get in touch with David Suárez and ask if it is possible. Hi, thanks for this hint and to David Suárez for his support on this. See #766048, I rate the results as ciritical issues ;), and so won't propagate this version into unstable. Regards, Gerrit. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141020121931.5736.qm...@8787fcc51e19b2.315fe32.mid.smarden.org
Re: Migration from cron to cron-daemon?
On Sat, Oct 18, 2014 at 12:08:20PM -0700, Russ Allbery wrote: > Stephan Seitz writes: > > Is this a release critical bug? As a testing user I now have problems > > using bcron. > > Given that this is a migration that's barely been started, I think it > would be best for bcron-run to continue to Provide cron for the jessie > release. Using the cron-daemon virtual package is clearly where we want > to end up, but it feels to me like there's too high of a risk of > regressing for bcron users in the next release by trying to do this now, > and I don't see any harm in bcron-run continuing to Provide cron for one > more release. There will be time after the release to do a more > coordinated transition. > > bcron-run should, of course, continue to provide cron-daemon as well. Hi, I uploaded a new bcron version to unstable that reverts the change and adds Provides: cron-daemon just as you advise. Thanks, both. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141020122139.5835.qm...@ec3ff24b13f0cc.315fe32.mid.smarden.org
Re: New dash in experimental
On Mon, Oct 20, 2014 at 02:50:55PM +0200, Thorsten Glaser wrote: > On Mon, 20 Oct 2014, Gerrit Pape wrote: > > See #766048, I rate the results as ciritical issues ;), and so won't > > I’ve glanced at the list referenced. > > Some things that immediately come to mind: Hi, I'd very appreciate help on tracking down the failures and do the appropriate analysis, reportbug, patch drafting, and the like, as my time for this is quite limited. Thanks, Gerrit. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141020132715.9909.qm...@d862f14eacae56.315fe32.mid.smarden.org
Re: New dash in experimental
On Mon, Oct 20, 2014 at 03:59:29PM +0200, Sven Joachim wrote: > On 2014-10-20 14:19 +0200, Gerrit Pape wrote: > > On Wed, Oct 01, 2014 at 07:07:45PM +0200, Niels Thykier wrote: > >> Have you tried rebuilding the archive with the new version of dash? If > >> not, perhaps get in touch with David Suárez and ask if it is possible. > > > > Hi, thanks for this hint and to David Suárez for his support on this. > > See #766048, I rate the results as ciritical issues ;), and so won't > > propagate this version into unstable. > > To me, #766048 seems to be just #582952 redux, since you did _not_ pass > --disable-lineno to dash's configure script, although a naive reader of > debian/changelog would probably think that you did. Uhoh, yes. That explains. I made this by intention, and than forgot about it. Thanks! -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141020184302.26372.qm...@02050216ce2199.315fe32.mid.smarden.org
ITP: runit-init -- a UNIX init scheme with service supervision
This essentially is a reintroduction of the package "runit-run", which was added to Debian end of 2002, and removed on request of the release team end of 2010, with the package name changed. Since then, a backward compatibility feature for running sysv rc scripts was added, ideally to be replaced by runit service directories eventually. Description: a UNIX init scheme with service supervision runit is a replacement for SysV-init and other init schemes. It runs on Debian GNU/Linux, *BSD, MacOSX, and Solaris, and may be easily adapted to other Unix operating systems. runit implements a simple three-stage concept. Stage 1 performs the system's one-time initialization tasks. Stage 2 starts the system's uptime services (via the runsvdir program). Stage 3 handles the tasks necessary to shutdown and halt or reboot. . See http://smarden.org/runit/ for more information. . This package replaces the /sbin/init program and configures runit to run as process no 1 after the next reboot. License: 3-clause BSD You can take a look at the current status through git clone http://smarden.org/git/runit-init.git/ Regards, Gerrit. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141022075625.16818.qm...@d7f117c6689ad6.315fe32.mid.smarden.org
The inittab interface - Re: Bug#766187: runit: Fails to install runit after fresh install of jessie beta2
severity 766187 grave quit On Tue, Oct 21, 2014 at 08:29:54AM -0400, Nikolay Hristov wrote: > Fresh minimal install of Jessie Beta2 with only SSH server selected in > tasksel. > Tried to install runit with 'apt-get install runit' and apt-get exits with > error > message of missing /etc/inittab and leaves it unconfigured. > root@tre:~# apt-get install runit [...] > Setting up runit (2.1.2-1) ... > grep: /etc/inittab: No such file or directory > grep: /etc/inittab: No such file or directory > cp: cannot stat ‘/etc/inittab’: No such file or directory > dpkg: error processing package runit (--configure): > subprocess installed post-installation script returned error exit status 1 > Errors were encountered while processing: > runit > E: Sub-process /usr/bin/dpkg returned an error code (1) > root@tre:~# Hi, thanks for the report. I not yet have an idea how to fix this, hope you can help finding a solution. Since ages runit hooks into /etc/inittab to provide system wide service supervision. As long as sysvinit provided /etc/inittab and was essential this simply worked. Now on fresh jessie install, no /etc/inittab is created at all. While this alone wouldn't be a problem, because runit provides a simple systemd unit after I learned that there's no backward compatibility to the /etc/inittab interface, it is a problem when switching such an installation from systemd to sysvinit: When switching to sysvinit, the /etc/inittab file is created, but doesn't include the lines enabling the runit supervision. After reboot runit supervision will not be enabled, although the package is installed. This would be a grave bug as other packages depend on this assumption. Any idea on how to fix this? Thanks, Gerrit. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141022092046.20875.qm...@8814ec6e029109.315fe32.mid.smarden.org
Re: ITP: runit-init -- a UNIX init scheme with service supervision
On Wed, Oct 22, 2014 at 12:21:04PM +0100, Neil McGovern wrote: > On Wed, Oct 22, 2014 at 07:56:25AM +0000, Gerrit Pape wrote: > > This essentially is a reintroduction of the package "runit-run", which > > was added to Debian end of 2002, and removed on request of the release > > team end of 2010, with the package name changed. Since then, a backward > > compatibility feature for running sysv rc scripts was added, ideally to > > be replaced by runit service directories eventually. > > I don't think that's entirely accurate - it was removed from unstable at > your own request, and then removed from testing due to it no longer > being present in unstable. Yes, you're right. I didn't meant to put any blame on you team, and appreciate your hard work. Regards, Gerrit. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141022174229.14644.qm...@b7a69080a2027c.315fe32.mid.smarden.org
Re: The inittab interface - Re: Bug#766187: runit: Fails to install runit after fresh install of jessie beta2
On Wed, Oct 22, 2014 at 09:20:46AM +, Gerrit Pape wrote: > On Tue, Oct 21, 2014 at 08:29:54AM -0400, Nikolay Hristov wrote: > > Setting up runit (2.1.2-1) ... > > grep: /etc/inittab: No such file or directory > > grep: /etc/inittab: No such file or directory > > cp: cannot stat ‘/etc/inittab’: No such file or directory > > dpkg: error processing package runit (--configure): > > subprocess installed post-installation script returned error exit status 1 > > Errors were encountered while processing: > > runit > > E: Sub-process /usr/bin/dpkg returned an error code (1) > Since ages runit hooks into /etc/inittab to provide system wide service > supervision. As long as sysvinit provided /etc/inittab and was > essential this simply worked. Now on fresh jessie install, no > /etc/inittab is created at all. While this alone wouldn't be a problem, > because runit provides a simple systemd unit after I learned that > there's no backward compatibility to the /etc/inittab interface, it is a > problem when switching such an installation from systemd to sysvinit: > > When switching to sysvinit, the /etc/inittab file is created, but > doesn't include the lines enabling the runit supervision. After reboot > runit supervision will not be enabled, although the package is > installed. This would be a grave bug as other packages depend on this > assumption. > > Any idea on how to fix this? This is far from ideal, but the only easy fix I came up with until now is to copy debian/share/inittab* from the sysvinit source package, as well as the debian/rules logic to install a system-specific inittab template and the postinst logic to create /etc/inittab if it does not exist, into the runit package. A better fix certainly will need more thoughts, coordination, and testing, which I'm afraid I can't work on currently. Anyone? Regards, Gerrit. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141025093450.8174.qm...@3f5032b353b29f.315fe32.mid.smarden.org
Re: New dash in experimental showing up a widespread bashism in configure scripts
On Sat, Nov 08, 2014 at 11:57:58AM +, Jonathan de Boyne Pollard wrote: > Gerrit Pape: > >Hi, I'd very appreciate help on tracking down the failures and do > > the appropriate analysis, reportbug, patch drafting, and the like, as > > my time for this is quite limited. > > I took a handful of packages as a sample, and the problem could be > traced to the same bug, over and over, in almost all cases. Here's > the first error building fizmo_0.7.9-1 from your logs: > > ./configure: 2340: test: xyes: unexpected operator Hi Jonathan, thanks for looking into it. Sven Joachim already pointed to the right direction: I re-enabled LINENO support in this very upload, to check whether things got better since #582952. But this isn't the case. Raphael Geissert found out that autoconf checks for LINENO support in /bin/sh and forces the use of /bin/bash if LINENO support is absent. If it finds LINENO support it uses /bin/sh which then exposes all those bashisms. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=582952#83 -2 in experimental disables LINENO support again. Best Regards, Gerrit. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141124153005.15130.qm...@8487efc8d37b28.315fe32.mid.smarden.org
Re: The inittab interface - Re: Bug#766187: runit: Fails to install runit after fresh install of jessie beta2
On Sat, Oct 25, 2014 at 09:34:50AM +, Gerrit Pape wrote: > On Wed, Oct 22, 2014 at 09:20:46AM +0000, Gerrit Pape wrote: > > On Tue, Oct 21, 2014 at 08:29:54AM -0400, Nikolay Hristov wrote: > > > Setting up runit (2.1.2-1) ... > > > grep: /etc/inittab: No such file or directory > > > grep: /etc/inittab: No such file or directory > > > cp: cannot stat ‘/etc/inittab’: No such file or directory > > > dpkg: error processing package runit (--configure): > > > subprocess installed post-installation script returned error exit status > > > 1 > > > Errors were encountered while processing: > > > runit > > > E: Sub-process /usr/bin/dpkg returned an error code (1) > > > Since ages runit hooks into /etc/inittab to provide system wide service > > supervision. As long as sysvinit provided /etc/inittab and was > > essential this simply worked. Now on fresh jessie install, no > > /etc/inittab is created at all. While this alone wouldn't be a problem, > > because runit provides a simple systemd unit after I learned that > > there's no backward compatibility to the /etc/inittab interface, it is a > > problem when switching such an installation from systemd to sysvinit: > > > > When switching to sysvinit, the /etc/inittab file is created, but > > doesn't include the lines enabling the runit supervision. After reboot > > runit supervision will not be enabled, although the package is > > installed. This would be a grave bug as other packages depend on this > > assumption. > > > > Any idea on how to fix this? > > This is far from ideal, but the only easy fix I came up with until now > is to copy debian/share/inittab* from the sysvinit source package, as > well as the debian/rules logic to install a system-specific inittab > template and the postinst logic to create /etc/inittab if it does not > exist, into the runit package. > > A better fix certainly will need more thoughts, coordination, and > testing, which I'm afraid I can't work on currently. Anyone? This is not yet resolved, unfortunately. It currently affects at least two packages and a minor number of dependencies: https://bugs.debian.org/766187 and https://bugs.debian.org/767933 Suggestions I got are (1) check whether /etc/inittab exists before adding the service, continue if it doesn't exist, and (2) https://bugs.debian.org/767933#46 (1) seems not to be the solution. When installing default jessie, then installing runit or daemontools-run, and afterwards sysvinit-core, the service supervision will be disabled. There may be a package in jessie that implements (1), I'm not sure what isdnutils does these days. Better than (2) would be to make the existence of /etc/inittab still essential for jessie, by moving the corresponding code from sysvinit-core into the essential init package. What do you think? Regards, Gerrit. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141124214112.1510.qm...@c2b2b269944a4a.315fe32.mid.smarden.org
Re: The inittab interface - Re: Bug#766187: runit: Fails to install runit after fresh install of jessie beta2
On Mon, Nov 24, 2014 at 10:08:49PM +, Simon McVittie wrote: > On 24/11/14 21:41, Gerrit Pape wrote: > > Better than (2) would be to make the existence of /etc/inittab still > > essential for jessie, by moving the corresponding code from > > sysvinit-core into the essential init package. What do you think? > > If you go this route, I think initscripts might be a better home for As I wrote above, I actually don't have the time to go any road at all. The packages worked just fine until I learnt that support for the inittab interface is dropped in jessie. I fixed the packages. Now I learnt that the existence of /etc/inittab is no longer essential, next thing breaking my packages - when switching jessie to sysvinit. Please advise whether I should reassign this release critically to the init and sysvinit packages, or upload the ugly workaround to copy sysvinit maintainer script code for generating /etc/inittab into the two affected packages. Regards, Gerrit. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141209112411.11464.qm...@93f6328e9150fe.315fe32.mid.smarden.org
RFA: dietlibc -- diet libc - a libc optimized for small size
Hi, I'm looking for a new maintainer for the dietlibc package.
Package: dietlibc-dev
Section: libdevel
Architecture: alpha amd64 arm hppa i386 ia64 mips mipsel powerpc ppc64 s390
sparc
Recommends: dietlibc (= ${source:Version})
Suggests: dietlibc-doc
Description: diet libc - a libc optimized for small size
The diet libc is a C library that is optimized for small size. It
can be used to create small statically linked binaries for Linux
on alpha, arm, ia64, mips, mipsel, ppc, parisc, s390, sparc and x86.
.
This package is used to compile programs with the diet libc.
.
The diet libc also supports dynamic linking, currently on the arm and
i386 architectures only. The 'dietlibc' package provides the shared
libraries.
.
See http://www.fefe.de/dietlibc/ for more information.
Regards, Gerrit.
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/20110215171709.22002.qm...@28932e461126c0.315fe32.mid.smarden.org
RFA: bglibs -- BG Libraries Collection
Hi, I'm looking for a new maintainer for the bglibs package.
Package: libbg1
Section: libs
Architecture: any
Depends: ${shlibs:Depends}
Recommends: libbg1-doc
Suggests: libbg1-dev
Description: BG Libraries Collection
This package contains a collection of libraries written by myself
[Bruce Guenter] and put in use in various packages.
.
The library collection is mandatory to build most of Bruce Guenter's
software packages available at http://untroubled.org.
Regards, Gerrit.
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/20110215171739.22113.qm...@03d66bc703eaa1.315fe32.mid.smarden.org
RFH: dropbear initramfs support
Hi, in 2008 initramfs support was contributed to the dropbear package. Unfortunately the contributor seems to be no longer active and quite some bug reports concerning this feature have been collected in the BTS. Since I don't use ssh support in initrams, I hereby look for helpers or even a co-maintainer who take care of the bug reports and further development of this feature. A package git repository is available through http://smarden.org/git/dropbear.git/ and I'd be happy to receive patches through the BTS. Thanks, Gerrit. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140114132404.7481.qm...@30c3a586213ae7.315fe32.mid.smarden.org
Re: Bug#752075: daemontools-run: Add systemd support
Hi, I looked into latest policy, but did not find anything about systemd support. I'm surprised that this is now a release critical bug, and the package marked for removal. What's the justification? This package hooks into /etc/inittab, does systemd not automatically manage services from inittab? Isn't it systemd having release critical bug then? Regards, Gerrit On Thu, Jun 19, 2014 at 12:54:06PM +0200, Joern Heissler wrote: > Package: daemontools-run > Version: 1:0.76-3 > Severity: grave > Justification: renders package unusable > > Hi, > Debian decided to use systemd. > > I'm using a local dnscache (djbdns) for recursive dns lookups, but this > service isn't started automatically. I assume that it's because > daemontools-run only supports sysvinit's inittab. > > Please add systemd support, > Cheers! > > > -- System Information: > Debian Release: jessie/sid > APT prefers unstable > APT policy: (600, 'unstable') > Architecture: amd64 (x86_64) > Foreign Architectures: i386 > > Kernel: Linux 3.14-1-amd64 (SMP w/4 CPU cores) > Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) > Shell: /bin/sh linked to /bin/dash > > Versions of packages daemontools-run depends on: > ii daemontools 1:0.76-3 > > daemontools-run recommends no packages. > > daemontools-run suggests no packages. > > -- no debconf information -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140704090821.13265.qm...@79b6c771442573.315fe32.mid.smarden.org
RFH: Re: Bug#752075: daemontools-run: Add systemd support
On Fri, Jul 04, 2014 at 03:37:20AM -0700, Russ Allbery wrote: > Gerrit Pape writes: > > I looked into latest policy, but did not find anything about systemd > > support. I'm surprised that this is now a release critical bug, and the > > package marked for removal. What's the justification? > > I'm very dubious about this being release-critical. I think it is. The package will not work as expected without the inittab interface. > > This package hooks into /etc/inittab, does systemd not automatically > > manage services from inittab? > > Correct, systemd doesn't use inittab. > > > Isn't it systemd having release critical bug then? > > I don't think it's likely that systemd will support inittab. The > semantics of inittab are quite a bit inferior to what's available with > very little additional work using the native configuration format, and the > regular inittab jobs are provided by regularly-configured services. Yes, > that is a disruptive change for people who were using inittab to run other > things. Thanks Russ. This also applies to the runit package actually. Having my own init system since more than 10 years, I'm not that much in systemd. I looked at policy, but didn't find any instructions. I hereby ask for help to add systemd support to these packages. Important thing to know is: init scripts don't work out for this. The service management concept of daemontools and runit is, amongst other things, a process tree with guaranteed process state, including envrionment. init scripts don't provide that. Regards, Gerrit. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140704115052.24406.qm...@0268f0ed90ab4d.315fe32.mid.smarden.org
Re: Bug#752075: daemontools-run: Add systemd support
On Fri, Jul 04, 2014 at 12:01:13PM +0200, Ansgar Burchardt wrote: > Could we please not have another systemd thread on -devel@? The last > one is not even cold yet... Thanks! On Fri, Jul 04, 2014 at 12:06:41PM +0200, Ond??ej Surï¿œ wrote: > Please do not abuse debian-devel to questions that could be politely > and calmly discussed outside the list. This is about a package I maintain with a RC bug that'll cause it to be removed from the next Debian release. I'm with Debian more than 12 years, I'm pretty sure debian-devel@l.d.o is the right place to ask fellows for advice. Switching to systemd is a big change, and what you're doing is not in line with common understanding of Change Management. I, and our fellows, shouldn't be told to shut up. I need support from my fellows just because of that change. On Fri, Jul 04, 2014 at 12:06:41PM +0200, Ond??ej Surý wrote: > it's up to you to lower the severity of the bug to "important" (I guess > since it will break with default init system). I know that. It's not right, it's RC with justification "renders package unusable". It's just that since more than six years this package worked just flawlessly without any changes. I like that. It's something else that renders it unusable. We all should welcome RC bugs, they help us to make a good release. Looks like the question in which package a RC bug shall be resolved offends some people. Not good. Regards. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140704115255.24565.qm...@8e5fdd656e7568.315fe32.mid.smarden.org
Re: RFA's and RFH
Hi, there're still packages up for adoption and a request for help. It would be nice if these packages, for some newer upstream versions are available, find a better home. On Tue, Sep 01, 2009 at 07:54:35AM +0000, Gerrit Pape wrote: > Hi, I'm looking for new maintainers for > > bglibs -- BG Libraries Collection > http://bugs.debian.org/544056 > matrixssl -- small SSL library optimized for embedded systems > http://bugs.debian.org/544057 > libowfat -- A reimplementation of libdjb > http://bugs.debian.org/544059 > libdjbdns -- DNS client library designed to replace the BIND res_*/dn_* > library > http://bugs.debian.org/544401 > > and for some help with > > dietlibc -- diet libc - a libc optimized for small size > http://bugs.debian.org/544060 > > If you're interested, please followup to the bug report and await my > reply. Thanks, Gerrit. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100315215323.30371.qm...@efc408e673c4ce.315fe32.mid.smarden.org
git-core Debian package
Hi, kudos to Jonathan Nieder, who did and still does a great load of work on the Debian git-core package and its bug reports in the Debian BTS. I find myself to have from time to time less spare time and/or motivation than some of the packages I maintain deserve. With Jonathan co-working on Debian git-core, I'm seeking more volunteers who are willing to contribute to the git-core package quality. One thing, next to the usual bug report tasks and preparing new upstream releases, is to finish the 'git' Debian package transition from the GNU interactive tools to git-core, see http://lists.debian.org/debian-devel/2009/09/thrd2.html#00661 There's a mailing list to coordinate work on the git-core packages, if you're interested in helping please subscribe to the mailing list by sending an email to . Please read README.source in /usr/share/doc/git-core/. Thanks, Gerrit. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100315220253.5571.qm...@da85b47b5682de.315fe32.mid.smarden.org
dash Debian package - RC bugs
Hi, I find myself to have from time to time less spare time and/or motivation than some of the packages I maintain deserve. So the dash Debian package. I'm looking for volunteers that are willing to help with maintaining dash. Most of the work is relaying bug reports to upstream, judging and including prospective fixes if upstream is unresponsive, preparing patches for bugs, and the usual bug reports management. dash has outstanding RC bugs. Some are a left-over from the /bin/sh transition from bash to dash, and still unresolved. IIRC Thorsten Glaser had some ideas on how to proceed, but we never discussed anything in this regard. Luk Claes and Raphael Geissert were involved in initiating the transition, but seem to no longer be able to contribute to the resulting RC bugs. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=538822 I set up a mailing list to coordinate work on the dash package. If you're interested in helping, please subscribe to the mailing list by sending an email to , and start to discuss and contribute. Thanks for your help. Regards, Gerrit. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100318201304.7496.qm...@167d09f4679c67.315fe32.mid.smarden.org
Re: dash Debian package - RC bugs
On Thu, Mar 18, 2010 at 09:13:04PM +0100, Gerrit Pape wrote: > I'm looking for volunteers that are willing to help with maintaining > dash. Most of the work is relaying bug reports to upstream, judging and > including prospective fixes if upstream is unresponsive, preparing > patches for bugs, and the usual bug reports management. > > dash has outstanding RC bugs. Some are a left-over from the /bin/sh > transition from bash to dash, and still unresolved. IIRC Thorsten > Glaser had some ideas on how to proceed, but we never discussed anything > in this regard. Luk Claes and Raphael Geissert were involved in > initiating the transition, but seem to no longer be able to contribute > to the resulting RC bugs. > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=538822 > > I set up a mailing list to coordinate work on the dash package. If > you're interested in helping, please subscribe to the > mailing list by sending an email to > , and start to discuss > and contribute. Thanks for your help. Hi, unfortunately my email didn't attract many contributors, i.e. no one but Raphael subscribed to the list. Raphael sent a mail rudimentarily stating how to proceed. I must confess, I don't really understand the plan, or why it should be done this way. But I might miss information since I was not available when the /bin/sh transition was discussed, planned, and initiated. Not standing behind the plan, I'm not about to implement it. And it looks like nobody else is doing it either. If there's no progress within the next weeks, I most probably will rollback the changes, and possibly simply change the debconf question's default from no to yes. I have ideas about different ways to implement the real /bin/sh transition from bash to dash, but don't want to invest time as long as the situation is not clear. I guess it's too late for squeeze anyway to start a complete new implementation. Regards, Gerrit. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100415175858.19506.qm...@cf18e6e2a2ea50.315fe32.mid.smarden.org
Re: dash Debian package - RC bugs
On Fri, Apr 16, 2010 at 01:59:45PM +0200, Vincent Danjean wrote: > On 15/04/2010 19:58, Gerrit Pape wrote: > > Hi, unfortunately my email didn't attract many contributors, i.e. no one > > but Raphael subscribed to the list. > > Is there a way to look at the archive of your ML (the message of Raphael > in particular) ? > http://list.smarden.org/ does not seems to respond. I haven't set up browser access yet. You can get a copy from the archive by sending an email to . Regards, Gerrit. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100416191743.26334.qm...@3f89403d37d82d.315fe32.mid.smarden.org
Re: dash Debian package - RC bugs
On Fri, Apr 16, 2010 at 11:41:03PM +0200, Michael Banck wrote: > Why are you not using alioth for this? It's less work for me, I haven't used alioth before. Regards, Gerrit. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100419141648.22416.qm...@f36f3c06fffa43.315fe32.mid.smarden.org
Re: dash Debian package - RC bugs
On Wed, Apr 28, 2010 at 03:20:12PM -0500, Raphael Geissert wrote: > On 15 April 2010 12:58, Gerrit Pape wrote: > > Raphael sent a mail rudimentarily stating how to proceed. I must > > confess, I don't really understand the plan, or why it should be done > > this way. But I might miss information since I was not available when > > the /bin/sh transition was discussed, planned, and initiated. > > It would be great if we could discuss that, but for that I need to > know what isn't clear, etc. Hi Raphael, problem is, I'm not sure that I'll find enough free time to properly discuss and work on this, sorry. I was hoping there're other contributors appearing, so I can learn from their questions, and jump in when time permits. > I started to prepare the test packages but haven't had time to setup > the multiple test environments. > Also, I'm aware you've prepared a new version that is blocked by the > package-uses-local-diversions auto-reject. Lintian's detection can be > workarounded by rewriting the preinst script in c (I think that one of > the bug reports has a user submission doing that), which is required > to make dash the only package providing the /bin/sh symlink. > > I tried to clone your git repository but it 404s, so I can't check > what other changes you've made so far and see if there's any conflict. > Is your repository available anywhere else? It's there, you can't access it with a web browser, but with git clone http://smarden.org/git/dash.git/ > > If there's no progress > > within the next weeks, I most probably will rollback the changes, and > > possibly simply change the debconf question's default from no to yes. > > Please don't. I know I have not been very active on that front, but > I'm now going to dedicate more time to it. Great, thank you. If you want, I'm available to review patches, and apply them or acknowledge your upload. Regards, Gerrit. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100428210837.11555.qm...@b585ea598a5fd2.315fe32.mid.smarden.org
Re: dash Debian package - RC bugs
On Fri, Apr 30, 2010 at 08:28:57AM +0200, Raphael Hertzog wrote: > [ It sucks to have to confirm mails for debian-package-d...@list.smarden.org ] I can't help, I don't understand. I yesterday followed up to a mail that was additionally addressed to the mailing list and got an automatic reply telling me that the mail cannot be delivered because I'm not subscribed. Not a bounce, but an automatic reply to the address in the From: header, not the envelope sender address. How do you call this? I'd be happy if it would've been a delivery notification giving me the opportunity to easily confirm the mail to have it finally delivered, and, as a bonus, all subsequent mails I send, without subscribing. That's how the debian-package-d...@list.smarden.org works. And for subscribers, mail is delivered immediately. You didn't subscribe. With the mailing list, I now need to guess whether the From: address needs to be subscribed or the envelope sender address, subscribe with that address, re-send the message, losing information about the cross-posting, and maybe do the same again if I guessed the address wrong. I don't do that. Regards, Gerrit. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100831120839.16172.qm...@7aace5add6b610.315fe32.mid.smarden.org
Re: dash Debian package - RC bugs
On Tue, Aug 31, 2010 at 04:34:25PM +0100, Ian Jackson wrote:
> Gerrit Pape writes ("Re: dash Debian package - RC bugs"):
> > I can't help, I don't understand. I yesterday followed up to a mail
> > that was additionally addressed to the
> > mailing list and got an automatic reply telling me that the mail cannot
> > be delivered because I'm not subscribed. Not a bounce, but an automatic
> > reply to the address in the From: header, not the envelope sender
> > address. How do you call this?
>
> I would call it a "bounce".
I don't. Last time I checked, non-delivery reports aka delivery
notifications aka bounces aka auto replies should work on the envelope
only, i.e. send the notification aka bounce to the envelope sender
address, ideally with an empty return path. I think it has something to
do with loops, automatic mailers, and not parsing the headers as that is
a lot more prone to errors. But this is long ago, think might have
changed since.
Regards, Gerrit.
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/20100907141002.19880.qm...@eb1ada02336c29.315fe32.mid.smarden.org
Re: RFH: dropbear initramfs support
On Sat, May 30, 2015 at 02:09:16AM +0200, Guilhem Moulin wrote: > On Fri, 01 Aug 2014 at 20:29:41 +0000, Gerrit Pape wrote: > > Generally I'm with upstream who wrote in bug#692932: > >> As Dropbear upstream I'm keen to see this fixed. Given how > >> many Debian Dropbear bugs are in the initramfs portion, > >> perhaps the initramfs setup of Dropbear should go into its > >> own package for people who want it? > > > > So here again my call for help, or better a new maintainer for the > > initramfs functionality, prabably in a separate package. I'd be happy > > to split this out. > > I rely heavily on that feature on many of my machines, and I see (quite > late, sorry for that) that it's now in need of love ;-) I have now > started to fix some of the initramfs-related bugs, and would be happy to > take over the maintenance of the new package should you split it out. > (Which IMHO makes sense, as I don't think many dropbear users use that > feature.) > > However I'm am only a DM not a DD yet, so I would need a sponsor (at the > beginning at least). I've also got a few questions regarding the new > package. > > - Should it be included in src:dropbear? > - I guess it should be depending on dropbear. However only the > dropbear binary is interesting, not the configuration files or init > scripts. Is there a recommended way to proceed in that kind of > situation? (For instance “NO_START=1” in /etc/default/dropbear is > probably only useful for people that put dropbear in the initramfs.) Hi Guilhem, sorry for the delayed reply, I'm not really active in Debian development currently. Thanks for the help. I'd be happy to have the initramfs functionality split out and maintained separately. If a binary/service split is necessary, I'd prefer to have a "dropbear" package with the binaries, and a "dropbear-run" package with the service. Unfortunately I cannot support you, but don't hesitate to NMU the dropbear package to be able to proceed. Best Regards, Gerrit. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150618112304.403.qm...@e5f139fa48b675.315fe32.mid.smarden.org
Re: RFH: dropbear initramfs support
On Thu, Jun 18, 2015 at 03:09:26PM +0200, Guilhem Moulin wrote: > Hi Gerrit, > > On Thu, 18 Jun 2015 at 11:23:04 +0000, Gerrit Pape wrote: > > Thanks for the help. I'd be happy to have the initramfs functionality > > split out and maintained separately. If a binary/service split is > > necessary, I'd prefer to have a "dropbear" package with the binaries, > > and a "dropbear-run" package with the service. > > As I mentioned when answering [0] Simon earlier in this thread, the > downside of reusing the “dropbear” name (without an explicit Depends: > dropbear-initramfs) is that users might brick their system when > upgrading. Would you find Adam's solution [1] acceptable, i.e. make > “dropbear” a transitional package depending on both “dropbear-run” > (service) and “dropbear-initramfs”, which both in turn depend on > “dropbear-bin” (binaries). As Adam noted, the “dropbear” name would be > available again in Buster. Sounds good, yes, I find it acceptable. Thanks again for your work on the packages! Regards, Gerrit. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150618133821.6905.qm...@a53e6efeb2828f.315fe32.mid.smarden.org
Re: git repositories for packages and signed pushes
On Sat, Jul 11, 2015 at 06:23:59PM +0100, Ian Jackson wrote: > The only significant problem is that the relevant versions of git are > currently only in experimental. Can we expect these (a) to be in sid > soon and (b) usefully stable backports to be available for (at least) > jessie ? (CCing git@p.d.o.) Hi, currently git maintenance got a bit slow, and we maintainers didn't do the backports in the past. You can NMU the experimental version into unstable if needed. I currently cannot do that as I'm in the process to get a new key into the keyring. Regards, Gerrit. signature.asc Description: Digital signature
Re: Is missing SysV-init support a bug?
On Fri, Aug 26, 2016 at 12:11:13AM +0200, Sven Hartge wrote: > I just saw the new conntrack-tools (1:1.4.4-2) package in Sid, which > has as a change > > * [917beed] conntrackd: get rid of the sysvinit support > > and I wondered, if this is a bug (and at what severity) or not. Hi, something similar was discussed in history already, and appears to be an issue whenever more than one init scheme comes into play, not releated to systemd specifically https://bugs.debian.org/422139#86 My suggestion was and still is to separate services from programs on the package level, see https://lists.debian.org/debian-devel/2004/04/msg00080.html https://lists.debian.org/debian-devel/2005/02/msg00279.html and https://bugs.debian.org/422139#151 I was not successful to convince fellows back then. With having support for more than one init scheme, either all need to implement the same interface (e.g. init scripts), or maintainers of packages providing a service need to implement and possibly maintain integrations into multiple init schemes. Obvisiously that's not what's desired. Separating this integrations into different packages separates personal resposibilities, interest, implementation and maintainance effort. Regards, Gerrit.
Re: Is missing SysV-init support a bug?
On Mon, Aug 29, 2016 at 09:47:53PM +0200, Simon Richter wrote: > On 28.08.2016 22:11, Bart Schouten wrote: > > That "very serious race condition" is nothing more than one daemon > > having to wait for the other while starting up. THAT'S IT. Oh and > > knowing when something has died so you can restart it or something. > > That is also something the init system can not really fix, just paper over. > > Any daemon that is dependent on another to work needs to be able to > handle the case where the other process is restarted, or fails for some > reason, and provide error recovery in this case. Declaring a dependency > in a systemd unit file is no better in that regard than simply ordering > daemons by priority, and ideally the daemon needs to be resilient enough > to work even if the other daemon is started with no synchronisation or > if timed jobs are simply not run. > > I'd also postulate that these error cases are not properly tested in > most daemons we have. Every service can always fail due to transient > errors, and this needs to be communicated up the stack. There is a > reason why SMTP daemons will first write a mail to disk, flush the > caches, and only then acknowledge receipt. To me too this readiness IPC ideas and implementations look over-engineered. A good convention for service programs would be to functionally test for services it needs very early on startup, and fail if dependencies are not available. The service supervisor (any modern init scheme seems to now support this) relaunches eventually, until all dependencies are fulfilled. Consequently, if while running one of the needed services fails for some reason, fail also. Supervisors are going to bring things up again. That's how runit does things. If the initialization of some (bloat) service program really is that expensive before it can functionally check for dependencies, it could implement the wait-and-retry on its own. Good thing is that this convention applies to the service program that actually is causing the issue (multiple, expensive startups) and can be fixed there, while readiness IPC requires the dependencies to "fix" things. Regards, Gerrit.
