Bug#1063191: libcifpp-data: Incorrect URL in update-libcifpp-data script

[Maarten L. Hekkelman]

Hi Andreas,

The URL's were updated in upstream some time ago. The debian version of 
libcifpp (and all dependent tools) are a bit out of date.


The problem I have is that development of libcifpp is a bit too fast. 
Whenever I break the ABI I have to ask for someone to upload a newer 
version. And last time this apparently did not went well and so the 
update stalled. I don't remember who I asked to update, but since that 
didn't happen I forgot about it.


Anyway, so I had an upload ready for version 5.2 and libcifpp is now at 
version 6.1. I will thus have to prepare yet another update and then 
upload all depending packages. I'll see what I can do.


regards, -maarten

Op 13-02-2024 om 08:28 schreef Andreas Tille:

Hi Maarten,

since last September there is a new upstream version in Git which was
not uploaded.  I see less instances of ftp.wwpdb.org in this code but
there are some remainings.  It would be great if you could upload your
preparation after checking that the bug below is fixed.

Kind regards
Andreas.

Am Mon, Feb 05, 2024 at 11:27:36AM -0500 schrieb Rick Bernard:

Package: libcifpp-data
Version: 5.0.7.1-3
Severity: important
Tags: patch

Dear Maintainer,

*** Reporter, please consider answering these questions, where appropriate ***

* What led up to the situation?
Installing libcifpp-data via "apt install".  The incorrect URL causes apt to
hang for a long period of time before returrning to a prompt.  As a result, the
file supposed to be loaced in /var/cache/libcifpp/components.cif fails to
download.  The Stable version of this package was showing timeout errors when
attempting to connect to https://ftp.wwpdb.org.  The correct URL that is
published by wwpdb.org is https://files.wwpdb.org for downloading via HTTP.
This will happen durring install via apt when you are prompted Package
configuration about setting up weekly downloads of these data files from
wwpdb.org.

* What exactly did you do (or not do) that was effective (or
  ineffective)?
 Editing the file /etc/cron.weekly/update-libcifpp-data and changing the URL
for the components.cif download from https://ftp.wwpdb.org to
https://files.wwpdb.org leaving all subpaths the same resolves the issue.  This
also helps with the stable version of this package and fixes dpkg and apt when
running "dpkg --configure -a"

* What was the outcome of this action?
  Resolves the package install and fixes apt/dpkg package management system.

* What outcome did you expect instead?
 The expected outcome is that "apt install" will successfully install the
package and be able to run the download scripts successfully.

*** End of the template - remove these template lines ***


-- System Information:
Debian Release: 12.4
   APT prefers stable
   APT policy: (990, 'stable'), (500, 'stable-security'), (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.1.0-17-amd64 (SMP w/12 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libcifpp-data depends on:
ii  debconf [debconf-2.0]  1.5.82

libcifpp-data recommends no packages.

libcifpp-data suggests no packages.

-- debconf information:
* libcifpp/update: true
--- update-libcifpp-data.orig   2024-02-05 11:13:15.964579981 -0500
+++ update-libcifpp-data2024-02-05 11:24:35.219320601 -0500
@@ -60,7 +60,7 @@
  
  # Update the dictionaries
  
-update_dictionary "/var/cache/libcifpp/components.cif" "https://ftp.wwpdb.org/pub/pdb/data/monomers/components.cif.gz;

+update_dictionary "/var/cache/libcifpp/components.cif" 
"https://files.wwpdb.org/pub/pdb/data/monomers/components.cif.gz;
  update_dictionary "/var/cache/libcifpp/mmcif_pdbx.dic" 
"https://mmcif.wwpdb.org/dictionaries/ascii/mmcif_pdbx_v50.dic.gz;
  update_dictionary "/var/cache/libcifpp/mmcif_ma.dic" 
"https://github.com/ihmwg/ModelCIF/raw/master/dist/mmcif_ma.dic;
  
___

Debian-med-packaging mailing list
debian-med-packag...@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-med-packaging




--
Maarten L. Hekkelman
http://www.hekkelman.com/

Bug#1060267: -qmake: emits wrong QT_HOST_LIBEXECS - fix

[Maarten van der Schrieck]

ho "This is fixed by adding the following line to $QT6CONF"
echo "   $LINE"
run sh -c "echo \"$LINE\" >> $QT6CONF"

echo "@@Cross compiling for armel, with patch..."
run sh -c "make clean && arm-linux-gnueabi-qmake6 && make -j"
echo "@@Resulting binary:"
run ls -alh http
run file http
echo "@@The above is expected to show a valid ARM binary of ~79K"

} 2>&1 | sed -e "s/^/   /;s/^   @@//;s/^\(.\{$MAX_LINE_LEN\}\).*/\1/"

EOF

The script shows various results (failing/succeeding builds) and
indicates what is expected.

Kind regards, Maarten

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

Kernel: Linux 4.19.0-10-amd64 (SMP w/8 CPU threads)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to 
C.UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: unable to detect

Versions of packages qmake6 depends on:
ii  perl5.38.2-3
ii  qmake6-bin  6.4.2+dfsg-21

qmake6 recommends no packages.

qmake6 suggests no packages.

-- no debconf information

Bug#1061954: frog: NMU diff for 64-bit time_t transition

[Maarten van Gompel]

Hi Joost, Lukas, 

On second thought, I read https://wiki.debian.org/ReleaseGoals/64bit-time and 
checked the updated Frog sources, there is no time_t
exposed at all anymore in the new version I'm packaging. So if I understand 
things correctly, the new
libfrog3 library does not need the t64 transition and I can revert
https://salsa.debian.org/science-team/frog/-/commit/2bbda8d92d40b96a216e8d8db972a9589f8df02f
 ?

> Afaik the plan is to keep the binary packages named libt64 (reading
> https://wiki.debian.org/ReleaseGoals/64bit-time ); this helps executing the
> transition.

I'll rebase so the libfrog2t64 patch is included, but it'll be
immediately superseded by libfrog3.

Regards,

-- 

Maarten van Gompel (proycon)

web: https://proycon.anaproy.nl
gpg: 0x39FE11201A31555C


signature.asc
Description: PGP signature

Bug#1061954: frog: NMU diff for 64-bit time_t transition

[Maarten van Gompel]

Hi Lukas,

On Tue Jan 30, 2024 at 2:31 PM CET, Lukas Märdian wrote:
> As part of the 64-bit time_t transition required to support 32-bit
> architectures in 2038 and beyond
> (https://wiki.debian.org/ReleaseGoals/64bit-time), we have identified
> frog as a source package shipping runtime libraries whose ABI
> either is affected by the change in size of time_t, or could not be
> analyzed via abi-compliance-checker (and therefore to be on the safe
> side we assume is affected).
>
> To ensure that inconsistent combinations of libraries with their
> reverse-dependencies are never installed together, it is necessary to
> have a library transition, which is most easily done by renaming the
> runtime library package.
>
> Since turning on 64-bit time_t is being handled centrally through a change
> to the default dpkg-buildflags (https://bugs.debian.org/1037136), it is
> important that libraries affected by this ABI change all be uploaded close
> together in time.  Therefore I have prepared a 0-day NMU for frog
> which will initially be uploaded to experimental if possible, then to
> unstable after packages have cleared binary NEW.
>
> Please find the patch for this NMU attached.
>
> If you have any concerns about this patch, please reach out ASAP.  Although
> this package will be uploaded to experimental immediately, there will be a
> period of several days before we begin uploads to unstable; so if information
> becomes available that your package should not be included in the transition,
> there is time for us to amend the planned uploads.

Thanks for your patch. I am currently in the progress of upgrading these
packages to the new upstream sources after a long hiatus. This would
involve a library transition anyway (libfrog2 -> libfrog3). Is it
sufficient if I include  'Provides: ${t64:Provides}' for the new
libfrog3 package to accomodate this transition? I just did this in
commit 2bbda8d92d40b96a216e8d8db972a9589f8df02f:
  
  
https://salsa.debian.org/science-team/frog/-/commit/2bbda8d92d40b96a216e8d8db972a9589f8df02f

Perhaps that also removes the need for the oddly named frog2t64 package?
If not, I'll apply your patch and rebase my changes on top of it.

Regards,

-- 

Maarten van Gompel (proycon)

web: https://proycon.anaproy.nl
gpg: 0x39FE11201A31555C


signature.asc
Description: PGP signature

Bug#1052445: Transition: libpqxx 6.4->7.8

[Maarten van Geijn]

reassign 1052445 release.debian.org

On 22/09/2023 17:22, Christoph Berg wrote:

Re: Maarten van Geijn

Hi Christoph,

Thanks for pointing this out.
Yes, this is intended as pre-approval request for the transition into sid. I
got this https://wiki.debian.org/Teams/ReleaseTeam/Transitions site, from
which I understood that a bug-report on this was necessary for the sid
upload, but perhaps I misunderstood.


Yes, a bug report on the "release.debian.org" pseudo package.

(You can reassign this bug, or open a new one.)

Christoph



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1052445: Transition: libpqxx 6.4->7.8

[Maarten van Geijn]

Hi Christoph,

Thanks for pointing this out.
Yes, this is intended as pre-approval request for the transition into 
sid. I got this https://wiki.debian.org/Teams/ReleaseTeam/Transitions 
site, from which I understood that a bug-report on this was necessary 
for the sid upload, but perhaps I misunderstood.


I will discuss with Teus on uploads.

Regards
Maarten

On 22/09/2023 13:31, Christoph Berg wrote:

Re: Maarten van Geijn

Dear Release Team,


Hi Maarten,

you filed this on the libpqxx package, the release team won't see it
there.

Is this the pre-approval request for the transition?


Package libpqxx has a new update from upstream in experimental.

Checked sqlsmith and osm2pgrouting source packages, which seem to be unaffected.

Ben information:
 Affected: .depends ~ /\b(libpqxx\-7\.8|libpqxx\-6\.4)\b/
 Good: .depends ~ /\b(libpqxx\-7\.8)\b/
 Bad: .depends ~ /\b(libpqxx\-6\.4)\b/


The automatic tracker got that right already:

https://release.debian.org/transitions/html/auto-libpqxx.html


Request scheduled binNMU for libpqxx into sid.


You need to actually upload libpqxx to sid, it won't transition like
sid->testing works.

BinNMUs can then take care of the two rdeps.

Christoph



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1052445: Transition: libpqxx 6.4->7.8

[Maarten van Geijn]

Source: libpqxx
Version: 6.4.5-2
Severity: normal
X-Debbugs-Cc: teusjanne...@gmail.com, team+postgre...@tracker.debian.org

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

- -BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Dear Release Team,

Package libpqxx has a new update from upstream in experimental.

Checked sqlsmith and osm2pgrouting source packages, which seem to be unaffected.

Ben information:
Affected: .depends ~ /\b(libpqxx\-7\.8|libpqxx\-6\.4)\b/
Good: .depends ~ /\b(libpqxx\-7\.8)\b/
Bad: .depends ~ /\b(libpqxx\-6\.4)\b/

Request scheduled binNMU for libpqxx into sid.

Thank you.


- - -- System Information:
Debian Release: 12.1
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 6.1.0-12-amd64 (SMP w/24 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE
Locale: LANG=en_NL.UTF-8, LC_CTYPE=en_NL.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_US.UTF-8), LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled



- -BEGIN PGP SIGNATURE-

iQGzBAEBCgAdFiEEQHgC5j/bt9iVaqKB+i7cMmA+GmYFAmUNN1IACgkQ+i7cMmA+
GmYBJgwAiUrJV4IldAURd/sswIBfet9hORhPbOtaPOBmwgejnf5JZxWgoprxEZNB
0wxh5ZhTewGgmVONjVacUK4PnxfmK3hF6RIUtm8OPXkPJyryzDn7T0eRG/YWeuLa
TYs6vV7YW7Ampq3Ga/JeAYJS0IJRIJEbIXfPDLFC0hKGud0GuwKNcW+mKgUmQO21
pzucie5Q5k3XmeVTg2/IFHCRqWR2GavSadapNzWGmve5zIiUdq13vJqBV79pio1Q
wONPCWy+m0vLXsFjsUL4YlAZiJoxbm+LcfgwEyVxbnycfxtwkYXj72ZaBliZCJHi
U3rLuwCPlDK1ai7C/u+qbVeEoPod11fcDvTZdgFS4qnX5KrFqoHuIEo6D65w4zZL
s18zxLMVhuBbB33qbVYLrRW3Pd2v/vg7k9rw6KdncPSz6sXSLQ7vEUCw3XKaJq2i
k3/SwwKftXVSswD9n100F1/nRP1DtboQZaOSnELOTeL2NdNCOaxA28iDt9yHW1kI
Rm6swfJo
=fqEi
- -END PGP SIGNATURE-

-BEGIN PGP SIGNATURE-

iQGzBAEBCgAdFiEEQHgC5j/bt9iVaqKB+i7cMmA+GmYFAmUNN6EACgkQ+i7cMmA+
GmZqyQwAnDXiOfZc872ozCa7ZaCHpIiBhrjUlwVTyy1Av0Uh3rXZ27doKQq97p4L
iQcXLKDGS0lbFIte4aAsiwwve9Gy8FR7E7VivbBiHPOVVRHFufaZlci/Gzlidmpj
kiz8QufZKqvAipM64aNF3Bdhc2FB44n2e7HmkkLPEhz2slhUm1Fzg8UhDNgTaW06
EHq9O48tcQV0l5wRg530op700V4vhWuRvRVZQucct3b/tOB1ANyp4kKkPiisMmLh
k4KtNhjF/JUCghkVAAELsVRi5kMGvVr7oiy+Y7C77ym+jQ9dyqq8ASugQnO+HYEd
7fVNMWygRIWfkBLmTFCYpR0qT2ix9M5B2w97uD8zkKZtpsm/HlXDZCsSq7Ejf/HO
S6LbQZa+IOY+lV0SgQCYQetxxJ4QK7h+77Gg7g1TLNpQeYsVYEd4qFYj6P2XxLJc
rLybO3RG8737j7P8pBel7ZNi638RbS7nD4ioo4rlbIBnBqVYcz3XtZy+i9Uli5e5
aOVqQ0xg
=DTBd
-END PGP SIGNATURE-

Bug#975000: Will be fixed with upcoming package update

[Maarten van Geijn]

Hi Roman,

I realise your bug report has been out here for almost three years.
We are planning a package update in sid which will include this fix.

Thanks for your contribution to tot project.

Regards,
Maarten van Geijn


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1050949: Acknowledgement (routine-update had my rules for lunch)

[Maarten L. Hekkelman]

I'm sorry, I messed up. This report should not have been sent. I used a 
wrong version of routine-update.


-maarten

Op 31-08-2023 om 19:33 schreef Debian Bug Tracking System:

Thank you for filing a new Bug report with Debian.

You can follow progress on this Bug here: 1050949: 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1050949.

This is an automatically generated reply to let you know your message
has been received.

Your message is being forwarded to the package maintainers and other
interested parties for their attention; they will reply in due course.

Your message has been sent to the package maintainer(s):
  Debian Med Packaging Team 

If you wish to submit further information on this problem, please
send it to 1050...@bugs.debian.org.

Please do not send mail to ow...@bugs.debian.org unless you wish
to report a problem with the Bug-tracking system.



--
Maarten L. Hekkelman
http://www.hekkelman.com/

Bug#1050949: routine-update had my rules for lunch

[Maarten L. Hekkelman]

Package: routine-update
Severity: important

Dear Maintainer,

For my debian package I used the wiki page on SphinxDocumentation as inspiration
and added the following lines to my rules file:


override_dh_auto_build: export http_proxy=127.0.0.1:9
override_dh_auto_build: export https_proxy=127.0.0.1:9
override_dh_auto_build:
dh_auto_build

The reason to do this is that I wanted to have the http_proxy set while still
running the regular build (using cmake). My cmake setup builds the documentation
and this avoids sphinx to try to fetch resources from the internet.

However, running routine-update on this package removed the last two lines and
the effect was that nothing was built anymore.

Of course, the rules file is suboptimal, but simply removing the last two lines
makes it worse.

regards, -maarten

-- System Information:
Debian Release: 11.7
  APT prefers oldstable-updates
  APT policy: (500, 'oldstable-updates'), (500, 'oldstable-security'), (500, 
'oldstable-proposed-updates'), (500, 'oldstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.10.0-21-amd64 (SMP w/2 CPU threads)
Locale: LANG=nl_NL.UTF-8, LC_CTYPE=nl_NL.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#1003724: I would like to help implement this item

[Maarten van Geijn]

Hi all,

Looks like this request is out there for a while. I am a user of this 
package as well and I have been looking into how to upgrade this 
upstream version and I would like to help with this.


I found the most recent version is 7.8.1, I would suggest to upgrade to 
this version instead, unless there is any objection against it.


I just need a little guidance on how to get seasoned for debian package 
maintenance (am responsible for package maintenance for production 
systems, but not within the debian context).


I have the new version building locally, but someone experienced will 
need to review this and all being well approve.


Regards

Maarten

Bug#1003724: I would like to help implement this item

[Maarten van Geijn]

Hi all,

Looks like this request is out there for a while. I am a user of this 
package as well and I have been looking into how to upgrade this 
upstream version and I would like to help with this.


I found the most recent version is 7.8.1, I would suggest to upgrade to 
this version instead, unless there is any objection against it.


I just need a little guidance on how to get seasoned for debian package 
maintenance (am responsible for package maintenance for production 
systems, but not within the debian context).


I have the new version building locally, but someone experienced will 
need to review this and all being well approve.


Regards

Maarten

Bug#1025778: libnewuoa breaks libpdb-redo autopkgtest: pdb-redo-example (Failed)

[Maarten L. Hekkelman]

Dear Paul,

The issue with libnewuoa and libpdb-redo is solved in the new version of 
libpdb-redo that is waiting in experimental.


And libpdb-redo is coupled to libcifpp which is also waiting in 
experimental, hoping it will get a slot to move into testing.


Perhaps the bug in libnewuoa should be reassigned to libpdb-redo?

regards,

-maarten

Op 08-12-2022 om 22:02 schreef Paul Gevers:

Source: libnewuoa, libpdb-redo
Control: found -1 libnewuoa/0.1.2-1
Control: found -1 libpdb-redo/2.0.3-1
Severity: serious
Tags: sid bookworm
User: debian...@lists.debian.org
Usertags: breaks needs-update

Dear maintainer(s),

With a recent upload of libnewuoa the autopkgtest of libpdb-redo fails 
in testing when that autopkgtest is run with the binary packages of 
libnewuoa from unstable. It passes when run with only packages from 
testing. In tabular form:


   pass    fail
libnewuoa  from testing    0.1.2-1
libpdb-redo    from testing    2.0.3-1
all others from testing    from testing

I copied some of the output at the bottom of this report.

Currently this regression is blocking the migration of libnewuoa to 
testing [1]. Due to the nature of this issue, I filed this bug report 
against both packages. Can you please investigate the situation and 
reassign the bug to the right package?


More information about this bug and the reason for filing it can be 
found on

https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Paul

[1] https://qa.debian.org/excuses.php?package=libnewuoa

https://ci.debian.net/data/autopkgtest/testing/amd64/libp/libpdb-redo/29137519/log.gz 



-- The CXX compiler identification is GNU 12.2.0
-- The C compiler identification is GNU 12.2.0
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/c++ - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: /usr/bin/cc - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Looking for ccp4/ccp4_general.h - /usr/include
-- Found CCP4: /usr/lib/x86_64-linux-gnu/libccp4c.so  -- Performing 
Test CMAKE_HAVE_LIBC_PTHREAD

-- Performing Test CMAKE_HAVE_LIBC_PTHREAD - Success
-- Found Threads: TRUE  -- Looking for clipper/clipper.h - /usr/include
-- Found CCP4: /usr/lib/x86_64-linux-gnu/libclipper-core.so  -- FFTW2 
libraries - /usr/lib/libsfftw.so

-- - /usr/lib/libsrfftw.so
-- FFTW2 header directory - /usr/include
-- Performing Test _LINKING_WITH_CLIPPER_CORE
-- Performing Test _LINKING_WITH_CLIPPER_CORE - Success
-- Looking for clipper/clipper-ccp4.h - /usr/include
-- Found CCP4: /usr/lib/x86_64-linux-gnu/libclipper-ccp4.so  -- 
Looking for clipper/clipper-contrib.h - /usr/include
-- Found CCP4: /usr/lib/x86_64-linux-gnu/libclipper-contrib.so  -- 
CCP4 include directory: /usr/include
-- Found Boost: 
/usr/lib/x86_64-linux-gnu/cmake/Boost-1.74.0/BoostConfig.cmake (found 
suitable version "1.74.0", minimum required is "1.70.0") found 
components: system iostreams regex -- Found Boost: 
/usr/lib/x86_64-linux-gnu/cmake/Boost-1.74.0/BoostConfig.cmake (found 
suitable version "1.74.0", minimum required is "1.70.0") found 
components: system date_time regex -- Looking for ccp4/ccp4_general.h 
- /usr/include
-- Found CCP4: /usr/lib/x86_64-linux-gnu/libccp4c.so  -- Looking for 
clipper/clipper.h - /usr/include
-- Found CCP4: /usr/lib/x86_64-linux-gnu/libclipper-core.so  -- FFTW2 
libraries - /usr/lib/libsfftw.so

-- - /usr/lib/libsrfftw.so
-- FFTW2 header directory - /usr/include
-- Looking for clipper/clipper-ccp4.h - /usr/include
-- Found CCP4: /usr/lib/x86_64-linux-gnu/libclipper-ccp4.so  -- 
Looking for clipper/clipper-contrib.h - /usr/include
-- Found CCP4: /usr/lib/x86_64-linux-gnu/libclipper-contrib.so  -- 
CCP4 include directory: /usr/include

-- Configuring done
-- Generating done
-- Build files have been written to: 
/tmp/autopkgtest-lxc.qdh1lkps/downtmp/autopkgtest_tmp/build

[ 50%] Building CXX object CMakeFiles/pdb-redo-example.dir/example.cpp.o
[100%] Linking CXX executable pdb-redo-example
/usr/bin/ld: warning: libnewuoa.so.0, needed by 
/usr/lib/x86_64-linux-gnu/libpdb-redo.so.2.0.3, not found (try using 
-rpath or -rpath-link)

[100%] Built target pdb-redo-example
Test project /tmp/autopkgtest-lxc.qdh1lkps/downtmp/autopkgtest_tmp/build
    Start 1: pdb-redo-example
1/1 Test #1: pdb-redo-example .***Failed    0.00 sec

0% tests passed, 1 tests failed out of 1

Total Test time (real) =   0.00 sec

The following tests FAILED:
  1 - pdb-redo-example (Failed)
Errors while running CTest
Output from these tests are in: 
/tmp/autopkgtest-lxc.qdh1lkps/downtmp/autopkgtest_tmp/build/Testing/Temporary/LastTest.log
Use "--rerun-failed --output-on-f

Bug#1024893: libcifpp: Requesting transition slot

[Maarten L. Hekkelman]

Source: libcifpp
Severity: normal

Dear Maintainer,

libcifpp and libpdb-redo are both in experimental. I've prepared the 
packages depending on them and am now requesting a time slot to take
the following transition steps.

regards,

-maarten hekkelman

Bug#1024622: ITP: libmcfp -- A header-only C++ argv and configuration parsing library

[Maarten L. Hekkelman]

Package: wnpp
Severity: wishlist
Owner: "Maarten L. Hekkelman" 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: libmcfp
  Version : 1.2.2
  Upstream Author : Maarten L. Hekkelman 
* URL : http://github.com/mhekkel/libmcfp
* License : BSD-2-Clause
  Programming Lang: C++
  Description : A header-only C++ argv and configuration parsing library

There are already a few configuration parser around, but most of them
introduce runtime dependencies. This header-only library avoids that
and add a simple to use and complete C++ API for accessing configuration
passed through command line arguments or configuration files. The argv
parsing is following the POSIX standard.

All of the programs I've submitted to Debian before have switched
from using boost::program_options to libcfp. Adding this library to
Debian would ease packaging updates to these tools a lot. (Alternative
is to include a copy of this lib to each and every tools separately).

This library is intended to be maintained by the med-team.

This ITP replaces the one from bug nr #1024144 which had a name
conflict on other platforms.

Bug#1024144: ITP: libcfp -- A header-only C++ argv and configuration parsing library

[Maarten L. Hekkelman]

Package: wnpp
Severity: wishlist
Owner: "Maarten L. Hekkelman" 
X-Debbugs-Cc: debian-de...@lists.debian.org, maar...@hekkelman.com

* Package name: libcfp
  Version : 1.2.0
  Upstream Author : Maarten L. Hekkelman 
* URL : https://github.com/mhekkel/libcfp.git
* License : BSD-2-Clause
  Programming Lang: C++
  Description : A header-only C++ argv and configuration parsing library

There are already a few configuration parser around, but most of them
introduce runtime dependencies. This header-only library avoids that
and add a simple to use and complete C++ API for accessing configuration
passed through command line arguments or configuration files. The argv
parsing is following the POSIX standard.

All of the programs I've submitted to Debian before have switched
from using boost::program_options to libcfp. Adding this library to
Debian would ease packaging updates to these tools a lot. (Alternative
is to include a copy of this lib to each and every tools separately).

Bug#958155: marked as done (please package the new version of Guake 3.7.0 and fix the debian/watchfile)

[Maarten]

Would it be possible to update the package to the bugfix release 3.8.1
please?

Thank you

kind regards,

Maarten Fonville


Op di 26 okt. 2021 om 06:21 schreef Debian Bug Tracking System <
ow...@bugs.debian.org>:

> Your message dated Tue, 26 Oct 2021 04:18:31 +
> with message-id 
> and subject line Bug#958155: fixed in guake 3.8.0-1
> has caused the Debian Bug report #958155,
> regarding please package the new version of Guake 3.7.0 and fix the
> debian/watchfile
> to be marked as done.
>
> This means that you claim that the problem has been dealt with.
> If this is not the case it is now your responsibility to reopen the
> Bug report if necessary, and/or fix the problem forthwith.
>
> (NB: If you are a system administrator and have no idea what this
> message is talking about, this may indicate a serious mail system
> misconfiguration somewhere. Please contact ow...@bugs.debian.org
> immediately.)
>
>
> --
> 958155: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=958155
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems
>
>
>
> -- Forwarded message --
> From: "shirish शिरीष" 
> To: debian-bts 
> Cc:
> Bcc:
> Date: Sun, 19 Apr 2020 05:49:53 +
> Subject: please package the new version of Guake 3.7.0 and fix the
> debian/watchfile
> Package: guake
> Version: 3.6.3-2
> Severity: wishlist
>
> Dear Maintainer,
>
> Upstream has released guake 3.7.0. See
> https://github.com/Guake/guake/releases/tag/3.7.0
>
> While it has few fixes and things, dunno if its requirements for VTE
> and GTK has also changed or not, probably for the better. I wasn't
> able to find anything on upstream as readthedocs on guake is stale
>
>
> https://guake.readthedocs.io/en/latest/user/installing.html#install-from-source
>
> Currently what we use is -
>
> Guake not running, starting it
> Guake Terminal 3.6.3
> VTE 0.60.1
> Gtk 3.24.18
>
> This is from my .xsession-errors file, hence I know it's correct.
>
> -- System Information:
> Debian Release: bullseye/sid
>   APT prefers testing
>   APT policy: (900, 'testing'), (500, 'testing-debug'), (100,
> 'unstable-debug'), (100, 'experimental'), (100, 'unstable'), (50,
> 'experimental-debug')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 5.5.0-1-amd64 (SMP w/4 CPU cores)
> Locale: LANG=en_IN, LC_CTYPE=en_IN (charmap=UTF-8), LANGUAGE=en_IN:en
> (charmap=UTF-8)
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
>
> Versions of packages guake depends on:
> ii  dconf-gsettings-backend [gsettings-backend]  0.36.0-1
> ii  gir1.2-glib-2.0  1.64.1-1
> ii  gir1.2-gtk-3.0   3.24.18-1
> ii  gir1.2-keybinder-3.0 0.3.2-1+b1
> ii  gir1.2-notify-0.70.7.9-1
> ii  gir1.2-pango-1.0 1.44.7-3
> ii  gir1.2-vte-2.91  0.60.1-1
> ii  gir1.2-wnck-3.0  3.36.0-1
> ii  libglib2.0-bin   2.64.1-1
> ii  libutempter0 1.1.6-5
> ii  python3  3.8.2-3
> ii  python3-cairo1.16.2-2+b1
> ii  python3-dbus 1.2.16-1
> ii  python3-gi   3.36.0-1+b1
> ii  python3-pbr  5.4.3-2
>
> guake recommends no packages.
>
> Versions of packages guake suggests:
> pn  numix-gtk-theme  
>
> -- no debconf information
>
> --
>   Regards,
>   Shirish Agarwal  शिरीष अग्रवाल
>   My quotes in this email licensed under CC 3.0
> http://creativecommons.org/licenses/by-nc/3.0/
> http://flossexperiences.wordpress.com
>
> E493 D466 6D67 59F5 1FD0 930F 870E 9A5B 5869 609C
>
>
>
> -- Forwarded message --
> From: Debian FTP Masters 
> To: 958155-cl...@bugs.debian.org
> Cc:
> Bcc:
> Date: Tue, 26 Oct 2021 04:18:31 +
> Subject: Bug#958155: fixed in guake 3.8.0-1
> Source: guake
> Source-Version: 3.8.0-1
> Done: Daniel Echeverri 
>
> We believe that the bug you reported is fixed in the latest version of
> guake, which is due to be installed in the Debian FTP archive.
>
> A summary of the changes between this version and the previous one is
> attached.
>
> Thank you for reporting the bug, which will now be closed.  If you
> have further comments please address them to 958...@bugs.debian.org,
> and the maintainer will reopen the bug report if appropriate.
>
> Debian distribution maintenance software
> pp.
> Dan

Bug#958155: Guake 3.8.0

[Maarten]

Any chance that we will get an updated version of Guake uploaded to the
archive?
3.8.0 series is now around the corner, rc3 was released last week, and it
would be great to have the latest bugfixes/features/compatibility from the
latest version in the archive.

kind regards,

Maarten Fonville

Bug#989051: [Debian-med-packaging] Bug#989051: mrc: FTBFS on hppa - obj/mrc_rsrc.o created with wrong OS/ABI

[Maarten L. Hekkelman]

Hi Étienne,

Thank you very much for your reply. Luckily I found out the same route 
(using qemu) myself and fixed the problem All architectures are now 
green in tracker: https://buildd.debian.org/status/package.php?p=mrc


regards, -maarten


Op 12-09-2021 om 15:59 schreef Étienne Mollier:

Hi Maarten,

Maarten L. Hekkelman, on 2021-09-02:

I found the underlying problem, apparently the ABI field of the ELF header
should contain a flag indicating it is a Linux executable. In order to set
this flag properly, I need to find out various things and perhaps it is
easiest to try to figure out these myself. Is it possible to get access to a
HPPA machine running Debian? I am a Debian maintainer, if that makes any
difference.

Without easy access to a PA-RISC machine, you can resort to
Qemu.  The Debian hppa port can be emulated using one of the
emulators provided in the package qemu-system-misc.  If you
combine it with the package qemu-user-static (and also have
Debian ports keyring at hand), then you can directly debootstrap
a chroot able to run PA-RISC binaries:

$ uname -m
x86_64

$ sudo debootstrap \
--arch=hppa \
--keyring=/usr/share/keyrings/debian-ports-archive-keyring.gpg \
--include=debian-ports-archive-keyring \
sid sid-hppa-chroot http://ftp.ports.debian.org/debian-ports
I: Target architecture can be executed
[...]
I: Base system installed successfully.

$ sudo chroot sid-hppa-chroot uname -m
parisc


Otherwise, could you provide me the output of `cpp -dM /dev/null` and
perhaps also how to detect PA-RISC/Debian in a cmake file. That last
question is perhaps a bit too much to ask for, but any hint is appreciated.

Feel free to checkout cpp_hppa.h in attachment; I obtained it
with the aforementioned method.

In hope this helps,
Have a nice day,  :)


--
Maarten L. Hekkelman
http://www.hekkelman.com/

Bug#993123: frog FTCBFS: hard codes the build architecture pkg-config

[Maarten van Gompel]

Hi Helmut,

On 21-08-27 04:23, Helmut Grohne wrote:
> Source: frog
> Version: 0.20-2
> Tags: patch upstream
> User: debian-cr...@lists.debian.org
> Usertags: ftcbfs
>
> frog fails to cross build from source, because configure.ac hard codes
> the build architecture pkg-config in one place (after correctly
> detecting the host architecture one). Simply using the correct
> substitution variable makes frog cross buildable. Please consider
> applying the attached patch.
>
> Helmut

Thanks for the patch! I have applied it upstream and will try to soon prepare a
new debian release for Frog that includes it.

Regards,

--

Maarten van Gompel
Digital Infrastructure
Humanities Cluster
Koninklijke Nederlandse Akademie van Wetenschappen (KNAW)

proy...@anaproy.nl
https://proycon.anaproy.nl
https://github.com/proycon

GnuPG key:  0x39FE11201A31555C
XMPP:   proy...@anaproy.nl   Matrix: @proycon:matrix.anaproy.nl
Telegram:   proycon  IRC: proycon (libera.chat + oftc)
Mastodon:   https://social.anaproy.nl/@proycon   (@proy...@social.anaproy.nl)
Twitter:https://twitter.com/proycon
ORCID:  https://orcid.org/-0002-1046-0006

Bug#989051: mrc: FTBFS on hppa - obj/mrc_rsrc.o created with wrong OS/ABI

[Maarten L. Hekkelman]

Dear Dave,

Thanks for reporting, and apologies for not responding earlier.

I found the underlying problem, apparently the ABI field of the ELF 
header should contain a flag indicating it is a Linux executable. In 
order to set this flag properly, I need to find out various things and 
perhaps it is easiest to try to figure out these myself. Is it possible 
to get access to a HPPA machine running Debian? I am a Debian 
maintainer, if that makes any difference.


Otherwise, could you provide me the output of `cpp -dM /dev/null` and 
perhaps also how to detect PA-RISC/Debian in a cmake file. That last 
question is perhaps a bit too much to ask for, but any hint is appreciated.


regards, -maarten


Op 24-05-2021 om 20:09 schreef John David Anglin:

Source: mrc
Version: 1.2.3-2
Severity: normal

Dear Maintainer,

The build fails with the following error:

make[1]: Entering directory '/<>'

mrc.cpp
dummy.cpp

g++ -std=c++17 -o mrc-bootstrap obj/mrc.o obj/dummy.o -L/usr/lib/hppa-linux-gnu 
-lboost_program_options
./mrc-bootstrap -o obj/mrc_rsrc.o mrsrc.h
g++ -std=c++17 -o mrc obj/mrc.o obj/mrc_rsrc.o -L/usr/lib/hppa-linux-gnu 
-lboost_program_options
/usr/bin/ld: unknown architecture of input file `obj/mrc_rsrc.o' is 
incompatible with hppa1.1 output
collect2: error: ld returned 1 exit status
make[1]: *** [GNUmakefile:87: mrc] Error 1

As far as I can tell, this occurs because obj/mrc_rsrc.o is created with the
wrong OS/ABI:

dave@mx3210:~/debian/mrc/mrc-1.2.3$ file obj/mrc_rsrc.o
obj/mrc_rsrc.o: ELF 32-bit MSB relocatable, PA-RISC, 1.1 version 1 (SYSV), not 
stripped

SYSV should be GNU/Linux:

dave@mx3210:~/debian/mrc/mrc-1.2.3$ file obj/mrc.o
obj/mrc.o: ELF 32-bit MSB relocatable, PA-RISC, 1.1 version 1 (GNU/Linux), with 
debug_info, not stripped

Not sure why this happens.

Regards,
Dave Anglin

-- System Information:
Debian Release: 11.0
   APT prefers buildd-unstable
   APT policy: (500, 'buildd-unstable'), (500, 'unstable')
Architecture: hppa (parisc64)

Kernel: Linux 5.10.39+ (SMP w/4 CPU threads)
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)




--
Maarten L. Hekkelman
http://www.hekkelman.com/

Bug#987436: libcifpp: [INTL:pt_BR] Brazilian Portuguese debconf templates translation

[Maarten L. Hekkelman]

Hi Adriano,

Thanks very much

-maarten

Op 23-04-2021 om 21:41 schreef Adriano Rafael Gomes:

Package: libcifpp
Tags: l10n patch
Severity: wishlist

Hello,

Please, Could you update the Brazilian Portuguese Translation?

Attached you will find the file pt_BR.po. It is UTF-8 encoded and it is
tested with msgfmt and podebconf-display-po.

Kind regards.


--
Maarten L. Hekkelman
http://www.hekkelman.com/

Bug#986430: openvpn client does not resolve name correctly when nr of DNS A records exceeds a certain nr. Example 'remote swe.torguard.com 1912' response: Cannot resolve host address: swe.torguard.com

[Maarten Hondelink]

Package: openvpn
Version: 2.4.7-1
Severity: important
Tags: a11y

Dear Maintainer,

*** Reporter, please consider answering these questions, where 
appropriate ***


   * What led up to the situation?

   * What exactly did you do (or not do) that was effective (or
 ineffective)

   * What was the outcome of this action?
   * What outcome did you expect instead?

*** End of the template - remove these template lines ***


-- System Information:
Debian Release: 10.9
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.19.0-16-amd64 (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en (charmap=UTF-8)

Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages openvpn depends on:
ii  debconf [debconf-2.0]  1.5.71
ii  iproute2   4.20.0-2+deb10u1
ii  libc6  2.28-10
ii  liblz4-1   1.8.3-1
ii  liblzo2-2  2.10-0.1
ii  libpam0g   1.3.1-5
ii  libpkcs11-helper1  1.25.1-1
ii  libssl1.1  1.1.1d-0+deb10u6
ii  libsystemd0    241-7~deb10u7
ii  lsb-base   10.2019051400

Versions of packages openvpn recommends:
ii  easy-rsa  3.0.6-1

Versions of packages openvpn suggests:
ii  openssl   1.1.1d-0+deb10u6
pn  openvpn-systemd-resolved  
pn  resolvconf    

-- debconf information excluded

Bug#964848: Upstream reference

[Maarten Derickx]

This is the location of the corresponding upstream bugreport:
https://trac.sagemath.org/ticket/31340

Bug#981580: Replace isAlive by is_alive in /usr/share/hplip/scan/sane.py

[Maarten De Munck]

Hi Daniel

Same problem here. The problem appeared when Python was upgraded to 
version 3.9.


Apparently the (deprecated) threading.Thread.isAlive() function is 
removed in Python 3.9 and one should use the threading.Thread.is_alive() 
function.


Just replacing all occurences of 'isAlive' in 
/usr/share/hplip/scan/sane.py by 'is_alive' solved the problem for me 
(up-to-date Debian Testing).


Best regards

Maarten

Bug#979626: transmissionrpc: The packaged transmissionrpc is outdated and unmaintained upstream

[Maarten Fonville]

Source: transmissionrpc
Severity: normal

Dear Maintainer,

The packaged transmissionrpc is outdated for new versions of Transmission.
Also the source package is not maintained anymore and even unvailable upstream.
I'd propose to (re)package the maintained fork named 'transmission-rpc' (with a 
dash) that can be found at https://github.com/Trim21/transmission-rpc

kind regards,

Maarten

Bug#979314: libccp4: The endianness check in ccp4_sysdep.h is incorrect assuming powerpc is always big endian

[Maarten L. Hekkelman]

Source: libccp4
Version: 6.5.1-4
Severity: grave
Tags: patch upstream
Justification: renders package unusable
X-Debbugs-Cc: maar...@hekkelman.com




-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: ppc64el (ppc64le)

Kernel: Linux 5.4.0-58-generic (SMP w/12 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: unable to detect


The file ccp4_sysdep.h checks for the endianness in an incorrect way,
the check assumes powerpc is always big endian. By moving the catch-all
test up the test is more robust.

regards, -maarten
--- a/ccp4/ccp4_sysdep.h
+++ b/ccp4/ccp4_sysdep.h
@@ -177,6 +177,26 @@
 #define DFNTF_CONVEXNATIVE 5/**< Convex native floats */
 #define DFNTF_LEIEEE4   /**< little-endian IEEE format */

+/* From time to time new architectures are added here, often because Linux
+ * packagers want to build it on all platforms supported by their distro.
+ * Here we try to catch machines not listed explicitely above, under
+ * assumption that endianness is the same for floating point numbers
+ * as for integers. Which is safe assumption on modern standard computers
+ * (not embedded systems), according to
+ * http://en.wikipedia.org/wiki/Endianness#Floating-point_and_endianness
+ */
+#if defined(__BYTE_ORDER)
+# if __BYTE_ORDER == __LITTLE_ENDIAN
+#  define NATIVEIT DFNTI_IBO
+#  define NATIVEFT DFNTF_LEIEEE
+# elif __BYTE_ORDER == __BIG_ENDIAN
+#  define NATIVEIT DFNTI_MBO
+#  define NATIVEFT DFNTF_BEIEEE
+# endif
+#endif
+
+#if !defined(NATIVEIT) && !defined(NATIVEFT)
+
 #if defined (VAX) || defined (vax) /* gcc seems to use vax */
 #  define NATIVEFT DFNTF_VAX
 #  define NATIVEIT DFNTI_IBO
@@ -222,22 +242,6 @@
 # endif
 #endif

-/* From time to time new architectures are added here, often because Linux
- * packagers want to build it on all platforms supported by their distro.
- * Here we try to catch machines not listed explicitely above, under
- * assumption that endianness is the same for floating point numbers
- * as for integers. Which is safe assumption on modern standard computers
- * (not embedded systems), according to
- * http://en.wikipedia.org/wiki/Endianness#Floating-point_and_endianness
- */
-#if !defined(NATIVEIT) && !defined(NATIVEFT) && defined(__BYTE_ORDER)
-# if __BYTE_ORDER == __LITTLE_ENDIAN
-#  define NATIVEIT DFNTI_IBO
-#  define NATIVEFT DFNTF_LEIEEE
-# elif __BYTE_ORDER == __BIG_ENDIAN
-#  define NATIVEIT DFNTI_MBO
-#  define NATIVEFT DFNTF_BEIEEE
-# endif
 #endif

 #ifndef NATIVEFT

Bug#976849: ITP: density-fitness -- Calculates per-residue electron density scores real-space R, real-space correlation coefficient, EDIAm, and OPIA

[Maarten L. Hekkelman]

Package: wnpp
Severity: wishlist
Owner: "Maarten L. Hekkelman" 

* Package name: density-fitness
  Version : 1.0.0
  Upstream Author : Maarten L. Hekkelman 
* URL : https://github.com/PDB-REDO/density-fitness
* License : BSD-2-Clause
  Programming Lang: C++
  Description : Calculates per-residue electron density scores real-space 
R, real-space correlation coefficient, EDIAm, and OPIA

The program density-fitness calculates electron density metrics,
for main- (includes Cβ atom) and side-chain atoms of individual residues.

For this calculation, the program uses the structure model in either PDB
or mmCIF format and the electron density from the 2mFo-DFc and mFo-DFc maps.
If these maps are not readily available, the MTZ file and model can be used
to calculate maps clipper. Density-fitness support both X-ray and electron
diffraction data.

This program is essentially a reimplementation of _edstats_, a program
available from the CCP4 suite. However, the output now contains only the
RSR, SRSR and RSCC fields as in _edstats_ with the addition of EDIAm
and OPIA and no longer requires pre-calculated map coefficients.

The software uses libpdb-redo, libcifpp and libzeep.

Bug#976727: ITP: libpdb-redo -- Library containing shared code for the various programs in project PDB-REDO

[Maarten L. Hekkelman]

Package: wnpp
Severity: wishlist
Owner: "Maarten L. Hekkelman" 

* Package name: libpdb-redo
  Version : 1.0.0
  Upstream Author : Maarten L. Hekkelman 
* URL : https://github.com/PDB-REDO/libpdb-redo
* License : BSD-2-Clause
  Programming Lang: C++
  Description : Library containing shared code for the various programs in 
project PDB-REDO

For the PDB-REDO project, a lot of programs have been created over time. Many 
of these application share common routines and these are combined in this 
particular library. The PDB-REDO tools that are of general interest will follow 
as separate Debian packages.

About PDB-REDO:

PDB-REDO is a procedure to optimise crystallographic structure models, 
providing algorithms that make a fully automated decision making system for 
refinement, rebuilding and validation. It combines popular crystallographic 
software from CCP4, e.g. REFMAC and COOT, with with our specially developed 
rebuilding tools Centrifuge, Pepflip & SideAide and structure analysis tools 
like WHAT IF and PDB-care. PDB-REDO optimises refinement settings (e.g. 
geometric and B-factor restraint weights, B-factor model, TLS groups, NCS and 
homology restraints), refines with REFMAC, partially rebuilds the structure 
(rejects waters, refines side chains, checks peptide planes), refines some 
more, and then validates the results.

With PDB-REDO you can obtain updated and optimised versions of existing entries 
of the PDB from our DataBank, or you can optimise your own structure model 
using our Server. If you want to know more or install PDB-REDO on your own 
computers, please check below.

Bug#976627: libcifpp: [INTL:de] initial German debconf translation

[Maarten L. Hekkelman]

Thank Helge, I've placed the file where it is supposed to be, will be 
included at the next check-in.


regards, -maarten

Op 06-12-2020 om 05:49 schreef Helge Kreutzmann:

Package: libcifpp
Version: 1.0.0-3
Severity: wishlist
Tags: patch l10n

Please find the initial German debconf translation for libcifpp
attached.

Please place this file in debian/po/ as de.po for your next upload.

If you update your template, please use
'msgfmt --statistics '
to check the po-files for fuzzy or untranslated strings.

If there are such strings, please contact me so I can update the
German translation.

Greetings
 Helge

Bug#976272: ITP: libnewuoa-cpp -- C++ implementation of the NEWUOA algorithm

[Maarten L. Hekkelman]

Package: wnpp
Severity: wishlist
Owner: "Maarten L. Hekkelman" 

* Package name: libnewuoa-cpp
  Version : 0.1.0
  Upstream Author : Roman Siromakha
* URL : https://github.com/elsid/newuoa-cpp
* License : MIT
  Programming Lang: C++
  Description : C++ implementation of the NEWUOA algorithm

This library contains the C++ implementation of the NEWUOA derivative free
optmization algorithm originally published by Michael J. D. Powell.

Bug#975691: ITP: tortoize -- Application to calculate ramachandran z-scores.

[Maarten L. Hekkelman]

Package: wnpp
Severity: wishlist
Owner: "Maarten L. Hekkelman" 

* Package name: tortoize
  Version : 2.0.0
  Upstream Author : Maarten L. Hekkelman 
* URL : http://github.com/PDB-REDO/tortoize
* License : BSD-2-Clause
  Programming Lang: C++
  Description : Application to calculate ramachandran z-scores.

Tortoize validates protein structure models by checking the
Ramachandran plot and side-chain rotamer distributions. Quality
Z-scores are given at the residue level and at the model level
(ramachandran-z and torsions-z). Higher scores are better. To compare
models or to describe the reliability of the model Z-scores jackknife-
based standard deviations are also reported (ramachandran-jackknife-sd
and torsion-jackknife-sd).

This application depends on libcifpp and libzeep.

Bug#975526: ITP: cif-tools -- Suite of tools to manipulate, validate and query mmCIF files

[Maarten L. Hekkelman]

Package: wnpp
Severity: wishlist
Owner: "Maarten L. Hekkelman" 

* Package name: cif-tools
  Version : 1.0.0
  Upstream Author : Maarten L. Hekkelman 
* URL : http://github.com/PDB-REDO/cif-tools
* License : BSD-2-Clause
  Programming Lang: C++
  Description : Suite of tools to manipulate, validate and query mmCIF files

This package contains a suite of tools for the manipulation of mmCIF files.

The structure of macro molecules is nowadays recorded in mmCIF files. Until 
recently however the ancient PDB file format was used by many programs but that 
format has since long been deprecated.

This package provides two tools, pdb2cif and cif2pdb, that can convert files 
from one format into the other, provided that data fits of course.

Other tools are cif-validate, cif-grep, cif-diff, cif-merge and mmCQL. The 
latter can be used to manipulate an mmCIF file as if it were a SQL like 
database using SELECT, UPDATE, INSERT and DELETE commands.

This package depends on libcifpp.

Bug#975446: libzeep: FTBFS against boost_1.74

[Maarten L. Hekkelman]

Hi Anton,

Previous versions of libboost-tools-dev used to install a file called 
boost-build.jam in /usr/share/boost-build. Version 1.74 however no 
longer does this. Is this a permanent change? In the previous setup one 
could simply use bjam to build but with version 1.74 this no longer works.


So before I change my build scripts, I'd like to know if the omission of 
/usr/share/boost-build/boost-build.jam is an error or was intended to be 
dropped.


regards, -maarten


Op 22-11-2020 om 21:43 schreef Anton Gladky:

Hi Marteen,

there are really some misunderstandings with version numbers. Anyway,
I have just tried to build 5.0.2-3 and it still fails to build:



mkdir -p obj
cd doc; /usr/bin/bjam
/bin/bash /root/mod2/libzeep-5.0.2/libtool --silent --tag=CXX
--mode=compile g++ -std=c++17 -Wdate-time -D_FORTIFY_SOURCE=2 -g -O2
-fdebug-prefix-map=/root/mod2/libzeep-5.0.2=. -fstack-protector-strong
-Wformat -Werror=format-security -pthread -I/usr/include -Wall
-Wno-multichar -I include -O3 -DNDEBUG -MT obj/connection.lo -MD -MP
-MF obj/connection.d -c -o obj/connection.lo
lib-http/src/connection.cpp
/bin/bash /root/mod2/libzeep-5.0.2/libtool --silent --tag=CXX
--mode=compile g++ -std=c++17 -Wdate-time -D_FORTIFY_SOURCE=2 -g -O2
-fdebug-prefix-map=/root/mod2/libzeep-5.0.2=. -fstack-protector-strong
-Wformat -Werror=format-security -pthread -I/usr/include -Wall
-Wno-multichar -I include -O3 -DNDEBUG -MT obj/controller.lo -MD -MP
-MF obj/controller.d -c -o obj/controller.lo
lib-http/src/controller.cpp
/bin/bash /root/mod2/libzeep-5.0.2/libtool --silent --tag=CXX
--mode=compile g++ -std=c++17 -Wdate-time -D_FORTIFY_SOURCE=2 -g -O2
-fdebug-prefix-map=/root/mod2/libzeep-5.0.2=. -fstack-protector-strong
-Wformat -Werror=format-security -pthread -I/usr/include -Wall
-Wno-multichar -I include -O3 -DNDEBUG -MT obj/controller-rsrc.lo -MD
-MP -MF obj/controller-rsrc.d -c -o obj/controller-rsrc.lo
lib-http/src/controller-rsrc.cpp
Unable to load B2: could not find 'boost-build.jam'
---
Attempted search from '/root/mod2/libzeep-5.0.2/doc' up to the root at
'/usr/bin/b2'
Please consult the documentation at 'https://boostorg.github.io/build/'.


Could you please have a look?

Thanks

Anton

Am So., 22. Nov. 2020 um 21:22 Uhr schrieb Maarten L. Hekkelman
:


Hi,

The bug report is for libzeep version 5, but the logs show that an attempt was 
made to compile version 3. I'm quite sure that building libzeep version 5 with 
boost 1.74 will succeed, since I've been using it myself for several weeks now.

regards, -maarten

Op 22-11-2020 om 13:28 schreef Anton Gladky:

Package: libzeep
Version: 5.0.2-3
Severity: important
Tags: ftbfs
User: team+bo...@tracker.debian.org
Usertags: boost174

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Dear maintainer,

it was discovered that your package failed to build
against boost_1.74. Logs can be found here [1]. Most relevant
part is probably this:

dpkg-source: info: using options from libzeep-3.0.5/debian/source/options: 
--extend-diff-ignore=(^|/)(.vscode/.*|msvc|\.gitignore|\.travis\.yml|tests|zeep-test.*|webapp-test.cpp|doc/bin)$
  fakeroot debian/rules clean
dh clean
dh_auto_clean
make -j4 clean
make[1]: Entering directory '/<>'
rm -rf obj/* libzeep.a libzeep.so* zeep-test libzeep-3.0.5 libzeep-3.0.5.tgz
cd doc; bjam clean
Unable to load B2: could not find 'boost-build.jam'
- ---
Attempted search from '/<>/doc' up to the root at '/usr/bin/b2'
Please consult the documentation at 'https://boostorg.github.io/build/'.

make[1]: *** [makefile:122: clean] Error 1
make[1]: Leaving directory '/<>'
dh_auto_clean: error: make -j4 clean returned exit code 2
make: *** [debian/rules:8: clean] Error 25



It is planned to push boost_1.74 as the default version in Debian/Bullseye.

[1] 
http://qa-logs.debian.net/2020/10/27-boost/boost/libzeep_3.0.5-2_unstable_boost.log

Best regards

Anton

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

Kernel: Linux 5.9.0-1-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

-BEGIN PGP SIGNATURE-

iQJFBAEBCgAvFiEEu71F6oGKuG/2fnKF0+Fzg8+n/wYFAl+6WXURHGdsYWRrQGRl
Ymlhbi5vcmcACgkQ0+Fzg8+n/wYXFQ/6AobGTBmLGOayKBafvfY7JKMuOvQUt/CN
3x0Q1q9JKT3PrAiDupOILvGpU7kLVwXm+Xj7Y6jmOFmQXAIiejQINB5S3SMm3OW/
GJb2MkcbeAr/1gKnoRiXWGauFjBXT+RfHwKCB0qCRxaCcgd6wqN/sur9LiK1o9Jb
yAxYOhsAuqU3zrmGbJ6H9WGzRsOAFjhWRDu9vvq9+XWwhCZ1msETk8J+ube6dI3G
uYpkUgEUxf6dSLYAFki2vKtSX6TonmFwJ9Zn3uMer1OlTwOPGFfeKFP+Hvgd+Fx5
lwbGAh6RkoxM+9a+q+MSnIyhVoqMSYKWGbazen1SbJiQSR2tf8INYpryjd9wTYbK
aFlazYitywFTlq4I9cu+vDuHzLP6/rV480+v

Bug#975446: libzeep: FTBFS against boost_1.74

[Maarten L. Hekkelman]

Hi,

The bug report is for libzeep version 5, but the logs show that an 
attempt was made to compile version 3. I'm quite sure that building 
libzeep version 5 with boost 1.74 will succeed, since I've been using it 
myself for several weeks now.


regards, -maarten

Op 22-11-2020 om 13:28 schreef Anton Gladky:

Package: libzeep
Version: 5.0.2-3
Severity: important
Tags: ftbfs
User: team+bo...@tracker.debian.org
Usertags: boost174

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Dear maintainer,

it was discovered that your package failed to build
against boost_1.74. Logs can be found here [1]. Most relevant
part is probably this:

dpkg-source: info: using options from libzeep-3.0.5/debian/source/options: 
--extend-diff-ignore=(^|/)(.vscode/.*|msvc|\.gitignore|\.travis\.yml|tests|zeep-test.*|webapp-test.cpp|doc/bin)$
  fakeroot debian/rules clean
dh clean
dh_auto_clean
make -j4 clean
make[1]: Entering directory '/<>'
rm -rf obj/* libzeep.a libzeep.so* zeep-test libzeep-3.0.5 libzeep-3.0.5.tgz
cd doc; bjam clean
Unable to load B2: could not find 'boost-build.jam'
- ---
Attempted search from '/<>/doc' up to the root at '/usr/bin/b2'
Please consult the documentation at 'https://boostorg.github.io/build/'.

make[1]: *** [makefile:122: clean] Error 1
make[1]: Leaving directory '/<>'
dh_auto_clean: error: make -j4 clean returned exit code 2
make: *** [debian/rules:8: clean] Error 25



It is planned to push boost_1.74 as the default version in Debian/Bullseye.

[1] 
http://qa-logs.debian.net/2020/10/27-boost/boost/libzeep_3.0.5-2_unstable_boost.log

Best regards

Anton

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

Kernel: Linux 5.9.0-1-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

-BEGIN PGP SIGNATURE-

iQJFBAEBCgAvFiEEu71F6oGKuG/2fnKF0+Fzg8+n/wYFAl+6WXURHGdsYWRrQGRl
Ymlhbi5vcmcACgkQ0+Fzg8+n/wYXFQ/6AobGTBmLGOayKBafvfY7JKMuOvQUt/CN
3x0Q1q9JKT3PrAiDupOILvGpU7kLVwXm+Xj7Y6jmOFmQXAIiejQINB5S3SMm3OW/
GJb2MkcbeAr/1gKnoRiXWGauFjBXT+RfHwKCB0qCRxaCcgd6wqN/sur9LiK1o9Jb
yAxYOhsAuqU3zrmGbJ6H9WGzRsOAFjhWRDu9vvq9+XWwhCZ1msETk8J+ube6dI3G
uYpkUgEUxf6dSLYAFki2vKtSX6TonmFwJ9Zn3uMer1OlTwOPGFfeKFP+Hvgd+Fx5
lwbGAh6RkoxM+9a+q+MSnIyhVoqMSYKWGbazen1SbJiQSR2tf8INYpryjd9wTYbK
aFlazYitywFTlq4I9cu+vDuHzLP6/rV480+v6ZRKgNLO8ciNu3i/vB/a8G23cdAu
Bite4zw/29R5ekDUIvZcLLUSTVYfArKd1gMeRbVQFx9Y/AcFBC1/eZwqeiQFKmZv
c1PwFhB9bl54jDqS/mb7c85uhzt2LEbEeLrzo69TaUxjo1/1vQCvZa2FMn5uZgBF
aQwH4QSlL8Qh1zd3DW6DpQUzC4hg9TWFH/xIulFfuS46i2vD6UUDZYO/lBsw9Bod
a5Sgqn6aeKSZs2StgSOf8HFF067rSOYbC3oaDO9/7xBmNe8FHjYLV27mFr6+Sotu
OObqY7WdDP4=
=ljID
-END PGP SIGNATURE-----




--
Maarten L. Hekkelman
http://www.hekkelman.com/

Bug#974973: ITP: libcifpp -- A library for creating and manipulating mmCIF and PDB files containing macro molecular structure information

[Maarten L. Hekkelman]

Package: wnpp
Severity: wishlist
Owner: "Maarten L. Hekkelman" 

* Package name: libcifpp
  Version : 1.0.0
  Upstream Author : Maarten L. Hekkelman 
* URL : http://github.com/PDB-REDO/libcifpp
* License : BSD-2-Clause
  Programming Lang: C++
  Description : A library for creating and manipulating mmCIF and PDB files 
containing macro molecular structure information

The structure of macro molecules is nowadays recorded in mmCIF files. Until 
recently however the ancient PDB file format was used by many programs but that 
format has since long been deprecated.

This library contains code to read and write mmCIF files. It also contains 
validating code to check the integrity and validity of mmCIF files. As a bonus, 
this library is capable of importing and exporting PDB files which is not 
trivial.

The code greatly benefits from the CCP4 distribution being available, but does 
not require it to work.

The current DSSP in Debian needs to be replaced with a new version soon, this 
new version of DSSP will require libcifpp.

The Debian Med team will take care of maintenance.

Bug#974895: ftp.debian.org: MRS should be updated to support the new libzeep library

[Maarten L. Hekkelman]

Package: ftp.debian.org
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)

MRS is an information retrieval system, used to index terabytes of text based 
databanks on a single machine. Mostly used in the medical and biological world.

The version of MRS in currently in Debian is based on libzeep version 3. 
Libzeep was in fact a spin off project from MRS.

I stopped development of MRS in 2012 when I switched to a new employer but I 
took libzeep with me. Since then, libzeep has evolved and changed a lot and now 
compatibility with MRS is broken.

I've submitted the new version of libzeep into debian (it is currently in 
unstable) but now MRS no longer builds and so I request to remove it from 
Debian until it is updated.

regards, -maarten

Bug#974016: mrs: FTBFS with libzeep-dev 5.0.0-1: "Checking for libzeep...libzeep is not installed"

[Maarten L. Hekkelman]

Hi Juhani,

Bug #974074 is in fact a bug in MRS. However, the bug report does 
contain a useful observation, the usage of the various 
override_dh_auto_configure rules in libzeep is incorrect and no shared 
library is created.


Now the question is, is a shared library really required? If so I will 
have to go back to the drawing board and redesign the makefiles in the 
upstream project to create proper shared libraries, including a version 
numbering scheme.


regards, -maarten


Op 11-11-2020 om 09:13 schreef Juhani Numminen:

On Tue, 10 Nov 2020 23:03:57 +0100 Sebastian Ramacher  
wrote:

Hi Marten

On 2020-11-10 07:42:45 +0100, Maarten L. Hekkelman wrote:
...

Sorry, long story. To make it short.
- Keep mrc, no problem there
- Upgrade libzeep to version 5


Thanks for the detailed explanation. The first two steps are almost done
The current versions of mrc and libzeep should be able to migrate soon
as their RC bugs have been fixed.
...

Right, but one RC bug is not fixed yet: libzeep packages are missing the
shared library altogether; the .so files are not there.

For that we have bug #974074, and see gregor's message for suggested fix.
It seems he is confident in the first diff of that mail, while the latter diff
is more speculative.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=974074#19


Regards,
Juhani




--
Maarten L. Hekkelman
Cataloniëstraat 3
6663NJ Lent

http://www.hekkelman.com/
+31 24 348 0192

Bug#973526: FTBFS due to SIGABRT while running HTTP server tests, bug #973526

[Maarten L. Hekkelman]

Op 10-11-2020 om 16:21 schreef Andrey Rahmatullin:

Running 7 test cases...
started daemon at port 5923
terminate called after throwing an instance of 
'boost::wrapexcept'
   what():  resolve: Host not found (authoritative)

Looks like it tries to resolve something, and that usually implies
Internet access, as otherwise you could just connect to localhost?
Accessing the Internet is forbidden during building.
The test case tried to resolve "127.0.0.1" as host. I've changed that to 
"localhost" since adding a flag for boost to only interpret the value as 
numeric is not easy to add to the code. I've seen hosts where localhost 
is mapped to some other IP address in the range 127.0.0.0/255 Could this 
be the case on the particular build machine where the test failed?


Anyway, I assume that using localhost will be sufficient to fix this 
problem. We'll see that shorly.


regards, -maarten

Bug#974016: mrs: FTBFS with libzeep-dev 5.0.0-1: "Checking for libzeep...libzeep is not installed"

[Maarten L. Hekkelman]

Hi Andreas,

To avoid confusion, we're talking about three tools here: libzeep, mrc 
and mrs.


mrc is a simple resource compiler, is now compatible and bug free, 
builds on all architectures and should be kept. I believe it is very 
useful, using it I can create downloadable, portable applications that 
need additional static data without the need for installer scripts.


libzeep version 5 is the latest incarnation of a library I've been 
working on for 12 years now. It has evolved into a toolbox to build web 
applications in C++ inspired by the popular Java Spring framework and 
Thymeleaf template processor. It also contains a full XML and a JSON 
library. Using this library I could e.g. convert a pipeline to process 
genomics data into an interactive web application, the python scripts 
took up to 4 hours for each run, now you can do the same analysis in 
less than 5 seconds. I have a couple of applications based on libzeep 
that I would like to add to Debian, most of them tools used in 
crystallography and genomics research. But also a content management system.


And then we have MRS. This is a retrieval system, a web application 
capable of indexing and then searching terabytes of text based databanks 
on a single machine. Mostly used in the medical and biological world. It 
is used e.g. on mini computers that are sent into Africa where internet 
access is limited, that way large databanks like EMBL are still 
available. But I stopped development in 2012 when I switched jobs. I 
continued development of libzeep on which MRS is based but someone else 
took over development of MRS. A year ago I did a consultancy job fixing 
MRS which basically came down to reverting most of the attempted 
'improvements' after I left.


Currently I'm working at the Netherlands Cancer Institute, here I write 
both software used in crystallography as well as a genomics analysis 
tool. Many of the crystallographic tools are moving into open source 
right now. We would have liked to include those in the CCP4 
distribution, but unfortunately my code is way too new (C++17) to work 
in that environment. Next to that we would like to include our tools in 
Debian (DSSP already is, but that application needs an update), but if 
that won't work, I will set up a private repository to distribute our 
binaries.


I know libzeep is not very popular, that's because I never bothered much 
to find an audience. But I can't live without it myself, a lot of my 
tools are based on it one way or another. Libzeep is also quite mature 
and has been used in many tools in a production environment for many 
years now.


Sorry, long story. To make it short.
- Keep mrc, no problem there
- Upgrade libzeep to version 5
- Kick out mrs until it is upgraded to use libzeep 5

regards, -maarten

Op 09-11-2020 om 20:49 schreef Andreas Tille:

Hi Maarten,

On Mon, Nov 09, 2020 at 07:22:30PM +0100, Maarten L. Hekkelman wrote:

I'm sorry, but mrs as it is currently in Debian is not compatible with
libzeep version 5. It needs a major rewrite. Libzeep is a spin off project
of mrs and has evolved a lot since then.

So either libzeep should be kept at version 3 or mrs should be removed. If
mrs and libzeep are kept, I will not be able to release my other tools based
on libzeep in Debian.

You are the Uploader and the only competent person to decide.  If I
understood the issue correctly it came up right after mrc was added to
the Build-Depends.  Wouldn't it be an option to just de-couple both
again.
  

Upgrading mrs is of course the best option, but I won't have time to do that
soon.

So please draw a sensible decision.  Libzeep was according to popcon[1]
never installed by more than 10 users - currently the vote (active users)
is at zero.  Feel free to decided what *you* personally love to see in
Debian (but decreasing a version number is usually not nice).

Kind regards

  Andreas.

[1] https://qa.debian.org/popcon.php?package=libzeep
  

regards, -maarten

Op 09-11-2020 om 16:19 schreef Niko Tyni:

On Mon, Nov 09, 2020 at 09:17:25AM +0200, Juhani Numminen wrote:

Source: mrs
Version: 6.0.5+dfsg-8
Severity: serious
Tags: ftbfs sid
Justification: fails to build from source (but built successfully in the past)
| Checking for libzeep...libzeep is not installed, either install the package 
libzeep-dev
| or download libzeep from ftp://ftp.cmbi.ru.nl/pub/software/libzeep
| and run configure again.
| make[1]: *** [debian/rules:15: override_dh_auto_configure] Error 2

Looks to me like libzeep-dev is broken because the build
doesn't pass --enable-shared to ./configure.

Probably the override_dh_auto_configure-arch and
override_dh_auto_configure-indep targets in src:libzeep debian/rules
are not effective because of the earlier override_dh_auto_configure
target. But I didn't actually test any of this.

Hope this helps,

--
Maarten L. Hekkelman
Cataloniëstraat 3
6663NJ Lent

http://www.hekkelman.com/



--
Maarten L. Hekkelman
Cataloniëstraat 3
6663NJ Lent

http

Bug#974016: mrs: FTBFS with libzeep-dev 5.0.0-1: "Checking for libzeep...libzeep is not installed"

[Maarten L. Hekkelman]

I'm sorry, but mrs as it is currently in Debian is not compatible with 
libzeep version 5. It needs a major rewrite. Libzeep is a spin off 
project of mrs and has evolved a lot since then.


So either libzeep should be kept at version 3 or mrs should be removed. 
If mrs and libzeep are kept, I will not be able to release my other 
tools based on libzeep in Debian.


Upgrading mrs is of course the best option, but I won't have time to do 
that soon.


regards, -maarten

Op 09-11-2020 om 16:19 schreef Niko Tyni:

On Mon, Nov 09, 2020 at 09:17:25AM +0200, Juhani Numminen wrote:

Source: mrs
Version: 6.0.5+dfsg-8
Severity: serious
Tags: ftbfs sid
Justification: fails to build from source (but built successfully in the past)
| Checking for libzeep...libzeep is not installed, either install the package 
libzeep-dev
| or download libzeep from ftp://ftp.cmbi.ru.nl/pub/software/libzeep
| and run configure again.
| make[1]: *** [debian/rules:15: override_dh_auto_configure] Error 2

Looks to me like libzeep-dev is broken because the build
doesn't pass --enable-shared to ./configure.

Probably the override_dh_auto_configure-arch and
override_dh_auto_configure-indep targets in src:libzeep debian/rules
are not effective because of the earlier override_dh_auto_configure
target. But I didn't actually test any of this.

Hope this helps,


--
Maarten L. Hekkelman
Cataloniëstraat 3
6663NJ Lent

http://www.hekkelman.com/

Bug#970087: ITP: mrc -- resource compiler to store data in ELF object files

[Maarten L. Hekkelman]

Package: wnpp
Severity: wishlist
Owner: "Maarten L. Hekkelman" 

* Package name: mrc
  Version : 1.2.2
  Upstream Author : Maarten L. Hekkelman
* URL : http://github.com/mhekkel/mrc
* License : BSD-2-Clause-FreeBSD
  Programming Lang: C++
  Description : resource compiler to store data in ELF object files

Many applications come with supplementary data. This data is usually
stored on disk as regular files. The disadvantage of this procedure is
that an application cannot simply be copied to another location or
computer and expected to function properly.

Resources are a way to overcome this problem by including all data
inside the executable file. The mrc resource compiler can create object
files containing both the data and an index. This data can then be
accessed from within an application using C++ classes. A header file
to include in your C++ application is provided. As a resource in mrc
of course.

I'm the author of libzeep, a C++ based web application framework and
in combination with mrc I can create web based application with a
C++ backend, all combined in a single executable that's easily
distributable.

Libzeep is already sponsored by the Med team.

Bug#942518: Renewed Dutch translation for win32-loader

[Maarten]

Dear Holger


I have read your e-mail of 17 October 2019, in which you asked me two
questions about my Dutch translation for win32-loader.

Your questions are only about the following part of my translation.

SOURCE TEXT
Base URL for netboot images (linux and initrd.gz):

TRANSLATION
[Laat een basale URL het gedeelte van een URL zijn dat
gemeenschappelijk is voor alle bestanden van een server. Laat een
netwerk-opstart-image een archiefbestand zijn dat een bestandssysteem
bevat waarmee een computer kan worden opgestart via een netwerk.
--vertaler]\n
\n
Geef de basale URL voor de netwerk-opstart-images (linux en
initrd.gz):

YOUR QUESTIONS
You wrote that I had added a somewhat longer text to a string that
is short in English. You asked me whether I had checked that the
resulting long text will be correctly displayed by the program. You
also thought of the text as being displayed in a small box and asked
me whether that assumption is correct.

ANSWER TO YOUR FIRST QUESTION
I did not check that the translation will be correctly displayed by
the program.

However, checking the correct display of a translation is not my
responsibility. My responsibility is to provide the best possible
translation that complies with the translation instructions. In the
case of the above-mentioned translation, a translation instruction
was not given by the programmers. This means that I had complete
freedom in devising the best translation.

The characteristics of a perfect translation are many. One of them
is full usability for the purpose specified in the translation
instructions. When translation instructions are not provided, a
translator simply aims for maximum usefulness of the translation
itself for the target audience.

The correct display of a translation is the responsibility of the
programmers. The programmers can choose to use a text area with a
vertical scrollbar so that a translation will always fit, or they
can provide a translation instruction to make sure that a translation
will fit in the available space. The matter is not of my concern.

ANSWER TO YOUR SECOND QUESTION
I do not know whether the above translation is displayed in a small
box.

'Base URL for netboot images (linux and initrd.gz):' was found in
'work/l10n/win32-loader.c'. This file uses a function 'langstring'
that seems to be used in connection with nsis.

The website of nsis has a page about a message box. See
https://nsis.sourceforge.io/Reference/MessageBox . It is not clear
whether this message box has a vertical scrollbar that appears
automatically when needed. A procedure 'MessageBox' is called in 7
files in 'work' and their names end with '.nsi'.

The function 'langstring' seems to relate 'Base URL for netboot
images (linux and initrd.gz):' to 'custom5'. 'custom5' can also be
found in the file 'work/custom.nsi'. It contains '${NSD_CreateLabel}
0u 48u -3u 8u $(custom5)'. I cannot understand that code, however.

SUMMARY
You asked me whether I had checked that a long translation will be
correctly displayed by win32-loader. I did not check that. However,
checking the correct display of a translation is not my
responsibility.

You also asked me whether the translation is displayed in a small
box. I do not know that and I am not able to find that out.

CONCLUSION
Your questions have been answered.


With kind regards

Maarten
member of the Dutch translation team of Debian

Bug#942518: [INTL:nl] Renewed Dutch translation for win32-loader

[Maarten]

Package: win32-loader
Version: 0.10.0
Severity: wishlist
Tags: l10n, patch



Dear Maintainers


The Dutch translation for win32-loader has been renewed to meet the
needs of version 0.10.0.


With kind regards

Maarten
member of the Dutch translation team of Debian

nl.po.gz
Description: application/gzip

Bug#941672: [INTL:nl] Renewed Dutch translation for unattended-upgrades

[Maarten]

Package: unattended-upgrades
Version: 1.14
Severity: wishlist
Tags: l10n, patch



Dear Maintainer


The Dutch translation for unattended-upgrades has been renewed to
meet the needs of version 1.14.


With kind regards

Maarten
member of the Dutch translation team of Debian

nl.po.gz
Description: application/gzip

Bug#940851: [INTL:nl] Updated Dutch translation for the configuration of mdadm

[Maarten]

Package: mdadm
Version: 4.1-3
Severity: wishlist
Tags: l10n, patch




Dear Maintainers


The Dutch translation for the configuration of mdadm has been updated
to meet the needs of version 4.1-3.


With kind regards

Maarten
member of the Dutch translation team of Debian

nl.po.gz
Description: application/gzip

Bug#940624: Errors in the translatable messages

[Maarten]

ish source text is particularly important.


CONCLUSION
71 errors were found in the English source text of dbconfig-common.
I mark the text as unsatisfactory.

I recommend that:
1. You correct the English source text.
2. You have the result proofread according to the Debian Developer's
Reference.
3. You ask the translators for new translations.
4. You update the package.


Kind regards

Maarten
member of the Dutch translation team

Bug#939162: Updated debconf PO translation for the package dbconfig-common [INT:nl]

[Maarten]

Package: dbconfig-common
Version: 2.0.12
Severity: wishlist
Tags: patch, l10n



Dear Maintainer


Benedict Verheyen did not seem to be around any more. Therefore, I
updated the translation for dbconfig-common.


Kind regards

Maarten
member of the Dutch translation team of Debian

nl.po.gz
Description: GNU Zip compressed data

Bug#917700: dimbl: FTBFS: build-dependency not installable: libtimbl4-dev

[Maarten van Gompel]

Hi Lucas,

We're going to let this package get autoremoved, it's hardly used anyway
and not worth the effort to maintain.

Regards,

--

Maarten van Gompel
Language Machines research group
Centre for Language and Speech Technology
Radboud Universiteit Nijmegen

proy...@anaproy.nl
https://proycon.anaproy.nl
https://github.com/proycon

GnuPG key:  0x39FE11201A31555C
XMPP:   proy...@anaproy.nl   Matrix: @proycon:matrix.org
Telegram:   proycon  IRC: proycon (freenode)
Discord:proycon#8272
Mastodon:   https://mastodon.social/@proycon   (@proycon@mastodon.social)
Twitter:https://twitter.com/proycon
ORCID:  https://orcid.org/-0002-1046-0006
Keybase:https://keybase.io/proycon
Bitcoin:1BRptZsKQtqRGSZ5qKbX2azbfiygHxJPsd


signature.asc
Description: PGP signature

Bug#915264: libfolia: Please upgrade to version 1.15

[Maarten van Gompel]

Hi Hugh,

On 18-12-07 08:43, Hugh McMaster wrote:
> Hi Maarten,
>
> On Sunday, 2 December 2018 10:40 PM, Maarten van Gompel wrote:
> > Thanks, I'm aware of it and am currently working to update the debian
> > packages.
>
> Many thanks for your work on libfolia, ucto and frog.
>
> I saw you had updated the Salsa repositories for these packages.
> When do you plan to release them to unstable?

Everything is indeed ready and I in fact already attempted the upload,
but I received REJECTED from FTP master because various source packages 
introduce NEW
binaries and I seem to lack permission for that, I'm still having some trouble
securing the necessary help to get things going again, which causes some delay
unfortunately.

Regards,

--

Maarten van Gompel
Language Machines research group
Centre for Language and Speech Technology
Radboud Universiteit Nijmegen

proy...@anaproy.nl
https://proycon.anaproy.nl
https://github.com/proycon

GnuPG key:  0x39FE11201A31555C
XMPP:   proy...@anaproy.nl   Matrix: @proycon:matrix.org
Telegram:   proycon  IRC: proycon (freenode)
Discord:proycon#8272
Mastodon:   https://mastodon.social/@proycon   (@proycon@mastodon.social)
Twitter:https://twitter.com/proycon
ORCID:  https://orcid.org/-0002-1046-0006
Keybase:https://keybase.io/proycon
Bitcoin:1BRptZsKQtqRGSZ5qKbX2azbfiygHxJPsd


signature.asc
Description: PGP signature

Bug#913514: libfolia FTBFS with ICU 63.1

[Maarten van Gompel]

On 18-11-11 08:18, László Böszörményi wrote:
> Source: libfolia
> Source-Version: 1.6-2
> Severity: important
> Tags: patch
> Usertags: icu63
>
> Dear Maintainer,
>
> ICU 63.1 recently released, packaged and uploaded to experimental.
> Its transition is going to start soon. However your package fails to
> build with this version. I attach a patch which fixes the problem.
> Please check if it works with the version in Sid and upload the
> package when it's feasible for you.
>
> Thanks,
> Laszlo/GCS

Thanks for the heads up and the patch! This problem had already been addressed 
upstream as well and
I just prepared new updated debian packages that should fix it, still pending
upload.

Kind egards,

--

Maarten van Gompel
Language Machines research group
Centre for Language and Speech Technology
Radboud Universiteit Nijmegen

proy...@anaproy.nl
https://proycon.anaproy.nl
https://github.com/proycon

GnuPG key:  0x39FE11201A31555C
XMPP:   proy...@anaproy.nl   Matrix: @proycon:matrix.org
Telegram:   proycon  IRC: proycon (freenode)
Discord:proycon#8272
Mastodon:   https://mastodon.social/@proycon   (@proycon@mastodon.social)
Twitter:https://twitter.com/proycon
ORCID:  https://orcid.org/-0002-1046-0006
Keybase:https://keybase.io/proycon
Bitcoin:1BRptZsKQtqRGSZ5qKbX2azbfiygHxJPsd

Bug#915264: libfolia: Please upgrade to version 1.15

[Maarten van Gompel]

On 18-12-02 09:51, Hugh McMaster wrote:
> Package: libfolia6
> Version: 1.6-2+b1
> Severity: wishlist
>
> Dear Maintainer,
>
> The current version of libfolia is almost two years old and is missing several
> bug fixes and enhancements.
>
> It also does not work with icu 63.1.
>
> Please upgrade to the latest upstream version - 1.15.

Thanks, I'm aware of it and am currently working to update the debian
packages.

Regards,

--

Maarten van Gompel
Language Machines research group
Centre for Language and Speech Technology
Radboud Universiteit Nijmegen

proy...@anaproy.nl
https://proycon.anaproy.nl
https://github.com/proycon

GnuPG key:  0x39FE11201A31555C
XMPP:   proy...@anaproy.nl   Matrix: @proycon:matrix.org
Telegram:   proycon  IRC: proycon (freenode)
Discord:proycon#8272
Mastodon:   https://mastodon.social/@proycon   (@proycon@mastodon.social)
Twitter:https://twitter.com/proycon
ORCID:  https://orcid.org/-0002-1046-0006
Keybase:https://keybase.io/proycon
Bitcoin:1BRptZsKQtqRGSZ5qKbX2azbfiygHxJPsd

Bug#915008:

[Maarten]

see also: https://bugzilla.kernel.org/show_bug.cgi?id=201813

Bug#915008: firmware-iwlwifi: latest firmware broken for Intel AC9560

[Maarten]

Package: firmware-iwlwifi
Version: 20180825+dfsg-1
Severity: important
Tags: upstream

Dear Maintainer,
   * What led up to the situation?
   -> Upgrade of the firmware package
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   -> Downgrading firmware seems ineffective

journalctl -f output:

Nov 29 13:26:39 kernel: Intel(R) Wireless WiFi driver for Linux
Nov 29 13:26:39 kernel: Copyright(c) 2003- 2015 Intel Corporation
Nov 29 13:26:39 kernel: iwlwifi :00:14.3: firmware: direct-loading firmware
iwlwifi-9000-pu-b0-jf-b0-38.ucode
Nov 29 13:26:39 kernel: iwlwifi :00:14.3: loaded firmware version
38.c0e03d94.0 op_mode iwlmvm
Nov 29 13:26:39 kernel: iwlwifi :00:14.3: Detected Intel(R) Dual Band
Wireless AC 9560, REV=0x318
Nov 29 13:26:39 kernel: iwlwifi :00:14.3: Microcode SW error detected.
Restarting 0x0.
Nov 29 13:26:39 kernel: iwlwifi :00:14.3: Not valid error log pointer
0x for Init uCode
Nov 29 13:26:39 kernel: iwlwifi :00:14.3: SecBoot CPU1 Status: 0x3, CPU2
Status: 0x240f
Nov 29 13:26:39 kernel: iwlwifi :00:14.3: Failed to start INIT ucode: -5
Nov 29 13:26:39 kernel: iwlwifi :00:14.3: Failed to run INIT ucode: -5



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

Kernel: Linux 4.18.0-2-amd64 (SMP w/12 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

firmware-iwlwifi depends on no packages.

firmware-iwlwifi recommends no packages.

Versions of packages firmware-iwlwifi suggests:
ii  initramfs-tools  0.132

-- no debconf information

Bug#907930: New version upstream

[Maarten den Braber]

Package: webhook
Version: 2.5.0-2+b1

Current version is 2.5.0 which e.g. doesn't work correctly with the 
payload-hash-
sha256 check needed for X-Gogs-Signature. Could the package be uddated
to the current upstream version (2.6.8)? Thanks.
best,
Maarten

Bug#907561: Duplicate report

[Maarten de Jong]

If someone could please remove this report. There's already a report here:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=907466

Bug#907561: Relevant iso-codes bug report

[Maarten de Jong]

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=907466

This report says that iso-codes doesn't ship the xml files anymore and
wants apps to use the json files instead. Gedit also gives warning messages
because the xml files are missing. Should i report a bug there too?

Bug#907561: gnome-software: software fails to start: Failed to map ISO639 to language names

[Maarten de Jong]

Package: gnome-software
Version: 3.28.2-1
Severity: important

Dear Maintainer,

After moving from testing to unstable, I've been unable to start 
gnome-software. 
I have purged the package and reinstalled it but this doesn't fix it.
When running gnome-software from the terminal, i get the following error:

12:18:38:0278 Gs  Failed to map ISO639 to language names: cannot find source 
file : '/usr/pkg/share/xml/iso-codes/iso_639.xml'
Trace/breakpoint trap

At the beginning it also says in red: plugin appstream took 2.2 seconds to do 
setup
But i don't think that's relevant.

Since it's got to do with iso-codes i tried reinstalling iso-codes, which did 
not work. 
I downloaded the source code of iso-codes(sudo apt source iso-codes), but i 
still got the error.

so:
expected outcome: gnome-software runs when clicking on software.
real outcome: gnome-software fails to run, gives an error instead. 

This is on a debian minimal install (netinst, didn't select anything when 
installing), with gnome-core installed.

My sources:
deb http://ftp.nl.debian.org/debian/ unstable main contrib non-free
deb-src http://ftp.nl.debian.org/debian/ unstable main contrib non-free

-- System Information:
Debian Release: buster/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)

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 /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages gnome-software depends on:
ii  appstream0.12.2-2
ii  apt-config-icons 0.12.2-2
ii  dconf-gsettings-backend [gsettings-backend]  0.28.0-2
ii  gnome-software-common3.28.2-1
ii  gsettings-desktop-schemas3.28.0-1
ii  libappstream-glib8   0.7.12-1
ii  libatk1.0-0  2.28.1-1
ii  libc62.27-5
ii  libcairo21.15.12-1
ii  libfwupd21.1.1-1
ii  libgdk-pixbuf2.0-0   2.36.12-2
ii  libglib2.0-0 2.56.1-2
ii  libgnome-desktop-3-173.28.2-2
ii  libgspell-1-11.6.1-1
ii  libgtk-3-0   3.22.30-2
ii  libgtk3-perl 0.034-1
ii  libgudev-1.0-0   232-2
ii  libjson-glib-1.0-0   1.4.2-4
ii  libpackagekit-glib2-18   1.1.10-1
ii  libpolkit-gobject-1-00.105-21
ii  libsecret-1-00.18.6-2
ii  libsoup2.4-1 2.62.2-2
ii  packagekit   1.1.10-1
ii  software-properties-gtk  0.96.20.2-1

gnome-software recommends no packages.

Versions of packages gnome-software suggests:
pn  apt-config-icons-hidpi 
pn  fwupd  
pn  gnome-software-plugin-flatpak  
pn  gnome-software-plugin-limba
pn  gnome-software-plugin-snap 

-- no debconf information

Bug#903740: Many messages in unattended-upgrades.pot are poor

[Maarten]

Package: unattended-upgrades
Version: 1.2
Severity: minor
Tags: patch


Dear maintainers


Recently I made an improved Dutch translation of the messages in
unattended-upgrades.pot. It was submitted for inclusion in
unattended-upgrades on 7 July 2018.

During my translation, it appeared to me that many messages in
unattended-upgrades.pot are poor. This related mostly to poor
English, but also to other aspects, such as ambiguity and vagueness.

Therefore, I created a 'translation' of all messages in
proper English. The 'translation' also contains comments that briefly
point out both the language errors and the shortcomings in the
messages.

I have attached my 'translation' to this bug report.

Please study the attachment and then make corrections to your source
code. When you have generated a new pot-file, you may ask the English
translation team to proofread it.


With kind regards

Maarten
Member of the Dutch translation team of Debian


en.po.gz
Description: application/gzip

Bug#903214: Dutch translation has been improved

[Maarten]

Package: unattended-upgrades
Version: 1.2
Severity: minor
Tags: patch, l10n

Dear Maintainers


The Dutch translation for the unattended-upgrades package has been
improved. It has been made to apply to version 1.2 of your package.
However, it applies to version 1.4 too.

The improved translation has been reviewed within the Dutch
translation team. Please use the new translation for the next version
of your package.


With kind regards

Maarten
Member of the Dutch translation team of Debian


nl.po.gz
Description: application/gzip

Bug#855034: debdiff to update to Protobuf 3.2.1 and add ruby-google-protobuf

[Maarten]

Thanks for uploading the new updated protobuf packages Laszlo, much
appreciated!
I was wondering if you will push the source to a VCS, like the new Debian
salsa?

Thanks!

On Mon, May 21, 2018 at 8:03 PM László Böszörményi (GCS) 
wrote:

> On Fri, May 18, 2018 at 7:02 PM Pirate Praveen  wrote:
> > On Fri, 14 Apr 2017 11:06:10 +0000 Maarten 
> > wrote:
> > > tag 855034 +patch
> > > retitle 855034 update to Protobuf 3.2.1 and add ruby-google-protobuf
> > >
> > > I attached a debdiff to update to protobuf 3.2.1 and also added a
> > > decleration for the ruby-google-protobuf package.
>
> > protobuf 3.5.2 is available in experimental.
>
> > ruby-google-protobuf is a separate source package now.
>   Indeed.
>
> > Laszlo and other maintainers, what is the plan for uploading this
> > version to unstable? I need this for gitlab.
>   As I see, I'm the only maintainer at the moment - or other please speak
> up.
> About the upload timing: I'll do it when I could test everything and I'm
> allowed to do it.
>
> Cheers,
> Laszlo/GCS
>
-- 

met vriendelijke groet/kind regards,

Maarten Fonville

Bug#874498: updated protobuf

[Maarten]

Could you also maybe take a look at the version I maintained for my PPA
whether you could use any changes to update the official package, like
support for Ruby?

the source can be found at
https://github.com/mfonville/protobuf/commits/master
-- 

met vriendelijke groet/kind regards,

Maarten Fonville

Bug#888614: Installation of dotnet35 doesn't finalize

[Maarten Abbink]

I can confirm this bug report on Ubuntu 16.0.4.3LTS 4.4.0-112-generic x68_64
Play on Linux version: 4.2.10
Bug observed with wine prefixes: v3.1 x86, v1.9.19 x86

On my system, this infinite loops causes the reported error message to be
written to ~/.cache/upstart/unity7.log over and over again.
While this error is being logged, inspecting the registry of the affected
wine prefix reveals that the registry
key 'HKEY_LOCAL_MACHINE\Software\Microsoft\NET Framework Setup\NDP\v3.5'
does not exist. Adding it manually either during or before the dotnet35
setup has no effect.

Bug#884494: ITP: dokuwiki-plugin-graphviz -- Create directed and non-directed graph images

[Maarten Horden]

Package: wnpp
Severity: wishlist
Owner: Maarten Horden <m.horden+deb...@parsus.nl>

* Package name: dokuwiki-plugin-graphviz
  Version : 2016-02-03
  Upstream Author : Andreas Gohr <a...@splitbrain.org>
* URL : https://www.dokuwiki.org/plugin:graphviz
* License : GPL 2
  Programming Lang: PHP
  Description : Create directed and non-directed graph images

Provides the ability to create directed and non-directed
graph images from a textual description language called “dot” using the
Graphviz program. It can use a locally installed graphviz or use
Google's chart API for rendering.

Plugin for, and depends on dokuwiki, as well as graphviz.

Maintained by Maarten Horden <m.horden+deb...@parsus.nl>
Uploaded by Joost van Baal-Ilić <joos...@debian.org>

Bug#884461: ITP: dokuwiki-plugin-wrap -- Provides the ability to wrap wiki text inside containers

[Maarten Horden]

Package: wnpp
Severity: wishlist
Owner: Maarten Horden <m.horden+deb...@parsus.nl>

* Package name: dokuwiki-plugin-wrap
  Version : 2015-07-19
  Upstream Author : Anika Henke <an...@selfthinker.org>
* URL : https://www.dokuwiki.org/plugin:wrap
* License : GPL 2
  Programming Lang: PHP
  Description : Provides the ability to wrap wiki text inside containers

Universal plugin which combines the functionality of many other plugins.
Wrap wiki text inside containers (divs or spans) and give them a class
(choose from a variety of preset classes), a width and/or a language
with its associated text direction.

Plugin for, and depends on dokuwiki.

Maintained by Maarten Horden <m.horden+deb...@parsus.nl>
Uploaded by Joost van Baal-Ilić <joos...@debian.org>

Bug#879818: RM: xserver-xorg-video-freedreno -- ROM; Unmaintained and replaced by modesetting ddx upstream.

[Maarten Lankhorst]

Package: ftp.debian.org
Severity: normal

This package has been unmaintained upstream for the last 2 years except
for some build fixes. In the meantime the upstream maintainer considers it
abandoned, and recommends using the modesetting ddx with glamor instead.

Bug#861269: [Letsencrypt-devel] Bug#861269: certbot: Fails to install on jessie-backports

[Maarten]

Ran into the same bug. Any idea on how long this will take?

On Wed, 26 Apr 2017 19:19:36 + Harlan Lieberman-Berg  
wrote:
> Hello,
> 
> This is a result of the python-acme package being migrated from
> jessie-backports-policy to jessie-backports before the rest of the certbot
> packages.
> 
> It should resolve automatically when the rest of the certbot packages
> migrate.
> 
> Sorry for the delay!
> 
> Sincerely,
> -- 
> Harlan Lieberman-Berg
> ~hlieberman

Bug#860849: duplicity: Duplicity OOMs machines while processing backup chains (memleak?)

[Maarten Aertsen]

Hi,

On 2017-04-22 03:17, Alexander Zangerl wrote:
> On Thu, 20 Apr 2017 23:47:19 +0200, Maarten Aertsen writes:
> >Using duplicity with a S3 remote for a while, until multiple backup
> >chains exist.
> 
> could you please provide the output of a collection-status,
> 'multiple chains exist' is a bit too little information to debug.

I'm afraid I can't for exactly the same reason I think this is a bug: 
memory usage explodes, the machine locks up and I never get a result. 
This on a 1024MB vhost with 515MB free -/+ buffers/cache and 2GB nearly 
unused swap.

> how often do you remove chains?

Full backups happen every week, incrementals twice per day. Cleanup 
happens on S3 (duplicity has append-only rights to S3), with 90 day 
retention of full backups, 14 day retention of incrementals.

> how many chains are there?

I can make a count based on S3. There's 320 files, making up 8 chains, 

> how many incrementals per chain?

Within the 14 day retention, there's a maximum of two chains with a 
week's worth of incrementals (2*7*2=28 increments). Because duplicity 
does not perform the cleanup, at some point the oldest chain breaks 
(when the first incremental gets deleted).

The backups are very small, a full has ~42 volumes of 200MB = ~8.4G. 
Total size is ~76G.

Workaround is to move the files to a separate dir to make them invisible 
for duplicity.

> >   * What exactly did you do (or not do) that was effective (or ineffective)?
> >/usr/bin/duplicity full --s3-use-ia --asynchronous-upload --encrypt-key 
> >
> > --encrypt-key  --include-filelist /etc/backup-targets / 
> 
> does your /etc/backup-targets exclude /proc, /sys and /dev? otherwise your
> invocation as given here would attempt to back up everything, including
> stuff like /dev/mem.

No, /etc/backup-targets has "- /" as last line, and none of the 
mentioned paths is explicitly included in earlier lines.

thanks, Maarten

Bug#860849: duplicity: Duplicity OOMs machines while processing backup chains (memleak?)

[Maarten Aertsen]

Package: duplicity
Version: 0.7.10-1~bpo8+1
Severity: important

Dear Maintainer,

   * What led up to the situation?
Using duplicity with a S3 remote for a while, until multiple backup chains 
exist.

   * What exactly did you do (or not do) that was effective (or ineffective)?
/usr/bin/duplicity full --s3-use-ia --asynchronous-upload --encrypt-key  
--encrypt-key  --include-filelist /etc/backup-targets / 

(same effect when substituting full for incremental or collection-status)

   * What was the outcome of this action?
Sudden spikes in CPU and memory consumption resulting in a machine that does 
not react to console or ssh logins until reboot. Screen displays kernel 
warnings for hung tasks / timeouts (unfortunately not recoverable from logging).

   * What outcome did you expect instead?
Normal completion of full and incremental backups

when run using a soft ulimit on memory use, I get the following error trace:

>8 snip >8
Reading globbing filelist /etc/backup-targets
Local and Remote metadata are synchronized, no sync needed.


Traceback (most recent call last):
  File "/usr/bin/duplicity", line 1553, in 
with_tempdir(main)
  File "/usr/bin/duplicity", line 1547, in with_tempdir
fn()
  File "/usr/bin/duplicity", line 1398, in main
do_backup(action)
  File "/usr/bin/duplicity", line 1423, in do_backup
globals.archive_dir).set_values()
  File "/usr/lib/python2.7/dist-packages/duplicity/collections.py", line 710, 
in set_values
self.get_backup_chains(partials + backend_filename_list)
  File "/usr/lib/python2.7/dist-packages/duplicity/collections.py", line 836, 
in get_backup_chains
add_to_sets(f)
  File "/usr/lib/python2.7/dist-packages/duplicity/collections.py", line 830, 
in add_to_sets
if new_set.add_filename(filename):
  File "/usr/lib/python2.7/dist-packages/duplicity/collections.py", line 101, 
in add_filename
self.set_manifest(filename)
  File "/usr/lib/python2.7/dist-packages/duplicity/collections.py", line 148, 
in set_manifest
self.set_files_changed()
  File "/usr/lib/python2.7/dist-packages/duplicity/collections.py", line 128, 
in set_files_changed
mf = self.get_manifest()
  File "/usr/lib/python2.7/dist-packages/duplicity/collections.py", line 250, 
in get_manifest
return self.get_local_manifest()
  File "/usr/lib/python2.7/dist-packages/duplicity/collections.py", line 224, 
in get_local_manifest
return manifest.Manifest().from_string(manifest_buffer)
  File "/usr/lib/python2.7/dist-packages/duplicity/manifest.py", line 215, in 
from_string
vi = VolumeInfo().from_string(match.group(1))
MemoryError
>8 snip >8

-- System Information:
Debian Release: 8.7
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: amd64 (x86_64)

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

Versions of packages duplicity depends on:
ii  libc62.19-18+deb8u7
ii  librsync10.9.7-10
ii  python   2.7.9-1
ii  python-lockfile  1:0.8-2

Versions of packages duplicity recommends:
ii  python-oauthlib  0.6.3-1
ii  python-paramiko  1.15.1-1
ii  python-urllib3   1.9.1-3
ii  rsync3.1.1-3

Versions of packages duplicity suggests:
pn  lftp
pn  ncftp   
ii  python-boto 2.34.0-2
pn  python-cloudfiles   
pn  python-gdata
pn  python-swiftclient  
ii  tahoe-lafs  1.10.0-2

-- no debconf information

Bug#855034: Protobuf 3.2.1

[Maarten]

I now tried to package protobuf 3.2.1 for zesty

most important change is that gmock and gtest have been migrated to the new
googletest package.

I still lacks the creation of some new packages for the new languages
supported by protobuf.
-- 

met vriendelijke groet/kind regards,

Maarten Fonville

Bug#855034: Update packate to Protobuf 3.2.0

[Maarten]

Package: protobuf
Version: 3.0.0-9
Severity: wishlist

There is a new version of Protobuf released, version 3.2.0
I already packaged it in my PPA for Ubuntu at
https://launchpad.net/~maarten-fonville/+archive/ubuntu/protobuf/ but did
not create any new packages yet for the new php/javascript/java-lite etc, I
don't have any experience with starting those from scratch :-/

The deb source can be found at https://github.com/mfonville/protobuf

Hope somebody could update the version in Debian itself
-- 

met vriendelijke groet/kind regards,

Maarten Fonville

Bug#838112: uctodata: fails to upgrade from jessie - trying to overwrite /etc/ucto/es.abr

[Maarten van Gompel]

 old directory '/etc/ucto': Directory
> not empty
>   Setting up libgomp1:amd64 (6.3.0-4) ...
>   Setting up libxml2:amd64 (2.9.4+dfsg1-2.2) ...
>   Processing triggers for libc-bin (2.24-9) ...
>   Setting up libucto2:amd64 (0.9.6-1) ...
>   Removing obsolete conffile /etc/ucto/e-mail.rule ...
>   Removing obsolete conffile /etc/ucto/smiley.rule ...
>   Removing obsolete conffile /etc/ucto/url.rule ...
>   Removing obsolete conffile /etc/ucto/standard-eos.eos ...
>   Removing obsolete conffile /etc/ucto/standard-quotes.quote ...
>   Removing obsolete conffile /etc/ucto/tokconfig-generic ...
>   Processing triggers for libc-bin (2.24-9) ...
> 
> 
> libucto2.maintscript is missing this line:
> 
> rm_conffile /etc/ucto/tokconfig-generic 0.9.6-2~

Really? There's a line "rm_conffile /etc/ucto/tokconfig-generic 0.9.6~"
since the first commit. And it does say "Removing obsolete conffile
/etc/ucto/tokconfig-generic" above.


Ciao,


--

Maarten van Gompel
Centre for Language Studies
Radboud Universiteit Nijmegen

proy...@anaproy.nl
https://proycon.anaproy.nl
https://github.com/proycon

GnuPG key:  0x1A31555C  
XMPP: proy...@anaproy.nl  Matrix: @proycon:anaproy.nl
Telegram:   proycon   IRC: proycon (freenode)
Twitter:https://twitter.com/proycon
ORCIRD: https://orcid.org/-0002-1046-0006 
Bitcoin:1BRptZsKQtqRGSZ5qKbX2azbfiygHxJPsd

Bug#838112: uctodata: fails to upgrade from jessie - trying to overwrite /etc/ucto/es.abr

[Maarten van Gompel]

Quoting Andreas Beckmann (2017-01-24 02:54:36)
> On 2017-01-24 02:51, Andreas Beckmann wrote:
> > spotted a typo (trailing "a") in frogdata.maintscript
> > 
> > echo "rm_conffile /etc/frog/${subdir}Frog.mbt.1.0.known.dddwfWaw.wgt 
> > 0.13.7~"a
> 
> but that's harmless, its still a valid version to achieve your goal

Oops... Well spotted, I just fixed it in git, but it is probably overkill to 
prepare/upload a new release just
for that now I guess?

--

Maarten van Gompel
Centre for Language Studies
Radboud Universiteit Nijmegen

proy...@anaproy.nl
https://proycon.anaproy.nl
https://github.com/proycon

GnuPG key:  0x1A31555C  
XMPP: proy...@anaproy.nl  Matrix: @proycon:anaproy.nl
Telegram:   proycon   IRC: proycon (freenode)
Twitter:https://twitter.com/proycon
ORCIRD: https://orcid.org/-0002-1046-0006 
Bitcoin:1BRptZsKQtqRGSZ5qKbX2azbfiygHxJPsd

Bug#838112: uctodata: fails to upgrade from jessie - trying to overwrite /etc/ucto/es.abr

[Maarten van Gompel]

Hi Mattia, Andreas,

@Mattia: Thanks! I'm trying to finalize the packages but still running into 
something:

> use debian/$package.maintscript instead of doing it directly in maintscripts
> 
> put in there lines like
> 
> rm_conffile /etc/ucto/tokconfig-es 0.4-1~
> 
> no dpkg-maintscript-helper prefix, no default arguments, no trailing
> comments!
> use $VERSION_TO_BE_UPLOADED + "~" as prior-version argument
> 
> this will generate appropriate pre/post/inst/rm scripts with the same
> content

This is what I was looking for yes, I knew something must exist to take care of
this but didn't know what it was.  I now followed Andreas' instructions, but on 
but upon gbp buildpackage I now get
errors like:

/home/proycon/debian_packaging/uctodata/debian/uctodata.maintscript: 1: 
/home/proycon/debian_packaging/uctodata/debian/uctodata.maintscript: 
rm_conffile: not found 

So I'm still doing something wrong. Any idea what I am missing? You said no 
dpkg-maintscript-helper prefix..

Ciao,

--

Maarten van Gompel
Centre for Language Studies
Radboud Universiteit Nijmegen

proy...@anaproy.nl
https://proycon.anaproy.nl
https://github.com/proycon

GnuPG key:  0x1A31555C  
XMPP: proy...@anaproy.nl  Matrix: @proycon:anaproy.nl
Telegram:   proycon   IRC: proycon (freenode)
Twitter:https://twitter.com/proycon
ORCIRD: https://orcid.org/-0002-1046-0006 
Bitcoin:1BRptZsKQtqRGSZ5qKbX2azbfiygHxJPsd

Bug#838112: uctodata: fails to upgrade from 'jessie' - trying to overwrite /etc/ucto/es.abr

[Maarten van Gompel]

Hi Andreas et al,

Short follow up: we discussed it internally and think it's indeed best to just
move the 'configuration' files to /usr/share, as you pointed out; simplifying 
the package and
resolving the conflicts. 

We're currently working on new upstream releases for
ucto, uctodata, frogdata, and frog  (the latter two have the same division and
make the same mistake, and depends on ucto/uctodata too) that implement this. I
hope releasing four new packages so close to the freeze is not going to be a
problem. At least it should fix this bug for good.

Regards,

--

Maarten van Gompel
Centre for Language Studies
Radboud Universiteit Nijmegen

proy...@anaproy.nl
https://proycon.anaproy.nl
https://github.com/proycon

GnuPG key:  0x1A31555C  
XMPP: proy...@anaproy.nl  Matrix: @proycon:anaproy.nl
Telegram:   proycon   IRC: proycon (freenode)
Twitter:https://twitter.com/proycon
ORCIRD: https://orcid.org/-0002-1046-0006 
Bitcoin:1BRptZsKQtqRGSZ5qKbX2azbfiygHxJPsd



Quoting Maarten van Gompel (2017-01-23 11:10:18)
> Hi Andreas,
> 
> Thanks for your elaborate response! It seems this has indeed opened quite a 
> can
> of worms.. Here we go:
> 
> Quoting Andreas Beckmann (2017-01-22 22:27:08)
> > TL;DR: You have an ambitious task before you.
> 
> So I see...
> 
> > Let me see if I understand what's going on.
> >
> > Renaming conffiles and changing the owning package at the same time is a
> > PITA.
> > You add an extra point by making the old name a symlink to the new one,
> > owned by the new package
> >
> > In jessie, everything in /etc/ucto was owned by ucto.
> > In sid, a lot more stuff is in /etc/ucto, and either owned by uctodata
> > or libucto2, a m-a:same library package. These come from 2 different
> > source packages.
> 
> Indeed..
> 
> > Yuck. While putting conffiles in m-a:same packages is allowed, I highly
> > discourage this. Even if I haven't seen this fail once, yet. I'm just
> > afraid, someone has to clean up a mess caused by this at some point in
> > the future. and I'm afraid, I won't keep my fingers out of then :-(
> 
> Ok, we'll come back to this in your later suggestion to move the conffiles to 
> a
> new package.
> 
> > Before we start: Are these really conffiles? Supposed to be modified by
> > the local admin? Or are these rather data files that are not supposed to
> > be updated locally? And would better live in /usr/share in that case?
> 
> You have a point there; the user MAY add a new configuration or modify an
> existing one, but it is indeed not something that NEEDS to be modified to 
> run. You may be right that
> /usr/share might be better here. I'd have to discuss with the main upstream
> developer, but I think we're not opposed to such 'radical' solutions if that
> solves the packaging problems and makes more semantic sense anyway.
> What do you think is best for the short term to get this fixed before the
> freeze?
> 
> > And nearly everything from jessie's /etc/ucto content is now renamed and
> > a symlink.
> 
> > Can't you just fork the project? I'd suggest 'hpgb' and then use
> > /etc/hpgb for the conffiles. Oh, I forgot: we are in freeze, so no new
> > source packages ...
> >
> > Oh yeah, it well be a mess. But we will do it right. Including making
> > dpkg forget about the old conffiles.
> >
> > Right now, all upgrade attempts from jessie to stretch should always
> > have failed, so there is no further messed up state inbetween that
> > should be supported for clean upgrades.
> 
> Right
> 
> > can we move the conffiles from libucto2 to a new package, e.g.
> > ucto-common (which would be either m-a:foreign or m-a:allowed, but I
> > always mess up these two, I need to look up what's right?
> 
> Okay, that sounds good to me, if there's no objection to having yet another
> package.
> 
> > * Which version introduced the new layout?
> > * can you give me a list of
> >   + removed conffiles
> >   + renamed conffiles (old name, new name, new owning package, whether
> > they have a compat symlink, did the content change between jessie and sid)
> 
> ucto 0.9.2 introduced the split into uctodata. The jessie version is very 
> old: 0.5.3-3.1
> The following files moved out of ucto 0.9.2 (libucto2) into the new uctodata 
> package:
> 
>  config/es.abr
>  config/exotic-eos.eos
>  config/exotic-quotes.quote
>  config/ligatures.filter
>  config/nl_afk.abr
>  config/pt.abr  (not in jessie version)
>  config/tokconfig-de
>  config/tokconfig-en
>  config/tokconfig-es
>  config/tokconfig-fr
>  config/tokconfig-fy
>  config/tokconfig-it
>  config/

Bug#838112: uctodata: fails to upgrade from 'jessie' - trying to overwrite /etc/ucto/es.abr

[Maarten van Gompel]

   (not in jessie version)   -> 
config/tokconfig-tur
 config/tokconfig-sv -> config/tokconfig-swe

At that point we decided to symlink from  the old two-letter versions to the
new three-letter versions, for backward compatibility "to make things easy"..
but apparantly this didn't play out as anticipated :)

> Do you *really* need the compat symlinks?

No, it's just a courtesy for the user that we don't mind dropping at all if it
complicates matters like this.

> OK, packaging is in git. Need to check whether I have write permissions
> there ...
>
> rough plan:
>
> ucto uses d-m-h move-conffile (but provides no new version, so the old
> conffile should "disappear" and dpkg should forget about it.
> Maybe it's better to rm_conffile it instead.

Okay, I'll read up on all that today then because I have to prior experience 
with those.

> uctodata will probably need a Conflicts against ucto (<< current+fixed~)

Right,


Thanks for your help!


--

Maarten van Gompel
Centre for Language Studies
Radboud Universiteit Nijmegen

proy...@anaproy.nl
https://proycon.anaproy.nl
https://github.com/proycon

GnuPG key:  0x1A31555C  
XMPP: proy...@anaproy.nl  Matrix: @proycon:anaproy.nl
Telegram:   proycon   IRC: proycon (freenode)
Twitter:https://twitter.com/proycon
ORCIRD: https://orcid.org/-0002-1046-0006 
Bitcoin:1BRptZsKQtqRGSZ5qKbX2azbfiygHxJPsd

Bug#838112: uctodata: fails to upgrade from 'jessie' - trying to overwrite /etc/ucto/es.abr

[Maarten van Gompel]

Quoting Andreas Beckmann (2017-01-16 17:24:19)
> Followup-For: Bug #838112
> Control: found -1 0.3.1-1
> Control: affects -1 + ucto
> 
> that bug has just reappered:
> 
>   Preparing to unpack .../ucto_0.9.5-1_amd64.deb ...
>   Unpacking ucto (0.9.5-1) over (0.5.3-3.1+b1) ...
>   dpkg: warning: unable to delete old directory '/etc/ucto': Directory not 
> empty
>   Selecting previously unselected package uctodata.
>   Preparing to unpack .../uctodata_0.3.1-1_all.deb ...
>   Unpacking uctodata (0.3.1-1) ...
>   dpkg: error processing archive 
> /var/cache/apt/archives/uctodata_0.3.1-1_all.deb (--unpack):
>trying to overwrite '/etc/ucto/es.abr', which is also in package ucto 
> 0.9.5-1
> 
> 
> Andreas

Hi,

Thanks for the notification. It seems this bug is a persistent one and I don't 
really get why it's
resurfacing; I'm probably missing something so CC'ing the debian-science list
for help. Ucto 0.9.5 no longer has the
mentioned file /etc/ucto/es.abr, is was part of ucto until 0.8.0-1 and then
moved to a separate uctodata package. To prevent this issue, ucto 0.9.5 
(package libucto2 actually),
states:

Replaces: ucto (<< 0.5.5-1)
Breaks: ucto (<< 0.5.5-1)

Uctodata also states:

Replaces: ucto (<< 0.9.2-1)
Breaks: ucto (<< 0.9.2-1

But as this resurfaced, it's apparently not enough, What am I missing here?

Regards,

--

Maarten van Gompel
Centre for Language Studies
Radboud Universiteit Nijmegen

proy...@anaproy.nl
https://proycon.anaproy.nl
https://github.com/proycon

GnuPG key:  0x1A31555C  
XMPP: proy...@anaproy.nl  Matrix: @proycon:anaproy.nl
Telegram:   proycon   IRC: proycon (freenode)
Twitter:https://twitter.com/proycon
ORCIRD: https://orcid.org/-0002-1046-0006 
Bitcoin:1BRptZsKQtqRGSZ5qKbX2azbfiygHxJPsd

Bug#836821: Python3 patch; some obstacles found

[Maarten]

Hi everyone,

Thomas, thanks for your patch. I used it to build protobuf 3.0.2 for ubuntu
xenial, some remarks that might be of interest for the maintainers:

* The older GCC in Ubuntu does not accept
`-Wno-error=misleading-indentation` maybe this should be specified
conditional depending on the GCC version used?

* I had to add
```
set -e; \
export LD_LIBRARY_PATH=$(CURDIR)/src/.libs; \
```
online 49 in build/rules -> override_dh_auto_test-arch,
otherwise it would not find the protobuf library.

* I had to explicitly add `python3-six` as a build-dependency, not sure why
it did not get picked up by the automatic dependency management.

* The python3 tests have a bug in 3.0.2 and need this patch (
https://github.com/google/protobuf/commit/64958cdb1d68a0ddaf10bd0ebdb4c112c370c416
)
to pass successful.


-- 

met vriendelijke groet/kind regards,

Maarten Fonville

Bug#837542: mate-power-manager: segfault (infinite recursion) after changing brightness with brightness keys

[Maarten Aertsen]

Package: mate-power-manager
Version: 1.14.0-2
Followup-For: Bug #837542

Dear Maintainer,

I can reproduce this bug on this Dell XPS 13 9343 as described by
Samuel. I'm available to provide additional information if required.

best regards, Maarten

-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (750, 'testing'), (50, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages mate-power-manager depends on:
ii  dbus-x111.10.10-1
ii  libatk1.0-0 2.21.90-2
ii  libc6   2.23-5
ii  libcairo-gobject2   1.14.6-1+b1
ii  libcairo2   1.14.6-1+b1
ii  libcanberra-gtk3-0  0.30-3
ii  libcanberra00.30-3
ii  libdbus-1-3 1.10.10-1
ii  libdbus-glib-1-20.106-1
ii  libgdk-pixbuf2.0-0  2.34.0-1
ii  libglib2.0-02.49.6-1
ii  libgnome-keyring0   3.12.0-1+b1
ii  libgtk-3-0  3.21.5-3
ii  libmate-desktop-2-171.14.1-1
ii  libmate-panel-applet-4-11.14.2-1
ii  libnotify4  0.7.6-2
ii  libpango-1.0-0  1.40.2-1
ii  libpangocairo-1.0-0 1.40.2-1
ii  libstartup-notification00.12-4
ii  libunique-3.0-0 3.0.2-2
ii  libupower-glib3 0.99.4-3
ii  libx11-62:1.6.3-1
ii  libxext62:1.3.3-1
ii  libxrandr2  2:1.5.0-1
ii  libxrender1 1:0.9.9-2
ii  mate-notification-daemon [notification-daemon]  1.14.1-1
ii  mate-power-manager-common   1.14.0-2
ii  notification-daemon 3.20.0-1
ii  policykit-1 0.105-16
ii  systemd 231-4
ii  upower  0.99.4-3

mate-power-manager recommends no packages.

Versions of packages mate-power-manager suggests:
ii  mate-polkit  1.14.0-1

-- no debconf information

Bug#837611: ITP: uctodata -- Data for ucto tokeniser

[Maarten van Gompel]

Package: wnpp
Severity: wishlist
Owner: Maarten van Gompel <proy...@anaproy.nl>

* Package name: uctodata
  Upstream Author : Centre for Language and Speech Technology, Radboud 
University Nijmegen
* URL : https://languagemachines.github.io/ucto
* License : GPL-3
  Programming Lang: C++
  Description : Data for Unicode Tokenizer

 Ucto can tokenize UTF-8 encoded text files (i.e. separate words from
 punctuation, split sentences, generate n-grams), and  offers several other
 basic preprocessing steps that make your text suited for further processing 
 such as indexing, part-of-speech tagging, or machine translation.

 This package provides necessary language-specific datafiles for running Ucto.

 Ucto was written by Maarten van Gompel and Ko van der Sloot.  Work on Ucto
 was funded by NWO, the Netherlands Organisation for Scientific Research,
 under the Implicit Linguistics project, the CLARIN-NL program, and the 
 CLARIAH project.

 Ucto is a product of the Centre of Language and Speech Technology (Radboud
 University Nijmegen), and previously the ILK Research Group (Tilburg
 University, The Netherlands).



This is a split from package ucto, which previously contained the data as well.

--

Maarten van Gompel
Centre for Language Studies
Radboud Universiteit Nijmegen

proy...@anaproy.nl
http://proycon.anaproy.nl
http://github.com/proycon

GnuPG key:  0x1A31555C  XMPP: proy...@anaproy.nl
Telegram:   proycon IRC: proycon (freenode)
Twitter:https://twitter.com/proycon
Bitcoin:1BRptZsKQtqRGSZ5qKbX2azbfiygHxJPsd

Bug#813705: problem solved

[Maarten Tromp]

Hi,

After updating my whole system and a reboot, the problem is solved. 
Funny fact is that Awesome itself was not updated. It might have been an 
X issue.


Cheers,
Maarten
--
No trees were harmed in posting this message. However, a lot of 
electrons were terribly inconvenienced.

Bug#814250: ITP: colibri-core -- Colibri Core is a Natural Language Processing tool to quickly and efficiently count and extract patterns from large corpus data.

[Maarten van Gompel]

Package: wnpp
Severity: wishlist
Owner: proycon <proy...@anaproy.nl>

* Package name: colibri-core
  Version : 2.1.3
  Upstream Author : Maarten van Gompel <proy...@anaproy.nl>
* URL : https://proycon.github.io/colibri-core/
* License : GPL-3
  Programming Lang: C++, Python
  Description : Colibri Core is a Natural Language Processing tool and 
library to quickly and efficiently count and extract patterns from large corpus 
data.

Colibri Core is software consisting of command line tools as well as
programming libraries for C++ and Python to quickly and efficiently count and
extract patterns from large corpus data, to extract various statistics on the
extracted patterns, and to compute relations between the extracted patterns.

The employed notion of pattern or construction encompasses ngrams, skipgrams,
and flexgrams. Though, n-gram extraction may seem fairly trivial at first,
simple approachs place an unnecessarily high demand on memory resources, this
often becomes prohibitive if unleashed on large corpora. Colibri Core tries to
minimise these time & space requirements in several ways, and provides a
foundation for other tools to build on.

The package is to be maintained in the Debian Science packaging team. Hopefully
sponsored by Joost van Baal-Ilić? Extra help always welcome.

--

Maarten van Gompel
 Centre for Language Studies
 Radboud Universiteit Nijmegen

proy...@anaproy.nl
http://proycon.anaproy.nl
http://github.com/proycon

GnuPG key:  0x1A31555C  XMPP: proy...@anaproy.nl 
Telegram:   proycon IRC: proycon (freenode)
Twitter:https://twitter.com/proycon
Bitcoin:1BRptZsKQtqRGSZ5qKbX2azbfiygHxJPsd 


signature.asc
Description: signature

Bug#813705: awesome: statusbar does not always update

[Maarten Tromp]

Package: awesome
Version: 3.5.6-1
Severity: normal

Hi,

A while ago the "awesome" package was updated. Since the update there is a 
refresh problem with the bar on the top of the screen (wibox?). For instance, 
when I start another xterm, the bar is not updated, but when I move my mouse to 
another window the bar is immediately updated. Also, when I switch from a tag 
wich has windows in it to another tag which has windows, the bar is not 
updated, but when I switch to an empty tab or back then the bar is immediately 
updated.

Every 30 seconds or so the bar is updated anyway, but this might be the clock 
refreshing.

This problem happens both with the original lua config and with my own config.

Regards,
Maarten


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

Kernel: Linux 4.2.0-1-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)

Versions of packages awesome depends on:
ii  dbus-x11  1.10.6-1
ii  gir1.2-freedesktop1.46.0-3
ii  gir1.2-pango-1.0  1.38.1-1
ii  libc6 2.21-7
ii  libcairo2 1.14.6-1
ii  libdbus-1-3   1.10.6-1
ii  libgdk-pixbuf2.0-02.32.3-1
ii  libglib2.0-0  2.46.2-3
ii  liblua5.1-0   5.1.5-8
ii  libstartup-notification0  0.12-4
ii  libx11-6  2:1.6.3-1
ii  libxcb-cursor00.1.1-3
ii  libxcb-icccm4 0.4.1-1
ii  libxcb-keysyms1   0.4.0-1
ii  libxcb-randr0 1.11.1-1
ii  libxcb-render01.11.1-1
ii  libxcb-shape0 1.11.1-1
ii  libxcb-util0  0.3.8-3
ii  libxcb-xinerama0  1.11.1-1
ii  libxcb-xtest0 1.11.1-1
ii  libxcb1   1.11.1-1
ii  libxdg-basedir1   1.2.0-1
ii  lua-lgi   0.9.0.20151101.git.885af4-1
ii  menu  2.1.47

Versions of packages awesome recommends:
ii  feh2.14-1
ii  rlwrap 0.41-1+b1
ii  x11-xserver-utils  7.7+5

awesome suggests no packages.

-- no debconf information

Bug#810794: start-stop-daemon: daemons runnings inside lxc containers are seen as running on the host machine

[Maarten Tromp]

Package: dpkg
Version: 1.18.4
Severity: normal

Dear Maintainer,

On a server with LXC containers (virtual machines), there may be several copies 
of the same daemon running. For instance one inside a container and one on the 
host machine. This confuses start-stop-daemon. In my case this happened with 
samba running on both my host machine and inside a lxc container.

Start-stop-daemon does not take the containers into account. Using 
start-stop-daemon inside a container works fine, but when you try to start a 
daemon on the host machine when there already is a daemon with the same name 
running inside a container, start-stop-daemon sees the running daemon and 
doesn't start a new one.

The work-around I use is to stop samba inside the container, then start samba 
on the host machine, then start samba inside the container.

The bug occurs on a machine running Debian stable, amd64 multiarch
kernel: 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt9-3~deb8u1 (2015-04-24) x86_64 
GNU/Linux
dpkg version: 1.17.26
lxc version: 1.0.6

Regards,
Maarten Tromp

Bug#805720: ITP: python-clam - CLAM: Quickly turn command-line tools into RESTful webservices

[Maarten van Gompel]

Package: wnpp
Severity: wishlist

* Package name: python-clam
  Version:  0.99
  Upstream Author: Maarten van Gompel <proy...@anaproy.nl>
* URL: https://proycon.github.io/clam
  License: GPL-3
  Description: Quickly turn command-line tools into RESTful webservices with an 
auto-generated web interface for human end-users.

CLAM allows you to quickly and transparently transform your command line
application into a RESTful webservice, with which both human end-users as well
as automated clients can interact. CLAM takes a description of your system and
wraps itself around the system, allowing end-users or automated clients to
upload input files to your application, start your application with specific
parameters of their choice, and download and view the output of the application
once it is completed.

CLAM is set up in a universal fashion, requiring minimal effort on the part of
the service developer. Your actual application is treated as a black box,
of which only the parameters, input formats and output formats need to be
described. Your application itself needs not be network aware in any way, nor
aware of CLAM, and the handling and validation of input can be taken care of by
CLAM.

CLAM is entirely written in Python, runs on UNIX-derived systems, and is
available as open source under the GNU Public License (v3). It is set up in a
modular fashion, and offers an API, and as such is easily extendable. CLAM
communicates in a transparent XML format, and using XSL transformation offers a
full web 2.0 web-interface for human end users.

It is used frequently for Natural Language Processing applications.

--

Maarten van Gompel
 Centre for Language Studies
 Radboud Universiteit Nijmegen

proy...@anaproy.nl
http://proycon.anaproy.nl
http://github.com/proycon

GnuPG key:  0x1A31555C  XMPP: proy...@anaproy.nl 
Telegram:   proycon IRC: proycon (freenode)
Twitter:https://twitter.com/proycon
Bitcoin:1BRptZsKQtqRGSZ5qKbX2azbfiygHxJPsd 

Bug#771592: ITP: python-pynlpl -- Python Natural Language Processing Library

[Maarten van Gompel]

Package: wnpp
Severity: wishlist

* Package name: python-pynlpl
  Version:  0.7.6.11
  Upstream Author: Maarten van Gompel <proy...@anaproy.nl>
* URL: https://github.com/proycon/pynlpl
  License: GPL-3
  Description: PyNLPl, pronounced as ‘pineapple’, is a Python library for
  Natural Language Processing. It contains various modules useful for common,
  and less common, NLP tasks. PyNLPl can be used for basic tasks such as the
  extraction of n-grams and frequency lists, and to build simple language
  model. There are also more complex data types and algorithms. Moreover, there
  are parsers for file formats common in NLP (e.g.
  FoLiA/Giza/Moses/ARPA/Timbl/CQL). There are also clients to interface with
  various NLP specific servers. PyNLPl most notably features a very extensive
  library for working with FoLiA XML (Format for Linguistic Annotation).

--

Maarten van Gompel
 Centre for Language Studies
 Radboud Universiteit Nijmegen

proy...@anaproy.nl
http://proycon.anaproy.nl
http://github.com/proycon

GnuPG key:  0x1A31555C  XMPP: proy...@anaproy.nl 
Telegram:   proycon IRC: proycon (freenode)
Twitter:https://twitter.com/proycon
Bitcoin:1BRptZsKQtqRGSZ5qKbX2azbfiygHxJPsd 

Bug#791543: Installing python3-apt and python3-debian seems to solve #791543

[Maarten De Munck]

Hi,

I got the same error this morning when updating/upgrading my Debian
testing installation (using aptitude).

Installing the python3-apt package replaces the ImportError: No
module named 'apt' message by ImportError: No module named 'debian'.
Installing the python3-debian package and it dependencies solve that
error. So I suppose the debtags package should depend on (at least)
python3-apt and python3-debian too (or maybe python3-apt should depend
on python3-debian, but the packagers probably know how to solve this the
right way).

Best regards,

Maarten


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

Bug#722249: Man pages

[Maarten Baert]

Man pages are available upstream in the master branch but haven't been
released yet, because I don't have any new features that would warrant a
new release. But you can backport them if you want to have them
available right now. The command line options have not changed.

@Adrian: I did not realize that there were two separate packaging
attempts. I was aware of this one and thought that you were too. Sorry
for the confusion.

Maarten Baert


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

Bug#722249: help with debian packageing simplescreenrecorder

[Maarten Baert]

The text for the man pages can be taken from the --help output of both
simplescreenrecorder and ssr-glinject. There is a tool that can do this
automatically IIRC, but some reformatting may be needed. I can maintain
manpages upstream (which is probably desirable), but I have no
experience with creating them. I'll do some searching and try to come up
with something.

If there's anything else that I can do upstream to make packaging
easier, don't hesitate to let me know :).

Maarten Baert

On 10/03/15 19:26, Paul Elliott wrote:
 I have seen the ITP on simplescreenrecorder.
 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=722249

 I have decided to help out packaging this package.

 Whoever owns this bug and is working on this please clone:
 g...@github.com:pelliott80/simplescreenrecorder-dpm.git
 or
 https://github.com/pelliott80/simplescreenrecorder-dpm.git

 This is a packaging repository used for packaging. It
 is in dpm format.
 http://git-dpm.alioth.debian.org/

 This is the most common format for packaging work on alioth.

 packages in this format usually have at least 3 branches,
 upstream, pristine-tar, and master.

 upstream contains the upstream's source unmodified.
 pristine-tar is used to reconstruct a tarball.
 master is the files as modified for packaging
 there will be a debian directory and the source may
 be modified by any patches.

 here is the changelog entry I used to help get this package
 into Debian:

 simplescreenrecorder (0.3.3-2) unstable; urgency=medium

   * volunteer to help get it into Debian.
   * change to non-native package; native packages do not make it into Debian.
   * update standards version to 3.9.6
   * remove unneeded build dependency on build-essential
   * remove duplicate dependency in build depends, libxext-dev, libx11-dev,
   - libxfixes-dev
   * use correct format specification URI
   - https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
   * remove indefinite article from Description field
   * wrap too long line in Description field
   * remove empty debian/postinst
   * update copyright file
   * fix VCS fields
   - VCS fields should point to the source control for the packaging;
   - not the source control for the program.
   * create debian/watch file.

  -- Paul Elliott pelli...@blackpatchpanel.com  Sat, 07 Mar 2015 16:59:23 
 -0600

 here are the current results of lintian:
 P: simplescreenrecorder source: debian-watch-may-check-gpg-signature
 N: 
 N:This watch file does not include a means to verify the upstream tarball
 N:using cryptographic signature.
 N:
 N:If upstream distributions provide such signatures, please use the
 N:pgpsigurlmangle options in this watch file's opts= to generate the URL
 N:of an upstream GPG signature. This signature is automatically downloaded
 N:and verified against a keyring stored in
 N:debian/upstream-signing-key.asc.
 N:
 N:Of course, not all upstreams provide such signatures, but you could
 N:request them as a way of verifying that no third party has modified the
 N:code against their wishes after the release. Projects such as
 N:phpmyadmin, unrealircd, and proftpd have suffered from this kind of
 N:attack.
 N:
 N:Refer to the uscan(1) manual page for details.
 N:
 N:Severity: pedantic, Certainty: certain
 N:
 N:Check: watch-file, Type: source
 N: 
 W: simplescreenrecorder: binary-without-manpage usr/bin/simplescreenrecorder
 N: 
 N:Each binary in /usr/bin, /usr/sbin, /bin, /sbin or /usr/games should
 N:have a manual page
 N:
 N:Note that though the man program has the capability to check for several
 N:program names in the NAMES section, each of these programs should have
 N:its own manual page (a symbolic link to the appropriate manual page is
 N:sufficient) because other manual page viewers such as xman or tkman
 N:don't support this.
 N:
 N:If the name of the man page differs from the binary by case, man may be
 N:able to find it anyway; however, it is still best practice to make the
 N:case of the man page match the case of the binary.
 N:
 N:If the man pages are provided by another package on which this package
 N:depends, lintian may not be able to determine that man pages are
 N:available. In this case, after confirming that all binaries do have man
 N:pages after this package and its dependencies are installed, please add
 N:a lintian override.
 N:
 N:Refer to Debian Policy Manual section 12.1 (Manual pages) for details.
 N:
 N:Severity: normal, Certainty: possible
 N:
 N:Check: manpages, Type: binary
 N: 
 W: simplescreenrecorder: binary-without-manpage usr/bin/ssr-glinject

 I: Lintian run was successful.

 As I see it the outstanding issues on getting this package into
 Debian is the lack of manpages for ssr-glinject and simplescreenrecorder.

 Perhaps the upstream, Maarten Baert, could be persuaded to write those

Bug#722249: Man pages ready

[Maarten Baert]

Man pages are now included upstream, and will be included in the next
release (0.3.4). I don't have any new features right now that would
warrant a new release though, so you may want to include the man pages
as a patch for now, so you don't have to wait for them (the next release
could be months away).

Maarten Baert


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

Bug#779275: TAG: uberftp -- Interactive gridftp client

[Maarten Kooyman]

Package: wnpp
Severity: ITP


The source can be found at https://github.com/JasonAlt/UberFTP 
https://github.com/JasonAlt/UberFTP and licensed with the  University of 
Illinois/NCSA Open Source License .








smime.p7s
Description: S/MIME cryptographic signature

Bug#691902: Unable to shutdown Debian Wheezy via normal means

[Maarten Coenaerts]

Hi Joachim,

yes I did but it didn't help.
Although I have to say I also have a usb mouse and keyboard connected to 
the USB port.

I'm unable to unplug it because the pc is in a datacenter.


On 15/12/2014 6:45, Joachim Fahrner wrote:

Hi Maarten,

did you try uninstalling acpi-support-base?





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

Bug#691902: Unable to shutdown Debian Wheezy via normal means

[Maarten Coenaerts]

Dear,

I have the same problem on my debian wheezy system.
Tried with various kernels from kernel.org (3.12.15, 3.14.26, 3.18) all 
reboot the system instead of shutdown.

The only way to shutdown the system is via halt -fp
Motherboard is Gigabyte GA-990FXA-UD5 with AMD FX(tm)-6200 Six-Core 
Processor


Any news on this issue?

KR,
Maarten


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

Bug#758822: CPU autodetection bug on mipsel results in runtime bugs

[Maarten ter Huurne]

Package: openmsx
Version: 0.8.2-2.1

Little endian MIPS systems were autodetected as mips instead of mipsel, 
which means openMSX will be built for a big endian CPU. This leads to all 
kinds of runtime bugs, the most obvious of which is that all SHA1 sums for 
ROMs will mismatch from those in the hardware configs and software DB, 
meaning that system ROMs from the pool directory are not found and game ROMs 
don't run because the mapper type is unknown.

The bug is in openMSX itself, in the script build/detectsys.py. This is 
the commit in which I fixed the bug:

  http://sourceforge.net/p/openmsx/openmsx/ci/92fc9edb

This fix was made today and is not yet available in any released version of 
openMSX.

Instead of applying the fix, it is also possible to work around it by 
forcing the CPU type by passing OPENMSX_TARGET_CPU=mipsel to Make (only 
when building the mipsel arch, of course).

Bye,
Maarten


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

Bug#758822: Correction to workaround

[Maarten ter Huurne]

Sorry, I forgot to mention that if you pass OPENMSX_TARGET_CPU=mipsel to 
Make, you also have to pass OPENMSX_TARGET_OS=linux in order to bypass the 
broken autodetection.

Bye,
Maarten


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

Bug#741509: libdrm: please include exynos and freedreno DRM

[Maarten Lankhorst]

op 13-03-14 10:12, Fathi Boudra schreef:
 Source: libdrm
 Severity: wishlist

 Dear Maintainer,

 Exynos and freedreno DRM aren't enabled during libdrm build.
 Please could you enable Exynos and freedreno APIs?

 I packaged the X.Org driver side and only need libdrm support is missing
 now.

Do you have the packaged drivers somewhere? I should have a system to test 
freedreno soon, and I would be interested.

What about exynos, did you perform any testing on that? It should probably have 
a separate bug.

~Maarten


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

Bug#756021: ITP: xserver-xorg-video-freedreno - Xorg driver for freedreno

[Maarten Lankhorst]

Package: wnpp
Severity: wishlist
Owner: Maarten Lankhorst maarten.lankho...@ubuntu.com

* Package name: xserver-xorg-video-freedreno
  Version : 1.2.0
  Upstream Author : Rob Clark robdcl...@gmail.com
* URL : 
http://cgit.freedesktop.org/xorg/driver/xf86-video-freedreno/
* License : MIT/X
  Programming Lang: C
  Description : X.Org X server -- Open source support for MSM/QSD gpu's.

Long description:
---
 This package uses freedreno and libxatracker to provide acceleration.
 .
 More information about X.Org can be found at:
 URL:http://www.X.org
 .
 This package is built from the X.org xf86-video-freedreno driver module.
---

I have already built the package locally, derived from 
xserver-xorg-video-modesetting
packaging, but it depends on updated packaging for libdrm and mesa first.

~Maarten


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

Bug#755673: xserver-xorg-video-intel: Screen flickering with Xorg 1.16

[Maarten Lankhorst]

op 22-07-14 11:16, Bernhard Schmidt schreef:
 Package: xserver-xorg-video-intel
 Version: 2:2.99.912+git20140719-1~exp1
 Severity: normal

 Dear Maintainer,

 I have been a happy user of the experimental intel drivers because they
 fix a couple of annoyances for me. However since the upgrade of
 xserver-xorg to 2:1.15.99.904-1 I experience heavy flickering (Windows
 seems to switch between two versions of the window content).

 The problem is especially noticable in RDP sessions (Remmina) and in
 Thunderbird/Icedove. In Icedove's message list it behaves like a messed
 up scroll wheel.

 The problem can be observed in 2:2.99.912+git20140705-1~exp1+b1 and
 2:2.99.912+git20140719-1~exp1, downgrading to 2:2.21.15-2+b2 fixes the
 problem. I have been running the experimental drivers for a couple of
 weeks before Xorg 1.16 and cannot remember that issue.

 Best Regards,
 Bernhard

Smells like https://bugs.freedesktop.org/show_bug.cgi?id=81551

Can you give the patch there a try?

~Maarten


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

Bug#638869: Patch to version 1.0.28

[Maarten Bezemer]

Dear maintainer,

I have update the pydot package for Ubuntu, see 
https://bugs.launchpad.net/ubuntu/+source/pydot/+bug/987934 and was asked to 
send the patch to Debian as well.

Besides updating to the newest (1.0.28) version, I have updated the debian/* 
files as well to have them up-to-date again.

I have slightly modified my Ubuntu patch:
 * Refer to debian reports that are fixed by this update
 * Updated the Homepage field (per #719817)

Please consider applying the patch to the pydot package.
Best regards,
  Maarten

fix-638869.debdiff.gz
Description: application/gzip

Bug#735532: libanyevent-rabbitmq-perl: Invalid location of fixed_amqp0-9-1.xml

[Maarten van Schaik]

Package: libanyevent-rabbitmq-perl
Version: 1.15~dfsg-1
Severity: grave
Tags: patch
Justification: renders package unusable

Dear Maintainer,

The XML spec file that is used by AnyEvent::RabbitMQ seems to be in the wrong
location.

Because of licensing issues the original file is removed from the package, and
replaced by a symlink to a stripped version included in amqp-specs. The location
of the symlink differs from the expected location though.

To demonstrate the issue:

$ perl -MAnyEvent::RabbitMQ -e 'AnyEvent::RabbitMQ-new-load_xml_spec();'
Could not create file parser context for file 
/usr/share/perl5/auto/share/dist/AnyEvent-RabbitMQ/fixed_amqp0-9-1.xml: No 
such file or directory at /usr/share/perl5/Net/AMQP/Protocol.pm line 64.
(in cleanup) close already in progress at 
/usr/share/perl5/AnyEvent/RabbitMQ.pm line 612.

(This command is expected to give no output and no error.)

The symlink is located in a subdirectory 'share', which is not expected by the
library.

This patch fixes the issue for me:

diff --git a/debian/rules b/debian/rules
index 46cd581..a86c334 100755
--- a/debian/rules
+++ b/debian/rules
@@ -52,8 +52,8 @@ clean::
 # use separately packaged spec files
 DEB_DH_LINK_$(pkg) = \
  /usr/share/amqp/specs/0-9-1-rabbit/amqp0-9-1.stripped.extended.xml \
- /usr/share/perl5/auto/share/dist/AnyEvent-RabbitMQ/share/fixed_amqp0-9-1.xml
+ /usr/share/perl5/auto/share/dist/AnyEvent-RabbitMQ/fixed_amqp0-9-1.xml
 common-configure-arch common-configure-indep::
-   ln -sf 
/usr/share/amqp/specs/0-9-1-rabbit/amqp0-9-1.stripped.extended.xml 
share/fixed_amqp0-9-1.xml
+   ln -sf 
/usr/share/amqp/specs/0-9-1-rabbit/amqp0-9-1.stripped.extended.xml 
fixed_amqp0-9-1.xml
 clean::
-   rm -rf share/fixed_amqp0-9-1.xml
+   rm -rf fixed_amqp0-9-1.xml


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

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

Versions of packages libanyevent-rabbitmq-perl depends on:
ii  libanyevent-perl 7.070-1
ii  libdevel-globaldestruction-perl  0.12-1
ii  libfile-sharedir-perl1.03-1
ii  liblist-moreutils-perl   0.33-1+b2
ii  libnamespace-clean-perl  0.24-1
ii  libnet-amqp-perl 0.06~dfsg-1
ii  libreadonly-perl 1.04-1
ii  perl 5.18.1-5

Versions of packages libanyevent-rabbitmq-perl recommends:
ii  amqp-specs  1-0r0-2

libanyevent-rabbitmq-perl suggests no packages.

-- no debconf information


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