Bug#945820: sysvinit_2.96-2_amd64.changes REJECTED

[Dmitry Bogatov]

[2019-11-29 09:49] Aurelien Jarno 
> On 2019-11-28 22:04, Debian FTP Masters wrote:
> > sysvinit-core_2.96-2_amd64.deb: has 2 file(s) with a timestamp too far in 
> > the past:
> >   usr/share/doc/sysvinit-core/copyright (Thu Jan  1 00:00:01 1970)  
> > usr/share/doc/sysvinit-c
> ore/changelog.Debian.gz (Thu Jan  1 00:00:01 1970)

I do not understand what happened. I did source-only upload, so I
believe .deb files are generated by buildd, not me.
-- 
Note, that I send and fetch email in batch, once in a few days.
Please, mention in body of your reply when you add or remove recepients.

Bug#945464: /lib/init/init-d-script: stop action: missing --oknodo in s-s-d invocation

[Dmitry Bogatov]

control: tags -1 +confirmed

[2019-11-25 12:06] Jan Braun 
> Dear Maintainer,
>
> The /lib/init/init-d-script errorneously returns failure when asked to
> stop a non-running service:
> [...]
>
> And indeed, one call to start-stop-daemon in /lib/init/init-d-script is
> missing the --oknodo flag. Namely, the first call in the stop action:
> [...]
> Adding --oknodo in line 76 (line 2 in the quote) should fix this bug.

Thank you very much for your detailed analysis. I included --oknodo flag
as you suggested. Unless there is objections in upcoming few days, I
will upload it.

> Additionally, I'd like to point out that the calculation of the return
> code in this function seems fishy to me: it will always be the return
> code of the first s-s-d invocation, unless the second invocation returns
> 2 (which aiui means "a process survived SIGKILL" in this context).
> Wouldn't taking the maximum (or sum) of the two return codes be more
> sensible?

Sum is definitely not apporiate, since there is standard that specifies
meanings of error codes of init.d script[^1]. But you raise valid point,
and it is not clear to me why exit code 2 is handled specially.

Also, returning 2 should mean "invalid or excess argument(s)",
which is not the case.  Should't we return exit code 1 in all cases when
s-s-d fails?

Collegues, opinions? Maybe anybody remember why it was done this way?

 [^1]: 
https://fedoraproject.org/wiki/EPEL:SysVInitScripts?rd=Packaging:SysVInitScript
-- 
Note, that I send and fetch email in batch, once in a few days.
Please, mention in body of your reply when you add or remove recepients.

Bug#939733: lsb-release: lsb_release does not show point release on Debian 10.1

[Dmitry Bogatov]

[2019-11-10 02:31] Santiago Vila 
> > I am losing context. We have at least following three files (oh, why all
> > this madness?):
> > 
> >  * /usr/lib/os-release
> >  * /etc/os-release
> >  * /etc/debian_version
> > 
> > So, in case of conflicts, what should override what?
>
> Please note that /usr/lib/os-release and /etc/os-release are the same file.

Thank you for your patience.

> AFAIK, lsb-release is already ignoring /etc/debian_version in buster,
> which is the reason we have this problem.

Not exactly. We have following code, where get_os_release() reads
"/usr/lib/os-release", and guess_debian_release() uses several other
files, including "/etc/debian_version".

lsbinfo = get_os_release()
# OS is only used inside guess_debian_release anyway
for key in ('ID', 'RELEASE', 'CODENAME', 'DESCRIPTION',):
if key not in lsbinfo:
distinfo = guess_debian_release()
distinfo.update(lsbinfo)
return distinfo
 else:
 return lsbinfo

So /etc/os-release overrides /etc/debian_version. Probably, we could
drop guess_debian_release() code though, since base-files are essential.

> b) As it has been suggested by you, fixing the problem in base-files
> by including the minor version in /etc/os-release "somewhere".
>
> I am ok with doing the change in base-files, because I believe it's
> the best option in the long term.
>
> I also believe that it would suffice to change VERSION_ID, but I need
> confirmation for that.
> [..]
>
> So: Is this ok for you?

Yes, that is fine. As I just checked, `lsb_release -d` (as is in
Archives) will happily output anything I put into VERSION_ID variable of
/etc/os_release.
-- 
Note, that I send and fetch email in batch, once in a few days.
Please, mention in body of your reply when you add or remove recepients.

Bug#939733: lsb-release: lsb_release does not show point release on Debian 10.1

[Dmitry Bogatov]

control: tags -1 +help

[2019-11-08 13:42] Santiago Vila 
> Hi.
>
> I've asked the Release Managers about this here:
>
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=944351
>
> If they say yes, I'll modify base-files accordingly (for Debian 10.2).
>
> If they say no, please be ready to fix the bug in lsb-release as soon
> as you can, by making an upload to proposed-updates (there is a point
> release around the corner).

I am losing context. We have at least following three files (oh, why all
this madness?):

 * /usr/lib/os-release
 * /etc/os-release
 * /etc/debian_version

So, in case of conflicts, what should override what?

BTW, help via NMU/Team upload is welcome.
-- 
Note, that I send and fetch email in batch, once in a few days.
Please, mention in body of your reply when you add or remove recepients.

Bug#941273: marked as pending in runit

[Dmitry Bogatov]

Control: tag -1 pending

Hello,

Bug #941273 in runit reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/debian/runit/commit/166d6052c62b8178910ae3ebbdb6a9c65a67dd11


Temporary disable forced-rescan test

Closes: #941273


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/941273

Bug#939733: lsb-release: lsb_release does not show point release on Debian 10.1

[Dmitry Bogatov]

control: severity -1 +normal

[2019-09-10 10:21] Jonathan Wiltshire 
> >> The x.y there was a remnant from Debian sarge times.
> > 
> > Up until squeeze I have seen it show x.y.z, then from wheezy to
> > stretch I see only x.y, but it does seem new behaviour in buster to
> > only show x.
> > 
> > $ ansible '*' -i inventories/testing -a 'lsb_release -d' | grep ^Descr | 
> > sort -u
> > Description:Debian GNU/Linux 10 (buster)
> > Description:Debian GNU/Linux 8.11 (jessie)
> > Description:Debian GNU/Linux 9.10 (stretch)
>
> This stems from lsb_release switching to reading the cross-distro
> standard file, /usr/lib/os-release:
>
> | $ cat /etc/debian_version
> | 10.1
> | $ cat /usr/lib/os-release
> | PRETTY_NAME="Debian GNU/Linux 10 (buster)"
> | NAME="Debian GNU/Linux"
> | VERSION_ID="10"
> | VERSION="10 (buster)"

As pointed by maintainer of base-files, this format of
/usr/lib/os-release is with us for some time (just checked on stretch
box).

In theory, I can revert #914287, but is it good thing? Actually, I fail
to see the whole point of `lsb_release` command. You can't squash all
information in your /etc/apt/sources.list into two digits.

This said, I feel current behaviour more logical. LSB pretends to
provide cross-distributions interface, so reading /usr/lib/os-release
feels more natural than /etc/debian_release.
-- 
Note, that I send and fetch email in batch, once in a few days.
Please, mention in body of your reply when you add or remove recepients.

Bug#938952: [debian Buster] [arm64 pinebook] [sysvinit-core] libsoup2.4-1 : Depends: glib-networking (>= 2.32.0) but it is not going to be installed

[Dmitry Bogatov]

[2019-09-08 17:53] Jean-Marc LACROIX 
>  > Please:
>  >
>  >   * Try installing something else, like `tor'. I expect you will get
>  > similar error (`tor' depends on libsystemd0, sigh)
>
> ansible@pinebook:~$ sudo apt install tor
> [...]

Okay, tor installs fine with your apt-pinning. My guess was wrong.

> ansible@pinebook:~$ dpkg -l |grep -v ii
> Desired=Unknown/Install/Remove/Purge/Hold
> | 
> Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
> |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
> ||/ NameVersion 
>  Architecture Description
> +++-===---===
> 
> ansible@pinebook:~$ dpkg -l |grep systemd
> ii  dbus-user-session 
> 1.12.16-1arm64simple interprocess messaging 
> system (systemd --user integration)
> ii  libpam-systemd:arm64241-5 
>  arm64system and service manager - PAM module
> ii  libsystemd0:arm64   241-5 
>  arm64systemd utility library
> ii  syslog-ng-mod-journal   3.19.1-5 
>  arm64Enhanced system logging daemon 
> (systemd journal plugin)
> ii  systemd 241-5 
>  arm64system and service manager
> ii  systemd-sysv241-5 
>  arm64system and service manager - SysV links

Okay, on this stage you have systemd as pid1 implementation.

> [...]
> Now, according Debian doc, i try to install sysvinit

Which exactly doc? I guess it needs to be adjusted.

> ansible@pinebook:~$ sudo apt install sysvinit sysvinit-utils
> Reading package lists... Done
> Building dependency tree
> Reading state information... Done
> Package sysvinit is not available, but is referred to by another package.
> This may mean that the package is missing, has been obsoleted, or
> is only available from another source
> However the following packages replace it:
>sysvinit-core:armhf systemd-sysv:armhf sysvinit-core systemd-sysv
>
> E: Package 'sysvinit' has no installation candidate
>
> It seems on Debian 10.1, there is now one new package name ?
> [...]

There were no package renaming at least last year.

> ansible@pinebook:~$ sudo apt install sysvinit-core sysvinit-utils
> Reading package lists... Done
> Building dependency tree
> Reading state information... Done
> sysvinit-utils is already the newest version (2.93-8).
> Some packages could not be installed. This may mean that you have
> requested an impossible situation or if you are using the unstable
> distribution that some required packages have not yet been created
> or been moved out of Incoming.
> The following information may help to resolve the situation:
>
> The following packages have unmet dependencies:
>   dconf-service : Depends: default-dbus-session-bus or
>dbus-session-bus
>   libsoup2.4-1 : Depends: glib-networking (>= 2.32.0) but it is not 
> going to be installed
> E: Error, pkgProblemResolver::Resolve generated breaks, this may be 
> caused by held packages.

Wait, do you have installation of "recommends" disabled? If I try to
install "dconf-service" on my system (antiX + Devuan + Debian,
pid1=runit-init), I too get resolution error, but

 # apt-get install dconf-service --no-install-recommends

resolves fine. Please, try this. Otherwise, your better bet would
be to reassign to libelogind or dbus or something like this.
sysvinit-core only depends on libc and libselinux (sigh), so it can't
cause conflicts with packages you show.
-- 
Note, that I send and fetch email in batch, once in a few days.
Please, mention in body of your reply when you add or remove recepients.

Bug#938952: [debian Buster] [arm64 pinebook] [sysvinit-core] libsoup2.4-1 : Depends: glib-networking (>= 2.32.0) but it is not going to be installed

[Dmitry Bogatov]

control: tags -1 +moreinfo

[2019-08-30 16:44] Jean-Marc LACROIX 
> Package: sysvinit
> Version: 2.93-8
> Severity: grave
>
> Dear maintainers,
>
> It seems there is a dependency issue when installing sysvinit-core as 
> indicated in following trace
> [...]
> Package: *systemd*
> Pin: release *
> Pin-Priority: -1

I think problem is here. *systemd* matches `libsystemd0`, and given that
even apt depends on `libsystemd0`, you are unlikely to solve any
dependency.

Please:

 * Try installing something else, like `tor'. I expect you will get
   similar error (`tor' depends on libsystemd0, sigh)
 * Replace `*systemd*' with `systemd' (without wildcard) in your
   apt-pinnings and try installing sysvinit-core again.
-- 
Note, that I send and fetch email in batch, once in a few days.
Please, mention in body of your reply when you add or remove recepients.

Bug#932073: closed by Niels Thykier (Bug#932073: fixed in debhelper 12.2.1)

[Dmitry Bogatov]

control: tags -1 +confirmed

[2019-07-17 07:41] Helmut Grohne 
> part   text/plain1094
> Control: reopen -1
> Control: affects -1 + src:dropbear
>
> On Tue, Jul 16, 2019 at 08:42:09PM +, Debian Bug Tracking System wrote:
> >* dh_installinit: Fix regression where dh_installinit bailed
> >  out on --name if only one of the acted on packages had an
> >  init script file.  Thanks to Helmut Grohne for reporting
> >  the issue.  (Closes: #932073)
>
> The bug is partially fixed. A full build of openssh and dropbear now
> works. At least the following situation (dropbar) is still broken:
>
> The init script lives in an arch-all package, you pass the relevant
> --name and you perform an arch-only build. Here is a cross build log,
> but it fully reproduces natively:

Yep, -A/-B separation. Can someone remind me its purpose?

As for code, then instead of "$dh{DOPACKAGES}" there must be
"getpackages()", like this. Not sure how to write regression test for
this situation.

diff --git a/dh_installinit b/dh_installinit
index 5aecf25b..6a7abaf8 100755
--- a/dh_installinit
+++ b/dh_installinit
@@ -233,7 +233,7 @@ init(options => {
 my %snippet_options = ('snippet-order' => 'service');
 
 if (my $name = $dh{NAME}) {
-   if (!grep { -f "debian/$_.${name}.init" || -f 
"debian/$_.${name}.default" } @{$dh{DOPACKAGES}}) {
+   if (!grep { -f "debian/$_.${name}.init" || -f 
"debian/$_.${name}.default" } getpackages()) {
error("--name=$dh{NAME} option specified, but init script nor 
default file not found");
}
 }

-- 
Note, that I send and fetch email in batch, once in a few days.
Please, mention in body of your reply when you add or remove recepients.

Bug#932339: Building of test packages hangs in Lintian due to commit 789eb18b

[Dmitry Bogatov]

[2019-07-17 19:24] Felix Lechner 
> Hi,
>
> Updating from version 12.1.1 in testing to 12.2.2 breaks the build
> process for test packages in Lintian. The unstable pipelines on
> jenkins and Gitlab are failing.
>
> The command 't/bin/build-test-packages' in Lintian runs for a while
> but then hangs. Some of the processes that build test packages in
> parallel may not terminate. The command also stalled when using
> '--jobs=1'. I was unable to locate an error message.
>
> The issue is caused by commit 789eb18b, which was found through
> bisection.

This change can't hang debhelper -- it adds no loops. But it can cause
debhelper errorneously fail (see #932073).  This extra check was added
in 12.2. Maybe it matters.

But if this conjecture is true, it is strange that bisection found
789eb18b guilty, but not e5fc959, which produces even more erroneous
failures.
-- 
Note, that I send and fetch email in batch, once in a few days.
Please, mention in body of your reply when you add or remove recepients.

Bug#932073: dh_installinit fails with "--name=foo option specified, but init script not found"

[Dmitry Bogatov]

[2019-07-14 17:59] Niels Thykier 
> > debhelper 12.2 fixes #462389 and makes dh_installinit fail when the
> > --name'd init script does not exist. This behaviour change makes at
> > least openssh and util-linux FTBFS. These are two high popcon example
> > packages. I expect more.
> > [...]
> > 
> > It is unclear to me whether it can be fixed in debhelper at all. Yet I
> > am filing the bug to have something recorded. If you determine that this
> > should be fixed in the individual packages, please clone and reassign.
> > 
> > Helmut
> > 
>
> Hi Dmitry,
>
> This report seems to be a regression related to your patch from #462389.

Definitely regression.

From a7288f30a003759b186389b93d336bef90491062 Mon Sep 17 00:00:00 2001
From: Dmitry Bogatov 
Date: Mon, 15 Jul 2019 16:08:01 +
Subject: [PATCH] Fix logic error in --name sanity check

Commit [e5fc959e], resolving #462389 changed behaviour of `--name' option of
dh_installinit. Before this change, if `debian/{package}.{name}.init' is 
missing,
this option was silently ignored. This change made it error.

This change was incorrect, since it demanded presence of 
`debian/{package}.{name}.init'
file for /every/ binary package.

This commit instead throws error only if `debian/{package}.{name}.init' does
not exist for /all/ binary {package} names. Regression test is added.

Closes: #932073
---
 dh_installinit | 10 ++
 t/dh_installinit/debian/bar.other.init |  4 
 t/dh_installinit/dh_installinit.t  |  2 ++
 3 files changed, 12 insertions(+), 4 deletions(-)
 create mode 100644 t/dh_installinit/debian/bar.other.init

diff --git a/dh_installinit b/dh_installinit
index 6a490370..cd038af1 100755
--- a/dh_installinit
+++ b/dh_installinit
@@ -232,6 +232,12 @@ init(options => {
 
 my %snippet_options = ('snippet-order' => 'service');
 
+if (my $name = $dh{NAME}) {
+   if (!grep { -f "debian/$_.${name}.init" } @{$dh{DOPACKAGES}}) {
+   error("--name=$dh{NAME} option specified, but init script not 
found");
+   }
+}
+
 foreach my $package (@{$dh{DOPACKAGES}}) {
my $tmp=tmpdir($package);
 
@@ -311,10 +317,6 @@ foreach my $package (@{$dh{DOPACKAGES}}) {
my $init=pkgfile($package,$scriptsrc) || pkgfile($package,"init") ||
pkgfile($package,"init.d");
 
-   if (!$init && defined $dh{NAME}) {
-   error("--name=$dh{NAME} option specified, but init script not 
found");
-   }
-
if ($init ne '' && ! $dh{ONLYSCRIPTS}) {
install_dir("$tmp/etc/init.d");
install_prog($init,"$tmp/etc/init.d/$script");
diff --git a/t/dh_installinit/debian/bar.other.init 
b/t/dh_installinit/debian/bar.other.init
new file mode 100644
index ..ea948c58
--- /dev/null
+++ b/t/dh_installinit/debian/bar.other.init
@@ -0,0 +1,4 @@
+#!/bin/sh
+cat << 'EOF'
+I am init script to be installed into package "bar" into /etc/init.d/other 
path.
+EOF
\ No newline at end of file
diff --git a/t/dh_installinit/dh_installinit.t 
b/t/dh_installinit/dh_installinit.t
index afe3821f..3b6bc038 100755
--- a/t/dh_installinit/dh_installinit.t
+++ b/t/dh_installinit/dh_installinit.t
@@ -12,6 +12,7 @@ our @TEST_DH_EXTRA_TEMPLATE_FILES = (qw(
 debian/changelog
 debian/control
 debian/foo.service
+debian/bar.other.init
 ));
 
 plan(tests => 2);
@@ -30,6 +31,7 @@ each_compat_from_and_above_subtest(11, sub {
 
ok(run_dh_tool('dh_installinit'));
ok(! run_dh_tool({'quiet' => 1}, 'dh_installinit', '--name=missing'));
+   ok(  run_dh_tool({'queit' => 1}, 'dh_installinit', '--name=other'));
ok(! -e "debian/foo/lib/systemd/system/foo.service");
ok(!find_script('foo', 'postinst'));
ok(run_dh_tool('dh_clean'));


-- 
Note, that I send and fetch email in batch, once in a few days.
Please, mention in body of your reply when you add or remove recepients.

Bug#929709: libgdbm6: file exists in libgdbm-dev as well as gdbm

[Dmitry Bogatov]

control: severity -1 minor

[2019-05-29 13:31] lkcl 
> Package: libgdbm6
> Version: 1.18.1-4
> Severity: serious
> Justification: 2
>
> Unpacking libgdbm-dev:amd64 (1.18.1-4) ...
> dpkg: error processing archive 
> /var/cache/apt/archives/libgdbm-dev_1.18.1-4_amd64.deb (--unpack):
>  trying to overwrite '/usr/share/info/gdbm.info.gz', which is also in package 
> libgdbm3:amd64 1.8.3-11
> Errors were encountered while processing:
>  /var/cache/apt/archives/libgdbm-dev_1.18.1-4_amd64.deb

Issue, yes. But you are upgrading from rather old version of libgdbm3.
According to https://tracker.debian.org/gdbm, it predates even
old-stable.

Since Debian does not support skip upgrades, this issue is not
release-critical. Downgrading severity.

I just checked in virtual machine, upgrade stable (1.8.3-14) -> testing
(1.18.1-4) seems fine. Please, consider upgrading gradually.

I doubt that release team would approve unblock for issue of upsupported
upgrade, sorry.
-- 
Note, that I send and fetch email in batch, once every 24 hours.
 If matter is urgent, try https://t.me/kaction
 --

Bug#927442: Bug #927442 in runit marked as pending

[Dmitry Bogatov]

Control: tag -1 pending

Hello,

Bug #927442 in runit reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/debian/runit/commit/6c03140f5fd199c2cb5162ae3eb68dac1cf6a542


Fix preinst script on fresh installation

Closes: #927442


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/927442

Bug#927442: Bug #927442 in runit marked as pending

[Dmitry Bogatov]

Control: tag -1 pending

Hello,

Bug #927442 in runit reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/debian/runit/commit/9faee1d81353fb3d49e3fbcc3fb6b74de04729eb


Fix preinst script on fresh installation

Closes: #927442


(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/927442

Bug#919296: git-daemon-run: fails with 'warning: git-daemon: unable to open supervise/ok: file does not exist'

[Dmitry Bogatov]

[2019-03-16 00:41] Lorenzo Puliti 
> >Bogatov wrote:
> >Dear git maintainer, you could plug this bug by adding
> >`/var/lib/supervise/git-daemon' into `debian/git-daemon-run.dirs'.
>
> Dmitry, are you sure? runsv can create the 'git-daemon' directory if 
> it's not there, and a dangling symlink won't stop it.
> You can do a test:
> # update-service --remove /etc/sv/git-daemon
> # rm -r /var/lib/supervise/git-daemon
> # update-service --add /etc/sv/git-daemon
> wait at least 5 seconds, than do
> # sv term git-daemon

You are right. Not sure why creating directory fixed issue for me, but
probably I should do less of testing on live system and do more of
clean-room testing.
-- 
Note, that I send and fetch email in batch, once every 24 hours.
 If matter is urgent, try https://t.me/kaction
 --

Bug#924327: directfb FTBFS for armel,armhf: error: implicit declaration of function 'makedev'

[Dmitry Bogatov]

[2019-03-11 17:55] Helmut Grohne 
> directfb has build failures. A cross build for armel fails:
>
> |   mknod( C64X_DEVICE, 0666 | S_IFCHR, makedev( 400, 0 ) );

I encountered similar error on one of my packages recently (can't
remember which one). It was due upgrade to glibc-2.28 and missing

#include 

Sorry, can't check on arm* architectures.
-- 
Note, that I send and fetch email in batch, once every 24 hours.
 If matter is urgent, try https://t.me/kaction
 --

Bug#921558: lsb-base: killproc does not pass name parameter to start-stop-daemon

[Dmitry Bogatov]

[2019-03-11 21:51] Axel Beckert 
> > I believe it would be reasonable to add '--name $base' into `else'
> > clause. Opinions?
>
> Sounds sane, I just checked that with #924311 (miredo, uses
> start-stop-daemon directly, edited the init script) as well as #924312
> (stunnel4, by editing /lib/lsb/init-functions) and it worked in both
> cases.
>
> Here's the change I made to /lib/lsb/init-functions (as Dmitry already
> suggested):

Okay. Should I NMU or not? Anybody know what is the current status of
maintenance?

> --- /lib/lsb/init-functions~2018-11-28 20:21:37.0 +0100
> +++ /lib/lsb/init-functions 2019-03-11 21:46:41.673767215 +0100
> @@ -141,7 +141,7 @@
>  if [ ! $pidfile ]; then
>  name_param="--name $base --pidfile /var/run/$base.pid"
>  else
> -name_param="--pidfile $pidfile"
> +name_param="--name $base --pidfile $pidfile"
>  fi
>  
>  sig=$(echo ${2:-} | sed -e 's/^-\(.*\)/\1/')
-- 
Note, that I send and fetch email in batch, once every 24 hours.
 If matter is urgent, try https://t.me/kaction
 --

Bug#921558: lsb-base: killproc does not pass name parameter to start-stop-daemon

[Dmitry Bogatov]

control: tags -1 +moreinfo

[2019-02-06 20:20] Andreas Metzler 
> Package: lsb-base
> Version: 10.2018112800
> Severity: serious
>
> Hello,
>
> there is a logic error in /lib/lsb/init-functions's killproc:
>
> base=${1##*/}
> if [ ! $pidfile ]; then
> name_param="--name $base --pidfile /var/run/$base.pid"
> else
> name_param="--pidfile $pidfile"
> fi
>
> The if clause checks for nonempty $pidfile instead of nonempty $base to
> decide whether --name is used.
>
> Also --pidfile $pidfile is always used, even when $pidfile is empty.
>
> I am reportig this as serious since sid's start-stop-daemon requires a
> name parameter in addition to --pidfile when the pidfile is not owned by
> root, therefore this bug causes init script failures. (#921205)

[ I am not familiar with src:lsb, but I need this issue resolved fixed
  to keep src:sysvinit suitable for Buster. By the way, sysvinit does
  not use killproc. ]

I believe it would be reasonable to add '--name $base' into `else'
clause. Opinions?

PS. Dear maintainer, are you still willing to give-up maintainership of
src:lsb ( comment in 888743)?
-- 
Note, that I send and fetch email in batch, once every 24 hours.
 If matter is urgent, try https://t.me/kaction
 --

Bug#923609: proposed solution

[Dmitry Bogatov]

[2019-03-08 22:40] Niko Tyni 
> On Fri, Mar 08, 2019 at 02:39:53PM +0000, Dmitry Bogatov wrote:
>  
> > I believe this patch would somewhat solve issue. Dear submitter, can you
> > please apply this patch, build package and check, that `gdbm_load-nolfs'
> > binary from created bin:gdbmtool does sensible thing?
>
> Thanks. It doesn't quite work as-is, because 'future=+all' in
> DEB_BUILD_MAINT_OPTIONS still pulls the LFS flags in the build. But if
> I take that away, it works at least for my trivial databases (both GDBM
> and NDBM). I'll try to test a bit more later.

Good. Try this version of patch, please. It seems to works for me in my
i386 chroot.

> It would make sense to limit this to 32-bit architectures as I believe the
> 64-bit architectures always have LFS support no matter the build flags.

I'd leave it as-is. Yes, it may be redundant on 64 bit platforms, but it
will go away rather soon anyway. I'd rather not complicate `debian/rules'.

> Shipping these -nolfs binaries and including instructions for upgrading
> databases in the Buster release notes would be an acceptable fix for
> this issue IMO.

Good.

By the way, should I file bug aganist release.debian.org now, or when we
are settled on solution?

From 8a76aafea8096d71a72ee16596c3cfaa12e0f291 Mon Sep 17 00:00:00 2001
From: Dmitry Bogatov 
Date: Thu, 7 Mar 2019 20:19:11 +
Subject: [PATCH] Provide version with LFS support disabled

---
 debian/rules | 9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/debian/rules b/debian/rules
index fce1572..78eeb73 100755
--- a/debian/rules
+++ b/debian/rules
@@ -1,6 +1,6 @@
 #!/usr/bin/make -f
 export LC_ALL = C
-export DEB_BUILD_MAINT_OPTIONS = hardening=+all future=+all reproducible=+all
+export DEB_BUILD_MAINT_OPTIONS = hardening=+all reproducible=+all
 include /usr/share/dpkg/default.mk
 
 # Upstream source code in src/version.c uses __DATE__ and __TIME__
@@ -35,21 +35,26 @@ ifeq ($(HAVE_DIETLIBC),yes)
--libdir $(DIET_LIBDIR) \
--disable-shared \
--enable-static \
+   --enable-largefile \
--enable-memory-mapped-io=no \
CC='diet gcc' CPPFLAGS='-UHAVE_MMAP'
 endif
-   dh_auto_configure -B glibc-build -- --enable-libgdbm-compat
+   dh_auto_configure -B glibc-build -- --enable-libgdbm-compat 
--enable-largefile
+   dh_auto_configure -B glibc-nolfs-build -- \
+   CFLAGS='-static' --program-suffix=-nolfs --disable-largefile
 
 override_dh_auto_build:
 ifeq ($(HAVE_DIETLIBC),yes)
dh_auto_build -B diet-build
 endif
dh_auto_build -B glibc-build
+   dh_auto_build -B glibc-nolfs-build
 
 override_dh_auto_install:
 ifeq ($(HAVE_DIETLIBC),yes)
dh_auto_install -B diet-build
 endif
+   dh_auto_install -B glibc-nolfs-build
dh_auto_install -B glibc-build
 
 ifeq ($(HAVE_DIETLIBC),yes)
-- 
Note, that I send and fetch email in batch, once every 24 hours.
 If matter is urgent, try https://t.me/kaction
 --

Bug#923957: /lib/runit/run_sysv_scripts shouldn't use 'sh -e'

[Dmitry Bogatov]

control: severity -1 important

[2019-03-07 17:21] Andras Korn 
> The supplied "/etc/runit/1" calls "/lib/runit/run_sysv_scripts /etc/rcS.d"
> during boot.
>
> /lib/runit/run_sysv_scripts runs under "sh -eu", which has the effect that
> if any initscript exits unsuccesfully, all subsequent scripts are skipped.
>
> This can lead to, for example, the "networking" initscript not being
> started, which then results in no connectivity for the box and thus no way
> to log in remotely. (This is my justification for the 'critical' severity:
> "breaks the entire system".)

Downgrading severity, since "breaks the entire system" happens only in
very specific configuration -- script before 'networking' fails /and/
box is inaccessible without network.

> I think runit-init should do what /etc/init.d/rc does: log failures and
> continue.

Reasonable. Will fix.
-- 
Note, that I send and fetch email in batch, once every 24 hours.
 If matter is urgent, try https://t.me/kaction
 --

Bug#923609: proposed solution

[Dmitry Bogatov]

I believe this patch would somewhat solve issue. Dear submitter, can you
please apply this patch, build package and check, that `gdbm_load-nolfs'
binary from created bin:gdbmtool does sensible thing?

By the way, can I somehow help to make autopkgtests on !amd64 happen?

From dbbe906795dd977ed16cccaa7b0385ce8654c8a5 Mon Sep 17 00:00:00 2001
From: Dmitry Bogatov 
Date: Thu, 7 Mar 2019 20:19:11 +
Subject: [PATCH] Provide version with LFS support disabled

---
 debian/rules | 4 
 1 file changed, 4 insertions(+)

diff --git a/debian/rules b/debian/rules
index fce1572..03b6242 100755
--- a/debian/rules
+++ b/debian/rules
@@ -39,17 +39,21 @@ ifeq ($(HAVE_DIETLIBC),yes)
CC='diet gcc' CPPFLAGS='-UHAVE_MMAP'
 endif
dh_auto_configure -B glibc-build -- --enable-libgdbm-compat
+   dh_auto_configure -B glibc-nolfs-build -- \
+   CFLAGS='-static' --program-suffix=-nolfs --disable-largefile
 
 override_dh_auto_build:
 ifeq ($(HAVE_DIETLIBC),yes)
dh_auto_build -B diet-build
 endif
dh_auto_build -B glibc-build
+   dh_auto_build -B glibc-nolfs-build
 
 override_dh_auto_install:
 ifeq ($(HAVE_DIETLIBC),yes)
dh_auto_install -B diet-build
 endif
+   dh_auto_install -B glibc-nolfs-build
dh_auto_install -B glibc-build
 
 ifeq ($(HAVE_DIETLIBC),yes)
-- 
Note, that I send and fetch email in batch, once every 24 hours.
 If matter is urgent, try https://t.me/kaction
 --


pgp49H8gGpqHE.pgp
Description: PGP signature

Bug#923609: Binary incompatibility in libgdbm6

[Dmitry Bogatov]

[2019-03-05 17:44] Sergey Poznyakoff 
> Hello,
>
> Investigation of the attached file has shown that it has been created
> by gdbm 1.8.3 compiled without large file support (sizeof(off_t) == 4).
> In contrast, gdbm 1.18.1 was compiled with large file support enabled,
> which naturally lead to the observed behavior. Recompile it with the
> --disable-largefile flag and it will be able to read the file.

Thank you, Sergey. Does incompatibility goes other way too, that version
without LFS support is incapable of reading file, created with LFS
version?

I consider providing statically-linked, LFS-disabled version of
gdbm_{load,dump,tool}, so user with database, created on stretch could
do `gdbm_dump old.gdbm | gdbm_load new.gdbm'. Opinions?

Oh, we may need to ask release team, for we are too close to hard-freeze.
-- 
Note, that I send and fetch email in batch, once every 24 hours.
 If matter is urgent, try https://t.me/kaction
 --

Bug#923609: Binary incompatibility in libgdbm6

[Dmitry Bogatov]

control: tags -1 +upstream +forwarded

Hello!

Can you please take a look at this Debian bug report [1]. It seems that
compatibility issues we discussed before and which were believed to
resolved in release 1.18.1 actually still present.

Reporter kindly provided receipe to reproduce issue and example of
problematic database.

Thank you for developing gdbm.

 [1] https://bugs.debian.org/923609
-- 
Note, that I send and fetch email in batch, once every 24 hours.
 If matter is urgent, try https://t.me/kaction
 --
--- Begin Message ---
Package: libgdbm6
Version: 1.18.1-3
Severity: serious
Control: block 923238 with -1

GDBM databases created on stretch (gdbm 1.8.3-14) are not
compatible with libgdbm in sid/buster (1.18.1-3) on at least
the i386 (32-bit x86) architecture, probably also armhf.

This means that any local user databases will break on upgrade from
stretch to buster. It also breaks a few Debian packages that use GDBM
files (known affected are libmarc-charset-perl and command-not-found).

Bug #910911 discussed a similar problem that applied to all architectures.
It seems probable that the fix for that never worked on i386 but this
was just not detected earlier. The incompatibility was reported recently
in bug #923238 and was found because Ubuntu has a better architecture
coverage on their autopkgtest setup.

Below are steps to reproduce, testing with Python 2, Python 3, and Perl.
We make a trivial GDBM database with each, containing just one key "foo"
with the value "bar". After upgrading to buster on i386, none of these
databases can be read and "Malformed database file header" is reported.
On amd64, everything works fine after the upgrade.

# start from stretch
# apt install python-gdbm python3-gdbm perl

python - <<'EOF'
import gdbm   
gdbm.open("py2-stretch.gdbm", "c")["foo"] = "bar"
EOF

python3 <<'EOF'
import dbm.gnu
dbm.gnu.open("py3-stretch.gdbm", "c")["foo"] = "bar"
EOF

perl <<'EOF'
use GDBM_File;
tie %h,  q(GDBM_File), "perl-stretch.gdbm", _WRCREAT, 0640
  or die "opening GDBM file failed: $!";
$h{foo} = "bar"
EOF

# ls -l *.gdbm
-rw-r- 1 root root 12294 Mar  2 19:04 perl-stretch.gdbm
-rw-r--r-- 1 root root 12294 Mar  2 19:04 py2-stretch.gdbm
-rw-r--r-- 1 root root 12294 Mar  2 19:04 py3-stretch.gdbm

# upgrade to buster
# sed -i s/stretch/buster/ /etc/apt/sources.list && apt update && apt 
dist-upgrade && apt install gdbmtool

# test with gdbmtool
# gdbmtool py2-stretch.gdbm fetch foo
gdbmtool: stdin:1.1-10: cannot open database py2-stretch.gdbm: Malformed 
database file header
# gdbmtool py3-stretch.gdbm fetch foo
gdbmtool: stdin:1.1-10: cannot open database py3-stretch.gdbm: Malformed 
database file header
# gdbmtool perl-stretch.gdbm fetch foo
gdbmtool: stdin:1.1-10: cannot open database perl-stretch.gdbm: Malformed 
database file header

# similar results with any of these:

perl <<'EOF'
use GDBM_File;
 tie %h,  q(GDBM_File), "perl-stretch.gdbm", _READER, 0640
  or die "opening GDBM file failed: $!";
print $h{foo}, "\n";
EOF

python <<'EOF'
import gdbm
print(gdbm.open("py2-stretch.gdbm", "r")["foo"])
EOF

python3 <<'EOF'
import dbm.gnu 
print(dbm.gnu.open("py3-stretch.gdbm", "r")["foo"])
EOF

-- 
Niko Tyni   nt...@debian.org

--- End Message ---

Bug#923238: libmarc-charset-perl: needs a rebuild on 32bit architectures?

[Dmitry Bogatov]

`
[2019-02-28 18:01] Niko Tyni 
> > > But ideally gdbm would restore compatibility and libmarc-charset-perl 
> > > would
> > > not need any changes.
> > 
> > I believe upstream release 1.8.1 introduced change, that
> > made it possible to read old /usr/lib/libmarc-charset-perl/Table. Am I
> > missing something in current situation?
>
> I thought so too, but this new bug highlights the fact that the fix
> does not work on all architectures.  This was missed earlier because
> Debian does not have autopkgtest checks on !amd64, so we're relying
> on user bug reports and haven't got any so far.
>
> I've now verified that creating GDBM files with Perl, Python 2 or Python 3
> on stretch i386 and then upgrading to buster renders the old databases
> unusable with the corresponding software in buster.
>
> I can file a separate bug against src:gdbm if that makes things clearer.

Yes, it would help. Please include as much details, as possible,
including database created on stretch-i386. It would speed-up
communication with upstream.

> > By the way, I disagree about compability. If all we need to make
> > everything good is just a binNMU, I'd rather not introduce any
> > patches/hacks/compatibility layers/etc.
>
> binNMU'ing libmarc-charset-perl will only fix libmarc-charset-perl,
> not unpackaged local user databases. If those become unusable on
> stretch -> buster upgrades with no way to recover them, that seems
> like a major problem.
>
> binNMU'ing libmarc-charset-perl does not fix partial upgrades where
> perl that uses a newer libgdbm is upgraded before  libmarc-charset-perl.
> Hence the need for Breaks and versioned build dependencies that I listed.

Ah, I see. Yes, breaking user databases would not be nice.

> > By the way, it is sad that libmarc-charset-perl uses gdbm, not cdb.
> Are you referring to https://cr.yp.to/cdb.html ? I see there's a CDB_File
> Perl module in libcdb-file-perl but I'm not familiar with it. Seems worth
> a wishlist bug.

Among advantages of cdb is that it has well-specified format on disk.
-- 
Note, that I send and fetch email in batch, once every 24 hours.
 If matter is urgent, try https://t.me/kaction
 --

Bug#923238: libmarc-charset-perl: needs a rebuild on 32bit architectures?

[Dmitry Bogatov]

[2019-02-27 21:20] Niko Tyni 
> > - update perl to build-depend on libgdbm-dev (>= 1.18-2) and Break
> >   older versions of libmarc-charset-perl (and any other perl packages
> >   bundling GDBM or NDBM databases)
> > 
> > - update libmarc-charset-perl (and any other perl packages bundling
> >   GDBM or NDBM databases) to build-depend and depend on the newer perl
> > 
> > I assume other language bindings like python-gdbm will need something
> > similar.
>
> But ideally gdbm would restore compatibility and libmarc-charset-perl would
> not need any changes.

I believe upstream release 1.8.1 introduced change, that
made it possible to read old /usr/lib/libmarc-charset-perl/Table. Am I
missing something in current situation?

By the way, I disagree about compability. If all we need to make
everything good is just a binNMU, I'd rather not introduce any
patches/hacks/compatibility layers/etc.

By the way, it is sad that libmarc-charset-perl uses gdbm, not cdb.

-- 
Note, that I send and fetch email in batch, once every 24 hours.
 If matter is urgent, try https://t.me/kaction
 --

Bug#789008: At least on Debian testing it upgraded without an issue.

[Dmitry Bogatov]

[2018-12-19 23:40] Dmitry Bogatov 
>
> part   text/plain 459
>
> control: tags -1 +moreinfo
>
> [2018-12-18 12:10] shirish शिरीष 
> >
> > Dear all,
> > 
> > At least here it updated without any issues -
> > 
> > $ sudo aptitude install insserv -y
> > The following packages will be upgraded:
> >   insserv
> > [...]
>
> Thank you for help with bug triage, shirish.
>
> Dear submitter, can you reproduce issue?  Note, that insserv=1.16 is no
> longer relevant, since now insserv=1.18 in sid and insserv=1.14 in
> stable.
>
-- 
Note, that I send and fetch email in batch, once every 24 hours.
 If matter is urgent, try https://t.me/kaction
 --

Bug#738775: insserv: Insserv 1.16 tries to connect to systemd even though system is running on sysv-init

[Dmitry Bogatov]

Since 1.18.0-1 (1.18.0-2 in unstable) debian packaging patch-out
integration with systemd, thus closing this bug.

Dear submitter, if you can somehow reproduce this bug with current
version of insserv, feel free to reopen this bug.
-- 
Note, that I send and fetch email in batch, once every 24 hours.
 If matter is urgent, try https://t.me/kaction
 --

Bug#919296: git-daemon-run: fails with 'warning: git-daemon: unable to open supervise/ok: file does not exist'

[Dmitry Bogatov]

[2019-01-23 12:41] Jonathan Nieder 
> Dmitry Bogatov wrote:
> >> Jonathan Nieder wrote:
>
> >>> +  * git-daemon-run: pre-create supervise directory so that postinst
> >>> +can start the service (thx Celejar and Dmitry Bogatov; closes:
> >>> +#919296).
> [...]
> > Wierd. It should work. /etc/sv/git-daemon/supervise is not dangling, is
> > it? Tell me which git commit I should build and test, in effort to help
> > debugging?
>
> It's not dangling.
>
> I tested with the debian-sid branch, with the patch in the message I
> sent applied on top.  That said:
>
> [...]
> > It is my fault. I dropped /var/lib/supervise directory in runit=2.1.2-4,
> > which was expected by git-daemon-run.
> >
> > Today runit packaging underwent quite a rework, and packages, providing
> > runscripts are encouraged to use dh_runit(1). It manages creation of
> > apporiate directories and symbolic links. If you have any issues, do not
> > hezitate to ask -- runit is my top priority.
>
> Thanks, these are two good starting points.  I'll take a look at the
> 2.1.2-4 changes and into whether it's simple to use dh_runit.  Hopefully
> the latter will take care of everything. :)

As promised, I applied patch over debian-sid branch and rebuilt package.
It worked out-of-box, except on on postinst, it output warning
about missing 'supervision/control', originating from this line:

sv -v term git-daemon || :

but it is harmless. You observe another, more buggy behaviour, don't you?
-- 
Note, that I send and fetch email in batch, once every 24 hours.
 If matter is urgent, try https://t.me/kaction
 --

Bug#919296: git-daemon-run: fails with 'warning: git-daemon: unable to open supervise/ok: file does not exist'

[Dmitry Bogatov]

[2019-01-23 12:41] Jonathan Nieder 
> [...]
> > It is my fault. I dropped /var/lib/supervise directory in runit=2.1.2-4,
> > which was expected by git-daemon-run.
> >
> > Today runit packaging underwent quite a rework, and packages, providing
> > runscripts are encouraged to use dh_runit(1). It manages creation of
> > apporiate directories and symbolic links. If you have any issues, do not
> > hezitate to ask -- runit is my top priority.
>
> Thanks, these are two good starting points.  I'll take a look at the
> 2.1.2-4 changes and into whether it's simple to use dh_runit.  Hopefully
> the latter will take care of everything. :)

It should. If not, I am here to help/fix/improve.

Still, I am surprised, that adding /var/lib/supervise did not help to
you. I will apply patch to `debian-sid' branch and take a closer look at
this weekend.
-- 
Note, that I send and fetch email in batch, once every 24 hours.
 If matter is urgent, try https://t.me/kaction
 --

Bug#919296: git-daemon-run: fails with 'warning: git-daemon: unable to open supervise/ok: file does not exist'

[Dmitry Bogatov]

[2019-01-21 19:54] Jonathan Nieder 
> Dmitry Bogatov wrote:
> > [2019-01-16 14:49] Dmitry Bogatov 
>
> >> So, should I propose you patch (in 7 days), that merges
> >> bin:git-daemon-run into bin:git-daemon, would you be able to review
> >> and apply/upload it before hard freeze?
> >
> > Probably, even better would be to merge `git-daemon-run' and
> > `git-daemon-sysvinit'. What do you think?
>
> For "buster", I prefer a minimal fix within the framework of the
> current packages, along the lines you suggested upthread:

I am fine with it. I will prepare patch, but in more relaxed time frame.

> This way, the same behavior as the previous release will persist for
> users expecting it (in particular, allowing users to easily decide
> which configuration will control their running daemon --- see [1] for
> more context).  That said, I'm happy to pursue a merge of the packages
> into a git-daemon package in experimental in preparation for buster+1,
> especially if there's a standard for runit service packaging that we
> can follow there.

Fine. I see it as git-daemon package Provides+Replaces+Breaks
git-daemon-sysvinit and git-daemon-run.
-- 
Note, that I send and fetch email in batch, once every 24 hours.
 If matter is urgent, try https://t.me/kaction
 --

Bug#919296: git-daemon-run: fails with 'warning: git-daemon: unable to open supervise/ok: file does not exist'

[Dmitry Bogatov]

[2019-01-21 20:03] Jonathan Nieder 
> Jonathan Nieder wrote:
> > +  * git-daemon-run: pre-create supervise directory so that postinst
> > +can start the service (thx Celejar and Dmitry Bogatov; closes:
> > +#919296).
> > [...]
>
> Unfortunately, this doesn't work.  /var/lib/supervise/git-daemon ought
> to contain a definition of a supervise service, whereas this produces
> an empty directory so it still fails.

Wierd. It should work. /etc/sv/git-daemon/supervise is not dangling, is
it? Tell me which git commit I should build and test, in effort to help
debugging?

> Do you have more details?  Why was this approach expected to work, and
> where can I read more about what changed in runit and how to
> appropriately adjust this package to handle the changes?

It is my fault. I dropped /var/lib/supervise directory in runit=2.1.2-4,
which was expected by git-daemon-run.

Today runit packaging underwent quite a rework, and packages, providing
runscripts are encouraged to use dh_runit(1). It manages creation of
apporiate directories and symbolic links. If you have any issues, do not
hezitate to ask -- runit is my top priority.
-- 
Note, that I send and fetch email in batch, once every 24 hours.
 If matter is urgent, try https://t.me/kaction
 --

Bug#919296: git-daemon-run: fails with 'warning: git-daemon: unable to open supervise/ok: file does not exist'

[Dmitry Bogatov]

[2019-01-16 14:49] Dmitry Bogatov 
> So, should I propose you patch (in 7 days), that merges
> bin:git-daemon-run into bin:git-daemon, would you be able to review
> and apply/upload it before hard freeze?

Probably, even better would be to merge `git-daemon-run' and
`git-daemon-sysvinit'. What do you think?

Bug#911515: dvtm in backports

[Dmitry Bogatov]

Hello?

Dear maintainer of ncurses, could you please upload a backport of
ncurses-term?


pgpLomqpgPKeE.pgp
Description: PGP signature

Bug#919296: git-daemon-run: fails with 'warning: git-daemon: unable to open supervise/ok: file does not exist'

[Dmitry Bogatov]

control: tags -1 +confirmed

[2019-01-14 19:56] Celejar 
> ~# dpkg-reconfigure git-daemon-run
> Service git-daemon already added.
> warning: git-daemon: unable to open supervise/ok: file does not exist
> 
> > If I'm lucky then that will get it working.  I'll try to reproduce it
> > here and set the right dependencies.
> 
> Sorry :/
> 
> Again, thanks for the help. I'm likely doing something basic wrong, so
> thanks for bearing with me.

Dear submitter, you are not doing wrong. It is actually bug. To
workaround it it /right now/:

# mkdir /var/lib/supervise/git-daemon

If you have running 'runsvdir /etc/service' process (due
runit-{init,sysv,systemd}, for example), things should be fine.

Dear git maintainer, you could plug this bug by adding
`/var/lib/supervise/git-daemon' into `debian/git-daemon-run.dirs'.

But I wish to discuss proper solution. After discussing issue of runit
scripts, debian-devel@ consensus was that runit scripts should be part
of main package, `git-daemon' in this particular case.

So, should I propose you patch (in 7 days), that merges
bin:git-daemon-run into bin:git-daemon, would you be able to review and
apply/upload it before hard freeze?

Bug#917394: gitlint: FTBFS -- test suite fails

[Dmitry Bogatov]

Package: gitlint
Version: 0.9.0-2
Severity: serious
Justification: FTBFS

Dear Maintainer,

gitlint fails to build from source -- it have 3 test cases failing. As I
discovered when trying to prepare NMU for #891538, these tests also fail
with gitlint-0.10, so I add upstream maintainer to thread.

Oh, and I already created `debian/gitlint' repository on Salsa. gitlint
lack Vcs-Git field in `debian/control', I hope you would be interested
in moving on salsa.

Failed build log:
-

dpkg-buildpackage: info: source package gitlint
dpkg-buildpackage: info: source version 0.9.0-2
dpkg-buildpackage: info: source distribution unstable
dpkg-buildpackage: info: source changed by Patrik Hagedorn 

 dpkg-source --before-build .
dpkg-buildpackage: info: host architecture amd64
dpkg-source: info: using patch list from debian/patches/series
dpkg-source: info: applying 0001-Add-support-for-python3-for-gitlint-tests.patch
dpkg-source: info: applying 
0002-Change-get_sample-and-get_expected-to-context.patch
dpkg-source: info: applying 0003-Fix-regexp-matching-in-tests.patch
dpkg-source: info: applying 0004-Remove-duplicate-line.patch
 fakeroot debian/rules clean
dh clean --with python3 --buildsystem=pybuild
   dh_auto_clean -O--buildsystem=pybuild
I: pybuild base:217: python3.7 setup.py clean 
running clean
removing '/tmp/gitlint-0.9.0/.pybuild/cpython3_3.7/build' (and everything under 
it)
'build/bdist.linux-amd64' does not exist -- can't clean it
'build/scripts-3.7' does not exist -- can't clean it
   dh_autoreconf_clean -O--buildsystem=pybuild
   dh_clean -O--buildsystem=pybuild
 dpkg-source -b .
dpkg-source: info: using source format '3.0 (quilt)'
dpkg-source: info: building gitlint using existing ./gitlint_0.9.0.orig.tar.gz
dpkg-source: info: using patch list from debian/patches/series
dpkg-source: info: building gitlint in gitlint_0.9.0-2.debian.tar.xz
dpkg-source: info: building gitlint in gitlint_0.9.0-2.dsc
 debian/rules build
dh build --with python3 --buildsystem=pybuild
   dh_update_autotools_config -O--buildsystem=pybuild
   dh_autoreconf -O--buildsystem=pybuild
   dh_auto_configure -O--buildsystem=pybuild
I: pybuild base:217: python3.7 setup.py config 
running config
   dh_auto_build -O--buildsystem=pybuild
I: pybuild base:217: /usr/bin/python3 setup.py build 
running build
running build_py
creating /tmp/gitlint-0.9.0/.pybuild/cpython3_3.7/build/qa
copying qa/base.py -> /tmp/gitlint-0.9.0/.pybuild/cpython3_3.7/build/qa
copying qa/test_commits.py -> /tmp/gitlint-0.9.0/.pybuild/cpython3_3.7/build/qa
copying qa/test_hooks.py -> /tmp/gitlint-0.9.0/.pybuild/cpython3_3.7/build/qa
copying qa/test_config.py -> /tmp/gitlint-0.9.0/.pybuild/cpython3_3.7/build/qa
copying qa/test_user_defined.py -> 
/tmp/gitlint-0.9.0/.pybuild/cpython3_3.7/build/qa
copying qa/__init__.py -> /tmp/gitlint-0.9.0/.pybuild/cpython3_3.7/build/qa
copying qa/test_gitlint.py -> /tmp/gitlint-0.9.0/.pybuild/cpython3_3.7/build/qa
creating /tmp/gitlint-0.9.0/.pybuild/cpython3_3.7/build/gitlint
copying gitlint/rules.py -> 
/tmp/gitlint-0.9.0/.pybuild/cpython3_3.7/build/gitlint
copying gitlint/hooks.py -> 
/tmp/gitlint-0.9.0/.pybuild/cpython3_3.7/build/gitlint
copying gitlint/options.py -> 
/tmp/gitlint-0.9.0/.pybuild/cpython3_3.7/build/gitlint
copying gitlint/config.py -> 
/tmp/gitlint-0.9.0/.pybuild/cpython3_3.7/build/gitlint
copying gitlint/utils.py -> 
/tmp/gitlint-0.9.0/.pybuild/cpython3_3.7/build/gitlint
copying gitlint/display.py -> 
/tmp/gitlint-0.9.0/.pybuild/cpython3_3.7/build/gitlint
copying gitlint/user_rules.py -> 
/tmp/gitlint-0.9.0/.pybuild/cpython3_3.7/build/gitlint
copying gitlint/lint.py -> 
/tmp/gitlint-0.9.0/.pybuild/cpython3_3.7/build/gitlint
copying gitlint/__init__.py -> 
/tmp/gitlint-0.9.0/.pybuild/cpython3_3.7/build/gitlint
copying gitlint/cli.py -> /tmp/gitlint-0.9.0/.pybuild/cpython3_3.7/build/gitlint
copying gitlint/git.py -> /tmp/gitlint-0.9.0/.pybuild/cpython3_3.7/build/gitlint
creating /tmp/gitlint-0.9.0/.pybuild/cpython3_3.7/build/gitlint/tests
copying gitlint/tests/base.py -> 
/tmp/gitlint-0.9.0/.pybuild/cpython3_3.7/build/gitlint/tests
copying gitlint/tests/test_config_builder.py -> 
/tmp/gitlint-0.9.0/.pybuild/cpython3_3.7/build/gitlint/tests
copying gitlint/tests/test_user_rules.py -> 
/tmp/gitlint-0.9.0/.pybuild/cpython3_3.7/build/gitlint/tests
copying gitlint/tests/test_title_rules.py -> 
/tmp/gitlint-0.9.0/.pybuild/cpython3_3.7/build/gitlint/tests
copying gitlint/tests/test_hooks.py -> 
/tmp/gitlint-0.9.0/.pybuild/cpython3_3.7/build/gitlint/tests
copying gitlint/tests/test_cli.py -> 
/tmp/gitlint-0.9.0/.pybuild/cpython3_3.7/build/gitlint/tests
copying gitlint/tests/test_git.py -> 
/tmp/gitlint-0.9.0/.pybuild/cpython3_3.7/build/gitlint/tests
copying gitlint/tests/test_config.py -> 
/tmp/gitlint-0.9.0/.pybuild/cpython3_3.7/build/gitlint/tests
copying gitlint/tests/test_config_precedence.py -> 
/tmp/gitlint-0.9.0/.pybuild/cpython3_3.7/build/gitlint/tests
copying gitlint/tests/__init__.py -> 

Bug#789008: At least on Debian testing it upgraded without an issue.

[Dmitry Bogatov]

control: tags -1 +moreinfo

[2018-12-18 12:10] shirish शिरीष 
>
> Dear all,
> 
> At least here it updated without any issues -
> 
> $ sudo aptitude install insserv -y
> The following packages will be upgraded:
>   insserv
> [...]

Thank you for help with bug triage, shirish.

Dear submitter, can you reproduce issue?  Note, that insserv=1.16 is no
longer relevant, since now insserv=1.18 in sid and insserv=1.14 in
stable.

Bug#911515: dvtm: unsatisfiable dependency in stretch-backports: ncurses-term (>> 6.1+20180210-3)

[Dmitry Bogatov]

[2018-10-21 10:44] Andreas Beckmann 
> Package: dvtm
> Version: 0.15-3~bpo9+1
> Severity: serious
> User: debian...@lists.debian.org
> Usertags: piuparts

> during a test with piuparts I noticed your package is not
> installable in stretch-backports:

> ncurses-term | 6.0+20161126-1+deb9u2 | stable | all
> ncurses-term | 6.1+20180714-1| testing| all
> ncurses-term | 6.1+20181013-1| unstable   | all

Oh, I see. My bad. And it is not clear how to fix it myself only.

[Added ncurser-term maintainer into thread]

Craig, would it be possible for you to backport ncurses-term=6.1+20181013-3
into stretch-backports?

Bug#910911: libgdbm6: can't read (some?) older GDBM databases

[Dmitry Bogatov]

[2018-10-15 20:18] Niko Tyni 
> > I am sorry to say it, but probably binNMU or sourceful upload would
> > be required for all packages, that bundle gdbm databases, generated
> > by (gdbm << 1.9)
> 
> This sounds really sad. So even the gdbm we have in our current stable
> release is too old to be supported anymore!
> 
> Any packaged databases are easily rebuilt, but what about local user
> databases? I think breaking compat with those is horrible, and I don't
> even see a way to recover their contents after they've upgraded gdbm.

Well, you can use gdbm_dump/stable. What else?

 * I can write debian/NEWS to warn about incompatibility.
 * We can introduce new source package, that provides gdbmtool
   out of gdbm-1.8 (I am not fan of this idea)

Bug#910911: libgdbm6: can't read (some?) older GDBM databases

[Dmitry Bogatov]

[2018-10-13 13:20] Niko Tyni 
> The libgdbm6 transition broke autopkgtest checks of src:perl and
> libmarc-charset-perl.
> 
> It looks like some GDBM databases which were working with the older
> gdbm are not readable any more with the new one.

After a bit more research I deduced, that libmarc-charset-perl, as
present in sid, was build with gdbm-1.8.3. gdbm-1.9 is incompatible with
1.8.3, so it is pure luck, that thigs worked with gdbm-1.14.

I am sorry to say it, but probably binNMU or sourceful upload would be
required for all packages, that bundle gdbm databases, generated by
(gdbm << 1.9)

Bug#910911: libgdbm6: can't read (some?) older GDBM databases

[Dmitry Bogatov]

control: tag -1 +moreinfo

[2018-10-13 13:20] Niko Tyni 
> For reference, the output with libgdbm5 1.14.1-6+b1 is
> 
>  % gdbm_dump debian/tests/data/jessie.gdbm
>  # GDBM dump file created by GDBM version 1.14.1. 03/01/2018 on Sat Oct 13 
> 13:15:59 201
> 8
>  #:version=1.0
>  #:file=debian/tests/data/jessie.gdbm
>  #:uid=1000,user=niko,gid=1000,group=niko,mode=644
>  # End of header
>  #:len=3
>  Zm9v
>  #:len=9
>  amVzc2llIE9L
>  #:count=1
>  # End of data

I compiled gdbm-1.14.1 from source to check
`/usr/lib/libmarc-charset-perl/Table'.  For me, exit code is non-zero. I
belive that issue is with database, but older versions of gdbm_dump
failed to properly report it.

In addition, just checked bin:man-db database. It is fine. So I believe
problem is not /too/ grave.

But I agree, usability issue is at hand: something worked (no matter
why), and now it no longer works. Let us debug.

How those problematic databases are created?

Bug#910911: libgdbm6: can't read (some?) older GDBM databases

[Dmitry Bogatov]

control: tag -1 confirmed


[2018-10-13 13:20] Niko Tyni 
>
> part   text/plain1170
> Package: libgdbm6
> Version: 1.18-2
> Severity: grave
> X-Debbugs-Cc: p...@packages.debian.org, 
> libmarc-charset-p...@packages.debian.org
> 
> The libgdbm6 transition broke autopkgtest checks of src:perl and
> libmarc-charset-perl.
> 
> It looks like some GDBM databases which were working with the older
> gdbm are not readable any more with the new one.
> 
>  # file /usr/lib/libmarc-charset-perl/Table
>  /usr/lib/libmarc-charset-perl/Table: GNU dbm 1.x or ndbm database, little 
> endian, old

Yes, I can confirm the problem. I already located commit, that
introduced it (2ed540). Its commit message is 'Improve error checking',
so right now I am investigating, whether there is error in mentioned
commit, or mentioned database has format errors.

Bug#897725: auto-gdbm transition

[Dmitry Bogatov]

control: tag -1 patch

Hello!

This bug blocks auto-gdbm transition.
I prepared and uploaded NMU, debdiff is below.


diff -Nru courier-authlib-0.68.0/debian/changelog 
courier-authlib-0.68.0/debian/changelog
--- courier-authlib-0.68.0/debian/changelog 2017-09-11 21:06:17.0 
+
+++ courier-authlib-0.68.0/debian/changelog 2018-10-10 16:35:27.0 
+
@@ -1,3 +1,11 @@
+courier-authlib (0.68.0-4.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Relax checks for C++ symbols (Closes: #897725)
+  * Update Vcs-* fields in debian/control
+
+ -- Dmitry Bogatov   Wed, 10 Oct 2018 16:35:27 +
+
 courier-authlib (0.68.0-4) unstable; urgency=medium
 
   [ Matthias Klose ]
diff -Nru courier-authlib-0.68.0/debian/control 
courier-authlib-0.68.0/debian/control
--- courier-authlib-0.68.0/debian/control   2017-08-06 20:10:56.0 
+
+++ courier-authlib-0.68.0/debian/control   2018-10-10 16:35:27.0 
+
@@ -20,8 +20,8 @@
pkg-config,
procps
 Homepage: https://www.courier-mta.org/
-Vcs-Git: https://anonscm.debian.org/git/collab-maint/courier-authlib.git
-Vcs-Browser: https://anonscm.debian.org/cgit/collab-maint/courier-authlib.git
+Vcs-Git: https://salsa.debian.org/debian/courier-authlib.git
+Vcs-Browser: https://salsa.debian.org/debian/courier-authlib
 
 Package: courier-authlib
 Architecture: any
diff -Nru courier-authlib-0.68.0/debian/rules 
courier-authlib-0.68.0/debian/rules
--- courier-authlib-0.68.0/debian/rules 2017-09-11 20:43:47.0 +
+++ courier-authlib-0.68.0/debian/rules 2018-10-10 16:35:27.0 +
@@ -15,8 +15,6 @@
 # package maintainers to append LDFLAGS
 #export DEB_LDFLAGS_MAINT_APPEND = -Wl,--as-needed
 
-export DPKG_GENSYMBOLS_CHECK_LEVEL=4
-
 # the build captures $SHELL, hard-wire to "/bin/sh"
 export CONFIG_SHELL=/bin/sh
 




pgpqlT7qdfyWm.pgp
Description: PGP signature

Bug#836948: getty-run: fails to remove: warning: getty-tty6: unable to open supervise/ok: file does not exist

[Dmitry Bogatov]

control: close -1

[2016-09-07 22:56] Dmitry Bogatov <kact...@gnu.org>
> control: tags -1 +fixed-in-experimental
>
> > >From the attached log (scroll to the bottom...):
> >
> >   Removing getty-run (2.1.2-6) ...
> >   warning: getty-tty6: unable to open supervise/ok: file does not exist
> >   dpkg: error processing package getty-run (--remove):
> >subprocess installed pre-removal script returned error exit status 1
>
> Err, getty-run_7 will not upgrade/purge cleanly. Unless service was started
> to make it possible to 'force-shutdown' it, the only way would be
> mentioned sed command. Sorry.

Somehow I missed this bug. With `runit_2.1.2-9' in testing, bug is
resolved.

My apologizes for those, who had to upgrade from -6 to -7.

--
X-Web-Site: https://sinsekvu.github.io | Note that I process my email in batch,
Accept-Languages: eo,ru,en | at most once every 24 hours. If matter
Accept: text/plain, text/x-diff| is urgent, you have my phone number.


pgp4_ESSZwjl2.pgp
Description: PGP signature

Bug#829299: Bug#847040: evil-el: test suite fails under emacs25

[Dmitry Bogatov]

[2016-12-13 11:02] Sean Whitton <spwhit...@spwhitton.name>
> On Wed, Dec 07, 2016 at 09:34:13AM +0300, Dmitry Bogatov wrote:
> > I switched to emacs25 already (since this bug report). So far, no
> > changes.
> >
> > > - Could you fix #829299 based on the private e-mails we exchanged a few
> > >   weeks ago, please?
> >
> > I already pushed (but not released) fix for #829299 (d057d2).
>
> It's been a week since we last discussed this.  Have you been using
> evil-el with emacs25 every day, without any problems?  If so, it would
> be great if you could make an upload fixing both of these bugs.

I pushed change (1a1ee03a87f30718c488358cabd893e39daa3a79) and made RFS.

> When you add a patch commenting out the tests, please annotate it so
> that it is clear that this is a temporary fix that should eventually be
> removed.

I did. Feel free to adjust wording.

--
X-Web-Site: https://sinsekvu.github.io | Note that I process my email in batch,
Accept-Languages: eo,ru,en | at most once every 24 hours. If matter
Accept: text/plain, text/x-diff| is urgent, you have my phone number.


pgpdxsEAaIJfS.pgp
Description: PGP signature

Bug#838888: closed by Dmitry Bogatov <kact...@gnu.org> (Bug#838888: fixed in dh-haskell 0.3)

[Dmitry Bogatov]

> > > I don't see the related changes there, nor attribution (or NACK) for the
> > > patch...
> >
> > I read you patch email *after* I wrote almost same patch myself and
> > made RFS. Are there any attribution issues?
>
> Oh, no attribution issues whatsoever, more of a friendly thing. Always better
> to err on attribution as it encourages further patches from new users IMHO. :)

Sure. But in your case, I only can add attribution by modifying
alredy-was-in-archive changelog.

> > No. Now dh-haskell is under umbrella of DHG. Look here:
>
> Ah. Now, to be fair, the kaction-guest location was mentioned in dh-haskell
> 0.2 but was (silently!) changed for the 0.3 upload.

It is my fault, but in this case I do not see point to tamper with
already existing changelog.

-- 
X-Web-Site: https://sinsekvu.github.io | Note that I process my email in batch,
Accept-Languages: eo,ru,en | at most once every 24 hours. If matter
Accept: text/plain, text/x-diff| is urgent, you have my phone number.

Bug#838888: closed by Dmitry Bogatov <kact...@gnu.org> (Bug#838888: fixed in dh-haskell 0.3)

[Dmitry Bogatov]

> Did you forget to push this to:
>
>   https://anonscm.debian.org/cgit/users/kaction-guest/dh-haskell.git

No. Now dh-haskell is under umbrella of DHG. Look here:

https://anonscm.debian.org/cgit/pkg-haskell/dh-haskell.git

> I don't see the related changes there, nor attribution (or NACK) for the
> patch... :)

I read you patch email *after* I wrote almost same patch myself and
made RFS. Are there any attribution issues?

-- 
X-Web-Site: https://sinsekvu.github.io | Note that I process my email in batch,
Accept-Languages: eo,ru,en | at most once every 24 hours. If matter
Accept: text/plain, text/x-diff| is urgent, you have my phone number.

Bug#836948: getty-run: fails to remove: warning: getty-tty6: unable to open supervise/ok: file does not exist

[Dmitry Bogatov]

control: tags -1 +fixed-in-experimental

> >From the attached log (scroll to the bottom...):
>
>   Removing getty-run (2.1.2-6) ...
>   warning: getty-tty6: unable to open supervise/ok: file does not exist
>   dpkg: error processing package getty-run (--remove):
>subprocess installed pre-removal script returned error exit status 1

Err, getty-run_7 will not upgrade/purge cleanly. Unless service was started
to make it possible to 'force-shutdown' it, the only way would be
mentioned sed command. Sorry.

Bug#836948: getty-run: fails to remove: warning: getty-tty6: unable to open supervise/ok: file does not exist

[Dmitry Bogatov]

> during a test with piuparts I noticed your package fails to remove.
>
> >From the attached log (scroll to the bottom...):
>
>   Removing getty-run (2.1.2-6) ...
>   warning: getty-tty6: unable to open supervise/ok: file does not exist
>   dpkg: error processing package getty-run (--remove):
>subprocess installed pre-removal script returned error exit status 1

Include 'force-shutdown' into maintainer script was bad idea. This is
no longer happens with version in experimental (-7), but -6 is
buggy. As I checked via piuparts, upgrade from -6 to -7 should be
clean. If you want to purge -6 revision, you may need

# sed -i '/^sv/ d' /var/lib/dpkg/info/getty-run.prerm

Probably, I should mark this bug as

control: tags -1 +fixed-in-experimental

Bug#835903: Same error here

[Dmitry Bogatov]

> My (dist-)upgrade attempt failed this morning with the same exact problem :
>
> -
> root@SAP5057241:~# apt-get dist-upgrade -u -f
> Lecture des listes de paquets... Fait
> Construction de l'arbre des dépendances
> Lecture des informations d'état... Fait
> Calcul de la mise à jour... Fait
> Les paquets suivants seront mis à jour :
>runit
> 1 mis à jour, 0 nouvellement installés, 0 à enlever et 0 non mis à jour.
> Il est nécessaire de prendre 0 o/103 ko dans les archives.
> Après cette opération, 3 072 o d'espace disque supplémentaires seront
> utilisés.
> Souhaitez-vous continuer ? [O/n] o
> Lecture des fichiers de modifications (« changelog »)... Terminé
> (Lecture de la base de données... 610356 fichiers et répertoires déjà
> installés.)
> Préparation du dépaquetage de .../runit_2.1.2-6_amd64.deb ...
> unsupported: /etc/service exists, but does not point to
> /etc/runit/runsvdir/current
> dpkg: erreur de traitement de l'archive
> /var/cache/apt/archives/runit_2.1.2-6_amd64.deb (--unpack) :
>   le sous-processus nouveau script pre-installation a retourné une
> erreur de sortie d'état 1
> Des erreurs ont été rencontrées pendant l'exécution :
>   /var/cache/apt/archives/runit_2.1.2-6_amd64.deb
> E: Sub-process /usr/bin/dpkg returned an error code (1)

Thanks for report. I know about problem. I did migration to runlevel
(-5 -> -6) support poorly. If you are interested, you can see
#835278. I am working on fix.

BTW, usually it is better to provide non-localized error message.

Bug#834088: What's up with mongrel2?

[Dmitry Bogatov]

control: tags -1 +moreinfo

Jan, could you please provide more information?  I did not follow. As
I understand, there was some problem with mongrel2-run, but, as
mongrel2/1.11.0-1 it is no longer case (and I can confirm it, just
installed mongrel2-run without any problems), but this bug is still
open.

Is problem solved? Can I close this bug?

-- 
Accept: text/plain, text/x-diff
Accept-Language: eo,en,ru
X-Web-Site: sinsekvu.github.io


pgpYL5tLDkevW.pgp
Description: PGP signature

Bug#832656: runit: breaks users of runit: ln: failed to create symbolic link '/etc/service/bcron-sched': No such file or directory

[Dmitry Bogatov]

> I'm not sure, but did you mean to report this bug against bcron package?
> I fail to understand why runit should have such problem

Well, it is my bad. runit-2.1.2_4 deserved a transition, but now we have at 
least following
uninstallabe packages:

bcron-run
twoftpd-run
tinydns-run

and rest of -run packages deserve some love, care and debhelper.
Fixing issue is extremely difficult without converting packages
to debhelper (since I need dh_runit). I am discussing with
Gerrit about taking over a least three packages above.

-- 
Accept: text/plain, text/x-diff
Accept-Language: eo,en,ru
X-Web-Site: sinsekvu.github.io

Bug#831342: nis: FTBFS due lacking debhelper compat file

[Dmitry Bogatov]

Package: nis
Version: 3.17-34
Severity: serious
Justification: fails to build from source (but built successfully in the past)

Dear Maintainer,

Package no longer builds from source in up-to-date sid
environment. Build log attached.

-- System Information:
Debian Release: 8.5
  APT prefers stable
  APT policy: (900, 'stable'), (500, 'stable-updates'), (500, 
'buildd-unstable'), (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 4.6.0-0.bpo.1-amd64 (SMP w/8 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=UTF-8) (ignored: LC_ALL set to C.UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
dpkg-buildpackage: info: source package nis
dpkg-buildpackage: info: source version 3.17-34
dpkg-buildpackage: info: source distribution unstable
dpkg-buildpackage: info: source changed by Mark Brown 
dpkg-buildpackage: info: host architecture amd64
(cd yp-tools-2.9 && [ -f Makefile ] && make distclean)
debian/rules:67: recipe for target 'clean' failed
(cd ypbind-mt-1.20.1  && [ -f Makefile ] && make distclean)
debian/rules:67: recipe for target 'clean' failed
(cd ypserv-2.19  && [ -f Makefile ] && make distclean)
debian/rules:67: recipe for target 'clean' failed
rm -rf ypbind-mt-1.20.1/rpcsvc
rm -rf /home/user/stuff/nis-3.17/debian/tmp
rm -rf ypserv-2.19/autom4te.cache
rm -f build debian/{files,substvars,templates.gen}
find . -name '*.bak' -o -name '*~' | xargs -r rm --
rm -f */config.cache
dh_autoreconf_clean
rm -f debian/debhelper.log
dpkg-source: info: using source format '1.0'
dpkg-source: info: building nis using existing nis_3.17.orig.tar.gz
dpkg-source: info: building nis in nis_3.17-34.diff.gz
dpkg-source: info: use the '3.0 (quilt)' format to have separate and documented 
changes to upstream files, see dpkg-source(1)
dpkg-source: info: building nis in nis_3.17-34.dsc
dh_autoreconf
debian/rules:37: recipe for target 'build' failed

Bug#790655: python3-pygithub, remove the package?

[Dmitry Bogatov]

* Gianfranco Costamagna costamagnagianfra...@yahoo.it [2015-08-08 
07:35:10+]
 Hi Dmitry,
 I propose this solution:

 remove all the Debian patches (actually the python3 patch seems correctly 
 handled by 2to3 at build time)

 add a new patch to disable the only test actually requiring an internet
 connection:
 [..]

Thank you for suggestion. It simplify things and seems to work. Please
take from my unstable on alioth and upload.

 Let me know if it is ok for you, or you want to drop all the testsuite.

Totally okay. Currently I see no problem with testsuite, so why touch
it?

 This particular bug appears to caused by
  [..]

Would you be so kind to do not top-post?

--
Accept: text/plain, text/x-diff
Accept-Language: eo,en,ru
X-Keep-In-CC: yes


pgpw3gSXYRy6a.pgp
Description: PGP signature

Bug#790655: python3-pygithub, remove the package?

[Dmitry Bogatov]

 Just a few problems, seems that you didn't start from the last upload

 you need to start with -3 release with the changes, because otherwise it 
 messes up things
 (e.g.
 [...]

Nice catch, thanks. Get fixed -4 release from my unstable.

--
Accept: text/plain, text/x-diff
Accept-Language: eo,en,ru
X-Keep-In-CC: yes


pgp70PGlH7m95.pgp
Description: PGP signature

Bug#790655: python3-pygithub, remove the package?

[Dmitry Bogatov]

* Gianfranco Costamagna costamagnagianfra...@yahoo.it [2015-08-08 
11:22:51+]
 Nice catch, thanks. Get fixed -4 release from my unstable.
 Just a little nitpick, please add a Description for the patch, to make 
 lintian silent.

Added.

 if this is ok for you, just ack and I'll upload :)
 (no need to put on alioth the new package)

If you do not object, I prefer situation, when what I provided is
byte-in-byte ready for upload. Please, take fixed version from my
unstable.

--
Accept: text/plain, text/x-diff
Accept-Language: eo,en,ru
X-Keep-In-CC: yes


pgpXgxQtlxeG2.pgp
Description: PGP signature

Bug#790655: python3-pygithub, remove the package?

[Dmitry Bogatov]

Try this:
 cd ~kaction-guest/repository/unstable

Seems mini-dinstall does not allow others view incoming/ queque. Sorry.

--
Accept: text/plain, text/x-diff
Accept-Language: eo,en,ru
X-Keep-In-CC: yes


pgpcOmF5G194e.pgp
Description: PGP signature

Bug#790655: python3-pygithub, remove the package?

[Dmitry Bogatov]

* Gianfranco Costamagna costamagnagianfra...@yahoo.it [2015-08-06 
08:59:21+]
 Okay. mentors gives me 500 error, probably it dislikes Tor. I will
 investigate, but now to keep things fast you can
 
 git clone git://anonscm.debian.org/users/kaction-guest/pygithub.git
 
 and NMU it. Also, I can violate nettiqette *hard* and email
 packaging to you.
 thanks a lot, but I leave the decision to you.

I found new solution: please get package from alioth
(~kaction-guest/repository/mini-dinstall), review (changes are trivial,
but still) and upload it. If I am correct, it will
avoid NMU.

--
Accept: text/plain, text/x-diff
Accept-Language: eo,en,ru
X-Keep-In-CC: yes


pgpJR_fL_GXBI.pgp
Description: PGP signature

Bug#790655: python3-pygithub, remove the package?

[Dmitry Bogatov]

* Gianfranco Costamagna costamagnagianfra...@yahoo.it [2015-08-05 
15:15:00+]
 Control: forwarded -1 https://github.com/PyGithub/PyGithub/issues/331


 Hi Dmitry, I guess the package is really not python3 ready, in my opinion
 we should at least let the python2 version migrate to testing, because I need 
 it as dependency
 of the new w3af.

 How do you feel about doing that? I can NMU it if needed, or sponsor an 
 upload for you :)

Okay. mentors gives me 500 error, probably it dislikes Tor. I will
investigate, but now to keep things fast you can

git clone git://anonscm.debian.org/users/kaction-guest/pygithub.git

and NMU it. Also, I can violate nettiqette *hard* and email
packaging to you.

--
Accept: text/plain, text/x-diff
Accept-Language: eo,en,ru
X-Keep-In-CC: yes


pgpUA4jK3W2XE.pgp
Description: PGP signature