Bug#1050967: RFS: mesa/23.1.6-1~bpo12+1

[Jérémy Viès]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for the package "mesa":

 * Package name : mesa
   Version  : 23.1.6
   Upstream contact : debia...@lists.debian.org, uploader
ab...@debian.org
 * URL  : https://mesa3d.org/
 * License  : MIT and more (see
https://docs.mesa3d.org/license.html)
 * Vcs  : https://salsa.debian.org/xorg-team/lib/mesa.git
   Section  : graphics

The source builds the following binary packages:

  mesa

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

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

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

  dget -
x https://mentors.debian.net/debian/pool/main/m/mesa/mesa_23.1.6-1~bpo12+1.dsc

Changes since the last upload:

* Rebuild for bookworm-backports.

Regards,

Bug#1005222: gedit: Open dialog defaults to HOME instead of current file's directory

[Jérémy Viès]

Package: gedit
Version: 3.38.1-1

This issue has been fixed upstream in 3.38.2 (cf
https://gitlab.gnome.org/GNOME/gedit/-/issues/382).

Can Gnome team consider updating gedit to 3.38.2 ?

Best regards,
Jérémy VIES

Bug#963980: issue confirmed on newly installed Debian 11.2

[Jérémy Viès]

I can confirm I have the same issue using a brandly new installed machine
with the nvidia driver.


primus: fatal: Bumblebee daemon reported: error: [XORG] (EE) Unable to
locate/open config directory: "/etc/bumblebee/xorg.conf.d"

Bug#987584: docker.io: docker-proxy does not bind to ipv6 "all network" address

[Jérémy Viès]

Package: docker.io
Version: 20.10.5+dfsg1-1+b1
Severity: important
Tags: ipv6

Dear Maintainer,


   * What led up to the situation?
I'm trying to expose some web app to the ipv6 Internet !
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
I enabled ipv6 support in /etc/docker/daemon.json as explained in docker doc.
   * What was the outcome of this action?
Exposed ports are only on ipv4 even if ipv6 is enabled in docker configuration.
   * What outcome did you expect instead?
The binding shall be done on both ipv4 and ipv6 networks.

The issue is confirmed upstream : https://github.com/moby/moby/issues/42059
It is due to https://github.com/moby/libnetwork/issues/2607
It seems to be fixed already, and packaged in version 20.10.6 that has been
just released.


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

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

Versions of packages docker.io depends on:
ii  adduser  3.118
ii  containerd   1.4.4~ds1-2
ii  init-system-helpers  1.60
ii  iptables 1.8.7-1
ii  libc62.31-11
ii  libdevmapper1.02.1   2:1.02.175-2.1
ii  libsystemd0  247.3-3
ii  lsb-base 11.1.0
ii  runc 1.0.0~rc93+ds1-2+b2
ii  tini 0.19.0-1

Versions of packages docker.io recommends:
ii  apparmor 2.13.6-10
ii  ca-certificates  20210119
ii  cgroupfs-mount   1.4
ii  git  1:2.30.2-1
ii  needrestart  3.5-2
ii  xz-utils 5.2.5-2

Versions of packages docker.io suggests:
ii  aufs-tools 1:4.14+20190211-1
pn  btrfs-progs
pn  debootstrap
pn  docker-doc 
ii  e2fsprogs  1.46.2-1
pn  rinse  
pn  rootlesskit
pn  xfsprogs   
pn  zfs-fuse | zfsutils-linux  

Bug#932501: problem still present in 0.8.15

[Jérémy Viès]

Hi,

Just to confirm the issue is still present in bullseye current release.
I had to add the following lines to apparmor configuration to make it work.

  /etc/squid-deb-proxy/** r,
  /var/log/squid-deb-proxy/* rw,
  /run/squid-deb-proxy.pid rwk,
  /var/cache/squid-deb-proxy/** rw,

Best regards

Bug#970885: adriconf : first trial of packaging

[Jérémy Viès]

Hi Rogério and all,

I've done a trial to package the tool adriconf. It works, but it misses
several things:
* the .desktop file from the flatpak directory should be copied. But I
am very new debian packaging and I don't know how to override some rule
to do that.
* no manpage
* the tests are generated but not ran at package build


I can provide the source package if it can help someone.

Regards,

Bug#942229: Issue confirmed on Buster i386

[Jérémy Viès]

Hello,

I haven't find any solution for the llvm build on buster i386.

By the way, the -3 release from sid makes the backport further more
complicated as now it draws z3, that needs a newer version of ocaml...
For now, I abandonned the idea to quickly backport mesa from sid to buster.

Best regards,
Jérémy

Le sam. 26 oct. 2019 à 19:41, Sylvestre Ledru  a écrit :

> Hello
>
> I just experienced it too and the cmake logs are useless.
>
> Have you been able to find a fix for that? It is pretty confusing :/
>
> Thanks
>
> Sylvestre
>
>
> Le 17/10/2019 à 19:29, Jérémy Viès a écrit :
> > Hello,
> >
> > I'm following this bug as I try to do the same backport. I can confirm
> > the issue in a simple docker configuration, based on i386/debian:buster
> > with only the declared deps of llvm-toolchain installed.
> >
> > Best regards,
> > Jérémy
> >
> > ___
> > Pkg-llvm-team mailing list
> > pkg-llvm-t...@alioth-lists.debian.net
> > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-llvm-team
>

Bug#942229: Issue confirmed on Buster i386

[Jérémy Viès]

Hello,

I'm following this bug as I try to do the same backport. I can confirm
the issue in a simple docker configuration, based on i386/debian:buster
with only the declared deps of llvm-toolchain installed.

Best regards,
Jérémy

Bug#928146: reported on freedesktop too

[Jérémy Viès]

Hi all,

it seems the issue is already reported and fixed in upstream repo:
https://bugs.freedesktop.org/show_bug.cgi?id=110509

Bug#925084: di-netboot-assistant: debian-installer-xxx-netboot-yyy are wrongly configured

[Jérémy Viès]

Hi Andreas,

sorry for the delay, your emails went to my spam folder.

I thought I was more smart than the doc... I didn't mount/bind the
installer folder, instead I linked it to the correct place.
I've just tried mounting the folder, and all is OK !

so sorry again for the disturbing !

by curiosity, why does it work using mount/bind and not with a simple
symbolic link ?

regards,


Le ven. 22 mars 2019 à 18:48, Andreas B. Mundt  a écrit :

> Control: tags + unreproducible moreinfo
>
>
> Hi Jérémy,
>
> On Tue, Mar 19, 2019 at 07:43:47PM +0100, Jérémy Viès wrote:
> […]
> > I get a "No DEFAULT or UI configuration directive found!" when the PXE
> client
> > boots on one of these installer.
>
> I cannot reproduce the problem you reported.  It works fine here, also
> with the packaged installer.  Can you check if the installer is
> available in '/var/lib/tftpboot/d-i/n-pkg/' (or your corresponding
> TFTP-root)?
>
> Thanks and best regards,
>
>   Andi
>

Bug#925084: di-netboot-assistant: debian-installer-xxx-netboot-yyy are wrongly configured

[Jérémy Viès]

Package: di-netboot-assistant
Version: 0.60~bpo9+1
Severity: normal
Tags: d-i

Dear Maintainer,


I've just discovered and then set-up di-netboot-assistant to manage several
debian netboot versions.
It works great when it manages setup di-netboot-assistant installed by itself,
but it fails to configure correctly already installed installers from official
packages.
I get a "No DEFAULT or UI configuration directive found!" when the PXE client
boots on one of these installer.

(Other system information are not relevant as I'm not writing from the PXE boot
server)

Best regards,
Jérémy VIES



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

Kernel: Linux 4.19.0-3-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages di-netboot-assistant depends on:
ii  curl  7.64.0-1
ii  wget  1.20.1-1

Versions of packages di-netboot-assistant recommends:
ii  grub-efi-amd64-bin2.02+dfsg1-12
pn  tftpd-hpa | atftpd | dnsmasq  

Versions of packages di-netboot-assistant suggests:
pn  dnsmasq | isc-dhcp-server | udhcpd  
pn  syslinux
pn  vim-addon-manager   

Bug#882213: gvfs-fuse: MTP device still visible after disconnecting

[Jérémy Viès]

It only happens on stretch with backports enabled.
It seems related to a different behavior of systemd 237 vs 232 that is in
vanilla stretch.

I've backported the patch on my 2 systems, and have seen no regression
until now... but I didn't made a lot of tests !

Regards,

On Thu, 5 Apr 2018 10:43:24 +0100 Simon McVittie <s...@debian.org> wrote:
> On Wed, 04 Apr 2018 at 21:06:01 +0200, Jérémy Viès wrote:
> > The fixes for gnome-3-22 has also been posted on gnome git repository.
> > Can you backport the fix to gvfs 1.30, used by gnome 3.22 that are on
stretch ?
>
> Maybe. It depends how serious the bug is and how intrusive the fixes are:
> introducing a regression of equal or greater severity would be worse than
> leaving this bug open.
>
> All the reports of this issue that had version information were in
> buster/sid or in a sid-based Debian derivative. Can it be reproduced on
> a pure stretch system, or on a stretch system with specified backports,
> perhaps udev and/or the kernel?
>
> smcv
>
>

Bug#882213: gvfs-fuse: MTP device still visible after disconnecting

[Jérémy Viès]

The fixes for gnome-3-22 has also been posted on gnome git repository.
Can you backport the fix to gvfs 1.30, used by gnome 3.22 that are on
stretch ?

https://github.com/GNOME/gvfs/commits/gnome-3-22

Thx a lot,
Jérémy

On Tue, 3 Apr 2018 12:03:36 +0100 Simon McVittie  wrote:
> Version: 1.35.90-1
>
> On Mon, 20 Nov 2017 at 11:20:10 +0100, Michal M. wrote:
> >  - Unmount your device, disconnect USB cable. Device is removed, but
item is
> > still visible in "Devices" section. It's dead item, not possible to
remove it
> > or mount/unmount
>
> This is believed to have been fixed in gvfs 1.35 (see #882353, #883425).
>
> smcv
>
>

Bug#784003: workaround

[Jérémy Viès]

I confirm the bug on Jessie.

I just commented both lines with has_separator property, and it seems ok.


-- 
Theory is where you know everything, but nothing works; practice is where
everything works, but nobody knows why. Here we combine theory with
practice; nothing works and nobody knows why !
A.Einstein

Bug#750821: sweethome3d crashes when selecting "Preferences"

[Jérémy Viès]

Hi Gabriele,

I can confirm that appending this
"-Dcom.eteks.sweethome3d.j3d.checkOffScreenSupport=false"
args to the JAVA_ARGS  fixes the issue.

I'm also running the default jessie JRE, on a system running the radeon OSS
driver.

Regards,
Jérémy

PS: my opengl driver follows:
OpenGL vendor string: X.Org
OpenGL renderer string: Gallium 0.4 on AMD PITCAIRN (DRM 2.43.0, LLVM 3.7.0)
OpenGL core profile version string: 4.1 (Core Profile) Mesa 11.0.3
OpenGL core profile shading language version string: 4.10
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile
OpenGL core profile extensions:
OpenGL version string: 3.0 Mesa 11.0.3
OpenGL shading language version string: 1.30
OpenGL context flags: (none)
OpenGL extensions:
OpenGL ES profile version string: OpenGL ES 3.0 Mesa 11.0.3
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.00
OpenGL ES profile extensions:

-- 
Theory is where you know everything, but nothing works; practice is where
everything works, but nobody knows why. Here we combine theory with
practice; nothing works and nobody knows why !
A.Einstein

Bug#747130: owncloud 'Depends' on php-irods-prods while it is noted 'Recommends'

[Jérémy Viès]

Package: owncloud
Version: 6.0.2+dfsg-1~bpo70+1
After the installation of owncloud on Debian Wheezy, it was configured
correctly, but was never able to start.

lighttpd error logs show:
2014-05-05 09:10:41: (mod_fastcgi.c.2676) FastCGI-stderr: PHP Fatal
error:  require_once(): Failed opening required 'ProdsConfig.inc.php'
(include_path='/usr/share/owncloud/lib/private:/usr/share/owncloud/config:/usr/share/owncloud/3rdparty:/usr/share/owncloud/apps:/usr/share/owncloud/lib:.:/usr/share/php:/usr/share/pear:/usr/share/owncloud:/usr/share/owncloud/apps/search_lucene/3rdparty:/usr/share/php/irods/prods/src')
in /usr/share/owncloud/apps/files_external/lib/irods.php on line 15

The installation of php-irods-prods fixed the problem.

Bug#747130: owncloud 'Depends' on php-irods-prods while it is noted 'Recommends'

[Jérémy Viès]

Sorry for sending via the wrong report system !

You're right, I activated some external storage support (local in fact).
And I agree with your analysis, only files_external uses php-irods-prods.

So I think, the bug reported can rejected.
I suppose that to note the dependencies of each provided application in the
README.Debian would take too much time...

ok thank you for your reactiveness !




2014-05-05 22:42 GMT+02:00 David Prévot taf...@debian.org:

 Hi Jérémy,

 On Mon, May 05, 2014 at 10:15:32PM +0200, Jérémy Viès wrote:
  Package: owncloud
  Version: 6.0.2+dfsg-1~bpo70+1

 “Please report bugs that you found in the packages to the backports
 mailinglist[1] and NOT to the Debian BTS!”[2]

1: http://lists.debian.org/debian-backports/
2: http://backports.debian.org/Instructions/#index6h2

  After the installation of owncloud on Debian Wheezy, it was configured
  correctly, but was never able to start.
 
  lighttpd error logs show:
  2014-05-05 09:10:41: (mod_fastcgi.c.2676) FastCGI-stderr: PHP Fatal
  error:  require_once(): Failed opening required 'ProdsConfig.inc.php'
 
 (include_path='/usr/share/owncloud/lib/private:/usr/share/owncloud/config:/usr/share/owncloud/3rdparty:/usr/share/owncloud/apps:/usr/share/owncloud/lib:.:/usr/share/php:/usr/share/pear:/usr/share/owncloud:/usr/share/owncloud/apps/search_lucene/3rdparty:/usr/share/php/irods/prods/src')
  in /usr/share/owncloud/apps/files_external/lib/irods.php on line 15
 
  The installation of php-irods-prods fixed the problem.

 AFAICT, only the files_external app needs php-irods-prods, but it’s not
 enabled by default, so no strict dependency is necessary here
 (administrators who decide not to follow the maintainer’s
 recommendations are exposed to fix their own installation).

 Can you please confirm that you activated the files_external app?

 Regards

 David




-- 
Theory is where you know everything, but nothing works; practice is where
everything works, but nobody knows why. Here we combine theory with
practice; nothing works and nobody knows why !
A.Einstein

Bug#633972: cron.daily/standard fails on mount point with a space in path.

[Jérémy Viès]

here is the run of the patched standard :

+ cd /
+ LOCKFILE=/var/lock/cron.daily
+ LOFO=lost+found
++ which flock
+ exec
+ flock -x -n 9
+ '[' -f /etc/default/cron ']'
+ . /etc/default/cron
++ READ_ENV=yes
+ '[' '' = no ']'
+ read DEV MTPT FSTYPE OPTS REST
+ case $DEV in
+ case $FSTYPE in
+ '[' / = / ']'
+ MTPT=
++ echo
++ sed -e 's/\040/ /g'
+ MTPT=
+ '[' '!' -d /lost+found ']'
+ cd /lost+found
+ LIST=
+ for NAME in '*'
+ '[' '*' = '*' ']'
+ break
+ '[' -n '' ']'
+ continue
+ read DEV MTPT FSTYPE OPTS REST
+ case $DEV in
+ continue
+ read DEV MTPT FSTYPE OPTS REST
+ case $DEV in
+ continue
+ read DEV MTPT FSTYPE OPTS REST
+ case $DEV in
+ continue
+ read DEV MTPT FSTYPE OPTS REST
+ case $DEV in
+ continue
+ read DEV MTPT FSTYPE OPTS REST
+ case $DEV in
+ continue
+ read DEV MTPT FSTYPE OPTS REST
+ case $DEV in
+ continue
+ read DEV MTPT FSTYPE OPTS REST
+ case $DEV in
+ continue
+ read DEV MTPT FSTYPE OPTS REST
+ case $DEV in
+ continue
read DEV MTPT FSTYPE OPTS REST
+ case $DEV in
+ case $FSTYPE in
+ '[' /home = / ']'
++ echo /home
++ sed -e 's/\040/ /g'
+ MTPT=/home
+ '[' '!' -d /home/lost+found ']'
+ cd /home/lost+found
+ LIST=
+ for NAME in '*'
+ '[' '*' = '*' ']'
+ break
+ '[' -n '' ']'
+ continue
+ read DEV MTPT FSTYPE OPTS REST
+ case $DEV in
+ case $FSTYPE in
+ '[' $'/home/Documents040Partag\303\251s' = / ']'
++ echo $'/home/Documents040Partag\303\251s'
++ sed -e 's/\040/ /g'
+ MTPT='/home/Documents Partagés'
+ '[' '!' -d '/home/Documents Partagés/lost+found' ']'
+ cd '/home/Documents Partagés/lost+found'
+ LIST=
+ for NAME in '*'
+ '[' '*' = '*' ']'
+ break
+ '[' -n '' ']'
+ continue
+ read DEV MTPT FSTYPE OPTS REST
+ case $DEV in
+ case $FSTYPE in
+ '[' /mnt/Archives = / ']'
++ echo /mnt/Archives
++ sed -e 's/\040/ /g'
+ MTPT=/mnt/Archives
+ '[' '!' -d /mnt/Archives/lost+found ']'
+ cd /mnt/Archives/lost+found
+ LIST=
+ for NAME in '*'
+ '[' '*' = '*' ']'
+ break
+ '[' -n '' ']'
+ continue
+ read DEV MTPT FSTYPE OPTS REST
+ case $DEV in
+ continue
+ read DEV MTPT FSTYPE OPTS REST
+ case $DEV in
+ continue
+ read DEV MTPT FSTYPE OPTS REST
+ case $DEV in
+ continue
+ read DEV MTPT FSTYPE OPTS REST
+ case $DEV in
+ continue
+ read DEV MTPT FSTYPE OPTS REST
+ case $DEV in
+ continue
+ read DEV MTPT FSTYPE OPTS REST
+ '[' -n '' ']'
+ '[' -n '' ']'
+ rm -f /var/lock/cron.daily

it is ok for me now.
I just wonder if they are not other special chars it should also handle ?

regards


2011/7/19 Javier Fernández-Sanguino Peña j...@computer.org

 On Mon, Jul 18, 2011 at 10:12:06PM +0200, J?r?my Vi?s wrote:
  The problem is related to the \040 I have in my fstab to have a space in
 the
  path. I don't know if their is another proper way to have a space in a
 mount
  point...
  If not, I can patch the standard script to replace the \040 by a space.

 Could you please patch your /etc/cron.daily/standard with the attached
 patch
 and see if still have the issue?


 You can manually force the cron run by running /etc/cron.daily/standard (as
 root) directly. Please send me (privately if it contains confidential
 information) the output of running 'sh -x /etc/cron.daily/standard' with
 the
 patch herein.

 Regards

 Javier




-- 
Theory is where you know everything, but nothing works; practice is where
everything works, but nobody knows why. Here we combine theory with
practice; nothing works and nobody knows why !
A.Einstein

Bug#633972: cron.daily/standard fails on mount point with a space in path.

[Jérémy Viès]

here is the report I receive by email:

/etc/cron.daily/logrotate:
error: error running non-shared postrotate script for /var/log/mediatomb.log
of '/var/log/mediatomb.log '
run-parts: /etc/cron.daily/logrotate exited with return code 1
/etc/cron.daily/standard:

Some local file systems lack a lost+found directory. This means if the
file system is damaged and needs to be repaired, fsck will not have
anywhere to put stray files for recovery. You should consider creating
a lost+found directory with mklost+found(8).

The following lost+found directories were not available:

/home/Documents040Partagés/
lost+found


#

here is my related mtab line:

[...]
/dev/sdb1 /home/Documents\040Partagés ext4 rw,noatime,acl 0 0
[...]

The problem is related to the \040 I have in my fstab to have a space in the
path. I don't know if their is another proper way to have a space in a mount
point...
If not, I can patch the standard script to replace the \040 by a space.

regards



2011/7/18 Javier Fernández-Sanguino Peña j...@computer.org


 Could you please precise what error does it generate?

 Also, please send attached a copy of your /etc/mtab to the bug report.

 Thanks,

 Javier




-- 
Theory is where you know everything, but nothing works; practice is where
everything works, but nobody knows why. Here we combine theory with
practice; nothing works and nobody knows why !
A.Einstein

Bug#633972: cron.daily/standard fails on mount point with a space in path.

[Jérémy Viès]

Package: cron
Version: 3.0pl1-118
Severity: normal
Tags: wheezy



-- Package-specific info:
--- EDITOR:
not set

--- usr/bin/editor:
/bin/nano

--- /usr/bin/crontab:
-rwxr-sr-x 1 root crontab 33984 Jun  5 11:27 /usr/bin/crontab

--- /var/spool/cron
drwxr-xr-x 3 root root 4096 Jun 25 22:49 /var/spool/cron

--- /var/spool/cron/crontabs
drwx-wx--T 2 root crontab 4096 Jun 28 20:50 /var/spool/cron/crontabs


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

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

Versions of packages cron depends on:
ii  adduser   3.113  add and remove users and groups
ii  debianutils   4.0.2  Miscellaneous utilities specific t
ii  dpkg  1.16.0.3   Debian package management system
ii  libc6 2.13-7 Embedded GNU C Library: Shared lib
ii  libpam-runtime1.1.3-2Runtime support for the PAM librar
ii  libpam0g  1.1.3-2Pluggable Authentication Modules l
ii  libselinux1   2.0.98-1.1 SELinux runtime shared libraries
ii  lsb-base  3.2-27 Linux Standard Base 3.2 init scrip

Versions of packages cron recommends:
ii  exim4 4.76-2 metapackage to ease Exim MTA (v4) 
ii  exim4-daemon-light [mail-tran 4.76-2 lightweight Exim MTA (v4) daemon

Versions of packages cron suggests:
ii  anacron   2.3-14 cron-like program that doesn't go 
pn  checksecurity none (no description available)
ii  logrotate 3.7.8-6Log rotation utility

Versions of packages cron is related to:
pn  libnss-ldap   none (no description available)
pn  libnss-ldapd  none (no description available)
pn  libpam-ldap   none (no description available)
pn  libpam-mount  none (no description available)
pn  nis   none (no description available)
pn  nscd  none (no description available)

-- no debconf information



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