Bug#918134: O: dpatch -- patch maintenance system for Debian source packages

[Gergely Nagy]

Package: wnpp
Severity: normal

I *think* the Alioth archives are up-to-date. Or at least not too far
behind.

Description: patch maintenance system for Debian source packages
 dpatch is an easy to use patch system for Debian packages, somewhat
 similar to the dbs package, but much simpler to use.
 .
 It lets you store patches and other simple customization templates in
 debian/patches and otherwise does not require much reorganization of
 your source tree. To get the patches applied at build time you simply
 need to include a makefile snippet and then depend on the
 patch/unpatch target in the build or clean stage of debian/rules - or
 you can use the dpatch patching script directly.
 .
 It can easily apply patches only on specific architectures if needed.

-- 
|8]

Bug#918133: O: aalib -- ASCII art library

[Gergely Nagy]

Package: wnpp
Severity: normal

I'm orphaning aalib. It's in reasonable state, I believe, but it might
need some updates here and there (mostly to change the Vcs headers to
something that exists... the alioth archives are - I think - up to
date).

Package description is:

Description: ASCII art library
 AAlib is a portable ASCII art graphics library. Internally, it works like
 a graphics display, but the output is rendered into gorgeous platform
 independent ASCII graphics.

-- 
|8]

Bug#918132: O: riemann-c-client -- C language client library for the Riemann event stream processor

[Gergely Nagy]

Package: wnpp
Severity: normal

I'm orphaning riemann-c-client. I still intend to maintain it upstream
(there's not much to maintain there, mind you), but I no longer wish to
maintain the Debian package.

Feel free to pick it up.

The package description is:

Description: C language client library for the Riemann event stream processor
 Riemann is a network event stream processor, intended for analyitics,
 metrics and alerting; and to glue various monitoring systems together.
 .
 This library provides a C language client, with a simple but
 convenient API, to connect to Riemann, send events and run queries
 against it.

(There's also a -dev package, and one with utilities based on the library.)

-- 
|8]

Bug#851746: Orphaning dh-exec

[Gergely Nagy]

retitle 851746 dh-exec -- Scripts to help with executable debhelper files
thanks

You do not need to contact me if you want to adopt the package, just go
ahead with it.

-- 
|8]

Bug#916232: check breaks riemann-c-client autopkgtest

[Gergely Nagy]

On Tue, Dec 11, 2018 at 7:42 PM Paul Gevers  wrote:
> autopkgtest [04:39:51]: test symver: [---
> In file included from tests/check_symver.c:9:
> tests/tests.h:10: warning: "ck_assert_float_eq" redefined
>  #define ck_assert_float_eq(X, Y) \
>
> In file included from tests/check_symver.c:3:
> /usr/include/check.h:784: note: this is the location of the previous
> definition
>  #define ck_assert_float_eq(X, Y) _ck_assert_floating(X, ==, Y, float, "")
>

This appears to be an issue in riemann-c-client. I'll fix it, test it,
and upload a new version tomorrow. Thanks for reporting the issue!

-- 
|8]

Bug#910608: RFS: libtheft/0.4.5-1 ITP #910296

[Gergely Nagy]

>>>>> "Paul" == Paul Wise  writes:

Paul> On Sun, Oct 21, 2018 at 1:54 PM Gergely Nagy wrote:
>> - The package build-depends on `debhelper-compat (= 11)`, which works,
>> but it's a virtual package. I'd suggest build-depending on `debhelper
>> (>= 11)`, and adding a `debian/compat` file with "11" as its content.
>> This will get rid of one of the warnings on mentors, too.

Paul> debhelper-compat is the new replacement for debian/compat that aims to
Paul> get rid of the repetition of the debhelper compat level in two places
Paul> and is also nicer for backporters than the debhelper dep you
Paul> suggested.

Ah, my bad. I checked debhelper(7) when I saw it, but forgot that I'm on
testing, not unstable. Indeed, the build-depends is fine then as it is.

Thanks!

-- 
|8]

Bug#910608: RFS: libtheft/0.4.5-1 ITP #910296

[Gergely Nagy]

Hi!

I just had a quick look at the libtheft packaging on mentors, and
noticed a few things that at the moment, prevent me from sponsoring the
package. These are:

- I was unable to find the public part of your GPG key, thus, was unable
  to verify the signature on the source package. Where can one find it?
  (Uploading it to a public key server might be best).
- The package build-depends on `debhelper-compat (= 11)`, which works,
  but it's a virtual package. I'd suggest build-depending on `debhelper
  (>= 11)`, and adding a `debian/compat` file with "11" as its content.
  This will get rid of one of the warnings on mentors, too.
- debian/copyright does not document the license of `src/theft_hash.c`
  (public domain, but that needs to be documented too).
- debian/copyright does not document the license and author of
  `debian/*`. In most cases - and theft is no exception - the Debian
  packager is not the upstream author. If unspecified, the `*` wildcard
  applies to `debian/*` too, which would be incorrect.
- The control file does not set a Homepage - a minor thing, but while
  fixing the other issues, might as well fix this one, and point the
  Homepage field in debian/control to theft's GitHub.

Other than these, the package looks ok. Can you fix the above?

Drop me an email when done, and I'll have another look.

-- 
|8]

Bug#908226: Unicode input does not actually input the selected symbol

[Gergely Nagy]

An additional data point: I upgraded to the latest Kitty in testing
today, and noticed a thing in the changelog:

 + Add support for IME via IBus, enabled by setting GLFW_IM_MODULE=ibus

So I exported that variable before starting kitty, and inputting unicode
works now. It does not pop up the symbol selection kitten, but lets me
enter the code (which is perfect, this is the same behaviour
gnome-terminal has).

As far as I'm concerned, this issue can be closed.

-- 
|8]

Bug#908226: Unicode input does not actually input the selected symbol

[Gergely Nagy]

> "James" == James McCoy  writes:

James> Your earlier mail leads me to believe you may have already tried 
this,
James> but just to be sure... If you manually run the kitty command from an
James> existing terminal, are any diagnostics displayed in the original
James> terminal?

When I run kitty from an existing terminal, there's no output - neither
diagnostics, nor anything else - in the original terminal. :(

I tried --debug-font-fallback, but that suggests that the fallback font
is found (which makes sense, since the symbol selection kitten does
correctly show the symbols).

-- 
|8]

Bug#908226: Unicode input does not actually input the selected symbol

[Gergely Nagy]

>>>>> "James" == James McCoy  writes:

James> On Fri, Sep 07, 2018 at 04:43:17PM +0200, Gergely Nagy wrote:
>> I can bring up the unicode input overlay with C-S-u, but no matter what 
symbol I
>> select there, once I press Enter to input it, nothing happens, no symbol 
appears
>> in my terminal.

James> At the time you reported this, I was seeing the same behavior.  
However,
James> now (granted on a different computer) things are working as expected.
James> Can you still reproduce this?

Yep, still happens as it did then (running up-to-date testing as of
about two days ago).

-- 
|8]

Bug#908226: Unicode input does not actually input the selected symbol

[Gergely Nagy]

Package: kitty
Version: 0.11.3-1
Severity: normal
Tags: upstream

I can bring up the unicode input overlay with C-S-u, but no matter what symbol I
select there, once I press Enter to input it, nothing happens, no symbol appears
in my terminal. My kitty configuration consists of color settings only, no font
configured. I tried with symbols that otherwise work, like 67 ('g'), but that
does not seem to have any effect at all either. Kitty does not log an error,
either, as far as I see.

I tried with different programs running in the terminal, but that did not help
either: whether I used zsh, bash, or even cat, no symbol was input.

-- System Information:
Debian Release: buster/sid
  APT prefers testing
  APT policy: (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.17.0-3-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages kitty depends on:
ii  kitty-terminfo  0.11.3-1
ii  libc6   2.27-5
ii  libfontconfig1  2.13.0-5
ii  libfreetype62.8.1-2
ii  libharfbuzz0b   1.8.8-2
ii  libpng16-16 1.6.34-2
ii  libpython3.63.6.6-1
ii  libx11-62:1.6.6-1
ii  libx11-xcb1 2:1.6.6-1
ii  libxkbcommon-x11-0  0.8.2-1
ii  libxkbcommon0   0.8.2-1
ii  python3 3.6.5-3
ii  python3.6   3.6.6-1
ii  zlib1g  1:1.2.11.dfsg-1

Versions of packages kitty recommends:
pn  kitty-doc  

kitty suggests no packages.

-- no debconf information

Bug#889006: dh-autoreconf is run before patching

[Gergely Nagy]

Sorry for the brevity, I'm a tad short on time right now: yeah, I'm ok
with a 0-day NMU of dpatch, that tweaks the sequence, and includes the
patch for #868978 as well.

Thanks!

-- 
|8]

Bug#851746: RFA: dh-exec -- Scripts to help with executable debhelper files

[Gergely Nagy]

Package: wnpp
Severity: normal

I request an adopter for the dh-exec package, ideally someone familiar
with debhelper and surrounding tools. Best would be to have it under the
debhelper team umbrella.

The package is in a reasonable shape, but there are some issues that
would need work - some of that work has been done in the git tree (which
at the moment, is under my personal account on GitHub, but should be
moved to somewhere else - talk to me about it!), but has not been
uploaded.

Some of the things in it are... scary. The adopter will need reasonable
Perl knowledge, and a deeper understanding of Debhelper. It's not for
the faint of heart. But it's also not as bad as I may paint it.

The package description is:
 Debhelper (in compat level 9 and above) allows its config files to be
 executable, and uses the output of such scripts as if it was the
 content of the config file.
 .
 To ease and standardize the most common tasks, this package provides
 a few solutions to help constructing such executable scripts:
 .
  * A way to ease variable substitution, from environment variables or
dpkg-architecture.
  * Ability to filter files by architecture or build profile, within a
single debhelper control file.
  * An extension to dh_install and dh_installman, with the ability to
rename files.

If anyone is interested, please contact me first, I want to see this in
good hands.

-- 
|8]

Bug#849917: O: ivykis -- Asynchronous I/O readiness notification library

[Gergely Nagy]

Package: wnpp
Severity: normal

I'm orphaning the ivykis library, primarily used by syslog-ng. I don't
use neither syslog-ng, nor ivykis anymore, and lack the time and
energy to maintain it properly. The latest packaging is on Alioth at
collab-maint/ivykis, but I lost bits and pieces of the puzzle to
properly create a package from that. I seem to recall I was using
gitpkg, but I forgot how, over the years. Whoever takes the package
on, may have to do some digging, I'm afraid.

Upstream is friendly and responsive, and there has been little
movement in development over the recent years. There is a new upstream
version that should be packaged, however.

The package description, for reference, is just below:

Description: Asynchronous I/O readiness notification library
 The ivykis library is a thin, portable wrapper around OS-provided
 mechanisms such as epoll(4), kqueue(2) and poll(2). It was mainly
 designed for building high-performance network applications, but can
 be used in any event-driver application that uses pollable file
 descriptors as its event sources.
 .
 Programs written to the ivykis API are generally single-threaded (or
 use only a small number of threads), and never block on I/O. All
 input and output is done in a nonblocking fashion, with I/O readiness
 notification delivered via callback functions.

-- 
|8]

Bug#831786: dh-exec: breaks dh_install --fail-missing

[Gergely Nagy]

Control: tag -1 pending

Hi!

To summarize the case quickly for Niels: if we have a package that has
an arch:all and an arch:any binary, and uses dh_install --fail-missing,
and dh-exec in either (or both) binary packages' .install file, and we
do an arch-indep or arch-only build, --fail-missing will break.

This is because debhelper passes DH_CONFIG_ACT_ON_PACKAGES with only the
relevant package included in the list. This is correct. However, in this
case, dh-exec's install becomes a noop for the other package, and that
will break --fail-missing.

So the easiest fix for this would be to ignore the noop if we are doing
an arch-indep or arch-only build. Problem is, the only currently
existing way I can figure out whether this is the case, is
DH_INTERNAL_OPTIONS. That has been around for a while, and - as far as I
see - has not changed in a way since its introduction that would prevent
dh-exec from (ab)using this environment variable.

As such, I have a fix prepared[1], that does just this: if -a or -i is
in DH_INTERNAL_OPTIONS, then dh-exec will ignore
DH_CONFIG_ACT_ON_PACKAGES. This appears to fix the issue, and does not
break any of the existing test cases, so I'm fairly sure it should work
in practice.

 [1]: 
https://github.com/algernon/dh-exec/commit/a92e18250953279a5393e0426d7616736cc9a5dd#diff-369c5eb9f23b41f57a45ad212f711d2c

I'm Cc-ing Niels too, in case he has a better idea, and to see if he
sees anything wrong with the approach I may have missed.

I plan to upload dh-exec sometime next week (likely at the end of it,
too), but I'd prefer to hear some feedback from the debhelper side too.

Thanks for reporting the bug, and for Niels in advance for his input!

-- 
|8]

Bug#498067: pending

[Gergely Nagy]

Control: tag -1 pending

This is fixed in git, has been for a while, and is waiting for an
upload. If all goes well, that will happen in a few days.

-- 
|8]

Bug#198507: dh_install: fails if filenames have an embedded space

[Gergely Nagy]

> "Niels" == Niels Thykier  writes:

>> [...]
>> 
>> You only need to teach debhelper to handle the \-escaped spaces.
>> 

Niels> I am not really sure I want to use \-escaped spaces. Besides being a
Niels> pain in themselves, it would also suggest that the glob characters 
can
Niels> be escaped.  Which leads us to Joey Hess's comment in #198507#17.

Niels> If we go down that route of backslash escaped characters, I inclined 
to
Niels> go all in with Text::ParseWords's shellwords/parse_line from the 
beginning.

Niels> Would that still be doable in the dh-exec end?

Yep. All the funny parts of dh-exec are implemented in Perl, so I can
use the same libraries Debhelper does. When deciding what language to
use for the scripts, Perl was chosen because Debhelper is in Perl, too.

On a crazy note, I could even make dh-exec do the parsing, replace all
spaces with ?, or do some other trickery, like copying the file to a
unique directory, and replacing the line with DIR/*. That way, debhelper
wouldn't need to change anything at all. But this would be crazy. ;)

-- 
|8]

Bug#198507: dh_install: fails if filenames have an embedded space

[Gergely Nagy]

Hi!

> "Niels" == Niels Thykier  writes:

  Niels> On Mon, 23 Jun 2003 09:59:52 -0400 Joe Nahmias  
wrote:

Now, this is quite an ancient issue! :D

>> dh_install has problems handling files listed in debian/pkgname.install
>> when the filename contains (an) embedded space(s).  For example, when
>> debian/fceu-doc.install contains the line:
>> 
>> Documentation/tech/ppu/2C02\ technical\ operation.TXT
usr/share/doc/fceu-doc/tech/
>> 
>> the following results:
>> 
>> dh_install
>> cp: cannot stat `./Documentation/tech/ppu/2C02\\': No such file or 
directory
>> dh_install: command returned error code 256
>> make: *** [install] Error 1

Niels> A couple of points/ideas:

Niels> * dh-exec and debhelper should /preferably/ agree on users write 
their
Niels> spaces to be preserved (so the interface is the same for users with
Niels> and without dh-exec).

Agreed. I'll see if there are any parts of dh-exec that need to handle
spaces better. My gut feeling is, that apart from
dh-exec-install-rename, there aren't any.

Niels> * The internal communication between dh-exec and debhelper does not
Niels> have to be the same as the input format.  Especially not if it would
Niels> save you trouble of having to do complex "decode and recode" cycles

Right now, dh-exec just preprocesses the file, there is no special
communication protocol, and for the sake of simplicity, I'd prefer if
this stayed that way. Otherwise I'd have to rewrite most of it.

That is, I'd like to keep the internal communication format the same as
it is today, free of any special dh-exec <=> debhelper stuff. What
dh-exec spits out in the end, should be treated as a traditional
debhelper control file. If any other communication needs to be done
(which would mostly mean debhelper telling dh-exec some more info), that
should be in environment variables - just like it is now.

Niels> As an example, dh-exec-install-rename would go from:

Niels> if (/([^\s]*)\s+=>\s+([^\s]*)/ || /^=>\s+([^\s]*)/) {
Niels> ...
Niels> }
Niels> ...

Niels> $_ .= " " . $dstpath if ($append_destpath eq TRUE);

Niels> To something like (untested):

Niels> if (/([^\x1e]*)\x1e=>\x1e([^\x1e]*)/ || /^=>\x1e([^\x1e]*)/) {
Niels> ...
Niels> }
Niels> ...
Niels> $_ .= "\x1e" . $dstpath if ($append_destpath eq TRUE);

Niels> (possible with /x and some inline spaces to make it more readable).

Mmmm... I'd rather change the regexp to be a bit more lenient about
spaces. It originally had (.*), and that was changed to disallowing
spaces only to avoid being greedy and treat "foo  => bar" as an
instruction to rename "foo " to "bar".

Instead, I could just use .*, and strip the spaces at the end, unless
they are escaped. That is a lot less code for both dh-exec and
debhelper: I only have to change dh-exec, and debhelper does not need
any dh-exec-specific code.

Niels> * avoid having to add (complex) decode+encode in all the
Niels> scripts

dh-exec does not need complex decode+encode steps. At least, not more
than it already does have. It just adds some extra sugar on top of the
debhelper-understood format, and writes out the same format users would
write. I think this design is fine, and just this case alone is not a
reason enough to change this.

Niels> * put all the parsing of the user-formatted input in one place for
Niels> dh-exec.

This would be useful, if there were other places than -install-rename
where this matters, but there isn't, and I don't really see this
changing in the future.

Niels> * put all compatibility handling with debhelper in one place

Well, it's already in one place, pretty much, the only place that needs
it. :)

If there will be more places that need this special handling, I can
still easily pull out the functions that do the decoding/encoding,
without having to change debhelper itself.

Niels> This still leaves the question of the input format.  If you have any
Niels> suggestions for that or alternatives, please let me know. :)

My suggestion is: don't change the format. I'll make dh-exec handle
spaces in the rename script. You only need to teach debhelper to handle
the \-escaped spaces.

The dh-exec part of this is about 10 lines plus tests, at a guess. Doing
the \x1e separator thing would be considerably more, and as such, I'd
opt for the easier solution.

-- 
|8]

Bug#838410: RFA: ccze -- A robust, modular log coloriser

[Gergely Nagy]

Hi!

>>>>> "Axel" == Axel Beckert <a...@debian.org> writes:

Axel> Gergely Nagy wrote:
>> >>>>> "Axel" == Axel Beckert <a...@debian.org> writes:
>> Nope, not interested. The upstream "maintainer" part is a bit of an
>> exaggeration too, I haven't touched it in a long while, and have no
>> plans to do so. It's pretty much abandoned, I'm afraid,

Axel> That's a pity, especially since my previous favourite log colorized
Axel> "loco" got removed from Debian a few releases ago. (c.f.
Axel> https://bugs.debian.org/587245)

>> so if you are - or anyone else is - interested, I'll happily pass on
>> upstream maintainership too.

Axel> I'm definitely _not_ interested in taking over upstream for a
Axel> C-written program. I only want a simple, usable log colorizer in
Axel> Debian. So I'd only take over the package maintenance, preferable with
Axel> one or more co-maintainers.

Just to be clear: I will happily merge any bugfixes, new features and
whatnot, but I do not intend to do any development myself. If there are
very annoying bugs, I can help debugging them and fix them, eventually,
but the time I can allocate to this is very small.

Axel> (Or maybe I will reintroduce loco and take over its upstream
Axel> instead.)

That may be a better idea in the long run.

-- 
|8]

Bug#838410: RFA: ccze -- A robust, modular log coloriser

[Gergely Nagy]

Hi,

> "Axel" == Axel Beckert  writes:

Axel> Tobias Frost wrote:
>> The current maintainer of ccze, Stephen Gran ,
>> looks for someone to take over this package.

Axel> If no one else is interested, I'd take it over.

Axel> But maybe Gergely (in Cc) is intererested in taking the package back
Axel> as he maintained it in the past and is also the upstream
Axel> maintainer.

Nope, not interested. The upstream "maintainer" part is a bit of an
exaggeration too, I haven't touched it in a long while, and have no
plans to do so. It's pretty much abandoned, I'm afraid, so if you are -
or anyone else is - interested, I'll happily pass on upstream
maintainership too. The code is on GitHub at the moment, all former TLA
history nicely imported, in reasonable shape, I hope.

-- 
|8]

Bug#833919: Crashes with "stack smashing detected" whenevery I try to apply changes

[Gergely Nagy]

Package: gpointing-device-settings
Version: 1.6.0~git20150314.de7fe9e7-1
Severity: grave

No matter which settings I change, whether I run the software as my own
user or via sudo, whenever I try to apply changes, it crashes with the
attached backtrace printed on the terminal I launched it from. This
makes the package completely unusable, unfortunately.

*** stack smashing detected ***: gpointing-device-settings terminated
=== Backtrace: =
/lib/x86_64-linux-gnu/libc.so.6(+0x6ef45)[0x7f940391bf45]
/lib/x86_64-linux-gnu/libc.so.6(__fortify_fail+0x37)[0x7f94039a4627]
/lib/x86_64-linux-gnu/libc.so.6(__fortify_fail+0x0)[0x7f94039a45f0]
/usr/lib/x86_64-linux-gnu/gpointing-device-settings/module/touchpad.so(+0x2585)[0x7f93fd36f585]
/usr/lib/x86_64-linux-gnu/gpointing-device-settings/module/touchpad.so(+0x3030)[0x7f93fd370030]
/usr/lib/x86_64-linux-gnu/gpointing-device-settings/module/touchpad.so(+0x310e)[0x7f93fd37010e]
/lib/x86_64-linux-gnu/libglib-2.0.so.0(g_list_foreach+0x1d)[0x7f94045ae52d]
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0(g_cclosure_marshal_VOID__ENUMv+0x58)[0x7f940488b518]
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0(+0x101d4)[0x7f94048891d4]
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0(g_signal_emit_valist+0xc06)[0x7f94048a39a6]
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0(g_signal_emit+0x8f)[0x7f94048a408f]
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0(+0x101d4)[0x7f94048891d4]
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0(g_signal_emit_valist+0xc06)[0x7f94048a39a6]
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0(g_signal_emit+0x8f)[0x7f94048a408f]
/usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0(+0x8cf75)[0x7f9405f60f75]
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0(g_closure_invoke+0x145)[0x7f9404888fa5]
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0(+0x21afc)[0x7f940489aafc]
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0(g_signal_emit_valist+0xfbc)[0x7f94048a3d5c]
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0(g_signal_emit+0x8f)[0x7f94048a408f]
/usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0(+0x8beb9)[0x7f9405f5feb9]
/usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0(+0x13299c)[0x7f940600699c]
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0(g_closure_invoke+0x145)[0x7f9404888fa5]
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0(+0x2256e)[0x7f940489b56e]
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0(g_signal_emit_valist+0xa59)[0x7f94048a37f9]
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0(g_signal_emit+0x8f)[0x7f94048a408f]
/usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0(+0x24a31c)[0x7f940611e31c]
/usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0(gtk_propagate_event+0xc4)[0x7f9406005134]
/usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0(gtk_main_do_event+0x2cb)[0x7f94060054eb]
/usr/lib/x86_64-linux-gnu/libgdk-x11-2.0.so.0(+0x5ac9c)[0x7f9405c79c9c]
/lib/x86_64-linux-gnu/libglib-2.0.so.0(g_main_context_dispatch+0x2a7)[0x7f94045b21a7]
/lib/x86_64-linux-gnu/libglib-2.0.so.0(+0x4a400)[0x7f94045b2400]
/lib/x86_64-linux-gnu/libglib-2.0.so.0(g_main_loop_run+0xc2)[0x7f94045b2722]
/usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0(gtk_main+0xb7)[0x7f9406004567]
gpointing-device-settings[0x400978]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf0)[0x7f94038cd730]
gpointing-device-settings[0x4009b9]
=== Memory map: 
0040-00401000 r-xp  08:01 1188753
/usr/bin/gpointing-device-settings
0060-00601000 r--p  08:01 1188753
/usr/bin/gpointing-device-settings
00601000-00602000 rw-p 1000 08:01 1188753
/usr/bin/gpointing-device-settings
01efd000-02334000 rw-p  00:00 0  [heap]
7f93ef00-7f93f000 rw-s  00:05 43941919   
/SYSV (deleted)
7f93f000-7f93f0022000 rw-p  00:00 0 
7f93f0022000-7f93f400 ---p  00:00 0 
7f93f4255000-7f93f42b6000 rw-p  00:00 0 
7f93f451a000-7f93f453 r-xp  08:01 928652 
/lib/x86_64-linux-gnu/libgcc_s.so.1
7f93f453-7f93f472f000 ---p 00016000 08:01 928652 
/lib/x86_64-linux-gnu/libgcc_s.so.1
7f93f472f000-7f93f473 rw-p 00015000 08:01 928652 
/lib/x86_64-linux-gnu/libgcc_s.so.1
7f93f473-7f93f48a1000 r-xp  08:01 1186299
/usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.22
7f93f48a1000-7f93f4aa1000 ---p 00171000 08:01 1186299
/usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.22
7f93f4aa1000-7f93f4aab000 r--p 00171000 08:01 1186299
/usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.22
7f93f4aab000-7f93f4aad000 rw-p 0017b000 08:01 1186299
/usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.22
7f93f4aad000-7f93f4ab1000 rw-p  00:00 0 
7f93f4ab1000-7f93f632d000 r-xp  08:01 1181114
/usr/lib/x86_64-linux-gnu/libicudata.so.57.1
7f93f632d000-7f93f652c000 ---p 0187c000 08:01 1181114

Bug#816341: Patch

[Gergely Nagy]

Control: tag -1 patch

Patch that restricts the tag to install/manpages files is attached. Good
catch, thanks!

-- 
|8]
>From bbec428b16b73deaae0dab1e1fe52ba10c87da98 Mon Sep 17 00:00:00 2001
From: Gergely Nagy <alger...@madhouse-project.org>
Date: Tue, 1 Mar 2016 08:58:17 +0100
Subject: [PATCH] dh-exec-useless-usage applies to install/manpages only

Using ${DEB_HOST_MULTIARCH} in, say, dirs is perfectly legitimate. Do
the test for install/manpages files only. Fixes #816341.

Signed-off-by: Gergely Nagy <alger...@madhouse-project.org>
---
 checks/debhelper.pm  | 2 +-
 debian/changelog | 3 +++
 t/tests/debhelper-dh-exec/debian/debian/dirs | 1 +
 t/tests/debhelper-dh-exec/debian/debian/docs | 2 ++
 t/tests/debhelper-dh-exec/tags   | 2 +-
 5 files changed, 8 insertions(+), 2 deletions(-)
 create mode 100755 t/tests/debhelper-dh-exec/debian/debian/docs

diff --git a/checks/debhelper.pm b/checks/debhelper.pm
index 360a75a..aa47cb3 100644
--- a/checks/debhelper.pm
+++ b/checks/debhelper.pm
@@ -504,7 +504,7 @@ sub _check_dh_exec {
 $dhe_useless = 1;
 }
 }
-if ($dhe_useless) {
+if ($dhe_useless && $path =~ /debian\/.*(install|manpages)/ ) {
 my $form = $_;
 chomp($form);
 $form = "\"$form\"";
diff --git a/debian/changelog b/debian/changelog
index 1bc9ae6..adea20e 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -13,6 +13,9 @@ lintian (2.5.42) UNRELEASED; urgency=medium
   * checks/systemd.{desc,pm}:
 + [NT] Apply patch from Chris Lamb to flag systemd units
   without the "Documentation" key.  (Closes: #799083)
+  * checks/debhelper.pm:
++ [GN] Only do the dh-exec-useless-usage check for install and
+  manpages files.   (Closes: #816341)
 
   * data/scripts/interpreters:
 + [JW] Add hhvm as a known interpreter.  (Closes: #789878)
diff --git a/t/tests/debhelper-dh-exec/debian/debian/dirs b/t/tests/debhelper-dh-exec/debian/debian/dirs
index bc147d0..1540bd9 100755
--- a/t/tests/debhelper-dh-exec/debian/debian/dirs
+++ b/t/tests/debhelper-dh-exec/debian/debian/dirs
@@ -1,2 +1,3 @@
 #! /usr/bin/dh-exec
 usr/lib
+usr/lib/${DEB_HOST_MULTIARCH}/octave/packages
\ No newline at end of file
diff --git a/t/tests/debhelper-dh-exec/debian/debian/docs b/t/tests/debhelper-dh-exec/debian/debian/docs
new file mode 100755
index 000..55634c1
--- /dev/null
+++ b/t/tests/debhelper-dh-exec/debian/debian/docs
@@ -0,0 +1,2 @@
+#! /usr/bin/dh-exec
+debian/rules
\ No newline at end of file
diff --git a/t/tests/debhelper-dh-exec/tags b/t/tests/debhelper-dh-exec/tags
index 6d45ebe..d5030b2 100644
--- a/t/tests/debhelper-dh-exec/tags
+++ b/t/tests/debhelper-dh-exec/tags
@@ -5,4 +5,4 @@ I: debhelper-dh-exec source: dh-exec-subst-unknown-variable debian/manpages DEB_
 I: debhelper-dh-exec source: dh-exec-useless-usage debian/install "usr/lib/${DEB_HOST_MULTIARCH} /usr/lib/${DEB_HOST_MULTIARCH}/"
 I: debhelper-dh-exec source: dh-exec-useless-usage debian/install "usr/lib/${DEB_HOST_MULTIARCH}"
 I: debhelper-dh-exec source: dh-exec-useless-usage debian/install "usr/lib/${DEB_HOST_MULTIARCH}/some-package/*.so"
-W: debhelper-dh-exec source: dh-exec-script-without-dh-exec-features debian/dirs
+W: debhelper-dh-exec source: dh-exec-script-without-dh-exec-features debian/docs
-- 
2.7.0

Bug#811064: Please don't do this

[Gergely Nagy]

On Fri, Jan 15, 2016 at 1:54 PM, Raphael Hertzog  wrote:
> On Fri, 15 Jan 2016, Wouter Verhelst wrote:
>> If a build-dependency is not available on a given architecture, then the
>> package cannot be built on that architecture. Period. If that's a
>
> Life is not black and white. My present case shows it quite nicely.
>
> Shall I drop an architecture just because I can't build the manual page
> on that architecture ?
>
> My answer is a clear no. I have multiple other options, like moving the
> manual pages to a -doc package which is arch: all. I did not want to do
> this because it would bloat the archive with a tiny little package for a
> possibly temporary solution. I preferred to temporarily exclude some files
> until the architecture recovers from its missing pandoc (since that seems
> likely to happen).

How about a compromise? I can enable the ? syntax for .manpages files
only, so it covers this case (provided that manpage installation can
be moved to a .manpages file from .install).

What do you think?

-- 
|8]

Bug#498067: dh_install wildcard exception mechanism request

[Gergely Nagy]

Hi!

This wishlist was recently brought to my attention, as something that
could be added via dh-exec. I have a couple of ideas for the syntax:

1) usr/bin/djview3 => usr/bin/djview3

This is the existing syntax for dh-exec-install-rename, which does a
copy behind the scenes. For this feature, it would need to do a rename.
I do not want to break existing functionality, so if I go with this
syntax, we will need a flag to tell dh-exec to do a move instead of
copy.

Something like -Oinstall-rename=move or --move-files. Or, following
existing syntax: --with-scripts=install-movefiles. I am leaning towards
this last one.

2) => usr/bin/djview3

Kind of like the rename syntax, but only with the second part of it.
This is shorter, and does not need additional flags on the #! line. But
it does not allow renaming with a move. I suppose that is not
particularly important, seeing that I know of no such request.

3) A combination of both.

By default, install-movefiles would come after install-rename, thus the
latter would rewrite the src => dest form before install-move gets
there. With a --with-scripts argument, movefiles would win the race
instead.

Having dumped this here, I will go with the third option. Thank you for
listening.

-- 
|8]

Bug#801809: dh-exec: syntax

[Gergely Nagy]

On Sat, Oct 17, 2015 at 4:29 PM, Edmund Grimley Evans
 wrote:
>> I just pushed a fix to git that partially addresses the issue. The other
>> issue is in the fpc install script: [!linux-armel !linux-powerpc] means
>> either !armel, or !powerpc, therefore, it will always be true.
>
> Isn't that confusingly inconsistent with the syntax used in debian/control?

Indeed, it is. I was reading too much build profiles stuff. I have a
proper fix now, which makes [!linux-armel !linux-powerpc] work like it
should. Will push to git in a bit.

-- 
|8]

Bug#801809: dh-exec: fix for multiple arch filters

[Gergely Nagy]

Control: tag -1 patch

I just pushed a fix to git that partially addresses the issue. The other
issue is in the fpc install script: [!linux-armel !linux-powerpc] means
either !armel, or !powerpc, therefore, it will always be true. If you
want to exlude both, the correct syntax is: [!linux-armel]
[!linux-powerpc]. Unfortunately, that does not work with dh-exec 0.21,
but I committed a fix to git, that should make it work.

Can you give it a go, to see if it's all right, and if fpc triggers any
more issues I may have missed?

-- 
|8]

Bug#802034: This is a dh-exec issue

[Gergely Nagy]

Control: reassign -1 dh-exec

The problem here is that with the DH_CONFIG_ACT_ON_PACKAGES change,
dh-exec lost the ability to work with plain debian/install or
debian/manpages files. I'll restore that functionality in the next
dh-exec upload.

-- 
|8]

Bug#801809: dh-exec: fails to filter with multiple arch wildcards provided

[Gergely Nagy]

On Wed, Oct 14, 2015 at 8:27 PM, Paul Gevers  wrote:
> (experimental_powerpc-dchroot)elbrus@partch:~/fpc-3.0.0~rc1+dfsg$ cat 
> debian/fp-units-gfx-3.0.0.install
> #!/usr/bin/dh-exec
> /usr/lib/fpc/*/units/*/cairo
> /usr/lib/fpc/*/units/*/ggi
> /usr/lib/fpc/*/units/*/graph
> /usr/lib/fpc/*/units/*/hermes
> /usr/lib/fpc/*/units/*/imagemagick
> /usr/lib/fpc/*/units/*/libgd
> /usr/lib/fpc/*/units/*/libpng
> /usr/lib/fpc/*/units/*/opencl [!linux-armel !linux-powerpc]
> /usr/lib/fpc/*/units/*/opengl
> /usr/lib/fpc/*/units/*/opengles
> /usr/lib/fpc/*/units/*/ptc
> /usr/lib/fpc/*/units/*/rsvg
> /usr/lib/fpc/*/units/*/svgalib
> /usr/lib/fpc/*/units/*/xforms
> /usr/share/doc/fp-units-gfx

Much appreciated, will fix this too. Can I ping you on IRC or
elsewhere, to try a fix, before I go through the whole build & upload
stuff?

-- 
|8]

Bug#511048: dh_clean: Another directory removal suggestion

[Gergely Nagy]

Another idea: delegate this to dh-exec!

Not sure if debian/clean can be executable yet, but if so, I can easily
teach dh-exec to rm -rf a directory when it sees "foo/", and leave it up
to dh_clean to do its stuff otherwise.

-- 
|8]

Bug#511048: [debhelper-devel] Bug#511048: directory removal suggestion

[Gergely Nagy]

On Thu, Oct 8, 2015 at 6:58 PM, Axel Beckert  wrote:
> Hi,
>
> Barak A. Pearlmutter wrote:
>> How about using the same convention as .gitignore, so to include a
>> directory foo put a line foo/ in debian/clean.  The trailing slash
>> would tell dh_clean that this is a directory please remove it anyway.
>> This would avoid making debian/cleandirs which seems like too much
>> clutter, and the syntax is pretty easy to remember and read.
>
> I like this proposition way more than to (ab)use the overhead of
> dh-exec for this purpose. It's simple, obvious and can't be
> misunderstood.

I too, would favour a solution that does not involve dh-exec. If this
can be done in debhelper, yay! But if not, I'll add the magic to
dh-exec, which is still a reasonable solution, even if it's an
overhead.

Which shall it be?

-- 
|8]

Bug#801184: RFA: git-flow -- Git extension to provide a high-level branching model

[Gergely Nagy]

Package: wnpp
Severity: normal

I request an adopter for the git-flow package.

The package description is:
 A set of scripts that provide high-level repository operations for
 managing feature/release/hotfix branches in a Git repository,
 particularly suited to be utilised to follow Vincent Driessen's
 branching model, described at
 .
 .
 This package follows the AVH edition.

I do not use the package anymore, and do not have the resources to
take proper care of it. I'd be happy to hand over the package to
someone who uses it, and can take better care of it. Meanwhile, I'll
try to update it, and bring it to a better shape, but I'm not sure
when I'll be able to do that.

Bug#801104: lintian: dh-exec check improvements

[Gergely Nagy]

Source: lintian
Severity: wishlist
Version: 2.5.38
Tags: patch

Attached are two patches against lintian master, which do the following:

* The first teaches lintian about some new dh-exec features, such as
  architecture and build profile filters. Therefore, the
  "dh-exec-script-without-dh-exec-features" tag will not be emitted for
  packages that make use of these new features, but not the old ones.

* The second one is an attempt at catching unnecessary dh-exec use: when
  one uses dh-exec to install /usr/lib/${DEB_HOST_MULTIARCH}, that can
  be done with a simple wildcard, without dh-exec. There may be false
  positives, so the new tag is of wishlist severity only.

-- 
|8]
>From 6b35ed7bb3ac3efcfe2ba253c0b3c0514f29c165 Mon Sep 17 00:00:00 2001
From: Gergely Nagy <alger...@madhouse-project.org>
Date: Tue, 6 Oct 2015 11:54:07 +0200
Subject: [PATCH 1/2] checks/debhelper.pm: Update the dh-exec feature checks

Update the dh-exec feature checks to notice the arch and build profile
filters too, and not emit dh-exec-script-without-dh-exec-features if
these are used.

Signed-off-by: Gergely Nagy <alger...@madhouse-project.org>
---
 checks/debhelper.pm | 6 --
 t/tests/debhelper-dh-exec/debian/debian/dirs| 2 ++
 t/tests/debhelper-dh-exec/debian/debian/install | 2 +-
 t/tests/debhelper-dh-exec/debian/debian/rules   | 1 +
 t/tests/debhelper-dh-exec/tags  | 2 +-
 5 files changed, 9 insertions(+), 4 deletions(-)
 create mode 100755 t/tests/debhelper-dh-exec/debian/debian/dirs

diff --git a/checks/debhelper.pm b/checks/debhelper.pm
index f40f8ab..59c1341 100644
--- a/checks/debhelper.pm
+++ b/checks/debhelper.pm
@@ -481,7 +481,7 @@ sub _check_dh_exec {
 tag 'dh-exec-private-helper', $path;
 }
 
-my ($dhe_subst, $dhe_install) = (0, 0);
+my ($dhe_subst, $dhe_install, $dhe_filter) = (0, 0, 0);
 my $fd = $path->open;
 while (<$fd>) {
 if (/\$\{([^\}]+)\}/) {
@@ -499,10 +499,12 @@ sub _check_dh_exec {
 }
 }
 $dhe_install = 1 if / => /;
+$dhe_filter = 1 if /\[[^\]]+\]/;
+$dhe_filter = 1 if /<[^>]+>/;
 }
 close($fd);
 
-if (!($dhe_subst || $dhe_install)) {
+if (!($dhe_subst || $dhe_install || $dhe_filter)) {
 tag 'dh-exec-script-without-dh-exec-features', $path;
 }
 
diff --git a/t/tests/debhelper-dh-exec/debian/debian/dirs b/t/tests/debhelper-dh-exec/debian/debian/dirs
new file mode 100755
index 000..bc147d0
--- /dev/null
+++ b/t/tests/debhelper-dh-exec/debian/debian/dirs
@@ -0,0 +1,2 @@
+#! /usr/bin/dh-exec
+usr/lib
diff --git a/t/tests/debhelper-dh-exec/debian/debian/install b/t/tests/debhelper-dh-exec/debian/debian/install
index bc147d0..819be1a 100755
--- a/t/tests/debhelper-dh-exec/debian/debian/install
+++ b/t/tests/debhelper-dh-exec/debian/debian/install
@@ -1,2 +1,2 @@
 #! /usr/bin/dh-exec
-usr/lib
+usr/lib/foo [linux-any] [hurd-any] [kfreebsd-any]
diff --git a/t/tests/debhelper-dh-exec/debian/debian/rules b/t/tests/debhelper-dh-exec/debian/debian/rules
index 4d45dbe..0a817ea 100755
--- a/t/tests/debhelper-dh-exec/debian/debian/rules
+++ b/t/tests/debhelper-dh-exec/debian/debian/rules
@@ -6,5 +6,6 @@
 override_dh_installman:
 
 override_dh_install:
+	touch debian/debhelper-dh-exec/usr/lib/foo
 
 override_dh_link:
diff --git a/t/tests/debhelper-dh-exec/tags b/t/tests/debhelper-dh-exec/tags
index 2d0786a..b418aee 100644
--- a/t/tests/debhelper-dh-exec/tags
+++ b/t/tests/debhelper-dh-exec/tags
@@ -2,4 +2,4 @@ E: debhelper-dh-exec source: dh-exec-install-not-allowed-here debian/links
 E: debhelper-dh-exec source: dh-exec-private-helper debian/manpages
 E: debhelper-dh-exec source: package-uses-dh-exec-but-lacks-build-depends
 I: debhelper-dh-exec source: dh-exec-subst-unknown-variable debian/manpages DEB_BUILD_WHATEVER
-W: debhelper-dh-exec source: dh-exec-script-without-dh-exec-features debian/install
+W: debhelper-dh-exec source: dh-exec-script-without-dh-exec-features debian/dirs
-- 
2.5.3

>From d279b43ea3cec4664b6a23404562c939309c5c17 Mon Sep 17 00:00:00 2001
From: Gergely Nagy <alger...@madhouse-project.org>
Date: Tue, 6 Oct 2015 12:28:21 +0200
Subject: [PATCH 2/2] checks/debhelper.pm: Add a new dh-exec test

The new check tries to find cases where using dh-exec is not needed, and
a better, simpler solution exists. The new tag, dh-exec-useless-usage is
emitted when lintian finds a construct where a wildcard would do instead
of using dh-exec's variable substitution powers.

Signed-off-by: Gergely Nagy <alger...@madhouse-project.org>
---
 checks/debhelper.desc   | 20 ++
 checks/debhelper.pm | 28 +
 t/tests/debhelper-dh-exec/debian/debian/install |  3 +++
 t/tests/debhelper-dh-exec/desc  |  1 +
 t/tests/debhelper-dh-exec/tags  |  2 ++
 5 files changed, 54 insertions(+

Bug#801104: Anoter useless-use-of-dh-exec check

[Gergely Nagy]

Attached is another patch, a followup to the previous two. It catches
the 'usr/lib/${DEB_HOST_MULTIARCH}/some-dir/*.so' cases too.

-- 
|8]
>From 577add3f0269411abf378fe461f3c1f4c829678a Mon Sep 17 00:00:00 2001
From: Gergely Nagy <alger...@madhouse-project.org>
Date: Tue, 6 Oct 2015 13:00:11 +0200
Subject: [PATCH 3/3] checks/debhelper.pm: Add another useless use of dh-exec
 check

Catch usr/lib/${DEB_HOST_MULTIARCH}/$stuff cases too. Cases where there
is no explicit destination, and only the dpkg-architecture substitution
variables are used.

Signed-off-by: Gergely Nagy <alger...@madhouse-project.org>
---
 checks/debhelper.pm | 3 ++-
 t/tests/debhelper-dh-exec/debian/debian/install | 1 +
 t/tests/debhelper-dh-exec/tags  | 1 +
 3 files changed, 4 insertions(+), 1 deletion(-)

diff --git a/checks/debhelper.pm b/checks/debhelper.pm
index db00b5a..a896eb9 100644
--- a/checks/debhelper.pm
+++ b/checks/debhelper.pm
@@ -503,7 +503,8 @@ sub _check_dh_exec {
 $dhe_filter = 1 if /<[^>]+>/;
 
 if (/^usr\/lib\/\$\{([^\}]+)\}\/?$/ ||
-/^usr\/lib\/\$\{([^\}]+)\}\/?\s+\/usr\/lib\/\$\{([^\}]+)\}\/?$/) {
+/^usr\/lib\/\$\{([^\}]+)\}\/?\s+\/usr\/lib\/\$\{([^\}]+)\}\/?$/ ||
+/^usr\/lib\/\$\{([^\}]+)\}[^\s]+$/) {
 my $sv = $1;
 my $dv = $2;
 my $dhe_useless = 0;
diff --git a/t/tests/debhelper-dh-exec/debian/debian/install b/t/tests/debhelper-dh-exec/debian/debian/install
index 50055cb..c79e8ae 100755
--- a/t/tests/debhelper-dh-exec/debian/debian/install
+++ b/t/tests/debhelper-dh-exec/debian/debian/install
@@ -3,3 +3,4 @@ usr/lib/foo [linux-any] [hurd-any] [kfreebsd-any]
 usr/lib/${DEB_HOST_MULTIARCH}
 usr/lib/${DEB_HOST_MULTIARCH} /usr/lib/${DEB_HOST_MULTIARCH}/
 usr/lib/${DEB_BUILD_MULTIARCH} /usr/lib/${DEB_HOST_MULTIARCH}/
+usr/lib/${DEB_HOST_MULTIARCH}/some-package/*.so
diff --git a/t/tests/debhelper-dh-exec/tags b/t/tests/debhelper-dh-exec/tags
index 50d5f12..6d45ebe 100644
--- a/t/tests/debhelper-dh-exec/tags
+++ b/t/tests/debhelper-dh-exec/tags
@@ -4,4 +4,5 @@ E: debhelper-dh-exec source: package-uses-dh-exec-but-lacks-build-depends
 I: debhelper-dh-exec source: dh-exec-subst-unknown-variable debian/manpages DEB_BUILD_WHATEVER
 I: debhelper-dh-exec source: dh-exec-useless-usage debian/install "usr/lib/${DEB_HOST_MULTIARCH} /usr/lib/${DEB_HOST_MULTIARCH}/"
 I: debhelper-dh-exec source: dh-exec-useless-usage debian/install "usr/lib/${DEB_HOST_MULTIARCH}"
+I: debhelper-dh-exec source: dh-exec-useless-usage debian/install "usr/lib/${DEB_HOST_MULTIARCH}/some-package/*.so"
 W: debhelper-dh-exec source: dh-exec-script-without-dh-exec-features debian/dirs
-- 
2.5.3

Bug#800518: O: 9base -- Plan 9 userland tools

[Gergely Nagy]

Package: wnpp
Severity: normal

I'm orphaning the 9base package, because I do not use it, and do not
have neither the time, the energy or motivation to keep it in good
shape. The packaging is available on Alioth, under collab-maint/9base,
in Git.

The description reads:

Description: Plan 9 userland tools
 9base is a port of following original Plan 9 userland tools to Unix:
 awk, basename, bc, cat, cleanname, date, dc, echo, grep, mk, rc, sed, seq,
 sleep, sort, strings, tee, test, touch, tr, uniq, and yacc.

Bug#800519: O: dadadodo -- Exterminates all rational thought

[Gergely Nagy]

Package: wnpp
Severity: normal

I'm orphaning dadadodo, because I have neither the time, energy nor
motivation to maintain it properly. The sources are in Git, under
collab-maint/dadadodo.

The description reads:

Description: Exterminates all rational thought
 DadaDodo is a program that analyses texts for Markov chains of word
 probabilities and then generates random sentences based on that.
 Sometimes these sentences are nonsense; but sometimes they cut right
 through to the heart of the matter and reveal hidden meanings.

Bug#698054: Updated patch

[Gergely Nagy]

Updated patch attached, as per discussion on IRC.

-- 
|8]

>From ea6ebe371c5b5a1c66576504e199c73bc7383db1 Mon Sep 17 00:00:00 2001
From: Gergely Nagy <alger...@madhouse-project.org>
Date: Wed, 23 Sep 2015 10:12:43 +0200
Subject: [PATCH] Dh_Lib: Export an env var before running +x scripts

In order to let executable scripts discover what package is being built,
so they can avoid side-effects in case a package is to be skipped,
export DH_CONFIG_ACT_ON_PACKAGES before running them.

This, along with changes to dh-exec, will close #698054.

Signed-off-by: Gergely Nagy <alger...@madhouse-project.org>
---
 Debian/Debhelper/Dh_Lib.pm | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Debian/Debhelper/Dh_Lib.pm b/Debian/Debhelper/Dh_Lib.pm
index a5743e9..af3b3ac 100644
--- a/Debian/Debhelper/Dh_Lib.pm
+++ b/Debian/Debhelper/Dh_Lib.pm
@@ -760,7 +760,9 @@ sub filedoublearray {
 	if ($x) {
 		require Cwd;
 		my $cmd=Cwd::abs_path($file);
+		$ENV{"DH_CONFIG_ACT_ON_PACKAGES"} = join(",", @{$dh{"DOPACKAGES"}});
 		open (DH_FARRAY_IN, "$cmd |") || error("cannot run $file: $!");
+		delete $ENV{"DH_CONFIG_ACT_ON_PACKAGES"};
 	}
 	else {
 		open (DH_FARRAY_IN, $file) || error("cannot read $file: $!");
-- 
2.5.1

Bug#698054: debhelper: dh_install seems to call all executable debian/*.install files even with -p

[Gergely Nagy]

I just managed to reproduce this, test package attached.

What happens is that if dh_install gets called with -pfoo, then
foo.install will still be read and executed, but no copying will
happen. The contents are needed for --list-missing/--fail-missing, as
far as I see.

The problem only manifests when the .install file is executable, and has
side-effects, like in the case of dh-exec renaming a file.

To combat this, debhelper really needs to pass down an environment
variable, so dh-exec can know when to avoid side-effects. I tried
various other solutions, such as a dh-exec sequence (and a
dh_exec_init/dh_exec_deinit pair), but that was quickly discarded,
because it's either incredibly painful to use, or unreliable, or
both. So the only sane way is for debhelper to set an environment
variable which dh-exec can use.

I suggest _DH_DO_PACKAGES, which can be set/unset from
Dh_Lib::filedoublearray, just when running the executable script. I'll
submit a patch in a few minutes.

-- 
|8]



698054-repro.tar.gz
Description: application/gzip

Bug#698054: A patch to export a variable when calling +x scripts

[Gergely Nagy]

Control: tag -1 patch

A patch that exports _DH_DO_PACKAGES before running an executable script
is attached. It may be worth restricting this to compat 10, but... I
don't see the harm in exporting this even in lower compat levels. The
only upside of restricting it to 10 would be to make sure that stuff
that rely on this behaviour use the right compat level.

Yet, since there's about one potential user for this so far, and that
can just build-depend on a higher debhelper, I don't think adding the
compat 10 restriction is worth it.

-- 
|8]

>From 80766c948080a382bb752f0cb90623073626aa05 Mon Sep 17 00:00:00 2001
From: Gergely Nagy <alger...@madhouse-project.org>
Date: Wed, 23 Sep 2015 10:12:43 +0200
Subject: [PATCH] Dh_Lib: Export _DH_DO_PACKAGES before running executable
 scripts

In order to let executable scripts discover what package is being built,
so they can avoid side-effects in case a package is skipped, export
_DH_DO_PACKAGES before running them.

This, along with changes to dh-exec, will close #698054.

Signed-off-by: Gergely Nagy <alger...@madhouse-project.org>
---
 Debian/Debhelper/Dh_Lib.pm | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Debian/Debhelper/Dh_Lib.pm b/Debian/Debhelper/Dh_Lib.pm
index a5743e9..03553ce 100644
--- a/Debian/Debhelper/Dh_Lib.pm
+++ b/Debian/Debhelper/Dh_Lib.pm
@@ -760,7 +760,9 @@ sub filedoublearray {
 	if ($x) {
 		require Cwd;
 		my $cmd=Cwd::abs_path($file);
+		$ENV{"_DH_DO_PACKAGES"} = join(",", @{$dh{"DOPACKAGES"}});
 		open (DH_FARRAY_IN, "$cmd |") || error("cannot run $file: $!");
+		delete $ENV{"_DH_DO_PACKAGES"};
 	}
 	else {
 		open (DH_FARRAY_IN, $file) || error("cannot read $file: $!");
-- 
2.5.1

Bug#799552: dh-exec: BuildProfiles stanza make tool abort when no profile is set

[Gergely Nagy]

> "Samuel" == Samuel Thibault  writes:

Samuel> I have added a stage1 build profile to my package, and thus my
Samuel> .install.in file looks like this:

[...]

Samuel> and so if there is no profile, it just aborts.  Is that
Samuel> really expected?

It was the easiest and quickest I could come up with, certainly not the
best kind of behaviour. I have an idea how to handle these cases better,
will push them to git soon. I also asked #debian-bootstrap to verify my
assumptions. Once someone more knowledgeable about build profiles
acknowledges my changes, I'll upload a new dh-exec.

For the record, the current plan is this:

* " foo" will skip foo, if DEB_BUILD_PROFILES is empty.
* " foo" will install foo, if DEB_BUILD_PROFILES is empty,
  because a normal build is not a stage1 build.

-- 
|8]

Bug#798648: debhelper: Run make check VERBOSE=1 when using autoconf

[Gergely Nagy]

Package: debhelper
Version: 9.20150811
Severity: wishlist
Tags: patch

automake, for some time, uses a test runner that records test output and
whatnot in a file. Upon test suite failure, it will - by default - not
display the contents of that file, just point at it. This makes build
logs considerably less useful when it comes to discovering test
failures.

Thankfully, passing VERBOSE=1 (which is different from V=1 or
--disable-silent-rules!) to make when doing `make check` solves this
problem, because that tells automake to display the contents of its test
log file when the suite fails.

Attached is a patch (against debhelper master, as of this writing) that
changes the autoconf part of dh_auto_test to also handle the test stage
(provided configure exists in the sourcedir, and Makefile in the
builddir), and does the same as the parent class would, except it also
adds VERBOSE=1 to the command line.

It should have no ill side-effects, as far as I see.

(The test suite was also updated & extended)

-- 
|8]

>From 3c604a8e7ba2fe8d4504be91e732ccb3ccfcb49c Mon Sep 17 00:00:00 2001
From: Gergely Nagy <alger...@madhouse-project.org>
Date: Fri, 11 Sep 2015 14:30:05 +0200
Subject: [PATCH] dh_auto_test: Add VERBOSE=1 when using autoconf

When the build system is autoconf, assume that one also uses automake,
and pass VERBOSE=1 to make check too. Without VERBOSE=1, newer
automake-generated makefiles will not display the actual test errors,
but store them in a file. This makes build logs considerably less useful
when it comes to discovering test failures.

With VERBOSE=1 set, test failures are displayed. It should have no ill
effects when used with a non-automake makefile + autoconf combination.

The test suite was updated to reflect the changes, and new tests were
added to verify the new functionality.

Signed-off-by: Gergely Nagy <alger...@madhouse-project.org>
---
 Debian/Debhelper/Buildsystem/autoconf.pm | 10 ++
 t/buildsystems/autoconf/configure|  2 +-
 t/buildsystems/buildsystem_tests | 13 +
 3 files changed, 20 insertions(+), 5 deletions(-)

diff --git a/Debian/Debhelper/Buildsystem/autoconf.pm b/Debian/Debhelper/Buildsystem/autoconf.pm
index 62ff8b3..8604152 100644
--- a/Debian/Debhelper/Buildsystem/autoconf.pm
+++ b/Debian/Debhelper/Buildsystem/autoconf.pm
@@ -23,6 +23,10 @@ sub check_auto_buildable {
 	if ($step eq "configure") {
 		return 1 if -x $this->get_sourcepath("configure");
 	}
+	if ($step eq "test") {
+		return 1 if (-e $this->get_buildpath("Makefile") &&
+			 -x $this->get_sourcepath("configure"));
+	}
 	return 0;
 }
 
@@ -78,6 +82,12 @@ sub configure {
 	}
 }
 
+sub test {
+	my $this=shift;
+	$this->make_first_existing_target(['test', 'check'],
+		"VERBOSE=1", @_);
+}
+
 1
 
 # Local Variables:
diff --git a/t/buildsystems/autoconf/configure b/t/buildsystems/autoconf/configure
index b606f9e..80cf3ec 100755
--- a/t/buildsystems/autoconf/configure
+++ b/t/buildsystems/autoconf/configure
@@ -51,7 +51,7 @@ all: stamp_configure \$(CONFIGURE)
 
 # Tests if dh_auto_test executes 'check' target if 'test' does not exist
 check: \$(CONFIGURE) stamp_build
-	\@echo Tested > stamp_test
+	\@echo VERBOSE=\$(VERBOSE) > stamp_test
 
 install: stamp_build
 	\@echo DESTDIR=\$(DESTDIR) > stamp_install
diff --git a/t/buildsystems/buildsystem_tests b/t/buildsystems/buildsystem_tests
index 98b3895..6bda610 100755
--- a/t/buildsystems/buildsystem_tests
+++ b/t/buildsystems/buildsystem_tests
@@ -1,6 +1,6 @@
 #!/usr/bin/perl
 
-use Test::More tests => 297;
+use Test::More tests => 299;
 
 use strict;
 use warnings;
@@ -264,7 +264,7 @@ test_check_auto_buildable($bs{perl_makemaker}, "Makefile.PL", { configure => 1 }
 # With Makefile
 touch "$builddir/Makefile";
 test_check_auto_buildable($bs{makefile}, "Makefile", 1);
-test_check_auto_buildable($bs{autoconf}, "configure+Makefile", { configure => 1 });
+test_check_auto_buildable($bs{autoconf}, "configure+Makefile", { configure => 1, test => 1 });
 test_check_auto_buildable($bs{cmake}, "CMakeLists.txt+Makefile", 1);
 touch "$builddir/CMakeCache.txt"; # strong evidence that cmake was run
 test_check_auto_buildable($bs{cmake}, "CMakeCache.txt+Makefile", 2);
@@ -317,7 +317,7 @@ touch "$tmpdir/configure", 0755;
 touch "$builddir/Makefile";
 test_autoselection("autoconf",
 { configure => "autoconf", build => "makefile",
-  test => "makefile", install => "makefile", clean => "makefile" }, %tmp);
+  test => "autoconf", install => "makefile", clean => "makefile" }, %tmp);
 cleandir $tmpdir;
 
 # Perl Makemaker (build, test, clean fail with builddir set [not supported])
@@ -474,7 +474,12 @@ sub dh_a

Bug#794585: systemd unit file does not read /etc/default/syslog-ng

[Gergely Nagy]

Control: forwarded -1 https://github.com/balabit/syslog-ng/issues/683

Forwarded this upstream, because while it is reasonably easy to fix it
in Debian only, it is much easier to fix it upstream. That way the
packaging doesn't have to patch anything, nor ship its own systemd
service file.

-- 
|8]

Bug#794585: systemd unit file does not read /etc/default/syslog-ng

[Gergely Nagy]

Control: forwarded -1 https://github.com/balabit/syslog-ng/issues/683

Forwarded this upstream, because while it is reasonably easy to fix it
in Debian only, it is much easier to fix it upstream. That way the
packaging doesn't have to patch anything, nor ship its own systemd
service file.

-- 
|8]

Bug#703201: Add an option to process per-arch/per-os *and* normal install files

[Gergely Nagy]

>>>>> "Lisandro" == Lisandro Damián Nicanor Pérez Meyer <perezme...@gmail.com> 
>>>>> writes:

Lisandro> On Tuesday 01 September 2015 19:49:06 Dmitry Shachnev wrote:
    >> On Tue, 01 Sep 2015 10:56:17 +0200, Gergely Nagy wrote:
>> > This can easily be done with dh-exec now, with much nicer syntax than
>> > what I proposed two years ago:
>> > 
>> > Instead of foo.install-common, foo.install.$os, foo.install.$arch, one
>> 
>> > can use a single executable foo.install file, with some special markup:
>> Yes, we (the Qt maintainers) have already been thinking about using 
dh-exec.
>> We don't want to change existing packages as our current code works fine,
>> but we will definitely look at it if we need it in our next packages.
>> > Since I have a little bit of free time, how about this:
>> > 
>> > If foo.install.common exists, auto-include foo.install.$arch and
>> > foo.install.$os (if they exist), provided that foo.install is 
executable
>> > and uses dh-exec.
>> > 
>> > Alternatively, an executable foo.install, and executable
>> > foo.install.$arch/$os could also be a trigger, so foo.install.common
>> > wouldn't be required, and could be rolled into foo.install.
>> 
>> I don't think this is needed. A single file with architecture- or
>> OS-specific lines is much simplier to use and maintain.

Lisandro> Just for the record: we are currently using a hacked -common 
-arch approach, 
Lisandro> but having a special syntax in .install files would be just 
awesome.

Lisandro> Having the possibility to add negations like [!linux] would also 
be just cool. 
Lisandro> Ie, much in the current way we can manage build dependencies.

That works right now with dh-exec. It supports all wildcards
dpkg-architecture does (it uses that under the hood). Support for the
syntax is in stable too, and dh-exec is trivial to backport to
oldstable, if so need be.

So, you can write this right now:

,
| #! /usr/bin/dh-exec
| [hurd-i386] this-is-hurd-i386-only
| [linux-any] this-is-linux-only
| [!kfreebsd-amd64] this-is-not-for-kfreebsd-amd64
| [any-i386 any-powerpc] this-is-complicated
`

This works for all debhelper scripts one can make executable, not only
foo.install files. (Though I've no idea why it would be useful anywhere
else, but hey!)

-- 
|8]

Bug#703201: Add an option to process per-arch/per-os *and* normal install files

[Gergely Nagy]

This can easily be done with dh-exec now, with much nicer syntax than
what I proposed two years ago:

Instead of foo.install-common, foo.install.$os, foo.install.$arch, one
can use a single executable foo.install file, with some special markup:

,
| #! /usr/bin/dh-exec
| 
| ## Common stuff
| /usr/share
| 
| ## arch-specific stuff
| [any-amd64] /usr/lib/foo-amd64 /usr/lib
| [any-i386] /usr/lib/foo-i386 /usr/lib
| 
| ## os-specific stuff
| [linux-any] /usr/lib/foo-linux /usr/lib/foo/
| [freebsd-any] /usr/lib/foo-freebsd /usr/lib/foo/
`

And so on and so forth, see dh-exec-install(1). The wildcards follow the
same syntax as dpkg-architecture(1).

This approach does not require splitting the files, and only works when
everything is in a single file, which may get lengthy. If there is a
need to support some kind of inclusion, I can very easily add that to
dh-exec. It's about 5-6 lines of code, and a few handful more for tests.

Since I have a little bit of free time, how about this:

If foo.install.common exists, auto-include foo.install.$arch and
foo.install.$os (if they exist), provided that foo.install is executable
and uses dh-exec.

Alternatively, an executable foo.install, and executable
foo.install.$arch/$os could also be a trigger, so foo.install.common
wouldn't be required, and could be rolled into foo.install.

A third option would be what I suggested in 2013: an explicit #include.

I'd only implement at most one of the above, let me know which would be
the most debhelper-ish way to accomplish the task (the currently
available syntax is an option too, of course).

-- 
|8]

Bug#793377: linux-image-4.0.0-2-amd64: USB keyboard losing keystrokes

[Gergely Nagy]

Package: linux-image-4.0.0-2-amd64
Version: 4.0.8-1
Severity: important

Dear Maintainer,

I recently upgraded from Jessie to Stretch, which bought along a
kernel upgrade from 3.16 to 4.0. After the upgrade - and a reboot - my
USB keyboard (TypeMatrix 2030) started losing keystrokes: typing at
normal speed, about 25% of keys pressed were lost completely.

This happened under GNOME. I tried on the console, and couldn't
reproduce the problem (I didn't try typing fast, mind you). I couldn't
reproduce the problem with the built-in keyboard of my laptop (Dell
XPS 13, 2014 model), either.

I have not tried switching to another DE, or WM. But I did try
downgrading the kernel to 3.16, and my woes are now gone.

I have no idea how to debug the regression, any pointers in that
direction would be helpful. I can provide dmesg output and whatever
logs you may need, if told to do so.

-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (1, 
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)


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

Bug#792954: dpatch: please make the build reproducible

[Gergely Nagy]

Control: tag -1 pending

 Maria == Maria Valentina Marin marival...@gmail.com writes:

Maria While working on the “reproducible builds” effort [1], we have 
noticed
Maria that dpatch could not be built reproducibly.

Maria The attached patch sets the mtimes of all files which are modified
Maria during the built to the date of the last changelog entry in order to
Maria produce files with reproducible metadata.

Thanks for the patch, applied. Will upload dpatch 2.0.36 later today.

-- 
|8]


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

Bug#768634: ITA: propellor -- property-based host configuration management in haskell

[Gergely Nagy]

Control: retitle -1 O: propellor -- property-based host configuration 
management in haskell
Control: noowner -1

 PICCA == PICCA Frederic-Emmanuel 
 frederic-emmanuel.pi...@synchrotron-soleil.fr writes:

PICCA Hello, just to know if you are planning to update propellor in Debian

While I really wanted to, I have to admit I lack the resources to do
so. Setting it back to O:, to allow someone else to take better care of
it.

-- 
|8]


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

Bug#787696: syslog-ng-core: syslog-ng not supporting RFC5424

[Gergely Nagy]

Package: syslog-ng-core
Version: 3.6.1+git20141206-g4d90138-4
Severity: important
Owner: Michael Bushey mich...@realtymogul.com

(Submitting on behalf of Michael Bushey)

Dear Maintainer,

From a remote machine, this does not work:
logger --tcp --port 514 -n l01 --tag scrub -p 6 Scrub test from logger

This does work:
logger --rfc3164 --tcp --port 514 -n l01 --tag scrub -p 6 Scrub test
from logger


ii  bsdutils   1:2.26.2-5amd64
   basic utilities from 4.4BSD-Lite


What led up to the situation: Upgraded from bsdutils 1:2.25.2-6 to 1:2.26.2-5
What exactly did you do (or not do) that was effective (or
ineffective): added --rfc3164 to logger

I just upgraded syslog-ng to 3.6.1 in an attempt to fix the problem,
3.5.6 did the same thing.


-- System Information:
Debian Release: stretch/sid
  APT prefers testing-updates
  APT policy: (500, 'testing-updates'), (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 4.0.4-x86_64-linode57 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages syslog-ng-core depends on:
ii  init-system-helpers1.23
ii  libc6  2.19-18
ii  libcap21:2.24-8
ii  libevtlog0 0.2.12-7
ii  libglib2.0-0   2.44.1-1
ii  libivykis0 0.36.2-1
ii  libnet11.1.6+dfsg-3
ii  libpcre3   2:8.35-5
ii  libssl1.0.01.0.2a-1
ii  libsystemd0215-18
ii  libwrap0   7.6.q-25
ii  syslog-ng-mod-journal  3.6.1+git20141206-g4d90138-4
ii  util-linux 2.26.2-5

Versions of packages syslog-ng-core recommends:
ii  logrotate  3.8.7-2

Versions of packages syslog-ng-core suggests:
ii  syslog-ng-mod-amqp  3.6.1+git20141206-g4d90138-4
ii  syslog-ng-mod-geoip 3.6.1+git20141206-g4d90138-4
pn  syslog-ng-mod-graphite  none
ii  syslog-ng-mod-json  3.6.1+git20141206-g4d90138-4
ii  syslog-ng-mod-mongodb   3.6.1+git20141206-g4d90138-4
ii  syslog-ng-mod-redis 3.6.1+git20141206-g4d90138-4
pn  syslog-ng-mod-riemann   none
ii  syslog-ng-mod-smtp  3.6.1+git20141206-g4d90138-4
ii  syslog-ng-mod-sql   3.6.1+git20141206-g4d90138-4
ii  syslog-ng-mod-stomp 3.6.1+git20141206-g4d90138-4

-- no debconf information

-- 
|8]


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

Bug#774351: sbuild: patch to fail when hooks fail

[Gergely Nagy]

Hi!

A friend of mine recently ran into this issue too, so I tried to come up
with a quick  dirty patch to make hooks abort the build if they fail. I
haven't tested it yet, mind you. In any case, patch is attached. When I
hear back from either my friend, or from anyone reading this, that the
patch works, I'll clean it up and resubmit.

-- 
|8]

From 2fc906196c67cb71fb79f8e517b28d830f59d4fc Mon Sep 17 00:00:00 2001
From: Gergely Nagy alger...@madhouse-project.org
Date: Fri, 29 May 2015 09:01:24 +0200
Subject: [PATCH] Sbuild::Build: Abort when a hook fails

Signed-off-by: Gergely Nagy alger...@madhouse-project.org
---
 lib/Sbuild/Build.pm | 48 ++--
 1 file changed, 30 insertions(+), 18 deletions(-)

diff --git a/lib/Sbuild/Build.pm b/lib/Sbuild/Build.pm
index cda5cf3..00513a7 100644
--- a/lib/Sbuild/Build.pm
+++ b/lib/Sbuild/Build.pm
@@ -367,9 +367,11 @@ sub run_chroot_session {
 
 	# Run pre build external commands
 	$self-check_abort();
-	$self-run_external_commands(pre-build-commands,
- $self-get_conf('LOG_EXTERNAL_COMMAND_OUTPUT'),
- $self-get_conf('LOG_EXTERNAL_COMMAND_ERROR'));
+my $returnval;
+	$returnval = $self-run_external_commands(pre-build-commands,
+  $self-get_conf('LOG_EXTERNAL_COMMAND_OUTPUT'),
+  $self-get_conf('LOG_EXTERNAL_COMMAND_ERROR'));
+$self-request_abort (External command failed) if (!$returnval);
 
 	$self-check_abort();
 	if (!$session-begin_session()) {
@@ -512,9 +514,10 @@ sub run_chroot_session_locked {
 
 	# Run specified chroot setup commands
 	$self-check_abort();
-	$self-run_external_commands(chroot-setup-commands,
- $self-get_conf('LOG_EXTERNAL_COMMAND_OUTPUT'),
- $self-get_conf('LOG_EXTERNAL_COMMAND_ERROR'));
+	my $returnval = $self-run_external_commands(chroot-setup-commands,
+ $self-get_conf('LOG_EXTERNAL_COMMAND_OUTPUT'),
+ $self-get_conf('LOG_EXTERNAL_COMMAND_ERROR'));
+$self-request_abort (External command failed) if (!$returnval);
 
 	$self-check_abort();
 
@@ -702,9 +705,11 @@ sub run_fetch_install_packages {
 
 	# Run specified chroot cleanup commands
 	$self-check_abort();
-	$self-run_external_commands(chroot-cleanup-commands,
- $self-get_conf('LOG_EXTERNAL_COMMAND_OUTPUT'),
- $self-get_conf('LOG_EXTERNAL_COMMAND_ERROR'));
+	my $returnval = $self-run_external_commands(chroot-cleanup-commands,
+ $self-get_conf('LOG_EXTERNAL_COMMAND_OUTPUT'),
+ $self-get_conf('LOG_EXTERNAL_COMMAND_ERROR'));
+$self-request_abort (External command failed) if (!$returnval);
+$self-check_abort();
 
 	if ($self-get('Pkg Status') eq successful) {
 	$self-log_subsection(Post Build);
@@ -715,9 +720,11 @@ sub run_fetch_install_packages {
 
 	# Run post build external commands
 	$self-check_abort();
-	$self-run_external_commands(post-build-commands,
-	 $self-get_conf('LOG_EXTERNAL_COMMAND_OUTPUT'),
-	 $self-get_conf('LOG_EXTERNAL_COMMAND_ERROR'));
+	my $returnval = $self-run_external_commands(post-build-commands,
+ $self-get_conf('LOG_EXTERNAL_COMMAND_OUTPUT'),
+ $self-get_conf('LOG_EXTERNAL_COMMAND_ERROR'));
+$self-request_abort (External command failed) if (!$returnval);
+$self-check_abort();
 
 	}
 };
@@ -1473,9 +1480,12 @@ sub build {
 	return 0;
 }
 
-$self-run_external_commands(starting-build-commands,
- $self-get_conf('LOG_EXTERNAL_COMMAND_OUTPUT'),
- $self-get_conf('LOG_EXTERNAL_COMMAND_ERROR'));
+my $returnval;
+$returnval = $self-run_external_commands(starting-build-commands,
+  $self-get_conf('LOG_EXTERNAL_COMMAND_OUTPUT'),
+  $self-get_conf('LOG_EXTERNAL_COMMAND_ERROR'));
+$self-request_abort (External command failed) if (!$returnval);
+$self-check_abort();
 
 $self-set('Build Start Time', time);
 $self-set('Build End Time', $self-get('Build Start Time'));
@@ -1666,9 +1676,11 @@ sub build {
 $self-log(Build finished at $finish_date\n);
 
 
-$self-run_external_commands(finished-build-commands,
- $self-get_conf('LOG_EXTERNAL_COMMAND_OUTPUT'),
- $self-get_conf('LOG_EXTERNAL_COMMAND_ERROR'));
+my $retval = $self-run_external_commands(finished-build-commands,
+  $self-get_conf('LOG_EXTERNAL_COMMAND_OUTPUT'),
+  $self-get_conf('LOG_EXTERNAL_COMMAND_ERROR'));
+$self-request_abort (External command failed) if (!$returnval);
+$self

Bug#783689: bustle-pcap: Manual is in the wrong package

[Gergely Nagy]

Source: bustle
Version: 0.4.7-3

With bustle-pcap being moved out into a separate package, the
corresponding manual page should have been moved too. But it remained in
the original bustle package (noticed by lintian). Please fix that at
some point.

-- 
|8]


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

Bug#783694: mrrescue: Small suggestion for the packaging

[Gergely Nagy]

Source: mrrescue
Version: 1.02c-1
Severity: wishlist

Hi!

I have a small suggestions regarding the mrrescue packaging: you can
work around debhelper bug #719359 in a different way: put the files in
debian/data/, and change debian/mrrescue.install to search for the
script to run the game and the desktop file in debian/data/ instead of
debian/.

This allows you to get rid of a lintian override, and the dh_installinit
override in debian/rules too.

Just a suggestion, feel free to close this report if you disagree.

-- 
|8]


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

Bug#776937: dpatch: please make the build reproducible

[Gergely Nagy]

 Chris == Chris Lamb la...@debian.org writes:

Chris While working on the reproducible builds effort [1], we have 
noticed
Chris that dpatch could not be built reproducibly.

Thanks for the patch, I will apply it, and upload the fixed package soonish.

-- 
|8]


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

Bug#773168: [Syslog-ng-maintainers] Bug#773168: remove afsql from default modules

[Gergely Nagy]

Control: reassign -1 syslog-ng-core
Control: forcemerge -1 650814

 Matus == Matus UHLAR - fantomas uh...@fantomas.sk writes:

Matus the module afsql is listed as default, although split into different
Matus package.  That causes syslog complain about missing default module 
everytime
Matus it's reloaded. Please remove the module from list of default
Matus modules.

This is the same as #650814, which has been fixed in syslog-ng = 3.4
(and thus in testing and sid, and in wheezy-backports too). There are no
plans to fix the issue in the 3.3 branch. If you wish to stick with 3.3
(and not use 3.5 from backports), I'd recommend either installing
syslog-ng-mod-sql, or passing --default-modules to syslog-ng, to
override its default.

-- 
|8]


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

Bug#772464: unblock: propellor/0.9.1.1 (pre-approval)

[Gergely Nagy]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Hi!

I'd like to upload propellor 0.9.1.1 (version pending approval from Joey
Hess) to testing-proposed-updates to fix #769452, and adopt the package
(#768634). It can't go via unstable, because that has 0.9.2 already,
with unrelated changes.

The source diff is attached.

unblock propellor/0.9.1.1

-- 
|8]

diff --git a/debian/changelog b/debian/changelog
index c580b3b..e1cac4b 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,15 @@
+propellor (0.9.1.1) testing-proposed-updates; urgency=medium
+
+  [ Joey Hess ]
+  * Docker: Stop using docker.io; that was a compat symlink in
+the Debian package which has been removed in docker.io 1.3.1~dfsg1-2.
+(Closes: #769452)
+
+  [ Gergely Nagy ]
+  * New maintainer. (Closes: #768634)
+
+ -- Gergely Nagy alger...@madhouse-project.org  Sun, 07 Dec 2014 15:14:05 +0100
+
 propellor (0.9.1) unstable; urgency=medium
 
   * Docker: Add ability to control when containers restart.
diff --git a/src/Propellor/Property/Docker.hs b/src/Propellor/Property/Docker.hs
index d9d5f19..5a7a084 100644
--- a/src/Propellor/Property/Docker.hs
+++ b/src/Propellor/Property/Docker.hs
@@ -567,7 +567,7 @@ readIdentFile cid = fromMaybe (error bad ident in identFile)
 	. readish $ readFile (identFile cid)
 
 dockercmd :: String
-dockercmd = docker.io
+dockercmd = docker
 
 report :: [Bool] - Result
 report rmed

Bug#771774: RFS: libmongo-client/0.1.8-2 [ITA]

[Gergely Nagy]

 Jörg == Jörg Frings-Fürst deb...@jff-webhosting.net writes:

 * The build: target was there for a reason. Without it, we will build
 the arch-indep stuff by default too, which is something we want to
 avoid.
 
 For example, it will FTBFS on buildds, because they do not install
 build-depends-indep. And we really don't want doxygen and graphviz in
 B-D, because those pull in a shitload of stuff, to build docs that
 will be discarded by buildds anyway.

Jörg I fully agree with you.
Jörg But where are the problem? The package has no FTBFS and I don't change
Jörg your -arch / -indep division. 

Jörg Please can you specify your minds.

Ah, yes, now I remember. This was done for backporting purposes, so the
package could be built on older releases where sbuild didn't call
build-arch yet, but used build. For unstable, dropping the build target
as you did is fine, indeed.

 * Why move --dbg-package from DH_OPTIONS to an override?

Jörg --dbg-package is only needed in dh_strip[1]. 

Yes. But it works fine in DH_OPTIONS too, without any ill side-effects,
and is shorter there. (Personal thing, but I hate overrides, and if
there's another way to do what I want, which isn't convoluted, I'd
choose that)

But override or DH_OPTIONS, in this case, doesn't matter.

The updated package looks fine, good job! One thing you may wish to
change is the Source: stanza in debian/copyright. While I intend to
restore the git URL there (I just need to reinstall cgit), it currently
doesn't work, and github is the canonical one nowadays.

-- 
|8]


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

Bug#771774: RFS: libmongo-client/0.1.8-2 [ITA]

[Gergely Nagy]

 Jörg == Jörg Frings-Fürst deb...@jff-webhosting.net writes:

Jörg I am looking for a sponsor for my package libmongo-client

Jörg Package name: libmongo-client
Jörg Version : 0.1.8-2

As the former maintainer and upstream, there are a few issues I see with
the packaging (also sent earlier in private mail, but repeating here in
case someone was looking at the package and wanting to sponsor it).

* Instead of disabling the watch file, if you tweak the regexp to only
  match upstream releases, then it will work, and not catch my old
  debian/ tags:

  ,
  | version=3
  |
  | https://github.com/algernon/libmongo-client/releases 
.*/libmongo-client-([\d\.]+)\.tar\.gz
  `

* The build: target was there for a reason. Without it, we will build
  the arch-indep stuff by default too, which is something we want to
  avoid.

  For example, it will FTBFS on buildds, because they do not install
  build-depends-indep. And we really don't want doxygen and graphviz in
  B-D, because those pull in a shitload of stuff, to build docs that
  will be discarded by buildds anyway.

* Why move --dbg-package from DH_OPTIONS to an override?

-- 
|8]


signature.asc
Description: PGP signature

Bug#770801: RFA: libmongo-client -- Alternate C driver for MongoDB

[Gergely Nagy]

Package: wnpp
Severity: normal

I am looking for a new maintainer for libmongo-client (both Debian and
upstream, but they do not have to be the same person). It is an
alternative C language driver for the MongoDB NoSQL database, used by
both rsyslog and syslog-ng for their respective MongoDB supporting
modules.

The library and the packaging is - I believe - in reasonably good
shape. The reason for RFA-ing is that I do not use neither the
library, nor MongoDB anymore, but there are a fair number of users of
it who deserve better maintenance than what I can provide.

Description of the main package follows:

Description-en: Alternate C driver for the MongoDB document-oriented datastore
 MongoDB is a high-performance, open source, schema-free
 document-oriented data store.
 .
 This library provides an alternative C language driver, focusing on
 stability, ease of use, striving to make the most common use cases as
 convenient as possible.
 .
 Among its features are:
 .
   * Well documented, easy, clean and stable API.
   * Support for asynchronous operation.
   * ReplicaSet support, with support for automatic reconnecting and
   discovery.
   * Safe-mode support, to optionally enable extra safety checks on
   writes.

If interested, either in upstream or Debian maintenance, please
contact me.


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

Bug#760426: [systemd] Logs gone after moving to systemd

[Gergely Nagy]

Control: retitle -1 syslog-ng: Remove dangling syslog.service symlink in preinst
Control: tag -1 help

The same dance will need to be done for syslog-ng-core (which ships
syslog-ng.service) that rsyslog will be doing (see #741496). It's
blocked until the proper steps to do the syslog.service transfer are
figured out.

-- 
|8]


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

Bug#727649: syslog-ng memory leak when using templated filenames and rewrite rules

[Gergely Nagy]

Control: forwarded -1 https://github.com/balabit/syslog-ng/issues/308
Control: tag -1 upstream
Control: found -1 3.5.6-2
Control: found -1 3.6.1-1

I managed to reproduce the problem on the latest upstream version too,
and forwarded it upstream. During my tests, it seemed that the
unix-stream() source file was opened many many times, which would easily
explain the leak.

Can you check what happens in your case? Also, does the problem persist
if you use unix-dgram() for /dev/log, instead of unix-stream()?

-- 
|8]


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

Bug#769452: docker.io compat symlink removed

[Gergely Nagy]

 Joey == Joey Hess i...@joeyh.name writes:

Joey propellor's docker support uses the docker.io command, but this
Joey turns out to have been a deprecated compat symlink which was removed 
in
Joey docker.io 1.3.1~dfsg1-2. Which has already migrated to testing.

Joey This is fixed in propellor 0.9.2, which has not migrated and contains
Joey other, unrelated changes. The commit fixing the problem is
Joey 9755b761bb46bc40d19a2723165424a1f8a27cbb

Joey I'm glad I don't have to worry about whether this is RC or how to fix
Joey it. ;)

The correct way is through t-p-u, I'll handle the paperwork ~tomorrow,
if all goes well. And this is - in my opinion - not RC, because
propellor is perfectly usable without docker support. Nevertheless, it's
a trivial fix.

-- 
|8]


signature.asc
Description: PGP signature

Bug#703639: [Syslog-ng-maintainers] Bug#703639: kill -HUP $(cat /var/run/syslog-ng.pid) can cause duplicate logging issues

[Gergely Nagy]

 Evgeni == Evgeni Golov evg...@debian.org writes:

Evgeni Hi,
Evgeni On Fri, Mar 22, 2013 at 03:59:11PM +0100, Gergely Nagy wrote:

 * Fixing the configuration and reloading gets things back in order, no
 matter how many times messages were duplicated before.

Evgeni I have a heavily customized config, which does not throw any errors,
Evgeni but triggers the issue on a wheezy box.

Evgeni The config is for a central log-server, which gets syslog via UDP 
from
Evgeni quite a few hosts and sorts these accordingly. Every day at 
logrotate
Evgeni a SIGHUP is issued and my /var/log gets full. The ratio is about 1 
real 
Evgeni message to 3000 (yes, three thousand!) duplicates :/

Evgeni A real restart solves the issue.

Evgeni I hope this is helful for you to track down the issue.

I didn't have time to reproduce the problem yet, but I'm going to
forward it upstream. Are you using the wheezy version of syslog-ng? If
so, can you try the 3.5.6 backport from wheezy-backports, and see if the
problem persists?

(A lot of things that may result in this kind of behaviour have been
fixed between 3.3.5 in wheezy and 3.5.6 in backports.)


-- 
|8]


signature.asc
Description: PGP signature

Bug#768634: ITA: propellor -- property-based host configuration management in haskell

[Gergely Nagy]

Control: retitle -1 ITA: propellor -- property-based host configuration 
management in haskell

I intend to adopt propellor. I'm starting to use it at work, and at home
too, would be a shame to let it fall out of Debian. It's also a great
excuse to learn more about Haskell packaging.

-- 
|8]


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

Bug#763725: git-flow: Bad variable name when space characters in path

[Gergely Nagy]

Peter van der Does pe...@avirtualhome.com writes:

 On Thu, 02 Oct 2014 09:30:33 +0200 Jeremie Burtin
 jere...@jeremieburtin.fr wrote:
 Package: git-flow
 Version: 1.7.0-1
 Severity: grave
 Tags: upstream
 Justification: renders package unusable
 
 Hi,
 When trying to perform git flow feature start feature_name, the script 
 fails
 with a Bad variable name error. It seems to come from the fact the path to
 the directory where I'm working contains space characters (ie : 2 - 
 Developpement)
 The same repository in another path with no space does not fail.
 

 This was a bug in version 1.7, it's fixed in version 1.8.

 P.S. I develop git-flow AVH Edition, but do not maintain the Debian package.

Thanks for the report, and the heads-up on the fix being available in
1.8! I'll update the Debian package today.

-- 
|8]


pgpUWAd0lnz5U.pgp
Description: PGP signature

Bug#757903: [Syslog-ng-maintainers] Bug#757903: syslog-ng-core: invoke-rc.d: initscript syslog-ng, action stop failed.

[Gergely Nagy]

 % systemctl status syslog-ng.service; dpkg-reconfigure syslog-ng-core
 syslog-ng.service - System Logger Daemon
Loaded: loaded (/lib/systemd/system/syslog-ng.service; enabled)
Active: active (running) since Tue 2014-08-12 20:42:04 CEST; 1s ago
  Docs: man:syslog-ng(8)
  Main PID: 24163 (syslog-ng)
CGroup: /system.slice/syslog-ng.service
└─24163 /usr/sbin/syslog-ng -F

 Aug 12 20:42:04 mercury2 systemd[1]: Started System Logger Daemon.
 Aug 12 20:42:04 mercury2 systemd[1]: Started System Logger Daemon.
 + [ configure = triggered ]
 + dpkg-trigger register-syslog-ng-plugin
 + deb-systemd-helper unmask syslog-ng.service
 + deb-systemd-helper --quiet was-enabled syslog-ng.service
 + deb-systemd-helper enable syslog-ng.service
 + [ -x /etc/init.d/syslog-ng ]
 + update-rc.d syslog-ng defaults 10 90
 + exit 0
 Processing triggers for syslog-ng-core (3.5.6-1) ...
 + [ triggered = triggered ]
 + invoke-rc.d syslog-ng stop
 Job for syslog-ng.service canceled.
 invoke-rc.d: initscript syslog-ng, action stop failed.
 + exit 1
 dpkg: error processing package syslog-ng-core (--configure):
  subprocess installed post-installation script returned error exit status 1
 Errors were encountered while processing:
  syslog-ng-core

 I was suspecting a systemd rate limit at first, but the upgrade that failed
 today didn't include any other packages shipping anything systemd related. See
 the attached history.log for the packages involved in the failing upgrade.

Turns out this is a known issue with systemd and socket activated
services (such as syslog-ng), see #736258 and #751744. However, we do
not use the recommended --restart-after-upgrade mechanism, and I'm
unsure whether that would fix the issue.

Nevertheless, I have a far better idea of what is happening, and will
try to reproduce the issue locally.

-- 
|8]


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

Bug#757903: [Syslog-ng-maintainers] Bug#757903: Bug#757903: syslog-ng-core: invoke-rc.d: initscript syslog-ng, action stop failed.

[Gergely Nagy]

Control: reassign 757903 dh-systemd
Control: forcemerge 751741 757903
Control: affects + 751741 syslog-ng-core

Gergely Nagy alger...@balabit.hu writes:

 Turns out this is a known issue with systemd and socket activated
 services (such as syslog-ng), see #736258 and #751744. However, we do
 not use the recommended --restart-after-upgrade mechanism, and I'm
 unsure whether that would fix the issue.

I'm changing syslog-ng-core to use --restart-after-upgrade, but that
will likely not solve the problem completely (although I have not been
able to reproduce it locally), so I'm reassigning the bug to dh-systemd,
and merging it with other similar issues.

3.5.6-2 will likely hit unstable by tonight, I would be very interested
in hearing whether the problem persists with that version.

-- 
|8]


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

Bug#757903: syslog-ng-core: invoke-rc.d: initscript syslog-ng, action stop failed.

[Gergely Nagy]

Sebastian Ramacher sramac...@debian.org writes:

 Package: syslog-ng-core
 Version: 3.5.6-1
 Severity: grave
 Justification: renders package unusable

 Today the upgrade from 3.5.5-2 to 3.5.6-1 failed with:
 | Processing triggers for syslog-ng-core (3.5.6-1) ...
 | Job for syslog-ng.service canceled.
 | invoke-rc.d: initscript syslog-ng, action stop failed.
 | dpkg: error processing package syslog-ng-core (--configure):
 |  subprocess installed post-installation script returned error exit status 1

 Uncommenting invoke-rc.d syslog-ng stop || exit $? in line 6 of the
 postinst script and running apt install -f fixes the issue and lets the
 installation complete.

 I've also seen this issue while installing syslog-ng-core for the first
 time on another system.

 Both systems are running systemd if that matters. Let me know if you
 want more info. My other system waits to be upgraded.

What does systemctl status syslog-ng.service print?

-- 
|8]


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

Bug#755212: transition: protobuf-c

[Gergely Nagy]

Robert Edmonds edmo...@debian.org writes:

 Emilio Pozuelo Monfort wrote:
 On 18/07/14 22:19, Robert Edmonds wrote:
  * The header file (protobuf-c.h) which compiled .pb-c.h files must
include.  This is shipped in the libprotobuf-c0-dev package
(protobuf-c  1.0.0), or the libprotobuf-c-dev package (protobuf-c
= 1.0.0).  (libprotobuf-c-dev Provides: libprotobuf-c0-dev, which
smoothes the transition for packages with an unversioned
build-dependency on libprotobuf-c0-dev.)
 
 I just realized that that's not going to work, because the old
 libprotobuf-c0-dev is still available, and so packages that build-depend on 
 that
 will get libprotobuf-c0-dev. So they'll need sourceful uploads to 
 build-depend
 on the new (unversioned) libprotobuf-c-dev.

 Hi, Emilio:

 Are you sure about that?  protobuf-c-compiler has:

 Depends: ${shlibs:Depends}, ${misc:Depends}, libprotobuf-c-dev (= 
 ${binary:Version})


I believe the problem arises when you (build-)depend on
libprotobuf-c0-dev, without protobuf-c-compiler. That happened with
riemann-c-client:

 * I changed the build-dependency to libprotobuf-c-dev |
   libprotobuf-c0-dev + protobuf-c-compiler.
 * On unstable, that correctly pulled in libprotobuf-c-dev
 * Headers were generated using the new protobuf-c-compiler
 * The libriemann-client-dev package still had a dependency on
   libprotobuf-c0-dev, though.
 * syslog-ng-incubator build-depends on libriemann-client-dev, which
   pulled in libprotobuf-c0-dev and libprotobuf-c1!
 * syslog-ng-incubator FTBFS'd because of the generated header
   conflicted.

I ended up changing the libriemann-client-dev dependency to
libprotobuf-c-dev, and all is well.

So another thing to pay attention to is transitive build-dependency, as
that can - and will - break if one's not forcing libprotobuf-c-dev onto
the system.

 I think all of the packages I listed in my original email had a
 build-dep on either protobuf-c-compiler only, or protobuf-c-compiler and
 libprotobuf-c0-dev.  (I don't think there are any with just
 libprotobuf-c0-dev.)

Not directly, but transitively, syslog-ng-incubator build-depends on
libriemann-client-dev, which depended on libprotobuf-c0-dev only,
without protobuf-c-compiler. I'm not sure if there are other packages
like this, but the riemann-c-client + syslog-ng-incubator combo has been
taken care of.

-- 
|8]


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

Bug#755887: ITP: adderall -- a miniKanren implementation in Hy

[Gergely Nagy]

Package: wnpp
Severity: wishlist
Owner: Gergely Nagy alger...@madhouse-project.org

* Package name: adderall
  Version : 0.1.2
  Upstream Author : Gergely Nagy alger...@madhouse-project.org
* URL : https://github.com/algernon/adderall
* License : LGPL
  Programming Lang: Hy
  Description : a miniKanren implementation in Hy

This is a dependency of Hydiomatic, a Hy code transformer. But it's
useful in its own right too. I've yet to come up with a reasonable
long description, though. The module will be packaged under the
umbrella of pkg-hy, along with its dependency (monaxhyd) and
Hydiomatic.

Binary packages created will likely be called python-hy-adderall and
python3-hy-adderall.


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

Bug#755212: transition: protobuf-c

[Gergely Nagy]

Robert Edmonds edmo...@debian.org writes:

 The various riemann-c-client headers in /usr/include/riemann include
 proto/riemann.pb-c.h, and there's syslog-ng-mod-riemann (from
 syslog-ng-incubator) that uses the library, thus, the generated header
 too, transitively.

 Ah, right.  From a brief look at the source code for that module it
 looks like it doesn't require a (bin-)NMU at all, if I'm understanding
 the libriemann-client API correctly.

Yep, I agree. syslog-ng-incubator should not need a bin-NMU, as it uses
everything through the libriemann-client API, and never touches the
protobuf structures directly.

  I would recommend that the upstream developers ship a .proto file
  instead.
 
 I'd rather not ship a .proto file, if at all possible. I'll see if I can
 hide it completely.

 This would eliminate the problem, too.

 It looks like you typedef the structures generated by protoc-c and wrap
 them in your own API, e.g. from riemann/query.h:

 #include riemann/proto/riemann.pb-c.h

 typedef Query riemann_query_t;

 riemann_query_t *riemann_query_new (const char *string);
 void riemann_query_free (riemann_query_t *query);

 int riemann_query_set_string (riemann_query_t *query, const char *string);

 (Query is from typedef struct _Query Query in riemann.pb-c.h.)

 If your API callers always use the *_new(), *_free(), etc. functions and
 never try to dereference or calculate sizeof() on the wrapped struct's
 it might be possible to remove the #include of the .pb-c.h file and
 change your typedef to, e.g.:

 typedef struct _Query riemann_query_t;

 And then have riemann_query_t be an opaque type.  Though this depends
 on protoc-c continuing to generate structure tags with leading
 underscores, which may not always be the case.  (I've wanted to get rid
 of the leading underscores for a while now.)

 (Similiarly for the other riemann_*_t types that wrap protoc-c generated
 structures.)

 It might also be possible to wrap the structure types generated by
 protoc-c in your own opaque structure type and expose that wrapper type
 via your API.  Something like:

 typedef struct riemann_query riemann_query_t;

 riemann_query_t *riemann_query_new (const char *string);
 void riemann_query_free (riemann_query_t *query);

 int riemann_query_set_string (riemann_query_t *query, const char *string);

 (In riemann/query.h.)

 #include proto/riemann.pb-c.h

 struct riemann_query {
 Query query;
 };

 /* rest of the implementation... */

 (In lib/riemann/query.c.)

 That's a bit uglier since you have to update accesses to go via the
 wrapper but would provide the maximum amount of insulation between the
 libriemann-client API and the underlying structures generated by the
 protoc-c code generator.

I gave this some more thought, and there's a problem: while generating
riemann events and similar can be done with opaque types, if I do a
query, then I want to access the results, and to do that with opaque
types would mean I need a lot of getter functions (and an API + ABI
bump). So I'll stick to how it is done today, for the foreseeable
future.

But I'll keep your suggestions in mind in case I end up writing another
library that uses protobuf, I'll hide the protobuf stuff deeper then! :)

-- 
|8]


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

Bug#755212: transition: protobuf-c

[Gergely Nagy]

Robert Edmonds edmo...@debian.org writes:

 riemann-c-client
 

 Rebuilt by hand successfully against protobuf-c 1.0.0~rc2-1 from
 experimental.

 Has an unversioned build dependency on libprotobuf-c0-dev.  This
 needs to be updated to libprotobuf-c-dev eventually.

I can switch that to libprotobuf-c-dev | libprotobuf-c0-dev in the next
upload (I'd like to be able to compile the package on wheezy without
changes, hence the alternative). Since I just released a new upstream
version of the library, I'll be doing an upload at some point anyway,
I'll try to make it so that binNMUs won't be required after.

 Has a build dependency on protobuf-c-compiler and runs protoc-c
 during the build.

 No protoc-c generated symbols are exported by libriemann-client0.

 The libriemann-client-dev package exports the following header files
 generated by protoc-c:

 /usr/include/riemann/proto/riemann.pb-c.h

 However, I have not found any packages in the Debian archive which
 utilize this file.

The various riemann-c-client headers in /usr/include/riemann include
proto/riemann.pb-c.h, and there's syslog-ng-mod-riemann (from
syslog-ng-incubator) that uses the library, thus, the generated header
too, transitively.

 I would recommend that the upstream developers ship a .proto file
 instead.

I'd rather not ship a .proto file, if at all possible. I'll see if I can
hide it completely.

-- 
|8]


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

Bug#745014: src:syslog-ng: please update build-depends from libjson0-dev to libjson-c-dev

[Gergely Nagy]

Ondřej Surý ond...@debian.org writes:

 the json-c upstream has   dropped an compatibility layer from 
 libjson0(-dev)
 to libjson-c2(-dev) in current upstream release.

 Please update your build-depends from libjson0-dev to libjson-c-dev.

Thanks for the notice, it will be corrected with the next syslog-ng upload.

-- 
|8]


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

Bug#747020: syslog-ng-core: Add /var/log/error to /etc/logrotate.d/syslog-ng

[Gergely Nagy]

Facundo Aguirre facu...@creativadigital.com.ar writes:

 I think that /var/log/error should be in /etc/logrotate.d/syslog-ng like all
 the others files that are managed by the default configuration of
 syslog-ng-core.

Thanks for noticing this omission, it will be fixed in the next upload!

-- 
|8]


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

Bug#744182: syslog-ng: include option should be befor the log paths in the main syslog-ng.conf file

[Gergely Nagy]

jdossan...@docs.homelinux.org writes:

 The @include /etc/syslog-ng/conf.d/ option is on the bottom of the
 syslog-ng.conf file, but it should be befor the log paths, as example:

Good catch, I'll consider updating the default config with the next
syslog-ng upload. Thanks for the suggestion!

(Putting the includes at the end had other, beneficial properties, so
moving them further up isn't as straightforward as one might imagine. It
can easily break existing configurations, which is something I'd rather
avoid. But I'll explore my options anyway!)

-- 
|8]


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

Bug#739932: aalib: FTBFS with clang instead of gcc

[Gergely Nagy]

Hi!

Arthur Marble art...@info9.net writes:

 Using the rebuild infrastructure, your package fails to build with clang 
 (instead of gcc).

I checked the patch, but it returns 2, while the comment above the
function says that it should return 0 on failure, and it is used as such
later. Returning 2 there will result in buggy behaviour.

I'll change it to return 0, and upload a fixed version in a couple of
hours. Thanks for the bug report and the effort!

-- 
|8]


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

Bug#739604: sysvinit: The new skeleton does not work on kFreeBSD

[Gergely Nagy]

Source: sysvinit
Version: 2.88dsf-50
Severity: serious

The change introduced in sysvinit 2.88dsf-50, which turns
/etc/init.d/skeleton into a script that has /lib/init/init-d-script as
interpreter fails on kFreeBSD, because on that platform, interpreters
cannot be other scripts.

To demonstrate:

,[ test.sh ]
| #!/lib/init/init-d-script
| DAEMON=/bin/uname
`

On linux, running ./test.sh prints the usage. On kFreeBSD (as tested
locally and on falla.d.o), it prints nothing, because the #! line will
be ignored, it being a script and all.

If you want to do this kind of thing, you will either need a binary
wrapper at least on kFreeBSD, or you'll need to use sourcing.

-- 
|8]


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

Bug#739604: sysvinit: The new skeleton does not work on kFreeBSD

[Gergely Nagy]

Petter Reinholdtsen p...@hungry.com writes:

 [Gergely Nagy]
 The change introduced in sysvinit 2.88dsf-50, which turns
 /etc/init.d/skeleton into a script that has /lib/init/init-d-script
 as interpreter fails on kFreeBSD, because on that platform,
 interpreters cannot be other scripts.

 Oh.  I tested on Linux and Hurd, and did not imagine that kFreeBSD was
 that different from these two. :)

It's Linux (since 2.6), Hurd and Minix being different from anything
else :)

 If you want to do this kind of thing, you will either need a binary
 wrapper at least on kFreeBSD, or you'll need to use sourcing.

 Right.  Back to the drawing board. :)

 Can you test this construct instead of #!/lib/init/init-d-script:

   #!/bin/sh
   if [ true != $INIT_D_SCRIPT_SOURCED ] ; then
 set $0 $@; INIT_D_SCRIPT_SOURCED=true . /lib/init/init-d-script
   fi

I can try it tomorrow or so. If you want, you can try it on the kfreebsd
porter boxes, it's easily reproducible there.

-- 
|8]


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

Bug#736656: libdbi-drivers: drivers not found anymore, due to multi-arch

[Gergely Nagy]

Source: libdbi-drivers
Version: 0.9.0-1
Severity: grave
Justification: renders package unusable

libdbi1 0.9.0-1 is built with a multi-arch, and will search for
drivers in a multi-arch directory, but the binaries produced from
libdbi-drivers still produce packages that use the old, non-multiarch
directory. This renders any software using libdbi unusable, as they
will not be able to find drivers.

(Originally reported by Matt Zagrabelny mzagr...@d.umn.edu on the
syslog-ng mailing list)

-- System Information:
Debian Release: jessie/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.12-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash


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

Bug#736240: libdbi: debian/copyright file mistakes

[Gergely Nagy]

Source: libdbi
Version: 0.8.4-6

The debian/copyright file lists the license of libdbi as LGPLv2.1, while
in reality, it is LGPLv2.1+. Also, there are a couple of files that have
a diferent license (at least in 0.9.0-1), namely:

 * src/asprintf.c: This one says ripped from gcc - it would be nice to
   figure out the proper license for this.
 * src/atoll.c: This one is (C) MySQL AB, and is LGPLv2+, where the L is
   Library, not Lesser.

The copyright file also seems to be a bit of a mess, you don't need to
list *why* a person has copyright on a file. But this is just nit
picking, and likely personal preference. The above three problems do
need a fix, though.

-- 
|8]


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

Bug#635659: libdbi{,-drivers} maintenance

[Gergely Nagy]

László Böszörményi (GCS) g...@debian.org writes:

 I'm the maintainer of sqlite and sqlite3 and back then I was the only
 syslog-ng maintainer. Thus when I saw libdbi and libdbi-drivers is up
 for adoption, started working on them. It was March, last year. When
 almost finished, I put it down, I don't know the reason.
 Still, yesterday I've made the last bits. Both build fine with
 pbuilder. You can grab them[1][2] for testing. May I be their
 maintainers, adding whoever wants it as uploader or is there anyone
 else to continue the packaging?

As I said before, the less work I need to do, the better, so since the
update is all done and seems to be well, I'm happy. I think the lot of
you are enough to be Uploaders, I don't need to be there.

So as far as I'm concerned, go ahead and upload!

-- 
|8]


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

Bug#635659: Any progress? (Was: Re: RFA: libdbi)

[Gergely Nagy]

Hi!

I was wondering if there's any progress in adopting the package, and
packaging the new upstream version? syslog-ng could really use an
updated (0.9.0+) version. If there's no progress, I would like to update
the package to the new upstream version, and bring it under
collab-maint/ on git.d.o. (And possibly adopt it, for the time being)

-- 
|8]


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

Bug#635659: Any progress?

[Gergely Nagy]

Control: retitle -1 ITA: libdbi -- DB Independent Abstraction Layer for C

Thomas Goirand z...@debian.org writes:

 On 01/15/2014 06:03 PM, Gergely Nagy wrote:
 Hi!
 
 I was wondering if there's any progress in adopting the package, and
 packaging the new upstream version? syslog-ng could really use an
 updated (0.9.0+) version. If there's no progress, I would like to update
 the package to the new upstream version, and bring it under
 collab-maint/ on git.d.o. (And possibly adopt it, for the time being)

 Hi,

 Please go ahead and adopt libdbi and libdbi-drivers.

 Since these 2 packages are high in the popcon, it is important that the
 work is done well, with care, taking enough time to do so. I did fill a
 RFA for that reason: I don't have time to maintain it correctly (I
 already maintain too many packages in Debian).

 If you adopt it and put it in the git of collab-maint, then great!
 Please keep me in the uploaders list then.

They will be taken good care of. Since it is something we need at $work,
I'll have enough time to do a good job. I'll keep you in uploaders for
both packages.

-- 
|8]


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

Bug#635658: ITA

[Gergely Nagy]

Control: retitle -1 ITA: libdbi-drivers -- Database drivers for libdbi

As mentioned in #635659, I'll be adopting libdbi, and this package too.

-- 
|8]


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

Bug#635659: Any progress?

[Gergely Nagy]

Prach Pongpanich prach...@gmail.com writes:

 I have been waiting for your response for long time.

I can put you both as Uploaders. Or even better, I'd be happiest if I
didn't have to adopt the package at all. If a 0.9.0 packaging can be
done and upload within a week, that's fine with me. The less I need to
do, the better.

-- 
|8]


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

Bug#730333: php-opencloud: VCS- links are 404

[Gergely Nagy]

Source: php-opencloud
Version: 1.6.0+dfsg-1

The VCS fields in the package reference a repository that does not
exist. As far as I see, an s/pkg-opencloud/pkg-php/g; needs to be
applied to it.

(If anyone reading this on unknown-package@, php-opencloud just cleared
NEW, and the maintainer is CC'd.)

-- 
|8]


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

Bug#730314: ITP: syslog-ng-incubator -- Extra modules for syslog-ng

[Gergely Nagy]

Package: wnpp
Severity: wishlist
Owner: Gergely Nagy alger...@madhouse-project.org

* Package name: syslog-ng-incubator
  Version : git master (or whatever I call it by the time I
get there)
  Upstream Author : BalaBit IT Security Ltd.
* URL : https://github.com/balabit/syslog-ng-incubator
* License : GPL2+
  Programming Lang: C
  Description : Extra modules for syslog-ng

The syslog-ng module incubator is a collection of tools and modules
for syslog-ng that for one reason or the other, are not part of the
official repository. This serves both as a staging ground for
experimental modules, and as a repository of plugins that are not
aimed at upstream inclusion. It's also an example of a third party
syslog-ng module.

The package would contain the Riemann destination, a trigger-source
for debugging, a couple of new template functions and various small
utilities.

The packaging is reasonably complete, needs some polishing, and
riemann-c-client[1] to get through NEW. Maintenance will be under the
umbrella of the syslog-ng maintainers[2].

 [1]: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=728591
 [2]: https://alioth.debian.org/projects/syslog-ng/


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

Bug#729991: syslog-ng-core uninstallable

[Gergely Nagy]

Martin Bagge / brother brot...@bsnet.se writes:

 On 2013-11-20 15:57, Gergely Nagy wrote:
 The file() thing here comes from the system() source. system() is 
 expanded at run-time, depending on the OS/platform/whatever
 syslog-ng is running on.
 
 You can run syslog-ng --preprocess-into=/dev/stdout -s to see
 what it does with the config file. You'll find the
 file(/dev/kmsg) thing there.

 root@drake~# syslog-ng --preprocess-into=/dev/stdout -s
 root@drake~# echo $?
 0

Right, looks like /dev/stdout is a thing in my shell. Can you try
syslog-ng -s --preprocess-into=/tmp/processed-config.txt, and send the
/tmp/processed-config.txt to me?

 Can you tell me the kernel version you have? And does this happen
 in a container, VM, or on bare metal?

 root@drake~# uname -a
 Linux drake 3.2.0-4-686-pae #1 SMP Debian 3.2.51-1 i686 GNU/Linux

 VM on top of VMware ESXI 4.1

Thanks, I'll test with that and see if I can reproduce the problem.

-- 
|8]


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

Bug#729991: syslog-ng-core uninstallable

[Gergely Nagy]

Control: tag -1 upstream

I managed to reproduce the problem using a 3.2 kernel, I know how to fix
it, and I'm now working on a patch (it's not trivial to make the fix
nice).

I expect I'll be able to do a 3.5.2 release early next week, and the
package will hit unstable a few hours later.

-- 
|8]


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

Bug#725668: syslog-ng: Space in ident ends up in msg instead of the program macro

[Gergely Nagy]

Control: found -1 3.5.1-1

Allan Wind allan_w...@lifeintegrity.com writes:

 If ident contains space (like fail2ban does) then the space and the ':' 
 separator ends up in msg.  Configured syslog-ng with the following:

 template tagged {
 template(r_isodate=$R_ISODATE host=$HOST program=$PROGRAM pid=$PID 
 msg=$MSG\n);
 };
 destination debug {
 file(/tmp/syslog-ng.log frac_digits(3) template(tagged));
 };
 log {
 source(input);
 destination(debug);
 };

 and logging an ident with space:

 allan@pawan:~$ logger --tag 'test ' msg

 results in this log event:

 r_isodate=2013-10-07T03:09:46.652-04:00 host=pawan program=test pid= 
 msg=: msg

 where I expected program = 'test ' and msg='msg' (no quotes).

Unfortunately, the BSD syslog protocol is weird and not exactly clear.
The RFC (3164) says this:

 Most commonly, the first character of the CONTENT field that signifies
 the conclusion of the TAG field has been seen to be the left square
 bracket character ([), a colon character (:), or a space character.
 This is explained in more detail in Section 5.3.

In practice, if we ignored whitespace between : and the program name,
we may break other, legacy applications. I would rather suggest fixing
fail2ban to not send a space.

I tried to take a look at the fail2ban sources, but couldn't find where
it puts the space into the message. Can you perhaps send me a sample?

-- 
|8]


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

Bug#729575: syslog-ng-core: bogus date for kernel messages

[Gergely Nagy]

Control: tag -1 upstream

Found the issue, I'm pushing a fix into git, fixed package should hit
unstable early next week latest. Thanks for the report and the
assistance!

-- 
|8]


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

Bug#729575: syslog-ng-core: bogus date for kernel messages

[Gergely Nagy]

Jakub Wilk jw...@debian.org writes:

 * Gergely Nagy alger...@balabit.hu, 2013-11-15, 17:05:
syslog-ng has just logged this:

1961-02-05T20:15:59+01:00 borsuk kernel: usb 1-2: USB disconnect, device 
number 5

 The timestamp is obviously bogus. My system date is correct, and
 non-kernel messages are logged with correct timestamps.

 According to my logs this started happening after the 3.3.9-1 -
 3.5.1-1 
upgrade.

Likely not relevant, but are you using systemd?

 Nope, the good old sysvinit.

Do all kernel messages have bogus dates, or only a few ones?

 All of them.

Hm... I have not been able to reproduce it yet... can you change your
template to include ${.linux.timestamp} too, and send me a sample?

-- 
|8]


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

Bug#729575: syslog-ng-core: bogus date for kernel messages

[Gergely Nagy]

Jakub Wilk jw...@debian.org writes:

 * Gergely Nagy alger...@balabit.hu, 2013-11-21, 14:42:
Hm... I have not been able to reproduce it yet...

 I suspect the bug might be architecture-specific. I can reproduce it
 on i386, but not on amd64.

Mhm, great, then I have a suspicion where the problem lies.

 can you change your template to include ${.linux.timestamp} too, and
 send me a sample?

 With

   template($YEAR-$MONTH-$DAY $HOUR:$MIN:$SEC (${.linux.timestamp}) 
 $MSG\n);

 I've got this:

 1961-02-05 14:29:55 (2278410933) fb1: VESA VGA frame buffer device

Good, good, so parsing is correct, computing the date is off, though.
Thanks, this narrows things down considerably!

-- 
|8]


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

Bug#729991: syslog-ng-core uninstallable

[Gergely Nagy]

Andrei POPESCU andreimpope...@gmail.com writes:

 On Mi, 20 nov 13, 00:19:49, Martin Bagge / brother wrote:
[...]

 [] Starting system logging: syslog-ngUnable to determine how to
 monitor this file, follow_freq() unset and it is not possible to poll
 it with the current ivykis polling method. Set follow-freq() for
 regular files or change IV_EXCLUDE_POLL_METHOD environment variable to
 override the automatically selected polling method;
 filename='/dev/kmsg', fd='9'
 Error initializing message pipeline;
  failed!
 invoke-rc.d: initscript syslog-ng, action start failed.

The file() thing here comes from the system() source. system() is
expanded at run-time, depending on the OS/platform/whatever syslog-ng is
running on.

You can run syslog-ng --preprocess-into=/dev/stdout -s to see what it
does with the config file. You'll find the file(/dev/kmsg) thing
there.

Can you tell me the kernel version you have? And does this happen in a
container, VM, or on bare metal?

As a quick workaround, you can remove the system() line from the config,
and replacing it with whatever it expands to (see the command above),
without the /dev/kmsg part.

-- 
|8]


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

Bug#729575: syslog-ng-core: bogus date for kernel messages

[Gergely Nagy]

Jakub Wilk jw...@debian.org writes:

 Package: syslog-ng-core
 Version: 3.5.1-1

 syslog-ng has just logged this:

 1961-02-05T20:15:59+01:00 borsuk kernel: usb 1-2: USB disconnect, device 
 number 5

 The timestamp is obviously bogus. My system date is correct, and
 non-kernel messages are logged with correct timestamps.

 According to my logs this started happening after the 3.3.9-1 -
 3.5.1-1 
 upgrade.

Likely not relevant, but are you using systemd?

Do all kernel messages have bogus dates, or only a few ones?

-- 
|8]


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

Bug#728716: RFS: xchroot/2.3.2-9 [ITP] -- Hi Debian!

[Gergely Nagy]

Elmar Stellnberger estel...@elstel.org writes:

 Am 04.11.13 18:43, schrieb Paul Tagliamonte:



 On Mon, Nov 4, 2013 at 12:42 PM, Paul Tagliamonte
 paul...@debian.org mailto:paul...@debian.org wrote:

 On Mon, Nov 04, 2013 at 06:22:15PM +0100, Elmar Stellnberger wrote:
  Is it really a problem? If yes then I can add an exception for
  distributors like Debian.

 Perhaps you're interesting in reading our guidelines:

 http://www.debian.org/social_contract#guidelines

 point 8 is License Must Not Be Specific to Debian.

 We could possibly allow any distribution to distribute patches without
 notifying the
 original authors as far as the term distribution can be defined
 clearly and
 doubtlessly (i.e. to only apply this restriction to individuals and
 organizations who
 do not distribute their software for free to the public; if that would
 help us).

That will not be possible, due to DFSG#3 (derived works): The license
must allow modifications and derived works, and must allow them to be
distributed under the same terms as the license of the original
software.

Which means that whoever gets the software through Debian MUST be able
to redistribute it under the very same terms Debian did.

Furthermore, there are many distributions derived from Debian, asking
all of them to send you patches whenever they make the tiniest
modification (even to packaging!) is not going to work, neither for you,
nor for Debian, nor for any of the distributions based on it.

I would strongly suggest you reconsider your license, or at least this
requirement, as it will never, ever work as you expect it to: people
will just not use your software, because requiring them to send patches
back no matter what is so huge a pain in the backside that noone in
their right mind will do it. It's a much smaller effort to find an
alternative (like schroot, in this case) or roll your own.

Furthermore, there's this part of the license:

 If you want to develop a separate branch of this program you need to
 ask the original authors for permission.

That goes against DFSG#4, which permits the author to require
distribution under a different name, but still requires the license to
allow distributing patched versions. The quoted paragraph prevents that,
so much so, that it's far too strict even for non-free: if we ever want
to do a non-maintainer upload for whatever reason, it's not possible,
because that may very well mean develop a separate branch, and thus
require asking for permission.

Furthermore, the quoted paragraph also has a loophole: it only requires
one to ask the original authors for permission, it does not say that
the permission needs to be granted too. In a strict reading of the text,
just asking for permission and not waiting for an answer is ok. Even
better, asking, but receiving a negative answer is still ok, because one
asked.

Going further:

 Distribution of the program by third parties must be done free of
 charge apart from fees for the physical reproduction of the data
 medium

This goes against DFSG#1: The license of a Debian component may not
restrict any party from selling or giving away the software as a
component of an aggregate software distribution containing programs from
several different sources. The license may not require a royalty or
other fee for such sale.

While this part may be okay for non-free, it definitely is a no-go for
main. The exceptions given do not matter.

The way distribution is defined is also a bit odd: The term
distribution describes shipping of a given set of software and its
documentation with adherent materials.

So if I strip away parts of the software (like documentation), and
publish that, does that count as distribution? Strictly reading the
license: no, because adherent materials are not shipped with it.

 Availablity free of charge or costs includes tools, software and
 manuals needed to download or obtain the distribution in a finally
 usable state as well as the possibility to verify the integrity of the
 download securely but not general connectivity to the internet.

This part is also quite vague. Lets imagine the following scenario:
there's Joe Average user, installing GNU/Linux for the first time. He
has absolutely no idea how to do it, so he buys a book about the topic.
To install additional software, such as those covered by this license,
he uses tools and techniques described in the manual, for which he paid
for. In this case, the distribution is not allowed to let Joe Average
install programs covered by this license, because he needed a paid-for
manual to install the distribution and the software covered by the
license in question.

That's not going to work, either.
 
  However what I want is being noticed somehow about changed versions
  of my programmes.

 That's OK. It just means you need to upload to non-free.

 I hope that will not pose an unnecessary restriction to the
 re-distribution as
 the program may f.i. also be especially 

Bug#728716: RFS: xchroot/2.3.2-9 [ITP] -- Hi Debian!

[Gergely Nagy]

Elmar Stellnberger estel...@gmail.com writes:

 S-FSL v1.3.3 uploaded at http://www.elstel.org/license/

   Having clearly considered your critics I have published a reworked
 edition
 of S-FSL which should more strictly adhere to the terms of OSS-software.

 As you can understand and as I have already partially described there are
 still issues to me which discourage me from using an existing license like
 f.i. GPL or BSD.

I wouldn't mind hearing the full explanation, because I honestly see far
more issues with a new license than with using any of the existing,
battle-tested ones.

I will review the current (1.3.3) license, but that's about as much time
as I'm willing to spend on it. I would recommend getting your license
OSI[1] approved, to make things much easier for distributors like
Debian.

 [1]: http://opensource.org/approval

So, about that review:

  This program may be used free of charge. It has been designed as
  research work and comes without claim for fitness to any particular
  usage purpose and completely without warranty or any kind of liability
  such as lost revenues, profits, harm or damage of any kind.

So far, so good.

  The program may be distributed by a third party given that the program
  is distributed in its original state completely without any kind of
  modifications or patches.

This fails DFSG#3 and DFSG#4, but...

  If you need to re-distribute a patched version of this program you
  need to distribute the patches separately from the original so that
  the pristine version can be restored at any time. Any derived work
  must carry the name of the distributor, vendor or the product in its
  name (or a unique shothand for it) preceded by the original unchanged
  name of the software and its version.

With this clarification, it passes DFSG#3 and DFSG4, but only barely.
  
  Modifications applied to this program may not affect the name,
  original version, copyright or any reference given to the authors such
  as their email addresses or their web presence and/or page in any part
  of the program or any files attached to the program.

What exactly does this mean? Does that mean that if someone makes a
modification in form of a patch, he can't add his copyright to the
modified files? Or does that mean that they can't modifiy the original
copyright  license notes?

Or, another question: what if a software under this license is included
in something like Debian, where after the freeze, you're not supposed to
upload new versions of the software, but the upstream webpage moves, or
e-mail address changes, and for some reason, the maintainer wants to
correct that in the package. She then has to modify the email addresses
and URLs in the package, which would - in my reading - go against the
license.
  
  You may only extend or modify this program given that you do also
  consent with the following terms. As far as you are not a public
  distributor you are oblidged to send a copy of your patches to the
  original authors referred to herein as the authors of the first
  version of the program as being listed in the changelog or program
  header whenever you publish or exchange your patches with other
  people.

This is against DFSG6: no discrimination against fields of endeavor. It
discriminates non-public distributors (whatever they may be), which
makes the license non-free at best.

It also is unclear about what a public distributor is (ok, that's
explained a bit better later, see my comments there). Consider that
Debian is not a legal entity, either. Software within Debian are
distributed using a mirror network, some of which are operated by
commercial entities. There are also private mirrors of Debian (my
company has one too, for internal use), which would not be able to carry
software under this license, since they're not public distributors.

In this reading, it's not ok for non-free, either, as it cannot be
distributed by Debian at all.

Also, the wording is unclear: whenever you publish or exchange your
patches with other people is very vague. If someone downloads the
patches from a mirror, that can be considered exchange. Do I, as a
distributor, need to send the same patch every time someone downloads
it? Do I, as a developer, need to send the patch every time I send it in
for internal review? Do I need to send work in progress patches too?
(It's a patch, and I'm sharing it with collegues, after all!)

That is unreasonable and unenforcable, and clearly goes against the
spirit of free software. Furthermore, trying to force out such strict
control of the software is very discouraging for potential contributors.

  By distributing patches you do consent apart from this that the
  original authors may incorporate your patches into future versions of
  this program. The patched parts of the program and the patches
  themselves will also become subject to this licensing and may even be
  used for free in other programs or in the same program under different
  licensing as soon 

Bug#728591: ITP: riemann-c-client -- C language client library for the Riemann event stream processor

[Gergely Nagy]

Package: wnpp
Severity: wishlist
Owner: Gergely Nagy alger...@madhouse-project.org

* Package name: riemann-c-client
  Version : 1.0.1
  Upstream Author : Gergely Nagy alger...@madhouse-project.org
* URL : https://github.com/algernon/riemann-c-client/
* License : LGPL-3+
  Programming Lang: C
  Description : C language client library for the Riemann event stream 
processor
 Riemann is a network event stream processor, intended for analyitics,
 metrics and alerting; and to glue various monitoring systems together.
 .
 This library provides a C language client, with a simple but
 convenient API, to connect to Riemann, send events and run queries
 against it.

I already have the debianisation complete, it just needs to be
uploaded. This is a dependency of the syslog-ng-incubator project
which I also plan to upload shortly after syslog-ng 3.5 made it into
unstable.


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

Bug#728592: RFA: mikmod -- Portable tracked music player

[Gergely Nagy]

Package: wnpp
Severity: normal

I request an adopter for the mikmod package. The package recently got
a new upstream maintainer, and a new release has been made with quite
a lot of important improvements (such as working ALSA support).
Unfortunately, I lack the time to properly take care of the new
upstream release and package it, so I'm looking for a someone to take
it over (along with libmikmod, as they go hand in hand).

The package description is:
 Mikmod is a very portable tracked music player which supports a wide
 variety of module formats including compressed sample Impulse Tracker
 modules. It also supports many archive formats, as well as on the fly
 decompression.


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

Bug#728593: RFA: libmikmod -- Portable sound library

[Gergely Nagy]

Package: wnpp
Severity: normal

I request an adopter for the libmikmod package. It recently got a new
upstream maintainer and new, much improved releases have been made,
which should be packaged. I lack the time to take good care of the
package, hence the request for a new maintainer. This goes hand in
hand with the mikmod package, which is also up for adoption, and
should be maintained by the same person or team.

The package description is:
 This library is capable of playing samples as well as module
 files and was originally written by Jean-Paul Mikkers (MikMak) for DOS. It has
 subsequently been hacked by many hands and now runs on many Unix flavours.
 It uses the OSS /dev/dsp driver included in all recent kernels for output,
 and will also write wav files.
 .
 Supported file formats include mod, stm, s3m, mtm, xm, and it.


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

Bug#710473: bats: 0.3.1 status?

[Gergely Nagy]

Hi!

I have recently started playing with the idea of using BATS, and came
across your ITP and RFS. However, for my use, I'd need a more recent
version (0.3.1+). Could you update your packaging to that version? I'd
be happy to review and sponsor it afterwards.

-- 
|8]


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

Bug#727683: lintian: erroneously reports a warning on :-separated RPATHs

[Gergely Nagy]

Package: lintian
Version: 2.5.19
Severity: normal

While working on my unofficial syslog-ng packages[1], I came across a
spurious warning when running Lintian on the results:

E: syslog-ng-core: binary-or-shlib-defines-rpath 
usr/lib/syslog-ng/3.5.0rc1/libcryptofuncs.so 
/usr/lib/syslog-ng:/usr/lib/syslog-ng/3.5.0rc1

This seemed strange, as the RPATH some of the binaries set
(/usr/lib/syslog-ng:/usr/lib/syslog-ng/3.5.0rc1) is, by the letter of
policy, allowed: both components are under /usr/lib/$srcpkg.

The reason lintian fails is because it's prepared to find multiple
RPATHs set within an object, but not for the case where a single
record uses : as a separator (a'la PATH). It ends up checking that the
rpath is either /usr/lib/$srcpkg or /usr/lib/$srcpkg/: the ':'
confuses it.

I will submit a patch in a few minutes that corrects lintian by
splitting the rpath into components first.

-- System Information:
Debian Release: jessie/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.10-3-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages lintian depends on:
ii  binutils   2.23.90.20130927-1
ii  bzip2  1.0.6-5
ii  diffstat   1.57-1
ii  file   1:5.14-2
ii  gettext0.18.3.1-1
ii  hardening-includes 2.4
ii  intltool-debian0.35.0+20060710.1
ii  libapt-pkg-perl0.1.29+b1
ii  libarchive-zip-perl1.30-7
ii  libclass-accessor-perl 0.34-1
ii  libclone-perl  0.35-1
ii  libdigest-sha-perl 5.85-1+b1
ii  libdpkg-perl   1.16.12
ii  libemail-valid-perl1.192-1
ii  libfile-basedir-perl   0.03-1
ii  libipc-run-perl0.92-1
ii  liblist-moreutils-perl 0.33-1+b2
ii  libparse-debianchangelog-perl  1.2.0-1
ii  libtext-levenshtein-perl   0.06~01-2
ii  libtimedate-perl   1.2000-1
ii  liburi-perl1.60-1
ii  man-db 2.6.5-2
ii  patchutils 0.3.2-2
ii  perl [libdigest-sha-perl]  5.18.1-4
ii  t1utils1.37-2

Versions of packages lintian recommends:
ii  libautodie-perl 2.21-1
ii  libperlio-gzip-perl 0.18-1+b3
ii  perl-modules [libautodie-perl]  5.18.1-4

Versions of packages lintian suggests:
pn  binutils-multiarch none
ii  dpkg-dev   1.16.12
ii  libhtml-parser-perl3.71-1+b1
ii  libtext-template-perl  1.46-1
ii  xz-utils   5.1.1alpha+20120614-2

-- no debconf information


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