Bug#1057130: sdcc: missing sdas6500

[Gabriele Gorla]

Package: sdcc
Version: 4.2.0+dfsg-1
Severity: important

Dear Maintainer,
the sdcc mos6502 target does not work because the required sdas6500 is
missing from the sdcc package.
Compiling any C file with:
sdcc -mmos6502 file.c 
will fail with:
sh: 1: sdas6500: not found


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

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

Versions of packages sdcc depends on:
ii  libc6   2.36-9+deb12u3
ii  libgcc-s1   12.2.0-14
ii  libstdc++6  12.2.0-14
ii  sdcc-libraries  4.2.0+dfsg-1
ii  zlib1g  1:1.2.13.dfsg-1

Versions of packages sdcc recommends:
ii  sdcc-doc  4.2.0+dfsg-1

Versions of packages sdcc suggests:
pn  python  
pn  sdcc-ucsim  

-- no debconf information

Bug#1018033: xjadeo: recommends unavailable packages mencoder and transcode

[Gabriele Stilli]

Package: xjadeo
Version: 0.8.11-1+b1
Severity: normal
X-Debbugs-Cc: superenz...@libero.it

Hi,

the package xjadeo recommends mencoder and transcode, but those packages
are currently unavailable in testing.

The package "mencoder" is part of the mplayer source, but the state of
mplayer in Debian is shaky at best, as described in this bug:
https://bugs.debian.org/1005899

The package "transcode" was removed from Debian in 2016.

Maybe it's better to try and find viable alternatives.

Cheers,
Gabriele :-)

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

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

Versions of packages xjadeo depends on:
ii  libasound21.2.7.2-1
ii  libavcodec59  7:5.1-2+b1
ii  libavformat59 7:5.1-2+b1
ii  libavutil57   7:5.1-2+b1
ii  libc6 2.34-4
ii  libfreetype6  2.12.1+dfsg-3
ii  libimlib2 1.7.4-2
ii  libjack-jackd2-0 [libjack-0.125]  1.9.21~dfsg-1
ii  liblo70.31-1
ii  libltc11  1.3.1-1
ii  libportmidi0  1:217-6.1
ii  libsdl1.2debian   1.2.15+dfsg2-8
ii  libswscale6   7:5.1-2+b1
ii  libx11-6  2:1.8.1-2
ii  libxext6  2:1.3.4-1
ii  libxpm4   1:3.5.12-1
ii  libxv12:1.0.11-1.1

Versions of packages xjadeo recommends:
pn  mencoder   
pn  transcode  

xjadeo suggests no packages.

-- no debconf information

Bug#1016590: php8.1-xdebug: update to php8.1-xdebug removes php7.4-xdebug without a reason

[Gabriele Dini Ciacci]

Package: php8.1-xdebug
Version: 3.1.2+2.9.8+2.8.1+2.5.5-4
Severity: important

Dear Maintainer,

the use case is a dev machine that needs to have both php7.4 and php8.1
running and both should have xdebug working. It's a long know issue
that was already solved time ago when php dirs where properly
re-organized. IMHO this is a rollback in pagkage organisazion. The
matter is hence probably already know to you. Anyhow the long
explanation.

If you have php-xdebug installed and you update you may get updated
from php7.4-xdebug to php8.1-xdebug. The latter removes php7.4-xdebug
(that is now a vitual package) and leaves you without debugging
functionality for php7.4. As said, you cannot install php7.4-xdebug
because it's virtual and manually downloading a .deb gives conflict.

To an initial inspection, there is no reason for the two pacakge to not
be able to live together on the system. php8.1 is using new API dir
20210902 meanwhile php7.4 is using API dir 20190902, hence the two
packages have no conflicting files (maybe the docs files in
php7.4-xdebug that are in a generic php-xdebug directory instead of a
versioned one, but that should be fixed in the package then, even if
php8.1-xdebug properly named its directory, so no problem).

Notice also that php8.1-xdebug migrated the conf files for xdebug by
*moving* user edited files from php7.4 directory. That should have
really been a *copy* of those files. If a conf file is edited for some
php version removing it might break a working module e.g. user has some
the mod compiled or other corner cases.

I expect to have two packages:
php7.4-xdebug
php8.1-xdebug
be able to have both of them installed on the system so to be able to
debug with both versions of php switching between them with
update-alternatives or just running both of them simulataneously with
php-fpm (quite common setup we have on our server).


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

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

Versions of packages php8.1-xdebug depends on:
ii  libc62.33-4
ii  php-common   2:76
ii  php8.1-cli [phpapi-20210902] 8.1.7-1
ii  php8.1-common8.1.7-1
ii  php8.1-phpdbg [phpapi-20210902]  8.1.7-1
ii  ucf  3.0043

php8.1-xdebug recommends no packages.

php8.1-xdebug suggests no packages.

-- no debconf information

Bug#971875: RFS: austin/2.0.0-1 -- Frame stack sampler for CPython

[Gabriele]

> would you be interested in joining the Debian Python team (
> https://wiki.debian.org/Teams/PythonTeam) and maintaining austin under its
> umbrella? it's generally easier to find sponsors for python-related
> projects there.

> btw, it would also be good if you could package austin-tui :)

OMG!  Apologies for this rather late reply of mine! I have just
accidentally discovered your reply to this RFS while looking for my
latest RFS status for v2.1.1!!!

If the offer is still up, I'd be happy to join the team! :)

Cheers,
Gabriele

-- 
"Egli è scritto in lingua matematica, e i caratteri son triangoli,
cerchi, ed altre figure
geometriche, senza i quali mezzi è impossibile a intenderne umanamente parola;
senza questi è un aggirarsi vanamente per un oscuro laberinto."

-- G. Galilei, Il saggiatore.

Bug#981814: lilypond-doc: Unable to upgrade

[Gabriele Stilli]

Hello,

I found the same identical bug on my machine. At least I can confirm
that it's not unreproducible :-)

If you need the extra information about my system, just tell me.

Regards,
Gabriele Stilli

Bug#981879: RFS: austin/2.1.1-1 -- Frame stack sampler for CPython

[Gabriele]

Dang! Like I said, this one is a bit tricky :(. I've pushed a new
revision. Fingers crossed.

On Sat, 6 Feb 2021 at 13:22, Adam Borowski  wrote:
>
> On Sat, Feb 06, 2021 at 12:53:53PM +, Gabriele wrote:
> > Thanks for reporting this and apologies for the late reply but I just
> > noticed this email in the spam folder!
> >
> > The new tests are a bit of a pain as they test for behaviour with/without
> > sudo so it very much depends on the host setup. I have uploaded a new
> > revision which I hope fixes the issue.
>
> Alas:
>
> autopkgtest
> ---
>
> autopkgtest [14:16:17]: starting date: 2021-02-06
> autopkgtest [14:16:17]: version 5.16
> autopkgtest [14:16:17]: host valinor; command line: /usr/bin/autopkgtest 
> /home/kilobyte/tmp/pkg/austin_2.1.1-1.dsc 
> /home/kilobyte/tmp/pkg/austin_2.1.1-1_amd64.changes -- schroot 
> unstable-amd64-pkgtest
> autopkgtest [14:16:17]: testbed dpkg architecture: amd64
> autopkgtest [14:16:17]: testbed running kernel: Linux 
> 5.11.0-rc6-00069-gc78e0fad19ee #1 SMP Wed Feb 3 20:21:40 CET 2021
> autopkgtest [14:16:17]:  source 
> /home/kilobyte/tmp/pkg/austin_2.1.1-1.dsc
> dpkg-source: warning: extracting unsigned source package 
> (/tmp/autopkgtest.Ir6aZU/austin_2.1.1-1.dsc)
> dpkg-source: info: extracting austin in src
> dpkg-source: info: unpacking austin_2.1.1.orig.tar.gz
> dpkg-source: info: unpacking austin_2.1.1-1.debian.tar.xz
> autopkgtest [14:16:18]: testing package austin version 2.1.1-1
> autopkgtest [14:16:18]: build not needed
> autopkgtest [14:16:18]: test command1: preparing testbed
> Get:1 file:/tmp/autopkgtest.Ir6aZU/binaries  InRelease
> Ign:1 file:/tmp/autopkgtest.Ir6aZU/binaries  InRelease
> Get:2 file:/tmp/autopkgtest.Ir6aZU/binaries  Release [816 B]
> Get:2 file:/tmp/autopkgtest.Ir6aZU/binaries  Release [816 B]
> Get:3 file:/tmp/autopkgtest.Ir6aZU/binaries  Release.gpg
> Ign:3 file:/tmp/autopkgtest.Ir6aZU/binaries  Release.gpg
> Get:4 file:/tmp/autopkgtest.Ir6aZU/binaries  Packages [1134 B]
> Reading package lists...
> Reading package lists...
> Building dependency tree...
> Reading state information...
> Correcting dependencies...Starting pkgProblemResolver with broken count: 0
> Starting 2 pkgProblemResolver with broken count: 0
> Done
>  Done
> Starting pkgProblemResolver with broken count: 0
> Starting 2 pkgProblemResolver with broken count: 0
> Done
> The following additional packages will be installed:
>   bats libc6-dbg valgrind
> Suggested packages:
>   valgrind-mpi kcachegrind alleyoop valkyrie
> Recommended packages:
>   parallel valgrind-dbg gdb
> The following NEW packages will be installed:
>   bats libc6-dbg valgrind
> 0 upgraded, 3 newly installed, 0 to remove and 0 not upgraded.
> 1 not fully installed or removed.
> Need to get 22.7 MB of archives.
> After this operation, 94.3 MB of additional disk space will be used.
> Get:1 http://apt-rosy.angband.pl:3142/debian unstable/main amd64 bats all 
> 1.2.1-1 [30.2 kB]
> Get:2 http://apt-rosy.angband.pl:3142/debian unstable/main amd64 libc6-dbg 
> amd64 2.31-9 [7507 kB]
> Get:3 http://apt-rosy.angband.pl:3142/debian unstable/main amd64 valgrind 
> amd64 1:3.16.1-1 [15.1 MB]
> Fetched 22.7 MB in 0s (174 MB/s)
> Selecting previously unselected package bats.
> (Reading database ... 9666 files and directories currently installed.)
> Preparing to unpack .../archives/bats_1.2.1-1_all.deb ...
> Unpacking bats (1.2.1-1) ...
> Selecting previously unselected package libc6-dbg:amd64.
> Preparing to unpack .../libc6-dbg_2.31-9_amd64.deb ...
> Unpacking libc6-dbg:amd64 (2.31-9) ...
> Selecting previously unselected package valgrind.
> Preparing to unpack .../valgrind_1%3a3.16.1-1_amd64.deb ...
> Unpacking valgrind (1:3.16.1-1) ...
> Setting up libc6-dbg:amd64 (2.31-9) ...
> Setting up bats (1.2.1-1) ...
> Setting up valgrind (1:3.16.1-1) ...
> Setting up autopkgtest-satdep (0) ...
> (Reading database ... 10502 files and directories currently installed.)
> Removing autopkgtest-satdep (0) ...
> autopkgtest [14:16:22]: test command1: bats test/test.bats
> autopkgtest [14:16:22]: test command1: [---
> 1..5
> ok 1 Test Austin: fork
> ok 2 Test Austin: fork multi-process
> ok 3 Test Austin: attach
> ok 4 Test Austin: valgrind
> not ok 5 Test Austin: errors
> # (from function `test_case' in file test/test.bats, line 27,
> #  in test file test/test.bats, line 51)
> #   `test_case error' failed
> # 1..6
> # not ok 1 Test no arguments
> # # (from function `check_ignored' in file test/common.bash, line 93,
> # #  from function `assert' in file test/common.bash, line 105,
> # #  from function `assert_success' in file test/common.bash, line

Bug#981879: RFS: austin/2.1.1-1 -- Frame stack sampler for CPython

[Gabriele]

Hi there

Thanks for reporting this and apologies for the late reply but I just
noticed this email in the spam folder!

The new tests are a bit of a pain as they test for behaviour with/without
sudo so it very much depends on the host setup. I have uploaded a new
revision which I hope fixes the issue.

Once again thanks for looking after this package!

Best regards,
Gabriele

On Fri, 5 Feb 2021 at 16:29, Adam Borowski  wrote:

> On Thu, Feb 04, 2021 at 06:49:57PM +0000, Gabriele wrote:
> >  * Package name: austin
> >Version : 2.1.1-1
>
> >  austin (2.1.1-1) unstable; urgency=medium
> >Improved general Python support on all the supported platforms.
> >Allowed specifying argument for time-like parameters using units
> (e.g. 10ms).
> >Error reporting has been made more accurate and informative.
> >Bugfix: Fixed line number reporting.
> >Bugfix: Fix symbol name clash on BSD systems with strtonum.
>
> Alas, it fails tests:
>
> FAIL: test/test
> ===
>
> 1..5
> ok 1 Test Austin: fork
> ok 2 Test Austin: fork multi-process
> ok 3 Test Austin: attach # skip requires root
> ok 4 Test Austin: valgrind
> not ok 5 Test Austin: errors
> # (from function `test_case' in file test/test.bats, line 27,
> #  in test file test/test.bats, line 51)
> #   `test_case error' failed
> # 1..6
> # ok 1 Test no arguments
> # ok 2 Test no command & PID
> # ok 3 Test not Python # skip requires root
> # ok 4 Test invalid command
> # ok 5 Test invalid PID
> # not ok 6 Test no permission
> # # (from function `check_ignored' in file test/common.bash, line 93,
> # #  from function `assert' in file test/common.bash, line 105,
> # #  from function `assert_status' in file test/common.bash, line 118,
> # #  in test file test/test_error.bats, line 92)
> # #   `assert_status 37' failed
> # # Test Austin with no permissions
> # #   Assertion failed:  "Got expected status (E: 37, G: 0)"
> # #
> # #Status: 0
> # #
> # #Collected Output
> # #
> # #
> # #   _   _
> # #  __ _ _  _ __| |_(_)_ _
> # # / _` | || (_-<  _| | ' \
> # # \__,_|\_,_/__/\__|_|_||_|
> # # 邏 austin version: 2.1.1
> # #  Python version: 3.9.1
> # #  Sampling time (min/avg/max) : 14/20/24 μs
> # #  Long sampling rate : 0/6 (0.00 %) samples took longer than the
> sampling interval
> # #  Error rate : 0/6 (0.00 %) invalid samples
> # # P61268;T17ec550; (/<>/test/sleepy.py);L35 44
> # # P61268;T17ec550; (/<>/test/sleepy.py);L35 100077
> # # P61268;T17ec550; (/<>/test/sleepy.py);L35 100066
> # # P61268;T17ec550; (/<>/test/sleepy.py);L35 100066
> # # P61268;T17ec550; (/<>/test/sleepy.py);L35 100074
> # # P61268;T17ec550; (/<>/test/sleepy.py);L35 100074
> # #
> FAIL test/test.bats (exit status: 1)
>
>
> Meow!
> --
> ⢀⣴⠾⠻⢶⣦⠀ .--[ Makefile ]
> ⣾⠁⢠⠒⠀⣿⡁ # beware of races
> ⢿⡄⠘⠷⠚⠋⠀ all: pillage burn
> ⠈⠳⣄ `
>


-- 


*"Egli è scritto in lingua matematica, e i caratteri son triangoli, cerchi,
ed altre figuregeometriche, senza i quali mezzi è impossibile a intenderne
umanamente parola;senza questi è un aggirarsi vanamente per un oscuro
laberinto."*

*-- *G. Galilei*, Il saggiatore.*

Bug#981879: RFS: austin/2.1.1-1 -- Frame stack sampler for CPython

[Gabriele]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "austin":

 * Package name: austin
   Version : 2.1.1-1
   Upstream Author : Gabriele N. Tornetta 
 * URL : https://github.com/P403n1x87/austin
 * License : GPL-3+
 * Vcs : https://github.com/P403n1x87/austin
   Section : devel

It builds those binary packages:

  austin - Frame stack sampler for CPython

To access further information about this package, please visit the
following URL:

  https://mentors.debian.net/package/austin/

Alternatively, one can download the package with dget using this command:

  dget -x 
https://mentors.debian.net/debian/pool/main/a/austin/austin_2.1.1-1.dsc

Changes since the last upload:

 austin (2.1.1-1) unstable; urgency=medium
 .
   Improved general Python support on all the supported platforms.
 .
   Allowed specifying argument for time-like parameters using units (e.g. 10ms).
 .
   Error reporting has been made more accurate and informative.
 .
   Bugfix: Fixed line number reporting.
 .
   Bugfix: Fix symbol name clash on BSD systems with strtonum.

Regards,
-- 
  Gabriele N. Tornetta

Bug#981491: lilypond-doc: lots of "install-info: warning: no info dir entry" messages

[Gabriele Stilli]

Package: lilypond-doc
Version: 2.22.0-5

Hello,

while upgrading from 2.22.0-4 to 2.22.0-5 a lot of info related warnings
appeared:

install-info: warning: no info dir entry in
`/usr/share/info/lilypond-extending.info.gz'
install-info: warning: no info dir entry in
`/usr/share/info/lilypond-snippets.info.gz'
install-info: warning: no info dir entry in
`/usr/share/info/lilypond-usage.info.gz'
install-info: warning: no info dir entry in
`/usr/share/info/lilypond-contributor.info.gz'
install-info: warning: no info dir entry in
`/usr/share/info/lilypond-learning.info.gz'
install-info: warning: no info dir entry in
`/usr/share/info/lilypond-essay.info.gz'
install-info: warning: no info dir entry in
`/usr/share/info/lilypond-notation.info.gz'
install-info: warning: no info dir entry in
`/usr/share/info/lilypond-changes.info.gz'
install-info: warning: no info dir entry in
`/usr/share/info/music-glossary.info.gz'

Any relevant info available on request.

Regards,
Gabriele Stilli

Bug#979718: Acknowledgement (request for new package rduty)

[Gabriele Giorgetti]

RFP: rduty  easily run commands on remote or local hosts and devices

COPYRIGHT is GPL2: https://github.com/gabgio/rduty/blob/main/LICENSE
Release:
https://github.com/gabgio/rduty/releases/download/v0.3.2/rduty-0.3.2.tar.gz
URL: https://github.com/gabgio/rduty

make deb  from the source tarball create a .deb package.

I'm looking to join as a maintainer myself, but I read that first a
sponsor is needed
But that's another story.

Thanks


Il giorno dom 10 gen 2021 alle ore 18:51 Debian Bug Tracking System <
ow...@bugs.debian.org> ha scritto:

> Thank you for filing a new Bug report with Debian.
>
> You can follow progress on this Bug here: 979718:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=979718.
>
> This is an automatically generated reply to let you know your message
> has been received.
>
> Your message is being forwarded to the package maintainers and other
> interested parties for their attention; they will reply in due course.
>
> Your message has been sent to the package maintainer(s):
>  unknown-pack...@qa.debian.org
>
> If you wish to submit further information on this problem, please
> send it to 979...@bugs.debian.org.
>
> Please do not send mail to ow...@bugs.debian.org unless you wish
> to report a problem with the Bug-tracking system.
>
> --
> 979718: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=979718
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems
>

Bug#979751: xserver-xorg-legacy: WARNING: tempfile is deprecated; consider using mktemp instead.

[Gabriele Stilli]

Package: xserver-xorg-legacy
Version: 2:1.20.10-2

Hello,

during configuration, the package threw up this message:

Configurazione di xserver-xorg-legacy (2:1.20.10-2)...
setting xserver-xorg-legacy/xwrapper/allowed_users from configuration file
WARNING: tempfile is deprecated; consider using mktemp instead.

(Configurazione di = Configuring)

Regards,
Gabriele Stilli

Bug#979718: request for new package rduty

[Gabriele Giorgetti]

Subject: rduty: request for new package rduty
Package: rduty
Version: 0.3.2-1
Severity: wishlist

Dear Maintainer,

request for new package:
rduty is a Python script to easily and quickly run a command or multiple
commands on remote and local hosts and devices via ssh (telnet is also
supported).
It is also able to automate repetitive tasks on many hosts using inventory
files from Ansible, or simple .ini inventory files.

https://github.com/gabgio/rduty

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

Kernel: Linux 5.9.0-5-amd64 (SMP w/4 CPU threads)
Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8),
LANGUAGE=it:en_US
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages rduty depends on:
ii  python3  3.9.1-1

-- no debconf information

Bug#979459: jed: WARNING: tempfile is deprecated; consider using mktemp instead.

[Gabriele Stilli]

Package: jed
Version: 1:0.99.19-8

Hello,

during configuration, the package threw up this message:

Configurazione di jed (1:0.99.19-8)...
WARNING: tempfile is deprecated; consider using mktemp instead.

(Configurazione di = Configuring)

Regards,
Gabriele Stilli

Bug#979458: jed-common: WARNING: tempfile is deprecated; consider using mktemp instead.

[Gabriele Stilli]

Package: jed-common
Version: 1:0.99.19-8

Hello,

during configuration, the package threw up these messages:

Preparativi per estrarre .../13-jed-common_1%3a0.99.19-8_all.deb...
WARNING: tempfile is deprecated; consider using mktemp instead.

Configurazione di jed-common (1:0.99.19-8)...
WARNING: tempfile is deprecated; consider using mktemp instead.

(Preparativi per estrarre = Preparing to extract; Configurazione di =
Configuring)

Regards,
Gabriele Stilli

Bug#975403: knocker 0.8.0

[Gabriele Giorgetti]

version 0.8.0 is out, it should fix the upstream bug.

thanks

Bug#716038: knocker 0.8.0

[Gabriele Giorgetti]

Hi,

this is just to tell you that knocker 0.8.0 has been released and it fixes
those bugs.

https://github.com/gabgio/knocker
or
https://knocker.sourceforge.io/

Maybe you can reintroduce it in unstable.

Thanks.

Regards.

Bug#975658: This bug is affecting Firefox

[Gabriele Svelto]

We've detected instances of this bug crashing Firefox. The corresponding
bug in our tracker is this one:

https://bugzilla.mozilla.org/show_bug.cgi?id=1679430

Note that the crash doesn't seem to be present in upstream libdrm, it
seems to me that the `hurd-port.diff` patch applied to the Debian
package is introducing it.

 Gabriele Svelto

Bug#973920: bash: malformed line in changelog.Debian.gz

[Gabriele Stilli]

Package: src:bash
Version: 2.01-0
Severity: minor

Hello,

a malformed line in changelog.Debian.gz triggers a warning when trying
to open said changelog inside aptitude. To reproduce it, open aptitude
(the ncurses interface), go to the "bash" package and press C (capital
C). The warning message is interspersed within the aptitude window, so
it can't be pasted here. I can't seem to reproduce it calling
aptitude-changelog-parser from the command line.

The guilty line seems to be:

"-- James Troup   Thur, 19 June 1997 19:13:34
+0100"

(yes, that's 1997, a whopping 23 years ago). It belongs to bash version
2.01-0, hence the "Version:" header.

I suspect that changing "Thur," into "Thu," would fix the issue.

Sorry for digging up such an archeological find.

Regards,
Gabriele Stilli

Bug#969082: RM: austin [armhf mipsel] -- RoM; ANAIS

[Gabriele]

Hi there

> Have you asked upstream about this?

I have been advised to open this issue to fix this. I'd love to
investigate the cause of the hangs on mipsel and armhf but
unfortunately I do not have easy access to such architectures. Hence,
for me at the moment, the request for removal is the only viable
option.

Please note that I have already submitted version 2.0.0-1 of Austin. I
have excluded the mentioned architecture in the debian/control file.
Hopefully I will have the chance to address this issue in the future
so that those archs can be supported again.

Cheers,
Gabriele

On Sat, 3 Oct 2020 at 19:56, Sean Whitton  wrote:
>
> control: tag -1 + moreinfo
>
> Hello,
>
> On Thu 27 Aug 2020 at 09:49am +01, Gabriele wrote:
>
> > May I kindly ask you to remove the austin binaries for architectures
> > armhf and mipsel for the time being, in order to fix the issue
> >
> > Bug#968309: src:austin: fails to migrate to testing for too long:
> > FTBFS on armhf and mipsel
> >
> > These binaries will not be requested again in future revisions
> > until I can manage to fix the actual underlying issue with Austin.
> > Unfortunately, I don't see a quicker way of dealing with this matter
> > at the moment, as I don't have the time and resources to debug on the
> > mentioned architectures.
>
> Have you asked upstream about this?
>
> Typically it is better to confirm that the bug is not a trivial fix
> before resorting to removal.
>
> --
> Sean Whitton



-- 
"Egli è scritto in lingua matematica, e i caratteri son triangoli,
cerchi, ed altre figure
geometriche, senza i quali mezzi è impossibile a intenderne umanamente parola;
senza questi è un aggirarsi vanamente per un oscuro laberinto."

-- G. Galilei, Il saggiatore.

Bug#971875: RFS: austin/2.0.0-1 -- Frame stack sampler for CPython

[Gabriele]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "austin":

 * Package name: austin
   Version : 2.0.0-1
   Upstream Author : Gabriele N. Tornetta 
 * URL : https://github.com/P403n1x87/austin
 * License : GPL-3+
 * Vcs : https://github.com/P403n1x87/austin
   Section : devel

It builds those binary packages:

  austin - Frame stack sampler for CPython

To access further information about this package, please visit the
following URL:

  https://mentors.debian.net/package/austin/

Alternatively, one can download the package with dget using this command:

  dget -x 
https://mentors.debian.net/debian/pool/main/a/austin/austin_2.0.0-1.dsc

Changes since the last upload:

 austin (2.0.0-1) unstable; urgency=medium
 .
   Substantial performance improvements. Austin 2 can sample deep call stacks
   5 to 8 times faster than previous versions.
 .
   Support for Python 3.9.
 .
   Added the exposure option to instruct Austin to sample for a given number of
   seconds only.

Regards,
--
  Gabriele N. Tornetta

Bug#971401: texlive-binaries: triggers update-alternatives warning for bibtex

[Gabriele Stilli]

Il 03/10/20 11:48, Hilmar Preuße ha scritto:

> The new TL base migrated into testing, so the issue should be gone
> now. Could you retest?
Hello,

after upgrading I tried to reinstall texlive-binaries a first time and
the error was there. Tried a second time and it was gone. Probably on
the first attempt the update-alternatives database was still broken and
needed a repair. Log follows. A third run didn't show the error either.

Thanks again!

Regards,
Gabriele

root@camelot:~# LC_ALL=C apt-get install --reinstall texlive-binaries
Reading package lists... Done
Building dependency tree
Reading state information... Done
0 upgraded, 0 newly installed, 1 reinstalled, 0 to remove and 0 not
upgraded.
Need to get 0 B/10.1 MB of archives.
After this operation, 0 B of additional disk space will be used.
(Reading database ... 424725 files and directories currently installed.)
Preparing to unpack .../texlive-binaries_2020.20200327.54578-5_amd64.deb ...
Unpacking texlive-binaries (2020.20200327.54578-5) over
(2020.20200327.54578-5) ...
Setting up texlive-binaries (2020.20200327.54578-5) ...
update-alternatives: warning: forcing reinstallation of alternative
/usr/bin/bibtex.original because link group bibtex is broken
Processing triggers for man-db (2.9.3-2) ...
Processing triggers for install-info (6.7.0.dfsg.2-5) ...
install-info: warning: no info dir entry in
`/usr/share/info/automake-history.info.gz'
Processing triggers for tex-common (6.15) ...
Building format(s) --all.
This may take some time... done.
==  How can you help?  (doc: https://wiki.debian.org/how-can-i-help)
==

-  Show old opportunities as well as new ones: how-can-i-help --old
-
root@camelot:~# LC_ALL=C apt-get install --reinstall texlive-binaries
Reading package lists... Done
Building dependency tree
Reading state information... Done
0 upgraded, 0 newly installed, 1 reinstalled, 0 to remove and 0 not
upgraded.
Need to get 0 B/10.1 MB of archives.
After this operation, 0 B of additional disk space will be used.
(Reading database ... 424725 files and directories currently installed.)
Preparing to unpack .../texlive-binaries_2020.20200327.54578-5_amd64.deb ...
Unpacking texlive-binaries (2020.20200327.54578-5) over
(2020.20200327.54578-5) ...
Setting up texlive-binaries (2020.20200327.54578-5) ...
Processing triggers for man-db (2.9.3-2) ...
Processing triggers for install-info (6.7.0.dfsg.2-5) ...
install-info: warning: no info dir entry in
`/usr/share/info/automake-history.info.gz'
Processing triggers for tex-common (6.15) ...
Building format(s) --all.
This may take some time... done.
==  How can you help?  (doc: https://wiki.debian.org/how-can-i-help)
==

-  Show old opportunities as well as new ones: how-can-i-help --old
 -

Bug#971401: texlive-binaries: triggers update-alternatives warning for bibtex

[Gabriele Stilli]

Il 30/09/20 16:50, Hilmar Preuße ha scritto:

> At least I expect that it should solve the issue, as the file 
> conflict has been removed. Could you re-test once the package
> entered testing?

Of course, I will :-)

Gabriele

Bug#971401: texlive-binaries: triggers update-alternatives warning for bibtex

[Gabriele Stilli]

Il 30/09/20 07:47, Hilmar Preuße ha scritto:

> Which version of texlive-base do you have installed?

2020.20200804-3, the one currently in testing.

Ah, now I see the latest texlive-base 2020.20200925-1 fixes #970838,
which should be the real bug behind this one. Is this so? In this case,
apologies for the noise.

Gabriele

Bug#971401: texlive-binaries: triggers update-alternatives warning for bibtex

[Gabriele Stilli]

Package: texlive-binaries
Version: 2020.20200327.54578-5

Hello,

while configuring texlive-binaries, the following warning appeared:

update-alternatives: warning: forcing reinstallation of alternative
/usr/bin/bibtex.original because link group bibtex is broken
update-alternatives: warning: not replacing
/usr/share/man/man1/bibtex.1.gz with a link

The warning is reproducible on subsequent reinstallations.

Regards,
Gabriele Stilli

Bug#883194: please convert mountstats and nfsiostat scripts to Python3

[Gabriele Stilli]

Hello,

recently Debian removed the binary package "python" from sid and
testing, thus breaking the Recommends: for nfs-common. The affected
scripts should be converted to Python 3 and the Recommend: field should
be updated accordingly.

Regards,
Gabriele Stilli

Bug#969082: RM: austin [armhf mipsel] -- RoM; ANAIS

[Gabriele]

Package: ftp.debian.org
Severity: normal

Dear ftp-master

May I kindly ask you to remove the austin binaries for architectures
armhf and mipsel for the time being, in order to fix the issue

Bug#968309: src:austin: fails to migrate to testing for too long:
FTBFS on armhf and mipsel

These binaries will not be requested again in future revisions
until I can manage to fix the actual underlying issue with Austin.
Unfortunately, I don't see a quicker way of dealing with this matter
at the moment, as I don't have the time and resources to debug on the
mentioned architectures.

Many thanks.

Best regards,
Gabriele

Bug#968309: src:austin: fails to migrate to testing for too long: FTBFS on armhf and mipsel

[Gabriele]

Dear Release Team

I believe this migration issue is caused by the build failure of
Austin on a couple of architectures. Unfortunately, I do not have the
means to debug on such platforms and therefore I am unlikely to be
able to provide a fix. Austin is guaranteed to work on the arm65, i368
and amd64 architectures. If tests pass on other platforms that's a
bonus, but given that I cannot develop nor test on other platforms, I
cannot guarantee broader support.

Please let me know if there's anything that I can do to address this issue.

Best regards,
Gabriele

On Wed, 12 Aug 2020 at 20:51, Paul Gevers  wrote:
>
> Source: austin
> Version: 1.0.0-1
> Severity: serious
> Control: close -1 1.0.1-2
> Tags: sid bullseye
> 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:austin in its
> current version in unstable has been trying to migrate for 66 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 bullseye, 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=austin
>
>


-- 
"Egli è scritto in lingua matematica, e i caratteri son triangoli,
cerchi, ed altre figure
geometriche, senza i quali mezzi è impossibile a intenderne umanamente parola;
senza questi è un aggirarsi vanamente per un oscuro laberinto."

-- G. Galilei, Il saggiatore.

Bug#968664: debian-policy: recommends an old version of libjs-sphinxdoc, again and again

[Gabriele Stilli]

Package: debian-policy
Version: 4.5.0.2

Hi,

as already happened, (#910561, #921889, #932359, #959005), the latest
libjs-sphinxdoc (3.2.1-1) breaks d-p's Recommends.

As a sidenote, I see bug #658238, from which this problem descends, has
been closed in sphinx version 1.8.1-1.

Thank you, once more!

Regards,
Gabriele Stilli

Bug#886798: Fwd: Hey

[Gabriele]

Hotshowshere! - https://wlsg-fkib.myshopify.com/Gabriele

Bug#962347: RFS: austin/1.0.1-2 [RC] -- Frame stack sampler for CPython

[Gabriele]

Package: sponsorship-requests
Severity: important

Dear mentors,

I am looking for a sponsor for my package "austin"

 * Package name: austin
   Version : 1.0.1-2
   Upstream Author : Gabriele N. Tornetta 
 * URL : https://github.com/P403n1x87/austin
 * License : GPL-3+
 * Vcs : https://github.com/P403n1x87/austin
   Section : devel

It builds those binary packages:

  austin - Frame stack sampler for CPython

To access further information about this package, please visit the
following URL:

  https://mentors.debian.net/package/austin

Alternatively, one can download the package with dget using this command:

  dget -x 
https://mentors.debian.net/debian/pool/main/a/austin/austin_1.0.1-2.dsc

Changes since the last upload:

   Enhanced test sources. Closes: #962001.

Regards,

--
  Gabriele N. Tornetta

Bug#962001: austin: autopkgtest regression: src/austin: No such file or directory

[Gabriele]

Ok will do!

Thanks,
Gabriele

On Wed, 3 Jun 2020 at 20:06, Paul Gevers  wrote:
>
> Hi Gabriele,
>
> On 03-06-2020 18:29, Gabriele wrote:
> > Ok mystery solved :). Once I have this fixed, what should I do? Push
> > the new tarball with the same version (1.0.1-1) or should I bump
> > something in the version? I'd expect that perhaps that -1 should
> > become a -2? If so, what's the correct way of doing this?
>
> Unfortunately I don't have the energy to mentor you in this process
> right now. I recommend you consult debian-ment...@lists.debian.org or
> #debian-mentors on IRC for pointers to the right documentation and help
> to get this fixed.
>
> Paul
>


-- 
"Egli è scritto in lingua matematica, e i caratteri son triangoli,
cerchi, ed altre figure
geometriche, senza i quali mezzi è impossibile a intenderne umanamente parola;
senza questi è un aggirarsi vanamente per un oscuro laberinto."

-- G. Galilei, Il saggiatore.

Bug#962001: austin: autopkgtest regression: src/austin: No such file or directory

[Gabriele]

Hi Paul

Ok mystery solved :). Once I have this fixed, what should I do? Push
the new tarball with the same version (1.0.1-1) or should I bump
something in the version? I'd expect that perhaps that -1 should
become a -2? If so, what's the correct way of doing this?

Cheers,
Gabriele

On Wed, 3 Jun 2020 at 16:36, Paul Gevers  wrote:
>
> Hi Gabriele,
>
> On 02-06-2020 23:37, Gabriele wrote:
> > Many thanks for your reply. I have had a look at the logs linked on this 
> > page
> >
> > https://ci.debian.net/packages/a/austin/testing/amd64/
> >
> > The only version that passes is v1.0.0 and by looking at the logs of
> > v0.7.0 and v1.0.1, which fail, it's a miracle that v1.0.0 even passes.
> > Indeed v0.7.0 and v1.0.1 fail for the very same reason: the binary
> > used for the tests, src/austin, is simply not there. Why it is there
> > for the v1.0.0 I don't know, so it looks like the problem is with
> > v1.0.0 paradoxically.
>
> It's funny, the first tries of 1.0.0 also failed. And I believe they
> they only starting passing when python3.7 was not the default Python3
> anymore.
>
> > This is the diff inside the debian/ folder between v1.0.0 and v1.0.1
> > (TLDR: only debian/austin.1, debian/changelog and debian/copyright
> > have changed)
>
> Instead, I diffed the source and this struck my eye:
>
> diff -Nru austin-1.0.0/test/test_fork.bats austin-1.0.1/test/test_fork.bats
> --- austin-1.0.0/test/test_fork.bats2019-10-19 10:37:23.0 +
> +++ austin-1.0.1/test/test_fork.bats2020-02-21 19:27:02.0 +
> @@ -56,6 +56,12 @@
>then
>  skip "Test failed but marked as 'Ignore'"
>else
> +echo
> +echo "Collected Output"
> +echo ""
> +echo
> +echo "$output"
> +echo
>  false
>fi
>  }
> @@ -109,6 +115,6 @@
>invoke_austin "3.7"
>  }
>
> -# @test "Test Austin with Python 3.8" {
> -#   invoke_austin "3.8"
> -# }
> +@test "Test Austin with Python 3.8" {
> +  invoke_austin "3.8"
> +}
>
> So, with 1.0.0 your tests were passing because all tests were skipped,
> and only with 1.0.1 your tests started testing the code again and failed
> because the required binary couldn't be found.
>
>
> > Hence, to the best of my knowledge, there are no changes in the
> > debian/ area that would cause the binary in src/ to be there unless it
> > accidentally ended up, say, in the source tarball.
>
> I think I've showed an alternative explanation.
>
> > My next question to you is then: where is the binary supposed to be
> > found during autopkgtest? Can I assume it will be on the PATH during
> > testing, so that I can invoke it simply with "austin"? Or do I need to
> > specify a precise path?
>
> The testbed is a clean Debian installation, created with debbootstrap
> and only your test dependencies installed. Everything is in it's regular
> location, so if austin is on the regular path for users, it on the
> regular path for the debci user in the testbed. Not specifying the
> precise path makes sure your testing that it's on the path for your
> users too, so better without path.
>
> Paul
>


-- 
"Egli è scritto in lingua matematica, e i caratteri son triangoli,
cerchi, ed altre figure
geometriche, senza i quali mezzi è impossibile a intenderne umanamente parola;
senza questi è un aggirarsi vanamente per un oscuro laberinto."

-- G. Galilei, Il saggiatore.

Bug#962001: austin: autopkgtest regression: src/austin: No such file or directory

[Gabriele]

Hi Paul

Many thanks for your reply. I have had a look at the logs linked on this page

https://ci.debian.net/packages/a/austin/testing/amd64/

The only version that passes is v1.0.0 and by looking at the logs of
v0.7.0 and v1.0.1, which fail, it's a miracle that v1.0.0 even passes.
Indeed v0.7.0 and v1.0.1 fail for the very same reason: the binary
used for the tests, src/austin, is simply not there. Why it is there
for the v1.0.0 I don't know, so it looks like the problem is with
v1.0.0 paradoxically.

This is the diff inside the debian/ folder between v1.0.0 and v1.0.1
(TLDR: only debian/austin.1, debian/changelog and debian/copyright
have changed)

$ git diff v1.0.0 v1.0.1 debian/
diff --git a/debian/austin.1 b/debian/austin.1
index 95a8ab0..3452e92 100644
--- a/debian/austin.1
+++ b/debian/austin.1
@@ -1,7 +1,7 @@
 .\" DO NOT MODIFY THIS FILE!  It was generated by help2man 1.47.6.
-.TH AUSTIN "1" "October 2019" "austin 1.0.0" "User Commands"
+.TH AUSTIN "16" "May 2020" "austin 1.0.1" "User Commands"
 .SH NAME
-austin \- manual page for austin 1.0.0
+austin \- manual page for austin 1.0.1
 .SH SYNOPSIS
 .B austin
 [\fI\,OPTION\/\fR...] \fI\,command \/\fR[\fI\,ARG\/\fR...]
diff --git a/debian/changelog b/debian/changelog
index 6d31034..352af1a 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+austin (1.0.1-1) unstable; urgency=medium
+
+  * Fixed support for Python 3.8
+
+ -- Gabriele N. Tornetta   Sat, 16 May 2020
12:36:00 +0100
+
+
 austin (1.0.0-1) unstable; urgency=medium

   * Added support for multi-process Python applications
diff --git a/debian/copyright b/debian/copyright
index 954ddfd..2f08861 100644
--- a/debian/copyright
+++ b/debian/copyright
@@ -4,7 +4,7 @@ Upstream-Contact: Gabriele N. Tornetta 
 Source: https://github.com/P403n1x87/austin

 Files: *
-Copyright: 2018-2019 Gabriele N. Tornetta 
+Copyright: 2018-2020 Gabriele N. Tornetta 
 License: GPL-3+

 License: GPL-3+



This is the diff inside the test/ folder (TLDR: only a test condition
has changed, but the problem is that bats cannot find the binary
src/austin, so it can't even get to the point where the test logic has
changed).

$ git diff v1.0.0 v1.0.1 test/
diff --git a/test/test_fork_mp.bats b/test/test_fork_mp.bats
index 391563b..797e0d1 100644
--- a/test/test_fork_mp.bats
+++ b/test/test_fork_mp.bats
@@ -18,9 +18,8 @@ invoke_austin() {
 echo "   - Check expected number of processes."
 expected=3
 n_procs=$( echo "$output" | sed -r 's/Process ([0-9]+);.+/\1/' |
sort | uniq | wc -l )
-echo " Expected $expected and got $n_procs"
-if [ $n_procs != $expected ]
-then continue; fi
+echo " Expected at least $expected and got $n_procs"
+if [ $n_procs < $expected ]; then continue; fi

 echo "   - Check output contains frames."
 if echo "$output" | grep -q "do
(test/target_mp.py);L[[:digit:]]*;fact (test/target_mp.py);L"
@@ -39,7 +38,7 @@ invoke_austin() {
 echo ""
 echo
 echo "$output"
-echo
+echo
 false
   fi
 }



Hence, to the best of my knowledge, there are no changes in the
debian/ area that would cause the binary in src/ to be there unless it
accidentally ended up, say, in the source tarball.

My next question to you is then: where is the binary supposed to be
found during autopkgtest? Can I assume it will be on the PATH during
testing, so that I can invoke it simply with "austin"? Or do I need to
specify a precise path?

Thanks for your support thus far.

Cheers,
Gabriele

Bug#962001: austin: autopkgtest regression: src/austin: No such file or directory

[Gabriele]

Hi Paul

Thanks for the report. Please note that nothing has changed in the way
Austin is built and packaged in-between version 1.0.0 and 1.0.1. From
what I can tell from the log, the tests are failing because src/austin
is not found, which would be the case if it's not being compiled from
sources using autotools. Indeed, in the linked logs I have spotted

autopkgtest [18:07:10]: build not needed

My guess is that a build is not needed for a binary package because
the binary should already be there? If so, it probably won't be in
src/, hence the failure.

As I said, the way of testing, building, and packaging Austin hasn't
changed across releases, which leads me to think that perhaps
something has changed in the Debian publication pipeline? Having said
that, I'd be happy to try and fix this if you could point me in the
right direction.

Thanks,
Gabriele

On Mon, 1 Jun 2020 at 21:27, Paul Gevers  wrote:
>
> Source: austin
> Version: 1.0.1-1
> X-Debbugs-CC: debian...@lists.debian.org
> Severity: serious
> User: debian...@lists.debian.org
> Usertags: regression
>
> Dear maintainer(s),
>
> With a recent upload of austin the autopkgtest of austin fails in
> testing when that autopkgtest is run with the binary packages of austin
> from unstable. It passes when run with only packages from testing. In
> tabular form:
>
>passfail
> austin from testing1.0.1-1
> all others from testingfrom testing
>
> I copied some of the output at the bottom of this report.
>
> Currently this regression is blocking the migration to testing [1]. Can
> you please investigate the situation and fix it?
>
> 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=austin
>
> https://ci.debian.net/data/autopkgtest/testing/amd64/a/austin/5721929/log.gz
>
> # not ok 11 Test Austin with Python 3.8
> # # (from function `invoke_austin' in file test/test_fork.bats, line 65,
> # #  in test file test/test_fork.bats, line 119)
> # #   `invoke_austin "3.8"' failed with status 127
> # # Python 3.8.3
> # # > Run 1 of 3
> # #   :: Standard profiling
> # #Exit code: 127
> # # > Run 2 of 3
> # #   :: Standard profiling
> # #Exit code: 127
> # # > Run 3 of 3
> # #   :: Standard profiling
> # #Exit code: 127
> # #
> # # Collected Output
> # # 
> # #
> # # /usr/libexec/bats-core/bats-exec-test: line 62: src/austin: No such
> file or directory
> # #
> not ok 2 Test Austin: fork multi-process
>


-- 
"Egli è scritto in lingua matematica, e i caratteri son triangoli,
cerchi, ed altre figure
geometriche, senza i quali mezzi è impossibile a intenderne umanamente parola;
senza questi è un aggirarsi vanamente per un oscuro laberinto."

-- G. Galilei, Il saggiatore.

Bug#961235: RFS: austin/1.0.1-1 -- Frame stack sampler for CPython

[Gabriele]

Oh dear. I didn't spot that one! Thanks for reporting this, I have
uploaded a new version with the amended manpage.

Cheers,
Gabriele

On Fri, 22 May 2020 at 23:47, Adam Borowski  wrote:
>
> On Thu, May 21, 2020 at 08:26:40PM +0100, Gabriele wrote:
> >  * Package name: austin
> >Version : 1.0.1-1
>
> > Changes since the last upload:
> >
> >* Fixed support for Python 3.8
>
> Fails to build:
>dh_installman -O--buildsystem=autoconf
> dh_installman: warning: Section for ./debian/austin.1 is computed as "16", 
> which is not a valid section
> dh_installman: error: Could not determine section for ./debian/austin.1
> dh_installman: error: Aborting due to earlier error
>
>
> Meow!
> --
> ⢀⣴⠾⠻⢶⣦⠀
> ⣾⠁⢠⠒⠀⣿⡁ in the beginning was the boot and root floppies and they were good.
> ⢿⡄⠘⠷⠚⠋⠀   --  on #linux-sunxi
> ⠈⠳⣄



-- 
"Egli è scritto in lingua matematica, e i caratteri son triangoli,
cerchi, ed altre figure
geometriche, senza i quali mezzi è impossibile a intenderne umanamente parola;
senza questi è un aggirarsi vanamente per un oscuro laberinto."

-- G. Galilei, Il saggiatore.

Bug#961235: RFS: austin/1.0.1-1 -- Frame stack sampler for CPython

[Gabriele]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "austin"

 * Package name: austin
   Version : 1.0.1-1
   Upstream Author : Gabriele N. Tornetta 
 * URL : https://github.com/P403n1x87/austin
 * License : GPL-3+
 * Vcs : https://github.com/P403n1x87/austin
   Section : devel

It builds those binary packages:

  austin - Frame stack sampler for CPython

To access further information about this package, please visit the
following URL:

  https://mentors.debian.net/package/austin

Alternatively, one can download the package with dget using this command:

  dget -x 
https://mentors.debian.net/debian/pool/main/a/austin/austin_1.0.1-1.dsc

Changes since the last upload:

   * Fixed support for Python 3.8

Regards,

--
  Gabriele N. Tornetta

Bug#960111: lxde: recommends deprecated clipit

[Gabriele Stilli]

Package: lxde
Version: 10

Hello,

lxde recommends clipit, which is now deprecated. It should be upgraded
to a current package, e.g. diodon.

Regards,
Gabriele Stilli

Bug#960109: clipit: wrong changelog entry

[Gabriele Stilli]

Source: clipit
Version: 1.4.4+git20190202-2

Hello,

the latest changelog reads: "Diodon will be removed from Debian after
Bullseye is released."

Maybe it was meant to read "Clipit will be removed"?

Regards,
Gabriele Stilli

Bug#954893: aptitude: messages from AppStream garble the ncurses interface

[Gabriele Stilli]

Il 24/03/20 22:55, Gabriele Stilli ha scritto:

> Package: aptitude
> Version: 0.8.12-3
> 
> Hello,
> 
> I use aptitude with the ncurses interface. Every time I do an update
> (press "u" in the program), the following message from AppStream pops up
> at the end:
> 
> "The AppStream system cache was updated, but some components were
> ignored. Refer to the verbose log for more information."
> 
> As a result, the interface gets garbled all around. I attach a
> screenshot illustrating the end result.

Hello again,

just for information, apparently I can't reproduce the bug anymore. This
might mean that something has changed in my AppStream cache
configuration or perhaps some other reason I can't spot right now. The
aptitude version hasn't changed (and hopefully neither has its
configuration). Just thought it useful to mention this.

Regards,
Gabriele Stilli

Bug#959005: debian-policy: recommends an old version of libjs-sphinxdoc, once again

[Gabriele Stilli]

Package: debian-policy
Version: 4.5.0.1

Hi,

once again (#910561, #921889, #932359), the latest libjs-sphinxdoc
(2.4.3-2) breaks d-p's Recommends.

Thank you, once more!

Regards,
Gabriele Stilli

Bug#956046: python3-pycryptodome: SyntaxWarning: "is" with a literal

[Gabriele Stilli]

Package: python3-pycryptodome
Version: 3.6.1-3

Hello,

on config, a Python script in python3-pycryptodome spits out a warning:

/usr/lib/python3/dist-packages/Cryptodome/SelfTest/Random/test_random.py:103:
SyntaxWarning: "is" with a literal. Did you mean "=="?
  if sys.version_info[0] is 3:

Regards,
Gabriele Stilli

Bug#955172: python3-l20n: SyntaxWarning: "is" with a literal

[Gabriele Stilli]

Package: python3-l20n
Version: 4.0.0~a1-5

Hello,

on running python rtupdate hooks, a Python script in python3-l20n spits
out a warning:

/usr/lib/python3/dist-packages/l20n/format/parser.py:79: SyntaxWarning:
"is not" with a literal. Did you mean "!="?
  if self._index is not 0 and \

Regards,
Gabriele Stilli

Bug#955170: solfege: SyntaxWarning: "is" with a literal

[Gabriele Stilli]

Package: solfege
Version: 3.23.4-7

on running python rtupdate hooks, a Python script in solfege spits out
these warnings:

/usr/share/solfege/solfege/mpd/lexer.py:166: SyntaxWarning: "is" with a
literal. Did you mean "=="?
  if notelen is 0:
/usr/share/solfege/solfege/mpd/lexer.py:186: SyntaxWarning: "is" with a
literal. Did you mean "=="?
  if skiplen is 0:

Regards,
Gabriele Stilli

Bug#955169: mma: SyntaxWarning: "is" with a literal

[Gabriele Stilli]

Package: mma
Version: 20.02-1

Hello,

on running python rtupdate hooks, a Python script in mma spits out a
warning:

/usr/share/mma/MMA/pat.py:1204: SyntaxWarning: "is" with a literal. Did
you mean "=="?
  if self.vtype is 'PLECTRUM':

Regards,
Gabriele Stilli

Bug#955168: hplip-data: SyntaxWarning: "is" with a literal

[Gabriele Stilli]

Package: hplip-data
Version: 3.20.3+dfsg0-1

Hello,

on config, some Python scripts in hplip-data spit out these warnings:

/usr/share/hplip/base/utils.py:2060: SyntaxWarning: "is" with a literal.
Did you mean "=="?
  if weburl is "" or weburl is None:
/usr/share/hplip/check-plugin.py:116: SyntaxWarning: "is" with a
literal. Did you mean "=="?
  if log_level is 'debug':
/usr/share/hplip/check.py:685: SyntaxWarning: "is not" with a literal.
Did you mean "!="?
  if 'getfacl' not in g and '' is not g and 'file' not in g:
/usr/share/hplip/installer/core_install.py:2037: SyntaxWarning: "is"
with a literal. Did you mean "=="?
  if home_dir is "":
/usr/share/hplip/ui5/devmgr_ext.py:15: SyntaxWarning: "is not" with a
literal. Did you mean "!="?
  if self.latest_available_version is not "":
/usr/share/hplip/ui5/devmgr_ext.py:37: SyntaxWarning: "is not" with a
literal. Did you mean "!="?
  if self.latest_available_version is not "":

Regards,
Gabriele Stilli

Bug#954893: aptitude: messages from AppStream garble the ncurses interface

[Gabriele Stilli]

Package: aptitude
Version: 0.8.12-3

Hello,

I use aptitude with the ncurses interface. Every time I do an update
(press "u" in the program), the following message from AppStream pops up
at the end:

"The AppStream system cache was updated, but some components were
ignored. Refer to the verbose log for more information."

As a result, the interface gets garbled all around. I attach a
screenshot illustrating the end result.

Cheers,
Gabriele Stilli

Bug#954074: Fn key for Bluetooth Apple Magic Keyboard - simple patch

[DVE - Gabriele Brugnoni]

Package: linux-image-4.19.0-8-amd64
Version: 4.19.98-1


Hello.

I'm using Debian Buster with kernel 4.19.0-8.

I would like to signal a very small patch that sould be applyied in
kernel 4.19 and future versions, to fix a problem with Apple magic
keyboard when connected via Bluetooth.

This keyboard works well when connected via USB, but when connected via
Bluethoot, the FN key is not recognised.

This bugs has been fixed in 2015, as reported here:

https://bugzilla.kernel.org/show_bug.cgi?id=99881#c41

but has you can see at the end of the page, the problem is still
present in new kernels 4.xx.

There is a little patch that fix the problem, the link is reported at
the end of the same page, this is the link:

https://lkml.org/lkml/2020/1/29/61


I've build the kernel 2.4.19 from source with that patch and after
installation the "fn" key of the keyboard works perfectly.


I hope this may be helpfull to fix this problem.

Thank you very mutch for your time and support.

Regards.


-- 
Gabriele Brugnoni

DVE Progettazione Elettronica
Via Solferino, 8 - 21020 Casciago (VA)
Tel (+39) 0332 229091
email: i...@developembedded.com
web:   http://www.developembedded.com



CONFIDENZIALE: Questa email ed i relativi allegati contengono 
informazioni confidenziali e riservate esclusivamente ai DESTINATARI 
specificati in indirizzo.
Se l'avete ricevuta per errore Vi chiediamo di informarci via e-mail 
o al numero +39 0332 229091 e di distruggere l'originale.
Qualunque utilizzazione, divulgazione o copia non autorizzata
di questa comunicazione è rigorosamente vietata e comporta violazione
delle disposizioni di legge sulla tutela dei dati personali
(D.Lgs.196/2003).
Grazie per la collaborazione.


CONFIDENTIAL: This  e-mail  and  any attachments are confidential and
may contain reserved information.
If you are not one of the named recipients, please notify the 
sender immediately. Moreover, you should not disclose the contents 
to any other person, nor should the information contained be used 
for any purpose or stored or copied in any form.
Thank you.

Bug#953712: src:austin: fails to migrate to testing for too long

[Gabriele]

Dear Paul

Many thanks for your email. As I have only recently started managing
packages on Debian, I am not sure if there is anything that I have to do
about this at all. If I understand correctly, the issue here is caused by
the fact that the latest sources (which are of version 1.0.0) are no longer
in sync with the version 0.7.0-1 of the Debian package. Some (automated, I
think) emails I have received after this one seems to suggest that this
issue has now been resolved.

Is my understanding correct? Or is there something that I still need to do?

Many thanks.

Best regards,
Gabriele

On Thu, 12 Mar 2020 at 11:51, Paul Gevers  wrote:

> Source: austin
> Version: 0.7.0-1
> Severity: serious
> Control: fixed -1 1.0.0-1
> Tags: sid bullseye
> 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:austin in its
> current version in unstable has been trying to migrate for 136 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 marked the version in unstable as fixing this bug, 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 bullseye, 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=austin
>
>
>

-- 


*"Egli è scritto in lingua matematica, e i caratteri son triangoli, cerchi,
ed altre figuregeometriche, senza i quali mezzi è impossibile a intenderne
umanamente parola;senza questi è un aggirarsi vanamente per un oscuro
laberinto."*

*-- *G. Galilei*, Il saggiatore.*

Bug#948304: also ship an austin-tui binary

[Gabriele]

> I hope that helps!

Yes, thanks! I will try to allocate some time to look into this.

Best,
Gab

On Tue, 14 Jan 2020 at 14:15, Antoine Beaupré  wrote:
>
> On 2020-01-13 23:10:09, Gabriele wrote:
> > Hi
> >
> > May I ask to clarify what the request is about?
>
> It's about shipping the austin-tui binary in Debian, in one form or the
> other.
>
> > Is it for a new Debian package, e.g. austin-tui, to be produced so
> > that it is easier to install the TUI? Or is it a request for providing
> > the TUI already with the installation of the existing Austin package?
>
> I don't mind either way. I guess the decision should be made based on
> the dependencies the new binary would generate. If there's extra
> undesired dependencies, I'd put it in a separate package, yes.
>
> > At the moment, installation from the Github repository is, imho, easy
> > enough. I would be a bit reluctant to create a dedicated package or
> > ship the TUI as an official application because it is more of an
> > example of how to use Austin than a properly maintained tool (although
> > I appreciate that it can be quite useful; I use it quite frequently
> > myself too).
>
> After reading the README, I didn't feel the TUI app was an example as
> much as the real thing. My thinking is that, out of the box, austin is
> not very useful in itself... You need to pipe it into *something* to
> have good results, and none of those "things" are really available in
> Debian by default. So it would be nice if this could work better with
> software in Debian, as opposed to telling people to install unreviewed
> software from the internet...
>
> > Anyway, once it is clearer to me what is being asked for with this
> > issue report I can have a look and see what I can do :).
>
> I hope that helps!
>
> a.
> --
> PHP was originally designed explicitly for non-programmers (and, reading
> between the lines, non-programs); it has not well escaped its roots.
>  - Alex Munroe, PHP: a fractal of bad design



-- 
"Egli è scritto in lingua matematica, e i caratteri son triangoli,
cerchi, ed altre figure
geometriche, senza i quali mezzi è impossibile a intenderne umanamente parola;
senza questi è un aggirarsi vanamente per un oscuro laberinto."

-- G. Galilei, Il saggiatore.

Bug#948304: also ship an austin-tui binary

[Gabriele]

Hi

May I ask to clarify what the request is about? Is it for a new Debian
package, e.g. austin-tui, to be produced so that it is easier to
install the TUI? Or is it a request for providing the TUI already with
the installation of the existing Austin package? At the moment,
installation from the Github repository is, imho, easy enough. I would
be a bit reluctant to create a dedicated package or ship the TUI as an
official application because it is more of an example of how to use
Austin than a properly maintained tool (although I appreciate that it
can be quite useful; I use it quite frequently myself too). Anyway,
once it is clearer to me what is being asked for with this issue
report I can have a look and see what I can do :).

Best,
Gab

On Mon, 6 Jan 2020 at 21:27, Antoine Beaupre  wrote:
>
> Package: austin
> Version: 1.0.0-1
> Severity: wishlist
>
> Could we get more of the goodies shipped with austin?
>
> The default output is not exactly useful, as it requires
> flamegraph.pl, which doesn't seem packaged as a standalone binary in
> Debian.
>
> (Well, technically, there's a version of flamegraph.pl available in
> libdevel-nytprof-perl, but that's kind of hard to discover, and its
> output is not as useful as the other stuff austin has.)
>
> There's also a web interface, although I'd be happy just with the tui
> interface.
>
> Thanks!
>
> -- System Information:
> Debian Release: 10.2
>   APT prefers stable-debug
>   APT policy: (500, 'stable-debug'), (500, 'stable'), (1, 'experimental'), 
> (1, 'unstable')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 4.19.0-6-amd64 (SMP w/4 CPU cores)
> Locale: LANG=fr_CA.UTF-8, LC_CTYPE=fr_CA.UTF-8 (charmap=UTF-8), 
> LANGUAGE=fr_CA.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
>
> Versions of packages austin depends on:
> ii  libc6  2.28-10
>
> austin recommends no packages.
>
> austin suggests no packages.
>
> -- debconf-show failed



-- 
"Egli è scritto in lingua matematica, e i caratteri son triangoli,
cerchi, ed altre figure
geometriche, senza i quali mezzi è impossibile a intenderne umanamente parola;
senza questi è un aggirarsi vanamente per un oscuro laberinto."

-- G. Galilei, Il saggiatore.

Bug#942738: RFS: austin/1.0.0-1 -- Frame stack sampler for CPython

[Gabriele]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "austin"

 * Package name: austin
   Version : 1.0.0-1
   Upstream Author : Gabriele N. Tornetta 
 * URL : https://github.com/P403n1x87/austin
 * License : GPL-3+
 * Vcs : https://github.com/P403n1x87/austin
   Section : devel

It builds those binary packages:

  austin - Frame stack sampler for CPython

To access further information about this package, please visit the
following URL:

  https://mentors.debian.net/package/austin

Alternatively, one can download the package with dget using this command:

  dget -x 
https://mentors.debian.net/debian/pool/main/a/austin/austin_1.0.0-1.dsc

Changes since the last upload:

   * Added support for multi-process Python applications
   * Added support for Python 3.8
   * Fixed support for WSL

Regards,

--
  Gabriele N. Tornetta

Bug#940095: debianutils: triggers error in update-mime at config time

[Gabriele Stilli]

Package: debianutils
Version: 4.9

Hi,

when installing debianutils it triggers an error at config time:

Use of uninitialized value $ARGV[0] in string ne at
/usr/sbin/update-mime line 43.

Here's the complete log of an install run (it's a reinstall, but the
message appeared also when installing over the previous version, 4.8.6.3):

# LC_ALL=C apt install --reinstall debianutils
Reading package lists... Done
Building dependency tree
Reading state information... Done
0 upgraded, 0 newly installed, 1 reinstalled, 0 to remove and 0 not
upgraded.
Need to get 0 B/101 kB of archives.
After this operation, 0 B of additional disk space will be used.
(Reading database ... 33 files and directories currently installed.)
Preparing to unpack .../debianutils_4.9_amd64.deb ...
Unpacking debianutils (4.9) over (4.9) ...
Setting up debianutils (4.9) ...
Use of uninitialized value $ARGV[0] in string ne at
/usr/sbin/update-mime line 43.
Processing triggers for man-db (2.8.7-3) ...

Best regards,
Gabriele Stilli

Bug#933599: musescore: create an upgrade path from 2 to 3

[Gabriele Stilli]

Package: musescore
Version: 3.0.3+dfsg1-1
Severity: wishlist

Hello,

shortly after the release of buster as stable, I upgraded my box from
buster to bullseye. I was kind of shocked to discover that musescore was
marked as "obsolete or locally created", i.e. not present in bullseye.
It took me some time to notice the package renaming from "musescore" to
"musescore3" and to find the right piece of changelog documenting it:

  * Rename binary packages to musescore3{,-common} for coïnstallability
(musescore{,-common} 2.x will stay around for buster’s lifetime, and
upstream says users should have both in parallel, for existing
scores)

(from 3.0.3+dfsg1-1, thus the Version: command above)

Now, I understand the reason for the change and have no problem myself
with the renaming and with installing a new package. I suspect, though,
that I wasn't the only user left in the cold and I wonder how many of
them know where to look to solve this. Could something be done, at least
to better document the change and suggest a solution?

Hopefully, at least, people will happen to read this bug and thus find
their way out :-)

Thanks for the great work!

Regards,
Gabriele Stilli

Bug#932359: debian-policy: recommends an old version of libjs-sphinxdoc, again

[Gabriele Stilli]

Package: debian-policy
Version: 4.4.0.0

Hi,

as usual (#910561, #921889), a new version of Sphinx (1.8.5-2) entered
testing and broke d-p's Recommends. Sorry for hitting the same key over
and over…

Thanks for the great work!

Regards,
Gabriele Stilli

Bug#921889: debian-policy: recommends an old version of libjs-sphinxdoc

[Gabriele Stilli]

found -1 4.3.0.2

Hi,

unfortunately the bug showed again when the latest libjs-sphinxdoc
1.8.4-1 entered buster.

(debian-policy now Recommends: libjs-sphinxdoc (< 1.8.3.0~))

Not sure we want to undergo all this at every sphinx version bump :-)

Regards
Gabriele Stilli

Bug#922144: amule-utils: recommends dummy transitional package ttf-dejavu-core

[Gabriele Stilli]

Package: amule-utils
Version: 1:2.3.2-4+b1

Hi,

amule-utils recommends dummy transitional package ttf-dejavu-core.
It should be changed to fonts-dejavu-core.

Regards,
Gabriele Stilli

Bug#922143: mate-applets: depends on transitional package gir1.2-mate-panel

[Gabriele Stilli]

Package: mate-applets
Version: 1.20.3-1

Hello,

mate-applets depends on transitional package gir1.2-mate-panel. It
probably should depend on gir1.2-matepanelapplet-4.0.

Regards,
Gabriele Stilli

Bug#921889: debian-policy: recommends an old version of libjs-sphinxdoc

[Gabriele Stilli]

Package: debian-policy
Version: 4.3.0.1

Hello,

debian-policy recommends libjs-sphinxdoc (<< 1.7.9.0~) while version
1.8.3-2 has just entered buster. Upgrading libjs-sphinxdoc would
therefore break the Recommends.

Regards,
Gabriele Stilli

Bug#921472: libqt5qml5: recommends dummy transitional package libgl1-mesa-glx

[Gabriele Stilli]

Package: libqt5qml5
Version: 5.11.3-2

Hi, libqt5qml5 recommends dummy transitional package libgl1-mesa-glx.
This should be updated to recommend current packages.

Regards,
Gabriele Stilli

Bug#921469: enigma: depends on dummy transitional packages ttf-dejavu-{core,extra}

[Gabriele Stilli]

Package: enigma
Version: 1.20-dfsg.1-2.1

Hi,

enigma depends on dummy transitional packages ttf-dejavu-{core,extra}.
Those should be changed to fonts-dejavu-{core,extra}.

Regards,
Gabriele Stilli

Bug#921226: RFS: austin/0.6.1~beta-1 [ITP]

[Gabriele]

Hi

Sorry for not including the bug address in the CC. I have simplified
the debian/rules file
(https://github.com/P403n1x87/austin/commit/655c3beb09199bb9dbe6c9dbdb8395c25e9213c9)
and verified with gbp buildpackage. I have excluded the custom
Makefile from the sources and seems fine to me now.

Please let me know if you want me to re-upload the package with the
latest changes.

Regarding python2, the package doesn't include any python2 code. Even
the python project inside austin/ is compatible with python3. However,
the main C application shipped with the package (which is just the
single binary src/austin) supports both python2 (2.3 - 2.7) and
python3 (3.3 - 3.7).

Thanks,
Gabriele

On Sun, 3 Feb 2019 at 23:31, Adam Borowski  wrote:
>
> On Sun, Feb 03, 2019 at 10:39:09PM +, Gabriele wrote:
> > Hey
> >
> > Many thanks for getting back to me!
>
> Could you please re-add 921...@bugs.debian.org to CC?  (I'm 99.9% sure
> you'll be ok with that but the rule is to never make anything public without
> an explicit permission).  Any such package reviews are supposed to be done
> in public, for a number of reasons:
>  * there's a record of the review
>  * anyone else can chime in
>  * anyone else can continue the review -- I might need to pass if there'll
>be any complex python-specific questions
>  * others can learn
>
> > I have sent the public key to the keyserver as you have suggested.
>
> Great, thanks!  It'll probably take a bit of time for it to propagate.
>
> > Regarding the dependencies you have mentioned, they shouldn't really
> > be such. The tarball includes snapcraft sources for creating artifacts
> > for the snap store (think of this as the analogue of the debian/
> > folder but for another type of repository, https://snapcraft.io/).
> > This tool is then not required for the application to run and to even
> > build.
>
> Yeah, but the build system still calls it.  After your changes at least
> repacking the sources succeeds, but the actual build still fails:
>
>
> Command: dpkg-buildpackage -us -uc -b -rfakeroot
> dpkg-buildpackage: info: source package austin
> dpkg-buildpackage: info: source version 0.6.1~beta-1
> dpkg-buildpackage: info: source distribution unstable
> dpkg-buildpackage: info: source changed by Gabriele N. Tornetta 
> 
>  dpkg-source --before-build .
> dpkg-buildpackage: info: host architecture amd64
>  fakeroot debian/rules clean
> dh clean
>dh_auto_clean
> make -j6 clean
> make[1]: Entering directory '/<>'
> snapcraft clean
> make[1]: snapcraft: Command not found
> make[1]: *** [Makefile:23: clean] Error 127
> make[1]: Leaving directory '/<>'
> dh_auto_clean: make -j6 clean returned exit code 2
>
> > In fact, all that austin requires is a C compiler. Python is
> > only a test dependency as it is invoked during tests. The Makefile
> > included in the tarball is not intended for autogeneration, but just
> > to simplify the testing during development. The package should be
> > built with the standard autoreconf process instead, as I think is
> > currently happening.
>
> Seems like this is the problem:
>
> dpkg-buildpackage: info: source package austin
> dpkg-buildpackage: info: source version 0.6.1~beta-1
> dpkg-buildpackage: info: source distribution unstable
> dpkg-buildpackage: info: source changed by Gabriele N. Tornetta 
> 
>  dpkg-source --before-build .
>  fakeroot debian/rules clean
> dh clean
>dh_clean
>  dpkg-source -b .
> dpkg-source: info: using source format '3.0 (quilt)'
> dpkg-source: info: building austin using existing 
> ./austin_0.6.1~beta.orig.tar.gz
> dpkg-source: info: using patch list from debian/patches/series
> dpkg-source: warning: ignoring deletion of file Makefile, use 
> --include-removal to override
> dpkg-source: warning: ignoring deletion of file src/Makefile.in, use 
> --include-removal to override
> dpkg-source: warning: ignoring deletion of file src/austin, use 
> --include-removal to override
> dpkg-source: warning: ignoring deletion of file test/test_process_iter.py, 
> use --include-removal to override
> dpkg-source: info: building austin in austin_0.6.1~beta-1.debian.tar.xz
> dpkg-source: info: building austin in austin_0.6.1~beta-1.dsc
>  dpkg-genbuildinfo --build=source
>  dpkg-genchanges --build=source >../austin_0.6.1~beta-1_source.changes
> dpkg-genchanges: info: including full source code in upload
>  dpkg-source --after-build .
> dpkg-buildpackage: info: full upload (original source is included)
>
> The patch system ignores deletions unless specifically told so (there are
> usually nicer ways to get this effect), which apparently results in some old
> version of the Makefile bein

Bug#921181: pescetti: recommends unavailable package dds

[Gabriele Stilli]

Il 04/02/19 01:12, Thorsten Alteholz ha scritto:

> according to the tracker [1] the package is still available in 
> version 2.9.0-6. Why do you think it is gone?

The binary package "dds", on which pescetti depends, has gone since
version 2.9.0-1; the source package "dds" only features libdds{0,-dev}.

Regards,
Gabriele

Bug#921226: RFS: austin/0.6.1~beta-1 [ITP]

[Gabriele]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "austin"

* Package name: austin
  Version : 0.6.1~beta-1
  Upstream Author : Gabriele N. Tornetta
* URL : https://github.com/P403n1x87/austin
* License : GPLv3
  Section : devel

It builds those binary packages:

  austin - a frame stack sampler for CPython

To access further information about this package, please visit the
following URL:

https://mentors.debian.net/package/austin


Alternatively, one can download the package with dget using this command:

  dget -x 
https://mentors.debian.net/debian/pool/main/a/austin/austin_0.6.1~beta-1.dsc

More information about austin can be obtained from https://www.example.com.

Changes since the last upload:

austin (0.6.1~beta-1) unstable; urgency=medium

  * Initial release (Closes: #918518)

 -- Gabriele N. Tornetta   Fri, 04 Jan 2019
23:13:40 +


Regards,
 Gabriele N. Tornetta

Bug#921204: RFS: austin/0.6.1-beta-1 [ITP]

[Gabriele]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "austin"

* Package name: austin
  Version : 0.6.1-beta-1
  Upstream Author : Gabriele N. Tornetta 
* URL : https://github.com/P403n1x87/austin
* License : GPLv3
  Section : devel

It builds those binary packages:

  austin - a frame stack sampler for CPython

To access further information about this package, please visit the
following URL:

https://mentors.debian.net/package/austin


Alternatively, one can download the package with dget using this command:

  dget -x 
https://mentors.debian.net/debian/pool/main/a/austin/austin_0.6.1-beta-1.dsc

More information about austin can be obtained from https://www.example.com.

Changes since the last upload:

austin (0.6.1-beta-1) unstable; urgency=medium

  * Initial release (Closes: #918518)

 -- Gabriele N. Tornetta   Fri, 04 Jan 2019
23:13:40 +


  Regards,
   Gabriele N. Tornetta

Bug#921181: pescetti: recommends unavailable package dds

[Gabriele Stilli]

Package: pescetti
Version: 0.5-3

Hi,

pescetti recommends dds which isn't available anymore, at least in
buster and sid.

Regards,
Gabriele Stilli

Bug#920960: libreoffice: recommends obsolete metapackage fonts-noto-hinted

[Gabriele Stilli]

Package: libreoffice
Version: 1:6.1.5~rc1-2
Severity: minor

Hi,

libreoffice recommends fonts-noto-hinted which, by its own description,
is an obsolete metapackage depending on fonts-noto-{,ui-}core.

It's probably a good idea to depend on current packages.

Kind regards,
Gabriele Stilli

Bug#920867: python3-lib2to3: descriptions still mention Python 3.6

[Gabriele Stilli]

Package: python3-lib2to3
Version: 3.7.2-3

Hi,

both long and short descriptions mention Python 3.6 even though lib2to3
has reached 3.7.2; maybe this is worth updating (perhaps leaving just
"3" and disregarding the subversion?).

Regards,
Gabriele Stilli

Bug#918182: dpkg: warning: unable to delete old directory '/usr/lib/python3.6/

[Gabriele Stilli]

Hi,

maybe there's yet something left to trim. Here's what I got when
updgrading to python3-lib2to3 (3.7.2-3):

Estrazione di python3-lib2to3 (3.7.2-3) su (3.7.1-1)...
dpkg: attenzione: impossibile eliminare la vecchia directory
"/usr/lib/python3.6/lib2to3/pgen2": Directory non vuota
dpkg: attenzione: impossibile eliminare la vecchia directory
"/usr/lib/python3.6/lib2to3/fixes": Directory non vuota
dpkg: attenzione: impossibile eliminare la vecchia directory
"/usr/lib/python3.6/lib2to3": Directory non vuota
Preparativi per estrarre .../13-python3-distutils_3.7.2-3_all.deb...
Estrazione di python3-distutils (3.7.2-3) su (3.7.1-1)...
dpkg: attenzione: impossibile eliminare la vecchia directory
"/usr/lib/python3.6/distutils/command": Directory non vuota
dpkg: attenzione: impossibile eliminare la vecchia directory
"/usr/lib/python3.6/distutils": Directory non vuota
Preparativi per estrarre .../14-python3-tk_3.7.2-3_amd64.deb...
Estrazione di python3-tk:amd64 (3.7.2-3) su (3.7.1-1)...
dpkg: attenzione: impossibile eliminare la vecchia directory
"/usr/lib/python3.6/tkinter": Directory non vuota
dpkg: attenzione: impossibile eliminare la vecchia directory
"/usr/lib/python3.6": Directory non vuota

(Sorry for the Italian; the message mean "warning: unable to delete old
directory […]: Directory not empty")

After upgrading, here's the content of /usr/lib/python3.6:

$ ls -aR /usr/lib/python3.6
/usr/lib/python3.6:
.  ..  tkinter

/usr/lib/python3.6/tkinter:
.  ..  __pycache__

/usr/lib/python3.6/tkinter/__pycache__:
.font.cpython-36.pyc
..   __init__.cpython-36.pyc
colorchooser.cpython-36.pyc  __main__.cpython-36.pyc
commondialog.cpython-36.pyc  messagebox.cpython-36.pyc
constants.cpython-36.pyc scrolledtext.cpython-36.pyc
dialog.cpython-36.pycsimpledialog.cpython-36.pyc
dnd.cpython-36.pyc   tix.cpython-36.pyc
filedialog.cpython-36.pycttk.cpython-36.pyc

Regards,
Gabriele Stilli

Bug#918518: ITP: austin -- a frame stack sampler for CPython

[Gabriele]

Package: wnpp
Owner: Gabriele N. Tornetta 
Severity: wishlist

* Package name: austin
  Version : 0.6.1
  Upstream Author : Gabriele N. Tornetta 
* URL : https://github.com/P403n1x87/austin
* License : GPL
  Programming Lang: C
  Description : a frame stack sampler for CPython

Austin is a frame stack sampler for CPython, meant to be
used to create high-performance Python profilers with
minimal impact on the profiled program.
.
Austin does not require any code instrumentation and can be
used on production code at run-time with almost no overhead.
.
I'm looking for a mentor to sponsor this package. Austin is
a pure C application with no dependencies other than stdlib
and that compiles to a single tiny binary.

Bug#913477: apt-show-versions: Name "Storable::recursion_limit_hash" used only once

[Gabriele Stilli]

Package: apt-show-versions
Version: 0.22.9

Dear maintainer,

while configuring apt-show-versions 0.22.9 the following appeared:

Configuring apt-show-versions (0.22.9)...
** initializing cache. This may take a while **
Name "Storable::recursion_limit_hash" used only once: possible typo at
/usr/bin/apt-show-versions line 271.

Regards,
Gabriele :-)

Bug#913013: RM: eboard-extras-pack1 -- obsolete, conflicts with latest eboard

[Gabriele Stilli]

Package: ftp.debian.org
Severity: normal

Dear ftpmasters,

since version 1.1.3-0.1 eboard has merged with eboard-extras-pack1,
which is now useless, obsolete and in conflict with eboard. When trying
to install eboard with the extras pack package installed it bailed out
with the following:

Preparing to unpack .../eboard_1.1.3-0.1_amd64.deb ...
Unpacking eboard (1.1.3-0.1) over (1.1.1-6.1+b1) ...
dpkg: error processing archive
/var/cache/apt/archives/eboard_1.1.3-0.1_amd64.deb (--unpack):
 trying to overwrite '/usr/share/games/eboard/Alpha.png', which is also
in package eboard-extras-pack1 2-3
dpkg-deb: error: paste subprocess was killed by signal (Broken pipe)
Errors were encountered while processing:
 /var/cache/apt/archives/eboard_1.1.3-0.1_amd64.deb

Therefore it looks like eboard-extras-pack1 should be removed.

See also bug #913011.

Cheers,
Gabriele :-)

Bug#913011: eboard: add Conflicts: eboard-extras-pack1

[Gabriele Stilli]

Package: eboard
Version: 1.1.3-0.1
Severity: important

Dear Maintainer,

since version 1.1.3-0.1 eboard has merged with eboard-extras-pack1,
which is now useless, obsolete and in conflict with eboard. When trying
to install eboard with the extras pack package installed it bailed out
with the following:

Preparing to unpack .../eboard_1.1.3-0.1_amd64.deb ...
Unpacking eboard (1.1.3-0.1) over (1.1.1-6.1+b1) ...
dpkg: error processing archive
/var/cache/apt/archives/eboard_1.1.3-0.1_amd64.deb (--unpack):
 trying to overwrite '/usr/share/games/eboard/Alpha.png', which is also
in package eboard-extras-pack1 2-3
dpkg-deb: error: paste subprocess was killed by signal (Broken pipe)
Errors were encountered while processing:
 /var/cache/apt/archives/eboard_1.1.3-0.1_amd64.deb

Therefore a "Conflict: eboard-extras-pack1" line looks appropriate.

Of course purging eboard-extras-pack1 worked around the problem, and it
should be removed from Debian as well, but this is another report.

Cheers,
Gabriele :-)

Bug#911023: memory leak in the backlight control of the dell-laptop module

[Gabriele Mazzotta]

Hi,

there are a couple of commits queued for 4.19 that fix some memory
leaks: https://patchwork.kernel.org/patch/10594683/ and
https://patchwork.kernel.org/patch/10594681/. Looking at the call
trace I'd say the first patch is going to fix your issue.

They should both be included in the stable trees given the tag in
the commit.

Regards,
Gabriele

Bug#910500: libqt5quick5: Sefault in applications using QWebEngineView

[Gabriele Mazzotta]

Package: libqt5quick5
Version: 5.11.1-6
Severity: important

Hi,

I have a simple Qt application that's been segfaulting ever since
libqt5quick5 has been updated to 5.11.1-6. The crash does not happen
with 5.11.1-5, so I assume the problem is caused by the unaligned
memory access fix that's been backported.

See the following example to reproduce the problem. The crash may
happen while scrolling the page, if not as soon as page is loaded.
Not all the webpages can trigger the bug.

I can provide more info in case the example is not enough to
reproduce the problem.

Regards,
Gabriele

---
$ cat main.cpp
#include 
#include 

int main(int argc, char *argv[])
{
QApplication app(argc, argv);

QWebEngineView view;
view.setUrl(QUrl("https://www.qt.io;));
view.resize(1024, 750);
view.show();

return app.exec();
}

$ cat example.pro
TEMPLATE = app

QT += webenginewidgets

SOURCES += main.cpp

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

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

Versions of packages libqt5quick5 depends on:
ii  libc6  2.27-6
ii  libqt5core5a [qtbase-abi-5-11-0]   5.11.1+dfsg-9
ii  libqt5gui5 5.11.1+dfsg-9
ii  libqt5network5 5.11.1+dfsg-9
ii  libqt5qml5 [qtdeclarative-abi-5-11-0]  5.11.1-6
ii  libstdc++6 8.2.0-7

libqt5quick5 recommends no packages.

libqt5quick5 suggests no packages.

-- no debconf information

Bug#908653: closed by Reinhard Tartler (Re: dokuwiki: CVE-2018-18123 patch leads to Call to undefined PostInput::filter())

[Gabriele Monfardini]

Hi Reinhard,

the error happens in package 0.0.20140505.a+dfsg-4+deb8u1, Debian Jessie.
I'm aware that in unstable there is a newer package without this issue, but
unfortunately I cannot upgrade right now.
Is it possible to build a fixed package for jessie?

Thank you,

Gabriele


> CVE-2018-18123-2f65d86.patch, introduced in security version
> 0.0.20140505.a+dfsg-4+deb8u1 changed two lines in /lib/exe/ajax.php.
> > Now ajax calls fail with PHP Fatal error:  Call to undefined method
> PostInput::filter() in /usr/share/dokuwiki/lib/exe/ajax.php on line 18
> >
>
> In the most recent upload to unstable, which upgrades the debian package
> to a more recent version of dokuwiki this patch is no longer necessary and
> included upstream. I'm unable to reproduce this issue, so I'm closing this
> bug with this email. Please follow-up you feel something is missing.
>
> Best,
> -rt
>
>
> -- Forwarded message --
> From: Gabriele Monfardini 
> To: Debian Bug Tracking System 
> Cc:
> Bcc:
> Date: Wed, 12 Sep 2018 10:39:15 +0200
> Subject: dokuwiki: CVE-2018-18123 patch leads to Call to undefined
> PostInput::filter()
> Package: dokuwiki
> Version: 0.0.20140505.a+dfsg-4+deb8u1
> Severity: normal
>
> Dear Maintainer,
>
> CVE-2018-18123-2f65d86.patch, introduced in security version
> 0.0.20140505.a+dfsg-4+deb8u1 changed two lines in /lib/exe/ajax.php.
> Now ajax calls fail with PHP Fatal error:  Call to undefined method
> PostInput::filter() in /usr/share/dokuwiki/lib/exe/ajax.php on line 18
>
> -- System Information:
> Debian Release: 8.11
>   APT prefers oldstable
>   APT policy: (500, 'oldstable')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 3.16.0-6-amd64 (SMP w/4 CPU cores)
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
>
> Versions of packages dokuwiki depends on:
> ii  debconf [debconf-2.0]  1.5.56+deb8u1
> ii  javascript-common  11
> ii  libjs-jquery   1.7.2+dfsg-3.2
> ii  libjs-jquery-cookie10-1
> ii  libjs-jquery-ui1.10.1+dfsg-1
> ii  libphp-simplepie   1.2.1-3
> ii  php-geshi  1.0.8.11-2
> ii  php-seclib 0.3.8-1
> ii  php5   5.6.37+dfsg-0+deb8u1
> ii  ucf3.0030
>
> Versions of packages dokuwiki recommends:
> ii  imagemagick8:6.8.9.9-5+deb8u13
> ii  php5-cli   5.6.37+dfsg-0+deb8u1
> ii  php5-gd5.6.37+dfsg-0+deb8u1
> ii  php5-ldap  5.6.37+dfsg-0+deb8u1
> ii  php5-mysqlnd [php5-mysql]  5.6.37+dfsg-0+deb8u1
> ii  php5-pgsql 5.6.37+dfsg-0+deb8u1
> ii  wget   1.16-1+deb8u5
>
> Versions of packages dokuwiki suggests:
> pn  libapache2-mod-xsendfile  
>
> -- Configuration Files:
> /etc/dokuwiki/mime.conf changed [not included]
> /etc/dokuwiki/plugins.local.php changed [not included]
>
> -- debconf information excluded
>

Bug#908653: dokuwiki: CVE-2018-18123 patch leads to Call to undefined PostInput::filter()

[Gabriele Monfardini]

Package: dokuwiki
Version: 0.0.20140505.a+dfsg-4+deb8u1
Severity: normal

Dear Maintainer,

CVE-2018-18123-2f65d86.patch, introduced in security version 
0.0.20140505.a+dfsg-4+deb8u1 changed two lines in /lib/exe/ajax.php. 
Now ajax calls fail with PHP Fatal error:  Call to undefined method 
PostInput::filter() in /usr/share/dokuwiki/lib/exe/ajax.php on line 18

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

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

Versions of packages dokuwiki depends on:
ii  debconf [debconf-2.0]  1.5.56+deb8u1
ii  javascript-common  11
ii  libjs-jquery   1.7.2+dfsg-3.2
ii  libjs-jquery-cookie10-1
ii  libjs-jquery-ui1.10.1+dfsg-1
ii  libphp-simplepie   1.2.1-3
ii  php-geshi  1.0.8.11-2
ii  php-seclib 0.3.8-1
ii  php5   5.6.37+dfsg-0+deb8u1
ii  ucf3.0030

Versions of packages dokuwiki recommends:
ii  imagemagick8:6.8.9.9-5+deb8u13
ii  php5-cli   5.6.37+dfsg-0+deb8u1
ii  php5-gd5.6.37+dfsg-0+deb8u1
ii  php5-ldap  5.6.37+dfsg-0+deb8u1
ii  php5-mysqlnd [php5-mysql]  5.6.37+dfsg-0+deb8u1
ii  php5-pgsql 5.6.37+dfsg-0+deb8u1
ii  wget   1.16-1+deb8u5

Versions of packages dokuwiki suggests:
pn  libapache2-mod-xsendfile  

-- Configuration Files:
/etc/dokuwiki/mime.conf changed [not included]
/etc/dokuwiki/plugins.local.php changed [not included]

-- debconf information excluded

Bug#883973: fonts-wine: Please move the ttf/otf fonts to /usr/share/fonts

[Gabriele Stilli]

Package: fonts-wine
Followup-For: Bug #883973

Hi,

I can confirm the degradation of some web pages after the latest
fonts-wine update.

Doing a quick search I found, among others, the issues below, which seem
related to the problem:
https://bugs.winehq.org/show_bug.cgi?id=26037
https://jira.reactos.org/browse/CORE-5338

Thanks!

Cheers,
Gabriele :-)

Bug#901931: the soundsystem still breaks after todays timidity and timidity-daemon upgrade to 2.14.0-8

[Gabriele Stilli]

Hi,

I think the problem is related to the fact that, on a Debian system
running pulseaudio, timidity-daemon still tries to add the "timidity"
user to the "audio" group. It shouldn't. On such systems (at least those
where the pulseaudio daemon is not being run system-wide) the "audio"
group should be empty. This is well explained here:
https://www.freedesktop.org/wiki/Software/PulseAudio/Documentation/User/PerfectSetup/
section «Should users be in the "audio" group?».

Emptying the "audio" group and rebooting the box fixed the issue.

(To whoever might read: only do this after taking precautions)

Hope this helps. Thanks for your work!

Cheers,
Gabriele :-)

Bug#861746: linux-image-4.9.0-2-amd64: Infinity `soft lockup` at kernel 4.9.0-1+ on HP ProLiant DL360G5

[Gabriele Monfardini]

Confirmed the same issue on kernel 4.9.0-4 (4.9.51-1) on a HP Proliant G4.
Regards,

Gabriele Monfardini

Bug#771563: gnome-control-center: bluetooth devices not listed

[Gabriele Brosulo]

Same problem here, on debian Jessie fully upgraded. Sometime it works,
but the most of the time it doesn't.
I've also installed firmware-atheros_0.43_all.deb, but it doesn't solve
the issue.

-- 
Gabriele Brosulo





signature.asc
Description: This is a digitally signed message part

Bug#861814: [Pkg-nagios-devel] Bug#861814: nagios-plugins-contrib: check_email_delivery fails using SMTP TLS

[Gabriele]

Hy,

> did you try the package from jessie/stretch? For making life easier you
> can fetch them from squeeze-backports and squeeze-backports-sloppy.

Yes from Jessie, same problem.
If you need it, I can reportbug from Jessie too.

Thank you,
GV

Bug#861814: nagios-plugins-contrib: check_email_delivery fails using SMTP TLS

[Gabriele Vivinetto]

Package: nagios-plugins-contrib
Version: 4.20120702
Severity: important

Using check_email_delivery with  SMTP TLS fails with error

EMAIL DELIVERY CRITICAL - smtp failed: SMTP SEND CRITICAL - invalid SSL_version 
specified at /usr/share/perl5/IO/Socket/SSL.pm line 332 

Command used:

/usr/lib/nagios/plugins/check_email_delivery \
--smtp-server smtp.gmail.com \
--smtp-username nag...@gmail.com \
--smtp-password 12345678 \
--smtptls \
--imap-server imap.example.com \
--username nag...@example.com \
--password 12345678 \
--imapssl \
--imap-port 993 \
--mailto nag...@example.com \
--mailfrom nag...@gmail.com

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

Kernel: Linux 3.2.0-4-amd64 (SMP w/1 CPU core)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash

nagios-plugins-contrib depends on no packages.

Versions of packages nagios-plugins-contrib recommends:
ii  freeipmi-tools1.1.5-3
ii  libc6 2.13-38+deb7u11
ii  libdate-manip-perl6.32-1
ii  libio-socket-ssl-perl 1.76-2
ii  libipc-run-perl   0.92-1
ii  liblocale-gettext-perl1.05-7+b1
ii  liblwp-useragent-determined-perl  1.06-1
ii  libmail-imapclient-perl   3.31-2
ii  libmemcached101.0.8-1
ii  libnagios-plugin-perl 0.36-1
ii  libnet-dns-perl   0.66-2+b2
ii  libnet-smtp-tls-perl  0.12-1
ii  libnet-snmp-perl  6.0.1-2
ii  libnet-ssleay-perl1.48-1+b1
ii  libreadonly-perl  1.03-4
ii  libyaml-syck-perl 1.20-1
ii  lsof  4.86+dfsg-1
ii  openssl   1.0.1t-1+deb7u2
ii  python2.7.3-4+deb7u1
ii  ruby  1:1.9.3
ii  ruby1.9.1 [ruby-interpreter]  1.9.3.194-8.1+deb7u5
ii  snmp  5.4.3~dfsg-2.8+deb7u1

Versions of packages nagios-plugins-contrib suggests:
pn  backuppc  
pn  cciss-vol-status  
pn  expect
pn  mpt-status
ii  perl-doc  5.14.2-21+deb7u4

-- Configuration Files:
/etc/nagios-plugins/check_rbl.ini changed [not included]

-- no debconf information

Bug#827039: recommends: lmms-vst-server:i386 but conflicts: lmms:i386

[Gabriele Stilli]

Package: lmms
Version: 1.1.3-3
Severity: normal

Dear Maintainer,

when trying to update lmms from 1.1.3-1+b2 to 1.1.3-3 I get the error
message that lmms conflicts with: lmms:i386. This is because lmms
recommends: lmms-vst-server:i386 which in turn recommends lmms:i386,
but lmms actually conflicts with lmms:i386. I solved deselecting
lmms-vst-server:i386 but this requires an intervention by hand.

Cheers,
Gabriele Stilli

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

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

Versions of packages lmms depends on:
ii  calf-ladspa   1.1.3-3
ii  libasound21.1.0-1
ii  libc6 2.22-11
ii  libfftw3-single3  3.3.4-2+b1
ii  libfltk1.31.3.3-8+b1
ii  libfluidsynth11.1.6-3
ii  libgcc1   1:6.1.1-4
ii  libice6   2:1.0.9-1+b1
ii  libjack-jackd2-0 [libjack-0.116]  1.9.10+20150825git1ed50c92~dfsg-1
ii  libogg0   1.3.2-1
ii  libportaudio2 19+svn20140130-1
ii  libpulse0 8.0-2+b2
ii  libqt4-xml4:4.8.7+dfsg-8
ii  libqtcore44:4.8.7+dfsg-8
ii  libqtgui4 4:4.8.7+dfsg-8
ii  libsamplerate00.1.8-8
ii  libsdl1.2debian   1.2.15+dfsg1-4
ii  libsm62:1.2.2-1+b1
ii  libsndfile1   1.0.25-10
ii  libstdc++66.1.1-4
ii  libstk-4.5.0  4.5.2+dfsg-2
ii  libvorbis0a   1.3.5-3
ii  libvorbisenc2 1.3.5-3
ii  libvorbisfile31.3.5-3
ii  lmms-common   1.1.3-3
ii  stk   4.5.2+dfsg-2
ii  zlib1g1:1.2.8.dfsg-2+b1

Versions of packages lmms recommends:
ii  caps  0.9.24-1+b1
pn  lmms-vst-server:i386  
ii  tap-plugins   0.7.3-1

Versions of packages lmms suggests:
ii  calf-ladspa [ladspa-plugin]  1.1.3-3
ii  caps [ladspa-plugin] 0.9.24-1+b1
pn  fil-plugins  
ii  fluid-soundfont-gm   3.1-5
ii  freepats 20060219-1
pn  mcp-plugins  
pn  omins
ii  swh-plugins [ladspa-plugin]  0.4.15+1-8
ii  tap-plugins [ladspa-plugin]  0.7.3-1

-- no debconf information

Bug#820981: samba: Credentials chain check failed

[Gabriele Vivinetto]

Package: samba
Version: 2:3.6.6-6+deb7u9
Followup-For: Bug #820981

Dear Maintainer,
even with winbind installed, running samba as a PDC does not let users logon
in the domain.
Trying to logon with a doman user from a workstation previously joned to the
domain gives the error:
 "The trust relationship between this workstation and the primary domain failed"

Trying to rejoin the domain does not solve this.

Winbind was already installed and running.

I had to downgrade to samba using:
 apt-get install \
 smbclient=2:3.6.6-6+deb7u7 \
 libwbclient0=2:3.6.6-6+deb7u7 \
 samba-common=2:3.6.6-6+deb7u7 \
 samba=2:3.6.6-6+deb7u7 \
 samba-common-bin=2:3.6.6-6+deb7u7 \
 winbind=2:3.6.6-6+deb7u7 \
 libnss-winbind=2:3.6.6-6+deb7u7

After doing this, every user ca logon succesfully to the domain from every
workstation without any kind of changes locally.

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

Kernel: Linux 3.2.0-4-amd64 (SMP w/2 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) (ignored: LC_ALL set to C)
Shell: /bin/sh linked to /bin/dash

Versions of packages samba depends on:
ii  adduser3.113+nmu3
ii  debconf [debconf-2.0]  1.5.49
ii  dpkg   1.16.17
ii  libacl12.2.51-8
ii  libattr1   1:2.4.46-8
ii  libc6  2.13-38+deb7u10
ii  libcap21:2.22-1.2
ii  libcomerr2 1.42.5-1.1+deb7u1
ii  libcups2   1.5.3-5+deb7u6
ii  libgssapi-krb5-2   1.10.1+dfsg-5+deb7u7
ii  libk5crypto3   1.10.1+dfsg-5+deb7u7
ii  libkrb5-3  1.10.1+dfsg-5+deb7u7
ii  libldap-2.4-2  2.4.31-2+deb7u1
ii  libpam-modules 1.1.3-7.1
ii  libpam-runtime 1.1.3-7.1
ii  libpam0g   1.1.3-7.1
ii  libpopt0   1.16-7
ii  libtalloc2 2.0.7+git20120207-1
ii  libtdb11.2.10-2
ii  libwbclient0   2:3.6.6-6+deb7u9
ii  lsb-base   4.1+Debian8+deb7u1
ii  procps 1:3.3.3-3
ii  samba-common   2:3.6.6-6+deb7u9
ii  update-inetd   4.43
ii  zlib1g 1:1.2.7.dfsg-13

Versions of packages samba recommends:
ii  logrotate  3.8.1-4
ii  tdb-tools  1.2.10-2

Versions of packages samba suggests:
pn  ctdb  
pn  ldb-tools 
pn  openbsd-inetd | inet-superserver  
pn  smbldap-tools 

-- debconf information:
  samba/run_mode: daemons
  samba/generate_smbpasswd: true
  samba-common/title:

Bug#820973: evolution-mapi: Evolution-mapi fail to connect after samba security upgrade to 4.2.10+dfsg-0+deb8u1

[Gabriele Messineo]

Package: evolution-mapi
Version: 3.12.7-1
Severity: important

Dear Maintainer,

after having performed the usual system update on stable and having applied the
following security fixes:

Start-Date: 2016-04-14  08:59:08
Commandline: apt-get upgrade
Upgrade: python-samba:amd64 (4.1.17+dfsg-2+deb8u2, 4.2.10+dfsg-0+deb8u1),
winbind:amd64 (4.1.17+dfsg-2+deb8u2, 4.2.10+dfsg-0+deb8u1), tdb-tools:amd64
(1.3.1-1, 1.3.6-0+deb8u1), samba:amd64 (4.1.17+dfsg-2+deb8u2,
4.2.10+dfsg-0+deb8u1), python-tdb:amd64 (1.3.1-1, 1.3.6-0+deb8u1),
libtevent0:amd64 (0.9.21-1, 0.9.25-0+deb8u1), samba-dsdb-modules:amd64
(4.1.17+dfsg-2+deb8u2, 4.2.10+dfsg-0+deb8u1), samba-common-bin:amd64
(4.1.17+dfsg-2+deb8u2, 4.2.10+dfsg-0+deb8u1), libldb1:amd64 (1.1.17-2+deb8u1,
1.1.20-0+deb8u1), libtdb1:amd64 (1.3.1-1, 1.3.6-0+deb8u1), samba-libs:amd64
(4.1.17+dfsg-2+deb8u2, 4.2.10+dfsg-0+deb8u1), libtalloc2:amd64 (2.1.1-2,
2.1.2-0+deb8u1), python-talloc:amd64 (2.1.1-2, 2.1.2-0+deb8u1),
libwbclient0:amd64 (4.1.17+dfsg-2+deb8u2, 4.2.10+dfsg-0+deb8u1), samba-vfs-
modules:amd64 (4.1.17+dfsg-2+deb8u2, 4.2.10+dfsg-0+deb8u1), python-ldb:amd64
(1.1.17-2+deb8u1, 1.1.20-0+deb8u1), samba-common:amd64 (4.1.17+dfsg-2+deb8u2,
4.2.10+dfsg-0+deb8u1), libsmbclient:amd64 (4.1.17+dfsg-2+deb8u2,
4.2.10+dfsg-0+deb8u1)
End-Date: 2016-04-14  08:59:45


Evolution stopped connecting to the Exchange server.

I tried to manually reauthenticate and to disable secure connection, but
nothing worked.

I tried performing a debug using:

LIBMAPI_DEBUG=15 evolution &>log_evolution.txt

and got:


(evolution:10441): Gtk-WARNING **: Failed to register client:
GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name
org.gnome.SessionManager was not provided by any .service files
INFO: Current debug levels:
  all: 15
  tdb: 15
  printdrivers: 15
  lanman: 15
  smb: 15
  rpc_parse: 15
  rpc_srv: 15
  rpc_cli: 15
  passdb: 15
  sam: 15
  auth: 15
  winbind: 15
  vfs: 15
  idmap: 15
  quota: 15
  acls: 15
  locking: 15
  msdfs: 15
  dmapi: 15
  registry: 15
  scavenger: 15
  dns: 15
  ldb: 15
INFO: Current debug levels:
  all: 15
  tdb: 15
  printdrivers: 15
  lanman: 15
  smb: 15
  rpc_parse: 15
  rpc_srv: 15
  rpc_cli: 15
  passdb: 15
  sam: 15
  auth: 15
  winbind: 15
  vfs: 15
  idmap: 15
  quota: 15
  acls: 15
  locking: 15
  msdfs: 15
  dmapi: 15
  registry: 15
  scavenger: 15
  dns: 15
  ldb: 15
Failed to parse dcerpc binding 'ncacn_ip_tcp:192.168.33.1[print,seal,]'
Failed to connect to remote server: ncacn_ip_tcp:192.168.33.1[print,seal,]
NT_STATUS_INVALID_PARAMETER_MIX
Failed to parse dcerpc binding 'ncacn_ip_tcp:192.168.33.1[print,seal,]'
Failed to connect to remote server: ncacn_ip_tcp:192.168.33.1[print,seal,]
NT_STATUS_INVALID_PARAMETER_MIX
Failed to parse dcerpc binding 'ncacn_ip_tcp:192.168.33.1[print,seal,]'
Failed to connect to remote server: ncacn_ip_tcp:192.168.33.1[print,seal,]
NT_STATUS_INVALID_PARAMETER_MIX
Failed to parse dcerpc binding 'ncacn_ip_tcp:192.168.33.1[print,seal,]'
Failed to connect to remote server: ncacn_ip_tcp:192.168.33.1[print,seal,]
NT_STATUS_INVALID_PARAMETER_MIX

(evolution:10441): GLib-GIO-CRITICAL **: g_network_address_set_addresses:
assertion 'addresses != NULL && addr->priv->sockaddrs == NULL' failed

(evolution:10441): GLib-GIO-CRITICAL **: g_network_address_set_addresses:
assertion 'addresses != NULL && addr->priv->sockaddrs == NULL' failed

(evolution:10441): GLib-GIO-CRITICAL **: g_network_address_set_addresses:
assertion 'addresses != NULL && addr->priv->sockaddrs == NULL' failed

(evolution:10441): GLib-GIO-CRITICAL **: g_network_address_set_addresses:
assertion 'addresses != NULL && addr->priv->sockaddrs == NULL' failed

(evolution:10441): GLib-GIO-CRITICAL **: g_network_address_set_addresses:
assertion 'addresses != NULL && addr->priv->sockaddrs == NULL' failed

(evolution:10441): GLib-GIO-CRITICAL **: g_network_address_set_addresses:
assertion 'addresses != NULL && addr->priv->sockaddrs == NULL' failed
INFO: Current debug levels:
  all: 15
  tdb: 15
  printdrivers: 15
  lanman: 15
  smb: 15
  rpc_parse: 15
  rpc_srv: 15
  rpc_cli: 15
  passdb: 15
  sam: 15
  auth: 15
  winbind: 15
  vfs: 15
  idmap: 15
  quota: 15
  acls: 15
  locking: 15
  msdfs: 15
  dmapi: 15
  registry: 15
  scavenger: 15
  dns: 15
  ldb: 15
Failed to parse dcerpc binding 'ncacn_ip_tcp:192.168.33.1[print,seal,]'
Failed to connect to remote server: ncacn_ip_tcp:192.168.33.1[print,seal,]
NT_STATUS_INVALID_PARAMETER_MIX
Failed to parse dcerpc binding 'ncacn_ip_tcp:192.168.33.1[print,seal,]'
Failed to connect to remote server: ncacn_ip_tcp:192.168.33.1[print,seal,]
NT_STATUS_INVALID_PARAMETER_MIX
INFO: Current debug levels:
  all: 15
  tdb: 15
  printdrivers: 15
  lanman: 15
  smb: 15
  rpc_parse: 15
  rpc_srv: 15
  rpc_cli: 15
  passdb: 15
  sam: 15
  auth: 15
  winbind: 15
  vfs: 15
  idmap: 15
  quota: 15
  acls: 15
  locking: 15
  msdfs: 15
  dmapi: 15
  registry: 15
  scavenger: 15
  dns: 15
  ldb: 15
Failed to parse dcerpc binding 

Bug#767798: bind9: ignores OPTIONS from /etc/default/bind9 w/ systemd

[Gabriele Vivinetto]

Package: bind9
Version: 1:9.9.5.dfsg-9+deb8u5
Followup-For: Bug #767798

Dear Maintainer,
I confirm this bug: had to modify systemd service file to use defaults file 
options.

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

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

Versions of packages bind9 depends on:
ii  adduser3.113+nmu3
ii  bind9utils 1:9.9.5.dfsg-9+deb8u5
ii  debconf [debconf-2.0]  1.5.56
ii  init-system-helpers1.22
ii  libbind9-901:9.9.5.dfsg-9+deb8u5
ii  libc6  2.19-18+deb8u2
ii  libcap21:2.24-8
ii  libcomerr2 1.42.12-1.1
ii  libdns100  1:9.9.5.dfsg-9+deb8u5
ii  libgssapi-krb5-2   1.12.1+dfsg-19+deb8u1
ii  libisc95   1:9.9.5.dfsg-9+deb8u5
ii  libisccc90 1:9.9.5.dfsg-9+deb8u5
ii  libisccfg901:9.9.5.dfsg-9+deb8u5
ii  libk5crypto3   1.12.1+dfsg-19+deb8u1
ii  libkrb5-3  1.12.1+dfsg-19+deb8u1
ii  liblwres90 1:9.9.5.dfsg-9+deb8u5
ii  libssl1.0.01.0.1k-3+deb8u2
ii  libxml22.9.1+dfsg1-5+deb8u1
ii  lsb-base   4.1+Debian13+nmu1
ii  net-tools  1.60-26+b1
ii  netbase5.3

bind9 recommends no packages.

Versions of packages bind9 suggests:
pn  bind9-doc   
ii  dnsutils1:9.9.5.dfsg-9+deb8u5
pn  resolvconf  
pn  ufw 

-- Configuration Files:
/etc/bind/named.conf.local changed [not included]

-- debconf information:
  bind9/different-configuration-file:
  bind9/run-resolvconf: false
  bind9/start-as-user: bind

Bug#803819: gnash: FTBFS with FFmpeg 2.9

[Gabriele Giacone]

On Mon, Nov 2, 2015 at 10:06 PM, Andreas Cadhalpun
 wrote:
> Package: gnash
> Version: 0.8.11~git20150419-3
> Severity: important
> Tags: patch
> User: pkg-multimedia-maintain...@lists.alioth.debian.org
> Usertags: ffmpeg2.9
>
> Dear Maintainer,
>
> your package fails to build with the upcoming ffmpeg 2.9.
> This bug will become release-critical at some point when the
> ffmpeg2.9 transition gets closer.
>
> Attached is a patch replacing the deprecated functionality.
> It also works with ffmpeg 2.8.
> Please apply this patch and forward it upstream, if necessary.
>
> These changes have little regression potential.

Thanks for providing patches.
Could you please make your changes conditional upon
LIBAVCODEC_VERSION_{MAJOR,MINOR} / LIBAVUTIL_VERSION_INT / ... when
needed to keep supporting old ffmpeg/libav versions too?

Thanks,
-- 
G..e

Bug#799151: RFA: haxe -- Web-oriented universal programming language

[Gabriele Giacone]

Package: wnpp
Severity: normal

I request an adopter for the haxe package.

The package description is:
 Programming language similar to JavaScript, but with full-featured
 static type system and generics.  The command-line compiler can
 generate Flash SWF files for client-side use, Neko bytecode for
 server-side use on Apache, or JavaScript/PHP using Browser DHTML API
 to create AJAX web applications.
 .
 haXe was written by Nicolas Cannasse.

-- 
G..e

Bug#799092: RFS: haxe/1:3.2.0+dfsg-1

[Gabriele Giacone]

Hi Vincent, hi Andy,

On Tue, Sep 15, 2015 at 10:09 PM, Vincent Bernat  wrote:
>  ❦ 16 septembre 2015 03:46 +0800, Andy Li  :
>
>> I am looking for a sponsor for my package "haxe".
>> I'm a member of the Haxe Foundation. I would like to maintain the
>> package in the long term to improve haxe's debian support.
> [...[
>> * Adopt package.
>> + Set maintainer to myself.
>
> Hi Andy!
>
> The package isn't flagged up for adoption. Did you discuss with the
> current maintainers? The package has recently been adopted by the Debian
> Flash Team. I am sure they would welcome your help and accept that you
> maintain the package, but please, ask them.

I'm ok with haxe adoption.
At that time I adopted it just to fix rc bugs and avoid its removal,
gnash testsuite depends on it.
At the moment, no time to maintain it nor to review adopters' packaging.
Just filed RFA bug https://bugs.debian.org/799151

Thanks for your time
-- 
G..e

Bug#793982: imagemagick: Nested SVG tag: wrong rendering - wrong positioning

[Gabriele Motta]

Package: imagemagick
Version: 8:6.9.1.2-1
Severity: normal



-- Package-specific info:
ImageMagick program version
---
animate:  ImageMagick 6.8.9-9 Q16 x86_64 2015-01-05 http://www.imagemagick.org
compare:  ImageMagick 6.8.9-9 Q16 x86_64 2015-01-05 http://www.imagemagick.org
convert:  ImageMagick 6.8.9-9 Q16 x86_64 2015-01-05 http://www.imagemagick.org
composite:  ImageMagick 6.8.9-9 Q16 x86_64 2015-01-05 http://www.imagemagick.org
conjure:  ImageMagick 6.8.9-9 Q16 x86_64 2015-01-05 http://www.imagemagick.org
display:  ImageMagick 6.8.9-9 Q16 x86_64 2015-01-05 http://www.imagemagick.org
identify:  ImageMagick 6.8.9-9 Q16 x86_64 2015-01-05 http://www.imagemagick.org
import:  ImageMagick 6.8.9-9 Q16 x86_64 2015-01-05 http://www.imagemagick.org
mogrify:  ImageMagick 6.8.9-9 Q16 x86_64 2015-01-05 http://www.imagemagick.org
montage:  ImageMagick 6.8.9-9 Q16 x86_64 2015-01-05 http://www.imagemagick.org
stream:  ImageMagick 6.8.9-9 Q16 x86_64 2015-01-05 http://www.imagemagick.org

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

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

Versions of packages imagemagick depends on:
ii  imagemagick-6.q16  8:6.9.1.2-1

imagemagick recommends no packages.

imagemagick suggests no packages.

-- no debconf information


1. Let's have an svg A nested into another svg file B.svg

2. Convert B into another format - let's say png- using Imagick

3. A positioning is not correct, and it's close to the upper left side of the 
main svg.

4. As you increase the size of the main svg, its position after conversion is 
moved in the upper left side, more and more, until it's not processed and not 
shown in the converted file B.png


I have another server, (Debian 7 and Imagick 3.1.0RC1, Version: ImageMagick 
6.7.7-10 2014-03-08 Q16), and it works like a sharm.

It follows an example of a wrong rendered SVG:

?xml version=1.0 encoding=iso-8859-1 standalone=no?
!DOCTYPE svg PUBLIC -//W3C//Dtd SVG 1.1//EN 
http://www.w3.org/Graphics/SVG/1.1/Dtd/svg11.dtd;
svg width=200px height=100px id=MAIN_SVG version=1.1 
xmlns=http://www.w3.org/2000/svg;


 rect x='0px' y='0px' width='100px' height='100px' fill='black'/

svg transform=  x=100px y=0px 
id=NESTED_SVG height=100px width=100px

descImagemagick doesn't render 
this embedded (nested) SVG   /desc

rect x='0px' y='0px' width='100px' 
height='100px' fill='red' /


/svg

/svg

I expect the svg with tag NESTED_SVG (a red square) should be positioned 
100px from the left.

This is the result in my old server mentioned above (debian 7). In a brief on 
the old server it works.

On the other side with this server and the enviroment explained at the 
beginning of this report, the NESTED_SVG is positioned at -25px, i.e. the 
WRONG position.


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

Bug#738758: [PATCH] ext4: optimize Hurd tests when reading/writing inodes

[Gabriele Giacone]

From #hurd@freenode:

00:01  gnu_srs gg0: I wrote to Ted Tso about the ext4 bug and he
replied: Huh?  This patch (ext4: kill i_version support for
Hurd-castrated file
00:01  gnu_srs systems) landed upstream over a year ago, in Linux
3.15.  It is git commit c4f65706056e9f0c.

Just tested reproducer at https://bugs.debian.org/738758#5 with Jessie
3.16 kernel, fsck doesn't detect unexpected inconsistency anymore.

Has ext4: optimize Hurd tests when reading/writing inodes patch at
https://bugs.debian.org/738758#57 been applied too?
Any reason to keep it open?


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

Bug#789694: schroot: Please consider patch to fix it on hurd-i386

[Gabriele Giacone]

On Thu, Jul 9, 2015 at 10:45 AM, Samuel Thibault sthiba...@debian.org wrote:
 - debootstrap sets up a passive (i.e. permanent) bind mount from /proc
 to $CHROOT/proc

debootstrap in hurd case just runs setup-translators -K, which sets
another passive /proc under chroot, and it bindmounts /dev and
/servers.
Bindmounts are active.
BTW patch fixes CHROOT_TYPE=file case only, I didn't spend time on
other cases. So how one creates the chroot tarball should not actually
matter.

 - schroot sets up other active bind mounts (e.g. for /dev, /servers,
 etc.) as added in gnu/fstab from your patch

Yes, /proc /dev /servers in gnu/fstab.

 - do_umount_all $CHROOT_MOUNT_LOCATION does not work on the Hurd
 because of bug #763932, that's why the second do_umount_all call.

Correct.

 - that second call (do_umount_all ${CHROOT_FILE_UNPACK_DIR}/${SESSION_ID})
 manages to umount /dev, /servers etc. but not /proc because that one is
 passive, and umount doesn't unmount passive mounts. This is why the
 addition of the explicit settrans to make it go away.

Correct.

 Please correct anything wrong in this summary.  Notably I don't think
 debootstrap uses a passive translator, and thus I don't see why the
 second do_umount_all shouldn't be able to umount $CHROOT/proc actually.

As said above, debootstrap does create /proc passive translator under
chroot and maybe that would break chroot removal in CHROOT_TYPE!=file
cases. Not tested.
In CHROOT_TYPE=file case, tarball gets uncompressed, no passive
translators around, /proc /dev /servers get bindmounted and everything
works and gets removed fine. Unless... one runs setup-translators by
hand or by upgrading hurd package in chroot, that will set /proc
passive translator, which will make chroot removal fail.

I already tried to explain it at [0][1], probably fixable by making
setup-translators not to set passive /proc under chroots if already
bindmounted, as said [2] no idea how to detect that.

[0] https://lists.debian.org/debian-hurd/2014/09/msg00058.html
[1] https://lists.debian.org/debian-hurd/2015/05/msg00069.html
[2] https://lists.debian.org/debian-hurd/2014/10/msg7.html

-- 
G..e


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

Bug#789448: linux-image-3.16.0-4-amd64: Arima NM46X (NVIDIA MCP55) hangs early on boot

[Gabriele Gorla]

I have tried all the relevant precompiled kernels from 
http://snapshot.debian.org/package/linux/

the last one working is:
linux-image-3.10-3-amd64 (3.10.11-1)


the next available on the snapshot directory is:
linux-image-3.11-1-amd64 (3.11.6-2)
which fails with the same symptom as the jessie kernel.

I am not sure what else I can do to help debug the issue.
I would really appreciate if anyone could suggest any further debugging steps.

thanks




- Original Message -
From: Gabriele Gorla gor...@yahoo.com
To: Ben Hutchings b...@decadent.org.uk
Cc: 789...@bugs.debian.org 789...@bugs.debian.org
Sent: Wednesday, June 24, 2015 11:33 AM
Subject: Re: Bug#789448: linux-image-3.16.0-4-amd64: Arima NM46X (NVIDIA MCP55) 
hangs early on boot

I tried several precompiled kernels from 
http://snapshot.debian.org/package/linux/


linux-image-3.10-3-amd64 worked fine contrary to what previously reported (I 
probably did not compile the sources correctly last time).


I am going to try a few more precompiled kernels between 3.10 and 3.16 to try 
to narrow down when things stopped working. (I also tried 
linux-image-4.0.0-2-amd64 and did not work)

thanks





From: Ben Hutchings b...@decadent.org.uk
To: Gabriele Gorla gor...@yahoo.com 
Cc: 789...@bugs.debian.org 
Sent: Sunday, June 21, 2015 3:20 PM
Subject: Re: Bug#789448: linux-image-3.16.0-4-amd64: Arima NM46X (NVIDIA MCP55) 
hangs early on boot


On Sun, 2015-06-21 at 14:56 -0700, Gabriele Gorla wrote:
 Thanks for the quick reply.
 
 Adding nomodeset has no effect on the failure (the log in the attached 
 screenshot is the same as before)

OK, then this probably isn't a bug in the graphics driver, which was my
first thought.

 I also tried to compile a few long term support vanilla kernels from 
 kernel.org
 The last one that I could make work was 3.4.108
 Kernel 3.10.80, 3.12.44 and 3.14.44 all fail to boot (in a different way than 
 described in this bug though)
 I have not tried anything between 3.4.108 and 3.10.80

There are more versions available at
http://snapshot.debian.org/package/linux/.




Ben.

-- 
Ben Hutchings
You can't have everything.  Where would you put it?


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

Bug#789448: linux-image-3.16.0-4-amd64: Arima NM46X (NVIDIA MCP55) hangs early on boot

[Gabriele Gorla]

I tried several precompiled kernels from 
http://snapshot.debian.org/package/linux/


linux-image-3.10-3-amd64 worked fine contrary to what previously reported (I 
probably did not compile the sources correctly last time).


I am going to try a few more precompiled kernels between 3.10 and 3.16 to try 
to narrow down when things stopped working. (I also tried 
linux-image-4.0.0-2-amd64 and did not work)

thanks




From: Ben Hutchings b...@decadent.org.uk
To: Gabriele Gorla gor...@yahoo.com 
Cc: 789...@bugs.debian.org 
Sent: Sunday, June 21, 2015 3:20 PM
Subject: Re: Bug#789448: linux-image-3.16.0-4-amd64: Arima NM46X (NVIDIA MCP55) 
hangs early on boot


On Sun, 2015-06-21 at 14:56 -0700, Gabriele Gorla wrote:
 Thanks for the quick reply.
 
 Adding nomodeset has no effect on the failure (the log in the attached 
 screenshot is the same as before)

OK, then this probably isn't a bug in the graphics driver, which was my
first thought.

 I also tried to compile a few long term support vanilla kernels from 
 kernel.org
 The last one that I could make work was 3.4.108
 Kernel 3.10.80, 3.12.44 and 3.14.44 all fail to boot (in a different way than 
 described in this bug though)
 I have not tried anything between 3.4.108 and 3.10.80

There are more versions available at
http://snapshot.debian.org/package/linux/.




Ben.

-- 
Ben Hutchings
You can't have everything.  Where would you put it?


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

Bug#789694: schroot: Please consider patch to fix it on hurd-i386

[Gabriele Giacone]

Package: schroot
Version: 1.6.10-1+b1
Severity: wishlist
User: debian-h...@lists.debian.org
Usertags: hurd

Dear maintainer,

attached patch makes schroot working on hurd, has been being tested on
exodar porterbox since many months.
It works around #763932 bug.

More info in threads at
 https://lists.debian.org/debian-hurd/2014/09/msg00058.html
 https://lists.debian.org/debian-hurd/2015/05/msg00063.html

Thanks for considering.

-- 
G..e
diff --git a/etc/profile-templates/all/gnu/fstab 
b/etc/profile-templates/all/gnu/fstab
new file mode 100644
index 000..159c200
--- /dev/null
+++ b/etc/profile-templates/all/gnu/fstab
@@ -0,0 +1,3 @@
+/proc   /proc   nonebind0   0
+/dev/devnonebind0   0
+/servers/serversnonebind0   0
diff --git a/etc/profile-templates/default/gnu/fstab 
b/etc/profile-templates/default/gnu/fstab
new file mode 100644
index 000..e848dad
--- /dev/null
+++ b/etc/profile-templates/default/gnu/fstab
@@ -0,0 +1,11 @@
+/home   /home   nonebind0   0
+/tmp/tmpnonebind0   0
+
+# It may be desirable to have access to /run, especially if you wish
+# to run additional services in the chroot.  However, note that this
+# may potentially cause undesirable behaviour on upgrades, such as
+# killing services on the host.
+#/run/runnonebind0   0
+#/run/lock   /run/lock   nonebind0   0
+#/dev/shm/dev/shmnonebind0   0
+#/run/shm/run/shmnonebind0   0
diff --git a/etc/profile-templates/desktop/gnu/fstab 
b/etc/profile-templates/desktop/gnu/fstab
new file mode 100644
index 000..96f775a
--- /dev/null
+++ b/etc/profile-templates/desktop/gnu/fstab
@@ -0,0 +1,16 @@
+/home   /home   nonebind0   0
+/tmp/tmpnonebind0   0
+
+# If you use gdm3, uncomment this line to allow Xauth to work
+#/var/run/gdm3   /var/run/gdm3   nonebind0   0
+# For PulseAudio and other desktop-related things
+/var/lib/dbus   /var/lib/dbus   nonebind0   0
+
+# It may be desirable to have access to /run, especially if you wish
+# to run additional services in the chroot.  However, note that this
+# may potentially cause undesirable behaviour on upgrades, such as
+# killing services on the host.
+#/run/runnonebind0   0
+#/run/lock   /run/lock   nonebind0   0
+#/dev/shm/dev/shmnonebind0   0
+#/run/shm/run/shmnonebind0   0
diff --git a/etc/setup.d/10mount b/etc/setup.d/10mount
index 27c18d0..884c36a 100755
--- a/etc/setup.d/10mount
+++ b/etc/setup.d/10mount
@@ -224,6 +224,21 @@ if [ $CHROOT_TYPE = directory ] \
 elif [ $STAGE = setup-stop ]; then
 
 do_umount_all $CHROOT_MOUNT_LOCATION
+#
+# If CHROOT_TYPE is file, _UNPACK_DIR is bindmounted on
+# _MOUNT_LOCATION. Hurd does need to also bindmount /dev and
+# /servers on respectively _MOUNT_LOCATION/dev and
+# _MOUNT_LOCATION/servers, but due to #763932, currently
+# bindmounts-on-bindmounts result mounted on first bindmount
+# source device i.e. _UNPACK_DIR.
+# Workaround also umounts filesystems under _UNPACK_DIR.
+#
+if [ $CHROOT_TYPE = file -a $(uname -s) = GNU ]; then
+do_umount_all ${CHROOT_FILE_UNPACK_DIR}/${SESSION_ID}
+info Unmounting ${CHROOT_FILE_UNPACK_DIR}/${SESSION_ID}/proc
+settrans -apg ${CHROOT_FILE_UNPACK_DIR}/${SESSION_ID}/proc || 
exit 1
+fi
+
 if [ $CREATE_UNION = yes ]; then
 do_umount_all $CHROOT_UNION_UNDERLAY_DIRECTORY
 fi

Bug#753801: pbuilder: Please consider patch to fix it on hurd-i386

[Gabriele Giacone]

On Tue, Jun 23, 2015 at 12:57 AM, Mattia Rizzolo mat...@mapreri.org wrote:
 On Sat, Jul 05, 2014 at 11:37:45AM +0200, Gabriele Giacone wrote:
 attached patch makes pbuilder working on hurd.

 Thanks, committed to my git repo, i'll include it in the next NMU/regular
 upload I'll do.
 I've just added a couple of quotes here and then.
 I'm easy on this patch since quite whatever might have break is inside
 [ $DEB_BUILD_ARCH_OS = hurd ] clouses, so if something still breaks, just send
 another patch.

Thanks.

I also have a schroot patch you might be interested in due to
hurd-and-only-hurd (GNU) case. Patch is at
http://darnassus.sceen.net/~gg0/02schroot.diff
More info in following threads:
 https://lists.debian.org/debian-hurd/2014/10/msg7.html
 https://lists.debian.org/debian-hurd/2015/05/msg00063.html
I should probably file a schroot bug.

 First and last hunks work around a hurd limitation: currently if
 mountpoints (also device pathnames) contain superfluous . and /,
 path is not canonicalized so user to properly umount needs to specify
 mountpoint exactly as it was specified at mount time, with superfluous
 . and / if any.

 --- a/pbuilderrc
 +++ b/pbuilderrc
 @@ -4,7 +4,7 @@
  BASETGZ=/var/cache/pbuilder/base.tgz
  #EXTRAPACKAGES=
  #export DEBIAN_BUILDARCH=athlon
 -BUILDPLACE=/var/cache/pbuilder/build/
 +BUILDPLACE=/var/cache/pbuilder/build
  MIRRORSITE=http://cdn.debian.net/debian
  #OTHERMIRROR=deb http://www.home.com/updates/ ./
  #export http_proxy=http://your-proxy:8080/

 Well, keep in mind that people might have changed this on /etc/pbuilderrc,
 so not sure whether you want to account this somewhere else too.

IIRC superfluous-dots-and-slashes issue has been fixed on hurd side,
so first and last hunks are useless at the moment.

-- 
G..e


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

Bug#789282: freehep-chartableconverter-plugin: switch B-D from libplexus-compiler-api-java to libplexus-compiler-java

[Gabriele Giacone]

On Fri, Jun 19, 2015 at 03:46:41PM +0200, Andreas Beckmann wrote:
 Source: freehep-chartableconverter-plugin
 Version: 2.0-6
 Severity: serious
 Tags: stretch sid
 
 Your package Build-Depends: libplexus-compiler-api-java which was a
 transitional package that has now been removed. Please switch to
 libplexus-compiler-java instead.

Hi Giovanni,

fixed bug, rebuilt, pushed changes.
Please upload it yourself or grant me DM upload rights.
Also available at

 
http://mentors.debian.net/debian/pool/main/f/freehep-chartableconverter-plugin/freehep-chartableconverter-plugin_2.0-7.dsc

Thanks,
-- 
G..e


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

Bug#789448: linux-image-3.16.0-4-amd64: Arima NM46X (NVIDIA MCP55) hangs early on boot

[Gabriele Gorla]

Package: src:linux
Version: 3.16.7-ckt11-1
Severity: critical
Justification: breaks the whole system

Machine has been working flawlessly with Wheezy and kernel 3.2.
Just upgraded to Jessie.
Machine hangs very early (about 0.5s) booting the 3.16 kernel. Last line in 
the log is:
ACPI: PCI Interrupt Link [LUS0] enabled at IRQ 23

ctrl-alt-del and ctrl-alt-sysreq are both not responsive.


-- Package-specific info:
** Kernel log: boot messages should be attached

** Model information
sys_vendor: NVIDIA 
product_name: MCP55S
product_version: REFERENCE
chassis_vendor: AMD
chassis_version: N/A
bios_vendor: ARIMA CORPORATION.
bios_version: NM46X 1.10
board_vendor: NVIDIA 
board_name: MCP55S
board_version: REFERENCE

** PCI devices:
00:00.0 RAM memory [0500]: NVIDIA Corporation MCP55 Memory Controller 
[10de:0369] (rev a2)
Subsystem: NVIDIA Corporation Device [10de:cb84]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast TAbort- TAbort- 
MAbort- SERR- PERR- INTx-
Latency: 0
Capabilities: access denied

00:01.0 ISA bridge [0601]: NVIDIA Corporation MCP55 LPC Bridge [10de:0364] (rev 
a3)
Subsystem: NVIDIA Corporation Device [10de:cb84]
Control: I/O+ Mem+ BusMaster+ SpecCycle+ MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap- 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast TAbort- TAbort- 
MAbort- SERR- PERR- INTx-
Latency: 0
Region 0: I/O ports at 1c00 [size=128]

00:01.1 SMBus [0c05]: NVIDIA Corporation MCP55 SMBus Controller [10de:0368] 
(rev a3)
Subsystem: NVIDIA Corporation Device [10de:cb84]
Control: I/O+ Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast TAbort- TAbort- 
MAbort- SERR- PERR- INTx-
Interrupt: pin A routed to IRQ 255
Region 0: I/O ports at 2000 [size=64]
Region 4: I/O ports at 2440 [size=64]
Region 5: I/O ports at 2400 [size=64]
Capabilities: access denied
Kernel driver in use: nForce2_smbus

00:02.0 USB controller [0c03]: NVIDIA Corporation MCP55 USB Controller 
[10de:036c] (rev a1) (prog-if 10 [OHCI])
Subsystem: NVIDIA Corporation Device [10de:cb84]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast TAbort- TAbort- 
MAbort- SERR- PERR- INTx-
Latency: 0 (750ns min, 250ns max)
Interrupt: pin A routed to IRQ 22
Region 0: Memory at d0004000 (32-bit, non-prefetchable) [size=4K]
Capabilities: access denied
Kernel driver in use: ohci_hcd

00:02.1 USB controller [0c03]: NVIDIA Corporation MCP55 USB Controller 
[10de:036d] (rev a2) (prog-if 20 [EHCI])
Subsystem: NVIDIA Corporation Device [10de:cb84]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast TAbort- TAbort- 
MAbort- SERR- PERR- INTx-
Latency: 0 (750ns min, 250ns max)
Interrupt: pin B routed to IRQ 21
Region 0: Memory at d0005000 (32-bit, non-prefetchable) [size=256]
Capabilities: access denied
Kernel driver in use: ehci_hcd

00:04.0 IDE interface [0101]: NVIDIA Corporation MCP55 IDE [10de:036e] (rev a1) 
(prog-if 8a [Master SecP PriP])
Subsystem: NVIDIA Corporation Device [10de:cb84]
Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast TAbort- TAbort- 
MAbort- SERR- PERR- INTx-
Latency: 0 (750ns min, 250ns max)
Region 0: [virtual] Memory at 01f0 (32-bit, non-prefetchable) [size=8]
Region 1: [virtual] Memory at 03f0 (type 3, non-prefetchable)
Region 2: [virtual] Memory at 0170 (32-bit, non-prefetchable) [size=8]
Region 3: [virtual] Memory at 0370 (type 3, non-prefetchable)
Region 4: I/O ports at 2480 [size=16]
Capabilities: access denied
Kernel driver in use: pata_amd

00:05.0 IDE interface [0101]: NVIDIA Corporation MCP55 SATA Controller 
[10de:037f] (rev a3) (prog-if 85 [Master SecO PriO])
Subsystem: NVIDIA Corporation Device [10de:cb84]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast TAbort- TAbort- 
MAbort- SERR- PERR- INTx-
Latency: 0 (750ns min, 250ns max)
Interrupt: pin A routed to IRQ 16
Region 0: I/O ports at 1c80 [size=8]
Region 1: I/O ports at 1c90 [size=4]
Region 2: I/O ports at 1c88 [size=8]
Region 3: I/O ports at 1c94 [size=4]
Region 4: I/O ports at 2490 [size=16]
Region 5: Memory at d0006000 (32-bit, non-prefetchable) [size=4K]
Capabilities: access denied
Kernel driver in use: sata_nv

00:05.1 IDE interface [0101]: NVIDIA Corporation MCP55 SATA 

Bug#785514: closed by Bart Martens ba...@quantz.debian.org (closing RFS: ming/1:0.4.7-1 [RC])

[Gabriele Giacone]

On Tue, May 19, 2015 at 08:24:12PM -0700, Vincent Cheng wrote:
 Control: owner -1 !
 
 On Tue, May 19, 2015 at 5:22 PM, Gabriele Giacone 1o5g4...@gmail.com wrote:
  On Tue, May 19, 2015 at 04:30:10PM +, Debian Bug Tracking System wrote:
  Date: Tue, 19 May 2015 16:27:40 +
  From: Bart Martens ba...@quantz.debian.org
  To: 785514-d...@bugs.debian.org
  Subject: closing RFS: ming/1:0.4.7-1 [RC]
 
  Package ming has been removed from mentors.
 
  Re-uploaded without non-redistributable files.
 
   DSC: 
  http://mentors.debian.net/debian/pool/main/m/ming/ming_0.4.7+dfsg-1.dsc
   Git repo: https://anonscm.debian.org/cgit/pkg-flash/ming.git
 
Changes since the last upload:
 
   ming (1:0.4.7+dfsg-1) unstable; urgency=medium
 
 * New upstream release.
   + Change php bindings license from PHP to LGPL-2.1+ (Closes: #752629).
 * Convert d/copyright to format 1.0.
   + Update php extension license.
 * Remove non-redistributable files under java_ext/, see d/README.source.
   + Fix d/watch, add Files-Excluded to d/copyright, add
 get-orig-source target.
 * Remove 04_bison 05_hurd 06_ungif patches, applied upstream.
 * Switch to 3.0 (quilt) format.
 * Remove non debian/ changes.
 * Add Vcs-* fields.
 * B-D on debhelper = 9.
 * Switch to Debian Flash Team maintainship. Add myself to Uploaders.
 * Enable hardening.
 * Bump Standards-Version to 3.9.6 (no changes).
 
 
 Looks good to me, so I guess the only remaining blocker is to clarify
 the licensing situation of those php bindings. Please ping me once you
 hear back from ftpmaster.

I just shared a g+ conversation between Sandro Santilli, the only active
ming developer and Steve Alberty, the only missing copyright holder.
I'd consider his words as an approval. Unfortunately since then May
20th, he's been pinged many times, no replies.

 https://github.com/libming/libming/issues/42#issuecomment-110694325

Are you ok with it?

-- 
G..e


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

Bug#750821: sweethome3d crashes when selecting Preferences

[Gabriele Giacone]

On Sat, May 30, 2015 at 08:07:36PM +0300, Török Edwin wrote:
 Package: sweethome3d
 Version: 4.5+dfsg-3
 Followup-For: Bug #750821
 
 Dear Maintainer,
 
 This problem is documented in the FAQ Sweet Home 3D crashes when I want to
 edit preferences, print, create a photo or create a video. What can I do?:
 http://www.sweethome3d.com/faq.jsp
 
 Using the workaround there I have edited JAVA_ARGS in /usr/bin/sweethome3d and
 added
 -Dcom.eteks.sweethome3d.j3d.checkOffScreenSupport=false.
 Now it no longer crashes:
 
 JAVA_ARGS=-Djava.library.path=/usr/lib/jni \
  -Dcom.eteks.sweethome3d.j3d.checkOffScreenSupport=false \
 -Dcom.eteks.sweethome3d.applicationFolders=$HOME/.eteks/sweethome3d:/usr/share/sweethome3d

Stefan, does it fix crash?

Török, thanks for sharing.
CC'ing Stefan because unless submitter subscribes bug, doesn't receive
followups.

 FWIW my OpenGL driver is:
 OpenGL vendor string: X.Org
 OpenGL renderer string: Gallium 0.4 on AMD RV730
 OpenGL core profile version string: 3.3 (Core Profile) Mesa 10.3.2
 OpenGL core profile shading language version string: 3.30
 OpenGL core profile context flags: (none)
 OpenGL core profile profile mask: core profile
 OpenGL core profile extensions:
 OpenGL version string: 3.0 Mesa 10.3.2
 OpenGL shading language version string: 1.30
 OpenGL context flags: (none)
 OpenGL extensions:
 OpenGL ES profile version string: OpenGL ES 3.0 Mesa 10.3.2
 OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.0
 OpenGL ES profile extensions:

-- 
G..e


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