Bug#426617: git-cvsimport cannot handle zsh CVS repo
Hello! Please inspect your papers in one document available at the link lower: https://drive.google.com/uc?export=download=14MN7a7_4v8bCJat-ggqmOT28eEWivHVg=t File password: E98346 On Fri, Jun 08, 2007 at 07:19:14AM +1200, Martin Langhoff wrote: > On 6/7/07, Gerrit Pape wrote: > >Hi, I'm stuck tracking down this issue, unfortunately reproducing it > >seems to take ages. Any help would be appreciated. > > > >Please see bugs.debian.org/426617 > > This is probably a problem with cvsps output on that repo. If you run > cvsps against the cvs repo, what does its output look like around/past > patchset 6965 > > There's a number of things that can confuse cvsps, as the cvs repo > format is horrid. Hi, the cvsps output is attached to the bug report bugs.debian.org/cgi-bin/bugreport.cgi?bug=426617;msg=72;filename=%3Apserver%3Aanonymous%40zsh.cvs.sourceforge.net%3A%23cvsroot%23zsh%23zsh;att=1 Does this help to track down and hopefully fix the problem? Thanks, Gerrit.
Bug#947702: O: qmail-tools -- collection of tools for qmail
Package: wnpp
Bug#947705: O: ucspi-proxy -- Connection proxy for UCSPI tools
Package: wnpp
Bug#947700: O: netqmail --
Package: wnpp
Bug#947697: O: ezmlm-idx --
Package: wnpp
Bug#947701: O: qmail-run -- sets up qmail as mail-transfer-agent
Package: wnpp
Bug#947704: O: twoftpd -- a simple secure efficient FTP server
Package: wnpp
Bug#947703: O: tinydyndns -- pop-before-dyndns service using djbdns
Package: wnpp
Bug#947694: O: checkpw -- checks password which is stored in ~/Maildir/.password
Package: wnpp
Bug#947699: O: ipsvd -- Internet protocol service daemons
Package: wnpp
Bug#947698: O: freecdb -- creating and reading constant databases
Package: wnpp
Bug#947696: O: daemontools -- collection of tools for managing UNIX services
Package: wnpp
Bug#947695: O: cvm -- Credential Validation Modules
Package: wnpp
Bug#926306: RFS: socklog/2.1.0-9
On Thu, Apr 04, 2019 at 01:40:16PM +0200, Mathieu Mirmont wrote: > On Thu, Apr 04, 2019 at 12:48:43PM +0200, Adam Borowski wrote: > > A nice new process is described here: > >https://wiki.debian.org/PackageSalvaging > > but it's probably an overkill for a clear case like here. But, the old > > maintainer being the upstream means you need to at least communicate with > > him beforehand. > > I did reach out to Gerrit Pape (previous maintainer & upstream) of > course before doing anything. I offered to help and he was happy to hand > over the package to me. I'll file an ITS if you guys think I should. > > Adding Gerrit Pape to CC. Hi all, this is okay with me! I'm happy to hand over the package, sorry for not making this clear in advance. Best Regards, and have fun, Mathieu, with maintaining socklog.
Bug#907097: O: integrit -- A file integrity verification program
I don't use this package anymore, and so indeed no longer maintain it. It's orphaned. Regards, Gerrit.
Bug#922783: daemontools-run: installation in docker catches job control signal
On Fri, Feb 22, 2019 at 04:30:05PM +0100, Florian Lohoff wrote: > Hi, > i would propose a patch like this - Usage of telinit shameless stolen > from glibc which calls telinit like this to restart init. > > Otherwise we would need to check for the existance and executability > of telinit (Which might be missing in container environments) Hi Florian, thanks for the patch. When reading your report I toed recall the reason why I chose to signal pid 1 back then, but even after reading history I failed to find out why. It might be a good idea to look at similar packages that hook into sysv's inittab to see what they are doing. runit may be a candidate. Regards, Gerrit.
Bug#924058: runit: replace obsolete usleep with nanosleep in sv.c
On Sun, Mar 10, 2019 at 07:12:36PM +, Dmitry Bogatov wrote: > [2019-03-08 23:43] Jan > > >From f7b8f943d1f7a8f26df8d81eeb0a2d5a69ee7e22 Mon Sep 17 00:00:00 2001 > > From: Jan > > Date: Wed, 6 Mar 2019 18:38:04 +0100 > > Subject: [PATCH] fix: replace obsolete usleep with nanosleep > > > > POSIX.1-2001 declares usleep obsolete, > > POSIX.1-2008 removes the specification of usleep, > > see https://linux.die.net/man/3/usleep > > Looks good to me. Thank you. I will let this patch hang till release, > and will apply and upload after thaw. While change seems perfectly fine, > moving parts around freeze feels worriesome. > > Gerrit, as you can see, there is some activity around runit, in > particular about C code. I consider releasing runit-2.1.2 with > all patches, accumulated in Debian package as runit-2.1.3 for > convenience of other distributions (Void, Gentoo). Do you object? > Would you like to do it yourself? Hi Dmitry, I'm about to resume some activities on FOSS which includes a runit-2.1.3 upstream version eventually. Please put the patches you consider appropriate only into the Debian namespace 2.1.2-*. Thanks a lot for the energy you put into runit, it motivates to participate a bit again. And thanks to Jan for the patch. Happy hacking, Gerrit.
Bug#912884: daemontools-run: move /etc/service to /service please, etckeeper explodes
On Sun, Nov 04, 2018 at 06:09:34PM +, Thorsten Glaser wrote: > Package: daemontools-run > Version: 1:0.76-7 > Severity: important > > I was wondering why my /etc is 11 GiB in size. > > Turns out /etc/.git (from etckeeper) is 10 GiB, > because it covers /service/*/log/main/* from dæmontools. > > This is… unfortunate. Hi Thorsten, I'd love to move to /service, from the very beginning actually, but FHS and so Debian Policy does not allow. daemontools works fine with symlinks, so you could setup log directories in /var/log/ and link them into service directories, e.g. /etc/service/foo/log/main -> /var/log/foo/ Regards, Gerrit.
Bug#916230: Svlogd: log files named as `timestamp.u' even if there is no processor in place
Hi Dmitry,
I'm sorry, can't give you any input, I'm busy with different things
these days. But there're people around knowing the runit programs and
code, you can try to contact them through the mailing list
.
Best Regards, Gerrit.
On Mon, Dec 17, 2018 at 02:54:43PM +, Dmitry Bogatov wrote:
>
> [2018-12-12 19:39] Dmitry Bogatov
> > I managed to reproduce bug. Seems that .u file appears when svlogd is
> > restarted and there is some .s files, but not always. I plan to debug
> > it this weekend.
> >
> > Thank you for report. If you have some ideas, how to reproduce bug
> > more reliable, it would be great!
>
> Offending .u file is created by rename(2) call at line 532, in
> logdir_open() function. It happens, when 'current' file exists,
> non-executable and non-empty.
>
> Well, this is quite normal state of affairs. When `svlogd' is running,
> `current' file is getting appended, when its size reaches `ld->sizemax'
> (or something like this), it gets renames to @timestamp, and new
> `current' is created.
>
> So, if I interrupt `svlogd' at any time, but just after rotation, I
> will get this leftover .u file. I am not perfectly sure, but seems that
> `struct logdir` has `size' field, that means current size of log file.
>
> I believe following patch would solve current issue. But wouldn't
> it cause another problems? There must be reason, why this logic was
> implemented. Gerrit, some input, please?
>
> diff --git a/runit-2.1.2/src/svlogd.c b/runit-2.1.2/src/svlogd.c
> index fab8441..3f8ead4 100644
> --- a/runit-2.1.2/src/svlogd.c
> +++ b/runit-2.1.2/src/svlogd.c
> @@ -521,20 +521,7 @@ unsigned int logdir_open(struct logdir *ld, const char
> *fn) {
>
>/* open current */
>if ((i =stat("current", )) != -1) {
> -if (st.st_size && ! (st.st_mode & S_IXUSR)) {
> - ld->fnsave[25] ='.'; ld->fnsave[26] ='u'; ld->fnsave[27] =0;
> - do {
> -taia_now();
> -fmt_taia(ld->fnsave, );
> -errno =0;
> - } while ((stat(ld->fnsave, ) != -1) || (errno != error_noent));
> - while (rename("current", ld->fnsave) == -1)
> -pause2("unable to rename current", ld->name);
> - rmoldest(ld);
> - i =-1;
> -}
> -else
> - ld->size =st.st_size;
> +ld->size =st.st_size;
>}
>else
> if (errno != error_noent) {
Bug#907093: orphaning packages
On Fri, Aug 24, 2018 at 06:32:21PM +0800, Shengjing Zhu wrote: > On Fri, Aug 24, 2018 at 5:45 PM Gerrit Pape wrote: > > On Thu, Aug 23, 2018 at 10:27:12PM +0200, Tobias Frost wrote: > > > The current maintainer of [packages], Gerrit Pape , > > > is apparently not active anymore. Therefore, I orphan this package now. > > > > Indeed, I'm not active since quite some time, but still around, with > > some motivation to get back to work eventually. We've been discussing > > this lately. It appears that I stressed your patience. > > Since I already send ITA to 907093(skalibs), I want to let you I'll > not hijack it if you're still around. > > But AFAIK, the current version of skalibs has no Build-Depends/Depends > in Debian archive, and is far behind upstream release. As I want to > package s6, I'll need the latest version of skalibs. So I hope I can > co-maintain this with you. Hi Zhu, thanks for following up. I'm happy with you taking over skalibs, and am also happy to see someone packaging s6, it's great software me thinks. So, go ahead and adopt skalibs as new maintainer. Best Regards, Gerrit.
Bug#907087: orphaning packages
On Thu, Aug 23, 2018 at 10:27:12PM +0200, Tobias Frost wrote: > The current maintainer of [packages], Gerrit Pape , > is apparently not active anymore. Therefore, I orphan this package now. Indeed, I'm not active since quite some time, but still around, with some motivation to get back to work eventually. We've been discussing this lately. It appears that I stressed your patience. Best Regards, Gerrit. signature.asc Description: Digital signature
Bug#777020: ucspi-tcp: please make the build reproducible
On Sun, Mar 05, 2017 at 09:29:21AM +, Chris Lamb wrote: > > Would you consider applying this patch and uploading? > > Friendly ping on this :) Hi, concerning all my "please make the build reproducible" bugs, I'm sorry that I'm currently quite inactive and not prepared to do uploads. NMUs welcome. Best Regards, Gerrit.
Bug#777288: bcron: please make the build reproducible
On Sun, Feb 05, 2017 at 10:00:51AM +1300, Chris Lamb wrote: > > Would you consider applying this patch and uploading? > > Friendly ping on this :) Hi, unfortunately I'm quite busy and currently not very active within Debian. NMU welcome! Best Regards, Gerrit.
Bug#838481: closed by "Dr. Tobias Quathamer" <to...@debian.org> (NMU of daemontools)
Thank you!
Regards, Gerrit.
On Sun, Nov 27, 2016 at 12:09:03AM +, Debian Bug Tracking System wrote:
> This is an automatic notification regarding your Bug report
> which was filed against the sponsorship-requests package:
>
> #838481: RFS: daemontools/0.76-7 [RC]
>
> It has been closed by "Dr. Tobias Quathamer" <to...@debian.org>.
>
> Their explanation is attached below along with your original report.
> If this explanation is unsatisfactory and you have not received a
> better one in a separate message then please contact "Dr. Tobias Quathamer"
> <to...@debian.org> by
> replying to this email.
>
>
> --
> 838481: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=838481
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems
> Date: Sun, 27 Nov 2016 01:06:39 +0100
> From: "Dr. Tobias Quathamer" <to...@debian.org>
> To: 838481-d...@bugs.debian.org
> Subject: NMU of daemontools
>
> Hi,
>
> the previous NMU did not seem to get to unstable, so I've uploaded
> it again. Please find attached the updated patch for the NMU.
>
> If you'd like to have a new version with yourself as maintainer
> sponsored into Debian, feel free to contact me.
>
> Regards,
> Tobias
> diff -u daemontools-0.76/debian/changelog daemontools-0.76/debian/changelog
> --- daemontools-0.76/debian/changelog
> +++ daemontools-0.76/debian/changelog
> @@ -1,3 +1,23 @@
> +daemontools (1:0.76-6.1) unstable; urgency=medium
> +
> + [ Jan Mojzis ]
> + * Non-maintainer upload.
> + * supervise.c: restart the monitored process when
> +fork(2) fails (Closes: #819036)
> + * d/rules: fix mtimes before building binary package to produce
> +reproducible output (Closes: #793003) (Closes: #776876)
> + * d/rules: do not FTBFS with dpkg-buildpackage -A (thx Santiago
> +Vila) (Closes: #831921)
> + * d/implicit: fixed md5sums permissions 0664 -> 0644
> + * d/control: bump to standards-version 3.9.8
> + * d/control: fixed the description
> +
> + [ Dr. Tobias Quathamer ]
> + * New upload with all changes from Jan, his previous NMU
> +to DELAYED/5 did not end up in unstable.
> +
> + -- Dr. Tobias Quathamer <to...@debian.org> Sun, 27 Nov 2016 00:26:56 +0100
> +
> daemontools (1:0.76-6) unstable; urgency=medium
>
>* workaround #767933 by copying from sysvinit-2.88dsf:
> @@ -242 +261,0 @@
> -
> diff -u daemontools-0.76/debian/control daemontools-0.76/debian/control
> --- daemontools-0.76/debian/control
> +++ daemontools-0.76/debian/control
> @@ -2,7 +2,7 @@
> Section: admin
> Priority: optional
> Maintainer: Gerrit Pape <p...@smarden.org>
> -Standards-Version: 3.9.5.0
> +Standards-Version: 3.9.8
>
> Package: daemontools
> Architecture: any
> @@ -10,7 +10,7 @@
> Suggests: daemontools-run | runit
> Depends: ${shlibs:Depends}
> Replaces: daemontools-doc
> -Description: a collection of tools for managing UNIX services
> +Description: collection of tools for managing UNIX services
> supervise monitors a service. It starts the service and restarts the
> service if it dies. Setting up a new service is easy: all supervise
> needs is a directory with a run script that runs the service.
> diff -u daemontools-0.76/debian/implicit daemontools-0.76/debian/implicit
> --- daemontools-0.76/debian/implicit
> +++ daemontools-0.76/debian/implicit
> @@ -35,7 +35,7 @@
> debian/$*/usr/share/doc/$*/changelog'
> @test -s debian/$*/usr/share/doc/$*/changelog || \
> sh -cx 'rm -f debian/$*/usr/share/doc/$*/changelog'
> - @gzip -9 debian/$*/usr/share/doc/$*/changelog*
> + @gzip -9n debian/$*/usr/share/doc/$*/changelog*
> %.deb-docs-docs: %.deb-docs-base
> @for i in `cat debian/$*.docs 2>/dev/null || :`; do \
> if test -d $$i; then \
> @@ -54,7 +54,7 @@
> @if test -r debian/$*.NEWS.Debian; then \
> sh -cx 'install -m0644 debian/$*.NEWS.Debian \
> debian/$*/usr/share/doc/$*/NEWS.Debian && \
> - gzip -9 debian/$*/usr/share/doc/$*/NEWS.Debian'; \
> + gzip -9n debian/$*/usr/share/doc/$*/NEWS.Debian'; \
> fi
> %.deb-docs-examples: %.deb-docs-docs
> @rm -rf debian/$*/usr/share/doc/$*/examples
> @@ -88,6 +88,7 @@
> @rm -f debian/$*/DEBIAN/md5sums
> @cd debian/$* && find * -path 'DEBIAN' -prune -o \
> -type f -exec md5sum {} >>DEBIAN/md5sums \;
> + @chmod 644 debian/$*/DEBIAN/md5sums
> %.deb-DEBIAN: %.deb-checkdir %.deb-DEBIAN-base %.deb-DEBIAN-scripts \
> %.deb-DEBIAN-md5sums
> : debian/$*/DEBIAN/ ok
> diff -u daemontools-0.76/debian/rules daemontools-0.76/deb
Bug#838482: RFS: netqmail/1.06-6 [RC]
Package: sponsorship-requests
Severity: important
Dear mentors,
I am looking for a sponsor for my package "netqmail":
* Package name: netqmail
Version : 1.06-6
Section : mail
It builds those binary packages:
qmail - a secure, reliable, efficient, simple message transfer agent
qmail-uids-gids - user ids and group ids for qmail
Download the package with dget using this command:
dget -x http://smarden.org/kaGh6ut/netqmail_1.06-6.dsc
Changes since the last upload:
* debian/rules: do not FTBFS with dpkg-buildpackage -A (thx Santiago
Vila; closes: #831963).
The process to get my new gpg key into the debian keyring is stuck for
some reason, although signatures are available, hence the RFS.
$ debdiff netqmail_1.06-5.dsc netqmail_1.06-6.dsc
diff -u netqmail-1.06/debian/changelog netqmail-1.06/debian/changelog
--- netqmail-1.06/debian/changelog
+++ netqmail-1.06/debian/changelog
@@ -1,3 +1,10 @@
+netqmail (1.06-6) unstable; urgency=low
+
+ * debian/rules: do not FTBFS with dpkg-buildpackage -A (thx Santiago
+Vila; closes: #831963).
+
+ -- Gerrit Pape <p...@smarden.org> Wed, 21 Sep 2016 08:58:41 +
+
netqmail (1.06-5) unstable; urgency=low
* debian/qmail.postrm: do not forcefully remove files in /etc/qmail/
diff -u netqmail-1.06/debian/rules netqmail-1.06/debian/rules
--- netqmail-1.06/debian/rules
+++ netqmail-1.06/debian/rules
@@ -14,6 +14,8 @@
done
touch patch-stamp
+build-arch: build
+build-indep: build
build: deb-checkdir build-stamp
build-stamp: patch-stamp
test -r conf-qmail'{orig}' || cp conf-qmail conf-qmail'{orig}'
@@ -110,5 +112,5 @@
dpkg -b '$(DIR)'-uids-gids ..
-.PHONY: patch build clean install binary-indep binary-arch binary
+.PHONY: patch build build-arch build-indep clean install binary-indep
binary-arch binary
include debian/implicit
Regards, Gerrit.
signature.asc
Description: Digital signature
Bug#838481: RFS: daemontools/0.76-7 [RC]
Package: sponsorship-requests Severity: important Dear mentors, I am looking for a sponsor for my package "daemontools": * Package name: daemontools Version : 0.76-7 Section : admin It builds those binary packages: daemontools - a collection of tools for managing UNIX services daemontools-run - daemontools service supervision Download the package with dget using this command: dget -x http://smarden.org/kaGh6ut/daemontools_0.76-7.dsc Changes since the last upload: * debian/rules: do not FTBFS with dpkg-buildpackage -A (thx Santiago Vila; closes: #831921). The process to get my new gpg key into the debian keyring is stuck for some reason, although signatures are available, hence the RFS. $ debdiff daemontools_0.76-6.dsc daemontools_0.76-7.dsc diff -u daemontools-0.76/debian/changelog daemontools-0.76/debian/changelog --- daemontools-0.76/debian/changelog +++ daemontools-0.76/debian/changelog @@ -1,3 +1,10 @@ +daemontools (1:0.76-7) unstable; urgency=low + + * debian/rules: do not FTBFS with dpkg-buildpackage -A (thx Santiago +Vila; closes: #831921). + + -- Gerrit Pape <p...@smarden.org> Wed, 21 Sep 2016 08:57:18 + + daemontools (1:0.76-6) unstable; urgency=medium * workaround #767933 by copying from sysvinit-2.88dsf: diff -u daemontools-0.76/debian/rules daemontools-0.76/debian/rules --- daemontools-0.76/debian/rules +++ daemontools-0.76/debian/rules @@ -14,6 +14,8 @@ done touch patch-stamp +build-arch: build +build-indep: build build: deb-checkdir build-stamp build-stamp: patch-stamp cd daemontools-0.76 && package/compile @@ -101,7 +103,7 @@ binary: binary-indep binary-arch -.PHONY: patch build clean install install-arch install-indep binary \ +.PHONY: patch build build-arch build-indep clean install install-arch install-indep binary \ binary-arch binary-indep include debian/implicit $ Regards, Gerrit. signature.asc Description: Digital signature
Bug#776760: dot-forward: please make the build reproducible
On Fri, Sep 16, 2016 at 09:50:57AM +0100, Chris Lamb wrote: > Dear Maintainer, > > > Source: dot-forward > > Version: 1:0.71-2 > > Tags: patch > > There hasn't seem to be any update on this bug in 32 days, in which > time the Reproducible Builds effort has come on a long way. :) > > Would you consider applying this patch and uploading? Hi, I'm quite inactive these days, and still don't have my new gpg key in the Debian keyring. I'd very appreciate a NMU. Regards, Gerrit.
Bug#831918:
On Thu, Aug 04, 2016 at 03:17:47PM +0200, Santiago Vila wrote: > owner 831918 sanv...@debian.org > thanks > > I plan to make a QA upload to fix this. Thank you!
Bug#784276: rotated log files are set executable
On Mon, Feb 08, 2016 at 06:12:27AM +, Jamie Heilman wrote: > chrysn wrote: > > please disable that behavior, make it optional and/or document why it is > > required. > > This is all based off daemontools' multilog ... > > https://cr.yp.to/daemontools/multilog.html > > ... which states: > > While multilog is running, current has mode 644. If multilog sees > the end of stdin, it writes current safely to disk, and sets the > mode of current to 744. When it restarts, it sets the mode of > current back to 644 and continues writing new lines. > > When multilog decides that current is big enough, it writes current > safely to disk, sets the mode of current to 744, and renames current > as an old log file. > > Thus it's effectively using the mode bits as flag to communicate the > state of the application, which while unusual, is harmless. Yes, and it's also documented in the svlogd(8) man page shipped with runit: [...] LOG FILE ROTATION svlogd appends selected log messages to the current log file. If current has size bytes or more (or there is a new-line within the last len of size bytes), or is older than a specified amount of time, current is rotated: svlogd closes current, changes permission of current to 0755, renames current to @timestamp.s, and starts with a new empty cur‐ rent. If svlogd sees num or more old log files in the log direc‐ [...] Please don't change this behavior. Regards, Gerrit.
Bug#832510: skalibs: FTBFS when built with dpkg-buildpackage -A (Missing build-indep target)
Hi Santiago, thanks a lot for your activities in this area and the bug reports you filed. Unfortunately I'm quite inactive currently in Debian, actually for many months already. Is it possible for you to NMU the packages with the "FTBFS when built with dpkg-buildpackage -A" bugs where I'm the current maintainer? Regards, Gerrit. On Tue, Jul 26, 2016 at 09:34:18AM +, Santiago Vila wrote: > Package: src:skalibs > Version: 0.47-1 > Severity: serious > Tags: patch > > Dear maintainer: > > I tried to build this package with "dpkg-buildpackage -A" > (i.e. only architecture-independent packages), and it failed: > > > [...] > debian/rules build-indep > make: *** No rule to make target 'build-indep'. Stop. > dpkg-buildpackage: error: debian/rules build-indep gave error exit status 2 > > > The build-arch and build-indep targets are mandatory. > > Previously, dpkg had a hack to make this work, but the hack has been recently > removed and this is now considered a serious bug. > > Fortunately, this is easy to fix. The following patch should suffice. > > Thanks. > > --- a/debian/rules > +++ b/debian/rules > @@ -30,6 +30,8 @@ configure-stamp: > echo 'diet -v -Os gcc' >diet/skalibs/conf-compile/conf-ld > touch configure-stamp > > +build-arch: build > +build-indep: build > build: deb-checkdir build-stamp > build-stamp: configure-stamp > (cd skalibs && package/compile) > @@ -89,7 +91,7 @@ binary-arch: install-arch skalibs-dev.deb > > binary: binary-indep binary-arch > > -.PHONY: configure build clean install-indep install-arch install > binary-indep \ > +.PHONY: configure build build-arch build-indep clean install-indep > install-arch install binary-indep \ > binary-arch binary > > include debian/implicit
Bug#829666: dash: diff for NMU version 0.5.8-2.3
On Tue, Jul 05, 2016 at 10:01:43PM +, Mattia Rizzolo wrote: > I've prepared an NMU for dash (versioned as 0.5.8-2.3) and > uploaded it to DELAYED/2. Please feel free to tell me if I > should delay it longer. Just fine. Thank you! Regards, Gerrit.
Bug#827090: RFS: runit/2.1.2-4 ITP
Hi Dmitry, it appears that it's time for me to let the runit package go, so, hereby my acknowledgement to you to adopt the Debian runit package as new maintainer. I'm positively surprised that after all these years somebody still is motivated to bring runit integration into Debian forward. It would be wrong to stop that, although I personally prefer to simply have my working runit package on my Debian systems, and not change the running systems. Good luck, have fun, and please keep runit in Debian in good shape! Best Regards, Gerrit On Sun, Jun 19, 2016 at 07:02:06PM +0300, Dmitry Bogatov wrote: > > > I've been there, done that. Many years ago, if interested search > > history for the runit-init package. Today I don't think runit is the > > right choice for integrating as init system into Debian. > > Would you be so kind to be more verbose/provide link? What is wrong for > runit provide init? > > > Take a look at s6, nosh, or perp maybe? > > I saw them. Not impressed. There is some features from s6 worth > adopting, but I still prefer runit. > > -- > Accept: text/plain, text/x-diff > Accept-Language: eo,en,ru > X-Keep-In-CC: yes > X-Web-Site: sinsekvu.github.io
Bug#827090: RFS: runit/2.1.2-4 ITP
On Fri, Jun 17, 2016 at 12:36:23AM +0300, Dmitry Bogatov wrote: > > > On Mon, Jun 13, 2016 at 10:18:04PM +0300, Dmitry Bogatov wrote: > > > > + * New maintainer > > > > did Gerrit asked for help? > > > > stepping in as maintainer needs an RFH or Orphan package. > > > > (well, Gerrit was fine on giving up some packages IIRC) > > > > > > Gerrit gave up fgetty (which I picked up), so I think he will be okay > > > with this. But explicit is better then implicit. > > > > Hi Gianfranco, Dmitry, > > > > actually I'm not okay with anyone taking over the runit packge. And I > > don't see why runit needs an update in Debian. The few bugs are known > > and can be worked around if necessary. > > Well, in current state, runit is not init system and using it is > rather complicated -- sysadmin have to manually copy files from > /usr/share/doc/ into /etc. It writes files under /etc, which may be > read-only. Using it under sysv control means that getty is not runit > service. It provides only tty5 runscript. > > My changes addresses all of above to provide something, that would > work out-of-box. Would you be interested in taking them? I've been there, done that. Many years ago, if interested search history for the runit-init package. Today I don't think runit is the right choice for integrating as init system into Debian. Take a look at s6, nosh, or perp maybe? Although I thank you for your efforts and interest in runit, I'm happy with the runit package in Debian as is. Regards, Gerrit
Bug#827090: RFS: runit/2.1.2-4 ITP
On Mon, Jun 13, 2016 at 10:18:04PM +0300, Dmitry Bogatov wrote: > > + * New maintainer > > did Gerrit asked for help? > > stepping in as maintainer needs an RFH or Orphan package. > > (well, Gerrit was fine on giving up some packages IIRC) > > Gerrit gave up fgetty (which I picked up), so I think he will be okay > with this. But explicit is better then implicit. Hi Gianfranco, Dmitry, actually I'm not okay with anyone taking over the runit packge. And I don't see why runit needs an update in Debian. The few bugs are known and can be worked around if necessary. Best Regards, Gerrit
Bug#816363: RFS: fgetty/0.7-0.1 [NMU] -- very small, efficient, console-only getty
On Wed, Mar 02, 2016 at 01:49:33PM +, Mattia Rizzolo wrote: > On Tue, Mar 01, 2016 at 07:02:59PM +0300, Dmitry Bogatov wrote: > > Before starting to work I tried to contact him. No reply since 8th > > Feb. Would it be polite to take maintainership? > > maybe pape is willing to either orphan or anyway givign up on the > maintainship. Hi, sorry for not replying earlier. I'm fine with you taking over the package, please give it a good new home! Best Regards, Gerrit.
Bug#790125: RFS: dropbear/2015.67-1.1 NMU
Hi all, sorry for the late reply.
On Thu, Aug 20, 2015 at 07:23:55AM +, Gianfranco Costamagna wrote:
> Hi Gerrit,
>
> >Alright, would it help moving forward if I were doing that? Reverting
>
> >to 2014.65 is easy, and the current 2015.68-1 could always be uploaded
> >once 2014.65-1 has entered testing. It'd be quite sad to upload known
> >bugs in a package containing multiple lintian warnings and errors [0],
> >but if someone is willing to review and upload the package, but only
> >with the split of dropbear-{bin,run,initramfs} and without the many
> >extra bug fixes, then I'm ready to clean, test and release [1].
>
>
> I didn't follow the thread, and seems that other DDs are already caring of
> this one, so I would just put my .02$ (and let me know if you need a review
> or help).
>
> Just a few questions:
> 1) Gerrit, you offered to add the package, but Guilhem might need to
> comaintain it,
> is that fine for you?
>
> Seems impossible to nmu it because of a binary package he starts to maintain.
>
> 2) what about updating to the latest version and upload on experimental?
>
> I don't see all this need to go for unstable, I might even sponsor an
> experimental upload
> because if Gerrit is not satisfied he can continue and upload his version to
> unstable,
> and experimental will disappear automagically.
>
> Isn't this one the experimental suite pourpose?
> We are still in the Stretch early stage, we might delay unstable until other
> folks tested it.
I'm currently not active, so I'm very happy with Guilhem bringing this
forward. I'm not particularly happy with the switch to debhelper, but
do not veto if it's necessary to progress.
Comaintenance is fine too. I not yet know Guilhem and his work for
Debian, but this won't change too soon, because my time to spend on
Debian is currently quite limited.
I hope Guilhem finds a sponsor soon.
Regards, Gerrit.
Bug#796118: Should djbdns be removed?
reassign 796118 djbdns retitle 796118 Should djbdns be removed? quit On Tue, Sep 08, 2015 at 08:29:18PM +0200, Moritz Mühlenhoff wrote: > On Wed, Aug 19, 2015 at 05:45:30PM +0200, Moritz Muehlenhoff wrote: > > djbdns is RC-buggy for many years now and was out of testing since 2009. > > Should we remove it from unstable? No, I don't think so.
Bug#650426: cvm: Should build-depend on libmysqlclient-dev
On Mon, Jun 29, 2015 at 12:44:00PM -0400, Martin Michlmayr wrote: severity 650426 serious thanks * Clint Byrum cl...@ubuntu.com [2011-11-29 09:39]: In Ubuntu, the attached patch was applied to achieve the following: * d/control: change to using just plain libmysqlclient-dev to pick up latest libmysqlclient on rebuild. mysql-ocaml fails to build in unstable now because libmysqlclient15-dev is no longer provided by mysql 5.6. Please apply Clint's patch. Hi, I won't get to this soon, please NMU. Thanks, Gerrit. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#775052: qmail-run: postinst uses /usr/share/doc content (Policy 12.3): /usr/share/doc/qmail-run/examples/aliases
On Fri, Feb 20, 2015 at 11:56:59AM +0100, Andreas Beckmann wrote: Hi Gerrit, attached is a patch that moves the default aliases out of /usr/share/doc. I verified that this fixes the serious problems discovered by piuparts. There are more issues still (leaving around created files, package should be converted to debhelper for easier maintenance, ...) but these should be addressed after jessie was released. I plan to do an undelayed NMU over the weekend, but of course you are welcome to beat me to it :-) Hi Andreas, thanks, the patch looks good. I won't beat you, so I'm very happy with you uploading the NMU. I set severity from serious to important on this issue, because the package was scheduled for removal from testing. Now when we have a fix, it should be set back to serious IMO. Regards, Gerrit. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#775052: qmail-run: postinst uses /usr/share/doc content (Policy 12.3): /usr/share/doc/qmail-run/examples/aliases
severity 775052 important quit Hi, currently I cannot work on an upload. NMU welcome. In the meanwhile, change severity to important to prevent autoremoval from testing. Regards, Gerrit. On Sat, Jan 10, 2015 at 08:46:10PM +0100, Andreas Beckmann wrote: Package: qmail-run Version: 2.0.2 Severity: serious Tags: wheezy-ignore User: debian...@lists.debian.org Usertags: piuparts Hi, a test with piuparts revealed that your package uses files from /usr/share/doc in its maintainer scripts which is a violation of Policy 12.3: Packages must not require the existence of any files in /usr/share/doc/ in order to function. https://www.debian.org/doc/debian-policy/ch-docs.html#s12.3 These files must be moved to /usr/share/$PACKAGE and may be symlinked from /usr/share/doc/$PACKAGE. This piuparts test prevents the installation of (most) files into /usr/share/doc with 'dpkg --path-exclude=...'. From the attached log (scroll to the bottom...): Selecting previously unselected package qmail-run. (Reading database ... 7981 files and directories currently installed.) Preparing to unpack .../qmail-run_2.0.2_all.deb ... Unpacking qmail-run (2.0.2) ... Setting up qmail-run (2.0.2) ... creating default /etc/aliases... cp: cannot stat '/usr/share/doc/qmail-run/examples/aliases': No such file or directory dpkg: error processing package qmail-run (--configure): subprocess installed post-installation script returned error exit status 1 Errors were encountered while processing: qmail-run Cheers, Andreas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#773770: git-daemon-run: Depend on runit which fails to install due to missing inittab
On Mon, Dec 22, 2014 at 07:18:47PM -0800, Jonathan Nieder wrote: Daniel Dickinson wrote: This packages depend on runit which depends on the existence of inittab which is not longer true with systemd. That sounds like a runit bug. Do you have a change in git-daemon-run in mind that would help? Hi, I'll upload a workaround to fix the bug in the runit package soon. Regards, Gerrit. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#766187: The inittab interface - Re: Bug#766187: runit: Fails to install runit after fresh install of jessie beta2
On Tue, Dec 09, 2014 at 11:24:11AM +, Gerrit Pape wrote: 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. Hi init and sysvinit maintainers, it looks like I don't get reasonable advise on debian-devel. What is your stand on this? Regards, Gerrit. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#766187: 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 +, 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-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#576503: 'man dash' typo: the shell .... proceed onto
Hi Stéphane, thanks for these bug resolutions. Good work! Regards, Gerrit. On Mon, Nov 17, 2014 at 10:41:29AM +0100, Stéphane Aulery wrote: tags 576503 + fixed-upstream stop See commit 69a966c574ea51a80bacbd0be465ee68906d4faf 2014-11-17 05:04:17 (GMT) Just after release v0.5.8 https://git.kernel.org/cgit/utils/dash/dash.git/commit/?id=69a966c574ea51a80bacbd0be465ee68906d4faf -- Stéphane Aulery -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#767933: daemontools-run: fails to install without /etc/inittab
tags 767933 - patch quit On Thu, Nov 13, 2014 at 12:20:01AM +0100, Simon Elsbrock wrote: the patch below fixes the build failure by checking for existence of /etc/inittab before grepping. Hi Simon, thanks for the patch, but that's not the solution, it has other problems which are not as obvious as an installation failure, see https://lists.debian.org/debian-devel/2014/10/msg00613.html Regards, Gerrit. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#768315: unblock: util-linux/2.25.2-3
On Thu, Nov 06, 2014 at 02:13:01PM +0100, Andreas Henriksson wrote: Explanation of changes: Martin Pitt reported fstrim taking a long time on his system and in combination with init-system-helpers (dh_systemd) starting the fstrim /service/ in postinst this will make the package upgrade take a long time. An improvement to dh_systemd_start has been suggested in #767429. Apart from that, others have expressed that we're apparently not yet mentally ready for shipping systemd units in Debian. Lets just ship the unit files as examples for now and let people continue to trim their SSDs manually (or manually set up their preferred method of having it done regularly for them). Hi, installing the unit files, which AFAICS entered jessie quite recently, also introduced a dependency on init-system-helpers and in turn on perl, making perl pseudo-essential (#757891). Can we revert this too? Regards, Gerrit. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#758231: this is actively harmful
On Thu, Oct 23, 2014 at 02:22:45AM +0200, Michael Biebl wrote: It's unfortunate that Gerrit objected to this proposed change and derailed the discussion. Well, there's two sides of the medal. Actually I felt that you (plural) derailed discussion, even before I had chance to start it. That's unfortunate https://lists.debian.org/debian-policy/2014/08/msg00037.html Regards, Gerrit. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#758231: closed by Michael Biebl em...@michaelbiebl.de (Re: Bug#758231: this is actively harmful)
On Sun, Oct 26, 2014 at 09:15:21PM +, Debian Bug Tracking System wrote: From: Michael Biebl em...@michaelbiebl.de Am 23.10.2014 um 01:56 schrieb Adam Borowski: For now, let's not change packages back and forth. Let's close this non-issue in rsyslog, it's a problem with the policy. Agreed. Well, obviously I do not agree. And from policy discussions I also don't read that there's agreement that it's a problem with the policy. I'm prepared to accept, if I fail to make my personal and professional interest and opinion clear enough or don't have any supporters on it, and you manage to get the policy change through. But we're not there yet. For the records, this bug can be closed because priorities have been adjusted accordingly, making things more transparent, and now rsyslogd no longer depends on packages with priority extra. Regards, Gerrit. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#766187: usertag piuparts for runit fails to install
On Mon, Oct 27, 2014 at 09:35:07PM +0100, Holger Levsen wrote: user debian...@lists.debian.org usertag 766187 + piuparts affects 766187 git-daemon-run thanks I can see this bug on piuparts.d.o too, eg at https://piuparts.debian.org/jessie/fail/git-daemon-run_1:2.1.1-1.log or rather obviously at https://piuparts.debian.org/sid/source/r/runit.html too. Thanks. Can you say whether this might affect even more packages? daemontools-run comes to mind. But if maintainers that utilized inittab added a fallback for a non-existing inittab, as also was requested for the runit package (#453106), the error cannot be found through piuparts I guess. Do you know a way to find out which packages of the whole archive adjust inittab through the maintainers script, can piuparts do that? Regards, Gerrit. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#766187: 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-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#766187: 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-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#766090: 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 +, 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-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#766048: dash 0.5.8-1 (experimental): build failures with several packages
Package: dash Version: 0.5.8-1 Severity: grave A rebuild of the archive with dash version 0.5.8-1 from experimental shows several build failures. Thanks to David Suárez for his support, see here for the rebuild results: http://aws-logs.debian.net/ftbfs-logs/dash/ Regards, Gerrit. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#766090: ITP: runit-init -- a UNIX init scheme with service supervision
Package: wnpp Severity: wishlist 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-run.git/ Regards, Gerrit. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#766090: ITP: runit-init -- a UNIX init scheme with service supervision
On Mon, Oct 20, 2014 at 07:54:20PM +, Gerrit Pape wrote: You can take a look at the current status through git clone http://smarden.org/git/runit-run.git/ Actually, git clone http://smarden.org/git/runit-init.git/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#759260: [PATCH v2] Remove priority extra, make all corresponding packages priority optional
Hi, further discussion on this topic drifted away to broader or other topics, as I read it. There were followups in favor of this change, and also an objection early in the discussion. I still think applying this change to the policy brings us forward in making the process how dependencies across priorities are handled much more transparent and so more easy to control. And I'd like to either see it accepted, or want to close the issue again. So I hereby ask for seconds to support this patch, or for your objection with reasoning. Regards, Gerrit. On Mon, Aug 25, 2014 at 03:43:02PM +, Gerrit Pape wrote: All packages that currently are of priority extra shall be changed to priority optional for the reasons outlined in message #35 to this report https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=758234#35 If technically feasible, and I think so, the transition shall be done through ftpmaster's override file, which will cause lintian warnings for affected packages so that the maintainers can adapt the packages' control files gradually. --- On Sat, Aug 23, 2014 at 09:59:09PM +0100, Simon McVittie wrote: On 23/08/14 17:54, Gerrit Pape wrote: --- a/policy.sgml +++ b/policy.sgml @@ -855,15 +855,6 @@ zope. distribution, and many applications. Note that optional packages should not conflict with each other. That last sentence is not feasible if the 'extra' priority is abolished, and should also be deleted by the patch. Yes, obviously, thanks for spotting this. Here's v2 of the patch with this sentence removed too. There might also be other mentions of 'extra' vs. the other priorities (packages in extra may conflict with other packages in the same suite, but higher priorities are expected to be fully installable) elsewhere in Policy, which should also be amended. I thoroughly searched policy.sgml for extra, optional, priorities, priority (ignore-case), and only found the example included in the patch. If further discussion doesn't happen or doesn't suggest otherwise, I still plan to call for seconds in about a week. Regards, Gerrit. policy.sgml | 20 +--- 1 file changed, 5 insertions(+), 15 deletions(-) diff --git a/policy.sgml b/policy.sgml index 6eac491..628a5c9 100644 --- a/policy.sgml +++ b/policy.sgml @@ -852,17 +852,7 @@ zope. install if you didn't know what it was and don't have specialized requirements. This is a much larger system and includes the X Window System, a full TeX - distribution, and many applications. Note that - optional packages should not conflict with each other. - /item - tagttextra/tt/tag - item - This contains all packages that conflict with others - with required, important, standard or optional - priorities, or are only likely to be useful if you - already know what they are or have specialized - requirements (such as packages containing only detached - debugging symbols). + distribution, and many applications. /item /taglist /p @@ -3660,10 +3650,10 @@ Files: size, section and priority and the filename. For example: example Files: - 4c31ab7bfc40d3cf49d7811987390357 1428 text extra example_1.2-1.dsc - c6f698f19f2a2aa07dbb9bbda90a2754 571925 text extra example_1.2.orig.tar.gz - 938512f08422f3509ff36f125f5873ba 6220 text extra example_1.2-1.diff.gz - 7c98fe853b3bbb47a00e5cd129b6cb56 703542 text extra example_1.2-1_i386.deb + 4c31ab7bfc40d3cf49d7811987390357 1428 text optional example_1.2-1.dsc + c6f698f19f2a2aa07dbb9bbda90a2754 571925 text optional example_1.2.orig.tar.gz + 938512f08422f3509ff36f125f5873ba 6220 text optional example_1.2-1.diff.gz + 7c98fe853b3bbb47a00e5cd129b6cb56 703542 text optional example_1.2-1_i386.deb /example The qref id=f-Sectionsection/qref and qref id=f-Prioritypriority/qref are the values of -- 2.1.0 -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140825154302.12284.qm...@86ac9ff3f66a19.315fe32.mid.smarden.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#759265: override: perl:perl/important perl-modules:perl/important (and some others)
On Mon, Aug 25, 2014 at 07:25:04PM +0200, Ansgar Burchardt wrote: Please consider raising perl's priority to important (and the same for the packages it depends on). I'll followup with the full list later as I had it only in emacs's scratch buffer a few days ago... Note that this increases the size Priority: important quite a bit, but Hi, there're other solutions discussed to solve this priority conflict that don't increase the size (or far less) of the set of priority important packages, which should be taken into account before adding this override https://bugs.debian.org/757891 https://bugs.debian.org/757905 I personally prefer the very first one (#757891). Regards, Gerrit. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#758234: [PATCH v2] Remove priority extra, make all corresponding packages priority optional
All packages that currently are of priority extra shall be changed to priority optional for the reasons outlined in message #35 to this report https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=758234#35 If technically feasible, and I think so, the transition shall be done through ftpmaster's override file, which will cause lintian warnings for affected packages so that the maintainers can adapt the packages' control files gradually. --- On Sat, Aug 23, 2014 at 09:59:09PM +0100, Simon McVittie wrote: On 23/08/14 17:54, Gerrit Pape wrote: --- a/policy.sgml +++ b/policy.sgml @@ -855,15 +855,6 @@ zope. distribution, and many applications. Note that optional packages should not conflict with each other. That last sentence is not feasible if the 'extra' priority is abolished, and should also be deleted by the patch. Yes, obviously, thanks for spotting this. Here's v2 of the patch with this sentence removed too. There might also be other mentions of 'extra' vs. the other priorities (packages in extra may conflict with other packages in the same suite, but higher priorities are expected to be fully installable) elsewhere in Policy, which should also be amended. I thoroughly searched policy.sgml for extra, optional, priorities, priority (ignore-case), and only found the example included in the patch. If further discussion doesn't happen or doesn't suggest otherwise, I still plan to call for seconds in about a week. Regards, Gerrit. policy.sgml | 20 +--- 1 file changed, 5 insertions(+), 15 deletions(-) diff --git a/policy.sgml b/policy.sgml index 6eac491..628a5c9 100644 --- a/policy.sgml +++ b/policy.sgml @@ -852,17 +852,7 @@ zope. install if you didn't know what it was and don't have specialized requirements. This is a much larger system and includes the X Window System, a full TeX - distribution, and many applications. Note that - optional packages should not conflict with each other. - /item - tagttextra/tt/tag - item - This contains all packages that conflict with others - with required, important, standard or optional - priorities, or are only likely to be useful if you - already know what they are or have specialized - requirements (such as packages containing only detached - debugging symbols). + distribution, and many applications. /item /taglist /p @@ -3660,10 +3650,10 @@ Files: size, section and priority and the filename. For example: example Files: - 4c31ab7bfc40d3cf49d7811987390357 1428 text extra example_1.2-1.dsc - c6f698f19f2a2aa07dbb9bbda90a2754 571925 text extra example_1.2.orig.tar.gz - 938512f08422f3509ff36f125f5873ba 6220 text extra example_1.2-1.diff.gz - 7c98fe853b3bbb47a00e5cd129b6cb56 703542 text extra example_1.2-1_i386.deb + 4c31ab7bfc40d3cf49d7811987390357 1428 text optional example_1.2-1.dsc + c6f698f19f2a2aa07dbb9bbda90a2754 571925 text optional example_1.2.orig.tar.gz + 938512f08422f3509ff36f125f5873ba 6220 text optional example_1.2-1.diff.gz + 7c98fe853b3bbb47a00e5cd129b6cb56 703542 text optional example_1.2-1_i386.deb /example The qref id=f-Sectionsection/qref and qref id=f-Prioritypriority/qref are the values of -- 2.1.0 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#758234: debian-policy: allow packages to depend on packages of lower priority
On Sun, Aug 24, 2014 at 03:17:14PM -0700, Russ Allbery wrote: As I understand it, your primary concern is around the decision-making process for handling changes to priority (particularly increasing priority). It's not necessarily the decision-making process. Actually I didn't look in detail into past override decisions, only into the current situation. It's the lack of transparency, packages with said added dependencies migrating into testing before the override decision has been made, and deliberate policy violation with excuse (debcheck priority data). That, in turn, I assume is driven by concerns about the size and packages included in a default Debian installation and a minimal Debian installation. Yes. So, here's what I would propose. First, I agree with your direction on eliminating extra and allowing Priority: optional packages to conflict with each other. I think the overhead of managing this distinction is more trouble than it's worth, and the original goals largely no longer apply. Second, I think we should document the actual way that priorities are changed in Debian Policy somewhere, and say explicitly that ftp-master is canoncial for priorities, not the package maintainers. Third, to address your concern about the process, what about consensus review on debian-devel for any change in priority to required or important (that is not a downgrade from required to important)? Consensus review isn't the best process, since sometimes it can be hard to determine when it's concluded, but it seems to work reasonably well for Pre-Depends, and I think it would at least address the awareness question. ftp-master as the holders of the overrides would then rely on the debian-devel consensus as input to their decision on whether to approve the override change. Does that sound like a workable way forward? Sounds good to me. But I think this bug should only deal with the first. It's almost never a good idea to broaden the scope of a proposed change, it makes finding consensus more difficult. And I don't see a reason to couple the changes, the second and third can be done on top of the first. Personally I don't rate the second that important, the third is in the spirit of transparency and so I'd be willing to second it. Regards, Gerrit. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#758234: [PATCH] Remove priority extra, make all corresponding packages priority optional
retitle 758234 Remove priority extra, make all corresponding packages priority optional quit Since discussion on this topic seems to have stopped, I suggest this patch to remove the priority extra for Debian packages. All packages that currently are of priority extra shall be changed to priority optional for the reasons outlined in message #35 to this very report https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=758234#35 If technically feasible, and I think so, the transition shall be done through ftpmaster's override file, which will cause lintian warnings for affected packages so that the maintainers can adapt the packages' control files gradually. If further discussion doesn't happen or doesn't suggest otherwise, I plan to call for seconds in about a week. Regards, Gerrit. --- policy.sgml | 17 - 1 file changed, 4 insertions(+), 13 deletions(-) diff --git a/policy.sgml b/policy.sgml index dad8d23..05d52f7 100644 --- a/policy.sgml +++ b/policy.sgml @@ -855,15 +855,6 @@ zope. distribution, and many applications. Note that optional packages should not conflict with each other. /item - tagttextra/tt/tag - item - This contains all packages that conflict with others - with required, important, standard or optional - priorities, or are only likely to be useful if you - already know what they are or have specialized - requirements (such as packages containing only detached - debugging symbols). - /item /taglist /p @@ -3658,10 +3649,10 @@ Files: size, section and priority and the filename. For example: example Files: - 4c31ab7bfc40d3cf49d7811987390357 1428 text extra example_1.2-1.dsc - c6f698f19f2a2aa07dbb9bbda90a2754 571925 text extra example_1.2.orig.tar.gz - 938512f08422f3509ff36f125f5873ba 6220 text extra example_1.2-1.diff.gz - 7c98fe853b3bbb47a00e5cd129b6cb56 703542 text extra example_1.2-1_i386.deb + 4c31ab7bfc40d3cf49d7811987390357 1428 text optional example_1.2-1.dsc + c6f698f19f2a2aa07dbb9bbda90a2754 571925 text optional example_1.2.orig.tar.gz + 938512f08422f3509ff36f125f5873ba 6220 text optional example_1.2-1.diff.gz + 7c98fe853b3bbb47a00e5cd129b6cb56 703542 text optional example_1.2-1_i386.deb /example The qref id=f-Sectionsection/qref and qref id=f-Prioritypriority/qref are the values of -- 2.1.0 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#758852: runit: bash-complete directories for sv
tags 758852 + pending quit On Fri, Aug 22, 2014 at 01:46:07AM -0400, Jeff King wrote: In addition to services running in /etc/service, users may have their own service directories (e.g., in ~/.service). The default bash completion made it easy to complete with sv t .serTABfooTAB, but the programmable completion does not include them at all. We can complete any local directories by using bash-completion's filedir helper. Thanks, applied. Regards, Gerrit. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#758234: debian-policy: allow packages to depend on packages of lower priority
On Sat, Aug 16, 2014 at 09:03:14AM -0700, Russ Allbery wrote: Gerrit Pape p...@dbnbgs.smarden.org writes: Hi, in my opinion this paragraph in policy is just fine I really don't agree. Policy currently implies that the maintainers of packages control their priority settings in the archive. This is simply not true, and has not been true for as long as I've been involved in Debian. Hi, AIUI this is not the topic this bug is about. The subject says allow packages to depend on packages of lower priority and the body suggest to remove the paragraph from policy. I hereby object to this change. and helps us to keep control over the size of required and important. This is a different issue. You want oversight over what goes into required and important. I can certainly see why you want this. Yes. However, Policy still should not contain incorrect statements about how that oversight works, and it certainly isn't under the control of the package maintainers. Currently, that oversight is provided by the ftp team with the (rather awkward) assistance of tools that look for priority inversions. The paragraph under discussion is in 2 The Debian Archive, which generally is not under control of the maintainers, not the area, not the section (also overridden), and not the priority. Also, from the very past when Manoj handled the policy changes process, I vaguely remember that he often commented that policy documents what shall be, and not how it shall be done. But my current interest is not in this area. The maintainers really aren't involved, and it's pointless to file bugs against the packages themselves about priorities, to try to fix it in debian/control, since that will have no effect on the priorities in the archive. Here I disagree. In a transparent workflow bugs against the package that is actually affected are a good thing, no matter how/where the bug can/will be fixed. See below. (It's reasonable to file bugs against the packages about *dependencies*, if you feel that they're pulling in too many other I'm afraid this often will be a dead end, e.g. https://bugs.debian.org/757891 If you don't feel that the ftp team is the right team to provide oversight, or want to propose a different way of managing the contents of those priorities, that's quite possibly a good conversation to have (although it's probably one for debian-devel). This is not my concern. And I think the maintainers greatly are involved, as they add dependencies to packages, and so start the ftp master's override process, so let me suggest another change and a workflow to think about: 1. Make optional and extra of the same priority. I.e. packages of priority optional depending on packages of priority extra no longer depend on packages with lower priority values. Now the debcheck priority information becomes useful again, as there's only tens of violations left. As it is now, latest evidence shows that it is used as an excuse for deliberate violation of policy 2.5, even for packages of priority important and standard, and possibly required[0]. 2. Whenever a maintainer adds a dependency to a package of lower priority, file a bug against ftp.debian.org asking to raise priority of the dependant package. To make this transparent, file a RC bug against the package where the dependency is added, or delay the upload. 3. As soon as the override is in place, the RC bug can be closed, or the package uploaded. There's nothing bad about RC bugs, we should not fear them! An RC bug on a package version in unstable prevents it from being migrated to testing, which is a good thing if there's an override decision pending. Currently the whole process is neither transparent nor controlled: E.g. since wheezy until now, the rsyslog maintainer added 10 new dependencies to packages of priority extra and optional. Including one dependency on a package that in turn depends on the perl package. rsyslog is of priority important. All of this already is in testing, and none of this information is transparent, neither through the rsyslog bug entries, nor through the ftp.debian.org bug entries https://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=ftp.debian.org;dist=unstable#_0_1_4 BUT, having these overrides now added by the ftp masters, as the replies I read until now suggest is the current workflow, will have an impact on the set of high priority packages I don't agree with. And policy neither. Regards, Gerrit. [0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=757891#42 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#758231: rsyslog: is priority important, depends on packages with priority extra
unmerge 758231 retitle 758231 rsyslog: is priority important, depends on packages with priority extra reassign 758231 rsyslog 8.2.2-3 severity 758231 serious retitle 758233 cron: is priority important, depends on package with priority extra reassign 758233 cron 3.0pl1-124.2 severity 758233 serious quit 15:34:45 bug#758229 filed against nfacct 15:47:02 bug#758231 filed against rsyslog 15:52:19 bug#758233 filed against cron 15:57:05 1st followup from rsyslog maintainer, ironic 15:59:55 bug#758231 re-assing to ftp.debian.org, merged with #758233, severity set to normal, retitle by ftpmaster 16:10:24 cross-post to two lists from rsyslog maintainer, intends to re-assign to policy 16:17:07 bug#758231, 758233 re-assign to policy 16:21:10 bug#758234 filed against policy, asking to remove MUST in policy by ftpmaster 16:31:42 cross-post to three mailing lists from rsyslog maintainer, FUD Heck, I was preparing a mail to debian-qa to give some explanation about my reasoning and suggestions on how to improve the situation. Don't you have other things to do? If not, how about thinking a bit about what the concerns of the bug submitter could be? In another area I work, this is called the jumping-on-bugs-anti-pattern I really don't think this is the way bugs filed by a Debian developer, who is with Debian since more than 13 years, should be handled. Actually no matter who filed the bugs. I filed bugs, raised my concerns, and stand by this. forcemerge 758231 758233 retitle 758233 override: init-system-helpers: admin/important This is not the bug I reported, but rsyslog: is priority important, depends on packages with priority extra and a list of four packages, not one. For reasoning, see https://lists.debian.org/debian-policy/2014/08/msg00033.html https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=758234#35 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#757891: init-system-helpers: Please do not depend on perl
On Thu, Aug 14, 2014 at 09:23:17AM +0300, Niko Tyni wrote: On Tue, Aug 12, 2014 at 10:41:50PM +0200, Michael Biebl wrote: Am 12.08.2014 21:15, schrieb Niko Tyni: The perl-base package is Essential:yes, so inclusion there is pretty close to a promise of supporting that interface forever inside the Essential set. So care must be taken when adding functionality there. IMO Perl reimplementations of /usr/bin/find, /usr/bin/basename, /bin/mkdir -p, and /bin/rm -r don't seem very good candidates. Why not? Can you elaborate? [...] But yeah, I may be making too big a fuss about just a few modules at 150kB. No, I don't think so. It's technically very easy to add features and size to an Essential: yes package every here and then, but very hard -if not impossible- to remove, just as you said. So, I very appreciate your thoroughness and wish that all developers maintaining essential packages, and those of priority required and important, show this sense of responsibility. Thanks, Gerrit. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#758229: nfacct: is priority important, depends on packages with priority extra
Package: nfacct Version: 1.0.1-1 Severity: serious Justification: Policy 2.5 Hi, the current nfacct package version in testing is priority important and depends on packages with priority extra. Policy 2.5 states: Packages must not depend on packages with lower priority values (excluding build-time dependencies). $ apt-cache show nfacct |grep -E '^Version:|^Priority|^Depends' Version: 1.0.1-1 Depends: libc6 (= 2.7), libmnl0, libnetfilter-acct1 Priority: important $ apt-cache show libmnl0 libnetfilter-acct1 |grep ^Priority Priority: extra Priority: extra $ Regards, Gerrit. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#758231: rsyslog: is priority important, depends on packages with priority extra
Package: rsyslog Version: 8.2.2-3 Severity: serious Justification: Policy 2.5 Hi, the current rsyslog package version in testing is priority important and depends on packages with priority extra. Policy 2.5 states: Packages must not depend on packages with lower priority values (excluding build-time dependencies). $ apt-cache show rsyslog |grep -E '^Version:|^Priority|^Depends' Version: 8.2.2-3 Depends: libc6 (= 2.17), libestr0 (= 0.1.4), libjson-c2 (= 0.10), liblogging-stdlog0 (= 1.0.2), liblognorm1 (= 0.3.0), libuuid1 (= 2.16), zlib1g (= 1:1.1.4), init-system-helpers (= 1.18~), lsb-base (= 3.2-14), initscripts (= 2.88dsf-13.3) Priority: important $ apt-cache show libestr0 libjson-c2 liblognorm1 init-system-helpers |grep ^Priority Priority: extra Priority: extra Priority: extra Priority: extra $ Regards, Gerrit. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#758233: cron: is priority important, depends on package with priority extra
Package: cron Version: 3.0pl1-124.2 Severity: serious Justification: Policy 2.5 Hi, the current cron package version in testing is priority important and depends on a package with priority extra. Policy 2.5 states: Packages must not depend on packages with lower priority values (excluding build-time dependencies). $ apt-cache show cron |grep -E '^Version:|^Priority|^Depends' Version: 3.0pl1-124.2 Depends: libc6 (= 2.7), libpam0g (= 0.99.7.1), libselinux1 (= 1.32), init-system-helpers (= 1.18~), debianutils (= 1.7), adduser, lsb-base (= 3.0-10), libpam-runtime (= 1.0.1-11) Priority: important $ apt-cache show init-system-helpers |grep ^Priority Priority: extra $ Regards, Gerrrit. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#757891: init-system-helpers: Please do not depend on perl
On Tue, Aug 12, 2014 at 10:41:50PM +0200, Michael Biebl wrote: Am 12.08.2014 21:15, schrieb Niko Tyni: What's the dependency from rsyslog to init-system-helpers for? Is there any room for movement there? The init-system-helpers dependency is there to ensure the systemd service is properly registered upon installation and removed on uninstall and it takes care of starting/stopping/restarting the service. I do not see a compelling to re-implement that functionality in the rsyslog maintainer scripts. So, no, I have no desire to switch away from init-system-helpers. $ apt-cache show rsyslog |grep ^Priority Priority: important $ apt-cache show init-system-helpers |grep ^Priority Priority: extra $ As of policy 2.5: Packages must not depend on packages with lower priority values (excluding build-time dependencies). There's more, as debcheck states https://qa.debian.org/debcheck.php?dist=unstablepackage=rsyslog I'd also like to advise using versioned dependencies only when really necessary, when updating to new stable $ apt-cache show rsyslog |grep ^Depends Depends: libc6 (= 2.17), libestr0 (= 0.1.4), libjson-c2 (= 0.10), liblogging-stdlog0 (= 1.0.2), liblognorm1 (= 0.3.0), libuuid1 (= 2.16), zlib1g (= 1:1.1.4), init-system-helpers (= 1.18~), lsb-base (= 3.2-14), initscripts (= 2.88dsf-13.3) $ Regards, Gerrit. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#505608: runit: stopped runsv processes not responding to TERM signals
On Fri, Aug 08, 2014 at 11:45:53AM +0200, Marc Haber wrote: I still can reproduce the behavior on a wheezy system. Here is the output of sv stat: sudo sv stat /var/lib/cereal/sessions/sw01 down: /var/lib/cereal/sessions/sw01: 82s; run: log: (pid 25393) 76s Hi Marc, when runsv is told to exit either through sv exit, or when receiving TERM, which also happens when the service directory symlink is removed from /etc/service/ (e.g. through update-service --remove), then from runsv(8): If the service is running, send it a TERM signal, and then a CONT signal. Do not restart the service. If the service is down, and no log service exists, runsv exits. If the service is down and a log service exists, runsv closes the standard input of the log service, and waits for it to terminate. If the log service is down, runsv exits. In your case the log service is still running, and so runsv is still waiting for it. The best solution is to make your log service detect that stdin is closed and exit as there's no more data to log. Does this fix your problem? Regards, Gerrit. PS: before runit 2.1.2 the sv(8) man page was wrong, stating that a TERM signal is sent to the log service, but actually only stdin is closed so that the log service has the chance to process everything that shall be logged. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#505608: runit: stopped runsv processes not responding to TERM signals
On Tue, Nov 03, 2009 at 01:54:10PM +0100, Marc Haber wrote: I can reproduce the issue with the instructions given by Jameson. On Mon, Oct 12, 2009 at 09:39:42AM +, Gerrit Pape wrote: Hi Jameson, if you still have this problem, please tar the service directory, and mail the tar archive to this bug report, I'll take a look then. Attached. $ pstree -apl 2856 runsvdir,2856 -P /etc/servicelog:\040.. $ sudo update-service --add /var/lib/cereal/sessions/sw01 cereal.sw01 Service cereal.sw01 added. $ pstree -apl 2856 runsvdir,2856 -P /etc/servicelog:\040.. └─runsv,3113 cereal.sw01 └─run,3114 -e ./run $ sudo update-service --remove /var/lib/cereal/sessions/sw01 cereal.sw01 Service cereal.sw01 removed, the service daemon received the TERM and CONT signals. $ pstree -apl 2856 runsvdir,2856 -P /etc/servicelog:\040.. └─runsv,3113 cereal.sw01 └─run,3114 -e ./run $ I would have expected processes 3113 and 3114 to die. Please note that you will probably have to install cereal to reproduce the issue as cereal makes heavy use of out-of-tree symlinks in its service directories. Hi, thanks for this and sorry for the late reply. I guess the service is hanging in the finish state, if so, ./finish should be fixed. runsv will not exit unless the ./finish script has done its job and terminated. The output of 'sv stat /var/lib/cereal/sessions/sw01' would be interesing in this situation, and tell us whether the service is in the finish state. Do you still have these services in operation and can check? Regards, Gerrit. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#735336: Info received (git-svn fails 'tempfile' can't be called as a method at /usr/share/perl5/Git.pm line 1042.)
On Fri, Jan 17, 2014 at 04:21:50PM -0600, James Michael DuPont wrote: OK the problem showed up again with sid I will check now the different versions. git review fatal: Unpack error, check server log) remote: Resolving deltas: 100% (25/25) error: unpack failed: error Missing blob 3635bf2ac5522a7e9c1fbae108c9ad9b639f10d7 To ssh://X@review.Y:29418/D/U ! [remote rejected] HEAD - refs/publish/master/review_master (n/a (unpacker error)) error: failed to push some refs to ssh://X@review.Y:29418/D/U git version 1.8.5.3.321.g14598b9 it happens when adding new files to an existing change. Hi mike, git is now at version 1:2.0.1-1 in testing. Can you please check whether you still have this issue with it? Regards, Gerrit. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#614981: allow option specification for dropbear in /etc/initramfs-tools/initramfs.conf
On Sat, Mar 01, 2014 at 05:37:49PM +0100, Guilhem Moulin wrote: I fully second this patch. Would be great to see it applied in Jessie ;-) Another common use case is where the dropbear in the ramdisk should listen on a port other than 22: then a simple firewall rule can make it inaccessible from the whole world while keeping the main SSH server accessible. Currently the only way to achieve that is again to edit /usr/share/initramfs-tools/scripts/init-premount/dropbear which isn't a very robust solution as it wouldn't survive an upgrade. Hi, I can add this part to the dropbear package (and actually do so with the next upload) --- /usr/share/initramfs-tools/scripts/init-premount/dropbear.ORG 2011-02-24 16:53:20.0 + +++ /usr/share/initramfs-tools/scripts/init-premount/dropbear 2011-02-24 16:54:16.0 + @@ -32,5 +32,5 @@ configure_networking mkdir -p /var/run -/sbin/dropbear +/sbin/dropbear $PKGOPTION_dropbear_OPTION but /etc/initramfs-tools/initramfs.conf is installed through the initramfs-tools package $ dpkg -S /etc/initramfs-tools/initramfs.conf initramfs-tools: /etc/initramfs-tools/initramfs.conf $ Please, if you want both parts applied, take care of this. Thanks, Gerrit. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#715048: Patch to add support for an indpendendent initramfs networking config
tags 715048 + patch quit On Tue, Jul 09, 2013 at 09:29:02AM -0500, Karl O. Pinc wrote: Attached is a patch which adds support for a completely different networking configuration in the initramfs from that of the running system. The patch brings down network interfaces, when configured to do so, after the rootfs is mounted. There is a configuration file in conf.d/ and a script in scripts/local-bottom/, and a patch to the debian/rules file to install them. It works for me, although I've not tested the debian/rules file. However, it does not work without a patch to klibc which enables the ipconfig command to bring down network interfaces. Hi Karl, thanks a lot for your contributions to the dropbear package. Can you tell me what's the status of this patch is? It doesn't look ready to be included to me. Regards, Gerrit. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#568092: daemontools: support QUIT, USR[12] signals
tags 568092 + wontfix quit On Tue, Feb 02, 2010 at 11:03:31PM +1100, Matthew Palmer wrote: It would be handy if we could send QUIT/USR1/USR2 signals to supervise-managed processes. Handily, there's already a patch for that out in the wild: http://thedjbway.b0llix.net/patches/daemontools-0.76.sigq12.patch I adjusted it ever-so-slightly and added manpage bits, to produce the attached patch. Hi, sorry for the late reply and thanks for the patch. I'm not about to apply the patch though, for the same reason as bug#534508 is wontfix: I actually want to keep daemontools in Debian as close to upstream as possible. There are alternatives you can use, like runit, perp, s6, ... Regards, Gerrit. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#734851: feature request
severity 734851 wishlist quit On Fri, Jan 10, 2014 at 06:26:38PM +0800, Wang Jian wrote: When using daemontools-run, only root can manipulate /etc/service. That sets strong limitation. For security reason, in a server farm for internet services, application processes that do real work are normally run under non-priviledged account instead of root, and separated from internet by frontend servers (load balancers). In the said scenario, daemontools should run under non-priviledged accounts. This eases operations. Here is my solution https://github.com/lark/daemontools-userrun Note that it still supports /etc/service for root (when configured). The only problem is without init's help (/etc/inittab), svscan may be killed and no respawn happens. IMHO, it's not a big problem if oom killer doesn't kill it. Please consider incorporate this 'daemontools-userrun' functionality into daemontools packages. The said git repository is in-house operation work so no explicit license is attached, while the code is based upon svscanboot. Hi, thanks for the suggestion. Unfortunately I have only limited time available to work on these Debian packages, so for now I set this report to severity wishlist and keep it in the packages' bug list. Regards, Gerrit. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#545286: mention setlock -n return value
On Sun, Sep 06, 2009 at 05:47:48PM +0800, jida...@jidanni.org wrote: Mention return value of -n No delay. If fn is locked by another process, setlock gives up. Please provide a patch, git clone http://smarden.org/git/daemontools.git -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#752075: daemontools-run: Add systemd support
Hi Michael, On Fri, Jul 18, 2014 at 08:06:11PM +0200, Michael Stapelberg wrote: Gerrit Pape p...@dbnbgs.smarden.org writes: I'm really not keen to add a dependency to daemontools-run, esp. not to the runit package, just for (un)installing and starting/stopping a service. I presume you mean init-system-helpers as the dependency you don???t want to add. Any dependency: $ apt-cache show runit |grep ^Depends $ apt-cache show daemontools-run |grep ^Depends Depends: daemontools ( 1:0.76) $ apt-cache show daemontools |grep ^Depends Depends: libc6 (= 2.7-1) $ Why isn't it as simple as installing the unit, and then?: systemd not installed || start service It is as simple as that. deb-systemd-invoke supports policy-rc.d, though, which your intended example (AIUI) does not. You???d make some users really unhappy if you break policy-rc.d with your package. I don't think so. The daemontools-run and runit packages don't include init scripts. policy-rc.d never had an effect on them, so nothing will break. systemd not installed || have service started by default When systemd is not installed, where does the logic for having the service started by default come from? While the actually relevant part of that is as simple as creating a symlink, there are some things make this entire process more complicated. Some of them come from the fact I hope this as simple as creating a symlink works out. that the enabled-state needs to be synchronized across init systems, i.e. what you do in systemd should also work for the sysvinit-fallback. This is not necessary for the packages in question. They have an inittab entry since many years SV:123456:respawn:/usr/sbin/runsvdir-start The whole purpose of the packages is to provide this service, no enabled-state is needed. $ apt-cache show runit |grep ^Description-en Description-en: system-wide service supervision $ apt-cache show daemontools-run |grep ^Description-en Description-en: daemontools service supervision $ Further, consider this (from the manpage of deb-systemd-helper): The enable action will only be performed once (when first installing the package). On the first enable, an state file is created which will be deleted upon purge. ???which enables administrators to disable units and not have them magically re-enabled on the next package upgrade. See above, I don't think this applies. Also, the dh-systemd/deb-systemd-helper combination properly handles mask-after-remove (i.e. remove but not purge). Anything wrong in this regard with my current implementation? In general, it???s hugely beneficial to Debian if packages use the same helpers/debhelper addons to build their maintainer scripts. Bugfixes and other improvements that we put into i-s-h will propagate to all packages without coordinating huge updates/fixes. You don???t need to think about all the intricacies of correctly handling unit files (in Debian!) because we already did it. We're different individuals in Debian and have different opinions. To me it's beneficial to Debian if there still exist packages not using debhelper, doing things differently than others, even than the masses, following KISS. I want to think about and understand how the inittab entry SV:123456:respawn:/usr/sbin/runsvdir-start translates most easily into a systemd service, now that I learned that this is necessary because systemd doesn't provide backward compatibility for such services. Let me also point out that _every_ system already has i-s-h installed these days, so there really is no cost in adding this dependency. That's not true. Just a few of my systems have this package pulled in, all of them have runit installed. Regards, Gerrit. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#752075: daemontools-run: Add systemd support
On Mon, Jul 28, 2014 at 02:36:06PM +0200, Michael Biebl wrote: Since you are going to do it your way anyway I'm not sure why you ask for feedback from us? It's like talking to a brick wall. Hi, I'm sorry that you feel this way. I also found our communication far from ideal, and after I refused to add a dependency to the daemontools-run and runit packages, it failed completely. To me this feels like do it your way, or no way. Since you're the specialists, there's still hope to get feedback other than On Tue, Jul 22, 2014 at 03:03:02PM +0200, Michael Biebl wrote: There is a reason, why we added the logic in a single place. On Tue, Jul 22, 2014 at 06:11:24PM +0200, Michael Stapelberg wrote: I'm not sure how we can state this more clearly: Use dh-systemd or you _will_ have bugs sooner or later. It is the most simple implementation that we could come up with. There also are reasons for my design choice. There are still various issues with the maintainer scripts code [1] Please tell me which ones. [1] aside from the fact that negative clauses make it unnecessarily hard to read. The fact is that people are different. To me this is most intuitively to read in set -e scripts. When does this script stop?: set -e true true false false || true false false false true || true false true false true || false true true || false true true false true false false and I see you dropped the .path unit again? Yes. I don't understand the question. On Tue, Jul 22, 2014 at 03:18:02PM +0200, Michael Biebl wrote: What about Ansgar's improvements/suggestions [1]? E.g. adding a Documentation= header, directly using svscan, etc? Thanks to Ansgar, I looked at them but currently don't want to do a bit more integration into systemd. KISS and provide the very same software experience to users of these packages under sysvinit, runit, and systemd. Regards, Gerrit. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#752075: daemontools-run: Add systemd support
Hi Michael, On Tue, Jul 22, 2014 at 06:11:24PM +0200, Michael Stapelberg wrote: I'm not sure how we can state this more clearly: Use dh-systemd or you _will_ have bugs sooner or later. It is the most simple implementation that we could come up with. sorry, we have different points of view, and I will definitely not switch my packages to debhelper. Sure, most probably there will be bugs sooner or later, considering that systemd intergration is still under development. But also for packages utilizing debhelper, maybe even more more so because the implementation is more complex. They'll probably go through binary NMUs. Regards, Gerrit. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#715512: sv status can get confused
tags 715512 + patch
quit
On Tue, Jul 09, 2013 at 09:01:27PM +, Jamie Heilman wrote:
This is pretty unlikely to happen in normal usage, but I ran across it
doing some testing of sv status behaviors; if sv is given multiple
service directories to operate on, and some of them don't have an
active runsv process sv status may report misleading information:
Given two service directories:
# ls testapp1
run supervise
# ls testapp2
log run supervise
where testapp1 is running, and testapp2 isn't:
# sv status ./testapp1
run: ./testapp1: (pid 3682) 408178s
# sv status ./testapp2
fail: ./testapp2: runsv not running
# sv status ./testapp1 ./testapp2
run: ./testapp1: (pid 3682) 408184s
fail: ./testapp2: runsv not running
run: ./testapp2: (pid 3682) 408184sfail: ./testapp2: runsv not running
That third line is the issue, afaics it shouldn't exist at all.
Thanks a lot for the report, it's a typo in the source since ages.
Here's a patch.
Regards, Gerrit.
diff --git a/runit-2.1.1/src/sv.c b/runit-2.1.1/src/sv.c
index e27ccb2..cea2487 100644
--- a/runit-2.1.1/src/sv.c
+++ b/runit-2.1.1/src/sv.c
@@ -153,7 +153,7 @@ int status(char *unused) {
int rc;
rc =svstatus_get();
- switch(r) { case -1: if (lsb) done(4); case 0: return(0); }
+ switch(rc) { case -1: if (lsb) done(4); case 0: return(0); }
rc =svstatus_print(*service);
if (chdir(log) == -1) {
if (errno != error_noent) {
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#752075: daemontools-run: Add systemd support
On Tue, Jul 22, 2014 at 03:03:02PM +0200, Michael Biebl wrote:
Am 22.07.2014 14:34, schrieb Gerrit Pape:
On Fri, Jul 18, 2014 at 12:03:41PM +, Gerrit Pape wrote:
I'm really not keen to add a dependency to daemontools-run, esp. not to
the runit package, just for (un)installing and starting/stopping a
service.
Hi, I've now prepared this changeset. Do you have any comments on it?
That said, the logic you added is incomplete/broken in several ways:
Hi, I'm about to upload these changes:
Author: Gerrit Pape p...@smarden.org
Date: Tue Jul 22 12:26:42 2014 +
* debian/systemd/daemontools.service: new; daemontools-run systemd unit
file (thx Michael Biebl, Jonathan de Boyne Pollard, Milan P. Stanic).
* debian/rules: install daemontools-run systemd unit file.
* debian/daemontools-run.postinst, debian/daemontools-run.postrm: enable
and start, disable and stop respectively, daemontools unit if systemd
is process 1 (closes: #752075).
diff --git a/debian/changelog b/debian/changelog
index 8d124f4..a7b7d0e 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,14 @@
+daemontools (1:0.76-4) unstable; urgency=low
+
+ * debian/systemd/daemontools.service: new; daemontools-run systemd unit
+file (thx Michael Biebl, Jonathan de Boyne Pollard, Milan P. Stanic).
+ * debian/rules: install daemontools-run systemd unit file.
+ * debian/daemontools-run.postinst, debian/daemontools-run.postrm: enable
+and start, disable and stop respectively, daemontools unit if systemd
+is process 1 (closes: #752075).
+
+ -- Gerrit Pape p...@smarden.org Sat, 26 Jul 2014 09:58:37 +
+
daemontools (1:0.76-3) unstable; urgency=low
* debian/daemontools-run.postinst: don't exec into the kill program, so
diff --git a/debian/daemontools-run.postinst b/debian/daemontools-run.postinst
index d51ac09..7c49b06 100644
--- a/debian/daemontools-run.postinst
+++ b/debian/daemontools-run.postinst
@@ -74,3 +74,10 @@ if ! grep '^SV:' /etc/inittab /dev/null; then
mv -f /etc/inittab'{new}' /etc/inittab
kill -s HUP 1
fi
+
+# systemd service
+test -h /etc/systemd/system/multi-user.target.wants/daemontools.service ||
+ test ! -d /etc/systemd/system/multi-user.target.wants ||
+ln -s /lib/systemd/system/daemontools.service \
+ /etc/systemd/system/multi-user.target.wants/
+test ! -d /run/systemd/system || systemctl start daemontools.service
diff --git a/debian/daemontools-run.postrm b/debian/daemontools-run.postrm
index 683e8dc..d27eef5 100644
--- a/debian/daemontools-run.postrm
+++ b/debian/daemontools-run.postrm
@@ -16,3 +16,9 @@ if grep -q #-- daemontools-run begin /etc/inittab; then
echo 'Sending log services the TERM and CONT signals...'
svc -dx /etc/service/*/log || :
fi
+
+# systemd service
+test ! -d /run/systemd/system ||
+ ! systemctl is-active daemontools.service /dev/null ||
+systemctl stop daemontools.service
+rm -f /etc/systemd/system/multi-user.target.wants/daemontools.service
diff --git a/debian/rules b/debian/rules
index eeab545..21fb57c 100755
--- a/debian/rules
+++ b/debian/rules
@@ -63,6 +63,10 @@ install-indep: deb-checkdir deb-checkuid
install -d -m0755 '$(DIR)'-run/usr/share/man/man8
install -m0644 debian/update-service.8 '$(DIR)'-run/usr/share/man/man8/
gzip -9 '$(DIR)'-run/usr/share/man/man8/update-service.8
+ # systemd service
+ install -d -m0755 '$(DIR)'-run/lib/systemd/system
+ install -m0644 debian/systemd/daemontools.service \
+ '$(DIR)'-run/lib/systemd/system/
# changelog
test -r changelog || ln -s daemontools-0.76/src/CHANGES changelog
diff --git a/debian/systemd/daemontools.service
b/debian/systemd/daemontools.service
new file mode 100644
index 000..09d9228
--- /dev/null
+++ b/debian/systemd/daemontools.service
@@ -0,0 +1,9 @@
+[Unit]
+Description=Daemontools service supervision
+
+[Service]
+ExecStart=/usr/bin/svscanboot /etc/service/
+Restart=always
+
+[Install]
+WantedBy=multi-user.target
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#752075: daemontools-run: Add systemd support
On Fri, Jul 18, 2014 at 12:03:41PM +, Gerrit Pape wrote:
I'm really not keen to add a dependency to daemontools-run, esp. not to
the runit package, just for (un)installing and starting/stopping a
service.
Hi, I've now prepared this changeset. Do you have any comments on it?
Author: Gerrit Pape p...@smarden.org
Date: Tue Jul 22 12:26:42 2014 +
* debian/systemd/daemontools.path, debian/systemd/daemontools.service:
new; daemontools-run systemd unit files (thx Michael Biebl, Jonathan de
Boyne Pollard, Milan P. Stanic).
* debian/rules: install daemontools-run systemd unit files.
* debian/daemontools-run.postinst, debian/daemontools-run.postrm: enable
and start, disable and stop respectively daemontools units if systemd
is process 1.
diff --git a/debian/changelog b/debian/changelog
index 8d124f4..d2d4efc 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,15 @@
+daemontools (1:0.76-3.1) UNRELEASED; urgency=low
+
+ * debian/systemd/daemontools.path, debian/systemd/daemontools.service:
+new; daemontools-run systemd unit files (thx Michael Biebl, Jonathan de
+Boyne Pollard, Milan P. Stanic).
+ * debian/rules: install daemontools-run systemd unit files.
+ * debian/daemontools-run.postinst, debian/daemontools-run.postrm: enable
+and start, disable and stop respectively, daemontools units if systemd
+is process 1.
+
+ -- Gerrit Pape p...@smarden.org Tue, 22 Jul 2014 14:00:45 +0200
+
daemontools (1:0.76-3) unstable; urgency=low
* debian/daemontools-run.postinst: don't exec into the kill program, so
diff --git a/debian/daemontools-run.postinst b/debian/daemontools-run.postinst
index d51ac09..1d7aae1 100644
--- a/debian/daemontools-run.postinst
+++ b/debian/daemontools-run.postinst
@@ -74,3 +74,7 @@ if ! grep '^SV:' /etc/inittab /dev/null; then
mv -f /etc/inittab'{new}' /etc/inittab
kill -s HUP 1
fi
+if test $(readlink /sbin/init || :) = /lib/systemd/systemd; then
+ systemctl enable -f daemontools.path
+ systemctl start daemontools.path
+fi
diff --git a/debian/daemontools-run.postrm b/debian/daemontools-run.postrm
index 683e8dc..04f5299 100644
--- a/debian/daemontools-run.postrm
+++ b/debian/daemontools-run.postrm
@@ -16,3 +16,10 @@ if grep -q #-- daemontools-run begin /etc/inittab; then
echo 'Sending log services the TERM and CONT signals...'
svc -dx /etc/service/*/log || :
fi
+if test $(readlink /sbin/init || :) = /lib/systemd/systemd; then
+ systemctl disable daemontools.path
+ ! systemctl is-active daemontools.path /dev/null ||
+systemctl stop daemontools.path
+ ! systemctl is-active daemontools.service /dev/null ||
+systemctl stop daemontools.service
+fi
diff --git a/debian/rules b/debian/rules
index eeab545..d7ff9c0 100755
--- a/debian/rules
+++ b/debian/rules
@@ -63,6 +63,10 @@ install-indep: deb-checkdir deb-checkuid
install -d -m0755 '$(DIR)'-run/usr/share/man/man8
install -m0644 debian/update-service.8 '$(DIR)'-run/usr/share/man/man8/
gzip -9 '$(DIR)'-run/usr/share/man/man8/update-service.8
+ # systemd units
+ install -d -m0755 '$(DIR)'-run/lib/systemd/system
+ install -m0644 debian/systemd/daemontools.* \
+ '$(DIR)'-run/lib/systemd/system/
# changelog
test -r changelog || ln -s daemontools-0.76/src/CHANGES changelog
diff --git a/debian/systemd/daemontools.path b/debian/systemd/daemontools.path
new file mode 100644
index 000..97ca37b
--- /dev/null
+++ b/debian/systemd/daemontools.path
@@ -0,0 +1,9 @@
+[Unit]
+Description=Daemontools service monitor
+
+[Path]
+DirectoryNotEmpty=/etc/service/
+Unit=daemontools.service
+
+[Install]
+WantedBy=multi-user.target
diff --git a/debian/systemd/daemontools.service
b/debian/systemd/daemontools.service
new file mode 100644
index 000..077e6ab
--- /dev/null
+++ b/debian/systemd/daemontools.service
@@ -0,0 +1,8 @@
+[Unit]
+Description=Daemontools service scanner
+
+[Service]
+ExecStart=/usr/bin/svscanboot /etc/service/
+Restart=always
+
+[Install]
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#752075: daemontools-run: Add systemd support
On Tue, Jul 22, 2014 at 03:03:02PM +0200, Michael Biebl wrote:
Am 22.07.2014 14:34, schrieb Gerrit Pape:
Hi, I've now prepared this changeset. Do you have any comments on it?
diff --git a/debian/daemontools-run.postinst
b/debian/daemontools-run.postinst
index d51ac09..1d7aae1 100644
--- a/debian/daemontools-run.postinst
+++ b/debian/daemontools-run.postinst
@@ -74,3 +74,7 @@ if ! grep '^SV:' /etc/inittab /dev/null; then
mv -f /etc/inittab'{new}' /etc/inittab
kill -s HUP 1
fi
+if test $(readlink /sbin/init || :) = /lib/systemd/systemd; then
+ systemctl enable -f daemontools.path
+ systemctl start daemontools.path
+fi
The canonical check if systemd is PID 1 is
test -d /run/systemd/system
Thanks.
That said, the logic you added is incomplete/broken in several ways:
The user first installs daemontools-run, later on systemd = the
daemon-tools service will not be enabled
How can I achieve this without calling systemctl? Creating the symlink
to /etc/systemd/system/... manually, unconditionally?
The user deinstalls systemd. Later on he deinstalls daemontools-run =
the symlinks will not be cleaned up.
So I should create and remove the symlinks unconditionally then, without
using systemctl.
The systemctl enable call is run on every update. = If the admin has
disabled the service, it will be re-enabled
Yes, the daemontools-run package is the very service, to disable it, the
package is removed.
I didn't look further. There are probably more cases your maintainer
scripts don't handle correctly.
There is a reason, why we added the logic in a single place.
With sysvinit I have the logic easily implemented in the maintainer
scripts. With runit it's even more simple. I really don't want to
depend on some complex logic and an additional package just to have a
service as simple as the daemontools' one installed and always running,
think the inittab approach.
Regards, Gerrit.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#752075: daemontools-run: Add systemd support
Hi, thanks for all the help I already got. On Mon, Jul 07, 2014 at 04:56:24PM +0200, Michael Biebl wrote: Am 07.07.2014 16:36, schrieb Gerrit Pape: As Ansgar already mentioned, probably the best way to handle that in Debian is to use the dh-systemd helper. Unfortuantely the daemontools package doesn't use debhelper, which complicates that a bit it. To me, that's not unfortunate. To me, debhelper complicates things. It can't be that difficult to enable a service, configure it to be enabled by default, and vice-versa. The problem here is, that you can't rely on systemd being installed, as it is not mandatory. Therefore we re-implemented the relevant bits in the init-system-helpers package. To see what snippets debhelper puts into maintainer scripts, can you point me to an example package in Debian that installs simple systemd services, Michael? I search for files containing systemd in the debian package directory, but with no applicable result. There are many packages which use dh-systemd (basically all packages depending on init-system-helpers. You can have a look at those. Also, Ansgar already more or less answered that question at [1]: As far as I know, this still misses the maintainer script logic that is needed to start the service on installation and stop it again when the package is removed. There is a debhelper addon to add them, but the daemontools doesn't use debhelper so they have to be added manually. The snippets can be found in autoscripts/* in the init-system-helpers source package (it also needs a runtime dependency on init-system-helpers). You can copy the relevant bits to your maintainer scripts, but it has the unfortunate effect that updates of dh-systemd will not automatically be applied to your package and you'll have to do that manually. I'm really not keen to add a dependency to daemontools-run, esp. not to the runit package, just for (un)installing and starting/stopping a service. Why isn't it as simple as installing the unit, and then?: systemd not installed || start service systemd not installed || have service started by default and systemd not installed || stop service systemd not installed || have service not started by default Why do I need a helper for that? Regards, Gerrit. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#752075: daemontools-run: Add systemd support
Hi Michael, thanks for your help. On Mon, Jul 07, 2014 at 02:59:05PM +0200, Michael Biebl wrote: [CCing the bug report] Am 07.07.2014 14:39, schrieb Jonathan de Boyne Pollard: I did systemd units for this ages ago. It's better to do this as two units: a path unit that watches the service directory and a service unit that is started when the service directory is found to be non-empty. Hi Jonathan, good to see you're still around. Thanks for your contribution. And you don't need svscanboot at all, since systemd's journal logs the output of svscan and does it better than readproctitle does. Ansgar suggested using the journal for that as well [1], which sounds reasonable. Is this journal an in-memory-log, or does it write to disk? And don't forget to run systemctl preset svscan.path as part of your package installation process. (I've heard rumours that update-rc.d svscan.path defaults runs systemctl preset svscan.path in some testing versions somewhere; but I've not witnessed this myself.) As Ansgar already mentioned, probably the best way to handle that in Debian is to use the dh-systemd helper. Unfortuantely the daemontools package doesn't use debhelper, which complicates that a bit it. To me, that's not unfortunate. To me, debhelper complicates things. It can't be that difficult to enable a service, configure it to be enabled by default, and vice-versa. To see what snippets debhelper puts into maintainer scripts, can you point me to an example package in Debian that installs simple systemd services, Michael? I search for files containing systemd in the debian package directory, but with no applicable result. Regards, Gerrit. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
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-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#752075: daemontools-run: Add systemd support
Hi Joern, you did nothing wrong. Severity and justification looks quite right to me. On Fri, Jul 04, 2014 at 12:42:43PM +0200, Joern Heissler wrote: On Fri, Jul 04, 2014 at 09:08:21AM +, Gerrit Pape wrote: 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? With the current stable (wheezy) this package works for most users. I assume that the next stable release, Jessie, will use systemd by default: https://lists.debian.org/debian-ctte/2014/02/msg00405.html So upon release, when this bug is not fixed yet, the package becomes useless for most users. makes the package in question unusable hence I choose grave as severity. Yep, fully understandable from you POV, thanks for filing the bug. * Can I only choose a release-critical severity for bugs affecting the current stable but not the next stable? Bug reporters are free to choose any severity they think applies. It's the maintainer setting it straight if she doesn't agree. I'm just asking debian-devel how to resolve this. I heard systemd is backward-compatible to sysvinit, but looks like this doesn't apply to the inittab interface. Regards, Gerrit -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#752075: RFH: Re: Bug#752075: daemontools-run: Add systemd support
On Fri, Jul 04, 2014 at 03:37:20AM -0700, Russ Allbery wrote: Gerrit Pape p...@dbnbgs.smarden.org 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-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#534508: daemontools: setuidgid should initialize the supplementary groups
On Thu, May 29, 2014 at 01:14:12PM +0200, Carlos Alberto Lopez Perez wrote: Hi, This bite me recently. I'm attaching a debdiff with the patch from Huaqing, which I tested and verified to work as expected. I also updated the manpage. Could you upload this please? If you don't have time I can do an NMU (if you think the attached debdiff is OK) Hi, I don't agree with this change, as I actually want to keep daemontools in Debian as close to upstream as possible. There are alternatives you can use, like runit, perp, s6, ... HTH, Gerrit. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#742549: skalibs-dev: How to link against skalibs with gcc?
On Mon, Mar 24, 2014 at 10:55:44PM +, Reuben Thomas wrote: I tried to compile a simple program http://skarnet.org/software/misc/infinity.c that needs skalibs.I can???t find any instructions in the Debian package other than that the gcc libraries are in /usr/lib, so I tried: $ gcc -o infinity infinity.c -I/usr/include/diet/skalibs /usr/lib/skalibs/*.a /usr/bin/ld.bfd.real: /usr/lib/skalibs/libstddjb.a(buffer_putalign.o): relocation R_X86_64_PC32 against undefined symbol `__errno_location@@GLIBC_2.2.5' can not be used when making a shared object; recompile with -fPIC /usr/bin/ld.bfd.real: final link failed: Bad value collect2: error: ld returned 1 exit status Adding -fPIC to the command-line doesn???t help; I presume the error is intended to mean that the library should be recompiled. Sorry if I???m missing something obvious, but I couldn???t find any more information in the documentation or online. Hi, the package in Debian is designed to allow building of small, static binaries. No shared libraries support as of now. Regards, Gerrit. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#739519: Dropbear init-premount script
On Wed, Feb 19, 2014 at 04:19:58PM +, LaNaar Dakoté wrote: The bug is (if it is) exactly the same as the one higlights in #626181, marked as wishlist item. Do I /really/ have to manually modify this scripts? Awaiting your response. Hi, please see https://lists.debian.org/debian-devel/2014/01/msg00289.html Regards, Gerrit. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#632656: any updates?
On Wed, Jan 29, 2014 at 06:43:48PM +0100, Mattia Rizzolo wrote: Dear Maintainer, any chance to ge this applied? (or the patch in launchpad linked above, as you prefer) Hi, please see https://lists.debian.org/debian-devel/2014/01/msg00289.html Regards, Gerrit. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#734869: dash should drop its privileges in setuid context and implement privileged mode support (-p)
On Thu, Jan 16, 2014 at 10:01:22PM +0100, Raphael Hertzog wrote: On Fri, 10 Jan 2014, Jonathan Nieder wrote: Agreed, this is an important and good change (both upstream and for Debian). Thanks for reporting. Adding the forwarded tag doesn't bring much in this case as it's clear that upstream has not acted on this patch submission... Well, actually it makes it clear that the request and patch has been brought to upstream's attention. Who are the upstream maintainers that we should ping? Herbert Xu? Herbert Xu is upstream, yes. Do we have anyone in Debian with commit rights to the upstream repo? No. Regards, Gerrit. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#690473: Chroot setup failed: stage=setup-start
On Sat, Jan 04, 2014 at 04:24:12PM +, Roger Leigh wrote: block 684607 by 690473 thanks On Sun, Oct 14, 2012 at 08:59:27PM -0700, Jonathan Nieder wrote: tags 690473 + upstream patch quit Hi Roger, Roger Leigh wrote: dash: $ echo foo /dev/full [nothing] How about something like this patch? Many thanks for the patch. Gerrit, did anything ever happen in debian or upstream for this? It would be really nice to have a solution here, either a specific one like Jonathan proposes or even better a generic one which covers more error cases as mentioned by Jilles Tjoelker. Hi Roger, no, not yet. I'll try to look into it within the next days. Regards, Gerrit. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#682813: dbndns srv patch
On Tue, May 21, 2013 at 04:08:33PM -0400, Daniel Kahn Gillmor wrote: the following patch looks like a reasonably-minimal patch to add SRV support: http://tinydns.org/srv-patch Attached is a debdiff that applies it to 1:1.05-9~exp1, and works fine -- i'm happy to go ahead and upload this to experimental if that's ok with you, Gerrit. Hi Daniel, fine with me, go ahead if you like. Thanks, Gerrit. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#706786: git: please use source format 3.0 (quilt)
On Sat, May 04, 2013 at 03:21:43PM -0700, Jonathan Nieder wrote: When adding debian/README.source, I wanted to make a symlink, but the traditional source package format represents the debian/ directory with a unified diff so it wasn't possible. How about this patch? Hi Jonathan, since I'm quite inactive these days anyway, I think go ahead with nearly all suggestions you have. You have my trust. If possible, I'd still like to see the general packaging, patch and build process unchanged (i.e. not switching to debhelper, dpatch or the like). Thanks a lot for taking care of the packages that steadily and also the upstream work you do. Regards, Gerrit. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#686650: bcron update for stable
Hi,
as suggested by Jonathan below, I prepared a bcron package fixing
#686650 as candidate for the next squeeze point release. A debdiff is
attached, the package ready for upload.
Regards, Gerrit.
On Thu, Jan 17, 2013 at 11:42:08AM -, Jonathan Wiltshire wrote:
Package: bcron
Dear maintainer,
Recently you fixed one or more security problems and as a result you closed
this bug. These problems were not serious enough for a Debian Security
Advisory, so they are now on my radar for fixing in the following suites
through point releases:
squeeze (6.0.7) - use target stable
Please prepare a minimal-changes upload targetting each of these suites,
and submit a debdiff to the Release Team [0] for consideration. They will
offer additional guidance or instruct you to upload your package.
I will happily assist you at any stage if the patch is straightforward and
you need help. Please keep me in CC at all times so I can
track [1] the progress of this request.
For details of this process and the rationale, please see the original
announcement [2] and my blog post [3].
0: debian-rele...@lists.debian.org
1: http://prsc.debian.net/tracker/686650/
2: 201101232332.11736.th...@debian.org
3: http://deb.li/prsc
Thanks,
with his security hat on:
--
Jonathan Wiltshire j...@debian.org
Debian Developer http://people.debian.org/~jmw
4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC 74C3 5394 479D D352 4C51
diff -u bcron-0.09/debian/changelog bcron-0.09/debian/changelog
--- bcron-0.09/debian/changelog
+++ bcron-0.09/debian/changelog
@@ -1,3 +1,14 @@
+bcron (0.09-11+squeeze1) stable; urgency=high
+
+ * debian/diff/0008-bcron-exec-Mark-all-temporary-files-close-...diff:
+new; from upstream git; bcron-exec: Mark all temporary files
+close-on-exec and close selfpipe; this fixes a security bug in
+bcron where cron jobs get access to the temporary output files from
+all other jobs that are still running (CVE-2012-6110, closes:
+#686650).
+
+ -- Gerrit Pape p...@smarden.org Fri, 18 Jan 2013 03:21:49 +
+
bcron (0.09-11) unstable; urgency=low
* debian/bcron-run.postrm: services' supervise dirs are now located in
only in patch2:
unchanged:
---
bcron-0.09.orig/debian/diff/0008-bcron-exec-Mark-all-temporary-files-close-on-exec-and.diff
+++
bcron-0.09/debian/diff/0008-bcron-exec-Mark-all-temporary-files-close-on-exec-and.diff
@@ -0,0 +1,79 @@
+From 6b30379c3bcab65a6a21b5c7677e333dbc357cc3 Mon Sep 17 00:00:00 2001
+From: Bruce Guenter br...@untroubled.org
+Date: Fri, 5 Oct 2012 18:15:11 -0600
+Subject: [PATCH] bcron-exec: Mark all temporary files close-on-exec and
+ close selfpipe
+
+This fixes a security bug in bcron where cron jobs get access to the
+temporary output files from all other jobs that are still running.
+
+First reported in Debian:
+http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=686650
+
+Conflicts:
+ NEWS
+---
+ bcron-exec.c |3 +++
+ tests/exec-fds | 22 ++
+ 2 files changed, 25 insertions(+)
+ create mode 100644 tests/exec-fds
+
+diff --git a/bcron-exec.c b/bcron-exec.c
+index 2414bd8..ec6c641 100644
+--- a/bcron-exec.c
b/bcron-exec.c
+@@ -13,6 +13,7 @@
+ #include path/path.h
+ #include str/env.h
+ #include str/str.h
++#include unix/cloexec.h
+ #include unix/nonblock.h
+ #include unix/selfpipe.h
+ #include unix/sig.h
+@@ -106,6 +107,7 @@ static void exec_cmd(int fdin, int fdout,
+const str* env,
+const struct passwd* pw)
+ {
++ selfpipe_close();
+ dup2(fdin, 0);
+ close(fdin);
+ dup2(fdout, 1);
+@@ -205,6 +207,7 @@ static void start_slot(int slot,
+ return;
+ }
+ unlink(tmp.s);
++cloexec_on(fd);
+ gethostname(hostname, sizeof hostname);
+ wrap_str(str_copyns(tmp, 6, To: , mailto, \n,
+ From: Cron Daemon root@, hostname, \n));
+diff --git a/tests/exec-fds b/tests/exec-fds
+new file mode 100644
+index 000..f2c4a9f
+--- /dev/null
b/tests/exec-fds
+@@ -0,0 +1,22 @@
++doexec \
++ 'sleep 1; echo all done' \
++ 'echo here 4; echo here 5; echo here 6; echo here 7; echo here
8'
++result
++15:2^@KJob complete,15:1^@KJob complete,
++bcron-exec: (USER) CMD (sleep 1; echo all done)
++bcron-exec: (USER) CMD (echo here 4; echo here 5; echo here 6; echo
here 7; echo here 8)
++bcron-exec: Waiting for remaining slots to complete
++To: USER
++From: Cron Daemon root@HOST
++Subject: Cron USER@HOST echo here 4; echo here 5; echo here 6; echo
here 7; echo here 8
++
++/bin/sh: 1: 4: Bad file descriptor
++/bin/sh: 1: 5: Bad file descriptor
++/bin/sh: 1: 6: Bad file descriptor
++/bin/sh: 1: 7: Bad file descriptor
++/bin/sh: 1: 8: Bad file descriptor
++To: USER
++From: Cron Daemon root@HOST
++Subject: Cron USER@HOST sleep 1; echo all done
++
++all done
+--
+1.7.10.4
+
Bug#630581: #630581 prevent upgrades from Squeeze to Wheezy
On Mon, Sep 24, 2012 at 09:37:55AM +0200, Jérémy Bobbio wrote: This bug is a source of pain for anyone using the dropbear initramfs hook during upgrades from Squeeze to Wheezy. Gerrit, do you see any problems with the proposed patch? Hi Jéré, I didn't take a deeper look, actually the iniramfs integration was contributed and promised to be maintained by Chris deb...@x.ray.net, see http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=630581#25 but it looks like he disappeared. If you don't have time for an upload, would you be fine with an NMU to fix this issue? I'd be very fine with you fixing this through a NMU, thanks. Regards, Gerrit. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#686650: PATCH worked ok
On Fri, Sep 07, 2012 at 02:07:47PM +0600, Anton Khalikov wrote: Hello there, looks like the provided patch works ok: no complaints received. It has been tested on 7 production servers within 2 days. Thanks you very much, Anton. I'll take this upstream. Regards, Gerrit. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#678137: git-svn: filenames with spaces trip svn 1.7 assertion (svn_uri_is_canonical)
tags 678137 - wheezy quit On Tue, Jun 19, 2012 at 08:47:01AM -0500, Jonathan Nieder wrote: Package: git-svn Version: 1:1.7.2.5-3 Severity: serious Tags: wheezy sid experimental upstream Justification: ftbfs with Subversion = 1.7 Forwarded: http://thread.gmane.org/gmane.comp.version-control.git/184644 Hi Gerrit, Gerrit Pape wrote[1]: ok 1 - initialize git svn expecting success: git svn fetch svn: E235000: In file '/tmp/buildd/subversion-1.7.5/subversion/libsvn_subr/dirent_uri.c' line 2291: assertion failed (svn_uri_is_canonical(url, pool)) Good catch. Subversion 1.7.5 was just uploaded to the archive, and it is stricter than 1.6.y about pathnames containing spaces. Hi Jonathan, wheezy still has subversion 1.6.17dfsg-4, and I just checked, git 1.7.10.4-1 builds fine in a wheezy environment (pbuilder). So I remove the wheezy tag, please re-add it if I missed anything. Thanks, Gerrit. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
