Bug#1073643: a patch to fix #1073643

[Georges Khaznadar]

Hello,

maybe the attached patch can help.

Best regards,   Georges.

-- 
Georges KHAZNADAR et Jocelyne FOURNIER
22 rue des mouettes, 59240 Dunkerque France.
Téléphone +33 (0)3 28 29 17 70

diff --git a/debian/changelog b/debian/changelog
index 87f3e95..80e7432 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+nilfs-tools (2.2.11-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * move files from /sbin to /usr/sbin. Closes: #1073643
+
+ -- Georges Khaznadar   Thu, 08 Aug 2024 10:21:14 +0200
+
 nilfs-tools (2.2.11-1) unstable; urgency=medium
 
   [ Debian Janitor ]
diff --git a/debian/rules b/debian/rules
index 4044ff8..ea672f2 100755
--- a/debian/rules
+++ b/debian/rules
@@ -16,3 +16,8 @@ override_dh_auto_install:
 
 	# removing unused files
 	rm -fv debian/nilfs-tools/usr/lib/*/*.la
+
+	# moving files from /sbin to /usr/sbin
+	mv debian/nilfs-tools/sbin/* debian/nilfs-tools/usr/sbin/
+	rmdir debian/nilfs-tools/sbin
+


signature.asc
Description: PGP signature

Bug#1077227: libcwiid1: Unintentionally libcwiid1t64 --> libcwiid1 changes ?

[Georges Khaznadar]

Hello Christian,

you are right: at some point I missed something.

The next step may be tougher for me: how can I withdraw the release 
0.6.91-8 from the NEW queue? Thank you in advance for any help.

I presume that changes done for the time_t transition in release
0.6.91-7.1 were not published in salsa, neither proposed as a pull
request for my repository, because my last push went smoothly.

I shall download sources of 0.6.91-7.1, and rebase my changes to comply
with gcc-14 on them.

Best regards,   Georges.

On Sat, 27 Jul 2024 07:38:59 +0200 Christian Marillat  
wrote:
> Package: libcwiid1
> Version: 0.6.91-8
> Severity: serious
> 
> Dear Maintainer,
> 
> Would be nice why the libcwiid1t64 has been renamed to libcwiid1
> whithouht a soname change.
> 
> Do you have forgot to include changes done for the time_t transition ?
> 
> ,
> | cwiid (0.6.91-7.1) unstable; urgency=medium
> | 
> |   * Non-maintainer upload.
> |   * Rename libraries for 64-bit time_t transition.  Closes: #1061995
> | 
> |  -- Michael Hudson-Doyle   Tue, 27 Feb 2024 23:25:09 
> +
> `
> 
> Christian
> 
> -- System Information:
> Debian Release: trixie/sid
>   APT prefers buildd-unstable
>   APT policy: (500, 'buildd-unstable'), (500, 'unstable')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
> 
> Kernel: Linux 6.9.11-1-custom (SMP w/24 CPU threads; PREEMPT)
> Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
> Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.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 libcwiid1 depends on:
> ii  libbluetooth3  5.73-1
> ii  libc6  2.39-6
> 
> libcwiid1 recommends no packages.
> 
> libcwiid1 suggests no packages.
> 
> -- no debconf information
> 
> 

-- 
Georges KHAZNADAR et Jocelyne FOURNIER
22 rue des mouettes, 59240 Dunkerque France.
Téléphone +33 (0)3 28 29 17 70



signature.asc
Description: PGP signature

Bug#1071738: pysatellites: segfault on arm64 with scipy 1.12

[Georges Khaznadar]

Hello Drew,

thank you for your report.

I shall push a dirty workaround: the file debian/tests/test_gui.py will
call scipy to compute the difference between two screenshots only when
platform.machine() == 'x86_64'.

The test is skipped on arm64, ppc64el and s390x and some other
architectures.

Should I propose a new test for maintainers of scipy? I suppose that
computing the difference between two arrays should be portable. 

Best regards,   Georges.

On Tue, 04 Jun 2024 16:17:02 +0200 Drew Parsons  wrote:
> Source: pysatellites
> Version: 2.7-2
> Followup-For: Bug #1071738
> Control: severity 1071738 serious
> 
> The error is persistent after uploading scipy 1.12 to unstable,
> so bumping severity to serious.
> 
> ppc64el and s390x are also affected.
> 
> 

-- 
Georges KHAZNADAR et Jocelyne FOURNIER
22 rue des mouettes, 59240 Dunkerque France.
Téléphone +33 (0)3 28 29 17 70



signature.asc
Description: PGP signature

Bug#1063864: src:mediawiki2latex: fails to migrate to testing for too long: not installable on armel, mips64el and s390x

[Georges Khaznadar]

Dirk Hünniger a écrit :
> chromium-sandbox [!armel !mips64el !s390x],

Done.

Best regards,   Georges.



signature.asc
Description: PGP signature

Bug#1064037: uploaded the fixed package to DELAYED+10

[Georges Khaznadar]

Hello, I uploaded xhtml2pdf_0.2.5-3.1_source.changes to delayed+10
today, and the modifications to Salsa's repository.

Best regards,   Georges.

-- 
Georges KHAZNADAR et Jocelyne FOURNIER
22 rue des mouettes, 59240 Dunkerque France.
Téléphone +33 (0)3 28 29 17 70



signature.asc
Description: PGP signature

Bug#1064037: xhtml2pdf: the new version of python-reportlab breaks xhtml2pdf/context.py

[Georges Khaznadar]

Source: xhtml2pdf
Version: 0.2.5-3
Severity: serious
Tags: patch upstream

Dear Maintainer,

since python-reportlab 4.0.1-1, xhtml2pdf cannot pass automatic tests:
see for example,
https://ci.debian.net/packages/x/xhtml2pdf/testing/amd64/43022906/
at line 480,
 from reportlab.platypus.frames import Frame, ShowBoundaryValue
 E   ImportError: cannot import name 'ShowBoundaryValue' from
'reportlab.platypus.frames' (/usr/lib/python3/dist-
packages/reportlab/platypus/frames.py)

I patched the file xhtml2pdf/context.py to fix this error.

Best regards,  Georges.


-- System Information:
Debian Release: trixie/sid
  APT prefers stable
  APT policy: (700, 'stable'), (650, 'testing'), (500, 'stable-updates'), (500, 
'stable-security'), (500, 'oldstable-updates'), (500, 'oldstable-security'), 
(500, 'oldoldstable'), (500, 'unstable'), (500, 'oldstable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.19.0-25-amd64 (SMP w/4 CPU threads)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.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
Beginning with python3-reporlab version 4.1.0, ShowBoundaryValue is no longer 
part
of reportlab.platypus.frames, but part of reportlab.pdfgen.canvas

Index: xhtml2pdf/xhtml2pdf/context.py
===
--- xhtml2pdf.orig/xhtml2pdf/context.py
+++ xhtml2pdf/xhtml2pdf/context.py
@@ -15,7 +15,8 @@ from reportlab.lib.pagesizes import A4
 from reportlab.lib.styles import ParagraphStyle
 from reportlab.pdfbase import pdfmetrics
 from reportlab.pdfbase.ttfonts import TTFont
-from reportlab.platypus.frames import Frame, ShowBoundaryValue
+from reportlab.platypus.frames import Frame
+from reportlab.pdfgen.canvas import ShowBoundaryValue
 from reportlab.platypus.paraparser import ParaFrag, ps2tt, tt2ps
 from xhtml2pdf.util import (copy_attrs, getColor, getCoords, getFile,
 getFrameDimensions, getSize, pisaFileObject,

Bug#1063864: src:mediawiki2latex: fails to migrate to testing for too long: not installable on armel, mips64el and s390x

[Georges Khaznadar]

Hello Paul, Dirk,

Dirk Hünniger a écrit :
> https://qa.debian.org/excuses.php?package=mediawiki2latex
> says:
> 
> Issues preventing migration:
> 
>  * mediawiki2latex/armel has unsatisfiable dependency
>  * mediawiki2latex/mips64el has unsatisfiable dependency
>  * mediawiki2latex/s390x has unsatisfiable dependency

At the same time, https://buildd.debian.org/status/package.php?p=mediawiki2latex
says that the package could be installed, so its runtime dependencies
are correct, on architectures: amd64, arm64, armel, armhf, i386, mips64el,
ppc64el, riscv64, s390x, alpha, hurd-i386, ia64, ppc64, sparc64.

I have no precise idea about this misbehavior, unfortunately.
However the excuses page tells that the package is 5 days old (needing 5
days), maybe we should wait 24 hours longer ?

If the migrations keeps failing, I can make some trivial change and make
another source upload.

Best regards,   Georges.



signature.asc
Description: PGP signature

Bug#1061155: cron: "crontab -e" does not report "unsafe" mail and so job output can be lost

[Georges Khaznadar]

Hello,

Thank you for your bug report.

I shall lower the severity of your bug report, since it 
"causes non-serious data loss"

a...@example.org would be parsed as a valid e-mail address if one uses
regexp matching.

What improvement would you suggest? Should "crontab -e" send an e-mail
to recipients stated by MAILTO and wait for a reply?

Best regards,   Georges.

On Fri, 19 Jan 2024 18:06:52 + Jonathan H N Chin  wrote:
> Package: cron
> Version: 3.0pl1-182
> Severity: grave
> Justification: causes non-serious data loss
> 
> Dear Maintainer,
> 
> 
>* What led up to the situation?
> 
> 1. A user ran "crontab -e"
> 
> 2. He added the line (note the space):
> 
> MAILTO=a...@example.org, b...@example.com
> 
> 
> 3. He saved and exited
> 
> 4. No errors were reported to the user.
> 
> 
>* What was the outcome of this action?
> 
> Subsequently, jobs ran but output was discarded.
> 
> /var/log/syslog contains "UNSAFE MAIL" messages which the user cannot see.
> 
> 
>* What outcome did you expect instead?
> 
> At step 4, crontab should have reported an error to the user
> and not applied the update.
> 
> 
> 
> -- System Information:
> Debian Release: trixie/sid
>   APT prefers unstable
>   APT policy: (500, 'unstable'), (1, 'experimental')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 5.15.0-91-generic (SMP w/1 CPU thread)
> Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
> Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> 
> Versions of packages cron depends on:
> ii  cron-daemon-common   3.0pl1-182
> ii  init-system-helpers  1.66
> ii  libc62.37-13
> ii  libpam-runtime   1.5.2-9.1
> ii  libpam0g 1.5.2-9.1+b1
> ii  libselinux1  3.5-1+b2
> ii  sensible-utils   0.0.20
> 
> Versions of packages cron recommends:
> ii  exim4-daemon-heavy [mail-transport-agent]  4.97-4+b1
> 

-- 
Georges KHAZNADAR et Jocelyne FOURNIER
22 rue des mouettes, 59240 Dunkerque France.
Téléphone +33 (0)3 28 29 17 70



signature.asc
Description: PGP signature

Bug#1059829: Thank you

[Georges Khaznadar]

Hello,

Javascript/Npm are not my cup of tea; so, please receive many thanks
about the help you provided to my poor packaging efforts.

If node-html5-qrcode happens to be dfsg-free, which should be the right
umbrella to host it on salsa.d.o? https://salsa.debian.org/js-team or
https://salsa.debian.org/georgesk ?

I saw that you managed to let salsa's automaton pass 53 of the upstream
tests, and I would like to learn such magics. Please have you some
useful links about them?

Best regards,   Georges.

-- 
Georges KHAZNADAR et Jocelyne FOURNIER
22 rue des mouettes, 59240 Dunkerque France.
Téléphone +33 (0)3 28 29 17 70



signature.asc
Description: PGP signature

Bug#1060458: uploaded release 804.036+dfsg1-2

[Georges Khaznadar]

Hi,

I just uploaded a new release, with your changes included.

Best regards,   Georges.

-- 
Georges KHAZNADAR et Jocelyne FOURNIER
22 rue des mouettes, 59240 Dunkerque France.
Téléphone +33 (0)3 28 29 17 70



signature.asc
Description: PGP signature

Bug#1034751: python-xmlschema: accesses internet during build

[Georges Khaznadar]

Hi,

thank you for the bug report.

Instead of executing some python tests conditionnally, I shall patch
them to prevent their execution, independently from the network's
availability.

Best regards,   Georges.

-- 
Georges KHAZNADAR et Jocelyne FOURNIER
22 rue des mouettes, 59240 Dunkerque France.
Téléphone +33 (0)3 28 29 17 70



signature.asc
Description: PGP signature

Bug#1024557: python3-branca: __version__ "unknown" breaks folium

[Georges Khaznadar]

Thank you for the patch, Nilesh!

I am uploading the fixed package.

Best regards,   Georges.

Nilesh Patra a écrit :
> Control: tags -1 patch
> 
> Hi,
> 
> The fix is just a one-liner. If you do not fix it in next seven days,
> I will NMU it.
> (I prefer not going the delayed queue route)
> 
> diff --git a/debian/control b/debian/control
> index 7eff938..fce9cfa 100644
> --- a/debian/control
> +++ b/debian/control
> @@ -6,6 +6,7 @@ Build-Depends: debhelper-compat (= 13),
>   dh-python,
>   python3,
>   python3-setuptools,
> + python3-setuptools-scm,
>   python3-jinja2,
>   python3-six
>  X-Python3-Version: >= 3.7
> 
> -- 
> Best,
> Nilesh



-- 
Georges KHAZNADAR et Jocelyne FOURNIER
22 rue des mouettes, 59240 Dunkerque France.
Téléphone +33 (0)3 28 29 17 70



signature.asc
Description: PGP signature

Bug#1009010: fix remaining bugs

[Georges Khaznadar]

Hello, please find as an attachment a patch to fix #1012190 and #981703
and close them.

Best regards,   Georges.

tags 1012190 + patch
thank you

-- 
Georges KHAZNADAR et Jocelyne FOURNIER
22 rue des mouettes, 59240 Dunkerque France.
Téléphone +33 (0)3 28 29 17 70

diff --git a/debian/changelog b/debian/changelog
index f5795bd..2c59b7e 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,18 @@
+slop (7.6-2.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * added a file d/libslop7.6.shlibs; #closes: #1012190
+  * modified d/control
++ now libslop7.6 conflicts with libslop7.5 and replaces it
++ added a strict dependency libdevel =>
+  libslopy7.6(>= ${source:Version}), libslopy7.6(<= ${source:Version}.1~)
+  * applied GSR's patch; closes: #981703
+  * modified d/rules to clean out bin/slop
+  * checked that the last release of maim can be built with this release of
+libslop7.6 and run seamlessly
+
+ -- Georges Khaznadar   Fri, 24 Jun 2022 15:38:33 +0200
+
 slop (7.6-2) experimental; urgency=medium
 
   * split out shared library in new binary packages (Closes: #1009010)
diff --git a/debian/control b/debian/control
index 42c61ce..8e6487b 100644
--- a/debian/control
+++ b/debian/control
@@ -51,6 +51,8 @@ Description: queries for a selection from the user and prints the region to stdo
   * Supports a magnifying glass.
 
 Package: libslopy7.6
+Conflicts:  libslopy7.5
+Replaces: libslopy7.5
 Architecture: any
 Depends: ${shlibs:Depends}, ${misc:Depends}
 Description: queries for a selection from the user and prints the region to stdout
@@ -65,7 +67,8 @@ Description: queries for a selection from the user and prints the region to stdo
 Package: libslopy-dev
 Section: libdevel
 Architecture: any
-Depends: ${shlibs:Depends}, ${misc:Depends}
+Depends: ${misc:Depends},
+ libslopy7.6(>= ${source:Version}), libslopy7.6(<= ${source:Version}.1~)
 Description: queries for a selection from the user and prints the region to stdout
  slop (Select Operation) is an application that queries for a
  selection from the user and prints the region to stdout. It grabs the
diff --git a/debian/libslopy7.6.shlibs b/debian/libslopy7.6.shlibs
new file mode 100644
index 000..05db7f3
--- /dev/null
+++ b/debian/libslopy7.6.shlibs
@@ -0,0 +1 @@
+libslopy 7.6 libslopy7.6
diff --git a/debian/patches/fix981703.patch b/debian/patches/fix981703.patch
new file mode 100644
index 000..c18e853
--- /dev/null
+++ b/debian/patches/fix981703.patch
@@ -0,0 +1,16 @@
+fix 981703: slop: Improve man page for better apropos results
+Index: slop/slop.1
+===
+--- slop.orig/slop.1
 slop/slop.1
+@@ -1,8 +1,8 @@
+ .\" Manpage for slop.
+ .\" Contact naelst...@gmail.com to correct errors or typos.
+-.TH SLOP 1 2017-03-21 Linux "slop man page"
++.TH SLOP 1 2021-02-03 Linux "slop man page"
+ .SH NAME
+-slop \- select operation
++slop \- select operation, either mark screen region or pick window
+ .SH SYNOPSIS
+ slop [-klqn] [OPTIONS]
+ .SH DESCRIPTION
diff --git a/debian/patches/series b/debian/patches/series
index 8c97052..fef7054 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -1 +1,2 @@
 fix994824.patch
+fix981703.patch
diff --git a/debian/rules b/debian/rules
index bb2a2a9..61fae45 100755
--- a/debian/rules
+++ b/debian/rules
@@ -20,3 +20,8 @@ export DEB_LDFLAGS_MAINT_APPEND = -Wl,--as-needed
 # main packaging script based on dh7 syntax
 %:
 	dh $@
+
+override_dh_auto_clean:
+	dh_auto_clean
+	# remove a binary file not cleaned by the Makefile
+	rm -f bin/slop


signature.asc
Description: PGP signature

Bug#976439: wminput: Aborts with "undefined symbol: PyVarObject_CallFunction"

[Georges Khaznadar]

Hallo Bernd,

many thanks for your MR! this is a great job.

Best regards,   Georges.

Bernd Zeimetz a écrit :
> 
> 
> Hi,
> 
> with this MR applied, it does not crash at least.
> https://salsa.debian.org/georgesk/cwiid/-/merge_requests/1
> 
> Not tested yet.
> 
> Bernd
> 
> -- 
>  Bernd ZeimetzDebian GNU/Linux Developer
>  http://bzed.dehttp://www.debian.org
>  GPG Fingerprint: ECA1 E3F2 8E11 2432 D485  DD95 EB36 171A 6FF9 435F

-- 
Georges KHAZNADAR et Jocelyne FOURNIER
22 rue des mouettes, 59240 Dunkerque France.
Téléphone +33 (0)3 28 29 17 70



signature.asc
Description: PGP signature

Bug#1010921: kodi FTBFS due to outdated shlibs

[Georges Khaznadar]

Dear Vasyl,

many thanks for your debdiff! I rebuilt the package and uploaded it in
binary form, as it is NEW currently.

Best regards,   Georges.

Vasyl Gello a écrit :
> Source: waylandpp
> Version: 1.0.0-1
> Severity: important
> Tags: ftbfs patch
> X-Debbugs-Cc: vasek.ge...@gmail.com
> 
> Dear Maintainer,
> 
> Recent upload of new waylandpp 1.0.0 broke kodi build
> with "dpkg-shlibdeps: can not find dependency info..."
> error message.
> 
> I took the responsibility to bump ABI versions in d/control
> and fix the shlibs so they are now ++1 rather than ++0.
> 
> Kodi builds and runs fine with it.
> 
> I have attached the debdiff for your convenience.
> 
> Sincerely,
> Vasyl
> 
> -- System Information:
> Debian Release: bookworm/sid
>   APT prefers testing
>   APT policy: (500, 'testing')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 5.10.0-7-amd64 (SMP w/32 CPU threads)
> Locale: LANG=C, LC_CTYPE=C (charmap=UTF-8) (ignored: LC_ALL set to 
> en_US.UTF-8), LANGUAGE not set
> Shell: /bin/sh linked to /usr/bin/dash
> Init: unable to detect



-- 
Georges KHAZNADAR et Jocelyne FOURNIER
22 rue des mouettes, 59240 Dunkerque France.
Téléphone +33 (0)3 28 29 17 70



signature.asc
Description: PGP signature

Bug#1009598: reassigned this bug to node-postcss-loader

[Georges Khaznadar]

Hello,

the errors raised during the build of node-ktex are due to an error
which comes from node-postcss-loader

for instance :
-8<
> ERROR in ./contrib/copy-tex/copy-tex.css 
> (/usr/share/nodejs/css-loader/dist/cjs.js??ref--5-1!/usr/share/nodejs/postcss-loader/dist/cjs.js??ref--5-2!./contrib/copy-tex/copy-tex.css)
> Module build failed (from 
> /usr/share/nodejs/postcss-loader/dist/cjs.js):
> TypeError: this.getOptions is not a function
> at Object.loader 
> (/usr/share/nodejs/postcss-loader/dist/index.js:40:24)
-8<

so I reassign this bug report to node-postcss-loader

best regards,       Georges.


-- 
Georges KHAZNADAR et Jocelyne FOURNIER
22 rue des mouettes, 59240 Dunkerque France.
Téléphone +33 (0)3 28 29 17 70



signature.asc
Description: PGP signature

Bug#1010215: closed by Georges Khaznadar (The new NMUed release is uploaded ...)

[Georges Khaznadar]

Hello Paul,

I fixed the issue about python3-numba, and the recently uploaded package
(release 0.3.0-2.3) is OK to enter testing.

I made a push request in salsa: 
https://salsa.debian.org/debian-astro-team/einsteinpy/-/merge_requests/4

Best regards,   Georges.



signature.asc
Description: PGP signature

Bug#1010215: closed by Georges Khaznadar (The new NMUed release is uploaded ...)

[Georges Khaznadar]

Hello Paul,

I think that I found the clue: Python3.10 interprets the following lines
-8<--- file src/einsteinpy.egg-info/requires.txt 
[:implementation_name == "cpython"]
numba!=0.49.0,>=0.46
-8<--

no exactly as Python3.9 did, and the result of ${python3:Depends} includes
python3-numba as a consequence.

So I shall test another modification: wiring the Python3 dependencies,
and declaring python3-numba as a recommendation.

Best regards,   Georges.

Paul Gevers a écrit :
> Hi,
> 
> [Why not in the bug report? Feel free to quote me.]
> 
> On 07-05-2022 15:44, Georges Khaznadar wrote:
> > Paul Gevers a écrit :
> > > Where are you seeing this? I only see failures:
> > > https://ci.debian.net/packages/e/einsteinpy/
> > 
> > The tests are still failing for Salsa/CI; however the bug 1010215 was
> > different: it was genuinely due to the wrong usage of the symbol np
> > (defined after "import numpy as np"), instead of the string "numpy".
> > This parameter finishes by reaching sympy.lamdify, and the current
> > version of sympy does no longer tolerate this wrong usage.
> > 
> > Please take a look at the begin of Bug#1010215's report for more 
> > information.
> > 
> > I took the freedom to patch einsteinpy's test syntax because sympy was
> > marked for AUTORM if nothing was done for a few weeks.
> > 
> > Besides, you are true: now, the failed tests report a broken dependency
> > on python-numba3, which is not yet compiled with/for Python3.10.
> 
> Your NMU einsteinpy grew a *new* dependency on python3-numba, which has RC
> bug 1000336 for a while already, so don't expect it to migrate. Hence, your
> fix can't migrate to testing as-is.
> 
> Paul




-- 
Georges KHAZNADAR et Jocelyne FOURNIER
22 rue des mouettes, 59240 Dunkerque France.
Téléphone +33 (0)3 28 29 17 70



signature.asc
Description: PGP signature

Bug#1010215: closed by Georges Khaznadar (The new NMUed release is uploaded ...)

[Georges Khaznadar]

Hello Paul,
Paul Gevers a écrit :
> Hi,
> 
> [Why not in the bug report? Feel free to quote me.]

Fixed: This e-mail is Cc-ed to 1010...@bugs.debian.org; I did not pay
attention to the Reply-To: field in the previous e-mail which was missing
1010...@bugs.debian.org

> 
> On 07-05-2022 15:44, Georges Khaznadar wrote:
> > Paul Gevers a écrit :
> > > Where are you seeing this? I only see failures:
> > > https://ci.debian.net/packages/e/einsteinpy/
> > 
> > The tests are still failing for Salsa/CI; however the bug 1010215 was
> > different: it was genuinely due to the wrong usage of the symbol np
> > (defined after "import numpy as np"), instead of the string "numpy".
> > This parameter finishes by reaching sympy.lamdify, and the current
> > version of sympy does no longer tolerate this wrong usage.
> > 
> > Please take a look at the begin of Bug#1010215's report for more 
> > information.
> > 
> > I took the freedom to patch einsteinpy's test syntax because sympy was
> > marked for AUTORM if nothing was done for a few weeks.
> > 
> > Besides, you are true: now, the failed tests report a broken dependency
> > on python-numba3, which is not yet compiled with/for Python3.10.
> 
> Your NMU einsteinpy grew a *new* dependency on python3-numba, which has RC
> bug 1000336 for a while already, so don't expect it to migrate. Hence, your
> fix can't migrate to testing as-is.

Please accept my apologies: I accidentally modified the file 
src/einsteinpy.egg-info/requires.txt, and did not check thouroughly the
patch's content.

Now I reversed the modification, and I shall wait for the feedback of
salsa/CI to decide whether my changes can be accepted.

-- 
Georges KHAZNADAR et Jocelyne FOURNIER
22 rue des mouettes, 59240 Dunkerque France.
Téléphone +33 (0)3 28 29 17 70



signature.asc
Description: PGP signature

Bug#1010215: fixed the bug.

[Georges Khaznadar]

The tiny changes are in a push request at salsa.debian.org

I apologize: I forgot the "--delayed 10" option when I made the NMU.
The new version of the package (revision 0.3.0-2.1) has been built
properly: https://buildd.debian.org/status/package.php?p=einsteinpy

Best regards,   Georges.

-- 
Georges KHAZNADAR et Jocelyne FOURNIER
22 rue des mouettes, 59240 Dunkerque France.
Téléphone +33 (0)3 28 29 17 70



signature.asc
Description: PGP signature

Bug#1007824: chemeq: autopkgtest failure on i386 (but no information)

[Georges Khaznadar]

Dear Paul,

thank you for the bug report! I was aware of the failure, yet, as
Salsa's CI automaton forwards me the test results.

I have currently few time to fix that issue, but as the binaries
produced by the new source package are the same, the problem is not so
important. I shall work out a fix next month.

So far, nobody reported a bug about the i386 binary package, I assume
that the feature which works incorrectly is seldom used.

Best regards,   Georges.

Paul Gevers a écrit :
> Source: chemeq
> Version: 2.22-2
> Severity: serious
> User: debian...@lists.debian.org
> Usertags: fails-always
> 
> Dear maintainer(s),
> 
> You recently added an autopkgtest to your package chemeq, great. However, it
> fails on i386. Currently this failure is blocking the migration to testing
> [1]. Can you please investigate the situation and fix it?
> 
> I copied all of the output of the test itself at the bottom of this report.
> There's nothing to see though.
> 
> 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=chemeq
> 
> https://ci.debian.net/data/autopkgtest/testing/i386/c/chemeq/19841417/log.gz
> 
> autopkgtest [21:09:59]: test command1
> 




-- 
Georges KHAZNADAR et Jocelyne FOURNIER
22 rue des mouettes, 59240 Dunkerque France.
Téléphone +33 (0)3 28 29 17 70



signature.asc
Description: PGP signature

Bug#990026: Aaargh!

[Georges Khaznadar]

Hello Christian,

Uploading to ftp-master [DELAYED/3] ... done.

Best regards,   Georges.

Christian Kastner a écrit :
> On 2022-03-08 21:58, Christian Kastner wrote:
> > I'll upload an NMU.
> 
> Ah, pulling the newest source from Salsa, I saw Georges' @debian.org
> address. Apologies!
> 
> In that case, please NMU it yourself (as you've already prepared the
> changelog).
> 
> Best,
> Christian

-- 
Georges KHAZNADAR et Jocelyne FOURNIER
22 rue des mouettes, 59240 Dunkerque France.
Téléphone +33 (0)3 28 29 17 70



signature.asc
Description: PGP signature

Bug#1000230: works, but with error messages

[Georges Khaznadar]

RITICAL **: 
> gdk_pixbuf_get_from_surface: assertion 'surface != NULL' failed from 
> /usr/share/screenruler/ruler_window.rb:275 Gdk-CRITICAL **: 
> gdk_pixbuf_get_from_surface: assertion 'surface != NULL' failed from 
> /usr/share/screenruler/ruler_window.rb:275 Gdk-CRITICAL **: 
> gdk_pixbuf_get_from_surface: assertion 'surface != NULL' failed from 
> /usr/share/screenruler/ruler_window.rb:275 Gdk-CRITICAL **: 
> gdk_pixbuf_get_from_surface: assertion 'surface != NULL' failed from 
> /usr/lib/ruby/2.7.0/delegate.rb:343 Gdk-CRITICAL **: 
> gdk_pixbuf_get_from_surface: assertion 'surface != NULL' failed from 
> /usr/lib/ruby/2.7.0/delegate.rb:343 Gdk-CRITICAL **: 
> gdk_pixbuf_get_from_surface: assertion 'surface != NULL' failed from 
> /usr/lib/ruby/2.7.0/delegate.rb:343 Gdk-CRITICAL **: 
> gdk_pixbuf_get_from_surface: assertion 'surface != NULL' failed from 
> /usr/lib/ruby/2.7.0/delegate.rb:343 Gdk-CRITICAL **: 
> gdk_pixbuf_get_from_surface: assertion 'surface != NULL' failed from 
> /usr/share/screenruler/ruler_window.rb:275 Gdk-CRITICAL **: 
> gdk_pixbuf_get_from_surface: assertion 'surface != NULL' failed from 
> /usr/share/screenruler/ruler_window.rb:275 Gdk-CRITICAL **: 
> gdk_pixbuf_get_from_surface: assertion 'surface != NULL' failed from 
> /usr/share/screenruler/ruler_window.rb:275 Gdk-CRITICAL **: 
> gdk_pixbuf_get_from_surface: assertion 'surface != NULL' failed from 
> /usr/share/screenruler/ruler_window.rb:275 Gdk-CRITICAL **: 
> gdk_pixbuf_get_from_surface: assertion 'surface != NULL' failed from 
> /usr/share/screenruler/ruler_window.rb:275 Gdk-CRITICAL **: 
> gdk_pixbuf_get_from_surface: assertion 'surface != NULL' failed from 
> /usr/share/screenruler/ruler_window.rb:275 Gdk-CRITICAL **: 
> gdk_pixbuf_get_from_surface: assertion 'surface != NULL' failed from 
> /usr/share/screenruler/ruler_window.rb:275 Gdk-CRITICAL **: 
> gdk_pixbuf_get_from_surface: assertion 'surface != NULL' failed from 
> /usr/share/screenruler/ruler_window.rb:275 Gdk-CRITICAL **: 
> gdk_pixbuf_get_from_surface: assertion 'surface != NULL' failed from 
> /usr/lib/ruby/vendor_ruby/gobject-introspection/loader.rb:600 Gdk-CRITICAL 
> **: gdk_pixbuf_get_from_surface: assertion 'surface != NULL' failed from 
> /usr/lib/ruby/vendor_ruby/gobject-introspection/loader.rb:600 Gdk-CRITICAL 
> **: gdk_pixbuf_get_from_surface: assertion 'surface != NULL' failed from 
> /usr/lib/ruby/vendor_ruby/gobject-introspection/loader.rb:600 Gdk-CRITICAL 
> **: gdk_pixbuf_get_from_surface: assertion 'surface != NULL' failed from 
> /usr/lib/ruby/vendor_ruby/gobject-introspection/loader.rb:600 Gdk-CRITICAL 
> **: gdk_pixbuf_get_from_surface: assertion 'surface != NULL' failed from 
> /usr/lib/ruby/2.7.0/delegate.rb:343 Gdk-CRITICAL **: 
> gdk_pixbuf_get_from_surface: assertion 'surface != NULL' failed from 
> /usr/lib/ruby/2.7.0/delegate.rb:343 Gdk-CRITICAL **: 
> gdk_pixbuf_get_from_surface: assertion 'surface != NULL' failed from 
> /usr/lib/ruby/2.7.0/delegate.rb:343 Gdk-CRITICAL **: 
> gdk_pixbuf_get_from_surface: assertion 'surface != NULL' failed from 
> /usr/lib/ruby/2.7.0/delegate.rb:343 Gdk-CRITICAL **: 
> gdk_pixbuf_get_from_surface: assertion 'surface != NULL' failed from 
> /usr/lib/ruby/vendor_ruby/gobject-introspection/loader.rb:674 Gdk-CRITICAL 
> **: gdk_pixbuf_get_from_surface: assertion 'surface != NULL' failed from 
> /usr/lib/ruby/vendor_ruby/gobject-introspection/loader.rb:674 Gdk-CRITICAL 
> **: gdk_pixbuf_get_from_surface: assertion 'surface != NULL' failed from 
> /usr/lib/ruby/vendor_ruby/gobject-introspection/loader.rb:674 Gdk-CRITICAL 
> **: gdk_pixbuf_get_from_surface: assertion 'surface != NULL' failed from 
> /usr/lib/ruby/vendor_ruby/gobject-introspection/loader.rb:674
> After that, I was unable to get genuinely newer messages, only the copies of 
> the above, in some order in blocks of 4.
> 2. A second-mouse-button click on the screenruler to call its menu does call 
> the menu but prints the following to the console :
> Gdk-Message: 14:19:12.255: Window 0x558616afc850 is a temporary window 
> without parent, application will not be able to position it on screen. 
> Gdk-CRITICAL **: gdk_wayland_window_handle_configure_popup: assertion 
> 'impl->transient_for' failed from 
> /usr/lib/ruby/vendor_ruby/gobject-introspection/loader.rb:598:in `invoke' 
> from /usr/lib/ruby/vendor_ruby/gobject-introspection/loader.rb:103:in `block 
> in define_singleton_method' from ./screenruler.rb:91:in `'
> Since the errors are marked as CRITICAL, I presume that something wrong goes 
> there.
> Thanks in advance for looking into it,
> Peter

-- 
Georges KHAZNADAR et Jocelyne FOURNIER
22 rue des mouettes, 59240 Dunkerque France.
Téléphone +33 (0)3 28 29 17 70



signature.asc
Description: PGP signature

Bug#998999: tix: missing required debian/rules targets build-arch and/or build-indep

[Georges Khaznadar]

Dear Ole, thank you for your work!

I shall upload the new package shortly, with some enhancements among
your propositions, see below:

Ole Streicher a écrit :
> Control: tags -1 + patch
> 
> Dear maintainer,
> 
> I have a package (ftools-fv) that depends on tix, which is scheduled for
> autoremoval on 2021/02/08. To avoid this, I prepared an NMU, which I am
> going to upload to DELAYED/7. This NMU just fixed this one issue (debdiff
> attached).
> 
> When looking into the package, I would recommend a few more small steps:
> 
>  * simplify d/rules using debhelper,
 not done currently

>  * put the package under tcltk team maintainance
 if you are part of the tcltk team maintainance, please feel free to
 move the package to the right section of salsa.debian.org

>  * create a repository on Salsa to help maintaining it
 the repository is created at https://salsa.debian.org/georgesk/tix,
 and the package is up to date there, in version 8.4.3-11
 The file debian/changelog bears a few other notifications.

Best regards,   Georges.

> 
> Best regards
> 
> Ole

> diff -Nru tix-8.4.3/debian/changelog tix-8.4.3/debian/changelog
> --- tix-8.4.3/debian/changelog2017-07-12 09:45:53.0 +0200
> +++ tix-8.4.3/debian/changelog2022-01-10 14:01:21.0 +0100
> @@ -1,3 +1,10 @@
> +tix (8.4.3-10.1) unstable; urgency=medium
> +
> +  * Non-maintainer upload.
> +  * d/rules: Add build_indep and build_arch targets (Closes: #998999)
> +
> + -- Ole Streicher   Mon, 10 Jan 2022 14:01:21 +0100
> +
>  tix (8.4.3-10) unstable; urgency=medium
>  
>* added a symlink Tix8.4 -> Tix8.4.3, by postinst and postrm
> diff -Nru tix-8.4.3/debian/rules tix-8.4.3/debian/rules
> --- tix-8.4.3/debian/rules2017-07-12 09:45:53.0 +0200
> +++ tix-8.4.3/debian/rules2022-01-10 13:56:06.0 +0100
> @@ -35,6 +35,8 @@
>  d_run= debian/$(p_run)
>  d_dev= debian/$(p_dev)
>  
> +build_indep:
> +build_arch: build
>  build: build-static build-shared
>  
>  build-static: build-static-stamp


-- 
Georges KHAZNADAR et Jocelyne FOURNIER
22 rue des mouettes, 59240 Dunkerque France.
Téléphone +33 (0)3 28 29 17 70



signature.asc
Description: PGP signature

Bug#1000230: screenruler still fails to start

[Georges Khaznadar]

Peter Mueller a écrit :
> reopen 1000230
> found 1000230 0.960+bzr41+deb10-6
> thanks

Dear Peter,

the getter and the setter for the property GtkWindow.has-resize-grip are
defined in the file /usr/lib/x86_64-linux-gnu/libgtk-3.so.0.2404.20 on
my computer; the last message reported before the crash is 
"Unknown property: GtkWindow.has-resize-grip from 
/usr/share/screenruler/utils/glade_window.rb"

Please can you tell me the version number of your package libgtk-3-0?

Best regards,   Georges.



signature.asc
Description: PGP signature

Bug#1000230: screenruler fails to start

[Georges Khaznadar]

Dear Peter,

please can you check whether installing the package
libcanberra-gtk3-module solves your issue?

If so, this package is probably missing as a dependency for screenruler,
and I can easily fix this bug.

Best regards,   Georges.

Peter Mueller a écrit :
> Package: screenruler
> Version: 0.960+bzr41+deb10-4
> I use Gnome on Wayland. Reproduce:
> 1) Open uxterm, bash being my shell.
> 2) Type in
> screenruler
> and press [Enter].
> 3) Observe:
> $ screenruler Loading libraries... Gtk-Message: 00:03:09.619: Failed to load 
> module "canberra-gtk-module" /usr/bin/screenruler:61:in `block in ': 
> 'Gdk::Pixbuf' has been deprecated. Use 'GdkPixbuf::Pixbuf'. 
> /usr/lib/ruby/vendor_ruby/gdk_pixbuf2/deprecated.rb:48:in `new': 
> GdkPixbuf::Pixbuf.new(path) is deprecated. Use GdkPixbuf::Pixbuf.new(:file => 
> path) instead. /usr/lib/ruby/vendor_ruby/gdk_pixbuf2/deprecated.rb:48:in 
> `new': GdkPixbuf::Pixbuf.new(path) is deprecated. Use 
> GdkPixbuf::Pixbuf.new(:file => path) instead. 
> /usr/lib/ruby/vendor_ruby/gdk_pixbuf2/deprecated.rb:48:in `new': 
> GdkPixbuf::Pixbuf.new(path) is deprecated. Use GdkPixbuf::Pixbuf.new(:file => 
> path) instead. Creating windows... Gtk-WARNING **: Unknown property: 
> GtkWindow.has-resize-grip from 
> /usr/share/screenruler/utils/glade_window.rb:29:in `initialize' from 
> /usr/share/screenruler/ruler_window.rb:51:in `initialize' from 
> /usr/bin/screenruler:76:in `new' from /usr/bin/screenruler:76:in `' 
> Reading settings... Presenting ruler... Shutting down...
> $ sudo aptitude show gnome|grep Version Version: 1:3.38+3
> I would be happy if I could kindly ask that my bug report finds attention.

-- 
Georges KHAZNADAR et Jocelyne FOURNIER
22 rue des mouettes, 59240 Dunkerque France.
Téléphone +33 (0)3 28 29 17 70



signature.asc
Description: PGP signature

Bug#996443: src:units-filter: fails to migrate to testing for too long: FTBFS

[Georges Khaznadar]

Dear Paul,

thank you for your e-mail.

I believed that I fixed the FTBFS bug when I uploaded the release 4.2-1
of units-filter approximately one month ago. However, I probably did too
much work: I enriched the package with a new graphic user interface, so
the new package is now in the NEW queue.

If I upload another package, without the new features (and the new
binary artifact), is there a chance that it will be taken in
consideration by the build system ? I fear that it would compete with
the other package in the NEW queue.

Another option would be to manage the NEW package, either drop it or
accept it, in order to fix the bug immediately, or open the way for a
simple bugfix upload.

Thank you in advance for any suggestion.

Best regards,   Georges.


Paul Gevers a écrit :
> Source: units-filter
> Version: 4.0-1
> Severity: serious
> Control: close -1 4.0.1-1
> Tags: sid bookworm
> User: release.debian@packages.debian.org
> Usertags: out-of-sync
> Control: block -1 by 992508
> 
> Dear maintainer(s),
> 
> The Release Team considers packages that are out-of-sync between testing
> and unstable for more than 60 days as having a Release Critical bug in
> testing [1]. Your package src:units-filter has been trying to migrate
> for 61 days [2]. Hence, I am filing this bug.
> 
> If a package is out of sync between unstable and testing for a longer
> period, this usually means that bugs in the package in testing cannot be
> fixed via unstable. Additionally, blocked packages can have impact on
> other packages, which makes preparing for the release more difficult.
> Finally, it often exposes issues with the package and/or
> its (reverse-)dependencies. We expect maintainers to fix issues that
> hamper the migration of their package in a timely manner.
> 
> This bug will trigger auto-removal when appropriate. As with all new
> bugs, there will be at least 30 days before the package is auto-removed.
> 
> I have immediately closed this bug with the version in unstable, so if
> that version or a later version migrates, this bug will no longer affect
> testing. I have also tagged this bug to only affect sid and bookworm, so
> it doesn't affect (old-)stable.
> 
> If you believe your package is unable to migrate to testing due to
> issues beyond your control, don't hesitate to contact the Release Team.
> 
> Paul
> 
> [1] https://lists.debian.org/debian-devel-announce/2020/02/msg5.html
> [2] https://qa.debian.org/excuses.php?package=units-filter
> 
> 




-- 
Georges KHAZNADAR et Jocelyne FOURNIER
22 rue des mouettes, 59240 Dunkerque France.
Téléphone +33 (0)3 28 29 17 70



signature.asc
Description: PGP signature

Bug#993104: src:wims-lti: fails to migrate to testing for too long: depends on package not allowed in testing

[Georges Khaznadar]

Hello Paul, thank you for this opened/closed bug report.

I looked at bug #923347: it will most probably never be fixed.

I shall try to patch wims-lti to use some other python package to
interact with the database.

Best regards,   Georges.

Paul Gevers a écrit :
> Source: wims-lti
> Version: 0.4.4-4
> Severity: serious
> Control: close -1 0.4.4.1-5
> Tags: sid bookworm
> User: release.debian@packages.debian.org
> Usertags: out-of-sync
> 
> Dear maintainer(s),
> 
> As recently announced [1], the Release Team now considers packages that
> are out-of-sync between testing and unstable for more than 60 days as
> having a Release Critical bug in testing. Your package src:wims-lti has
> been trying to migrate for 155 days [2]. Hence, I am filing this bug.
> 
> You added a new dependency on a package that's not allowed to migrate to
> testing due to security reasons: mysql-connector-python.
> 
> If a package is out of sync between unstable and testing for a longer
> period, this usually means that bugs in the package in testing cannot be
> fixed via unstable. Additionally, blocked packages can have impact on
> other packages, which makes preparing for the release more difficult.
> Finally, it often exposes issues with the package and/or
> its (reverse-)dependencies. We expect maintainers to fix issues that
> hamper the migration of their package in a timely manner.
> 
> This bug will trigger auto-removal when appropriate. As with all new
> bugs, there will be at least 30 days before the package is auto-removed.
> 
> I have immediately closed this bug with the version in unstable, so if
> that version or a later version migrates, this bug will no longer affect
> testing. I have also tagged this bug to only affect sid and bookworm, so
> it doesn't affect (old-)stable.
> 
> If you believe your package is unable to migrate to testing due to
> issues beyond your control, don't hesitate to contact the Release Team.
> 
> Paul
> 
> [1] https://lists.debian.org/debian-devel-announce/2020/02/msg5.html
> [2] https://qa.debian.org/excuses.php?package=wims-lti
> 
> 




-- 
Georges KHAZNADAR et Jocelyne FOURNIER
22 rue des mouettes, 59240 Dunkerque France.
Téléphone +33 (0)3 28 29 17 70



signature.asc
Description: PGP signature

Bug#990026: uploaded a fix

[Georges Khaznadar]

Hello, as bug #990026 got no update for three weeks, I uploaded a fix to
our salsa repository, which allows characters like "=" and "/" in e-mail
addresses.

I add the patch as an attachment.

Best regards,   Georges.

-- 
Georges KHAZNADAR et Jocelyne FOURNIER
22 rue des mouettes, 59240 Dunkerque France.
Téléphone +33 (0)3 28 29 17 70

diff --git a/debian/changelog b/debian/changelog
index e94afd6..f98102e 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,12 @@
+cron (3.0pl1-137.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * authorized characters like "=", "/" in email addresses.
+the modified file is debian/patches/features/Add-MAILFROM-environment-variable.patch
+Closes: #990026
+
+ -- Georges Khaznadar   Tue, 13 Jul 2021 11:04:41 +0200
+
 cron (3.0pl1-137) unstable; urgency=medium
 
   [ Laurent Combe ]
diff --git a/debian/patches/features/Add-MAILFROM-environment-variable.patch b/debian/patches/features/Add-MAILFROM-environment-variable.patch
index 1d31ed7..82edf04 100644
--- a/debian/patches/features/Add-MAILFROM-environment-variable.patch
+++ b/debian/patches/features/Add-MAILFROM-environment-variable.patch
@@ -16,11 +16,11 @@ Last-Update: 2021-02-16
  do_command.c | 45 ++---
  3 files changed, 39 insertions(+), 26 deletions(-)
 
-diff --git a/cron.8 b/cron.8
-index cae80a3..582270f 100644
 a/cron.8
-+++ b/cron.8
-@@ -123,7 +123,9 @@ then wakes up every minute, examining all stored crontabs, checking
+Index: cron/cron.8
+===
+--- cron.orig/cron.8
 cron/cron.8
+@@ -123,7 +123,9 @@ then wakes up every minute, examining al
  each command to see if it should be run in the current minute.  When
  executing commands, any output is mailed to the owner of the crontab
  (or to the user named in the MAILTO environment variable in the
@@ -31,11 +31,11 @@ index cae80a3..582270f 100644
  processes have their name coerced to uppercase, as will be seen in the
  syslog and ps output.
  .PP
-diff --git a/crontab.5 b/crontab.5
-index 70e411d..969370c 100644
 a/crontab.5
-+++ b/crontab.5
-@@ -100,12 +100,16 @@ on these systems, USER will be set also.)
+Index: cron/crontab.5
+===
+--- cron.orig/crontab.5
 cron/crontab.5
+@@ -100,12 +100,16 @@ on these systems, USER will be set also.
  .PP
  In addition to LOGNAME, HOME, and SHELL,
  .IR cron (8)
@@ -58,10 +58,10 @@ index 70e411d..969370c 100644
  .PP
  On the Debian GNU/Linux system, cron supports the
  .B pam_env
-diff --git a/do_command.c b/do_command.c
-index 930e910..7a94f52 100644
 a/do_command.c
-+++ b/do_command.c
+Index: cron/do_command.c
+===
+--- cron.orig/do_command.c
 cron/do_command.c
 @@ -52,6 +52,7 @@ static const struct pam_conv conv = {
  
  static void		child_process __P((entry *, user *)),
@@ -133,7 +133,7 @@ index 930e910..7a94f52 100644
  }
 +
 +static int safe_p(const char *usernm, const char *s) {
-+	static const char safe_delim[] = "@!:%-.,_+"; /* conservative! */
++	static const char safe_delim[] = "@!:%-.,_+=/"; /* conservative! */
 +	const char *t;
 +	int ch, first;
 +


signature.asc
Description: PGP signature

Bug#990489: python3-expeyes: why is there a Conflicts: modemmanager ?

[Georges Khaznadar]

Dear Ajith,

I uploaded a fixed package to Debian, just before Jithin proposed an
even better fix (more general for various hardware related to Phoenix
project).

We must let some time to developers of the release.debian.org to manage
the current "unblock request".

If they agree with the unblock request, expeyes will be part of the
next Debian/stable distribution. I shall try to upload Jithin's better
fix later: maybe some member of release.debian.org will be able to take
it in consideration, as a second (and lighter) change to this package.

Best regards,   Georges.

Ajith Kumar a écrit :
> Dear Georges,
> I think a message may be displayed during the installation of eyes17
> instructing to remove the modem manager in case of any trouble
> communicating with eyes17. It is left to the user instead of a forced
> removal. It is important to have it in the Distro. The users in Kerala is a
> closed community and we can instruct them. Jithin may consider it.


signature.asc
Description: PGP signature

Bug#990489: python3-expeyes: why is there a Conflicts: modemmanager ?

[Georges Khaznadar]

Dear Andreas,

thank you for the hint about post-installation scripts.

The colleague whom I lended my Eyes17 box could check the compatibility
of expeyes software vs. modemmanager with success: this validates the
udev rules file.

I uploaded a fixed package to unstable, anf filed an unblock request to
release.debian.org people.

The debdiff file is rather big, because a new version (4.8.8) had been
uploaded prevously to unstable, which features some ironing of
documentation files, and removes many useless files in the binary
package eyes17.

Best regards,   Georges.

Andreas Beckmann a écrit :
> Control: retitle -1 python3-expeyes: superfluous Conflicts: modemmanager 
> causes problems on buster->bullseye upgrades
> 
> On 30/06/2021 18.55, Georges Khaznadar wrote:
> > I attach the file eyes_udev.sh, which is called upon eyes17's
> > post-installation, as "eyes_udev.sh enable", thus creating or keeping
> > the file /lib/udev/rules.d/99-phoenix.rules, with this content:
> 
> Great, the fix seems to be already included in the package.
> So maybe it's sufficient to just drop all the Conflicts on modemmanager
> to fix this bug ;-)
> 
> In all the maintainer scripts, please use
>   invoke-rc.d udev 
> instead of
>   service udev 
> s.t. this gets properly filtered via policy-rc.d
> (an RC bug on its own, not filing it separately because we already have
> this one)
> 
> Lintian says this:
> 
> E: maintainer-script-calls-service
> N:
> N:   The maintainer script apparently runs the service command. This
> N:   command is reserved for local administrators and must never be used by
> N:   a Debian package.
> N:
> N:   Please replace with calls to update-rc.d(8) and invoke-rc.d(8). If
> N:   your package installs this service, this can be automated using
> N:   dh_installinit(1) or dh_installsystemd(1).
> N:
> N:   Refer to Debian Policy Manual section 9.3.3 (Interfacing with init
> N:   systems) for details.
> 
> 
> Andreas

-- 
Georges KHAZNADAR et Jocelyne FOURNIER
22 rue des mouettes, 59240 Dunkerque France.
Téléphone +33 (0)3 28 29 17 70



signature.asc
Description: PGP signature

Bug#990489: python3-expeyes: why is there a Conflicts: modemmanager ?

[Georges Khaznadar]

Sorry, here is the forgotten attachment, on e-mail later as usual.



eyes_udev.sh
Description: Bourne shell script


signature.asc
Description: PGP signature

Bug#990489: python3-expeyes: why is there a Conflicts: modemmanager ?

[Georges Khaznadar]

Dear Jithin,
thank you for your very fast response.

I attach the file eyes_udev.sh, which is called upon eyes17's
post-installation, as "eyes_udev.sh enable", thus creating or keeping
the file /lib/udev/rules.d/99-phoenix.rules, with this content:

---8<- /lib/udev/rules.d/99-phoenix.rules --
# udev rules for expEYES interface: AVR, FT232, MCP2200 and CH340
SUBSYSTEM=="usb",ATTRS{idVendor}=="03eb", ATTRS{idProduct}=="21ff", MODE="666"
SUBSYSTEM=="tty",ATTRS{idVendor}=="0403", ATTRS{idProduct}=="6001", MODE="666"
SUBSYSTEM=="tty",ATTRS{idVendor}=="04d8", ATTRS{idProduct}=="00df", MODE="666"
SUBSYSTEM=="tty",ATTRS{idVendor}=="1a86", ATTRS{idProduct}=="7523", MODE="666"
ATTRS{idVendor}=="03eb", ATTRS{idProduct}=="21ff", ENV{ID_MM_DEVICE_IGNORE}="1"
ATTRS{idVendor}=="0403", ATTRS{idProduct}=="6001", ENV{ID_MM_DEVICE_IGNORE}="1"
ATTRS{idVendor}=="04d8", ATTRS{idProduct}=="00df", ENV{ID_MM_DEVICE_IGNORE}="1"
ATTRS{idVendor}=="1a86", ATTRS{idProduct}=="7523", ENV{ID_MM_DEVICE_IGNORE}="1"
# interest_eyes17
---8<-

Please can you check whether ATTRS{idVendor}=="03eb", ... "0403",  
"04d8", ... "1a86" will be enough to blacklist our boxes' interfaces for
modemmanager, and eventually the interface of eyes17?

Then, please can you check that installing modemmanager will let Eyes17
boxes in peace, when such a rule is activated for udev?

Currently, my Eyes17 box is lended to a colleague who is trying the
complete list of experiments of the User Manual, while reviewing the
Spanish version, and might want to buy such boxes, for his technical
school. I can ask him to give it back, and he would do it shortly, but
he asked me two days ago whether I could lend the box some longer; I
did not know that I would get a bug report today :)

Best regards,   Georges.


jithin bp a écrit :
> Dear Georges,
> 
> The modem-manager probes serial ports with random AT commands causing
> communication errors in a wide range of devices which use the serial port,
> most common ones being embedded development tools such as for the Arduino ,
> PIC etc.
> This issue has been reported in many forums
> -
> https://mail.gnome.org/archives/networkmanager-list/2013-October/msg00038.html
> -
> https://askubuntu.com/questions/1231894/modemmanager-conflicts-with-arduino
> - https://github.com/ubuntu/ubuntu-make/issues/4
> 
> In case of ExpEYES, random communication errors, and subsequent data loss
> occurs during data acquisition tasks if Modem Manager is running in the
> background. Perhaps there is some way to place a lock on the active serial
> port to prevent MM from probing it.
> 
> One suggestion that needs to be rigorously tested is to blacklist the
> serial device of ExpEYES(VendorID:ProductID) for Modem Manager so that it
> will ignore it.
> https://askubuntu.com/questions/1231894/modemmanager-conflicts-with-arduino
> 
> The user community is currently in the range of a few thousands, and is
> expected to grow, so a solution must be quickly resolved after studying
> which serial devices Modem-Manager automatically likes to probe, and to
> keep ExpEYES ( ID 04d8:00df Microchip Technology, Inc.) out of that list.
> 
> 
> More about ExpEYES
> - https://expeyes.in/
> - https://csparkresearch.in/expeyes17/
> - https://csparkresearch.in/expeyes17/blog
> 
> Regards,
> Jithin
> 
> On Wed, Jun 30, 2021 at 9:36 PM Georges Khaznadar 
> wrote:
> 
> > Dear Andreas,
> >
> > I added in Cc: the authors of Expeyes hardware and software.
> >
> > Hello Jithin, Ajith! the context about the bug report with serious
> > severity is below.
> >
> > 
> >
> > I ignored that a statement like "Conflicts: modemmanager" would create
> > problems with buster->bullseye upgrades. Currently, binary packages
> > conflicting with modemmanager are: eyes17, python3-expeyes,
> > firm-phoenix-ware. The first one, eyes17, will be the most used.
> >
> > This statement was added because boxes of the Expeyes family do not
> > communicate correctly by their serial link when modemmanager is
> > installed. I did not investigate further, to know the precise reason of
> > the incompatibility.
> >
> > I got e-mails of some users of previous versions of expeyes packages,
> > who could not activate their boxes, and my reply was to uninstall
> > modemmanager or upgrade to the new 

Bug#990489: python3-expeyes: why is there a Conflicts: modemmanager ?

[Georges Khaznadar]

Dear Andreas,

I added in Cc: the authors of Expeyes hardware and software.

Hello Jithin, Ajith! the context about the bug report with serious
severity is below.



I ignored that a statement like "Conflicts: modemmanager" would create
problems with buster->bullseye upgrades. Currently, binary packages
conflicting with modemmanager are: eyes17, python3-expeyes, 
firm-phoenix-ware. The first one, eyes17, will be the most used.

This statement was added because boxes of the Expeyes family do not
communicate correctly by their serial link when modemmanager is
installed. I did not investigate further, to know the precise reason of
the incompatibility.

I got e-mails of some users of previous versions of expeyes packages,
who could not activate their boxes, and my reply was to uninstall
modemmanager or upgrade to the new version of eyes17 package.

The number of Expeyes users is currently growing in Kerala (a southern
state of India), and they rely on *eyes17* package, some with a Debian
machine, most with an Ubuntu machine. This community is growing since
Eyes17 box has become an officially encouraged scientific device, to be
distributed to all high schools in the state, together with training.

I cannot withdraw the confict statement without damaging this user
community in the future.

Hence the next question:


How would it be possible to keep expeyes packages in the soon-to-come
Debian/Stable distribution?

The package modemmanager is recommended by widely used packages, like
network-manager, while eyes17 is recommended by no package.

I do not know how many users do really need modemmanager, or use modems.

However I know better the profile of users who use eyes17: they are
students and teachers, wo interact inside a high school. Then, the link
with Internet is generally provided by some router or some wireless box,
and no modem is used.

@Jitin, @Ajith:
can you give please an estimate of the user community for eyes17 now,
and in a near future?

Best regards,   Georges.

Andreas Beckmann a écrit :
> Package: python3-expeyes
> Version: 4.8.7+repack-4
> Severity: serious
> User: debian...@lists.debian.org
> Usertags: piuparts
> Control: affects -1 + eyes17
> 
> Hi Georges,
> 
> while investigating incomplete buster->bullseye upgrades, I came across
> the Conflicts: modemmanager in python3-expeyes. Why was that added?
> It is not mentioned in the changelog and the git commit introducing it
> doesn't explain it either.
> Should this have been a versioned Breaks instead?
> 
> The modemmanager package still exists in bullseye, so what should be the
> desired buster->bullseye upgrade outcome for buster systems with both
> modemmanager and python3-expeyes installed (that happens e.g. when
> installing eyes17/buster with --install-recommends)?
> 
> 
> Andreas

-- 
Georges KHAZNADAR et Jocelyne FOURNIER
22 rue des mouettes, 59240 Dunkerque France.
Téléphone +33 (0)3 28 29 17 70



signature.asc
Description: PGP signature

Bug#987728: wims-modules: depends on unavailable tinymce

[Georges Khaznadar]

Hi Andreas,

thank you for the bug report!

I had a look at tinymce , and ...
Andreas Beckmann a écrit :
>[...] wims-modules : Depends: tinymce but it is not installable
> 
> tinymce has been removed recently: https://bugs.debian.org/977149

That is sad: the popcon score of tinymce was 1500 when it was removed
(it has decreased slowly from 3000 in the past)

The upstream developers of wims have embedded a version 5.4.2 of
tinymce, which is more than the last version maintained in Debian: 
3.4.8 which was introduced nine years ago; however, symlinking files
of the package wims-modules to the older javascript module did work.

Now, if I want to keep on maintaining the package wims, which is
important for education as a contents server, there are two possible
ways:

1 - revive a debian package for tinymce: I had a look at upstream
developments, they are very active. Unfortunately, tinymce is
becoming bolder and bolder. Compiling it requires yarn, and implies
downloading more than a thousand node modules. I strongly doubt to
find every of those depedencies already packaged inside Debian.
2 - replace Javascript-enhanced editor areas in Wims which depend on
tinymce by some alternative code, hopefully providing some 
*really tiny* editor, not the bloatware that tinymce is becoming.

I believe that only the second option is sustainable, probably by using
ckeditor whose debian package is up to date with upstream's ckeditor4.

Best regards,   Georges.





signature.asc
Description: PGP signature

Bug#987490: falkon FTBFS: dh_install: error: missing files, aborting

[Georges Khaznadar]

Hi Reiner, Adrian,

thank you for the bug report and for the hints.

I believe that the bug is fixed with the newly uploaded release.

Should I do something else to get falkon included in bullseye, or is it
enough to wait a few days?

Best regards,   Georges.

Reiner Herrmann a écrit :
> Hi Georges,
> 
> On Sat, Apr 24, 2021 at 05:56:45PM +0300, Adrian Bunk wrote:
> > ...
> >dh_install -a
> > dh_install: warning: Cannot find (any matches for) "usr/bin" (tried in ., 
> > debian/tmp)
> > 
> > dh_install: warning: falkon missing files: usr/bin
> > dh_install: warning: Cannot find (any matches for) "usr/lib/*-linux-gnu*/*" 
> > (tried in ., debian/tmp)
> > 
> > dh_install: warning: falkon missing files: usr/lib/*-linux-gnu*/*
> > dh_install: warning: Cannot find (any matches for) "usr/share" (tried in ., 
> > debian/tmp)
> > 
> > dh_install: warning: falkon missing files: usr/share
> > dh_install: error: missing files, aborting
> > make: *** [debian/rules:15: binary-arch] Error 25
> > 
> 
> sorry, my patch for #987455 was incomplete.
> Now that falkon is the only binary package, cmake will directly
> install into debian/falkon/ (instead of debian/tmp).
> This also means that debian/falkon.install is now unnecessary,
> as the contents of debian/falkon/ will be packed into the package.
> 
> I quickly tested building it with the .install file removed and compared
> the resulting .deb package with debdiff. The file list is identical
> with falkon 3.1.0+dfsg1-9.
> 
> Kind regards,
>   Reiner



-- 
Georges KHAZNADAR et Jocelyne FOURNIER
22 rue des mouettes, 59240 Dunkerque France.
Téléphone +33 (0)3 28 29 17 70



signature.asc
Description: PGP signature

Bug#987527: clonezilla: Fails to install on bullseye

[Georges Khaznadar]

Dear Chris, thank you for the bug report.

I believe that the bug is fixed with the newly uploaded release
3.35.2-3.

What should I do next to allow clonezilla to be included in bullseye ?
Is the upload enough or must I make some other acknowledgement, or send some
e-mail ?

Best regards,   Georges.


Chris Hofstaedtler a écrit :
> Control: severity -1 serious
> 
> * Matthias Gies  [210425 13:11]:
> > clonezilla (3.35.2-2) wird eingerichtet ...
> > ln: die symbolische Verknüpfung '/opt/' konnte nicht angelegt werden: Datei 
> > oder Verzeichnis nicht gefunden
> > dpkg: Fehler beim Bearbeiten des Paketes clonezilla (--configure):
> >  »installiertes clonezilla-Skript des Paketes 
> > post-installation«-Unterprozess gab den Fehlerwert 1 zurück
> 
> I believe packages are not allowed to install stuff into /opt. 
> If they are, this should be a normal file install, and not a
> postinst hack.
> 
> Chris

-- 
Georges KHAZNADAR et Jocelyne FOURNIER
22 rue des mouettes, 59240 Dunkerque France.
Téléphone +33 (0)3 28 29 17 70



signature.asc
Description: PGP signature

Bug#983785: wims-lti: fails to install: post-installation script subprocess returned error exit status 2

[Georges Khaznadar]

Dear Andreas,

thank you for the bug report, and for the fix!

Best regards,   Georges.

Andreas Beckmann a écrit :
> Package: wims-lti
> Version: 0.4.4-2
> Severity: serious
> User: debian...@lists.debian.org
> Usertags: piuparts
> 
> Hi,
> 
> during a test with piuparts I noticed your package failed to install. As
> per definition of the release team this makes the package too buggy for
> a release, thus the severity.
> 
> >From the attached log (scroll to the bottom...):
> 
>   Setting up wims-lti (0.4.4-2) ...
>   dpkg: error processing package wims-lti (--configure):
>installed wims-lti package post-installation script subprocess returned 
> error exit status 2
>   Processing triggers for libc-bin (2.31-9) ...
>   Processing triggers for ca-certificates (20210119) ...
>   Updating certificates in /etc/ssl/certs...
>   0 added, 0 removed; done.
>   Running hooks in /etc/ca-certificates/update.d...
>   done.
>   Errors were encountered while processing:
>wims-lti
> 
> If I insert set -x in the postinst script, the race ends with
> 
> [...]
> + db_get wims-lti/virtualHost
> + _db_cmd GET wims-lti/virtualHost
> + _db_internal_IFS=
> 
> + IFS=
> + printf %s\n GET wims-lti/virtualHost
> + IFS=
> 
> + read -r _db_internal_line
> + IFS=
> 
> + RET=wims-lti.example.com
> + return 0
> + virtualHost=wims-lti.example.com
> + appDir=/var/lib/wims-lti
> + apacheConfDist=/etc/apache2/sites-available/wims-lti-django.conf-dist
> + apacheConf=/etc/apache2/sites-available/wims-lti-django.conf
> + getent passwd lti
> + lti_entry=
> 
> I'd suggest this change to fix the logic, and something similar for the group:
> 
> -    lti_entry=$(getent passwd lti)
> -if [ -z "$lti_entry" ]; then
> +if ! getent passwd lti >/dev/null ; then
> 
> 
> cheers,
> 
> Andreas



-- 
Georges KHAZNADAR et Jocelyne FOURNIER
22 rue des mouettes, 59240 Dunkerque France.
Téléphone +33 (0)3 28 29 17 70



signature.asc
Description: PGP signature

Bug#979302: libgtkextra-3.0: ships libgtkextra-x11-3.0.so

[Georges Khaznadar]

Thank you for the bug report, Andreas!

So, as I understand it, the warnings reported by dh-missing were false
positives. I shall try to rebuild the package without the duplicate
installation of files, and a fresh build environment: I hope that the
last version of dh-missing will no longer prevent the build of the
package.

Best regards,   Georges.

Andreas Beckmann a écrit :
> Package: libgtkextra-3.0
> Version: 3.3.4-2
> Severity: serious
> User: debian...@lists.debian.org
> Usertags: piuparts
> 
> Hi,
> 
> during a test with piuparts I noticed your package failed to install
> because it tries to overwrite other packages files.
> 
> >From the attached log (scroll to the bottom...):
> 
>   Selecting previously unselected package libgtkextra-3.0.
>   Preparing to unpack .../61-libgtkextra-3.0_3.3.4-2_amd64.deb ...
>   Unpacking libgtkextra-3.0 (3.3.4-2) ...
>   Selecting previously unselected package libgtkextra-dev.
>   Preparing to unpack .../62-libgtkextra-dev_3.3.4-2_amd64.deb ...
>   Unpacking libgtkextra-dev (3.3.4-2) ...
>   dpkg: error processing archive 
> /tmp/apt-dpkg-install-gS1CgJ/62-libgtkextra-dev_3.3.4-2_amd64.deb (--unpack):
>trying to overwrite '/usr/lib/x86_64-linux-gnu/libgtkextra-x11-3.0.so', 
> which is also in package libgtkextra-3.0 3.3.4-2
>   Errors were encountered while processing:
>/tmp/apt-dpkg-install-gS1CgJ/62-libgtkextra-dev_3.3.4-2_amd64.deb
> 
> The .so symlink belongs into the -dev package, not into the package
> with the shared library. (Policy 8.4)
> 
> Looking at the changelog entry of the last upload I noticed
> 
> >   * modified debian/libgtkextra-3.0.install to include files
> > usr/lib/x86_64-linux-gnu/libgtkextra-x11-3.0.a and
> 
> The .a file belongs into the -dev package. (Policy 8.3)
> 
> > usr/lib/x86_64-linux-gnu/libgtkextra-x11-3.0.la in order to prevent
> 
> The .la file belongs into the trash bin.
> (https://wiki.debian.org/ReleaseGoals/LAFileRemoval)
> 
> > dh_missing's warning about files "not installed to anywhere"
> 
> 
> cheers,
> 
> Andreas



-- 
Georges KHAZNADAR et Jocelyne FOURNIER
22 rue des mouettes, 59240 Dunkerque France.
Téléphone +33 (0)3 28 29 17 70



signature.asc
Description: PGP signature

Bug#970808: Python3-venv is back, isn't it?

[Georges Khaznadar]

Dear Matthias,

as far as I could check, the directory Lib/venv appears as existing in
upstream sources (at least for version 3.9.0 of Python). So,
python3-venv might be considered as back, isn't it?

Can we close this bug for package thonny report now?

Best regards,   Georges.

-- 
Georges KHAZNADAR et Jocelyne FOURNIER
22 rue des mouettes, 59240 Dunkerque France.
Téléphone +33 (0)3 28 29 17 70



signature.asc
Description: PGP signature

Bug#970763: bug report acknowledged

[Georges Khaznadar]

Dear Ryan,

thank you for the bug report: wminput does segfault when it is called.

I tried to modify the source to get rid of the build warnings, which in
fact should be reported as errors. It appears to be a tough task, since
many warnings are about unapropriate pointer casts, due to the mix of
python2 and python3 concepts.

I shall try to get some help from the last upstream developer who
touched this software in source form.

Best regards,   Georges.

-- 
Georges KHAZNADAR et Jocelyne FOURNIER
22 rue des mouettes, 59240 Dunkerque France.
Téléphone +33 (0)3 28 29 17 70



signature.asc
Description: PGP signature

Bug#963036: Wild guess to fix this bug

[Georges Khaznadar]

Dear maintainer(s) of octave-symbolic, here is a wild guess, inspired by
a simple remark:

8<
$ python3 -c "import six; print(six.integer_types)" (,)
$ python2 -c "import six; print(six.integer_types)" (, )
8<

Would it be enough to patch octave-symbolic source, to replace
'sympy.core.compatibility.integer_types' by 'six.integer_types' ?

Best regards,   Georges.

-- 
Georges KHAZNADAR et Jocelyne FOURNIER
22 rue des mouettes, 59240 Dunkerque France.
Téléphone +33 (0)3 28 29 17 70



signature.asc
Description: PGP signature

Bug#963036: Sympy 3.6 no longer defined any integer_types attribute

[Georges Khaznadar]

Dear maintainer(s),

The command `grep -r integer_types .`, when launched from the source
directory of sympy's package, returns nothing.

On the other hand, the command
`grep -r integer_types /usr/share/octave/packages/symbolic-2.7.1/`
returns the following lines:

---8<---
/usr/share/octave/packages/symbolic-2.7.1/private/check_and_convert.m:  
persistent integer_types
/usr/share/octave/packages/symbolic-2.7.1/private/check_and_convert.m:
integer_types = sp.compatibility.integer_types;
/usr/share/octave/packages/symbolic-2.7.1/private/check_and_convert.m:
elseif (py.isinstance(x, integer_types))
/usr/share/octave/packages/symbolic-2.7.1/private/python_header.py:elif 
isinstance(x, sp.compatibility.integer_types):
---8<---

So I suspect that some parts of Octave-symbolic should be updated to
take in account the newer Sympy version.

Unfortunately, the documentation of Sympy 1.6 does not refere to the
word integer_types (which is the consequence of this word missing in the
source of the package).

I cannot help, so far, because I ignore what the attribute integer_types
was intended to in the previous version. Please can you, maintainer(s)
of octave-symbolic, provide some additional information ? If it is not
possible to fix the bug properly, maybe some tests should be temporarily
disabled?
 
Best regards,   Georges.

-- 
Georges KHAZNADAR et Jocelyne FOURNIER
22 rue des mouettes, 59240 Dunkerque France.
Téléphone +33 (0)3 28 29 17 70



signature.asc
Description: PGP signature

Bug#959475: screenkey: doesn't respect settings

[Georges Khaznadar]

Dear Tomas,

I patched screenkey's source heavily to make it ready for Python3 and
Gtk3, and it had many side-effects : features have worsened.

You are right with your bug report.

I sent my patches to people who used to maintain screenkey upstream, but
so far, I got no satisfactory feedback, and I am afraid that this
package is not really maintained.

If you have some proposition to make, to fix the bugs, you are welcome;
otherwise, as the package is almost dead upstream, it will slowly vanish
out of Debian.

Best regards,   Georges.

Tomas Janousek a écrit :
> Package: screenkey
> Version: 0.10-1
> Severity: grave
> Justification: renders package unusable
> 
> The python3 version seems almost entirely broken on my Debian testing system.
> Almost all settings are ignored, regardless of whether I change them using
> command-line switches or the settings GUI. Backspace shows as [⁰⁰₀₈] instead
> of ⌫. No matter what font I choose, it uses some fixed one that apparently
> lacks the symbol for backspace and many other keys. No matter what setting I
> choose for --bak-mode, it shows the same broken backspace unicode replacement
> instead of erasing the last char. --key-mode is ignored as well.
> 
> When changing settings through the setting GUI, the following exception is
> printed:
> 
>   File "/usr/lib/python3/dist-packages/Screenkey/screenkey.py", line 340, 
> in on_cbox_modes_changed
> self.options.key_mode = KEY_MODES.keys()[index]
> TypeError: 'dict_keys' object is not subscriptable
> 
> Downgrading to 0.9-2 from stable fixes all of this.
> 
> -- System Information:
> Debian Release: bullseye/sid
>   APT prefers testing
>   APT policy: (990, 'testing'), (990, 'stable'), (500, 'unstable-debug'), 
> (500, 'testing-debug'), (500, 'stable-debug'), (500, 'unstable'), (500, 
> 'stable'), (1, 'experimental-debug'), (1, 'experimental')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
> 
> Kernel: Linux 5.4.0-4-amd64 (SMP w/4 CPU cores)
> Kernel taint flags: TAINT_USER, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
> Locale: LANG=cs_CZ.UTF-8, LC_CTYPE=cs_CZ.UTF-8 (charmap=UTF-8), 
> LANGUAGE=cs_CZ.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
> 
> -- 
> Tomáš Janoušek, a.k.a. Pivník, a.k.a. Liskni_si, http://work.lisk.in/

-- 
Georges KHAZNADAR et Jocelyne FOURNIER
22 rue des mouettes, 59240 Dunkerque France.
Téléphone +33 (0)3 28 29 17 70



signature.asc
Description: PGP signature

Bug#954432: I cannot reproduce the bug you are describing

[Georges Khaznadar]

Dear Brice,

I cannot reproduce the bug reported as number 954432.

As the error messages are reporting failures with a QSettings object, 
I can suppose that some configuration file in your computer is not
structured as wanted for the current geophar application.

Please try to put the directory ${HOME}/.local/share/geophar out of the
way: erase it or rename it to some other name if you prefer keep the
file which raised the bug.

Without the directory ~/.local/share/geophar, the application will
rebuild the settings files consistently, and should not fail to start
anymore.

Please reply me shortly. Next week, I shall tag the bug as
non-reproducible and consider it as closed/done.

Best regards,   Georges.

-- 
Georges KHAZNADAR et Jocelyne FOURNIER
22 rue des mouettes, 59240 Dunkerque France.
Téléphone +33 (0)3 28 29 17 70



signature.asc
Description: PGP signature

Bug#936358: Bug#952496: python3-whiteboard, depends on package that is not in Debian.

[Georges Khaznadar]

Hi, I worked out a Python3 port of package python-cwiid to
python3-cwiid.

Please can you review the work done in
https://salsa.debian.org/georgesk/cwiid ?

As upstream development seems almost stopped, I made most changes inside
the branch upstream of the repository, and issued a new version number.

If nobody replies during the next weeks, I shall try an NMU. However it
is maybe tricky, since the new package introduces a chane in the name of
a binary package.

Best regards,   Georges.

peter green a écrit :
> Package: python3-whiteboard
> Version: 1.0+git20170915-3
> Severity: serious
> 
> python3-whiteboard depends on python3-cwiid, however I can't find any 
> evidence of this package existing, it's not in debian, it doesn't appear to 
> be in new (at least searching new for cwiid doesn't show anything) and my 
> google searches aren't turning anything up either.

-- 
Georges KHAZNADAR et Jocelyne FOURNIER
22 rue des mouettes, 59240 Dunkerque France.
Téléphone +33 (0)3 28 29 17 70



signature.asc
Description: PGP signature

Bug#940463: fixed in falkon 3.1.0+dfsg1-4

[Georges Khaznadar]

Dear John,

thank you for your interest in Bug#940463.

I got no reply from Xeno Idaltu , so I believe
that either he is not using falkon again, or he installed falkon's new
package and found the bug fixed. His only e-mail states that he made a
fresh install, and gives version numbers for the distribution and
dependencies.

Sorry, I had no time to reproduce the same installation. As my last
e-mail tells, I "Checked that falkon-3.1.0+dfsg1-3 does not crash",
which can be considered as being unable to reproduce the bug.

The issue seems to be fixed between two upstream releases (falkon 3.0
and falkon 3.1).

John, if you want to help about packaging falkon for Debian, you are
most welcome. By the way, were you able to reproduce the crash?

Best regards,   Georges.

John Scott a écrit :
> On Wed, 16 Oct 2019 10:00:15 + Georges Khaznadar  
> wrote:
> > Source: falkon
> > Source-Version: 3.1.0+dfsg1-4
> > 
> > We believe that the bug you reported is fixed in the latest version of
> > falkon, 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.
> > 
> > Changes:
> >  falkon (3.1.0+dfsg1-4) unstable; urgency=medium
> >  .
> >* Checked that falkon-3.1.0+dfsg1-3 does not crash.
> >  Closes: #940463
> 
> Did a change to Falkon fix the issue, or is 3.1.0+dfsg-1-4 the same as 
> 3.1.0+dfsg-1-3? Was the submitter's issue resolved or were you unable to 
> reproduce the crash?



-- 
Georges KHAZNADAR et Jocelyne FOURNIER
22 rue des mouettes, 59240 Dunkerque France.
Téléphone +33 (0)3 28 29 17 70



signature.asc
Description: PGP signature

Bug#939571: uploaded a NMU, delayed 15 days

[Georges Khaznadar]

Hello Gianfranco,

as the bug is (not elegantly) fixed, and as the deadline for autoremoval
is in 25 days, I uploaded python-pyqtgraph_0.10.0-4.1 as an NMU.

If you prefer download the good fix before two weeks, do not worry, the
NMU will silently die.

Best regards,   Georges.

-- 
Georges KHAZNADAR et Jocelyne FOURNIER
22 rue des mouettes, 59240 Dunkerque France.
Téléphone +33 (0)3 28 29 17 70



signature.asc
Description: PGP signature

Bug#939571: Found one clue about this bug

[Georges Khaznadar]

I do not know exactly why this bug arises, but here are the facts:

- when I download
  
http://ftp.de.debian.org/debian/pool/main/p/python-pyqtgraph/python3-pyqtgraph_0.10.0-4_all.deb
  and inspect this package, it misses the directory
  /usr/lib/python3/pyqtgraph/widget, hence the error message reported in
  the bug report: "ModuleNotFoundError: No module named 'pyqtgraph.widgets'"

- when I tried to know why this directory is missing from the package, I
  cloned the fork https://salsa.debian.org/georgesk/python-pyqtgraph and
  built the package again with debuild: then, the same bug happens:
  /usr/lib/python3/pyqtgraph/widget is missing again

- I patched the file setup.py, in order to view better le list of
  packages and sub-packages which were to install, and added a single
  line to print a message with the value of the variable allPackages:
  [line 68] print("Hello, allPackages =", allPackages)
  it happens that 'pyqtgraph.widget' is part of the list allPackages
  sometimes, and sometimes, not. THIS IS WEIRD!

- it seems that the function listAllPackages from the module
  tools.setupHelpers is not completely reliable, though I have no
  precise idea why. I could get a valid list of packages by calling this
  function from Python3 in interactive mode. I have no time to create a
  minimal example which can raise that buggy behavior, I just suspect
  that is come from Python's internals.

- here is attached a patch which provides the right list of packages as
  a hard-coded list. This list has been returned by the function
  listAllPackages() in interactive mode, and contains
  "pyqtgraph.widgets"; with that patch, the package is effective again.

I propose a pull request for this patch, in Salsa.

Best regards,   Georges.
-- 
Georges KHAZNADAR et Jocelyne FOURNIER
22 rue des mouettes, 59240 Dunkerque France.
Téléphone +33 (0)3 28 29 17 70

Index: python-pyqtgraph/setup.py
===
--- python-pyqtgraph.orig/setup.py
+++ python-pyqtgraph/setup.py
@@ -63,8 +63,8 @@ sys.path.insert(0, os.path.join(path, 't
 import setupHelpers as helpers
 
 ## generate list of all sub-packages
-allPackages = (helpers.listAllPackages(pkgroot='pyqtgraph') + 
-   ['pyqtgraph.'+x for x in helpers.listAllPackages(pkgroot='examples')])
+allPackages = ['pyqtgraph', 'pyqtgraph.GraphicsScene', 'pyqtgraph.util', 'pyqtgraph.util.colorama', 'pyqtgraph.tests', 'pyqtgraph.parametertree', 'pyqtgraph.opengl', 'pyqtgraph.opengl.items', 'pyqtgraph.pixmaps', 'pyqtgraph.graphicsItems', 'pyqtgraph.graphicsItems.PlotItem', 'pyqtgraph.graphicsItems.ViewBox', 'pyqtgraph.flowchart', 'pyqtgraph.flowchart.library', 'pyqtgraph.metaarray', 'pyqtgraph.widgets', 'pyqtgraph.dockarea', 'pyqtgraph.canvas', 'pyqtgraph.multiprocess', 'pyqtgraph.imageview', 'pyqtgraph.exporters', 'pyqtgraph.exporters.tests', 'pyqtgraph.console'] + ['pyqtgraph.'+x for x in helpers.listAllPackages(pkgroot='examples')]
+
 
 ## Decide what version string to use in the build
 version, forcedVersion, gitVersion, initVersion = helpers.getVersionStrings(pkg='pyqtgraph')


signature.asc
Description: PGP signature

Bug#919418: kuttypy: FTBFS in sid (pyuic5: Command not found)

[Georges Khaznadar]

Dear Santiago,

thank you for the bug report. I shall fix it today; besides, the author
has published the first stable version yesterday, so the bug fix will
come with the new release.

Best regards,   Georges.

Santiago Vila a écrit :
> Package: src:kuttypy
> Version: 0.1-1
> Severity: serious
> Tags: ftbfs
> 
> Dear maintainer:
> 
> I tried to build this package in sid but it failed:
> 
> 
> [...]
>  debian/rules build-indep
> dh build-indep --with python3
>dh_update_autotools_config -i
>dh_autoreconf -i
>dh_auto_configure -i
>dh_auto_build -i
>   make -j1 "INSTALL=install --strip-program=true"
> make[1]: Entering directory '/<>'
> ?. Using QT Version: PyQt5 pyuic5 pyrcc5 pylupdate5 3
> for d in utilities; do make PYUIC=pyuic5 PYRCC=pyrcc5 PYLUPDATE=pylupdate5 
> PY_VERSION=3 -C $d all; done
> make[2]: Entering directory '/<>/utilities'
> for d in templates; do make -C $d all; done
> make[3]: Entering directory '/<>/utilities/templates'
> PYRCC=pyrcc5
> pyuic5 --from-import dio.ui -o ui_dio.py
> make[3]: pyuic5: Command not found
> make[3]: *** [Makefile:26: ui_dio.py] Error 127
> make[3]: Leaving directory '/<>/utilities/templates'
> make[2]: *** [Makefile:6: recursive_all] Error 2
> make[2]: Leaving directory '/<>/utilities'
> make[1]: *** [Makefile:31: recursive_all] Error 2
> make[1]: Leaving directory '/<>'
> dh_auto_build: make -j1 "INSTALL=install --strip-program=true" returned exit 
> code 2
> make: *** [debian/rules:4: build-indep] Error 2
> dpkg-buildpackage: error: debian/rules build-indep subprocess returned exit 
> status 2
> 
> 
> The build was made in my autobuilder with "dpkg-buildpackage -A"
> but it also fails here:
> 
> https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/kuttypy.html
> 
> If this is really a bug in one of the build-depends, please use reassign and 
> affects,
> so that this is still visible in the BTS web page for this package.
> 
> Thanks.

-- 
Georges KHAZNADAR et Jocelyne FOURNIER
22 rue des mouettes, 59240 Dunkerque France.
Téléphone +33 (0)3 28 29 17 70



signature.asc
Description: PGP signature

Bug#912181: Fixed setup.py

[Georges Khaznadar]

Dear Piotr,

I maintain the package "turing", which build-depends on python-jedi. 
I found the reason why python-jedi FTBFS: setup.py tries to find out
the package's version by parsing jedi/__init__.py, but the parse tree
was interpreted in two different ways, depending on python's version.

I checked that the right expressions to access the package's version is
always `tree.body[1].value.s` and never `tree.body[0].value.s`, so I
simplified the source code.

Please find attached the patch used by quilt to fix this bug.

In case you have no time to publish a new version of your package, I am
pushing it as a NMU into DELAYED+15.

Best regards,       Georges.

-- 
Georges KHAZNADAR et Jocelyne FOURNIER
22 rue des mouettes, 59240 Dunkerque France.
Téléphone +33 (0)3 28 29 17 70

Cleaned out an alternative to assign the variable 'version' for
the package, which was not accessed in the same way, depending on
Python language's version.

It looked like a non-documented workaround to compensate some weird
behavior of an older version of the module ast.
Index: python-jedi-0.12.0/setup.py
===
--- python-jedi-0.12.0.orig/setup.py
+++ python-jedi-0.12.0/setup.py
@@ -11,10 +11,7 @@ __AUTHOR_EMAIL__ = 'davidhalter88@gmail.
 # Get the version from within jedi. It's defined in exactly one place now.
 with open('jedi/__init__.py') as f:
 tree = ast.parse(f.read())
-if sys.version_info > (3, 7):
-version = tree.body[0].value.s
-else:
-version = tree.body[1].value.s
+version = tree.body[1].value.s
 
 readme = open('README.rst').read() + '\n\n' + open('CHANGELOG.rst').read()
 with open('requirements.txt') as f:


signature.asc
Description: PGP signature

Bug#910226: expeyes-web: fails to upgrade from 'stretch': Exception: cannot get content of python3-expeyes

[Georges Khaznadar]

Hello Andreas,

thank you for the scrutiny!

I am fixing this bug in the next release.

Andreas Beckmann a écrit :
> Followup-For: Bug #910226
> Control: found -1 4.4.4+dfsg-3
> 
> The buggy package is *expeyes-web* not python3-expeyes.
> 
> And expeyes-web still has the call to
>   py3compile -p python3-expeyes
> https://salsa.debian.org/georgesk/expeyes/blob/master/debian/expeyes-web.postinst#L68
> where python3-expeyes is clearly the wrong package to be given as an
> argument (and not being installed at the time of the call).
> 
> 
>   Setting up expeyes-web (4.4.4+dfsg-3) ...
>   dpkg-query: package 'python3-expeyes' is not installed
>   Use dpkg --info (= dpkg-deb --info) to examine archive files,
>   and dpkg --contents (= dpkg-deb --contents) to list their contents.
>   Traceback (most recent call last):
> File "/usr/bin/py3compile", line 290, in 
>   main()
> File "/usr/bin/py3compile", line 270, in main
>   options.force, options.optimize, e_patterns)
> File "/usr/bin/py3compile", line 154, in compile
>   for fn, versions_to_compile in filter_files(files, e_patterns, 
> versions):
> File "/usr/bin/py3compile", line 106, in filter_files
>   for fn in files:
> File "/usr/share/python3/debpython/files.py", line 71, in filter_public
>   for fn in files:
> File "/usr/share/python3/debpython/files.py", line 53, in from_package
>   raise Exception("cannot get content of %s" % package_name)
>   Exception: cannot get content of python3-expeyes
>   dpkg: error processing package expeyes-web (--configure):
>subprocess installed post-installation script returned error exit status 1
> 
> 
> Andreas

-- 
Georges KHAZNADAR et Jocelyne FOURNIER
22 rue des mouettes, 59240 Dunkerque France.
Téléphone +33 (0)3 28 29 17 70



signature.asc
Description: PGP signature

Bug#910226: closed by Georges Khaznadar (Bug#910226: fixed in expeyes 4.4.4+dfsg-2)

[Georges Khaznadar]

Hello Andreas,

I shall have a look at the maintainer script, indeed.

However, have you checked whether the upgrade does work? I did it.

The version << 4.3 relied on the bad trick (declaring explicitely the
Python3 compilation), because there was no real python3-, this
package was only Provide(d), which was probably a bad practice, but
worked, since the code was compatible with both Python2 and Python3.

Since version 4.4, as quite all the computers of end-users have
distributions with Python3, we (upstream developers and I) decided to
switch definitely to Python3, so python-expeyes is no longer provided,
and replaced by pyhon3-expeyes, which becomes a plain package. When a
Conflict is declared against the version << 4.4, the old postrm script
is run and there is no interaction between the package from Stretch and
the new package from Buster.

Best regards,   Georges.

Andreas Beckmann a écrit :
> Control: found -1 4.4.4+dfsg-2
> 
> On 2018-10-05 17:54, Debian Bug Tracking System wrote:
> >* added confilcts/replaces for python3-expeyes << 4.3. Closes: #910226
> 
> I don't see how this was supposed to fix the buggy maintainer script in
> this package ...
> 
> Andreas

-- 
Georges KHAZNADAR et Jocelyne FOURNIER
22 rue des mouettes, 59240 Dunkerque France.
Téléphone +33 (0)3 28 29 17 70



signature.asc
Description: PGP signature

Bug#906491: mediawiki2latex: FTBFS in buster/sid (File name does not match module name)

[Georges Khaznadar]

Dear Dirk,

I created a git repository to manage debian packaging at salsa.debian.org,
and then modified slightly one debain patch to take your proposition in
account.

Unfortunately, the package still FTNFS.

Maybe you would like to create an account at https://salsa.debian.org
and either fork and request some pulls or become a direct maintainer of
https://salsa.debian.org/georgesk/mediawiki2latex

Please find attached the build log for my last build attempt, which is
synchronized with the current state of the repository mentioned above.

Best regards,   Georges.

Dirk Hünniger a écrit :
> Hi Georges,
> 
> Hi Santiago,
> 
> to me it looks that the line "Font" in the section "Other-Modules:" in the
> file "mediawiki2latex.cabal" needs to be removed to fix the issue. @Georges
> is it easy for you to create a patch to fix that, or should I better release
> a new version?
> 
> Yours Dirk
> 
> 
> On 17.08.2018 21:22, Santiago Vila wrote:
> > Package: src:mediawiki2latex
> > Version: 7.29-1
> > Severity: serious
> > Tags: ftbfs
> > 
> > Dear maintainer:
> > 
> > I tried to build this package in buster but it failed:
> > 
> > 
> > [...]
> >   debian/rules build-arch
> > dh build-arch
> > dh_update_autotools_config -a
> > debian/rules override_dh_auto_configure
> > make[1]: Entering directory '/<>'
> > ghc /<>/Setup.lhs
> > [1 of 1] Compiling Main ( /<>/Setup.lhs, 
> > /<>/Setup.o )
> > Linking /<>/Setup ...
> > /<>/Setup configure
> > Configuring mediawiki2latex-7.29...
> > make[1]: Leaving directory '/<>'
> > debian/rules override_dh_auto_build
> > make[1]: Entering directory '/<>'
> > /<>/Setup build
> > Preprocessing executable 'mediawiki2latex' for mediawiki2latex-7.29..
> > Building executable 'mediawiki2latex' for mediawiki2latex-7.29..
> > 
> > src/Font.hs:1:1: error:
> >  File name does not match module name:
> >  Saw: `Main'
> >  Expected: `Font'
> >|
> > 1 | import Data.Tuple
> >| ^
> > make[1]: *** [debian/rules:9: override_dh_auto_build] Error 1
> > make[1]: Leaving directory '/<>'
> > make: *** [debian/rules:14: build-arch] Error 2
> > dpkg-buildpackage: error: debian/rules build-arch subprocess returned exit 
> > status 2
> > 
> > 
> > The build was made with "dpkg-buildpackage -B" in my autobuilder.
> > Most probably, it also fails here in reproducible builds:
> > 
> > https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/mediawiki2latex.html
> > 
> > where you can get a full build log if you need it.
> > 
> > If this is really a bug in one of the build-depends, please use reassign 
> > and affects,
> > so that this is still visible in the BTS web page for this package.
> > 
> > Thanks.
> 

-- 
Georges KHAZNADAR et Jocelyne FOURNIER
22 rue des mouettes, 59240 Dunkerque France.
Téléphone +33 (0)3 28 29 17 70

dpkg-checkbuilddeps: error: Unmet build dependencies: ghc libghc-x509-dev 
libghc-pem-dev libghc-regex-compat-dev libghc-http-dev cabal-install 
libghc-hxt-dev libghc-split-dev libghc-blaze-html-dev libghc-file-embed-dev 
libghc-highlighting-kate-dev libghc-hxt-http-dev libghc-regex-pcre-dev 
libghc-temporary-dev libghc-url-dev libghc-utf8-string-dev 
libghc-utility-ht-dev libghc-http-conduit-dev libghc-happstack-server-dev 
libghc-directory-tree-dev libghc-zip-archive-dev libghc-strict-dev 
libghc-network-uri-dev
W: Unmet build-dependency in source
dpkg-source: info: applying 10-Makefile.patch
dpkg-source: info: applying 20-network-uri.patch
dpkg-source: info: applying 30-typos.patch
dh clean
   dh_auto_clean
make -j1 clean
make[1]: Entering directory 
'/home/georgesk/developpement/mediawiki2latex/collab/mediawiki2latex'
rm -rf mediawiki2latex Setup Setup.hi Setup.o ./dist/ mediawiki2latex.1.gz 
mediawiki2latex.1
make[1]: Leaving directory 
'/home/georgesk/developpement/mediawiki2latex/collab/mediawiki2latex'
   dh_clean
dpkg-source: info: using source format '3.0 (quilt)'
dpkg-source: info: building mediawiki2latex using existing 
./mediawiki2latex_7.29.orig.tar.gz
dpkg-source: info: building mediawiki2latex in 
mediawiki2latex_7.29-2.debian.tar.xz
dpkg-source: info: building mediawiki2latex in mediawiki2latex_7.29-2.dsc
I: Generated dsc will be overwritten by build res

Bug#896179: qspeakers FTBFS with Qt 5.10

[Georges Khaznadar]

Hello Benoît,

I am making a few modifications : the VCS repository is changed to
https://salsa.debian.org/georgesk/qspeakers.git, in order to fix the
current error reported about it: 

  Last scan: 2018-04-22 02:10:10+00
  Error: debian/changelog missing in 
svn://svn.gtmp.org/qspeakers/branches/qtcharts/

I shall upload the package shortly.
Please create a guest account at https://signup.salsa.debian.org/, so
you can maintain the package there. Please use git branches and tags
consistently: there should be at least two branches, "master" and
"upstream", which are supposed to differ only by the debian/
subdirectory in the "master" branch. Currently, tags are:

  debian/1.2.0-1
  upstream/1.2.0

New tags should use such a naming scheme.

Best regards,   Georges.


Benoît Rouits a écrit :
> Thank you for your report,
> 
> This has been just fixed upstream, thanks to you.
> The package is waiting to be uploaded by my mentor.
> 
> https://mentors.debian.net/package/qspeakers
> 
>  Benoît
> Le 20/04/2018 à 16:17, Adrian Bunk a écrit :
> > Source: qspeakers
> > Version: 1.1.0-1
> > Severity: serious
> > Tags: buster sid
> > 
> > https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/qspeakers.html
> > 
> > ...
> > g++ -Wl,-z,relro -o qspeakers main.o mainwindow.o speakerdialog.o 
> > speakerdb.o speaker.o importexport.o box.o sealedbox.o portedbox.o 
> > bandpassbox.o plot.o listdialog.o searchdialog.o system.o moc_mainwindow.o 
> > moc_speakerdialog.o moc_plot.o moc_listdialog.o moc_searchdialog.o   
> > -lQt5PrintSupport -lQt5Widgets -lQt5Gui -lQt5Xml -lQt5Core -lGL -lpthread 
> > plot.o: In function `Plot::~Plot()':
> > qspeakers_1.1.0-1/plot.cpp:34: undefined reference to 
> > `QtCharts::QXYSeries::clear()'
> > plot.o: In function `Plot::initializeCurve()':
> > qspeakers_1.1.0-1/plot.cpp:67: undefined reference to 
> > `QtCharts::QLineSeries::QLineSeries(QObject*)'
> > qspeakers_1.1.0-1/plot.cpp:68: undefined reference to 
> > `QtCharts::QAbstractSeries::setUseOpenGL(bool)'
> > ...
> > 
> > 
> > Due to the following in qspeakers.pro:
> > greaterThan(QT_VERSION, 5.8): QT += charts
> > 
> > This is interpreted as float, so 5.10 < 5.8
> > 

-- 
Georges KHAZNADAR et Jocelyne FOURNIER
22 rue des mouettes, 59240 Dunkerque France.
Téléphone +33 (0)3 28 29 17 70



signature.asc
Description: PGP signature

Bug#895499: enki-aseba FTBFS on armel/armhf: error: 'glGenLists' was not declared in this scope

[Georges Khaznadar]

Dear Adrian,

thank you for the enlightenment!

Adrian Bunk a écrit :
> [...] 
> The root cause is that on armel/armhf (and arm64 in Ubuntu)
> Qt5 is compiled with OpenGL ES instead of OpenGL.
> 
> enki-aseba should be fixed to build and work with OpenGL ES,

I shall ask upstream developers whether this is part of their scheduled
actions.

> but if this is not easily possible please
> - change the build dependency from libqt5opengl5-dev
>   to libqt5opengl5-desktop-dev, and
> - file a removal bug for the old armel+armhf binaries
>   of enki-aseba and aseba against ftp.debian.org

Just to be sure: if the build-dependency is on libqt5opengl5-desktop-dev
instead of libqt5opengl5-dev, the package would cease to be built for
armel/armhf, isn't it ?

Or should I rather replace Target: all by an explicit list of targets
for this package?

Thank you in advance for your reply.

-- 
Georges KHAZNADAR et Jocelyne FOURNIER
22 rue des mouettes, 59240 Dunkerque France.
Téléphone +33 (0)3 28 29 17 70



signature.asc
Description: PGP signature

Bug#894636: falkon: Incomplete debian/copyright?

[Georges Khaznadar]

Thank you Chris, I shall check more thoroughly missing copyright notices.

Best regards,   Georges.

Chris Lamb a écrit :
> Source: falkon
> Version: 3.0.0-1
> Severity: serious
> Justication: Policy 12.5
> X-Debbugs-CC: Georges Khaznadar 
> 
> Hi,
> 
> I just ACCEPTed falkon from NEW but noticed it was missing 
> attribution in debian/copyright for at least the MouseGestures,
> PIM, and ImageFinder plugins.
> 
> This is in no way exhaustive so please check over the entire
> package  carefully and address these on your next upload; thanks!
> 
> 
> Regards,
> 
> -- 
>   ,''`.
>  : :'  : Chris Lamb
>  `. `'`  la...@debian.org / chris-lamb.co.uk
>`-

-- 
Georges KHAZNADAR et Jocelyne FOURNIER
22 rue des mouettes, 59240 Dunkerque France.
Téléphone +33 (0)3 28 29 17 70



signature.asc
Description: PGP signature

Bug#890031: aseba: frequent parallel FTBFS

[Georges Khaznadar]

Thank you Adrian!

I shall upload a fixed revision immediately.

Best regards,   Georges.

Adrian Bunk a écrit :
> Source: aseba
> Version: 1.6.0-1
> Severity: serious
> Tags: patch
> 
> https://buildd.debian.org/status/package.php?p=aseba&suite=sid
> 
> ...
> [ 78%] Built target asebaqtplugins
> make -f clients/studio/CMakeFiles/asebastudio.dir/build.make 
> clients/studio/CMakeFiles/asebastudio.dir/depend
> make -f clients/studio/CMakeFiles/thymiovpl.dir/build.make 
> clients/studio/CMakeFiles/thymiovpl.dir/depend
> make -f clients/studio/CMakeFiles/rendervplblocks.dir/build.make 
> clients/studio/CMakeFiles/rendervplblocks.dir/depend
> make[3]: Entering directory '/<>/obj-powerpc64le-linux-gnu'
> make[3]: Entering directory '/<>/obj-powerpc64le-linux-gnu'
> make[3]: Entering directory '/<>/obj-powerpc64le-linux-gnu'
> [ 79%] Generating aseba-doc.qch
> [ 79%] Generating aseba-doc.qch
> [ 79%] Generating aseba-doc.qch
> cd /<>/obj-powerpc64le-linux-gnu/clients/studio && 
> /usr/lib/powerpc64le-linux-gnu/qt4/bin/qhelpgenerator 
> /<>/clients/studio/aseba-doc.qhp -o 
> /<>/obj-powerpc64le-linux-gnu/clients/studio/aseba-doc.qch
> cd /<>/obj-powerpc64le-linux-gnu/clients/studio && 
> /usr/lib/powerpc64le-linux-gnu/qt4/bin/qhelpgenerator 
> /<>/clients/studio/aseba-doc.qhp -o 
> /<>/obj-powerpc64le-linux-gnu/clients/studio/aseba-doc.qch
> cd /<>/obj-powerpc64le-linux-gnu/clients/studio && 
> /usr/lib/powerpc64le-linux-gnu/qt4/bin/qhelpgenerator 
> /<>/clients/studio/aseba-doc.qhp -o 
> /<>/obj-powerpc64le-linux-gnu/clients/studio/aseba-doc.qch
> Cannot register namespace aseba.main!
> Building up file structure...
> clients/studio/CMakeFiles/thymiovpl.dir/build.make:193: recipe for target 
> 'clients/studio/aseba-doc.qch' failed
> make[3]: *** [clients/studio/aseba-doc.qch] Error 255
> 
> 
> Generating the same file 3 times in parallel is simply wrong.
> 
> Note that this does not depend on the architecture,
> it is just more likely to FTBFS with higher levels
> of parallelism:
> "dpkg-buildpackage -J1" builds on ppc64el and
> "dpkg-buildpackage -J100" FTBFS on amd64.
> 
> The proper fix would be to fix the parallel build,
> but if that is not easily possible the following
> change to disable parallel building would be
> sufficient:
> 
> --- debian/rules.old  2018-02-10 10:05:25.449354215 +
> +++ debian/rules  2018-02-10 10:05:36.221354113 +
> @@ -15,6 +15,6 @@
>  
>  
>  %:
> - dh $@
> + dh $@ --no-parallel
>  
>  

-- 
Georges KHAZNADAR et Jocelyne FOURNIER
22 rue des mouettes, 59240 Dunkerque France.
Téléphone +33 (0)3 28 29 17 70



signature.asc
Description: PGP signature

Bug#885875: seelablet: Depends on python-appindicator

[Georges Khaznadar]

Dear Jeremy,

thank you for this bug report.

I contacted Seelablet's author: he will not maintain this package in a
foreseeable future. On reason is that the hardware addressed by the
package seelablet is discontinued, and that he developped an new
hardware, known as expeyes17, with similar features, and which already
has received a noticeable success.

As expeyes17 is supported by the debian package eyes17, which I
maintain, I think that the bes solution would be to ask for the removal
of seelablet from debian/sid and debian/buster.

As there are less than a hundred users of Seelablet box in the world,
its author says me that he can support these users with a custom
package, while a package in debian/stretch would be less useful. So this
package may be removed from debian/stretch too.

I filed a RM bug report.

Best regards,   Georges.

Jeremy Bicha a écrit :
> Source: seelablet
> Version: 1.0.6-2
> Severity: serious
> User: pkg-gnome-maintain...@lists.alioth.debian.org
> Usertags: oldlibs
> Tags: sid buster
> 
> python-seelablet depends on python-appindicator but python3-seelablet
> depends on gir1.2-appindicator3-0.1
> 
> The gir dependency is wrong since as far as I can tell seelablet
> doesn't use GObject Introspection at all. I *think* the python-
> appindicator dependency is wrong too because I thought python-
> appindicator required gtk and this doesn't use gtk at all.
> 
> (I can't actually tell if it works because I can't get the app to run.
> Filing a separate bug for that.)
> 
> I'm filing this bug as Serious since this is the last package keeping
> python-appindicator from being removable in Testing.
> 
> On behalf of the Debian GNOME team,
> Jeremy Bicha

-- 
Georges KHAZNADAR et Jocelyne FOURNIER
22 rue des mouettes, 59240 Dunkerque France.
Téléphone +33 (0)3 28 29 17 70



signature.asc
Description: PGP signature

Bug#853635: closing #853635 qwtplot3d: ftbfs with GCC-7

[Georges Khaznadar]

Hello,

I uploaded a new version of qwtplot3d, with no change in the source
tree, but a new version number to prevent collisions with other variants
of the package like backports, when .symbols files are modified.
The package is in the queue DELAYED+10

I initialized the files debian/*.symbols, which allows me to build the
package with gcc-7.

Here is the lintian output, after a build in a fresh Sid chroot:

+++ lintian output +++
I: qwtplot3d source: vcs-field-uses-insecure-uri vcs-svn
svn://anonscm.debian.org/debian-science/packages/qwtplot3d/trunk/
I: qwtplot3d source: testsuite-autopkgtest-missing
W: libqwtplot3d-doc: embedded-javascript-library
usr/share/doc/libqwtplot3d-doc/html/jquery.js please use libjs-jquery
I: libqwtplot3d-qt4-0v5: no-symbols-control-file
usr/lib/libqwtplot3d-qt4.so.0.2.7
I: libqwtplot3d-qt5-0: no-symbols-control-file
usr/lib/libqwtplot3d-qt5.so.0.2.7
+++ end of lintian output +++

I made no changes in anonscm.debian.org/debian-science/packages/

If somebody wants to improve the packaging, there are 10 days left.
I need this package to enter Buster, since I maintain scidavis which
depends on it.

Best regards,   Georges.
-- 
Georges KHAZNADAR et Jocelyne FOURNIER
22 rue des mouettes, 59240 Dunkerque France.
Téléphone +33 (0)3 28 29 17 70



signature.asc
Description: PGP signature

Bug#859535: Fixed the versioned dependency on autoconf

[Georges Khaznadar]

Hello, I fixed the obsoleted build-dependency, and uploaded package as a
NMU into delayed-10.

Best regards,   Georges.

-- 
Georges KHAZNADAR et Jocelyne FOURNIER
22 rue des mouettes, 59240 Dunkerque France.
Téléphone +33 (0)3 28 29 17 70



signature.asc
Description: PGP signature

Bug#828525: qupzilla: diff for NMU version 1.8.9~dfsg1-3.1

[Georges Khaznadar]

Thank you very much, Andrey!

Andrey Rahmatullin a écrit :
> 
> 
> Dear maintainer,
> 
> I've prepared an NMU for qupzilla (versioned as 1.8.9~dfsg1-3.1). The diff
> is attached to this message.
> 
> Regards.
> 
> -- 
> WBR, wRAR

> diff -Nru qupzilla-1.8.9~dfsg1/debian/changelog 
> qupzilla-1.8.9~dfsg1/debian/changelog
> --- qupzilla-1.8.9~dfsg1/debian/changelog 2016-01-23 20:42:31.0 
> +0500
> +++ qupzilla-1.8.9~dfsg1/debian/changelog 2016-12-18 20:22:33.0 
> +0500
> @@ -1,3 +1,10 @@
> +qupzilla (1.8.9~dfsg1-3.1) unstable; urgency=medium
> +
> +  * Non-maintainer upload.
> +  * Build with OpenSSL 1.0 (Closes: #828525).
> +
> + -- Andrey Rahmatullin   Sun, 18 Dec 2016 20:22:33 +0500
> +
>  qupzilla (1.8.9~dfsg1-3) unstable; urgency=medium
>  
>* removed the dependency on libqt5xcbqpa5. Closes: #812233
> diff -Nru qupzilla-1.8.9~dfsg1/debian/control 
> qupzilla-1.8.9~dfsg1/debian/control
> --- qupzilla-1.8.9~dfsg1/debian/control   2016-01-23 20:42:16.0 
> +0500
> +++ qupzilla-1.8.9~dfsg1/debian/control   2016-12-18 20:22:33.0 
> +0500
> @@ -7,7 +7,7 @@
>   qtbase5-private-dev, qtscript5-dev,
>   libqt5x11extras5-dev,
>   libx11-dev,
> - libssl-dev, kdelibs5-dev, libgnome-keyring-dev,
> + libssl1.0-dev | libssl-dev (<< 1.1.0~), kdelibs5-dev, libgnome-keyring-dev,
>   libjs-jquery, libjs-jquery-ui
>  Standards-Version: 3.9.7
>  Homepage: http://www.qupzilla.com/





signature.asc
Description: PGP signature

Bug#833758: zegrapher: diff for NMU version 3.0-1.1

[Georges Khaznadar]

Dear Mattia,

thank you for the NMU.

Best regards,   Georges.

Mattia Rizzolo a écrit :
> Control: tags 833758 + patch
> Control: tags 833758 + pending
> 
> Dear maintainer,
> 
> I've prepared an NMU for zegrapher (versioned as 3.0-1.1) and
> uploaded it to DELAYED/5. Please feel free to tell me if I
> should delay it longer.
> 
> Regards.
> 
> -- 
> regards,
> Mattia Rizzolo
> 
> GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
> more about me:  https://mapreri.org : :'  :
> Launchpad user: https://launchpad.net/~mapreri  `. `'`
> Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-

> diffstat for zegrapher-3.0 zegrapher-3.0
> 
>  changelog |8 
>  control   |2 +-
>  2 files changed, 9 insertions(+), 1 deletion(-)
> 
> diff -Nru zegrapher-3.0/debian/changelog zegrapher-3.0/debian/changelog
> --- zegrapher-3.0/debian/changelog2016-04-23 20:24:29.0 +
> +++ zegrapher-3.0/debian/changelog2016-08-11 09:03:38.0 +
> @@ -1,3 +1,11 @@
> +zegrapher (3.0-1.1) unstable; urgency=medium
> +
> +  * Non-maintainer upload.
> +  * Build-depend on unversioned boost.  Also, depend only on 
> libboost-math-dev
> +instead of all of boost.  Closes: #833758
> +
> + -- Mattia Rizzolo   Thu, 11 Aug 2016 09:03:38 +
> +
>  zegrapher (3.0-1) unstable; urgency=medium
>  
>* upgraded to the new upstream version
> diff -Nru zegrapher-3.0/debian/control zegrapher-3.0/debian/control
> --- zegrapher-3.0/debian/control  2016-04-23 20:24:09.0 +
> +++ zegrapher-3.0/debian/control  2016-08-11 09:03:19.0 +
> @@ -4,7 +4,7 @@
>  Maintainer: Georges Khaznadar 
>  Build-Depends: debhelper (>= 9.0.0),
>   qt5-qmake, qt5-default, qtbase5-dev, libqt5webkit5-dev,
> - libboost1.60-dev
> + libboost-math-dev,
>  Standards-Version: 3.9.7
>  Homepage: http://zegrapher.com/
>  





signature.asc
Description: PGP signature

Bug#817789: Fixed the bug

[Georges Khaznadar]

Hi,
It was just adding a new dependency.

I need blogdiag as a dependency of seelablet, so I have made a NMU to
delayed+9.

Tell me if you prefer managing this bug report in some other way.

Best regards,   Georges.

-- 
Georges KHAZNADAR et Jocelyne FOURNIER
22 rue des mouettes, 59240 Dunkerque France.
Téléphone +33 (0)3 28 29 17 70



signature.asc
Description: PGP signature

Bug#814790: scolasync: FTBFS: Paragraph ended before \verbatim@ was complete.

[Georges Khaznadar]

Hello Chris, thank you for the report.

The problem comes probably from some instability in packages doxypy or
doxygen.

I shall prebuild the PDF file with a version of doxy tools which does the
job now.

Best regards,   Georges.

Chris Lamb a écrit :
> Source: scolasync
> Version: 5.1-1
> Severity: serious
> Justification: fails to build from source
> User: reproducible-bui...@lists.alioth.debian.org
> Usertags: ftbfs
> X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org
> 
> Dear Maintainer,
> 
> scolasync fails to build from source in unstable/amd64:
> 
>   [..]
> 
>   espacesrc_1_1db_a6628948dc0e29baf0d368288dbb676be_cgraph.pdf>])
>   (./namespacesrc_1_1debug.tex
>   Runaway argument?
>   fonction pour passer la paramètre mw à la fonction de rappel cb\end \ETC.
>   ! Paragraph ended before \verbatim@ was complete.
>
>  \par 
>   l.41 \end{DoxyParams}
>
>   ? 
>   ! Emergency stop.
>
>  \par 
>   l.41 \end{DoxyParams}
>
>   !  ==> Fatal error occurred, no output PDF file produced!
>   Transcript written on refman.log.
>   for d in src; do make all -C $d 
> DESTDIR=/home/lamby/temp/cdt.20160215130548.zO8lxKc2mT/scolasync-5.1/debian/scolasync;
>  done
>   make[2]: Entering directory 
> '/home/lamby/temp/cdt.20160215130548.zO8lxKc2mT/scolasync-5.1/src'
>   make -C lang all
>   make[3]: Entering directory 
> '/home/lamby/temp/cdt.20160215130548.zO8lxKc2mT/scolasync-5.1/src/lang'
>   pylupdate5 -verbose scolasync.pro
>   Updating 'en_US.ts'...
>   Found 167 source texts (2 new and 165 already existing)
>   Updating 'fr_FR.ts'...
>   Found 166 source texts (1 new and 165 already existing)
>   Updating 'pt_PT.ts'...
>   Found 167 source texts (2 new and 165 already existing)
>   lrelease -qt5 *.ts 2>/dev/null || true
>   Updating 'en_US.qm'...
>   Generated 122 translation(s) (119 finished and 3 unfinished)
>   Ignored 11 untranslated source text(s)
>   Updating 'fr_FR.qm'...
>   Generated 9 translation(s) (9 finished and 0 unfinished)
>   Ignored 154 untranslated source text(s)
>   Updating 'pt_PT.qm'...
>   Generated 78 translation(s) (74 finished and 4 unfinished)
>   Ignored 87 untranslated source text(s)
>   make[3]: Leaving directory 
> '/home/lamby/temp/cdt.20160215130548.zO8lxKc2mT/scolasync-5.1/src/lang'
>   make[2]: Leaving directory 
> '/home/lamby/temp/cdt.20160215130548.zO8lxKc2mT/scolasync-5.1/src'
>   install -d 
> /home/lamby/temp/cdt.20160215130548.zO8lxKc2mT/scolasync-5.1/debian/scolasync/usr/share/scolasync/html
>   cp -R doc/html/* 
> /home/lamby/temp/cdt.20160215130548.zO8lxKc2mT/scolasync-5.1/debian/scolasync/usr/share/scolasync/html/
>   install -d 
> /home/lamby/temp/cdt.20160215130548.zO8lxKc2mT/scolasync-5.1/debian/scolasync/usr/share/scolasync/pdf
>   install -m 644 doc/latex/refman.pdf 
> /home/lamby/temp/cdt.20160215130548.zO8lxKc2mT/scolasync-5.1/debian/scolasync/usr/share/scolasync/pdf
>   install: cannot stat 'doc/latex/refman.pdf': No such file or directory
>   Makefile:11: recipe for target 'install' failed
>   make[1]: *** [install] Error 1
>   make[1]: Leaving directory 
> '/home/lamby/temp/cdt.20160215130548.zO8lxKc2mT/scolasync-5.1'
>   dh_auto_install: make -j1 install 
> DESTDIR=/home/lamby/temp/cdt.20160215130548.zO8lxKc2mT/scolasync-5.1/debian/scolasync
>  AM_UPDATE_INFO_DIR=no returned exit code 2
>   debian/rules:13: recipe for target 'binary' failed
>   make: *** [binary] Error 2
> 
>   [..]
> 
> The full build log is attached.
> 
> 
> Regards,
> 
> -- 
>   ,''`.
>  : :'  : Chris Lamb
>  `. `'`  la...@debian.org / chris-lamb.co.uk
>`-



-- 
Georges KHAZNADAR et Jocelyne FOURNIER
22 rue des mouettes, 59240 Dunkerque France.
Téléphone +33 (0)3 28 29 17 70



signature.asc
Description: PGP signature

Bug#813270: python3 stuff but no python3 dependency

[Georges Khaznadar]

Hello Mattia,

thank you for your fast notice!

Mattia Rizzolo a écrit :
> Source: pysatellites
> Version: 2.2-2
> Severity: serious
> 
> Dear maintainer,
> 
> It seems to me that python-satellites builds python3 stuff, it has
> several py3 dependencies, etc.
> But there is no python3 direct dependency, which is bad.
> That's because you're using ${python:Depends} instead of
> ${python3:Depends}.  I read in #813219 that you used to not be able to
> understand what it generated, feel free to ask I'm happy to explain it
> :)

I did not keep the file substvars which was made, but I remember that at
some time a dependency on a non-existing package had been automatically
generated. If I see something similar in the future, I shall try to
trigger the same error with a minimal package and report a bug.

Now I replaced ${python:Depends} by ${python3:Depends}, then launched
"debuild", and had a look at the file python-satellites.substvars
this file contains:
--8<
misc:Depends=
misc:Pre-Depends=
--8<

Should I raise a bug report? the environment used was not a chroot made
by pbuilder, and dh-python came in version 2.20150826.

> and btw, you build-depend on python2 packages, maybe you are more
> interested in python3 ones? (or at this point thet are maybe useless and
> just remove them?)

You are right! I only need the package which contains pyuic4 to convert
user interfaces designed with Qt designer.


> Then, the package name does not follow the debian python policy,
> according to which you should name it python3-satellites, the name you
> are currently using kind of imply python2 stuff (but this point is just
> a remark, the actual bug is about the first paragraph).

humm.. As this package does not create libraries very useful for other
developers, I suppose that it might as well be treated as a private
library: so the scripts should rather go to /usr/share/pysatellites, and
the package should just be named "pysatellites" rather than
python3-satellites. What do you think about it?

Best regards,   Georges

-- 
Georges KHAZNADAR et Jocelyne FOURNIER
22 rue des mouettes, 59240 Dunkerque France.
Téléphone +33 (0)3 28 29 17 70



signature.asc
Description: PGP signature

Bug#813219: python-satellites: uninstallable in sid: unsatisfiable Depends: python (>= 3.2) | python3.2

[Georges Khaznadar]

Hello Andreas,

Andreas Beckmann a écrit :
> Package: python-satellites
> Version: 2.2-1
> Severity: serious
> User: debian...@lists.debian.org
> Usertags: piuparts
> 
> Hi,
> 
> during a test with piuparts I noticed your package is no longer
> installable in sid:
> 
> unsatisfiable Depends: python (>= 3.2) | python3.2

When I compiled it last time with in a Sid chroot, python:Depends gave a
weird dependency which I did not understand. When I compile it right
now, the problem has vanished.

I shall upload the new package shortly.



signature.asc
Description: PGP signature

Bug#808195: uicilibris: deprecation of python-support

[Georges Khaznadar]

Thank you Mattia,

you patch is part of the new uploaded package, I upgraded a few features
and repacked uicilibris to comply better with lintian.

Best regards,   Georges.

Mattia Rizzolo a écrit :
> On Thu, Dec 17, 2015 at 02:07:55AM +, Mattia Rizzolo wrote:
> > Attached there is a patch that is really enough to fix this, and I'd be
> > happy to do a minimal NMU of it.
> 
> the 'y' key is just more handy than the 'a', sorry.
> Here is the patch :)
> 
> -- 
> regards,
> Mattia Rizzolo
> 
> GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
> more about me:  http://mapreri.org  : :'  :
> Launchpad user: https://launchpad.net/~mapreri  `. `'`
> Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-

> diffstat for uicilibris-1.12 uicilibris-1.12
> 
>  changelog |7 +++
>  control   |2 +-
>  rules |4 ++--
>  3 files changed, 10 insertions(+), 3 deletions(-)
> 
> diff -Nru uicilibris-1.12/debian/changelog uicilibris-1.12/debian/changelog
> --- uicilibris-1.12/debian/changelog  2013-01-03 22:50:27.0 +
> +++ uicilibris-1.12/debian/changelog  2015-12-17 02:03:47.0 +
> @@ -1,3 +1,10 @@
> +uicilibris (1.12-1.1) UNRELEASED; urgency=medium
> +
> +  * Non-maintainer upload.
> +  * Build with dh-python instead of python-support.
> +
> + -- Mattia Rizzolo   Thu, 17 Dec 2015 02:03:39 +
> +
>  uicilibris (1.12-1) unstable; urgency=low
>  
>* implemented a specific template for ISN:creditphoto
> diff -Nru uicilibris-1.12/debian/control uicilibris-1.12/debian/control
> --- uicilibris-1.12/debian/control    2012-12-29 19:43:18.0 +
> +++ uicilibris-1.12/debian/control2015-12-17 02:03:28.0 +
> @@ -3,7 +3,7 @@
>  Priority: extra
>  Maintainer: Georges Khaznadar 
>  Build-Depends: debhelper (>= 8.0.0), python-all,
> - pyqt4-dev-tools, qt4-linguist-tools
> + pyqt4-dev-tools, qt4-linguist-tools, dh-python
>  Standards-Version: 3.9.3
>  Homepage: http://georges.khaznadar.fr/uicilibris
>  
> diff -Nru uicilibris-1.12/debian/rules uicilibris-1.12/debian/rules
> --- uicilibris-1.12/debian/rules  2011-12-19 18:09:14.0 +
> +++ uicilibris-1.12/debian/rules  2015-12-17 02:03:35.0 +
> @@ -10,11 +10,11 @@
>  #export DH_VERBOSE=1
>  
>  %:
> - dh $@ 
> + dh $@ --with python2
>  
>  override_dh_auto_install:
>   dh_auto_install
>   # replace relative paths to system icons by absolute paths
>   for f in $$(find debian/uicilibris/usr -name "Ui_*.py"); do \
> sed 's%".*\(/usr/share/icons/Tango/.*\)"%"\1"%' $$f > $$f.tmp && mv 
> $$f.tmp $$f; \
> - done
> \ No newline at end of file
> + done




-- 
Georges KHAZNADAR et Jocelyne FOURNIER
22 rue des mouettes, 59240 Dunkerque France.
Téléphone +33 (0)3 28 29 17 70



signature.asc
Description: PGP signature

Bug#808165: jsxgraph: deprecation of python-support

[Georges Khaznadar]

Thank you Mattia,

I shall use your patch, and apply it while building the newest package
for jsxgraph, with version 0.99.3, to be uploaded shortly.

Best regards,   Georges.

Mattia Rizzolo a écrit :
> Package: jsxgraph
> Version: 0.98~dfsg1-3
> Severity: serious
> Tags: patch sid stretch
> User: debian-pyt...@lists.debian.org
> Usertags: pysupport-deprecation
> 
> Dear Maintainer,
> 
> your package either depends on the python-support package.
> 
> python-support has been deprecated for some time (since 2011), and we're
> currently in the process of removing it in favour of dh_python2.
> 
> Unfortunately your package went unnoticed till now, where we're on an
> advanced state of the transition, with very few blocker, so I'm sorry
> for the severity and the short notice of this bug report.
> 
> Attached there is a patch that is really enough to fix this, and I'd be
> happy to do a minimal NMU of it.
> 
> Thanks!
> 
> 
> -- 
> regards,
> Mattia Rizzolo
> 
> GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
> more about me:  http://mapreri.org  : :'  :
> Launchpad user: https://launchpad.net/~mapreri  `. `'`
> Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-

> diffstat for jsxgraph-0.98~dfsg1 jsxgraph-0.98~dfsg1
> 
>  changelog |7 +++
>  control   |5 ++---
>  rules |2 +-
>  3 files changed, 10 insertions(+), 4 deletions(-)
> 
> diff -Nru jsxgraph-0.98~dfsg1/debian/changelog 
> jsxgraph-0.98~dfsg1/debian/changelog
> --- jsxgraph-0.98~dfsg1/debian/changelog  2014-01-13 17:56:20.0 
> +
> +++ jsxgraph-0.98~dfsg1/debian/changelog  2015-12-16 17:27:23.0 
> +
> @@ -1,3 +1,10 @@
> +jsxgraph (0.98~dfsg1-3.1) UNRELEASED; urgency=medium
> +
> +  * Non-maintainer upload.
> +  * Build using dh-python instead of python-support.
> +
> + -- Mattia Rizzolo   Wed, 16 Dec 2015 17:27:12 +
> +
>  jsxgraph (0.98~dfsg1-3) unstable; urgency=low
>  
>* added build-dependencies node-uglify and zip, thanks to 
> diff -Nru jsxgraph-0.98~dfsg1/debian/control 
> jsxgraph-0.98~dfsg1/debian/control
> --- jsxgraph-0.98~dfsg1/debian/control2014-01-13 17:56:28.0 
> +
> +++ jsxgraph-0.98~dfsg1/debian/control2015-12-16 17:26:21.0 
> +
> @@ -4,14 +4,13 @@
>  Maintainer: Georges Khaznadar 
>  Build-Depends: debhelper (>= 7.0.50~), quilt
>  Build-Depends-Indep: jsdoc-toolkit (>=2.4.0+dfsg-3), yui-compressor,
> - node-almond, node-requirejs, node-uglify, zip
> + node-almond, node-requirejs, node-uglify, zip, python, dh-python
>  Standards-Version: 3.9.5
>  Homepage: http://jsxgraph.uni-bayreuth.de/cms/index.php
>  
>  Package: jsxgraph
>  Architecture: all
> -Depends: ${misc:Depends}, libjs-prototype, libjs-jquery,
> - python-support (>= 0.90), python
> +Depends: ${misc:Depends}, ${python:Depends}, libjs-prototype, libjs-jquery
>  Suggests: jsxgraph-examples
>  Description: Interactive Geometry with JavaScript
>   JSXGraph is a cross-browser library to display interactive geometry in a
> diff -Nru jsxgraph-0.98~dfsg1/debian/rules jsxgraph-0.98~dfsg1/debian/rules
> --- jsxgraph-0.98~dfsg1/debian/rules  2013-11-01 15:39:52.0 +
> +++ jsxgraph-0.98~dfsg1/debian/rules  2015-12-16 17:26:38.0 +
> @@ -10,7 +10,7 @@
>  #export DH_VERBOSE=1
>  
>  %:
> - dh $@ 
> + dh $@ --with python2
>  
>  get_latest_source:
>   debian/get-latest-source




-- 
Georges KHAZNADAR et Jocelyne FOURNIER
22 rue des mouettes, 59240 Dunkerque France.
Téléphone +33 (0)3 28 29 17 70



signature.asc
Description: PGP signature

Bug#791228: nmu diff for openlayer 2.1-1.1

[Georges Khaznadar]

Thank you for your help, Julien, I most appreciate it.

Best regards,   Georges.

Julien Cristau a écrit :
> Dear maintainer,
> 
> I've prepared a NMU for openlayer, to deal with the libstdc++ transition,
> and will shortly upload it to the 1-day delayed queue.  Please find the
> debdiff below.
> 
> Cheers,
> Julien
> 
> >From af9554c3a2d12da40f78f567550da4c4779ae2da Mon Sep 17 00:00:00 2001
> From: Julien Cristau 
> Date: Sun, 16 Aug 2015 17:51:28 +0200
> Subject: [PATCH] Rename library packages for g++5 ABI transition (closes:
>  791228).
> 
> ---
>  debian/changelog   | 7 +++
>  debian/control | 6 --
>  debian/libopenlayer2.dirs  | 1 -
>  debian/libopenlayer2.install   | 1 -
>  debian/libopenlayer2v5.dirs| 1 +
>  debian/libopenlayer2v5.install | 1 +
>  6 files changed, 13 insertions(+), 4 deletions(-)
>  delete mode 100644 debian/libopenlayer2.dirs
>  delete mode 100644 debian/libopenlayer2.install
>  create mode 100644 debian/libopenlayer2v5.dirs
>  create mode 100644 debian/libopenlayer2v5.install
> 
> diff --git a/debian/changelog b/debian/changelog
> index f404683..6eda24b 100644
> --- a/debian/changelog
> +++ b/debian/changelog
> @@ -1,3 +1,10 @@
> +openlayer (2.1-1.1) unstable; urgency=medium
> +
> +  * Non-maintainer upload.
> +  * Rename library packages for g++5 ABI transition (closes: 791228).
> +
> + -- Julien Cristau   Sun, 16 Aug 2015 17:51:28 +0200
> +
>  openlayer (2.1-1) unstable; urgency=low
>  
>* Initial release (Closes: #735016)
> diff --git a/debian/control b/debian/control
> index 6f1eb5f..36dc57e 100644
> --- a/debian/control
> +++ b/debian/control
> @@ -9,9 +9,11 @@ Build-Depends: debhelper (>= 8.0.0), cmake, 
> hardening-wrapper,
>  Standards-Version: 3.9.5
>  Homepage: http://openlayer.berlios.de/
>  
> -Package: libopenlayer2
> +Package: libopenlayer2v5
>  Architecture: any
>  Depends: ${shlibs:Depends}, ${misc:Depends}
> +Conflicts: libopenlayer2
> +Replaces: libopenlayer2
>  Description: hardware accelerated 2D Graphics library
>   OpenLayer is a hardware accelerated 2D Graphics library. It specifies
>   a new api to be used alongside of Allegro and takes control of how
> @@ -21,7 +23,7 @@ Description: hardware accelerated 2D Graphics library
>  Package: libopenlayer-dev
>  Section: libdevel
>  Architecture: any
> -Depends: ${shlibs:Depends}, ${misc:Depends}, libopenlayer2 (= 
> ${binary:Version})
> +Depends: ${shlibs:Depends}, ${misc:Depends}, libopenlayer2v5 (= 
> ${binary:Version})
>  Description: hardware accelerated 2D Graphics library : development files
>   OpenLayer is a hardware accelerated 2D Graphics library. It specifies
>   a new api to be used alongside of Allegro and takes control of how
> diff --git a/debian/libopenlayer2.dirs b/debian/libopenlayer2.dirs
> deleted file mode 100644
> index 6845771..000
> --- a/debian/libopenlayer2.dirs
> +++ /dev/null
> @@ -1 +0,0 @@
> -usr/lib
> diff --git a/debian/libopenlayer2.install b/debian/libopenlayer2.install
> deleted file mode 100644
> index 86eca04..000
> --- a/debian/libopenlayer2.install
> +++ /dev/null
> @@ -1 +0,0 @@
> -usr/lib/libopenlayer.so.*
> \ No newline at end of file
> diff --git a/debian/libopenlayer2v5.dirs b/debian/libopenlayer2v5.dirs
> new file mode 100644
> index 000..6845771
> --- /dev/null
> +++ b/debian/libopenlayer2v5.dirs
> @@ -0,0 +1 @@
> +usr/lib
> diff --git a/debian/libopenlayer2v5.install b/debian/libopenlayer2v5.install
> new file mode 100644
> index 000..86eca04
> --- /dev/null
> +++ b/debian/libopenlayer2v5.install
> @@ -0,0 +1 @@
> +usr/lib/libopenlayer.so.*
> \ No newline at end of file
> -- 
> 2.5.0
> 

-- 
Georges KHAZNADAR et Jocelyne FOURNIER
22 rue des mouettes, 59240 Dunkerque France.
Téléphone +33 (0)3 28 29 17 70



signature.asc
Description: Digital signature

Bug#784975: partclone: FTBFS on non x86 arches: error: unrecognized command line option '-m32'

[Georges Khaznadar]

Thank you for the bug report, James.

The binary file fail-mbr.bin can be built only with a (real or emulated) 
x-86 machine; however it makes sense to install it in a non-x-86 server,
since partclone can use it while restoring an x-86 client.

So, what may I do? 

I suggest to include fail-mbr.bin in the package's source, and override
the lintian error, while documenting that this file comes with its
source.

On the other hand, such a method cannot be recommended : the same
argument might be used for any arbitrary binary file, and a boot sector
can be considered as a very sensitive piece of software.

Please have you some suggestion, do you know other methods to build this
file only with *one* architecture, and declare it as available for "all"
architectures? This would enforce its build from sources in the debian
build farm.

The closest issue which I could imagine among debian packages is the
build system of the package firmware-free; however I could not
understand, while inspecting loosely this package, whether there were
real source files in the package and whether there is any chance to
buils any binary from source. When I try to debuild this package with an
amd64 machine, nothing is built, binaries are just copied.

Best regards,   Georges.

James Cowgill a écrit :
> Source: partclone
> Version: 0.2.78-1
> Severity: serious
> 
> Hi,
> 
> partclone failed to build on all non-x86 arches with this error:
> 
> > Making all in fail-mbr
> > make[3]: Entering directory '/«PKGBUILDDIR»/fail-mbr'
> > gcc -Wall -Werror -m32 -nostdlib -o fail-mbr.o fail-mbr.S
> > gcc: error: unrecognized command line option '-m32'
> > make[3]: *** [fail-mbr.o] Error 1
> > Makefile:481: recipe for target 'fail-mbr.o' failed
> > make[3]: Leaving directory '/«PKGBUILDDIR»/fail-mbr'
> > make[2]: *** [all-recursive] Error 1
> > Makefile:387: recipe for target 'all-recursive' failed
> > make[2]: Leaving directory '/«PKGBUILDDIR»'
> > make[1]: *** [all] Error 2
> > dh_auto_build: make -j1 returned exit code 2
> 
> Assembling fail-mbr.S with a non-x86 compiler clearly isn't going to work.
> 
> Thanks,
> James



-- 
Georges KHAZNADAR et Jocelyne FOURNIER
22 rue des mouettes, 59240 Dunkerque France.
Téléphone +33 (0)3 28 29 17 70



signature.asc
Description: Digital signature

Bug#740841: Move to udisks2, udisks 1 is deprecated

[Georges Khaznadar]

Dear Michael,

I began working on this issue some months ago. There is still some work
to do, however I think that I will be able to upload a valid revision
soon.

Best regards,   Georges.

Michael Biebl a écrit :
> Control: severity -1 serious
> 
> This bug has been open for about a year.
> I plan to ask for the removal of udisks1 in about 2 weeks.
> Therefor bumping the severity to serious.
> Please get your package ready by that time.
> 
> -- 
> Why is it that all of the instruments seeking intelligent life in the
> universe are pointed away from Earth?
> 



-- 
Georges KHAZNADAR et Jocelyne FOURNIER
22 rue des mouettes, 59240 Dunkerque France.
Téléphone +33 (0)3 28 29 17 70



signature.asc
Description: Digital signature

Bug#772365: simpleburn: bashism in /bin/sh script

[Georges Khaznadar]

Hello,

here is my contribution to Jessie's bug squash.
I attach a patch with various fixes for bashisms (not fully tested).

Best regards,   Georges.

-- 
Georges KHAZNADAR et Jocelyne FOURNIER
22 rue des mouettes, 59240 Dunkerque France.
Téléphone +33 (0)3 28 29 17 70

Index: simpleburn-1.7.0/scripts/simpleburn-detect.sh
===
--- simpleburn-1.7.0.orig/scripts/simpleburn-detect.sh
+++ simpleburn-1.7.0/scripts/simpleburn-detect.sh
@@ -1,6 +1,6 @@
 #!/bin/sh
 
-function detect() {
+detect() {
 	device=$1 #assumes it is a valid CD / DVD device
 	readcd dev=$device -fulltoc 2>/dev/null; rm -f  ~/toc.dat; rm -f toc.dat #wait for loading
 	if cdrom_id $device | grep -q "ID_CDROM_MEDIA"; then
@@ -22,7 +22,7 @@ function detect() {
 if [ -z "$mediacapacity" ]; then
 	mediacapacity=`cdrecord -atip dev=$device 2>&1 | grep "phys size:..." | tail -1 | sed 's/phys size:... \+//'`
 fi
-let mediacapacity=mediacapacity*2048
+mediacapacity=$((mediacapacity*2048))
 			fi
 			{ mplayer -dvd-device $device dvd://1 -identify -vo null -ao null -frames 0 2>&1 > /tmp/simpleburn-detect.$$ ;} 2>&1 >/dev/null
 			if grep -q "ID_DVD_TITLES" /tmp/simpleburn-detect.$$; then
@@ -31,13 +31,13 @@ function detect() {
 for title in `cat  /tmp/simpleburn-detect.$$ | grep "TITLE_[0-9]\+_LENGTH"`; do #for each title during more than 3'
 	titlenum=`echo $title | cut -d'_' -f4`
 	titlelenght=`echo $title | cut -d'=' -f2 | cut -f1 -d'.'`
-	let minutes=titlelenght/60
-	if (( minutes > 3 )); then
-		if (( $titlenum != 1 )); then
+	minutes=$((titlelenght/60))
+	if [ $(( minutes > 3 )) = 1 ]; then
+		if [ $(( $titlenum != 1 )) = 1 ]; then
 			{ mplayer -dvd-device $device dvd://$titlenum -identify -vo null -ao null -frames 0 2>&1 > /tmp/simpleburn-detect.$$; } 2>&1 >/dev/null
 		fi
 		if grep -q "ID_AID" /tmp/simpleburn-detect.$$ && grep -q "ID_SID" /tmp/simpleburn-detect.$$; then
-			let trackscount=trackscount+1
+			trackscount=$((trackscount+1))
 			if [ ! -z "$mediainfos" ]; then
 mediainfos="$mediainfos\n"
 detailedinfos="$detailedinfos\n"
@@ -58,7 +58,7 @@ function detect() {
 	subdetailedinfos="$subdetailedinfos $languagename($languageid)"
 done
 mediainfos="$mediainfos;$mediasubinfos"
-if [ "$id" == "ID_AID" ]
+if [ "$id" = "ID_AID" ]
 then detailedinfos="$detailedinfos\n\tlanguages: $subdetailedinfos"
 else detailedinfos="$detailedinfos\n\tsubtitles: $subdetailedinfos"
 fi
@@ -76,16 +76,17 @@ function detect() {
 mediatype="cd"
 if cdrom_id $device | grep -q "ID_CDROM_MEDIA_CD_R"; then
 mediacapacity=`cdrecord -atip dev=$device 2>&1 | grep "ATIP start of lead out:" | sed 's/.*: \([0-9]\+\) .*/\1/'` 
-	let mediacapacity=mediacapacity*2048
+	mediacapacity=$((mediacapacity*2048))
 fi
 if cdrom_id $device | grep -q "ID_CDROM_MEDIA_TRACK_COUNT_AUDIO"; then
 	mediacontent="audio"
 	mediasize=`cdrecord -toc dev=$device 2>&1 | grep "track:lout" | sed 's/track:lout lba: \+\([0-9]\+\) .*/\1/'`
-	let mediasize=mediasize*2048
+	mediasize=$((mediasize*2048))
 	cdda2wav -J -L1 -v titles,toc -g -N -H dev=$device out-fd=1 2>/dev/null | tr -d '\200-\377'> /tmp/simpleburn-detect.$$ 
 	medialabel=`cat /tmp/simpleburn-detect.$$ | grep "^Album title:" | sed 's/^Album title: .\(.*\). from .*$/\1/'`
 	n=`cat /tmp/simpleburn-detect.$$ | grep "^T..:" | wc -l`
-	for (( i=1; i<=$n; i++ )); do
+	i=1
+	while [ $((i<=$n)) =1 ]; do
 		line=`cat /tmp/simpleburn-detect.$$ | grep "^T..:" | sed -n $i\p`
 		if [ ! -z "$mediainfos" ]; then
 			mediainfos="$mediainfos\n"
@@ -96,6 +97,7 @@ function detect() {
 		tracklength=`echo $line | sed 's/T..: \(.*\) title.*/\1/' | cut -f1 -d .`
 		detailedinfos="$detailedinfos""track $tracknum ($tracklength): $tracktitle"
 		mediainfos="$mediainfos$tracknum;$tracktitle;$tracklength"
+		i=$((i+1))
 	done
 	rm -f /tmp/simpleburn-detect.$$
 fi
@@ -105,8 +107,8 @@ function detect() {
 		fi
 	fi
 	
-	let mediasize_=mediasize/1048576
-	let mediacapacity_=mediacapacity/1048576
+	mediasize_=$((mediasize/1048576))
+	mediacapacity_=$((mediacapacity/1048576))
 	if [ $rewritablemedia -eq 1 ]
 	then rewritablemedia_="yes"
 	else rewritablemedia_="no"
@@ -122,12 +124,12 @@ for tool in cdrom_

Bug#764791: geophar: Please update to use wxpython3.0

[Georges Khaznadar]

Dear Olly,

thank you for the bug report.

I apologize : geophar was ready for python-wxgtk3.0, but I did not
upgrade the dependency in the control file (mostly borrowed from the
defunct package wxgeometrie).

I upload the fix shortly!

Best regards,   Georges.

Olly Betts a écrit :
> Source: geophar
> Version: 14.07~dfsg1-1
> Severity: serious
> Justification: blocks the almost complete wxpython3.0 transition
> Tags: sid jessie
> User: freewx-ma...@lists.alioth.debian.org
> Usertags: wxpy3.0
> Control: block 755757 by -1
> 
> We've been working on migrating the archive to using wxpython3.0 instead
> of wxwidgets2.8 for a few months, and this process is close to complete,
> so jessie won't be releasing with wxwidgets2.8 - you can see the release
> team's tracker here:
> 
> https://release.debian.org/transitions/html/wxpython3.0.html
> 
> As I warned you a few weeks ago while geophar was still in NEW, you'll
> need to update it to use wxpython3.0 if you want it to be in jessie.
> 
> I've included the template email from the bugs filed for the transition
> which contains information which is likely to be useful for updating to
> wxpython3.0.
> 
> The wxPython 3.0 API mostly adds to the wxPython2.8 API.  Many packages
> work with wxPython 3.0 without any changes, but there are a few
> incompatibilities.  For example, wx.Color is no longer supported as
> an alias for wx.Colour, and some constants which were deprecated in 2.8
> have been removed.  All the removed constants I'm aware of were set to 0
> in wxPython 2.8, so removing them is still compatible with 2.8.
> 
> To assist updating to wxPython 3.0, I've put together a script which
> will help make the mechanical changes required.  This is in a git repo
> on collab-maint along with a README about using it and updating packages
> for wxPython 3.0 in general:
> 
> http://anonscm.debian.org/cgit/collab-maint/wx-migration-tools.git
> 
> The script has some options to control the sorts of changes it makes -
> see the README and --help output for more information - you can view
> the latest version of the README online here:
> 
> http://anonscm.debian.org/cgit/collab-maint/wx-migration-tools.git/tree/README
> 
> I've developed this script by trying to convert 20+ packages.  Please
> try it out on your package - in many cases, it should be enough to get
> your package working (if it doesn't already) - if it does, please upload
> (and close this bug).
> 
> If the script doesn't do the job, please let me know (or improve the
> script if you can figure out what it needs to do to get your package
> working).
> 
> Another issue you may hit is that wxWidgets 3.0 now defaults to enabling
> its "WXDEBUG" checks for incorrect API usage, so some applications will
> emit scary sounding "assertion failures".  These are unlikely to
> actually be new, just in a default build of 2.8, such incorrect uses
> were handled quietly behind the scenes.  Sometimes these are easy to
> fix, but if not you can easily patch the application to tell wx 3.0 to
> handle them in the same way wx 2.8 does - details of how to do so are in
> the README:
> 
> http://anonscm.debian.org/cgit/collab-maint/wx-migration-tools.git/tree/README
> 
> Cheers,
> Olly
> 

-- 
Georges KHAZNADAR et Jocelyne FOURNIER
22 rue des mouettes, 59240 Dunkerque France.
Téléphone +33 (0)3 28 29 17 70



signature.asc
Description: Digital signature

Bug#754617: units-filter: FTBFS on kfreebsd-amd64/s390x: mpfr::mpreal::mpreal declarations etc.

[Georges Khaznadar]

7;mpfr::mpreal& 
> mpfr::mpreal::operator*=(int64_t)' previously defined here
> |  inline mpreal& mpreal::operator*=(const int64_t  u){*this *= 
> mpreal(u); MPREAL_MSVC_DEBUGVIEW_CODE; return *this;}
> | ^
> | /usr/include/mpreal.h:1421:16: error: redefinition of 'mpfr::mpreal& 
> mpfr::mpreal::operator/=(long unsigned int)'
> |  inline mpreal& mpreal::operator/=(const unsigned long int v)
> | ^
> | /usr/include/mpreal.h:1143:16: error: 'mpfr::mpreal& 
> mpfr::mpreal::operator/=(uint64_t)' previously defined here
> |  inline mpreal& mpreal::operator/=(const uint64_t u){*this /= 
> mpreal(u); MPREAL_MSVC_DEBUGVIEW_CODE; return *this;}
> | ^
> | /usr/include/mpreal.h:1435:16: error: redefinition of 'mpfr::mpreal& 
> mpfr::mpreal::operator/=(long int)'
> |  inline mpreal& mpreal::operator/=(const long int v)
> | ^
> | /usr/include/mpreal.h:1142:16: error: 'mpfr::mpreal& 
> mpfr::mpreal::operator/=(int64_t)' previously defined here
> |  inline mpreal& mpreal::operator/=(const int64_t  u){*this /= 
> mpreal(u); MPREAL_MSVC_DEBUGVIEW_CODE; return *this;}
> | ^
> | make[2]: *** [unitesparser.o] Error 1
> | make[2]: Leaving directory `/«PKGBUILDDIR»/src'
> | make[1]: *** [all] Error 2
> | make[1]: Leaving directory `/«PKGBUILDDIR»'
> | dh_auto_build: make -j1 returned exit code 2
> | make: *** [build-arch] Error 2
> | dpkg-buildpackage: error: debian/rules build-arch gave error exit status 2
> 
> Full build logs:
>   
> https://buildd.debian.org/status/fetch.php?pkg=units-filter&arch=kfreebsd-amd64&ver=3.6-1&stamp=1396799120
>   
> https://buildd.debian.org/status/fetch.php?pkg=units-filter&arch=s390x&ver=3.6-1&stamp=1403695605
> 
> Mraw,
> KiBi.
> 

-- 
Georges KHAZNADAR et Jocelyne FOURNIER
22 rue des mouettes, 59240 Dunkerque France.
Téléphone +33 (0)3 28 29 17 70



signature.asc
Description: Digital signature

Bug#750904: scidavis: FTBFS on arm*: fatal error: sipAPIscidavis.h: No such file or directory

[Georges Khaznadar]

> | src/PythonScripting.cpp:60:28: fatal error: sipAPIscidavis.h: No such file 
> or directory
> |  #include "sipAPIscidavis.h"
> | ^
> | compilation terminated.
> | make[3]: *** [../tmp/scidavis/PythonScripting.o] Error 1
> 
> Full build logs:
>   
> https://buildd.debian.org/status/fetch.php?pkg=scidavis&arch=armhf&ver=1.D5-1&stamp=1401679921
>   
> https://buildd.debian.org/status/fetch.php?pkg=scidavis&arch=armel&ver=1.D5-1&stamp=1401653966
> 
> Mraw,
> KiBi.
> 

-- 
Georges KHAZNADAR et Jocelyne FOURNIER
22 rue des mouettes, 59240 Dunkerque France.
Téléphone +33 (0)3 28 29 17 70



signature.asc
Description: Digital signature

Bug#741743: NMU patch for kicad_0.20140224+bzr4027-3.1

[Georges Khaznadar]

Dear Aníbal,

many thank for the NMU. I was puzzled with the bug which you fixed, I
shall study your modifications.

Best regards,   Georges.

Aníbal Monsalve Salazar a écrit :
> Hello Georges Khaznadar,
> 
> At Imagination Technologies (http://imgtec.com/) Dejan Latinovic has
> found a solution to Debian bug #741743.
> 
> https://bugs.debian.org/741743
> 
> My NMU patch for kicad_0.20140224+bzr4027-3.1 is below, at the end of
> this message.
> 
> With the changes in the NMU patch kicad builds successfully on mips,
> mipsel and amd64.
> 
> Regards,
> 
> Aníbal
> --
> Aníbal Monsalve Salazar 
> 
> debdiff kicad_0.20140224+bzr4027-3.dsc kicad_0.20140224+bzr4027-3.1.dsc
> diff -Nru kicad-0.20140224+bzr4027/debian/changelog 
> kicad-0.20140224+bzr4027/debian/changelog
> --- kicad-0.20140224+bzr4027/debian/changelog 2014-03-07 10:49:51.0 
> +
> +++ kicad-0.20140224+bzr4027/debian/changelog 2014-05-09 04:33:34.0 
> +0100
> @@ -1,3 +1,12 @@
> +kicad (0.20140224+bzr4027-3.1) unstable; urgency=low
> +
> +  * Non-maintainer upload.
> +  * It FTBFS because kicad-common is arch independent.
> +Patch by Dejan Latinovic .
> +Closes: #741743
> +
> + -- Anibal Monsalve Salazar   Fri, 09 May 2014 04:33:24 
> +0100
> +
>  kicad (0.20140224+bzr4027-3) unstable; urgency=medium
>  
>* taken in account Samuel Thibault's hint. Closes: #740999
> diff -Nru kicad-0.20140224+bzr4027/debian/rules 
> kicad-0.20140224+bzr4027/debian/rules
> --- kicad-0.20140224+bzr4027/debian/rules 2014-03-07 10:50:28.0 
> +
> +++ kicad-0.20140224+bzr4027/debian/rules 2014-05-09 04:32:41.0 
> +0100
> @@ -21,7 +21,7 @@
>  override_dh_compress:
>   dh_compress --exclude=.pdf
>  
> -override_dh_install:
> +override_dh_install-arch:
>   convert bitmaps_png/icons/icon_kicad.xpm -resize 32x32 
> debian/tmp/icon_kicad.xpm
>   dh_install
>   # fix wrong permissions and link jnlp file to usr/share
> @@ -29,6 +29,9 @@
> chmod a-x $(COMMONDIR)/usr/share/kicad/internat/ja/*
>   ln -s ../share/kicad/freeroute.jnlp $(PKGDIR)/usr/bin
>   chmod a-x $(PKGDIR)/usr/share/kicad/freeroute.jnlp
> +
> +override_dh_install-indep:
> + dh_install
>   # remove out-of-topic files
>   find $(COMMONDIR)/usr/share/kicad -name "CMake*" -exec rm {} \;
>  



-- 
Georges KHAZNADAR et Jocelyne FOURNIER
22 rue des mouettes, 59240 Dunkerque France.
Téléphone +33 (0)3 28 29 17 70



signature.asc
Description: Digital signature

Bug#741743: Probable cause of the FTBFS

[Georges Khaznadar]

Dear Juhani,

thank you for your hint!

unfortunately, files installed to usr/local are generally not a possible
cause for FTBFS bugs. In the worst case, the package is built
successfully, but some files are not copied to the binary package.

Best regards,   Georges.

Juhani Numminen a écrit :
> Hello,
> 
> From the build logs:
> 
>  Install the project...
>  -- Install configuration: ""
>  -- Installing: 
> /«BUILDDIR»/kicad-0.20140224+bzr4027/debian/tmp/usr/local/share/doc/kicad/INSTALL.txt
>  -- Installing: 
> /«BUILDDIR»/kicad-0.20140224+bzr4027/debian/tmp/usr/local/bin/freeroute.jnlp
> 
> It seems that the package is installing to prefix /usr/local.
> Please try to fix this so kicad can re-enter testing. Thanks!
> 
> --
> Juhani Numminen
> 

-- 
Georges KHAZNADAR et Jocelyne FOURNIER
22 rue des mouettes, 59240 Dunkerque France.
Téléphone +33 (0)3 28 29 17 70



signature.asc
Description: Digital signature

Bug#743117: Intent to NMU

[Georges Khaznadar]

Dear Margarita, thank you for your contribution!

I was in vacations some days, so your NMU is welcome!

Best regards,   Georges.

Margarita Manterola a écrit :
> Hi,
> 
> I have taken the patch made by Paul, but added it to the 10-Makefile.patch,
> where it made more sense.
> 
> I've tested the resulting program and it seemed to use cairo properly, 
> although
> I'm not a French speaker, not a chemistry expert, it seemed to do the right
> thing.
> 
> I'm attaching here the debdiff corresponding to my change.  I'll be uploading
> this fix to the 3-day delayed queue.
> 
> -- 
> Cheers,
> Marga

> diff -Nru dozzaqueux-3.33/debian/changelog dozzaqueux-3.33/debian/changelog
> --- dozzaqueux-3.33/debian/changelog  2014-01-05 17:10:54.0 +0100
> +++ dozzaqueux-3.33/debian/changelog  2014-04-25 15:40:50.0 +0200
> @@ -1,3 +1,11 @@
> +dozzaqueux (3.33-1.1) unstable; urgency=medium
> +
> +  * Non-maintainer upload.
> +  * Modify 10-Makefile.patch to find cairocanvas component, fixing FTBFS.
> +Based on patch by Paul Gevers . Closes: #743117
> +
> + -- Margarita Manterola   Fri, 25 Apr 2014 15:13:49 +0200
> +
>  dozzaqueux (3.33-1) unstable; urgency=medium
>  
>* created a working watch file and added a script to make the new package
> diff -Nru dozzaqueux-3.33/debian/patches/10-Makefile.patch 
> dozzaqueux-3.33/debian/patches/10-Makefile.patch
> --- dozzaqueux-3.33/debian/patches/10-Makefile.patch  2014-01-05 
> 17:09:41.0 +0100
> +++ dozzaqueux-3.33/debian/patches/10-Makefile.patch  2014-04-25 
> 15:16:05.0 +0200
> @@ -1,6 +1,8 @@
>  /dev/null
> -+++ b/Makefile
> -@@ -0,0 +1,50 @@
> +Index: dozzaqueux-3.33/Makefile
> +===
> +--- /dev/null1970-01-01 00:00:00.0 +
>  dozzaqueux-3.33/Makefile 2014-04-25 15:16:01.448456823 +0200
> +@@ -0,0 +1,51 @@
>  +DESTDIR =
>  +
>  +FPC_VERSION = $(shell update-alternatives --list lazarus | tail -1 | awk -F 
> / '{print $$5}')
> @@ -12,6 +14,7 @@
>  +UNITLIBS += 
> -Fu/usr/lib/lazarus/$(FPC_VERSION)/components/lazutils/lib/$(ARCH)/
>  +UNITLIBS += 
> -Fu/usr/lib/lazarus/$(FPC_VERSION)/components/synedit/units/$(ARCH)/nogui/
>  +UNITLIBS += -Fu/usr/lib/lazarus/$(FPC_VERSION)/packager/units/$(ARCH)/
> ++UNITLIBS += 
> -Fu/usr/lib/lazarus/$(FPC_VERSION)/components/cairocanvas/lib/$(ARCH)/gtk2/
>  +UNITLIBS += 
> -Fu/usr/lib/lazarus/$(FPC_VERSION)/components/printers/lib/$(ARCH)/gtk2/
>  +UNITLIBS += 
> -Fu/usr/lib/lazarus/$(FPC_VERSION)/components/synedit/units/$(ARCH)/
>  +UNITLIBS += -Fu.


-- 
Georges KHAZNADAR et Jocelyne FOURNIER
22 rue des mouettes, 59240 Dunkerque France.
Téléphone +33 (0)3 28 29 17 70



signature.asc
Description: Digital signature

Bug#638760: Removal of grace, pygrace and expeyes

[Georges Khaznadar]

Dear Evgeny,

I strongly back your point of view.

As Neil wants a quick solution, I shall develop alternative depedencies
for expeyes which currently relies on grace: it will offer the
possibility to choose qtiplot.

I agree with you, a user which learned to use Xmgrace will grind loads
of work happily.

Best regards,   Georges.

Evgeny Stambulchik a écrit :
> Hello,
> 
> I'm the [passive] upstream maintainer. Just to make things clear:
> 
> 1. grace is perfectly happy using its own copy of t1lib. So you can
> safely remove the t1lib debian package.
> 
> 2. Yes, perhaps only 0.34% of all users use it. But same can be said
> about 90% of the entire debian archive (for each package separately,
> of course).
> 
> 3. Yes, it is potentially buggy and insecure. But since in 99.9% you
> use it within the projects you work yourself on, nothing wrong can
> happen. In the worst case you loose some time. (And in my
> experience, grace crashes MUCH less frequently than some
> high-profile softwares which are really exposed to the Internet.)
> 
> 4. I have no time and intention right now to switch to freetype. For
> the scope it is currently used in grace, t1lib is adequate. When I
> come across a bug, I fix it - that's how the bundled t1lib copy got
> emerged in the first place.
> 
> Best,
> 
> Evgeny
> 
> On 23/03/14 12:01, Neil Williams wrote:
> >On Sun, 23 Mar 2014 11:01:39 +1100
> >Drew Parsons  wrote:
> >
> >>Grace is one of the most useful packages in the entire archive.
> >
> >... for 0.34% of users of the archive, maybe. To me, it is simply an RC
> >buggy package which has had no new development upstream since 2012 and
> >which depends on an obsolete, abandoned library. Unless it can be
> >ported, it will need to be removed alongside t1lib.
> >
> >Those who care about grace need to scratch their own itch and fix it.
> >
> >>I am not aware of anything other package that provides the same degree
> >>of functionality.
> >>
> >>Removing it is not a good idea.
> >
> >Removing it is necessary, as explained. t1lib has been superseded and
> >packages which used to use it need to migrate. The other packages have
> >already done so, those which fail to do so cannot be supported when the
> >underlying dependency has been abandoned.
> >
> >
> 
> 

-- 
Georges KHAZNADAR et Jocelyne FOURNIER
22 rue des mouettes, 59240 Dunkerque France.
Téléphone +33 (0)3 28 29 17 70



signature.asc
Description: Digital signature

Bug#736118: expeyes: FTBFS: [eyes.pdf] Error 1

[Georges Khaznadar]

Hello Roland,

thank you for the reminder.
I am afraid that I do not understand the problem.

There is no build problem on my machine's pbuilder's chroot, either with
amd64-sid or with i386-sid. Previous versions did not trigger any bug
during the build of the documentation (LyX document translated to TeX,
then compiled with pdflatex).  Unexpectedly, this part is faulty with
other machines, in Debian's build farm.

Please can you give me some hint ... is it possible to get an
accreditation to launch a "pbuilder login" on some remote machine
configured like the machines in the build farm?

Best regards,   Georges.

Roland Stigge a écrit :
> Source: expeyes
> Version: 3.1.4-2
> Severity: serious
> 
> Hi,
> 
> expeyes FTBFS on most architectures. E.g. on powerpc:
> 
> ...
> 
> make[2]: Entering directory `/«PKGBUILDDIR»/doc'
> for l in en fr; do \
> make -C $l/Docs all; \
> make -C $l/Docs-jr all; \
> make -C $l/Progman-jr all; \
>   done
> make[3]: Entering directory `/«PKGBUILDDIR»/doc/en/Docs'
> make[3]: *** [eyes.pdf] Error 1
> Language=en, exporting eyes.lyx to a LaTeX file ... make[3]: Leaving 
> directory `/«PKGBUILDDIR»/doc/en/Docs'
> make[3]: Entering directory `/«PKGBUILDDIR»/doc/en/Docs-jr'
> make[3]: *** [eyesj.pdf] Error 1
> ...
> 
> Roland
> 
> 
> -- System Information:
> Debian Release: 7.0
>   APT prefers unreleased
>   APT policy: (500, 'unreleased'), (500, 'unstable')
> Architecture: powerpcspe (ppc)
> 
> Kernel: Linux 3.9.0-dirty (SMP w/2 CPU cores)
> Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) (ignored: 
> LC_ALL set to en_GB.UTF-8)
> Shell: /bin/sh linked to /bin/dash
> 

-- 
Georges KHAZNADAR et Jocelyne FOURNIER
22 rue des mouettes, 59240 Dunkerque France.
Téléphone +33 (0)3 28 29 17 70



signature.asc
Description: Digital signature

Bug#725996: wims: FTBFS on mips(el)

[Georges Khaznadar]

Hello Ivo,

do you mind that I could write "openjdk-7-jdk|openjdk-6-jdk|default-jdk"
to fix this issue?

Best regards,   Georges.

Ivo De Decker a écrit :
> package: wims
> severity: serious
> version: 1:4.07a~dfsg1-1
> 
> Dear maintainer,
> 
> Wims keeps failing to build on mips and mipsel (and is tried over and over).
> This is caused by the build-depends on 'openjdk-7-jdk|default-jdk'. This
> build-dependency cannot be satisfied by the buildd's, as they only look at the
> first alternative build-dependency, and openjdk-7-jdk is not available on
> mips(el).
> 
> https://buildd.debian.org/status/package.php?p=wims&suite=sid
> 
> Cheers,
> 
> Ivo
> 

-- 
Georges KHAZNADAR et Jocelyne FOURNIER
22 rue des mouettes, 59240 Dunkerque France.
Téléphone +33 (0)3 28 29 17 70



signature.asc
Description: Digital signature

Bug#713850: Processed: found 713850 in 1:4.05b~dfsg1-6

[Georges Khaznadar]

Hello Julien,

I am rebuilding wims with "pdebuild" rather than "debuild". Is there
something in the Policy against packages like wims/1:4.05b~dfsg1-6? The
build processes for other architectures have begun and are successful,
as per https://buildd.debian.org/status/package.php?p=wims

Best regards,   Georges.

Debian Bug Tracking System a écrit :
> Processing commands for cont...@bugs.debian.org:
> 
> > found 713850 1:4.05b~dfsg1-6
> Bug #713850 {Done: } [wims] wims: Please build your 
> packages in an up-to-date environment
> Marked as found in versions wims/1:4.05b~dfsg1-6 and reopened.
> > thanks
> Stopping processing here.
> 
> Please contact me if you need assistance.
> -- 
> 713850: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=713850
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems
> 

-- 
Georges KHAZNADAR et Jocelyne FOURNIER
22 rue des mouettes, 59240 Dunkerque France.
Téléphone +33 (0)3 28 29 17 70



signature.asc
Description: Digital signature

Bug#713850: wims: Please build your packages in an up-to-date environment

[Georges Khaznadar]

Hi Julien,

Julien Cristau a écrit :
> This has nothing to do with the buildds.  The binaries you uploaded
> yesterday have a dependency on libgd2-xpm.  Unless they were built a
> month ago, that means they weren't built in sid.

Are you talking about http://packages.debian.org/sid/libgd2-xpm-dev ?
As you are very affirmative, I tried a "pbuilder login", then "apt-get
install libgd2-xpm-dev". Depedencies are pretty well solved, no problem.
So what?

The last revision of the package wims is uploaded now.

Best regards,   Georges.



signature.asc
Description: Digital signature

Bug#713850: wims: Please build your packages in an up-to-date environment

[Georges Khaznadar]

Julien Cristau a écrit :
> Package: wims
> Version: 1:4.05b~dfsg1-3
> Severity: serious
> 
> The wims binary package you uploaded was not built in an up-to-date sid
> environment.  This is not the first time it happens.  Please stop doing
> that.

Hello Julien,

if you worry, please try it out. I built the package successfully at
home with pbuilder (ARCH=amd64 DIST=sid). For some reason, there is a
slight difference between the environment offered by pbuilder on my
computer and the tools used in Debian's compile farm. However I cannot
see which is precisely the slight the difference, so I cannot raise a
bug report about it.

I am working on that issue, modifying the makefiles to be able to make
the package with a pure dh7 flavored d/rules makefile -- that is, without
explicit manipulation of DESTDIR.

Best regards,   Georges.



signature.asc
Description: Digital signature

Bug#669749: chemical-structures: transition towards Apache 2.4

[Georges Khaznadar]

Hello Andreas,

I could not reproduce your test with piuparts.

I installed succesfully piuparts on my computer (version 0.53), and then
ran it against the package chemical-structures:

  $ sudo piuparts -b /var/cache/pbuilder/sid-amd64-base.tgz 
--proxy=http://127.0.0.1:3142 --keep-sources-list -l /tmp/mylog.log 
../chemical-structures_2.2.dfsg.0-9_amd64.changes
  [... let it run ...]
  $ grep Installation /tmp/mylog.log 
  4m41.6s INFO: Installation of 
['tmp/chemical-structures_2.2.dfsg.0-9_all.deb'] ok

So, as far as I use the basetgz file of my local pbuilder configuration,
and its sources.list settings, the package chemical-structures appears
as installable.

Now, what should I do? Request to close the bugreport? Make some new
bugreport?

Best regards,   Georges.


Andreas Beckmann a écrit :
> Followup-For: Bug #669749
> 
> Hi,
> 
> during a test with piuparts I noticed your package is no longer
> installable in sid:
> 
>   Selecting previously unselected package chemical-structures.
>   (Reading database ... 12151 files and directories currently installed.)
>   Unpacking chemical-structures (from 
> .../chemical-structures_2.2.dfsg.0-9_all.deb) ...
>   Setting up chemical-structures (2.2.dfsg.0-9) ...
>   dpkg: error processing chemical-structures (--configure):
>subprocess installed post-installation script returned error exit status 1
>   Errors were encountered while processing:
>    chemical-structures
> 
> 
> Cheers,
> 
> Andreas



-- 
Georges KHAZNADAR et Jocelyne FOURNIER
22 rue des mouettes, 59240 Dunkerque France.
Téléphone +33 (0)3 28 29 17 70



signature.asc
Description: Digital signature

Bug#705992: wims-moodle: fails to *remove*: find: `/var/lib/moodle/lang': No such file or directory

[Georges Khaznadar]

Thank you Andreas,

I removed the obsoleted file debian/prerm: as the postinst script does
no longer create the directory /var/lib/moodle/lang (if this directory
was not created earlier by moodle's usage), it can be missing, and a 
minimal environment does miss it.

Best regards,   Georges.

Andreas Beckmann a écrit :
> Followup-For: Bug #705992
> Control: found -1 4.0-4
> 
> And now we are failing on remove with the same error ...
> 
>   Removing wims-moodle ...
>   find: `/var/lib/moodle/lang': No such file or directory
>   dpkg: error processing wims-moodle (--remove):
>subprocess installed pre-removal script returned error exit status 1
> 
> Andreas



-- 
Georges KHAZNADAR et Jocelyne FOURNIER
22 rue des mouettes, 59240 Dunkerque France.
Téléphone +33 (0)3 28 29 17 70



signature.asc
Description: Digital signature

Bug#705992: closed by Georges Khaznadar (Bug#705992: fixed in wims-moodle 4.0-2)

[Georges Khaznadar]

Thank you for your scrutiny, Andreas!

for some reason I forgot to save the fix before making the last package.
Now it is done with the release 4.0-3, and I removed one last file remaining
in /usr/share/doc too.

Best regards,   Georges.

Andreas Beckmann a écrit :
> Control: found -1 4.0-2
> 
> Same problem as before.
> 
> the problematic postinst line seems to be
>   dirs=$(find $path -mindepth 1 -maxdepth 1 -type d)
> which fails since $path does not exist
> 
> Another problem I noticed while lookign at the postinst script:
> using anything in /usr/share/doc is prohibited (policy 12.3), e.g.
> /usr/share/doc/wims-moodle/lang/$lang/wims.php
> Please move everything needed for the package to work properly to
> /usr/share/wims-moodle
> 
> 
> Andreas
> 

-- 
Georges KHAZNADAR et Jocelyne FOURNIER
22 rue des mouettes, 59240 Dunkerque France.
Téléphone +33 (0)3 28 29 17 70



signature.asc
Description: Digital signature

Bug#705992: wims-moodle: fails to install: find: `/var/lib/moodle/lang': No such file or directory

[Georges Khaznadar]

Thank you for your custody, Andreas, I removed a subroutine which became
obsoleted since the move to moodle > 1.9

Best regards,   Georges.

Andreas Beckmann a écrit :
> Package: wims-moodle
> Version: 4.0-1
> Severity: serious
> User: debian...@lists.debian.org
> Usertags: piuparts
> 
> Hi,
> 
> during a test with piuparts I noticed your package failed to install. As
> per definition of the release team this makes the package too buggy for
> a release, thus the severity.
> 
> >From the attached log (scroll to the bottom...):
> 
>   Selecting previously unselected package wims-moodle.
>   (Reading database ... 55600 files and directories currently installed.)
>   Unpacking wims-moodle (from .../wims-moodle_4.0-1_all.deb) ...
>   Setting up wims-moodle (4.0-1) ...
>   find: `/var/lib/moodle/lang': No such file or directory
>   dpkg: error processing wims-moodle (--configure):
>subprocess installed post-installation script returned error exit status 1
>   Errors were encountered while processing:
>wims-moodle
> 
> 
> cheers,
> 
> Andreas



-- 
Georges KHAZNADAR et Jocelyne FOURNIER
22 rue des mouettes, 59240 Dunkerque France.
Téléphone +33 (0)3 28 29 17 70



signature.asc
Description: Digital signature

Bug#687947: wims: still modifies shipped files: /var/lib/wims/public_html/gifs/*

[Georges Khaznadar]

Andreas Beckmann a écrit :
> not much has changed in the last release ... therefore reopening.

Thank you for the feedback, Andreas! I wish I could install piuparts to
get this feedback sooner; however it failed when I tried to get the
package and install it last time.

I think that the next package will be right.

Best regards,   Georges.

> 
> 1m19.5s ERROR: FAIL: debsums reports modifications inside the chroot:
>   /var/lib/wims/public_html/gifs/symbols/20/_Arrow-h.gif
>   /var/lib/wims/public_html/gifs/symbols/20/_Arrow-v.gif
>   /var/lib/wims/public_html/gifs/symbols/20/_ArrowR-h.gif
>   /var/lib/wims/public_html/gifs/symbols/20/_ArrowR-v.gif
>   /var/lib/wims/public_html/gifs/symbols/20/_Diode-h.gif
>   /var/lib/wims/public_html/gifs/symbols/20/_Diode-v.gif
>   /var/lib/wims/public_html/gifs/symbols/20/_DiodeR-h.gif
>   /var/lib/wims/public_html/gifs/symbols/20/_DiodeR-v.gif
>   /var/lib/wims/public_html/gifs/symbols/20/_Zener-h.gif
>   /var/lib/wims/public_html/gifs/symbols/20/_Zener-v.gif
>   /var/lib/wims/public_html/gifs/symbols/20/_ZenerR-h.gif
>   /var/lib/wims/public_html/gifs/symbols/20/_ZenerR-v.gif
>   /var/lib/wims/public_html/gifs/symbols/20/_iArrow-h.gif
>   /var/lib/wims/public_html/gifs/symbols/20/_iArrow-v.gif
>   /var/lib/wims/public_html/gifs/symbols/20/_iArrowR-h.gif
>   /var/lib/wims/public_html/gifs/symbols/20/_iArrowR-v.gif
>   /var/lib/wims/public_html/gifs/symbols/20/del-h.gif
>   /var/lib/wims/public_html/gifs/symbols/20/del-v.gif
>   /var/lib/wims/public_html/gifs/symbols/20/delR-h.gif
>   /var/lib/wims/public_html/gifs/symbols/20/delR-v.gif
>   /var/lib/wims/public_html/gifs/symbols/20/isrc-v.gif
>   /var/lib/wims/public_html/gifs/symbols/20/isrcR-v.gif
>   /var/lib/wims/public_html/gifs/symbols/20/meter-h.gif
>   /var/lib/wims/public_html/gifs/symbols/20/meter-v.gif
>   /var/lib/wims/public_html/gifs/symbols/20/meterR-h.gif
>   /var/lib/wims/public_html/gifs/symbols/20/meterR-v.gif
>   /var/lib/wims/public_html/gifs/symbols/20/nand-h.gif
>   /var/lib/wims/public_html/gifs/symbols/20/nand-v.gif
>   /var/lib/wims/public_html/gifs/symbols/20/nandR-h.gif
>   /var/lib/wims/public_html/gifs/symbols/20/nandR-v.gif
>   /var/lib/wims/public_html/gifs/symbols/20/nor-h.gif
>   /var/lib/wims/public_html/gifs/symbols/20/nor-v.gif
>   /var/lib/wims/public_html/gifs/symbols/20/norR-h.gif
>   /var/lib/wims/public_html/gifs/symbols/20/norR-v.gif
>   /var/lib/wims/public_html/gifs/symbols/20/npn-h.gif
>   /var/lib/wims/public_html/gifs/symbols/20/npn-v.gif
>   /var/lib/wims/public_html/gifs/symbols/20/npn2-h.gif
>   /var/lib/wims/public_html/gifs/symbols/20/npn2-v.gif
>   /var/lib/wims/public_html/gifs/symbols/20/npn2R-h.gif
>   /var/lib/wims/public_html/gifs/symbols/20/npn2R-v.gif
>   /var/lib/wims/public_html/gifs/symbols/20/npnR-h.gif
>   /var/lib/wims/public_html/gifs/symbols/20/npnR-v.gif
>   /var/lib/wims/public_html/gifs/symbols/20/pnp-h.gif
>   /var/lib/wims/public_html/gifs/symbols/20/pnp-v.gif
>   /var/lib/wims/public_html/gifs/symbols/20/pnp2-h.gif
>   /var/lib/wims/public_html/gifs/symbols/20/pnp2-v.gif
>   /var/lib/wims/public_html/gifs/symbols/20/pnp2R-h.gif
>   /var/lib/wims/public_html/gifs/symbols/20/pnp2R-v.gif
>   /var/lib/wims/public_html/gifs/symbols/20/pnpR-h.gif
>   /var/lib/wims/public_html/gifs/symbols/20/pnpR-v.gif
>   /var/lib/wims/public_html/gifs/symbols/20/xnor-h.gif
>   /var/lib/wims/public_html/gifs/symbols/20/xnor-v.gif
>   /var/lib/wims/public_html/gifs/symbols/20/xnorR-h.gif
>   /var/lib/wims/public_html/gifs/symbols/20/xnorR-v.gif
> 
> 
> Andreas



-- 
Georges KHAZNADAR et Jocelyne FOURNIER
22 rue des mouettes, 59240 Dunkerque France.
Téléphone +33 (0)3 28 29 17 70



signature.asc
Description: Digital signature

Bug#695684: scolasync: FTBFS: 'ascii' codec can't decode byte 0xc3 in position 33

[Georges Khaznadar]

Hello Jakub,

I did not trigger this bug when I built locally the package, don't know
why.

I shall make the encoding explicit to avoid bad character management.

Best regards,   Georges.

Jakub Wilk a écrit :
> Source: scolasync
> Version: 4.0-1
> Severity: serious
> Justification: fails to build from source
> 
> scolasync FTBFS:
> | ./update_config_dox
> | Traceback (most recent call last):
> |   File "./update_config_dox", line 9, in 
> | indat=infile.readlines()
> |   File "/usr/lib/python3.2/encodings/ascii.py", line 26, in decode
> | return codecs.ascii_decode(input, self.errors)[0]
> | UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 33: 
> ordinal not in range(128)
> | make[1]: *** [doxy] Error 1
> | make[1]: Leaving directory `/build/scolasync-0_E22o/scolasync-4.0'
> | dh_auto_build: make -j1 returned exit code 2
> | make: *** [build] Error 2
> | dpkg-buildpackage: error: debian/rules build gave error exit status 2
> 
> -- 
> Jakub Wilk
> 

-- 
Georges KHAZNADAR et Jocelyne FOURNIER
22 rue des mouettes, 59240 Dunkerque France.
Téléphone +33 (0)3 28 29 17 70



signature.asc
Description: Digital signature

Bug#682265: Please undo automatic removals of wims, wims-extra, etc. from testing

[Georges Khaznadar]

Thank you Julien !

Julien Cristau a écrit :
> ...
> Unblocked, they should go back in once mootools is 10 days old.
> 
> Cheers,
> Julien



-- 
Georges KHAZNADAR et Jocelyne FOURNIER
22 rue des mouettes, 59240 Dunkerque France.
Téléphone +33 (0)3 28 29 17 70



signature.asc
Description: Digital signature

Bug#682265: Please undo automatic removals of wims, wims-extra, etc. from testing

[Georges Khaznadar]

, 682...@bugs.debian.org
Reply-To: 
In-Reply-To: 

Dear debian-release teammates,

Debian testing watch a écrit :
> FYI: The status of the wims source package
> in Debian's testing distribution has changed.
> 
>   Previous version: 4.03a-7
>   Current version:  (not in testing)
>   Hint: 

I read the e-mail thread related to bug #682265, and committed
Salvatore Bonaccorso's NMU which fixes this bug.

I wish I had been warned sooner about this bug, because it was quite easy
to fix, nothing like the work which had been necessary to package wims
and to make it installable on every architecture.

Here is the part of the page
http://release.debian.org/britney/hints/jcristau which is related to
this issue:

--8<-
# 20120720; done 20120801
# build-dep on node-uglify
# 682265
remove mootools/1.4.5~debian1-2
remove wims/4.03a-7 wims-extra/3.62-6 wims-modules-es/3.64-1
zoneminder/1.25.0-1.1
--8<-

If I consider dates, the removal was decided on the 20th July, and
Salvatore Bonaccorso posted his patch to fix the dependency problem the
21st July.  See:
http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=10;bug=682265 
I was notified of the automatic removals today, quite ten days later,
and committed a fix now.

If it is still possible, please do accept the NMU for mootools, which
makes it buildable in wheezy, then please undo removals for packages
wims/4.03a-7, wims-extra/3.62-6, wims-modules-es/3.64-1, and
zoneminder/1.25.0-1.1 which depend on it.

Thank you in advance,   Georges.




signature.asc
Description: Digital signature

Bug#682641: pycode-browser: FTBFS: LyX: Creating directory /sbuild-nonexistent/.lyx/

[Georges Khaznadar]

Hello Sebastian,

I suspected some behavior like this.
However when I launch pbuilder, the variable $HOME is not set to
/sbuild-nonexistent but it is set to /root (which exists).

So I have two and a half questions:

- which is the tool used to check the packages? I currently use
  pbuilder, but the errors are reported from some other tool.
- should I forward that bug to the maintainer of LyX?

and the half of a question:
- I suppose that defining temporarily HOME as $(mktemp -d) would 
  work around this problem. Should I close the bug if I use such a
  workaround? 

Sebastian Ramacher a écrit :
> The problem is that lyx tries to access $HOME, which is set to
> /sbuild-nonexistent (see Lucas' build log) and does not exist.


signature.asc
Description: Digital signature

Bug#682623: uicilibris: FTBFS: /bin/sh: 1: pyuic4: not found

[Georges Khaznadar]

Hello Lucas, I saw that this bug report, (and other bugreports too) have
been reassigned to pyqt4-dev-tools.

The key of the problem, as long as I could test it in a "pbuilder login"
chroot with a fresh Sid environment, is that pyuic4 has been ported to
python3 (and is meant to work only with python3).

So there must be a new dependency for the package pyqt4-dev-tools (at
least) : python3, python3-pyqt4

I append a patch to fix this bug.

Best regards,   Georges.

Lucas Nussbaum a écrit :
> Source: uicilibris
> Version: 1.8-1
> Severity: serious
> Tags: wheezy sid
> User: debian...@lists.debian.org
> Usertags: qa-ftbfs-20120724 qa-ftbfs
> Justification: FTBFS on amd64
> 
> Hi,
> 
> During a rebuild of all packages in sid, your package failed to build on
> amd64.
> 
> Relevant part:
> >  debian/rules build
> > dh build 
> >dh_testdir
> >dh_auto_configure
> >dh_auto_build
> > make[1]: Entering directory `/«PKGBUILDDIR»'
> > make -C uicilibris all
> > make[2]: Entering directory `/«PKGBUILDDIR»/uicilibris'
> > pyuic4 export.ui > Ui_export.py
> > /bin/sh: 1: pyuic4: not found
> > make[2]: *** [Ui_export.py] Error 127
> 
> The full build log is available from:
>
> http://people.debian.org/~lucas/logs/2012/07/24/uicilibris_1.8-1_unstable.log
> 
> A list of current common problems and possible solutions is available at 
> http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute!
> 
> About the archive rebuild: The rebuild was done on EC2 VM instances from
> Amazon Web Services, using a clean, minimal and up-to-date chroot. Every
> failed build was retried once to eliminate random failures.
> 

-- 
Georges KHAZNADAR et Jocelyne FOURNIER
22 rue des mouettes, 59240 Dunkerque France.
Téléphone +33 (0)3 28 29 17 70

--- control.orig	2012-07-24 20:22:31.35484 +0200
+++ control	2012-07-24 20:23:16.19084 +0200
@@ -353,8 +353,8 @@
  the Qt example programs ported to Python.
 
 Package: pyqt4-dev-tools
-Depends: python,
- python-qt4 (= ${binary:Version}),
+Depends: python3,
+ python3-pyqt4 (= ${binary:Version}),
  ${misc:Depends},
  ${shlibs:Depends}
 Architecture: any


signature.asc
Description: Digital signature

Bug#574235: Your "wims" stable upload

[Georges Khaznadar]

Thank you for the job Adam,

best regards,   Georges.

Adam D. Barratt a écrit :
> ...
> It is, however, in proposed-updates-NEW, as per
> http://release.debian.org/proposed-updates/stable.html
> ... 
> However, Andreas seems to have fixed up the bug state and reviewing the
> log the patch seems sane so I've flagged the package for acceptance.
> Please follow the documented procedures for any future stable uploads.
> 
> Regards,
> 
> Adam
> 
> 


signature.asc
Description: Digital signature

Bug#574235: Your "wims" stable upload

[Georges Khaznadar]

Hello Adam,

please accept my apologies, I forgot my obligations too long.

From the list of packages which I maintain, "wims" is the only with a RC
bug, which was raised by Andreas Beckmann. This bug is fixed in testing
and in unstable now, but Andreas raised it again because it is not fixed
in stable.

I proposed, as an update, a backport of the last version of wims to
squeeze with the version number 4.00-4+squeeze1.

This package does not seem to be referenced from
http://ftp-master.debian.org/new.html

I must clear this bug for Debian's version upgrade, and there are two
ways to do it:

- either ask you to accept the new package wims_4.00-4+squeeze1 which
  closes the bug report,
- or ask for removal of the package wims from squeeze, and manually
  close the bug report.

In both cases, the bug #574235 will be cleared, and wims users will be
happy (me too). 

Which is your mind? Would you accept a new submission of the package
wims for squeeze?

Best regards,   Georges.

Adam D. Barratt a écrit :
> On Tue, 2012-03-06 at 15:59 +, Georges Khaznadar wrote:
> > Adam D. Barratt a écrit :
> > > I noticed that you've uploaded "wims" to stable, in order to resolve
> > > #574235.  Was this discussed with any member of the Release Team
> > > beforehand?  If so, please could you point me at that discussion,
> > > because I'm currently unable to find it.
> > 
> > I sent a single e-mail to the Release Team just before uploading the
> > pqckage, so it can be not considered as a discussion.
> 
> Hmmm, when was that?  I still can't find it in my local mail, and it
> doesn't appear to be in the archives on lists.debian.org.
> 
> (In fact, neither of your mails today appear to have made it to the list
> or the archive either...)
> 
> > So here are elements to explain the upload I did:
> > 
> > - the bug #574235 is fixed in unstable: wims 4.03 is pretty installable.
> 
> Okay.  Which is the earliest version in which the affected code was
> either fixed or removed?  Please mark the bug as fixed in that version
> so that it's clearer what's going on.
> 
> >   However the first installation attempt always
> >   aborts when there is no earlier version of the package installed. The
> >   patch sent by Andreas is simple and fixes this bug nicely. The 
> > modification
> >   is just based on a reordering of commands in the post-installation
> >   script. It does not modify the package, it make just its installation
> >   successful at once, as it sould be.
> 
> That's still a modification. :-)
> 
> > > (Looking at the bug log, I can see that you were pointed to
> > > http://www.debian.org/doc/manuals/developers-reference/pkgs.html#upload-stable
> > >  ; this clearly indicates that any uploads to stable should be discussed 
> > > on -release first.)
> > 
> > I must apologize: I thought that only a notification was required. Next 
> > time I shall begin a true discussion before submitting the package.
> 
> Thanks.
> 
> Regards,
> 
> Adam
> 
> 


signature.asc
Description: Digital signature

Bug#676962: python-satellites: Missing dependency on python-tk

[Georges Khaznadar]

Hello Federico,

I shall fix the dependency issue, thank you for the report!

Federico Ceratto a écrit :
> Package: python-satellites
> Version: 1.0-5
> Severity: normal
> 
> Hi and thank you for packaging pysatellites
> The python-satellites package seems to be missing a dependency on python-tk:
> 
> $ pysatellites
> Traceback (most recent call last):
>   File "/usr/bin/pysatellites", line 3, in 
> import pysatellites
>   File "/usr/lib/python2.7/dist-packages/pysatellites/__init__.py", line 39, 
> in 
> from mainWindow import StartQT4
>   File "/usr/lib/python2.7/dist-packages/pysatellites/mainWindow.py", line 
> 33, in 
> from traj_satellite  import Trajectoire
>   File "/usr/lib/python2.7/dist-packages/pysatellites/traj_satellite.py", 
> line 9, in 
> from pylab import *
>   File "/usr/lib/pymodules/python2.7/pylab.py", line 1, in 
> from matplotlib.pylab import *
>   File "/usr/lib/pymodules/python2.7/matplotlib/pylab.py", line 264, in 
> 
> from matplotlib.pyplot import *
>   File "/usr/lib/pymodules/python2.7/matplotlib/pyplot.py", line 95, in 
> 
> new_figure_manager, draw_if_interactive, _show = pylab_setup()
>   File "/usr/lib/pymodules/python2.7/matplotlib/backends/__init__.py", line 
> 25, in pylab_setup
> globals(),locals(),[backend_name])
>   File "/usr/lib/pymodules/python2.7/matplotlib/backends/backend_tkagg.py", 
> line 8, in 
> import Tkinter as Tk, FileDialog
>   File "/usr/lib/python2.7/lib-tk/Tkinter.py", line 42, in 
> raise ImportError, str(msg) + ', please install the python-tk package'
> ImportError: No module named _tkinter, please install the python-tk package
> 
> After installing python-tk manually pysatellites ran.
> 
> Thank you.
> 
> -- System Information:
> Debian Release: wheezy/sid
>   APT prefers unstable
>   APT policy: (500, 'unstable')
> Architecture: i386 (i686)
> 
> Kernel: Linux 3.2.0-2-686-pae (SMP w/2 CPU cores)
> Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=ANSI_X3.4-1968) 
> (ignored: LC_ALL set to C)
> Shell: /bin/sh linked to /bin/dash
> 
> Versions of packages python-satellites depends on:
> ii  celestia-common1.6.1+dfsg-2
> ii  chromium [www-browser] 20.0.1132.21~r139451-3
> ii  ffmpeg 6:0.8.3-1
> ii  iceweasel [www-browser]10.0.5esr-1
> ii  libav-tools [ffmpeg]   6:0.8.3-1
> ii  netsurf-gtk [www-browser]  2.9-2
> ii  python 2.7.3~rc2-1
> ii  python-matplotlib  1.1.1~rc1-2
> ii  python-qt4 4.9.1-5
> ii  python2.6  2.6.7-4
> ii  python2.7  2.7.3~rc2-2.1
> ii  xplanet1.2.1-4.1+b1
> 
> python-satellites recommends no packages.
> 
> python-satellites suggests no packages.
> 
> -- no debconf information
> 
> 
> 


signature.asc
Description: Digital signature

Bug#669526: fixed in dozzaqueux 3.21-3

[Georges Khaznadar]

Thank you Matej,

in introduce the new build-depedency, and upload the newer package.

Best regards,   Georges.

Matej Vela a écrit :
> On Mon, May 28, 2012 at 03:25:07PM +0100, Stefano Rivera wrote:
> > Looks like the bug didn't get fixed, either.
> > https://buildd.debian.org/status/package.php?p=dozzaqueux
> 
> Hmm, it was building fine...  Ah, here we go, there's a missing build
> dependency on lcl-utils, which would (through lcl-utils-0.9.30.4) take
> care of setting up an alternative for lazarus:
> 
> [...]
> >>dh_auto_build -a
> >> update-alternatives: error: no alternatives for lazarus.
> >> update-alternatives: error: no alternatives for lazarus.
> >> ls: cannot access /usr/lib/lazarus//lcl/units/*/forms.ppu: No such file or 
> >> directory
> 
> optgeo does have a build dependency on lcl-utils, and the same check
> seems to be working there.
> 
> Cheers,
> 
> Matej
> 
> 
> 


signature.asc
Description: Digital signature

Bug#672727: kicad: diff for NMU (0.20120126+bzr3256-3.1)

[Georges Khaznadar]

Thank you Matej,

you can undelay your NMU, I had not enough time to understand what was
going wrong with kicad.

By the way: the version based on 0.20120126+bzr3256 is based on an
export made by upstream developers four months ago. Are there other
snapshots of interest maintained somewhere?

Best regards,   Georges

Matej Vela a écrit :
> tag 672727 pending
> thanks
> 
> Hi,
> 
> I'm uploading an NMU for kicad (0.20120126+bzr3256-3.1) to DELAYED/2-day.
> Please let me know if you'd like me to cancel it or delay further.
> 
> Cheers,
> 
> Matej



> --- kicad-0.20120126+bzr3256~/debian/changelog
> +++ kicad-0.20120126+bzr3256/debian/changelog
> @@ -1,3 +1,12 @@
> +kicad (0.20120126+bzr3256-3.1) unstable; urgency=low
> +
> +  * Non-maintainer upload.
> +  * gcc-4.7: Fix build failure with GCC 4.7.  Closes: #672727.
> +- include/boost/polygon/polygon_90_set_data.hpp: Include
> +  "detail/polygon_sort_adaptor.hpp" for gtlsort.
> +
> + -- Matej Vela   Fri, 25 May 2012 22:25:46 +0100
> +
>  kicad (0.20120126+bzr3256-3) unstable; urgency=low
>  
>* excluded .pdf files from dh_compress. Closes: #659660
> --- kicad-0.20120126+bzr3256~/debian/patches/gcc-4.7.patch
> +++ kicad-0.20120126+bzr3256/debian/patches/gcc-4.7.patch
> @@ -0,0 +1,17 @@
> +Description: Fix build failure with GCC 4.7
> + - include/boost/polygon/polygon_90_set_data.hpp: Include
> +   "detail/polygon_sort_adaptor.hpp" for gtlsort.
> +Bug-Debian: http://bugs.debian.org/672727
> +Author: Matej Vela 
> +Last-Update: 2012-05-17
> +
> +--- kicad-0.20120126+bzr3256~/include/boost/polygon/polygon_90_set_data.hpp
>  kicad-0.20120126+bzr3256/include/boost/polygon/polygon_90_set_data.hpp
> +@@ -16,6 +16,7 @@
> + #include "detail/iterator_points_to_compact.hpp"
> + #include "detail/iterator_compact_to_points.hpp"
> + #include "polygon_traits.hpp"
> ++#include "detail/polygon_sort_adaptor.hpp"
> + 
> + //manhattan boolean algorithms
> + #include "detail/boolean_op.hpp"
> --- kicad-0.20120126+bzr3256~/debian/patches/series
> +++ kicad-0.20120126+bzr3256/debian/patches/series
> @@ -0,0 +1 @@
> +gcc-4.7.patch





signature.asc
Description: Digital signature