Bug#910280: pandoc: Please reduce the binary size

[KAction]

[2018-10-04 17:41] John MacFarlane 
> kact...@gnu.org writes:
> 
> > We could generate packages with compressed binaries in a way,
> > similar to *-dbg packages. All compiled languages, except C (Go,
> > Rust, Haskell) would benefit, but it is quite a bit of work --
> > changes to debhelper and reprorepo, at least.
> 
> Seems like it would be more sensible just to add an option to 'apt' to
> compress the binaries.

Probably not: as submitter said, compressing pandoc takes around hour. 

Bug#910280: pandoc: Please reduce the binary size

[KAction]

[2018-10-05 00:50] Jonas Smedegaard 
> Quoting John MacFarlane (2018-10-04 19:58:54)
> > Jonas Smedegaard  writes:
> >
> > > The proper solution here, I guess (but am not expert in Haskell so 
> > > may be wrong) is to switch to using shared linking, so that 5 
> > > Haskell binaries will not consume 5 x the disk space of the parts 
> > > reused among them.

We could generate packages with compressed binaries in a way, similar to
*-dbg packages. All compiled languages, except C (Go, Rust, Haskell)
would benefit, but it is quite a bit of work -- changes to debhelper and
reprorepo, at least.

Bug#905889: transition: gdbm

[KAction]

[2018-10-02 09:38] Emilio Pozuelo Monfort 
> part   text/plain 567
> On 11/08/2018 09:40, Dmitry Bogatov wrote:
> > Package: release.debian.org
> > Severity: normal
> > User: release.debian@packages.debian.org
> > Usertags: transition
> > 
> > Hello. According to [1] I request approval of upload gdbm-1.17 into
> > unstable. It will affect 28 packages, 26 of which build cleanly
> > (no-changes source upload will be required) and I am ready to NMU
> > patches for two others (perl and qsf).

> Is perl still unfixed? With the upcoming perl transition, that's
> something th at I wouldn't like to see fixed through an NMU at this
> point.

No, according to #904005, Perl maintainer fixed this issue himself.
Only qsf left {no response from maintainer, will NMU}.

Bug#890297: NMU

[KAction]

Hello.

I uploaded NMU, that add completion script and closes this bug into
DELAYED/13.


pgpjYs8mzZjBx.pgp
Description: PGP signature

Bug#904005: perl: FTBFS gdbm/experimental

[KAction]

[2018-07-20 13:33] Niko Tyni 
> > > I guess that last gdbm fix can't be easily cherry-picked as it changes
> > > the interface?
> > 
> > Sorry, failed to parse.
> 
> Rephrasing: do you think you can apply the gdbm fix to the package in
> experimental?

No. This patch does not apply cleanly, and I am no expert in gdbm
internals to refresh it.

> Or do you have other suggestions about how to handle this?

As I see, what we can do:

 * do nothing, wait for next gdbm release.
 * package non-release commit of gdbm (I would better not)
 * disable this test for now. As much as I can say, it tests behavior
   in case of improper usage.

Bug#904005: perl: FTBFS gdbm/experimental

[KAction]

[2018-07-19 14:28] Niko Tyni 
> > Dear Maintainer,
> >
> > Your package test suite fails with libgdbm6 from experimental.
> > Could you please fix it? Failed sbuild log is attached.
> Thanks for the report. This is also [perl #133295]. Apparently
> gdbm has fixed the crash that this test checks for, but doesn't
> report errors properly either.
>
> The issue seems somewhat tricky with improvements suggested on
> both the gdbm and perl side.
>
>  https://rt.perl.org/Public/Bug/Display.html?id=133295
>
>  https://puszcza.gnu.org.ua/bugs/index.php?399
>
>  
> http://git.gnu.org.ua/cgit/gdbm.git/commit/?id=030e685eb9df82f63d73a1bf206da84b7aa52374


> I guess that last gdbm fix can't be easily cherry-picked as it changes
> the interface?

Sorry, failed to parse.

Bug#901136: can't remove if install fails

[KAction]

[2018-06-14 00:32] Wouter Verhelst 
> Hi,

Hi!

> On Wed, Jun 13, 2018 at 03:21:11AM +0300, kact...@gnu.org wrote:
> > I never worked with NSS, but how did it happen, that useradd {in postinst}
> > created user in a way, that userdel {in prerm} could not find?
> 
> That's not what happened.
> 
> The sreview user already existed before the sreview-common package was
> installed, but it did not exist in /etc/passwd; instead, it existed in a
> different location, configured through an NSS module.

Am I correct, some time ago it was created by previous version of maintainer 
script,
when I did not use dh-sysuser?

> The easiest way for you to test this is probably to install libnss-db,
> change the value of ETC in /etc/default/libnss-db to some other
> directory and cull the DBS value so it contains just passwd, then create
> a file called "passwd" in the directory that you pointed ETC to, run
> "make -C /var/lib/misc", and add "db" to /etc/nsswitch.conf on the
> "passwd" line.
> 
> Meanwhile, I'm going to have to implement it properly and remove
> dh_sysuser from my build-depends. Ah well.

So sad. Maybe you could suggest what should I use instead of 'useradd/userdel'
in sysuser-helper to make dh-sysuser also work with NSS?

Bug#901136: can't remove if install fails

[KAction]

control: tag -1 +help

> Control: reassign -1 sysuser-helper,sreview-common
> Control: retitle -1 sysuser-helper fails in terrible ways if users exist 
> through NSS modules that are not libnss-unix

> On Sat, Jun 09, 2018 at 09:53:53AM +, Peter Palfrader wrote:
> > Package: sreview-common
> > Version: 0.3.0-1~bpo.1
> > Severity: grave
> > User: debian-ad...@lists.debian.org
> > Usertags: needed-by-DSA-Team
> > 
> > 
> > sreview-common failed to configure.
> > 
> > | Setting up sreview-common (0.3.0-1~bpo.1) ...
> > | usermod: user 'sreview' does not exist in /etc/passwd
[...]

Bad, bad. Oblivious workaround would be create user manually, but let us
dig into the root of problem.

I never worked with NSS, but how did it happen, that useradd {in postinst}
created user in a way, that userdel {in prerm} could not find?

Bug#679289: inotify-tools: can't watch FS unmounts

[KAction]

[2018-06-04 16:15] "Neal P. Murphy" 
>
> part   text/plain1646
> On Sun, 03 Jun 2018 14:16:53 +0300
> kact...@gnu.org wrote:
> 
> > control: tag -1 +confirmed
> > control: found -1 3.14-5
> > 
> > [2012-06-27 00:40] Neal Murphy 
> > > Package: inotify-tools
> > > Version: 3.13-3.1
> > > Severity: normal
> > > 
> > > Dear Maintainer,
> > > 
> > > Inotifywait cannot watch for FS unmounts.
> > > 
> > > On Squeeze, I was able to:
> > >   (sleep 1; umount /mnt)&
> > >   inotifywait -q -e unmount /mnt
> > > to receive notice that the FS was unmounted and, by extension, that all
> > > buffers were flushed; thus it would be safe to unplug the medium.
> > > 
> > > On Wheezy, that inotifywait command results in:
> > > Setting up watches.
> > > Couldn't watch /mnt: Invalid argument
> > > 
> > > The problem occurs on two different recent Wheezy ix86-64 installations; 
> > > they
> > > are basic systems with web server, ssh server, and vim, apcupsd, 
> > > inotify-tools,
> > > hdparm, acl, samba and ntp (and their dependencies) installed, and 
> > > vim-tiny 
> > > removed.  
> > 
> > Interesting. I tried this command, and, got another (still wrong) behaviour.
> > To me, `inotifywait' seems to miss unmount event, and keeps waiting
> > after mountpoint was umounted.
> > 
> > Needs more research.

> Just tried this with a rotating drive on Stretch (inotifytools 3.14);
> it works OK. Haven't tried Jessie or other types of media.

Sorry, what is rotating drive?  BTW, I tested on `mount --bind'. Will
check on physical device.

> But (probably unrelated to this problem), I've noticed that XFCE on
> Stretch reports a USB thumb drive unmounted while its LED continu es
> to flash for a while. I'm beginning to wonder if Linux's unmount
> mechanism needs investigation; IMO, it shouldn't claim it's done until
> all dirty buffers for that medium have been written out.

I saw something similar recently. But I have no idea how debug it.

Bug#488091: Runit not started by upstart post-install, patch in ubuntu

[KAction]

control: close -1

[2009-10-07 12:25] Gerrit Pape 
> On Thu, Jun 26, 2008 at 11:12:16AM +0200, Gabriel de Perthuis wrote:
> > Ubuntu bug (closed):
> > https://bugs.launchpad.net/ubuntu/+source/runit/+bug/74135
> > http://launchpadlibrarian.net/14764478/start-supervisor.patch
> > 
> > Ubuntu delta:
> > http://packages.qa.debian.org/r/runit.html
> 
> Hi, upstream suggest a different upstart integration
>  http://smarden.org/runit/useinit.html#upstart

Seems this bug is no longer relevant, since upstart is no longer in sid.
Feel free to reopen if I am wrong.

Bug#638605: runit: chpst fails to change uid not listed in /etc/passwd

[KAction]

control: close -1

[2012-06-25 12:00] Andras Korn 
> Package: runit
> Version: 2.1.1-6.2
> Severity: normal
> 
> 
> When system run with libnss-ldapd, chpst fails to change user
> not listed in /etc/passwd (aka user in LDAP database).
> 
> Rebuilding package on the target system, this problem disappear.
> chpst binary is linked statically, so I guess linked version of
> getpwnam() might lack ability to look /etc/nssswitch.conf.
> 
> I suppose this problem caused by package build environment.
>
> FWIW, I use the following workaround to this problem:
> 
> #!/bin/sh
> [...]
> RUNASUID=$(getent passwd $RUNASUSER | cut -d: -f3)
> RUNASGROUPS=$(id -G $RUNASUSER | tr ' ' ':')
> [...]
> exec chpst -u :$RUNASUID:$RUNASGROUPS [...]

chpst is no longer compiled statically, so issue should be resolved now.
Feel free to reopen bug if I am wrong.

Bug#526201: runit: Environment variables in run script

[KAction]

control: tag -1 +wontfix
control: close -1

[2017-01-06 11:38] Dmitry Bogatov 
> What is wrong with
> 
> $ cd /etc/service/foo
> $ echo 'OPTIONS=-bar > conf
> $ cat run
> #!/bin/sh
> . conf
> [...]
> 
> I dislike idea to complicate runit itself, but it is not in my
> competence. Such change is better to be proposed to upstream.

Seems there is no much activity about this issue lately, so closing bug.
Should any strong arguments why this feature request shoudl be fulfilled
appear, feel free to reopen bug.

Bug#426359: fgetty: checkpassword error for nis account

[KAction]

control: close -1

[2017-01-06 11:37] Dmitry Bogatov 
> Can you please check your issue with fgetty_0.7-2?  I have little
> knowledge about NIS, so if bug persist, I could only ask for help.
> But does it persist?

Closing due timeout on moreinfo. Feel free to reopen.

Bug#898984: fuse: Enable user_allow_other by default

[KAction]

[2018-05-29 15:52] Miklos Szeredi 
>
> part   text/plain2489
> On Fri, May 18, 2018 at 10:51 AM, Dmitry Bogatov  wrote:
> > Package: fuse
> > Version: 2.9.7-1
> > Severity: wishlist
> >
> > Dear Maintainer,
> >
> > Is there any security or other concerns about enabling `user_allow_other'
> > in /etc/fuse.conf by default?
> 
> There are security concerns with this.   For details see
> Documentation/filesystems/fuse.txt in the linux kernel tree.  The
> following paragraphs are relevant:
[...]

Thank you for such elaborate response.

I understand. So, am I correct, that if my package requires
'user_allow_other' to operate properly, there is no other way, but make
human user to edit /etc/fuse.conf manually?

Bug#900393: runit 2.1.2-14 breaks git-daemon-run

[KAction]

--21882_ĵaŭ_Maj_31_13_32_22_MSK_2018
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


[2018-05-29 23:53] Jonathan Nieder 
> part   text/plain 646
> Package: runit
> Version: 2.1.2-14
> Severity: serious
> Justification: breaks upgrades
> =

> The changelog to runit 2.1.2-14 explains:
> =

>* Do not install `update-service' script.
> =

> but it doesn't give any more context than that.  This breaks the
> git-daemon-run package, as noticed e.g. by piuparts:
> =

>   https://piuparts.debian.org/sid/fail/git-daemon-run_1:2.17.1-1.log
> =

> Moreover, debian/runit.NEWS doesn't say anything about the change.
> https://codesearch.debian.net/search?q=3Dupdate-service=3D1 finds
> some other callers. =


Yes, my fault -- I forgot to check codesearch. Sorry, I will revert it.

> Where can I read more about how to handle this, and can you roll back
> the change for now to unblock updates?

In this change I wanted to phase out `update-service` script, but was
not so careful about it. `update-service' functionality is better served
by dh-runit and coreutils instead:

 * installing all required symbolic links and, maybe, enabling service
   by default, is handled by `dh-runit'
 * --add: ln -sf /etc/sv/$name /etc/service
 * --remove: unlink /etc/service/$name (`rm -f' is fine too)
 * --list: ls -1 /etc/service
 * --check: sv status $name

--21882_ĵaŭ_Maj_31_13_32_22_MSK_2018
Content-Type: application/pgp-signature

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEhnHVzDbtdH7ktKj4SBLY3qgmEeYFAlsPzzYACgkQSBLY3qgm
EeZKGQ//UH/8NtAYsZo06M2QglY/3Sl1vJZxsk6KKAcHZ3QIqDLl9OvCVyhL2y9W
lvIRdF218nPIvP2IYQnno0NIAuEMarYkbt7gCHIMUhkrbNkqJH2AYa2vQfmn6sUH
ucjsahtswNbKsydvYWhi98OkwUAa3fVosuuYTBKKkDkjT+flJJhBSnfOJIeEJhDI
5upK1kd+UtAKalarXDdEWOHTaZWpk8MdQN0S/NcyaPjT0kNu/WyJHpD1YiWeBS8v
oxdGEm0wzffOhPvnO0kxVk5w5g/i6RuH12Y7q3zuiEx1vhi4XSQ1MT+4zvZAT9H6
GZiM9YdHJGNVlbrftl+yrO1TvW6xcaWH8nvJ5EneXby+b/rOwxJwP/r23P/uCtHJ
ye797ZIr6OMPboLga0sqQBfnd0FVhFKJeggJy1cIDAOdKduKPTJ7hqqeJKhkCHEr
FDDW5e+UY9O+oE0XRNLbmboiCXtgZfXlEMBx0MlAm3HbZay9YlBat42J6p3q8omx
O+9AAomEf5hcBMMF3TT0rRnsoMuNEXTqjKFouRwvm9yzDZSszqcBy6L53mpPdrZM
OKPo8LH7RSOgViz9pFwolyTpS2JHut+2B68nbjXk9E1xtz+VFznQ60LxGmQG8xSL
r+Wp58PhHKrwMUy4xE9l5OINcQhg0s9oVV3KkK/D2Q5LddsiAc4=
=RoM3
-END PGP SIGNATURE-

--21882_ĵaŭ_Maj_31_13_32_22_MSK_2018--

Bug#866652: runit: Should depend on runit-(systemd|sysv) to be present

[KAction]

[2018-02-22 13:13] chrysn 
> part 1 text/plain 473
> Package: runit
> Version: 2.1.2-9.2
> Followup-For: Bug #866652
> 
> Hello Dmitry,
> 
> If this is implemented (which I think is a good idea), please implement
> it in a way that users of runit as PID 1 can also satisfy the
> dependency, eg. by making the dependency "runit-systemd | runit-any"
> where runit-any is virtual and provided by runit-systemd, runit-sysv,
> and users of runit-init can make it "Provides: runit-any" even if a
> runit-init does not come back to Debian.

I am considering

Recommends: runit-sysv | runit-init | runit-systemd

but, since runit-init /depends/ on runit, it feels almost like loop. Am
I correct, that this is bad thing?

Bug#897953: dvtm: Please stop shipping dvtm and dvtm-256color terminfo entries

[KAction]

[2018-05-21 05:16] Thomas Dickey 
> - Original Message -
> | From: "Sven Joachim" 
> | To: kact...@gnu.org
> | Cc: 897...@bugs.debian.org, ncur...@packages.debian.org
> | Sent: Monday, May 21, 2018 5:07:15 AM
> | Subject: Re: Bug#897953: dvtm: Please stop shipping dvtm and dvtm-256color 
> terminfo entries
> | 
> | On 2018-05-12 16:23 +0300, kact...@gnu.org wrote:
> | 
> | > control: tags -1 +pending
> | >
> | > [2018-05-05 08:29] Sven Joachim 
> | >> In early 2017, the dvtm and dvtm-256color terminfo entries were
> | >> added to
> | >> ncurses upstream, and I would like to include them in the
> | >> ncurses-term
> | >> package, replacing the ones shipped currently in the dvtm package.
> | >> 
> | >> This requires coordinated uploads of dvtm and ncurses, adding a
> | >> versioned Breaks/Replaces on dvtm to ncurses-term and a versioned
> | >> dependency on ncurses-term to dvtm.
> | >
> | > Sure. I just uploaded dvtm_0.15-3, that depends on
> | > ncurses-term (>> 6.1+20180210-2) into DELAYED/10.
> | >
> | > As such, I expect it to arrive at 2018/05/22. I propose you to make new
> | > upload of ncurses-term with apporiate Breaks/Depends into DELAYED in
> | > such way, that our packages arrive at same time.
> | 
> | Just uploaded ncurses 6.1+20180210-4 to DELAYED/1, thanks.
> 
> The package's versions of the terminfo entries have 2-3 errors in them.

Could you please elaborate? Which package have errors? Which errors? What and 
by whom
should be done to fix them?

Bug#898701: icinga2-doc: Inconsistent gzip of documentation

[KAction]

Here is patch:

>From 51750cdb1a2da7886b72b547e1e04205eca874dc Mon Sep 17 00:00:00 2001
From: Dmitry Bogatov 
Date: Wed, 16 May 2018 07:47:01 +0300
Subject: [PATCH] Compress 01-about.md

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

diff --git a/debian/rules b/debian/rules
index 60b3d3f..4691256 100755
--- a/debian/rules
+++ b/debian/rules
@@ -92,4 +92,8 @@ override_dh_strip:
 override_dh_makeshlibs:
dh_makeshlibs --no-scripts
 
+override_dh_compress:
+   dh_compress
+   dh_compress -p icinga2-doc usr/share/doc/icinga2/markdown/01-about.md
+
 # vi: noexpandtab ts=4 sw=4 :
 

Bug#897953: dvtm: Please stop shipping dvtm and dvtm-256color terminfo entries

[KAction]

[2018-05-12 19:17] Sven Joachim 
> Sorry, I had already uploaded ncurses 6.1+20180210-3 the other day, so
> you need to adjust the dependency to (>> 6.1+20180210-3)
> or (>= 6.1+20180210-4).

Fixed and re-uploaded to DELAYED/10.

> In the meantime, it would be great if you could test the new
> terminfo entries, since they are somewhat different from the ones
> shipped in the dvtm package.  I have attached the relevant excerpt from
> ncurses' misc/terminfo.src file so that you don't need to build the
> whole ncurses package.  E.g. run
> 
> TERMINFO=/tmp/terminfo tic -x dvtm.ti && TERMINFO=/tmp/terminfo dvtm

Tested under tty: seems to work fine to me -- bash and vim work as
expected. But I am no expert in terminal emulators.

Bug#897953: dvtm: Please stop shipping dvtm and dvtm-256color terminfo entries

[KAction]

control: tags -1 +pending

[2018-05-05 08:29] Sven Joachim 
> In early 2017, the dvtm and dvtm-256color terminfo entries were added to
> ncurses upstream, and I would like to include them in the ncurses-term
> package, replacing the ones shipped currently in the dvtm package.
> 
> This requires coordinated uploads of dvtm and ncurses, adding a
> versioned Breaks/Replaces on dvtm to ncurses-term and a versioned
> dependency on ncurses-term to dvtm.

Sure. I just uploaded dvtm_0.15-3, that depends on 
ncurses-term (>> 6.1+20180210-2) into DELAYED/10. 

As such, I expect it to arrive at 2018/05/22. I propose you to make new
upload of ncurses-term with apporiate Breaks/Depends into DELAYED in
such way, that our packages arrive at same time.

Bug#896014: inotify-tools: Consider using dgit-maint-gbp workflow

[KAction]

> > I am okay to wait for your next invention. Last one I remember --
> > separate patches instead of single squashed patch in
> > dgit-maint-merge(7) was awesome.
> 
> Sorry but I don't understand this last sentence.  Perhaps you could
> rephrase.

I mean, that I see improvements in dgit, and, while /now/ I do not
understand what 'debrebase' is about, do trust you, that it will
improve my dgit experience even more.

Bug#896014: inotify-tools: Consider using dgit-maint-gbp workflow

[KAction]

[2018-04-19 10:14] Sean Whitton 
> Hello both,
> 
> If Dmitry wants to continue to use dgit-maint-merge(7), using 3.0
> (quilt) will not help.  It will not introduce any additional metadata.
> The only change will be the addition of a patch header pointing to
> dgit-repos.

What do you mean by 'additional metadata'? Patch headers generated from
git commits?
 
> Switching to dgit-maint-gbp(7) means using a patches-unapplied workflow.
> [...]

I want to be able to do raw `dpkg-buildpackage`. I guess it means
patches-applied workflow, am I right.

> In the next month or so we (Ian Jackson and I) will be releasing a
> workflow called dgit-maint-debrebase(7) which
> 
> - is patches-applied; but
> - automatically generates a perfect 3.0 (quilt) representation of the
>   Debian changes.
> 
> I.e. it should satisfy everyone.

I am okay to wait for your next invention. Last one I remember -- 
separate patches instead of single squashed patch in dgit-maint-merge(7)
was awesome.

Bug#896014: inotify-tools: Consider using dgit-maint-gbp workflow

[KAction]

control: tags -1 help

[2018-04-18 14:11] Jeremy Bicha 
> Source: inotify-tools
> Version: 3.14-5
> 
> Please consider using the dgit-maint-gbp workflow instead of the
> dgit-maint-merge workflow.
> 
> The recent switch from 3.0 (quilt) eliminates useful context and
> metadata from the Debian package itself. That metadata is now only
> available in the git repo.
> [...]

Honestly, I now consider switch to 1.0 a mistake. But I do not know how
to convert back to 3.0 in a way, that `dgit quilt-fixup` will succeed.

Bug#895914: runit-init: stage 1: missing support for emergency shell (grub 'recovery mode')

[KAction]

[2018-04-17 16:03] Lorenzo Puliti 
> Dear Maintainer,
> 
> I've found two issues with the stage 1 file you are shipping with 2.1.11
> [...]

Looks fine. I will test your changes this weekend a bit more. Please, be
patient :) Same about #895904

Thank you a lot for your contribution. It inspires me to work further.

Bug#895948: ITP: detachtty -- Utility to connect to detached interactive programs

[KAction]

[2018-04-17 20:00] Giovanni Mascellani 
> [...]
>
> Detachtty lets you run interactive programs non-interactively, and connect
> to them over the network when you do need to interact with them. It is
> somewhat similar to screen, but it is less feature-rich, therefore
> lighter and with less dependencies. It allows to connect to programs
> running on remote hosts by mean of secure SSH connections.
> 
> Detachtty was removed from Debian because it was dead upstream. Now the
> upstream development has been resumed by another developer, so it is
> sensible to repackage it.

How does it compare to dtach?

Bug#895848: RFS: inotify-tools/3.14-5

[KAction]

[2018-04-16 21:49] Sean Whitton 
> control: tag -1 +moreinfo
> control: owner -1 !
> 
> On Mon, Apr 16, 2018 at 10:25:01PM +0300, Dmitry Bogatov wrote:
> > 
> > I am looking for a sponsor for my package "inotify-tools"
> [...]
> 
> Looks like you need to update your symbols file.

Yes. Did it.  7c6c6bea1edbec1683dd9e5a5ee524819dcd053d

Bug#895811: inotify-tools: do not enable sanitizers in production

[KAction]

[2018-04-16 11:25] James Cowgill 
> part 1.1.1 text/plain1507
> Source: inotify-tools
> Version: 3.14-4
> Severity: grave
> 
> Hi,
> 
> In inotify-tools 3.14-4, all the qa sanitizers were enabled in
> DEB_BUILD_MAINT_OPTIONS. This should not be done in production.
> 
> * The man page for dpkg-buildflags explicitly states these options
> should not be used in production builds and are for debugging only.
> [...]

My fault, definitely. Somehow I missed that warning in manpage.  Will
fix.

Bug#895712: ITP: misspell-fixer -- Tool for fixing common misspellings, typos in source code.

[KAction]

[2018-04-15 00:49] Lajos Veres 
> [...]
> 
> ---
>
> Reason: I have not found any sourcecode typofixer tool in Debian.
> Some users also mentioned that their life would be a little easier
> with a packaged version.

Lintian supports some spell checking, including 'spelling error in
binary'. Maybe their power could be united?


pgpGFU4qOrUmT.pgp
Description: PGP signature

Bug#889968: RFS: inotify-tools/3.14-4

[KAction]

control: tag -1 moreinfo

[2018-04-13 16:37] Gianfranco Costamagna 
> Hello,
> 
> >The next thing you might try is `git deborig`.  But I understand just
> >asking Dmitry!

Hello. I am a bit lost about state of this RFS, but it seems I did
stupid thing with format=1.0; complicating sponsoring.

Let me settle things, provide sane package with format=3.0 (quilt), with
pristine tar. I will ping once I am ready. Sorry for noise.

Bug#848239: on purge, not remove?

[KAction]

[2018-03-24 18:42] Antoine Beaupré 
> On 2018-03-25 00:00:31, kact...@gnu.org wrote:
> >> PS: I sent you a merge request on gitlab regarding documentation, as an
> >> experiment... Let me know how it works for you!
> Attached as well. :)

Applied both patches. Thank you.

Regarding second one, I believe most debhelpers work in same way -- they
read arguments from file or ARGV. If corresponding file do not exist and
ARGV is empty, they do nothing. See 'PROMISE: DH NOOP WITHOUT sysuser'.
But if you thought that this is not oblivious, then it is really not.

Again, thank you. And, by the way, git-format-patch(1) generates
one file per patch, which is perfect for applying. You may be also
interesed in git-send-email(1).


pgpoWaNrt5mzU.pgp
Description: PGP signature

Bug#848239: on purge, not remove?

[KAction]

> PS: I sent you a merge request on gitlab regarding documentation, as an
> experiment... Let me know how it works for you!

I do not use/follow gitlab in any way, except as place to `git push`.
Probably it is my bad, I failed to make it oblivious.

Could you please send patch here?

Bug#848239: on purge, not remove?

[KAction]

[2018-03-23 12:30] Antoine Beaupré 
> Control: found -1 1.3.1
> 
> 1.3.1 removes the user on *remove*, not *purge*, is that intentional?
> 
> Maybe I missed a part of the conversation, but it seems to me it would
> be more reasonable to delete the user on purge, as it is more likely
> files owned by that user will be gone in that state, e.g. config
> files...

I agree with you. /purge/ is actually more reasonable. Will fix it.


pgpyxKR3y_sBz.pgp
Description: PGP signature

Bug#893825: reportbug --mh does not work with mmh

[KAction]

[2018-03-22 16:52] Sandro Tosi 
> thanks; you attached a patch, which seems more targetting dput-ng -
> did you prepare a patch for this bug too and you attached the wrong
> file?

Wrong file; no patch for you, sorry.

Bug#893825: reportbug --mh does not work with mmh

[KAction]

Package: reportbug
Version: 7.1.10
Severity: normal

reportbug(1) assumes, that /usr/bin/mh/comp supports -file option, which
comp(1mh) from bin:mmh does not.

Please consider using -form option instead {is it supported by nmh} or
manually creating message at $(mhpath +drafts b) and calling $EDITOR.
>From c097349b42099784319f3f7a3836ad7de74a0d83 Mon Sep 17 00:00:00 2001
From: Dmitry Bogatov 
Date: Thu, 22 Mar 2018 23:06:49 +0300
Subject: [PATCH] Make bin:dput-ng recommend py3 version of paramiko

Since dput-ng is written in Python3, there is no use from extra Python2
library. python3-paramiko is needed for `scp` method, which, although
considered deprecated by dput-ng, is recommended by
debomatic-*.debian.net services.
---
 debian/control | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/debian/control b/debian/control
index 55d3455..bf38540 100644
--- a/debian/control
+++ b/debian/control
@@ -43,7 +43,7 @@ Depends:
  ${python3:Depends},
 Recommends:
  bash-completion,
- python-paramiko,
+ python3-paramiko,
 Description: next generation Debian package upload tool
  dput-ng is a Debian package upload tool which provides an easy to use
  interface to Debian (like) package archive hosting facilities. It allows

Bug#893824: dput-ng: bin:dput-ng recommends python-paramiko

[KAction]

Package: dput-ng
Version: 1.18
Severity: normal

Should be python3-paramiko instead. Patch attached.
>From c097349b42099784319f3f7a3836ad7de74a0d83 Mon Sep 17 00:00:00 2001
From: Dmitry Bogatov 
Date: Thu, 22 Mar 2018 23:06:49 +0300
Subject: [PATCH] Make bin:dput-ng recommend py3 version of paramiko

Since dput-ng is written in Python3, there is no use from extra Python2
library. python3-paramiko is needed for `scp` method, which, although
considered deprecated by dput-ng, is recommended by
debomatic-*.debian.net services.
---
 debian/control | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/debian/control b/debian/control
index 55d3455..bf38540 100644
--- a/debian/control
+++ b/debian/control
@@ -43,7 +43,7 @@ Depends:
  ${python3:Depends},
 Recommends:
  bash-completion,
- python-paramiko,
+ python3-paramiko,
 Description: next generation Debian package upload tool
  dput-ng is a Debian package upload tool which provides an easy to use
  interface to Debian (like) package archive hosting facilities. It allows

Bug#891005: New version

[KAction]

Hello!

New version (c762cf4202b415b6b76193cc0c8ddb1faf9955f0), now with
autopkgtests. 

Review is welcome. If you have access to exotic architecture, review is
twice as welcome ;)

Bug#892000: nm.debian.org: Key is not update properly

[KAction]

control: close -1

> > > Maybe it worth documenting, from what exactly keyserver does nm.debian.org
> > > fetch information?
> > 
> > I have done a --recv-keys from pgp.mit.edu and pushed to sks-keyservers
> > and then triggered a refresh on nm.d.o, and it's now shown.
> > 
> > > What constitutes 'very soon'? My expires in two months. Is it considered
> > > soon? And if it is, what expiration time is recommended?
> > 
> > Two months is definitely two short. 
> > [...]

Thank you! I changed expire date, uploaded to sks-keyservers, and now
nm.debian.org is satisfied.

Bug#892000: nm.debian.org: Key is not update properly

[KAction]

[2018-03-04 12:07] Mattia Rizzolo 
>
> part 1 text/plain2636
> Control: tag -1 moreinfo
> 
> On Sun, Mar 04, 2018 at 02:46:34AM +0300, Dmitry Bogatov wrote:
> > I am in new member process (https://nm.debian.org/process/448).  It
> > seems that something is not okay about my key. The web page says that
> > my key miss second DD signature and expires soon. Pressing 'update'
> > button does not help.
> > 
> > I do not know what is considered 'expires soon', but my key actually do
> > have two DD signatures, and they are uploaded on both public keyservers
> > and keyring.debian.org:
> 
> Are you sure you pushed to some public keyserver?  I seem unable to get
> it as well…
> [...]

Interesting. Here is link to pgp.mit.edu[0], where there is signature
from  is mentioned. So, maybe there is issue with servers
synchronization?

[0]: https://pgp.mit.edu/pks/lookup?op=vindex=0x2E20FEEE71FC7D81

Maybe it worth documenting, from what exactly keyserver does nm.debian.org
fetch information?

> So I can only confirm that:
> [...]
> 2) your key is about to expire very soon.

What constitutes 'very soon'? My expires in two months. Is it considered
soon? And if it is, what expiration time is recommended?

Bug#891005: RFS: gdbm/1.14.1-5

[KAction]

[2018-02-28 10:21] Ansgar Burchardt 
> Gianfranco Costamagna writes:
> > I think there is nothing to worry about :)
> >
> > this is the path:
> > /usr/lib/*/diet/*/libgdbm.a
> 
> It is a problem as the package might provide different functionality
> when someone else builds and uploads it.

Well, should I introduce whole binary package with just one single
gdbm.a instead?

Bug#891005: RFS: gdbm/1.14.1-5

[KAction]

Hello.

> Anyhow, if you want to enable, you can do something like this, to make
> me and you happy, and then easily revert when new bugs are opened
 
HAVE_DIETLIBC=no 
ifeq ($(shell dpkg -s dietlibc-dev | grep -o installed), installed)
DIET_LIBDIR := $(shell diet -L gcc)
HAVE_DIETLIBC=yes 
endif

ifeq ($(shell dpkg-vendor --derives-from Ubuntu && echo yes),yes)
HAVE_DIETLIBC=no 
endif

Thanks, I will add this snippet.

> If you want to enable it, please make sure it works :)

Okay. I will add some autopkgtests.

Bug#877331: sponsorship-requests: nix/1.1.15 (ITP 877019) -- Purely functional package manager

[KAction]

>   W: nix: manpage-has-errors-from-man usr/share/man/man1/nix-store.1.gz 1235: 
> warning [p 13, 9.7i]: can't break line
>   W: nix: binary-without-manpage usr/bin/nix-generate-patches
> 
> I hope this is acceptable.

// I am not DD; did not read source.

As far as I know, lintian warnings and errors are never acceptable. And,
as a user, I understand, why missing manpage is treated so severe.

I am not familiar with nix, but if nix-generate-patches is not
end-user-command, you could install it into private directory, that
would fix second warning.
 

Bug#891005: RFS: gdbm/1.14.1-5

[KAction]

[2018-02-21 17:02] Gianfranco Costamagna 
> >!Important! This upload re-enables diet libc support {conditional, via
> >build profiles}. Input from developers, experienced with Debian
> >bootstrap is very, very welcome.
> 
> Since this is causing troubles in Ubuntu (Matthias, please give your opinion 
> here),
> because dietlibc is in main, and gives also troubles to maintain the list of 
> dietlibc
> architectures where it is available, since it causes troubles using dietlibc
> (the build seems failing), I would prefer to actually implement it again once 
> dietlibc folks
> makes the whole stuff *working*.
> 
> [... description of problems in Ubuntu ...]

With all my respect, I am very relucant to solve problems of Ubuntu at
expense of Debian output. What exactly is wrong, Debian-wise, in package
we are discussing, apart the need to specify long list of architectures,
so I could fix it?

> I would prefer a patch from dietlibc folks, with an use case of *why*
> they need this static library, rather than building/including
> something that caused 4 bugs in Debian, a lot of pain in Ubuntu (and
> probably was even broken).
>
> What is your opinion? I would like to understand why we need this, and
> if this had even worked.

You ask good question. 

Short answer: 
  because you need it to link program, using gdbm, with diet libc,
  resulting small static executable.

Full answer: 
  because I believe Debian should provide not only libraries for
  build-dependencies of something in /bin, but also libraries for
  developers to develop with.

  I did some search, and seems this is already happening. We have a lot
  of leaf libraries (mostly perl and java), for example: 
- libxmlenc-java 
- libwx-scintilla-perl

Or maybe we just need Guix/Nix?

> The other stuff looks good to me :)

That is good news.

Bug#890294: asymptote: complex eval-using code triggers assert failure

[KAction]

Hi!

[2018-02-14 18:54] Hilmar Preuße 
> > Hello! Following piece of code is meant to create wrapper structures
> > around primitive types, simplifying creation of generic code.
> > 
> I simply copy any pasted your code into a file an tried to process it.
> Hope this was correct. Please confirm.

Yes, this is correct.
> 
> > Unfortunately, following error is produced instead:
> > 
> > asy: exp.cc:43: virtual void absyntax::exp::transAsType(trans::coenv&, 
> > types::ty*): Assertion `t->kind==ty_err
> or || equivalent(t,target)' failed.
> > 
> hille@amd64-sid:~$ asy -k asy.asy
> asy: exp.cc:43: virtual void absyntax::exp::transAsType(trans::coenv&,
> types::ty*): Assertion `t->kind==ty_error || equivalent(t,target)' failed.
> Aborted (core dumped)

Great, you see exactly the same error as I do.

> I got a core dump, the back trace is attached. I guess we have to
> escalate this to upstream. I did not have a look at their bug tracker
> yet as sf is currently down.

Yes, we definitely should send it upstream. You will do it, don't you?

Bug#889968: RFS: inotify-tools/3.14-4

[KAction]

> > [2018-02-12 13:07] Sean Whitton 
> >> > Last version is at bacef877c2f9293f9e1fd624b32d5306d7bc3c27 Maybe,
> >> > you could try again?
> >>
> >> Still FTBFSs.  Log attached.
> >>
> >> I suspect that the debomatic sid chroot is out-of-date.
> >
> > Stange. Just did 'sbuild-update -udcar', and still fails to reproduce.
> > I have same version of build-essential, by the way.
> >
> > Added debomatic admin into CC, maybe he has any opinion about
> > situation.  If not, I could remove sanitize support, although I am not
> > so happy with it. Or maybe you could tar.gz your chroot and upload
> > somewhere?
> 
> I tried deleting and rebuilding my chroot and disabling ccache and
> tmpfs, and I tried building on my i386 machine, again after rebuilding,
> disabling ccache and disabling tmpfs.
> 
> In all cases the package FTBFS.  I attach my i386 log..
> 
> I'm not sure how to proceed.  I can't upload this if I can't build it,
> and my configuration seems sufficiently standard that even if you are
> able to build it, we shouldn't upload.  Maybe we should try disabling
> sanitize support for now.

I understand your concerns, Sean. I invited Gianfranco into thread,
maybe he would sponspor instead.  Ah, another absurd idea. What about
your building package on debomatic? Maybe for some reason your source
package, generated from git repository, differs from mine? Also, could
you please try to run binaries, built by debomatic? Do they crash?

Hello! Gianfranco, could you please consider building and, probably,
sponsoring this package? We have issue, that it FTBFS on Sean's setup,
but builds on mine and on debomatic. As debomatic admin notified,
debomatic is not out-of-date {updated this sunday}.

https://salsa.debian.org/iu-guest/inotify-tools

Bug#890293: [PATCH] New binary package: wesperanto

[KAction]

Package: eo-spell
Version: 2.1.2000.02.25-54
Severity: wishlist

Hello! For some spell checking programs, like built-in Vim one, the most
simple way to setup spell-checking is to have raw, one word per line
list of correct words. It seems to be established practice to name
binary packages in format 'w{language}', like wamerican, wnorwegian or
wukrainian.

Attached debdiff adds new binary package 'wesperanto' to src:eo-spell. I
know, that it is not perfect, since it should also 'Provide: wordlist',
but, in my defense, wnorwegian also does not provide wordlist.

This patch creates list in utf-8 encoding (obliviously), but may it be
useful to have in addition, 'wesperanto-cx'?

Thank you for your attention, and please consider applying patch.
diffstat for eo-spell-2.1.2000.02.25 eo-spell-2.1.2000.02.25

 changelog  |7 +++
 control|9 +
 cx2utf8.sed|   13 +
 rules  |3 +++
 wesperanto.install |1 +
 5 files changed, 33 insertions(+)

diff -Nru eo-spell-2.1.2000.02.25/debian/changelog eo-spell-2.1.2000.02.25/debian/changelog
--- eo-spell-2.1.2000.02.25/debian/changelog	2015-09-22 13:16:05.0 +0300
+++ eo-spell-2.1.2000.02.25/debian/changelog	2018-01-24 17:52:43.0 +0300
@@ -1,3 +1,10 @@
+eo-spell (2.1.2000.02.25-55) unstable; urgency=low
+
+  * New binary package: wesperanto, providing plain list of esperanto words.
++ Thanks: Dmitry Bogatov 
+
+ -- Agustin Martin Domingo   Wed, 24 Jan 2018 17:52:43 +0300
+
 eo-spell (2.1.2000.02.25-54) unstable; urgency=medium
 
   * debian/control::myspell-eo: Use Conflicts where needed.
diff -Nru eo-spell-2.1.2000.02.25/debian/control eo-spell-2.1.2000.02.25/debian/control
--- eo-spell-2.1.2000.02.25/debian/control	2015-09-22 13:13:55.0 +0300
+++ eo-spell-2.1.2000.02.25/debian/control	2018-01-24 17:52:43.0 +0300
@@ -24,6 +24,15 @@
  Plena Ilustrita Vortaro, with additional country/language names.  It
  accepts Latin-3, 'cx' and '^c' forms.
 
+Package: wesperanto
+Architecture: all
+Depends: ${misc:Depends}
+Description: Esperanto dictionary words for /usr/share/dict
+ This package provides the file /usr/share/dict/esperanto,
+ containing a list of Esperanto words in utf-8 encoding. 
+ This list can be used by spelling checkers, and by programs
+ such as look(1).
+
 Package: myspell-eo
 Architecture: all
 Depends: ${misc:Depends},
diff -Nru eo-spell-2.1.2000.02.25/debian/cx2utf8.sed eo-spell-2.1.2000.02.25/debian/cx2utf8.sed
--- eo-spell-2.1.2000.02.25/debian/cx2utf8.sed	1970-01-01 03:00:00.0 +0300
+++ eo-spell-2.1.2000.02.25/debian/cx2utf8.sed	2018-01-24 17:52:43.0 +0300
@@ -0,0 +1,13 @@
+#/usr/bin/sed -f
+s/cx/ĉ/g
+s/hx/ĥ/g
+s/jx/ĵ/g
+s/sx/ŝ/g
+s/ux/ŭ/g
+s/gx/ĝ/g
+s/Cx/Ĉ/g
+s/Hx/Ĥ/g
+s/Jx/Ĵ/g
+s/Sx/Ŝ/g
+s/Ux/Ŭ/g
+s/Gx/Ĝ/g
diff -Nru eo-spell-2.1.2000.02.25/debian/rules eo-spell-2.1.2000.02.25/debian/rules
--- eo-spell-2.1.2000.02.25/debian/rules	2015-06-18 18:10:50.0 +0300
+++ eo-spell-2.1.2000.02.25/debian/rules	2018-01-24 17:52:43.0 +0300
@@ -80,6 +80,9 @@
 	cat kune.txt | ispell -d ./eo -e | tr -s ' ' '\n' | sort -u > $(TMP_BUILD)/eo-cx.wl
 	cat $(TMP_BUILD)/eo-cx.wl | grep -v -e "-'$$" | prezip -s -c | gzip -9n -c > $(TMP_BUILD)/eo-cx.cwl.gz
 	install -m 0644 debian/aspell/eo-cx.dat debian/aspell/eo-cx.multi $(TMP_BUILD)
+	unmunch $(TMP_BUILD)/eo.dic $(TMP_BUILD)/eo.aff \
+		| iconv -f latin3 -t utf-8 \
+		| sed -f debian/cx2utf8.sed > $(TMP_BUILD)/esperanto
 
 	touch $@
 
diff -Nru eo-spell-2.1.2000.02.25/debian/wesperanto.install eo-spell-2.1.2000.02.25/debian/wesperanto.install
--- eo-spell-2.1.2000.02.25/debian/wesperanto.install	1970-01-01 03:00:00.0 +0300
+++ eo-spell-2.1.2000.02.25/debian/wesperanto.install	2018-01-24 17:52:43.0 +0300
@@ -0,0 +1 @@
+esperanto /usr/share/dict

Bug#890297: [PATCH] ticgit: proposed completion script

[KAction]

Package: ticgit
Version: 1.0.2.17-2
Severity: wishlist

Hello! I wrote bash-completion script for tic(1).  While it is not
perfect and do not cover some options, I think it is still much better
than nothing. Please, consider including.

For your convenience, I attach both just script and debdiff.
# -*- shell-script -*-
# Copyright (C) 2017 Dmitry Bogatov
#
# This program is free software: you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation, either version 3 of the License, or
# (at your option) any later version.
#
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
# GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# along with this program.  If not, see .
#

# Ticket is represented by directory in 'ticgit' branch, which has
# TICKET_ID file with directory name in it.
#
# Real ticketId, as references by all subcommands of 'ticgit' is a
# hash of blob, corresponding to content of that TICKET_ID file.
#
# This function enumerates all tickets with ID starting with ${1}.
#
# Use of low-level representation of TicGit tickets and Git blobs is about
# factor 30 faster than parsing output of `ti list'.
_ticgit_tickets () {
local prefix=${1};
local names=$(git ls-tree -d --name-only ticgit 2>/dev/null) || return

for name in ${names} ; do
ticket=$(printf "blob %d\0%s\n" $(( 1 + ${#name})) "${name}"|sha1sum)
if [[ $prefix = "${ticket:0:${#prefix}}" ]] ; then
echo "${ticket:0:6}"
fi
done
}

_ticgit_tags () {
local prefix=${1}
local tree=$(git ls-tree -r ticgit --name-only 2>/dev/null) || return
for tag in $(echo "${tree}" | awk -FTAG_ '{ print $2 }') ; do
if [[ $prefix = "${tag:0:${#prefix}}" ]] ; then
echo "${tag}"
fi
done
}

_ticgit_complete_ticket_or_options () {
case "${cur}" in
-*) COMPREPLY=($(compgen -W "${options}" -- "${cur}")) ;;
*) COMPREPLY=($(_ticgit_tickets "${cur}")) ;;
esac
}

# Completion functions for specific subcommands
_ticgit_complete_show () {
local options='--help --version --full'
_ticgit_complete_ticket_or_options
}

_ticgit_complete_assign () {
local options='--version --help --user --checkout'
case "${prev}" in
-c|--checkout) COMPREPLY=($(_ticgit_tickets "${cur}")) ;;
-u|--user) ;; # FIXME: how to complete user?
*) _ticgit_complete_ticket_or_options ;;
esac
}

_ticgit_complete_checkout () {
local options='--help --version'
_ticgit_complete_ticket_or_options
}

_ticgit_complete_comment () {
local options='--help --version --file --message'
case "${prev}" in
-f|--file) _filedir ;;
-m|--message) ;;
*) _ticgit_complete_ticket_or_options ;;
esac
}

_ticgit_complete_list () {
local options='--help --version --list --saveas --assigned
--states --tags --order'
case "${prev}" in
-S|--saveas) ;;
-a|--assigned) #FIXME: not implemented
;;
-t|--tags) COMPREPLY=($(_ticgit_tags "$cur")) ;;
-s|--states)
COMPREPLY=($(compgen -W "$states" -- "$cur"))
;;
-o|--order)
local orders='assigned state date title'
COMPREPLY=($(compgen -W "$orders" -- "$cur"))
;;
*) COMPREPLY=($(compgen -W "$options" -- "$cur")) ;;
esac
}

_ticgit_complete_new () {
local options='--help --version --title'
case "${prev}" in
-t|--title) ;;
*) _ticgit_complete_ticket_or_options ;;
esac
}

_ticgit_complete_points () {
local options='--help --version'
if [[ $cword -eq 2 ]] ; then
_ticgit_complete_ticket_or_options
fi
}

_ticgit_complete_state () {
if [[ $cword -eq 2 ]] ; then
COMPREPLY=( $(_ticgit_tickets "${cur}")
$(compgen -W "${states}" -- "${cur}") )
else
COMPREPLY=( $(compgen -W "${states}" -- "${cur}") )
fi
}

_ticgit_complete_tag () {
if [[ $cword -eq 2 ]] ; then
COMPREPLY=( $(_ticgit_tickets "${cur}") )
else
COMPREPLY=( $(compgen -W "--delete" -- "${cur}")
$(_ticgit_tags "${cur}") )
fi
}

_ticgit () {
local states='hold invalid open resolved'
local cur prev word cword
_init_completion || return

local commands='assign checkout comment help init list new points
recent show state sync tag'

if [[ $cword -eq 1 ]] ; then
COMPREPLY=($(compgen -W "$commands" -- "$cur"))
else
case ${COMP_WORDS[1]} in
help) COMPREPLY=($(compgen -W "$commands" -- "$cur")) ;;
init|resent)
COMPREPLY=($(compgen -W '--help --version' -- "$cur"))
;;

Bug#890295: gettext-el: missing defcustom

[KAction]

Package: gettext-el
Version: 0.19.8.1-2
Severity: normal

Hello!

po-mode runs `po-subedit-mode-hook' in po-mode.el:2447, but that hook is
only mentioned in description of `po-edit-string()' function, but is not
declared as customizable variable (defvar/defcustom).

It makes it impossible to configure it with Custom or locate that hook
with `describe-variable()'[1]. I would suggest adding following lines:

(defcustom po-subedit-mode-hook nil
  "List of functions to run in buffer, created by `po-edit-string'."
  :group 'po
  :typee 'hook)

[1] Personally, I found this hook by reading the sources. Not very
user-friendly.

Bug#890294: asymptote: complex eval-using code triggers assert failure

[KAction]

Package: asymptote
Version: 2.41-4
Severity: normal

Hello! Following piece of code is meant to create wrapper structures
around primitive types, simplifying creation of generic code.

var casts = quote {
public TWrap operator cast(TInner value)
{
var obj = new TWrap;
obj.value = value;
return obj;
}
public TInner operator cast(TWrap obj)
{
return obj.value;
}
};

void define_wrapper(string type)
{
string wrapper = 'A' + type;
string prog = 'public struct ' + wrapper + '{ ' + type + ' 
value; };';
eval(prog, true);
eval('typedef ' + wrapper + ' TWrap', true);
eval('typedef ' + type + ' TInner', true);
eval(casts, true);
}
define_wrapper('int');
define_wrapper('real');


Unfortunately, following error is produced instead:

asy: exp.cc:43: virtual void absyntax::exp::transAsType(trans::coenv&, 
types::ty*): Assertion `t->kind==ty_error || equivalent(t,target)' failed.

Problem is present in both versions in sid and stretch.

Bug#890296: xinit: startx ignores SIGTERM

[KAction]

Package: xinit
Version: 1.3.4-3+b1
Severity: normal

Hello!

*startx* script ignores many signals, SIGTERM in particular; it causes
problems with process supervision.

Please consider applying following patch, which fulfil intended purpose
of ``trap`` statement, keeping process resposible to signals. 

PS. Just curious, under what circumstances would a /bin/sh receive a SIGILL?

diff -rU7 xinit-1.3.4:original/startx.cpp xinit-1.3.4/startx.cpp
--- xinit-1.3.4:original/startx.cpp 2017-10-02 01:33:07.556320513 +0300
+++ xinit-1.3.4/startx.cpp  2017-10-02 01:33:35.828321881 +0300
@@ -266,15 +266,15 @@
 echo "Couldn't create cookie"
 exit 1
 fi
 dummy=0

 XCOMM create a file with auth information for the server. ':0' is a dummy.
 xserverauthfile=$HOME/.serverauth.$$
-trap "rm -f '$xserverauthfile'" HUP INT QUIT ILL TRAP KILL BUS TERM
+trap "rm -f '$xserverauthfile'" EXIT
 xauth -q -f "$xserverauthfile" << EOF
 add :$dummy . $mcookie
 EOF
 #if defined(__APPLE__) || defined(__CYGWIN__)
 xserverauthfilequoted=$(echo ${xserverauthfile} | sed "s/'/'''/g")
 serverargs=${serverargs}" -auth '"${xserverauthfilequoted}"'"
 #else

Bug#889968: RFS: inotify-tools/3.14-4

[KAction]

[2018-02-12 13:07] Sean Whitton 
> > Last version is at bacef877c2f9293f9e1fd624b32d5306d7bc3c27 Maybe, you
> > could try again?
> 
> Still FTBFSs.  Log attached.
> 
> I suspect that the debomatic sid chroot is out-of-date.

Stange. Just did 'sbuild-update -udcar', and still fails to reproduce.
I have same version of build-essential, by the way.

Added debomatic admin into CC, maybe he has any opinion about situation.
If not, I could remove sanitize support, although I am not so happy with
it. Or maybe you could tar.gz your chroot and upload somewhere?

Bug#889968: RFS: inotify-tools/3.14-4

[KAction]

[2018-02-10 12:13] Sean Whitton 
> - It FTBFSs for me.  Log attached.

Look, debomatic build is succesful:

  
http://debomatic-amd64.debian.net/distribution#unstable/inotify-tools/3.14-4/buildlog

Last version is at bacef877c2f9293f9e1fd624b32d5306d7bc3c27
Maybe, you could try again?

Bug#889968: RFS: inotify-tools/3.14-4

[KAction]

[2018-02-10 12:13] Sean Whitton 
> Review of 3c46a878fd294e9af9f8e7c225d16e8aceb960cf:
> 
> - It looks like you added an entry to the changelog for 3.13-3 that
>   should have been in the changelog for 3.13-4.

Good catch. Will fix it.
 
> - I'm not sure that DPKG_EXPORT_BUILDFLAGS = 1 will have any effect
>   unless you export it?  Not sure; I have not used this feature.

This variable is checked not by external programs, but by make code in
/usr/share/dpkg/[...]. It is okay.

> - It FTBFSs for me.  Log attached.

Oh, I see, fails on ./configure. Unfortunately, I can't reproduce on my
own laptop. Maybe it is because it is i386. I am working on getting it
built on debomatic-amd64. 

I will ping you again, when I get results from debomatic.


pgp4BUzk9Gk_s.pgp
Description: PGP signature

Bug#747083: ITP: xcape -- use a modifier key as another key

[KAction]

Package: wnpp
Severity: wishlist
Owner: KAction kact...@gnu.org

* Package name: xcape
  Version : 1.1
  Upstream Author : Albin Olsson albin.ols...@gmail.com
* URL : https://github.com/alols/xcape
* License : GPL
  Programming Lang: C
  Description : use a modifier key as another key
 xcape allows you to use a modifier key as another key when pressed and
 released on its own. Note that it is slightly slower than pressing the
 original key, because the pressed event does not occur until the key is
 released. The default behaviour is to generate the Escape key when Left
 Control is pressed and released on its own. (If you don't understand why
 anybody would want this, I'm guessing that Vim is not your favourite text
 editor ;)

This package is currently the only maintained of its kind, as far
as I know. I am using it around year, no problems occured.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org