Bug#1079732: obs-studio: Starting recording fails

[Elmar Ludwig]

Downgrading the packages from src:obs-studio and src:ffmpeg to the previous
versions on snapshot.debian.org (30.1.2+dfsg-1+b2 and 6.1.1-5+b1 respectively)
resolves the issue, so either one of these updates seems to be the cause here.

The previous obs-studio package is not installable without downgrading ffmpeg
due to the ffmpeg transition.

Bug#1070110: distrobox: Permission denied on vboxusb

[Elmar Haneke]

Package: distrobox
Version: 1.7.1.0-1
Severity: normal

Dear Maintainer,

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

Im trying to start debian bullseye image

distrobox enter bullseye

this results in an error indicating permission problem on vboxusb:

Error: unable to start container
"21204c6e942944c89febc8bf0bc670116bb131d3f7e6728da2de05bb988a270e": runc: runc
create failed: unable to start container process: error during container init:
error mounting "/dev/vboxusb/003/005" to rootfs at "/dev/vboxusb/003/005":
lstat
/home/elmar/.local/share/containers/storage/overlay/22cdbab429db6e4f663a1bd95cdee146bf4cc677a4007d7b0c13d7e066c8b214/merged/dev/vboxusb/003:
permission denied: OCI permission denied


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


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

Kernel: Linux 6.7.12-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=de_DE.utf-8, LC_CTYPE=de_DE.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 distrobox depends on:
ii  podman  4.9.4+ds1-1
ii  uidmap  1:4.13+dfsg1-4

distrobox recommends no packages.

distrobox suggests no packages.

-- no debconf information

Bug#932909: Bug #932909: xchroot/2.7.5-1 [ITP] -- extended chroot with X11/Xorg forwarding

[Elmar Stellnberger]

Package: sponsorship-requests
Severity: wishlist

Xchroot 2.7.4 has also come with many new features. Dbus session 
creation and /dev/shm mounting satisfy the need even of exigent GUI 
programs like the Otter browser. It has a /media and subdirectory 
automounter which is especially useful for mirroring mounts of removable 
media. It is even possible to run a whole desktop session like KDE, 
Gnome or Xfce in an xchroot container. Desktop link creation for the GUI 
menu is included. The program has evolved much since Debian fellows have 
initially persuaded me to make the program open source. That time there 
was interest in the development of xchroot regarding Debian.

Bug#932909: Bug #932909: xchroot/2.7.5-1 [ITP] -- extended chroot with X11/Xorg forwarding

[Elmar Stellnberger]

Package: sponsorship-requests
Severity: wishlist

Dear Bart Martens,
Dear mentors,

  I have now applied the necessary changes for package "xchroot" to get 
sponsored:


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

  dget -xu 
https://mentors.debian.net/debian/pool/main/x/xchroot/xchroot_2.7.5-1.dsc


  Changes since the last upload:

  The changelog now contains only one entry with reference to making 
the ITP bug #721447 closed. Version number is -1 as required.


  version 2.7.5 has a more robust xauth mechanism and fixes a fallacy 
when X-authorization is given on a per user or local basis rather than 
by a MIT-MAGIC-COOKIE-1: Now xchroot can generate the cookie on the fly 
if none is encountered:

https://www.elstel.org/ViewRSS.php?guid=7470#7470

Regards,
Elmar Stellnberger

Bug#1028520: flamerobin: Crash on opening SQL Editor

[Elmar Haneke]

Package: flamerobin
Version: 0.9.6.ds.1-1+b2
Severity: important

Dear Maintainer,

   * What led up to the situation?
   * What exactly did you do (or not do) that was effective (or
 ineffective)?

Problem is reproducable with
- start flamerobin
- connect to some database
- select context-Menu "open SQL Editor"


   * What was the outcome of this action?

Program does crash with segmentation fault

   * What outcome did you expect instead?

Program should open SQL-Editor window

Running in gdb does result in the following:

~$ gdb flamerobin
GNU gdb (Debian 12.1-4+b1) 12.1
Copyright (C) 2022 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from flamerobin...
(No debugging symbols found in flamerobin)
(gdb) run
Starting program: /usr/bin/flamerobin
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x743ff6c0 (LWP 20690)]
[New Thread 0x73bfe6c0 (LWP 20691)]
[New Thread 0x733b16c0 (LWP 20692)]
[New Thread 0x72bb06c0 (LWP 20693)]
[New Thread 0x720e36c0 (LWP 20694)]
[Thread 0x720e36c0 (LWP 20694) exited]
10:12:06 AM: Debug: Trying to load image file
"/usr/share/flamerobin/images/object_16x16.png"
10:12:06 AM: Debug: Trying to load image file
"/usr/share/flamerobin/images/object_16x16.xpm"
10:12:06 AM: Debug: Trying to load image file
"/usr/share/flamerobin/images/object_16x16.bmp"
10:12:06 AM: Debug: Trying to load image file
"/usr/share/flamerobin/images/column_16x16.png"
10:12:06 AM: Debug: Trying to load image file
"/usr/share/flamerobin/images/column_16x16.xpm"
10:12:06 AM: Debug: Trying to load image file
"/usr/share/flamerobin/images/column_16x16.bmp"
10:12:06 AM: Debug: Trying to load image file
"/usr/share/flamerobin/images/computed_16x16.png"
10:12:06 AM: Debug: Trying to load image file
"/usr/share/flamerobin/images/computed_16x16.xpm"
10:12:06 AM: Debug: Trying to load image file
"/usr/share/flamerobin/images/computed_16x16.bmp"
10:12:06 AM: Debug: Trying to load image file
"/usr/share/flamerobin/images/databaseconnected_16x16.png"
10:12:06 AM: Debug: Trying to load image file
"/usr/share/flamerobin/images/databaseconnected_16x16.xpm"
10:12:06 AM: Debug: Trying to load image file
"/usr/share/flamerobin/images/databaseconnected_16x16.bmp"
10:12:06 AM: Debug: Trying to load image file
"/usr/share/flamerobin/images/databasedisconnected_16x16.png"
10:12:06 AM: Debug: Trying to load image file
"/usr/share/flamerobin/images/databasedisconnected_16x16.xpm"
10:12:06 AM: Debug: Trying to load image file
"/usr/share/flamerobin/images/databasedisconnected_16x16.bmp"
10:12:06 AM: Debug: Trying to load image file
"/usr/share/flamerobin/images/databaseserver_16x16.png"
10:12:06 AM: Debug: Trying to load image file
"/usr/share/flamerobin/images/databaseserver_16x16.xpm"
10:12:06 AM: Debug: Trying to load image file
"/usr/share/flamerobin/images/databaseserver_16x16.bmp"
10:12:06 AM: Debug: Trying to load image file
"/usr/share/flamerobin/images/dbtrigger_16x16.png"
10:12:06 AM: Debug: Trying to load image file
"/usr/share/flamerobin/images/dbtrigger_16x16.xpm"
10:12:06 AM: Debug: Trying to load image file
"/usr/share/flamerobin/images/dbtrigger_16x16.bmp"
10:12:06 AM: Debug: Trying to load image file
"/usr/share/flamerobin/images/dbtriggers_16x16.png"
10:12:06 AM: Debug: Trying to load image file
"/usr/share/flamerobin/images/dbtriggers_16x16.xpm"
10:12:06 AM: Debug: Trying to load image file
"/usr/share/flamerobin/images/dbtriggers_16x16.bmp"
10:12:06 AM: Debug: Trying to load image file
"/usr/share/flamerobin/images/ddltrigger_16x16.png"
10:12:06 AM: Debug: Trying to load image file
"/usr/share/flamerobin/images/ddltrigger_16x16.xpm"
10:12:06 AM: Debug: Trying to load image file
"/usr/share/flamerobin/images/ddltrigger_16x16.bmp"
10:12:06 AM: Debug: Trying to load image file
"/usr/share/flamerobin/images/ddltriggers_16x16.png"
10:12:06 AM: Debug: Trying to load image file
"/usr/share/flamerobin/images/ddltriggers_16x16.xpm"
10:12:06 AM: Debug: Trying to load image file
"/usr/share/flamerobin/images/ddltriggers_16x16.bmp"
10:12:06 AM: Debug: Trying to load image file
"/usr/share/flamerobin/images/dmltrigger_16x16.png"
10:12:06 AM: Debug: Trying to load image file
"/usr/share/flamerobin/images/dmltrigger_16x16.xpm"
10:12:06 AM: Debug: Trying to load image file
"/usr/share/fl

Bug#1021187: gnome-keyring: /usr/bin/gnome-keyring-daemon --daemonize --login 100% CPU usage

[Elmar Ludwig]

Just for the record:

This issue has been reported upstream today in the GNOME gitlab:

https://gitlab.gnome.org/GNOME/glib/-/issues/2795

confirming that a change in glib-2.74.1 caused the breakage.
So, I guess this bug should be reassigned to glib2.0?

Bug#1021187: gnome-keyring: /usr/bin/gnome-keyring-daemon --daemonize --login 100% CPU usage

[Elmar Ludwig]

I am seeing the same issue on my laptop with debian testing (bookworm/sid).

Downgrading all installed packages from src:glib2.0 to version 2.74.0-1 fixes
the issue for me. Since the last update of gnome-keyring was several months
ago and glib2.0 2.74.0-2 migrated to testing on 03 Oct 2022, I suspect some
recent change in glib2.0 triggered this.

I briefly looked a the top frames of the stuck process in gdb and all of them
were in glib2 and glibc. I see randomly (I guess depending on timing) one of
these backtraces:

0x7f89d2441614 in g_source_ref (source=source@entry=0x55af7fb2d400) at 
../../../glib/gmain.c:2285
Download failed: Invalid argument.  Continuing without source file 
./debian/build/deb/../../../glib/gmain.c.
2285../../../glib/gmain.c: No such file or directory.
(gdb) bt
#0  0x7f89d2441614 in g_source_ref (source=source@entry=0x55af7fb2d400) at 
../../../glib/gmain.c:2285
#1  0x7f89d2441700 in g_source_iter_next (iter=iter@entry=0x7ffeec1e7950, 
source=source@entry=0x7ffeec1e7948) at ../../../glib/gmain.c:1121
#2  0x7f89d2442d9b in g_main_context_prepare 
(context=context@entry=0x55af7fb10de0, priority=priority@entry=0x7ffeec1e79d0) 
at ../../../glib/gmain.c:3738
#3  0x7f89d2443873 in g_main_context_iterate (context=0x55af7fb10de0, 
block=block@entry=1, dispatch=dispatch@entry=1, self=) at 
../../../glib/gmain.c:4218
#4  0x7f89d2443c7f in g_main_loop_run (loop=0x55af7fb10ed0) at 
../../../glib/gmain.c:4438
#5  0x55af7ef850c5 in main (argc=, argv=) at 
daemon/gkd-main.c:1166

0x7f89d1efe32f in poll () from /lib/x86_64-linux-gnu/libc.so.6
(gdb) bt
#0  0x7f89d1efe32f in poll () from /lib/x86_64-linux-gnu/libc.so.6
#1  0x7f89d244393e in g_main_context_poll (priority=, 
n_fds=2, fds=0x55af7fb2b760, timeout=, context=0x55af7fb10de0) 
at ../../../glib/gmain.c:4543
#2  g_main_context_iterate (context=0x55af7fb10de0, block=block@entry=1, 
dispatch=dispatch@entry=1, self=) at ../../../glib/gmain.c:4233
#3  0x7f89d2443c7f in g_main_loop_run (loop=0x55af7fb10ed0) at 
../../../glib/gmain.c:4438
#4  0x55af7ef850c5 in main (argc=, argv=) at 
daemon/gkd-main.c:1166

Bug#1010749: sagemath: crash on startup with locale de_DE@euro

[Elmar]

Package: sagemath
Version: 9.5-4
Severity: normal
X-Debbugs-Cc: e220...@wolke7.net

Dear Maintainer,

sage crashes on startup from a terminal with locale de_DE@euro:

> sage  
SageMath version 9.5, Release Date: 2022-01-30
Speicherzugriffsfehler


(Speicherzugriffsfehler means segmentation fault.)

sage used to work with locale de_DE@euro before the upgrade to 9.5.

Kind regards,
Elmar

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

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

Versions of packages sagemath depends on:
ii  python3   3.10.4-1+b1
ii  python3-sage  9.5-4

Versions of packages sagemath recommends:
ii  sagemath-doc9.5-4
ii  sagemath-jupyter9.5-4
ii  sagetex 3.6+ds-2
ii  texlive-latex-base  2021.20220204-1

Versions of packages sagemath suggests:
pn  dot2tex  
pn  gap-design   
ii  gap-factint  1.6.3+ds-1
pn  gap-grape
pn  gap-guava
pn  gap-laguna   
pn  gap-sonata   
pn  gap-toric

-- no debconf information

Bug#1000378: telnetd: post-installation error

[Elmar Haneke]

Package: telnetd
Version: 0.17-43
Severity: grave
Justification: renders package unusable

Dear Maintainer,

package does report error on install:


aptitude install telnetd
Die folgenden NEUEN Pakete werden zusätzlich installiert:
  telnetd
0 Pakete aktualisiert, 1 zusätzlich installiert, 0 werden entfernt und 0 nicht
aktualisiert.
0 B/46,0 kB an Archiven müssen heruntergeladen werden. Nach dem Entpacken
werden 116 kB zusätzlich belegt sein.
Vormals nicht ausgewähltes Paket telnetd wird gewählt.
(Lese Datenbank ... 743851 Dateien und Verzeichnisse sind derzeit installiert.)
Vorbereitung zum Entpacken von .../telnetd_0.17-43_amd64.deb ...
Entpacken von telnetd (0.17-43) ...
telnetd (0.17-43) wird eingerichtet ...
Benutzer telnetd wird zur Gruppe utmp hinzugefügt.
chown: Zugriff auf '/usr/lib/telnetlogin' nicht möglich: Datei oder Verzeichnis
nicht gefunden
dpkg: Fehler beim Bearbeiten des Paketes telnetd (--configure):
 »installiertes telnetd-Skript des Paketes post-installation«-Unterprozess gab
den Fehlerwert 1 zurück
Trigger für man-db (2.9.4-2) werden verarbeitet ...
Fehler traten auf beim Bearbeiten von:
 telnetd
E: Sub-process /usr/bin/dpkg returned an error code (1)
telnetd (0.17-43) wird eingerichtet ...
chown: Zugriff auf '/usr/lib/telnetlogin' nicht möglich: Datei oder Verzeichnis
nicht gefunden
dpkg: Fehler beim Bearbeiten des Paketes telnetd (--configure):
 »installiertes telnetd-Skript des Paketes post-installation«-Unterprozess gab
den Fehlerwert 1 zurück
Fehler traten auf beim Bearbeiten von:
 telnetd



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

Kernel: Linux 5.14.0-4-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=de_DE.utf-8, LC_CTYPE=de_DE.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 telnetd depends on:
ii  adduser   3.118
ii  libc6 2.32-4
ii  openbsd-inetd [inet-superserver]  0.20160825-5
ii  passwd1:4.8.1-2

telnetd recommends no packages.

telnetd suggests no packages.

-- no debconf information

Bug#941993: cheese: Pixart Imaging, Inc. Typhoon Easycam USB 330K does no more work with cheese

[Elmar Stellnberger]

I know now why it does work with OpenSUSE but not with Debian:

GStreamer is compiled without libv4l2 code by default. Something that 
could be changed easily: 
https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/issues/644

Bug#981588: linux-image-5.10.0-2-amd64: Using pen crashes system

[Elmar]

Package: linux-image-5.10.0-2-amd64
Severity: important
X-Debbugs-Cc: e...@wolke7.net

Dear Maintainer,

after installation of linux-image-5.10.0-2-amd64 (5.10.9-1) on a Lenovo X1 Yoga 
Gen5
touching the screen with the pen immediately crashes the system immediately and 
completely.

It seems that there are no related messages in /var/log/kern.log, 
/var/log/syslog,
/var/log/messages or via journalctl.

Downgrading to linux-image-5.10.0-1-amd64 (5.10.4-1) solves the problem.

Same bug as(???) https://bugs.archlinux.org/task/69375

Kind regards,
Elmar

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

Kernel: Linux 5.10.0-1-amd64 (SMP w/8 CPU threads)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) (ignored: LC_ALL set to C), 
LANGUAGE=de
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages linux-image-5.10.0-2-amd64 depends on:
ii  initramfs-tools [linux-initramfs-tool]  0.139
ii  kmod28-1
ii  linux-base  4.6

Versions of packages linux-image-5.10.0-2-amd64 recommends:
ii  apparmor 2.13.6-7
ii  firmware-linux-free  20200122-1

Versions of packages linux-image-5.10.0-2-amd64 suggests:
pn  debian-kernel-handbook  
ii  grub-pc 2.04-12
pn  linux-doc-5.10  

Bug#944295: thunderbird: Spellcheck fixed to "English (United States)"

[Elmar Haneke]

Hello Carsten,

> Mozilla has changed how Add-Ons are now recognized and integrated with
> Thunderbird 68.
> Currently the old way how we can avoid the required installation of the
> spellchecking Add-Ons isn't working anymore. You will now need to
> install the German spell checking Add-On manually.
>
> https://addons.thunderbird.net/de/thunderbird/addon/german-dictionary/


This link did help.

But, the link inegrated into program do download additional languages
does direct to an old languagepack that is no longer working.

Bug#944295: thunderbird: Spellcheck fixed to "English (United States)"

[Elmar Haneke]

Package: thunderbird
Version: 1:68.2.1-1
Severity: normal

Dear Maintainer,

The Selection box to choose language for spellcheck does offer "English (United
states)" only.

On Add-On-Languages-Pages the only package installed is "Deutsch (DE)"




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

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

Versions of packages thunderbird depends on:
ii  debianutils   4.9
ii  fontconfig2.13.1-2+b1
ii  libatk1.0-0   2.34.1-1
ii  libc6 2.29-3
ii  libcairo-gobject2 1.16.0-4
ii  libcairo2 1.16.0-4
ii  libdbus-1-3   1.12.16-2
ii  libdbus-glib-1-2  0.110-4
ii  libevent-2.1-62.1.8-stable-4
ii  libffi6   3.2.1-9
ii  libfontconfig12.13.1-2+b1
ii  libfreetype6  2.10.1-2
ii  libgcc1   1:9.2.1-17
ii  libgdk-pixbuf2.0-02.40.0+dfsg-1
ii  libglib2.0-0  2.62.2-3
ii  libgtk-3-03.24.12-1
ii  libgtk2.0-0   2.24.32-4
ii  libicu63  63.2-2
ii  libjsoncpp1   1.7.4-3+b1
ii  libnspr4  2:4.23-1
ii  libnss3   2:3.47-1
ii  libpango-1.0-01.42.4-7
ii  libsqlite3-0  3.30.1-1
ii  libstartup-notification0  0.12-6
ii  libstdc++69.2.1-17
ii  libvpx6   1.8.1-dmo1
ii  libx11-6  2:1.6.8-1
ii  libx11-xcb1   2:1.6.8-1
ii  libxcb-shm0   1.13.1-2
ii  libxcb1   1.13.1-2
ii  libxext6  2:1.3.3-1+b2
ii  libxrender1   1:0.9.10-1
ii  libxt61:1.1.5-1+b3
ii  psmisc23.2-1+b1
ii  x11-utils 7.7+4
ii  zlib1g1:1.2.11.dfsg-1+b1

Versions of packages thunderbird recommends:
ii  hunspell-de-de [hunspell-dictionary]  20161207-7
ii  hunspell-en-us [hunspell-dictionary]  1:2018.04.16-1
ii  lightning 1:68.2.1-1

Versions of packages thunderbird suggests:
ii  apparmor  2.13.3-6
ii  fonts-lyx 2.3.3-2
ii  libgssapi-krb5-2  1.17-6

-- no debconf information

Bug#941993: common libraries these programs depend on

[Elmar Stellnberger]

  Today I have written a program to filter out common library 
dependencies of the three programs exposing this bug, i.e. cheese, vlc 
and firefox-esr. For one library depending upon another only the top 
level dependency is outputted:


elm@system76-18:~/projects/pydeps$ ./fetchupd.py commdep cheese vlc
common dependencies:
 libasound2-data all
 libevdev2 amd64
 libblkid1 amd64
 libaa1 amd64
 libdrm-common all
 libasound2 amd64
 libmtdev1 amd64
 libmount1 amd64
 libaom0 amd64
 libinput10 amd64
 libdrm2 amd64
 libglib2.0-0 amd64
 libgcc1 amd64
 libass9 amd64
 libvorbisfile3 amd64
 libc6 amd64
 libgpm2 amd64
elm@system76-18:~/projects/pydeps$ ./fetchupd.py commdep cheese firefox-esr
common dependencies:
 libncursesw6 amd64
 libatk1.0-0 amd64
 libasound2-data all
 libasound2 amd64
 libice6 amd64
 lsb-base all
 x11-common all
 libncurses6 amd64
 libatk1.0-data all
 libc6 amd64
 libgcc1 amd64
elm@system76-18:~/projects/pydeps$ ./fetchupd.py commdep vlc firefox-esr
common dependencies:
 libwayland-client0 amd64
 libdbus-1-3 amd64
 libsystemd0 amd64
 xkb-data all
 libxkbcommon0 amd64
 libgcc1 amd64
 libxcb-util0 amd64
 libc6 amd64
elm@system76-18:~/projects/pydeps$ ./fetchupd.py commdep vlc firefox-esr 
cheese

common dependencies:
 libdbus-1-3 amd64
 libxkbcommon0 amd64
 libgcc1 amd64
 libwayland-client0 amd64
 xkb-data all
 libc6 amd64
 libsystemd0 amd64
elm@system76-18:~/projects/pydeps$ ./fetchupd.py commdep cheese guvcview
common dependencies:
 libcap2 amd64
 libasound2-data all
 libavcodec58 amd64
 libaom0 amd64
 libusb-1.0-0 amd64
 libc6 amd64
 libgcc1 amd64
 libatk1.0-0 amd64
 libogg0 amd64
 libasound2 amd64
 libatk1.0-data all

  However I still do not know which library is causing the fault. A 
possible candidate would be libaom0 which implements an internet video 
codec. However I would suppose that the hardware uses a different 
protocol. Additionally libaom0 and libatk1.0 are also used by guvcview 
which works well. I do not know whether libinput10 only implements input 
devices like mice and keyboards or whether things like webcams are also 
supported. Another possible candidate would be libatk1.0. Unfortunately 
I do not really know what these libraries do or whether the bug is 
evoked by a totally different component. Only you, the developers or 
maintainers of cheese will know so please have a look and tell me about it!





#!/usr/bin/python3
# -*- coding: utf-8
# vim: expandtab;

import gzip, bz2, lzma, urllib.request, urllib.error, hashlib;
from itertools import count; from functools import reduce;
import sys, os, re;

repos = [ ("http://security.debian.org/debian-security";, "stable/updates", ["main"] ),
  ("http://deb.debian.org/debian";, "stable", ["main"] ) ];
agent="apt";
architectures=["amd64"];
blocksize=8192;
max_retries=3;
doCache = True; dryRun = False; topOnly = False;

def get_file(url):
  headers = { 'User-Agent': agent }
  req = urllib.request.Request(url, headers = headers)
  resp = urllib.request.urlopen(req)
  return resp;

def get_file_content_cached(url):
  cachefile = url.translate({ord(c):'_' for c in ":/"})+".cache" 
  try:
with open(cachefile,'rb') as rfd:
  return rfd.read();
  except Exception as ex:
data = get_file(url).read();
try:
  with open(cachefile,'wb') as wfd:
wfd.write(data);
except Exception as ex:
  print(ex);
return data;

def print_urllib_error(url,e):
  if type(e) == urllib.error.URLError:
print("error downloading %s: %s" % ( url, e.reason.strerror ), file=sys.stderr );
  elif type(e) == urllib.error.HTTPError:
print("error downloading %s: %i %s" % ( url, e.code, e.msg ), file=sys.stderr );
  else:
print("unknown error downloading %s: %s" % ( url, str(e) ), file=sys.stderr );
  sys.exit(2);

def get_file_content(url):
  try:
if doCache: return get_file_content_cached(url);
return get_file(url).read();
  except Exception as e:
print_urllib_error(url,e);

def save_file(url,filename):
  try:
resp = get_file(url);
h = hashlib.sha256();
with open(filename,'wb') as wfd:
  block = resp.read(blocksize);
  while block:
wfd.write(block);
h.update(block);
block = resp.read(blocksize);
return h.hexdigest();
  except Exception as e:
print_urllib_error(url,e);

def find(elm,lis):
  i = 0;
  for e in lis:
if e == elm: return i;
i += 1;
  return i;

def sgn(val):
  return -1 if val < 0 else ( 1  if val > 0 else 0 );

hash_prefs = ['SHA512','SHA384','SHA256','SHA224','SHA1','MD5'];
good_hash_prefs = 3;

def get_hash(content,hashtype):
  if hashtype=='SHA256':
h = hashlib.sha256();
  elif hashtype=='SHA512':
h = hashlib.sha512();
  elif hashtype=='MD5SUM' or hashtype=='MD5':
h = hashlib.md5();
  elif hashtype=='SHA1':
h = hashlib.sha1();
  elif hashtype=='SHA384':
h = hashlib.sha384();
  elif hashtype=='SHA224':
h = hashlib.sha224();
  else:
raise Exception("hash of type %s unknown!" % hashtype);
  h.update(conten

Bug#941993: cheese works with current openSUSE

[Elmar Stellnberger]

Today I have tested the same webcam also with cheese but on openSUSE 
Leap 15.1 - and look there it works without any problems. Probably some 
of the libraries of Debian 10 are causing the issue. In order to give 
you the possibility to find out about it I have attached all packages 
installed under openSUSE Leap 15.1 as well as their version numbers (rpm 
-qa).
python3-pyparsing-2.2.0-lp151.2.1.noarch
plymouth-scripts-0.9.4+git20190304.ed9f201-lp151.2.3.1.x86_64
Mesa-libEGL1-18.3.2-lp151.23.3.1.x86_64
wpa_supplicant-2.6-lp151.4.4.x86_64
liboggkate1-0.4.1-lp151.3.3.x86_64
libntfs-3g87-2016.2.22-lp151.3.2.x86_64
libxfce4ui-tools-4.12.1-lp151.3.4.x86_64
firewall-macros-0.5.5-lp151.5.1.noarch
yast2-alternatives-4.0.0-lp151.2.2.x86_64
libsoup-2_4-1-2.62.2-lp151.3.1.x86_64
pigz-2.3.3-lp151.2.3.x86_64
libyui-ncurses-pkg9-2.48.9-lp151.1.4.x86_64
libp11-kit0-0.23.2-lp151.3.3.x86_64
libclastfm0-0.5-lp151.2.3.x86_64
NetworkManager-lang-1.10.6-lp151.8.1.noarch
libreoffice-branding-openSUSE-15.1-lp151.2.2.noarch
tigervnc-1.9.0-lp151.3.2.x86_64
grub2-2.02-lp151.21.6.1.x86_64
libfreehand-0_1-1-0.1.2-lp151.2.4.x86_64
ghostscript-9.27-lp151.3.6.1.x86_64
showfont-1.0.5-lp151.2.3.x86_64
libharfbuzz-icu0-1.7.5-lp151.2.3.x86_64
xfce4-screenshooter-lang-1.9.5-lp151.1.1.noarch
translation-update-15.1-lp151.3.1.noarch
python3-pyasn1-0.4.2-lp151.2.2.noarch
openSUSE-xfce-icon-theme-4.12.0-lp151.8.3.noarch
libcdio_cdda2-10.2+0.93+1-lp151.2.3.x86_64
polkit-default-privs-13.2-lp151.16.6.1.noarch
libavahi-glib1-0.7-lp151.1.1.x86_64
libgpgmepp6-1.10.0-lp151.4.1.x86_64
patterns-base-enhanced_base-20171206-lp151.29.1.x86_64
tagsoup-1.2.1-lp151.2.43.noarch
perl-Net-SSLeay-1.81-lp151.2.4.x86_64
apparmor-utils-2.12.3-lp151.4.3.1.noarch
libabw-0_1-1-0.1.2-lp151.2.3.x86_64
accountsservice-0.6.45-lp151.5.1.x86_64
libbs2b0-3.1.0-lp151.2.3.x86_64
ftinspect-2.9-lp151.3.5.x86_64
xfce4-panel-plugin-pulseaudio-0.4.1-lp151.1.1.x86_64
myspell-de_DE-20190423-lp151.2.3.1.noarch
libevent-2_1-8-2.1.8-lp151.3.3.x86_64
gvfs-backend-afc-1.34.2.1-lp151.6.3.1.x86_64
libprocps6-3.3.12-lp151.5.3.x86_64
alsa-plugins-pulse-1.1.5-lp151.2.3.x86_64
libxcb-xfixes0-1.13-lp151.3.2.x86_64
gio-branding-openSUSE-42.1-lp151.4.2.noarch
xfdesktop-lang-4.12.4-lp151.4.3.1.noarch
perl-base-5.26.1-lp151.8.37.x86_64
findutils-4.6.0-lp151.3.71.x86_64
libxfsm-4_6-0-4.12.1-lp151.6.1.x86_64
perl-Encode-Locale-1.05-lp151.2.1.noarch
cups-filters-1.20.3-lp151.3.3.1.x86_64
libv4l1-0-1.14.1-lp151.2.5.x86_64
mlocate-lang-0.26-lp151.5.1.noarch
libcogl20-1.22.2-lp151.3.6.x86_64
libtwolame0-0.3.13-lp151.2.3.x86_64
hunspell-1.6.2-lp151.2.4.x86_64
xscreensaver-data-5.37-lp151.4.3.x86_64
ftgamma-2.9-lp151.3.5.x86_64
libMagickWand-7_Q16HDRI6-7.0.7.34-lp151.7.9.1.x86_64
libboost_filesystem1_66_0-1.66.0-lp151.4.5.x86_64
libgsf-1-114-1.14.42-lp151.3.5.x86_64
libgnome-desktop-3-12-3.26.2-lp151.3.3.x86_64
libsasl2-3-2.1.26-lp151.5.1.x86_64
xkeyboard-config-2.23.1-lp151.3.2.noarch
gtk3-immodule-amharic-3.22.30-lp151.6.6.1.x86_64
beforelight-1.0.5-lp151.2.2.x86_64
yast2-scanner-4.1.0-lp151.1.1.x86_64
libglvnd-1.0.0-lp151.2.3.x86_64
tumbler-lang-0.2.3-lp151.1.1.noarch
libopenjp2-7-2.3.0-lp151.2.3.x86_64
etags-25.3-lp151.3.60.x86_64
MozillaThunderbird-translations-common-68.1.1-lp151.2.13.1.x86_64
libass9-0.14.0-lp151.2.3.x86_64
xterm-330-lp151.3.3.x86_64
libGLU1-9.0.0-lp151.2.3.x86_64
libcupsppdc1-2.2.7-lp151.5.2.x86_64
libmms0-0.6.4-lp151.2.3.x86_64
systemd-presets-branding-openSUSE-12.2-lp151.13.2.noarch
xdg-user-dirs-gtk-0.10-lp151.2.3.x86_64
libfltk1-1.3.4-lp151.3.5.x86_64
google-opensans-fonts-1.0-lp151.2.1.noarch
libXp6-1.0.3-lp151.2.3.x86_64
typelib-1_0-Atk-1_0-2.26.1-lp151.3.4.x86_64
libjansson4-2.9-lp151.2.3.x86_64
perl-XML-Parser-2.44-lp151.2.13.x86_64
libdbusmenu-gtk3-4-16.04.0-lp151.3.2.x86_64
xcalc-1.0.6-lp151.2.3.x86_64
adobe-sourcecodepro-fonts-2.030-lp151.2.1.noarch
xev-1.2.2-lp151.2.2.x86_64
python3-gobject-cairo-3.26.1-lp151.2.3.x86_64
libfuse2-2.9.7-lp151.3.28.x86_64
perl-XML-SAX-Expat-0.51-lp151.2.1.noarch
xreader-backends-1.6.2-lp151.2.3.x86_64
plymouth-plugin-label-ft-0.9.4+git20190304.ed9f201-lp151.2.3.1.x86_64
xorg-x11-fonts-core-7.6-lp151.3.1.noarch
dialog-1.3-lp151.3.3.x86_64
libibus-1_0-5-1.5.19-lp151.2.3.1.x86_64
libdaemon0-0.14-lp151.2.2.x86_64
libssh4-0.8.7-lp151.2.3.1.x86_64
libnma0-1.8.10-lp151.4.6.x86_64
libSDL-1_2-0-1.2.15-lp151.3.1.x86_64
xorg-x11-fonts-7.6-lp151.3.1.noarch
liblzma5-5.2.3-lp151.4.3.1.x86_64
libsamdb0-4.9.5+git.187.71edee57d5a-lp151.2.6.1.x86_64
libasound2-1.1.5-lp151.7.4.x86_64
ucode-amd-20190618-lp151.2.6.1.noarch
libcanberra-gtk2-module-0.30-lp151.2.3.x86_64
coreutils-8.29-lp151.3.3.x86_64
xf86-input-joystick-1.6.3-lp151.2.4.x86_64
libobjc4-7.4.1+r270528-lp151.2.3.1.x86_64
udev-234-lp151.25.7.x86_64
dmidecode-3.2-lp151.3.1.x86_64
libcurl4-7.60.0-lp151.5.6.1.x86_64
pk-update-icon-lang-2-lp151.2.3.noarch
ca-certificates-mozilla-2.34-lp151.2.3.1.noarch
libgstrtsp-1_0-0-1.12.5-lp151.2.4.x86_64
libdrm_nouveau2-2.4.97-lp151.2.3.1.x86_64
audit-2.8.1-lp151.4.4

Bug#942365: libgtk2-perl: Package uninstallable

[Elmar Haneke]

Source: libgtk2-perl
Severity: important

Dear Maintainer,

package uninstallable due to dependency version problem:


apt-get install libgtk2-perl
Paketlisten werden gelesen... Fertig
Abhängigkeitsbaum wird aufgebaut.   
Statusinformationen werden eingelesen Fertig
Einige Pakete konnten nicht installiert werden. Das kann bedeuten, dass
Sie eine unmögliche Situation angefordert haben oder, wenn Sie die
Unstable-Distribution verwenden, dass einige erforderliche Pakete noch
nicht erstellt wurden oder Incoming noch nicht verlassen haben.
Die folgenden Informationen helfen Ihnen vielleicht, die Situation zu lösen:

Die folgenden Pakete haben unerfüllte Abhängigkeiten:
 libgtk2-perl : Hängt ab von: perlapi-5.28.1 ist aber nicht installierbar
E: Probleme können nicht korrigiert werden, Sie haben zurückgehaltene defekte 
Pakete.

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

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

Bug#941993: cheese: Pixart Imaging, Inc. Typhoon Easycam USB 330K does no more work with cheese

[Elmar Stellnberger]

Package: cheese
Version: 3.31.90-1
Severity: normal

Dear Maintainer,

Since Debian9 cheese can no more view the video output of my Pixart Imaging,
Inc. Typhoon Easycam USB 330K (newer)/Typhoon Easycam USB 2.0. It works with
cheese and Debian8 and also with a recent version of the program guvcview. This
seems to be a library issue as Firefox and VLC have the same problem.



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

Kernel: Linux 5.1.0 (SMP w/8 CPU cores; PREEMPT)
Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=de_AT.UTF-8, LC_CTYPE=de_AT.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to de_AT.UTF-8), LANGUAGE=de:pt_BR (charmap=UTF-8) (ignored: LC_ALL set to 
de_AT.UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages cheese depends on:
ii  cheese-common  3.31.90-1
ii  gnome-video-effects0.4.3-3
ii  libc6  2.28-10
ii  libcanberra-gtk3-0 0.30-7
ii  libcheese-gtk253.31.90-1
ii  libcheese8 3.31.90-1
ii  libclutter-1.0-0   1.26.2+dfsg-10
ii  libclutter-gtk-1.0-0   1.8.4-4
ii  libgdk-pixbuf2.0-0 2.38.1+dfsg-1
ii  libglib2.0-0   2.58.3-2
ii  libgnome-desktop-3-17  3.30.2.1-2
ii  libgstreamer1.0-0  1.14.4-1
ii  libgtk-3-0 3.24.5-1

Versions of packages cheese recommends:
ii  gvfs  1.38.1-5
ii  yelp  3.31.90-1

Versions of packages cheese suggests:
pn  gnome-video-effects-frei0r  

-- no debconf information

Bug#932915: RFS: qcoan/2.0-6

[Elmar Stellnberger]

Hi Adam

  Thanks for the work you have put into qcoan. I hope that we will get 
someone else to have a look at the program soon. I have now added the 
missing dependency for qcoan.


Regards,
Elmar

Am 30.07.19 um 06:16 schrieb Adam Borowski:

On Mon, Jul 29, 2019 at 02:02:58PM +0200, Elmar Stellnberger wrote:

I have now changed something in the dependencies and hope that this will
work better for you.


Alas:
qmake -qt=qt5 qcoan.pro
Project ERROR: Unknown module(s) in QT: core gui widgets

After adding qtbase5-dev, it builds.

But unfortunately, due to hardware problems, I cannot really continue.  All
my machines that both 1. work and 2. are adequate for mucking with gui
stuff, are on a different continent; unless situation improves I won't be
able to review this in quite a while.

Thus, I'm afraid it'd be best to ask someone else for now.


Meow!

Bug#932915: RFS: qcoan/2.0-6

[Elmar Stellnberger]

I have now changed something in the dependencies and hope that this will 
work better for you.


Am 28.07.19 um 02:02 schrieb Adam Borowski:

On Sat, Jul 27, 2019 at 10:00:45AM +0200, Elmar Stellnberger wrote:

This is a strange error. I have tested the package locally on Debian 10 as
well as on Debian 8 and Debian 9 via the OpenSuSE build service.


Well, "Debian 9" is oldstable, while all new packages must go to unstable
(and at most get backported later).  That's a difference of two major
releases (ok, maybe 1.2 releases as to-be-Bullseye is very young, although
it did already see the flurry of post-Buster upload).  No wonder the package
fails to build.


For the obs it tests building the package in a previously empty chroot and
installs only the packages given via the build dependencies.  Consequently
I can exclude that there is some missing dependency.


Also, I see that that OpenSuSE build service uses some hacked up homebrewed
dependency resolution -- it likely has a different behaviour than native
Debian tools, which also may be the culprit.


I´m afraid you will have to research what causes that error message on your
computer.


The official archive requires all packages to be buildable on unstable using
sbuild; pbuilder may also work -- it has different defaults (notably,
doesn't strip alternative build-dependencies) but those don't apply to your
package.

I haven't started the real review yet -- just tried if it builds -- but I
already see that the -dbg package is obsolete; these are built automatically
since quite a while ago.


On Wed, Jul 24, 2019 at 07:02:13PM +0200, Elmar Stellnberger wrote:

   * Package name: qcoan
 Version : 2.0-6



Meow!

Bug#932915: RFS: qcoan/2.0-6

[Elmar Stellnberger]

I have now installed a plain Bullseye chroot with debootstrap, installed 
all packages in build-depends and then run dpkg-buildpackage and see it 
builds without any problem. There needs to be something messed up with 
your build environment. Please have a look!


Am 28.07.19 um 02:02 schrieb Adam Borowski:

On Sat, Jul 27, 2019 at 10:00:45AM +0200, Elmar Stellnberger wrote:

This is a strange error. I have tested the package locally on Debian 10 as
well as on Debian 8 and Debian 9 via the OpenSuSE build service.


Well, "Debian 9" is oldstable, while all new packages must go to unstable
(and at most get backported later).  That's a difference of two major
releases (ok, maybe 1.2 releases as to-be-Bullseye is very young, although
it did already see the flurry of post-Buster upload).  No wonder the package
fails to build.


For the obs it tests building the package in a previously empty chroot and
installs only the packages given via the build dependencies.  Consequently
I can exclude that there is some missing dependency.


Also, I see that that OpenSuSE build service uses some hacked up homebrewed
dependency resolution -- it likely has a different behaviour than native
Debian tools, which also may be the culprit.


I´m afraid you will have to research what causes that error message on your
computer.


The official archive requires all packages to be buildable on unstable using
sbuild; pbuilder may also work -- it has different defaults (notably,
doesn't strip alternative build-dependencies) but those don't apply to your
package.

I haven't started the real review yet -- just tried if it builds -- but I
already see that the -dbg package is obsolete; these are built automatically
since quite a while ago.


On Wed, Jul 24, 2019 at 07:02:13PM +0200, Elmar Stellnberger wrote:

   * Package name: qcoan
 Version : 2.0-6



Meow!

Bug#932915: RFS: qcoan/2.0-6

[Elmar Stellnberger]

This is a strange error. I have tested the package locally on Debian 10 
as well as on Debian 8 and Debian 9 via the OpenSuSE build service. For 
the obs it tests building the package in a previously empty chroot and 
installs only the packages given via the build dependencies. 
Consequently I can exclude that there is some missing dependency.
I´m afraid you will have to research what causes that error message on 
your computer.


https://build.opensuse.org/package/show/home:estellnb:elstel/qcoan

Regards,
Elmar


Am 27.07.19 um 06:45 schrieb Adam Borowski:

On Wed, Jul 24, 2019 at 07:02:13PM +0200, Elmar Stellnberger wrote:

  * Package name: qcoan
Version : 2.0-6



   Changes since the last upload:

   The package is now available under GPLv3


I'm afraid it fails with:

dh_testroot
rm -f build-qt/* changelog.Debian.gz
dh_clean
  debian/rules build
#find ..  # -> ../SOURCES, ../BUILD/ - .at.bz2 extracted here, current dir, 
../qcoan_2.0-0.dsc, ../qcoan_2.0-0.diff.gz, ../DEBS,
  ../OTHER
qmake qcoan.pro
qmake: could not find a Qt installation of ''
make: *** [debian/rules:23: build] Error 1


Meow!

Bug#933014: ITP: xchroot -- chroot for Xorg with read-only access

[Elmar Stellnberger]

Package: wnpp
Severity: wishlist

 * Package name: xchroot
   Version : 2.3.4-2
   Upstream Author : Elmar Stellnberger
 * URL : https://www.elstel.org/xchroot/
 * License : GPLv3
   Programming Lang: bash
   Description : an extended chroot with features like Xorg-access 
or read-only roots


  xchroot is still one of the most used programs on elstel.org though 
nowadays there are alternatives for chroot with Xorg/X11. However 
xchroot also allows to chroot onto a chroot environment on a read only 
data carrier like a blue ray where temporary writes are stored via aufs 
where the differences can be saved to disk intermediately for later 
chroots. Besides two different methods for chroot with Xorg xchroot 
supports chroot as user via sudo, automounting of directories and 
multiple simultaneous chroots to the same root unmounting only when the 
last user leaves the chroot. sudoers entries can be added and removed 
via xchroot for different users and chroot root directories.

Bug#933012: ITP: confinedrv -- sets up a virtual drive with restricted access rights

[Elmar Stellnberger]

Package: wnpp
Severity: wishlist

 * Package name: confinedrv
   Version : 1.7.7-4
   Upstream Author : Elmar Stellnberger
 * URL : https://www.elstel.org/qemu/
 * License : GPLv3
   Programming Lang: bash
   Description : a script to confine individual partitions to 
read-only or no access


  confinedrv can be used to boot with qemu or similar virtualization 
software into another operating system installed on disk. If you have 
installed multiple operating systems into mutiple partitions you can not 
boot a second OS via qemu because you would need to give full write 
access to the same disk. However if the whole disk is accessed by two 
operating system instances in parallel that will cause disk corruption 
because there is no synchronization of these accesses. The solution 
confinedrv provides is to make the OS partition read write and all other 
partitions read-only so that they can not be written to and thereby 
possibly corrupted. Of course the OS partition must not be mounted by 
the host OS. You can also exclude read access for given partitions which 
will however still be visible in the partition table. confinedrv uses 
dmsetup and losetup internally to control access via device mapper. The 
partitions need to be aligned by the page size (usually 4096 Bytes) to 
make this work. However for modern SSDs this is the case by default.

Bug#933008: ITP: qcoan - a GUI for simulating non-deterministic FAs, PDAs and Turing machines

[Elmar Stellnberger]

Package: wnpp
Severity: wishlist
Owner: Elmar Stellnberer 

 * Package name: qcoan
   Version : 2.0-6
   Upstream Author : Elmar Stellnberger
 * URL : https://www.elstel.org/coan/
 * License : GPLv3
   Programming Lang: C++
   Description : an automata simulation GUI using Qt

Full-fledged automaton simulator which can run finite automata, pushdown 
automata, Turing machines and machine schemata for deterministic and 
non-deterministic automata. It may be used for educational as well as 
possibly also for scientific purposes to test a Turing machine 
constructed on paper. Many proves use Turing machines as model for 
computability. To ease the construction of complicated Turing machines 
you may define machine schemata. Simulating non-deterministic automata 
by showing all possible activations in parallel is also an interesting 
feature that is to my knowledge not supported by similar projects at 
least not for all machines and in a way providing similar oversight.

Bug#932999: ITP: bundsteg - printing with innner margin

[Elmar Stellnberger]

Package: wnpp
Severity: wishlist
Owner: Elmar Stellnberger 

 * Package name: bundsteg
   Version : 1.2-2
   Upstream Author : Elmar Stellnberger
 * URL : https://www.elstel.org/bundsteg/
 * License : GPLv3
   Programming Lang: bash
   Description : add an inner margin to a pdf for printing

Current printer driver dialogues offer to print multiple pages onto one 
which is good for printing presentation slides. However if you select an 
option like this and you need to stick the sheets together afterwards 
there is no space to do so. That is where you can use bundsteg. First 
print/convert the slides to pdf and then apply the bash script bundsteg 
to nup multiple slides onto one page and add a respective margin for 
even and odd pages. bundsteg supports horizontal as well as vertical 
stitching of sheets. It uses some other programs like pdftk, pdfinfo, 
pdfcrop and pdfjam as well as the ghostscript interpreter gs directly.

Bug#932915: RFS: qcoan/2.0-6

[Elmar Stellnberger]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

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

 * Package name: qcoan
   Version : 2.0-6
   Upstream Author : Elmar Stellnberger
 * URL : https://www.elstel.org/coan/
 * License : GPLv3
   Section : devel

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


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


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

  dget -xu 
https://mentors.debian.net/debian/pool/main/q/qcoan/qcoan_2.0-6.dsc


  More information about qcoan can be obtained from 
https://www.elstel.org/coan/.


  Changes since the last upload:

  The package is now available under GPLv3

Regards,
Elmar Stellnberger

Bug#932913: RFS: confinedrv/1.7.7-4

[Elmar Stellnberger]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

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

 * Package name: confinedrv
   Version : 1.7.7-4
   Upstream Author : Elmar Stellnberger
 * URL : https://www.elstel.org/qemu/
 * License : GPLv3
   Section : utils

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


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


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

  dget -xu 
https://mentors.debian.net/debian/pool/main/c/confinedrv/confinedrv_1.7.7-4.dsc


  More information about confinedrv can be obtained from 
https://www.elstel.org/qemu/.


  Changes since the last upload:

  The package is now available under GPLv3

Regards,
Elmar Stellnberger

Bug#932911: RFS: bundsteg/1.2-2

[Elmar Stellnberger]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

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

 * Package name: bundsteg
   Version : 1.2-2
   Upstream Author : Elmar Stellnberger
 * URL : https://www.elstel.org/bundsteg/
 * License : GPLv3
   Section : utils

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


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


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

  dget -xu 
https://mentors.debian.net/debian/pool/main/b/bundsteg/bundsteg_1.2-2.dsc


  More information about bundsteg can be obtained from 
https://www.elstel.org/bundsteg/.


  Changes since the last upload:

  The package is now available under GPLv3

Regards,
Elmar Stellnberger

Bug#932909: RFS: xchroot/2.3.4-2

[Elmar Stellnberger]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

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

 * Package name: xchroot
   Version : 2.3.4-2
   Upstream Author : Elmar Stellnberger
 * URL : https://www.elstel.org/xchroot/
 * License : GPLv3
   Section : x11

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


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


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

  dget -xu 
https://mentors.debian.net/debian/pool/main/x/xchroot/xchroot_2.3.4-2.dsc


  More information about xchroot can be obtained from 
https://www.elstel.org/xchroot/.


  Changes since the last upload:

  The package is now available under GPLv3

Regards,
Elmar Stellnberger

Bug#928064: Acknowledgement (matchbox battery panel: can not view battery state)

[Elmar Stellnberger]

I have just investigated the issue further and found out that matchbox 
still relies on the old /proc/acpi interface in mb-applet-battery.c:


#define ACPI_PREFIX "/proc/acpi"
#define BAT_PREFIX "battery/BAT0"
#define AC_PREFIX "ac_adapter/AC0"
...
f = fopen(ACPI_PREFIX "/" BAT_PREFIX "/info", "r");

However I fear that things are not as easy as to replace /proc/ACPI/... 
with /sys/class/... as I have just noticed that the reference is BAT1 
instead of BAT0 on another notebook from me:


cat /sys/class/power_supply/BAT1/status
Full / Discharging
cat /sys/class/power_supply/BAT1/capacity
96 ... means 96% charged
cat /sys/class/power_supply/ADP1/online
1 ... if ac adapter is plugged
0 ... if ac adapter is unplugged

I have also filed an upstream bug at:
https://github.com/coreos/matchbox/issues/744


On 27.04.19 12:09, Debian Bug Tracking System wrote:

Thank you for filing a new Bug report with Debian.

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

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):
  Moray Allan 

If you wish to submit further information on this problem, please
send it to 928...@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.

Bug#928064: matchbox battery panel: can not view battery state

[Elmar Stellnberger]

Package: matchbox
Version: 1:6
Severity: normal

Dear Maintainer,

Matchbox is the ideal desktop environment for my EEEPC 4G. However the battery 
pnael fails to view the battery fill state. This is a problem of matchbox since 
I can retrieve the battery state via sysfs and upower easily:

cat /sys/class/power_supply/BAT0/status
upower -i /org/freedesktop/UPower/devices/battery_BAT0
both work.

Please fix! - or am I still missing a required package?

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

Kernel: Linux 4.19.0-4-686 (SMP w/1 CPU core)
Locale: LANG=de_AT.UTF-8, LC_CTYPE=de_AT.UTF-8 (charmap=UTF-8), 
LANGUAGE=de_AT:de (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages matchbox depends on:
ii  matchbox-common  0.9.1-7
ii  matchbox-desktop 2.0-6
ii  matchbox-keyboard0.1+svn20080916-12
ii  matchbox-panel   0.9.3-10
ii  matchbox-panel-manager   0.1-8
ii  matchbox-window-manager  1.2-osso21-4

matchbox recommends no packages.

Versions of packages matchbox suggests:
pn  ttf-dejavu  

-- no debconf information

Bug#838344: Acknowledgement (linux-image-4.6.0-1-amd64: allow a patch that makes elder radeon cards UltraHD ready)

[Elmar Stellnberger]

  It is now about two years ago that I have developed a patch to set 
the TMDS frequency for Radeon cards. A similar patch for Nouveau and for 
the Windows ATI driver does already exist. The patch has been proven to 
work well in the long term at least with the Radeon R5 230 and the 
Radeon HD 6570. Other people have given positive reports as well (Radeon 
HD 6970, Radeon HD 6770, see: 
https://bugs.freedesktop.org/show_bug.cgi?id=93885#c24) though not as 
extensively as John Reinhard with the HD 6570.
  Many cards do not show heat issues at all when overclocking the TMDS. 
- and even if a card did Nouveau developers have told me that it would 
hardly be possible to damage a card with this. The reason why Radeon 
developers did not want to assimilate it seems to be business interest 
as they have told me frankly. The patch is safe and has been proven 
useful (since then many people with positive experience have linked to 
my site) - so why do we not include it for Debian?

Bug#916406: libarb-dev: Missing symbols in static libraries

[Elmar]

Package: libarb-dev
Version: 6.0.6-4
Severity: important
Tags: patch

Somehow all symbols have been wiped from the static libraries, making them
useless.

nm /usr/lib/arb/SL/HELIX/HELIX.a
nm: /usr/lib/arb/SL/HELIX/HELIX.a: no symbols






-- System Information:
Debian Release: buster/sid
  APT prefers bionic-updates
  APT policy: (500, 'bionic-updates'), (500, 'bionic-security'), (500, 
'bionic'), (100, 'bionic-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages libarb-dev depends on:
ii  libarb  6.0.6-4

libarb-dev recommends no packages.

libarb-dev suggests no packages.

-- no debconf information

Bug#913488: [pkg-gnupg-maint] Bug#913488: scdaemon: gnupg --card-status does not recognize smart card via usb reader

[Elmar Stellnberger]

On 12.11.18 11:52, Daniel Kahn Gillmor wrote:

Hi Elmar--

On Sun 2018-11-11 15:54:42 +0100, Elmar Stellnberger wrote:

The problem is that gnupg does not recognize my gpg-card if I insert it
via the Gemalto PC-card reader; if I use the integrated reader it works.
The problem only occurs with Debian GNU Linux 9. The USB reader still
works well with Debian GNU Linux 8; i.e. this is a regression. It is not
the way that gnupg always fails to recognize my gpg card via the USB
reader; sometimes it works; sometimes it does not.


Thanks for the report.  I'm hoping that gniibe (cc'ed) can shed more
light on this by asking you for clearer debugging info.  He's our
strongest expert on this stuff.

It looks from your debugging output like you're intermixing scdaemon
with pcsclite or possibly pcscd.  It's possible that two daemons are in
contention for the device.  Can you tell whether that might be the case
on your system?

--dkg



Now I have removed pcscd with apt-get remove and see it works now on my 
Debian 9 machine. Strangely on my Debian 8 machine pcscd is of version 
1.8.13-1 while no scdaemon is installed. Nonetheless I remember gpg 
--card-status always having worked on my Debian 8 machine.

Bug#913488: scdaemon: gnupg --card-status does not recognize smart card via usb reader

[Elmar Stellnberger]

Package: scdaemon
Version: 2.1.18-8~deb9u3
Severity: important

Dear Maintainer,

The problem is that gnupg does not recognize my gpg-card if I insert it 
via the Gemalto PC-card reader; if I use the integrated reader it works.
The problem only occurs with Debian GNU Linux 9. The USB reader still 
works well with Debian GNU Linux 8; i.e. this is a regression. It is not 
the way that gnupg always fails to recognize my gpg card via the USB 
reader; sometimes it works; sometimes it does not.


$ gpg --card-status
gpg: selecting openpgp failed: Kein passendes Gerät gefunden
gpg: OpenPGP card not available: Kein passendes Gerät gefunden
>> translation of the message: no fitting device found

$ pcsc_scan
PC/SC device scanner 

V 1.4.27 (c) 2001-2011, Ludovic Rousseau  

Compiled with PC/SC lite version: 1.8.17 

Using reader plug'n play mechanism 

Scanning present readers... 

0: O2 Micro Oz776 00 00 

1: Gemalto PC Twin Reader 01 00 





Sun Nov 11 15:02:08 2018 

Reader 0: O2 Micro Oz776 00 00 

  Card state: Card removed, 



Reader 1: Gemalto PC Twin Reader 01 00 

  Card state: Card inserted, 



  ATR: 3B DA 18 FF 81 B1 FE 75 1F 03 00 31 C5 73 C0 01 40 00 90 00 0C 




ATR: 3B DA 18 FF 81 B1 FE 75 1F 03 00 31 C5 73 C0 01 40 00 90 00 0C
+ TS = 3B --> Direct Convention
+ T0 = DA, Y(1): 1101, K: 10 (historical bytes)
  TA(1) = 18 --> Fi=372, Di=12, 31 cycles/ETU
129032 bits/s at 4 MHz, fMax for Fi = 5 MHz => 161290 bits/s
  TC(1) = FF --> Extra guard time: 255 (special value)
  TD(1) = 81 --> Y(i+1) = 1000, Protocol T = 1
-
  TD(2) = B1 --> Y(i+1) = 1011, Protocol T = 1
-
  TA(3) = FE --> IFSC: 254
  TB(3) = 75 --> Block Waiting Integer: 7 - Character Waiting Integer: 5
  TD(3) = 1F --> Y(i+1) = 0001, Protocol T = 15 - Global interface 
bytes following

-
  TA(4) = 03 --> Clock stop: not supported - Class accepted by the 
card: (3G) A 5V B 3V

+ Historical bytes: 00 31 C5 73 C0 01 40 00 90 00
  Category indicator byte: 00 (compact TLV data object)
Tag: 3, len: 1 (card service data byte)
  Card service data byte: C5
- Application selection: by full DF name
- Application selection: by partial DF name
- EF.DIR and EF.ATR access services: by GET DATA command
- Card without MF
Tag: 7, len: 3 (card capabilities)
  Selection methods: C0
- DF selection by full DF name
- DF selection by partial DF name
  Data coding byte: 01
- Behaviour of write functions: one-time write
- Value 'FF' for the first byte of BER-TLV tag fields: invalid
- Data unit in quartets: 2
  Command chaining, length fields and logical channels: 40
- Extended Lc and Le fields
- Logical channel number assignment: No logical channel
- Maximum number of logical channels: 1
Mandatory status indicator (3 last bytes)
  LCS (life card cycle): 00 (No information given)
  SW: 9000 (Normal processing.)
+ TCK = 0C (correct checksum)

Possibly identified card (using /usr/share/pcsc/smartcard_list.txt):
3B DA 18 FF 81 B1 FE 75 1F 03 00 31 C5 73 C0 01 40 00 90 00 0C
GnuPG card V2

*** pcsc_scan hangs here.

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

Kernel: Linux 4.19.0-rc2+ (SMP w/4 CPU cores)
Locale: LANG=de_AT.UTF-8, LC_CTYPE=de_AT.UTF-8 (charmap=UTF-8), 
LANGUAGE=de_AT:de (charmap=UTF-8)

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

Versions of packages scdaemon depends on:
ii  gnupg-agent2.1.18-8~deb9u3
ii  libassuan0 2.4.3-2
ii  libc6  2.24-11+deb9u3
ii  libgcrypt201.7.6-2+deb9u3
ii  libgpg-error0  1.26-2
ii  libksba8   1.3.5-2
ii  libnpth0   1.3-1
ii  libusb-1.0-0   2:1.0.21-1

scdaemon recommends no packages.

scdaemon suggests no packages.

-- no debconf information

Bug#886758: New version 1.8.4 available

[Elmar Gerdes]

Any news?  Upstream version contains bugfixes.

On Sun, 21 Jan 2018 08:22:15 +0100 Peter Spiess-Knafl 
 wrote:

I will take care of it.

> Am 09.01.2018 um 16:52 schrieb Yangfl :
> 
> Package: libjsoncpp

> Version: 1.7.4-3
> 
> The current Debian version is outdated. Since I'm packing

> https://github.com/avast-tl/retdec-config which require 1.8.4, it
> would be nice to update it to the current upstream one.
> 
> Thanks,

Bug#906816: thunderbird: Does not start

[Elmar Haneke]

The problem still remains after explicitely disabling apparmor


aa-status  --pretty-json | jq .profiles.thunderbird

results in "null"



Am 21.08.2018 um 18:09 schrieb Carsten Schoenert:
> On Tue, Aug 21, 2018 at 05:11:47PM +0200, Elmar Haneke wrote:
>>> you have installed apparmor, is the apparmor profile for Thunderbird
>>> also active?
>>>
>>> Please have a look at /usr/share/doc/thunderbird/README.apparmor
>> None of these instructions does help clearing that Problem.
> Now I still don't know if the AppArmor profile for Thunderbird is
> active.
>
> You give only poor information how this behaviour could be reproduced.
> Without this it's impossible to solve the issue on your side. Please
> help me to understand what your are doing and what is happen on your
> side.
>
> Putting your small log information into the search engine of my choice
> brings me to https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=887645
>
> So I would bet you have an active AA profile.
>
> Next would be to see what AppArmor is blocking. For this the mentioned
> Readme file is intended for.
>
> Regards
> Carsten
>

-- 
Mit freundlichen Grüßen

Elmar Haneke

===
|Dr. Elmar Haneke   Tel: +49-2241-39749-0 |
|   Fax: +49-2241-39749-30|
|Haneke SoftwareWWW: www.haneke.de|
|Dr. Elmar und Hubertus Haneke  Mail: el...@haneke.de |
|Johannesstraße 41|
|53721 Siegburg USt-IdNr. DE 123387209|
===

Bug#906816: thunderbird: Does not start

[Elmar Haneke]

you have installed apparmor, is the apparmor profile for Thunderbird
also active?

Please have a look at /usr/share/doc/thunderbird/README.apparmor


None of these instructions does help clearing that Problem.

Bug#906816: thunderbird: Does not start

[Elmar Haneke]

Package: thunderbird
Version: 1:60.0-1
Severity: important

Dear Maintainer,

thunderbird does fail to start, yust these errors are printed to console:

ExceptionHandler::GenerateDump cloned child 23947
ExceptionHandler::SendContinueSignalToChild sent continue signal to child
ExceptionHandler::WaitForContinueSignal waiting for continue signal...


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

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

Versions of packages thunderbird depends on:
ii  debianutils   4.8.6
ii  fontconfig2.13.0-5
ii  libatk1.0-0   2.28.1-1
ii  libc6 2.27-5
ii  libcairo-gobject2 1.15.10-3
ii  libcairo2 1.15.10-3
ii  libdbus-1-3   1.12.10-1
ii  libdbus-glib-1-2  0.110-3
ii  libevent-2.1-62.1.8-stable-4
ii  libffi6   3.2.1-8
ii  libfontconfig12.13.0-5
ii  libfreetype6  2.8.1-2
ii  libgcc1   1:8.2.0-4
ii  libgdk-pixbuf2.0-02.36.12-1
ii  libglib2.0-0  2.56.1-2
ii  libgtk-3-03.22.30-2
ii  libgtk2.0-0   2.24.32-2
ii  libhunspell-1.6-0 1.6.2-1+b1
ii  libicu60  60.2-6
ii  libjsoncpp1   1.7.4-3
ii  libnspr4  2:4.19-3
ii  libnss3   2:3.38-1
ii  libpango-1.0-01.42.4-1
ii  libpangocairo-1.0-0   1.42.4-1
ii  libpangoft2-1.0-0 1.42.4-1
ii  libsqlite3-0  3.24.0-1
ii  libstartup-notification0  0.12-5
ii  libstdc++68.2.0-4
ii  libvpx5   1.7.0-3
ii  libx11-6  2:1.6.5-1
ii  libx11-xcb1   2:1.6.5-1
ii  libxcb-shm0   1.13-2
ii  libxcb1   1.13-2
ii  libxext6  2:1.3.3-1+b2
ii  libxrender1   1:0.9.10-1
ii  libxt61:1.1.5-1
ii  psmisc23.1-1+b1
ii  x11-utils 7.7+4
ii  zlib1g1:1.2.11.dfsg-1

Versions of packages thunderbird recommends:
ii  hunspell-de-de [hunspell-dictionary]  20161207-5
ii  hunspell-en-us [hunspell-dictionary]  1:2018.04.16-1
pn  lightning 

Versions of packages thunderbird suggests:
ii  apparmor  2.13-8
ii  fonts-lyx 2.3.0-2
ii  libgssapi-krb5-2  1.16-2

-- no debconf information

Bug#904612: packaging of qcoan fully revised

[Elmar Stellnberger]

The packaging quality of qcoan has been highly improved since my 
original RFS. There are no more lintian errors that should be resolved 
and with the advice from wRAR at #debian-mentors I have improved the 
package internals (no nested .tar.bz2, debian/install list).


see: https://mentors.debian.net/package/qcoan

Bug#904612: RFS: qcoan/2.0-3 [ITP]

[Elmar Stellnberger]

Package: sponsorship-requests
Severity: wishlist


Dear mentors,

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

 * Package name: qcoan
   Version : 2.0-3
   Upstream Author : Elmar Stellnberger estel...@elstel.org
 * URL : https://www.elstel.org/coan/
 * License : C-FSL v1.1
   Section : devel

  It builds those binary packages:

qcoan - Automaton and Turing Machine Simulator

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


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


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

dget -x 
https://mentors.debian.net/debian/pool/main/q/qcoan/qcoan_2.0-3.dsc


  More information about qcoan can be obtained from 
https://www.elstel.org/coan.



Regards,
 Elmar Stellnberger

Bug#893785: python-zeroc-ice: Install fails

[Elmar Haneke]

Package: python-zeroc-ice
Version: 3.7.0-3
Severity: important

Dear Maintainer,

updating installation does fail on configuration packet:

python-zeroc-ice (3.7.0-3) wird eingerichtet ...
  File "/usr/lib/python2.7/dist-packages/Ice/IceFuture.py", line 27
def wrap_future(future, *, loop=None):
 ^
SyntaxError: invalid syntax

dpkg: Fehler beim Bearbeiten des Paketes python-zeroc-ice (--configure):
 installed python-zeroc-ice package post-installation script subprocess 
returned error exit status 101
Fehler traten auf beim Bearbeiten von:
 python-zeroc-ice
E: Sub-process /usr/bin/dpkg returned an error code (1)


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

Kernel: Linux 4.15.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=de_DE.utf-8, LC_CTYPE=de_DE.utf-8 (charmap=UTF-8), LANGUAGE= 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages python-zeroc-ice depends on:
ii  libc62.27-2
ii  libgcc1  1:8-20180321-1
ii  libmcpp0 2.7.2-4+b2
ii  libpython2.7 2.7.14-7
ii  libstdc++6   8-20180321-1
ii  libzeroc-ice3.7  3.7.0-3
ii  python   2.7.14-4

python-zeroc-ice recommends no packages.

python-zeroc-ice suggests no packages.

-- no debconf information

Bug#887985: jdbc

[Elmar Dolgener]

While direct connectors and odbc currently don't work, jdbc remains as a
last resort.

For all companions in misfuture, as there are many details to miss a
successful setup, a short summary:

1) apt-get install oracle-java8-installer
2) Download "mariadb mariadb-connector-j" from
https://mariadb.com/kb/en/library/about-mariadb-connector-j/
3) Run LibreOffice (Base or any other module): open
Tools/Options/LibreOffice/Advanced/Class Path;
4) Add "/your/path/to/mariadb-java-client-2.2.1.jar" (from step 2) as
"file" to the classpath,
5) Select your installed Java version
6) restart LibreOffice

To start a new database file, use:
  URL: jdbc://mariadb://localhost:3306/your_db_name
  driver class:  org.mariadb.jdbc.Driver

To reconnect an existing database file,
1) open it with lobase,
2) select "Edit/Database/Connection type" and enter :
 Database type: [JDBC] (not mysql(JDBC)! )
 Datasource URL: jdbc:mariadb://localhost:3306/your_db_name
 User name:your_db_username
 JDBC driver class: org.mariadb.jdbc.Driver [instead of
"com.mysql.jdbc.Driver"!]

Bug#887985: mysql-connector-linux_4-3_x86_64.oxt not workining properly, too

[Elmar Dolgener]

Hallo again,

sad news from "mysql-connector-linux_4-3_x86_64.oxt", I just run into
the problem, that it is unable to WRITE more than 96 chars into a TEXT
field, either directly using base's table view or via a text control on
a form. Trying so, you'll  get a "HY000 2006" error from mysql
(mariadb). To be sure, I verified the table definition is okay (CREATE
TABLE ...`Pathname` text, ... ).

What leaps to the users eye: 96 = 3 * 32 characters.

This means, that currently there is NO way to work unhamperedly with
Base and mariadb:

* MySQL(natively): garbage or length limitation in TEXT fields

* MySQL(ODBC): base crashes instantaneously as soon as a table (or form)
is opened

* ODBC: base crashes instantaneously as soon as a table (or form) is opened

Bug#882048: [thunderbird] 882048 also affects enigmail

[Elmar Dolgener]

Package: thunderbird

Version: 1:52.5.2-2

--- Please enter the report below this line. ---

Just adding for completeness: Enigmail is affected, too. This is the
case at least during the last three months on sid.

With running apparmor, one gets warnings like +keyError.keyIdNotFound
"Die konfigurierte Schlüssel-ID „%S“ wurde nicht in Ihrem Schlüsselbund
gefunden."

This might _somewhat_ misleading to users.

Only if someone digs into /var/log/messages, one can find " ...
apparmor="DENIED" operation="open" profile="thunderbird//gpg"... "


--- System information. ---

Architecture:

Kernel: Linux 4.14.0-2-amd64

Debian Release: buster/sid

500 xenial ppa.launchpad.net

500 trusty ppa.launchpad.net

500 testing ftp2.de.debian.org

500 testing deb.debian.org

500 stable deb.opera.com

--- Package information. ---

Depends (Version) | Installed

==-+-==

debianutils (>= 1.16) | 4.8.4

fontconfig | 2.12.6-0.1

psmisc | 23.1-1

x11-utils | 7.7+3+b1

libatk1.0-0 (>= 1.12.4) | 2.26.1-2

libc6 (>= 2.17) |

libcairo-gobject2 (>= 1.10.0) |

libcairo2 (>= 1.10.2-2~) |

libdbus-1-3 (>= 1.9.14) |

libdbus-glib-1-2 (>= 0.78) |

libevent-2.1-6 (>= 2.1.8-stable) |

libffi6 (>= 3.0.4) |

libfontconfig1 (>= 2.12) |

libfreetype6 (>= 2.2.1) |

libgcc1 (>= 1:4.0) |

libgdk-pixbuf2.0-0 (>= 2.22.0) |

libglib2.0-0 (>= 2.30.0) |

libgtk-3-0 (>= 3.4) |

libhunspell-1.6-0 |

libpango-1.0-0 (>= 1.14.0) |

libpangocairo-1.0-0 (>= 1.14.0) |

libpangoft2-1.0-0 (>= 1.14.0) |

libpixman-1-0 (>= 0.19.6) |

libstartup-notification0 (>= 0.8) |

libstdc++6 (>= 5.2) |

libvpx4 (>= 1.6.0) |

libx11-6 |

libx11-xcb1 |

libxcb-shm0 |

libxcb1 |

libxcomposite1 (>= 1:0.3-1) |

libxdamage1 (>= 1:1.1) |

libxext6 |

libxfixes3 |

libxrender1 |

libxt6 |

zlib1g (>= 1:1.2.3.4) |

Recommends (Version) | Installed

==-+-===

lightning (= 1:52.5.2-2) | 1:52.5.2-2

myspell-en-us |

OR hunspell-dictionary |

OR myspell-dictionary |

Suggests (Version) | Installed

===-+-===

apparmor | 2.12-1

fonts-lyx | 2.2.3-2

libgssapi-krb5-2 | 1.15.2-2

Bug#887985: [libreoffice-mysql-connector] Garbage starts at position 64!

[Elmar Dolgener]

Package: libreoffice-mysql-connector

Version: 1.0.2


--- Please enter the report below this line. ---


Thanks a lot for the quick response, Rene!


Here is more info:


1) sadly, Packages in
https://people.debian.org/~rene/libreoffice/test/mysql-connector behave
as those in the official repo.


2) "Garbage Text" always seems to start at Position 65 ! Maybe that
hints to the problem's root...


3) Concerning the mysterious v. 1.0.4, there are statements on

 
https://ask.libreoffice.org/en/question/64668/mysqlmariadb-native-driver-for-libreoffice-5/
 https://discussion.dreamhost.com/t/mysql-connector-1-0-4/29479




--- System information. ---

Architecture:

Kernel: Linux 4.14.0-2-amd64


Debian Release: buster/sid

500 xenial ppa.launchpad.net

500 trusty ppa.launchpad.net

500 testing ftp2.de.debian.org

500 testing deb.debian.org

500 stable deb.opera.com


--- Package information. ---

Package's Depends field is empty.


Package's Recommends field is empty.


Package's Suggests field is empty.

Bug#887985: [libreoffice-mysql-connector] using mariadb, libreoffice-mysql-connector produces garbage in memofields

[Elmar Dolgener]

Package: libreoffice-mysql-connector
Severity: grave

--- Please enter the report below this line. ---

Using current versions libreoffice-mysql-connector and mariadb, memo
fields in existing applications made with libreoffice base show garbage
text like this:


This is obviously not a case of wrong charset and renders base forms
totally unusable.
As afaik there is no other comparable desktop database frontend
available on linux, this is a grave obstacle.

If you purge libreoffice-mysql-connector and install
"mysql-connector-linux_4-3_x86_64.oxt" (from
https://extensions.libreoffice.org/extensions/mysql-native-connector)
instead, you get a version "1.0.4_3", which is correctly working with
mariadb also.

Particularly as debian has recently switched from MySQL to mariadb, it
would be necessary to upgrade the connector to a compatible version as
well. Fortunately, they yet exist!


--- System information. ---
Architecture:
Kernel:   Linux 4.14.0-2-amd64

Debian Release: buster/sid
  500 testing ftp2.de.debian.org
  500 testing deb.debian.org
  500 stable  deb.opera.com

--- Package information. ---
Package's Depends field is empty.

Package's Recommends field is empty.

Package's Suggests field is empty.

Bug#880567: rdesktop: Strange colors (Red/Blue switch)

[Elmar Haneke]

Package: rdesktop
Version: 1.8.3-2+b1
Severity: normal

Dear Maintainer,

when connecting (to an Windows-Vista system) with option "-a 16" on the display 
Red and blue are exchanged.
When specifying "-a 24" I do get an warning that an fallback fo 16bpp is done, 
but, colors are correct in that case.
Which "-a 32" colors are also ok - with no warning..

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

   * What led up to the situation?
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?

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


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

Kernel: Linux 4.13.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=de_DE.utf-8, LC_CTYPE=de_DE.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 rdesktop depends on:
ii  libasound21.1.3-5
ii  libc6 2.24-17
ii  libgssglue1   0.4-2+b2
ii  libpcsclite1  1.8.22-1
ii  libssl1.1 1.1.0f-5
ii  libx11-6  2:1.6.4-3
ii  libxrandr22:1.5.1-1

rdesktop recommends no packages.

Versions of packages rdesktop suggests:
ii  pcscd  1.8.22-1

-- no debconf information

Bug#857283: arb-common: broken symlinks: /usr/lib/arb/bin/mafft-*, /etc/arb/inputMasks/format.readme

[Pruesse, Elmar A2]

Hi Andreas,

I'd appreciate if you could just add it. I haven't used that SVN in a long time 
and it'd take a while for me to figure things out again.

Elmar

> On Mar 14, 2017, at 1:10 AM, Andreas Tille  wrote:
> 
> Hi Elmar,
> 
> On Mon, Mar 13, 2017 at 10:52:50PM +, Pruesse, Elmar A2 wrote:
>> FYI: you can disable building those by passing "MAFFTLINKS=" as argument to 
>> make (overrides the variable containing the targets with empty string), or 
>> patching bin/Makefile accordingly.
> 
> Thanks for the hint.  Do you intend to commit the according change to
> SVN yourself?
> 
> BTW, I intend to fix those errors in a post-Stretch-release bugsquashing
> effort since I see no point in making such upload to experimental right
> now.
> 
> Kind regards
> 
>  Andreas.
> 
> -- 
> http://fam-tille.de
> 

Bug#857283: arb-common: broken symlinks: /usr/lib/arb/bin/mafft-*, /etc/arb/inputMasks/format.readme

[Pruesse, Elmar A2]

Hi, 

FYI: you can disable building those by passing "MAFFTLINKS=" as argument to 
make (overrides the variable containing the targets with empty string), or 
patching bin/Makefile accordingly.

Elmar

> On Mar 9, 2017, at 7:38 AM, Andreas Beckmann  wrote:
> 
> Package: arb-common
> Version: 6.0.6-1
> Severity: normal
> User: debian...@lists.debian.org
> Usertags: piuparts
> 
> Hi,
> 
> during a test with piuparts I noticed your package ships (or creates)
> a broken symlink.
> 
>> From the attached log (scroll to the bottom...):
> 
> 2m1.8s ERROR: FAIL: Broken symlinks:
>  /usr/lib/arb/bin/mafft-xinsi -> mafft
>  /usr/lib/arb/bin/mafft-qinsi -> mafft
>  /usr/lib/arb/bin/mafft-nwnsi -> mafft
>  /usr/lib/arb/bin/mafft-nwns -> mafft
>  /usr/lib/arb/bin/mafft-linsi -> mafft
>  /usr/lib/arb/bin/mafft-ginsi -> mafft
>  /usr/lib/arb/bin/mafft-fftnsi -> mafft
>  /usr/lib/arb/bin/mafft-fftns -> mafft
>  /usr/lib/arb/bin/mafft-einsi -> mafft
>  /etc/arb/inputMasks/format.readme -> ../help/input_mask_format.hlp
> 
> There is /usr/lib/arb/lib/help/input_mask_format.hlp ...
> 
> 
> cheers,
> 
> Andreas
> 

Bug#767006: AW: Goodnews

[Kemmer, Elmar]

?


Von: Kemmer, Elmar
Gesendet: Samstag, 15. Oktober 2016 13:40
An: Kemmer, Elmar
Betreff: Goodnews


I, Liliane Donated 2,000,000 Dollars to you, Contact me on ( 
lbettencour...@hotmail.com ) for more details??

Bug#838344: linux-image-4.6.0-1-amd64: allow a patch that makes elder radeon cards UltraHD ready

[Elmar Stellnberger]

Package: src:linux
Version: 4.6.4-1
Severity: wishlist
Tags: patch

Here come the patches.

Am 2016-09-20 um 09:16 schrieb Elmar Stellnberger:

Package: src:linux
Version: 4.6.4-1
Severity: wishlist
Tags: patch

In March I had developed a kernel patch that allows to set the TMDS
frequency for radeon cards by a new kernel parameter called
radeon.hdmimhz if the automatically set frequency stays either behind of
what has been advertised for the card or by what is achievable through
overclocking. A similar parameter for nvidia/nouveau cards is already
available somewhat longer. However up to now the patch has not been
accepted into the mainline kernel simply because radeon developers are
not encouraged to enable this feature for elder cards by the policy of
their sponsors. Here are some of my considerations which you may take
into account when deciding about the acceptance of the patch for Debian
Stretch:

  * the patch is very simple, just a few lines of code
  * behaviour of the kernel is not influenced by the patch except when
the user gives a non-zero value for radeon.hdmimhz
  * the patch has already wheathered time; the surrounding code has more
or less remained unchanged since March
  * long time usage experience is already available at least with the
radeon R5 230 card as well as different monitors; my personal experience
with the patch is very good
  * the patch provides a huge advantage at least for all people who
still use Core 2 based systems:
- elder radeon cards can be made UHD ready
- the R5 230 card supported by the patch may be the only one of its
type that has a single slot height - and it has been sold to me as
DVI-UltraHD ready; however this feature can not be exploited without the
kernel patch
- newer radeon cards are often incompatible with elder Core 2 systems
  * at least nouveau developers say that by overclocking your TMDS it
would rarely be possible to damage a card; a way of proceeding
considered safe can be read in the linked article
(https://www.elstel.org/software/hunt-for-4K-UHD-2160p.html.en ; the
article is no more completely new and it will be updated soon.).

  P.S.: The attached patches are for application at the 4.8.0-rcX
kernels; however the same patch has also proven to work well for
4.6.x/Debian. If you do not want to update 4.6.0-1 then I`d apply for
inclusion of this patch with the adoption of 4.8.0.

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

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

Versions of packages linux-image-4.6.0-1-amd64 depends on:
ii  initramfs-tools [linux-initramfs-tool]  0.125
ii  kmod22-1.1
ii  linux-base  4.4

Versions of packages linux-image-4.6.0-1-amd64 recommends:
ii  firmware-linux-free  3.4
pn  irqbalance   

Versions of packages linux-image-4.6.0-1-amd64 suggests:
pn  debian-kernel-handbook  
ii  grub-pc 2.02~beta2-36
pn  linux-doc-4.6   

Versions of packages linux-image-4.6.0-1-amd64 is related to:
ii  firmware-amd-graphics 20160110-1
ii  firmware-atheros  20160110-1
ii  firmware-bnx2 20160110-1
ii  firmware-bnx2x20160110-1
ii  firmware-brcm8021120160110-1
ii  firmware-cavium   20160110-1
ii  firmware-intel-sound  20160110-1
ii  firmware-intelwimax   20160110-1
ii  firmware-ipw2x00  20160110-1
ii  firmware-ivtv 20160110-1
ii  firmware-iwlwifi  20160110-1
ii  firmware-libertas 20160110-1
pn  firmware-linux-nonfree
ii  firmware-misc-nonfree 20160110-1
ii  firmware-myricom  20160110-1
ii  firmware-netxen   20160110-1
ii  firmware-qlogic   20160110-1
ii  firmware-realtek  20160110-1
ii  firmware-samsung  20160110-1
ii  firmware-siano20160110-1
ii  firmware-ti-connectivity  20160110-1
pn  xen-hypervisor



>From 17245f2ba90fe9242041dd0626a570a8becce5c1 Mon Sep 17 00:00:00 2001
From: Elmar Stellnberger 
Date: Mon, 22 Aug 2016 10:27:53 +0200
Subject: [PATCH] radeon.hdmimhz parameter introduced * proven to work for a
 radeon XFX R5 230 card with radeon.hdmimhz=297   3840x2160@30 is offered
 automatically and can be set successfully   with an AOC u2868pqu as well as
 an iiyama X4071UHSU monitor;   no heat issues in the long term (cooler
 moderately warm after running half a day) * radeon_encoders.c:
 radeon_dig_monitor_is_duallink must always return   false otherwise screen
 stays black for the settings described above

---
 drivers/gpu/drm/radeon/radeon.h|  1 +
 drivers/gpu/drm/radeon/radeon_connectors.c | 16 ++--
 drivers/gpu/drm/radeon/radeon_drv.c|  4 
 drivers/g

Bug#838343: linux-image-4.6.0-1-amd64: allow a patch that makes elder radeon cards UltraHD ready

[Elmar Stellnberger]

Package: src:linux
Version: 4.6.4-1
Severity: wishlist
Tags: patch

In March I had developed a kernel patch that allows to set the TMDS 
frequency for radeon cards by a new kernel parameter called 
radeon.hdmimhz if the automatically set frequency stays either behind of 
what has been advertised for the card or by what is achievable through 
overclocking. A similar parameter for nvidia/nouveau cards is already 
available somewhat longer. However up to now the patch has not been 
accepted into the mainline kernel simply because radeon developers are 
not encouraged to enable this feature for elder cards by the policy of 
their sponsors. Here are some of my considerations which you may take 
into account when deciding about the acceptance of the patch for Debian 
Stretch:


  * the patch is very simple, just a few lines of code
  * behaviour of the kernel is not influenced by the patch except when 
the user gives a non-zero value for radeon.hdmimhz
  * the patch has already wheathered time; the surrounding code has 
more or less remained unchanged since March
  * long time usage experience is already available at least with the 
radeon R5 230 card as well as different monitors; my personal experience 
with the patch is very good
  * the patch provides a huge advantage at least for all people who 
still use Core 2 based systems:

- elder radeon cards can be made UHD ready
- the R5 230 card supported by the patch may be the only one of its 
type that has a single slot height - and it has been sold to me as 
DVI-UltraHD ready; however this feature can not be exploited without the 
kernel patch

- newer radeon cards are often incompatible with elder Core 2 systems
  * at least nouveau developers say that by overclocking your TMDS it 
would rarely be possible to damage a card; a way of proceeding 
considered safe can be read in the linked article 
(https://www.elstel.org/software/hunt-for-4K-UHD-2160p.html.en ; the 
article is no more completely new and it will be updated soon.).


  P.S.: The attached patches are for application at the 4.8.0-rcX 
kernels; however the same patch has also proven to work well for 
4.6.x/Debian. If you do not want to update 4.6.0-1 then I`d apply for 
inclusion of this patch with the adoption of 4.8.0.


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

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

Versions of packages linux-image-4.6.0-1-amd64 depends on:
ii  initramfs-tools [linux-initramfs-tool]  0.125
ii  kmod22-1.1
ii  linux-base  4.4

Versions of packages linux-image-4.6.0-1-amd64 recommends:
ii  firmware-linux-free  3.4
pn  irqbalance   

Versions of packages linux-image-4.6.0-1-amd64 suggests:
pn  debian-kernel-handbook  
ii  grub-pc 2.02~beta2-36
pn  linux-doc-4.6   

Versions of packages linux-image-4.6.0-1-amd64 is related to:
ii  firmware-amd-graphics 20160110-1
ii  firmware-atheros  20160110-1
ii  firmware-bnx2 20160110-1
ii  firmware-bnx2x20160110-1
ii  firmware-brcm8021120160110-1
ii  firmware-cavium   20160110-1
ii  firmware-intel-sound  20160110-1
ii  firmware-intelwimax   20160110-1
ii  firmware-ipw2x00  20160110-1
ii  firmware-ivtv 20160110-1
ii  firmware-iwlwifi  20160110-1
ii  firmware-libertas 20160110-1
pn  firmware-linux-nonfree
ii  firmware-misc-nonfree 20160110-1
ii  firmware-myricom  20160110-1
ii  firmware-netxen   20160110-1
ii  firmware-qlogic   20160110-1
ii  firmware-realtek  20160110-1
ii  firmware-samsung  20160110-1
ii  firmware-siano20160110-1
ii  firmware-ti-connectivity  20160110-1
pn  xen-hypervisor

Bug#835368: RFS: confinedrv/1.7.7-3 [ITP] -- Hi everyone!

[Elmar Stellnberger]

Hi Gianfranco, Hi Tobias,
Hi all Readers of this Debian Mentor Request,

Am 2016-08-25 um 13:12 schrieb Gianfranco Costamagna:

  Now this is an additional restriction: you need to provide everything
that is necessary to run your software under an OSS based system (with
exceptions given for the kernel modules).


I think this is a GPL-3 restriction, if you mean "Tivoization"
https://en.wikipedia.org/wiki/Tivoization


Sounds good to me. Then I am going to analyse GPL-3 and see if I can 
adopt it for my programs.




(and this is a good reason to stay away from GPL-3)



... just the other way round



Another issue is that I do not want to 'register' i.e. sell my
personal data to a company I do not trust just in order to fetch
their GPL-ed sources.


also not part of GPL.



what?
sorry I don't follow this sentence ;)


some minor issues that would remain (like obtaining the sources without 
undue obstacles) ..., however likely nothing that could stop me from 
adopting GPL-3 for my programs.


>>>  The problem about additional GPL-2 clauses seems to be that they
>>> can be dropped at any time. An unpleasant contributor can do so any
>>> time and I would not be able to incorporate his changes if I wanna
>>> keep the additional freedoms I wanna guarantee for the upstream
>>> version.
>> They can be dropped (and, in fact, ignored completely) only if they
>> introduce additional restrictions conficting with the GPL itself. If
>> you're granting additional rights, you're free to grant them only
>> under a certain condition ("you're free to relicence this software
>> under a different license but you must keep this statement in tact").
> I guess so

  Anyone else who could assert me that an additional GPL-3 clause would 
do what I want: i.e. give an additional right to relicense to a group 
called original authors only; let this be called GPL-3 + relicensing by 
authors. The GPL-3 amendment would more or less be the same as #7 of 
C-FSL and a statement to tag the GPL-3 abbreviation with the relicensing 
by authors flag.
  Is it really true that this can not be interpreted as restriction 
just because any contributor would have to consent in giving the 
original authors this additional right. It means that someone who does 
not consent is not allowed to apply changes because then the whole 
license would need to turn invalid.



Finally I would like to ask anyone who knows about another issue with 
C-FSL to share it with me as the programs in question will likely be 
available under C-FSL + GPL-3 + relicensing by authors for some ongoing 
time.


up to now I have noted the following issues for C-FSL:
* explicitly allow unchanged redistribution
* version number to use as default: v1.1
* mention online URL in the license

see: https://www.elstel.org/license/C-FSL-v1.0.txt

Regards,
Elmar

Bug#835368: RFS: confinedrv/1.7.7-3 [ITP] -- Hi everyone!

[Elmar Stellnberger]

Am 2016-08-25 um 12:39 schrieb Andrew Shadura:

On 25 August 2016 at 11:53, Elmar Stellnberger  wrote:

Am 2016-08-25 um 10:45 schrieb Gianfranco Costamagna:


I see many GPL-2 similar-looking licenses, with some special exceptions,
e.g.
"In addition to the above license, you can relicense this software in
whatever
form you want, with a special exception: you can't do foo and bar if you
change the
license"



  The problem about additional GPL-2 clauses seems to be that they can be
dropped at any time. An unpleasant contributor can do so any time and I
would not be able to incorporate his changes if I wanna keep the additional
freedoms I wanna guarantee for the upstream version.


They can be dropped (and, in fact, ignored completely) only if they
introduce additional restrictions conficting with the GPL itself. If
you're granting additional rights, you're free to grant them only
under a certain condition ("you're free to relicence this software
under a different license but you must keep this statement in tact").



  Yes, that is a good point and it certainly proves that GPL would work 
in this regard; but what about the other two issues:


> I do also know that the KDE team had a problem with their license
> when Apple came to publish their respective amendments in the sources
> of Safari. They do not run and will never run on OSS and this makes
> Apple publishing their sources rather useless to the OSS community.

  Now this is an additional restriction: you need to provide everything 
that is necessary to run your software under an OSS based system (with 
exceptions given for the kernel modules).


> Another issue is that I do not want to 'register' i.e. sell my
> personal data to a company I do not trust just in order to fetch
> their GPL-ed sources.

also not part of GPL.

Bug#835368: RFS: confinedrv/1.7.7-3 [ITP] -- Hi everyone!

[Elmar Stellnberger]

Am 2016-08-25 um 10:45 schrieb Gianfranco Costamagna:

I see many GPL-2 similar-looking licenses, with some special exceptions, e.g.
"In addition to the above license, you can relicense this software in whatever
form you want, with a special exception: you can't do foo and bar if you change 
the
license"


  The problem about additional GPL-2 clauses seems to be that they can 
be dropped at any time. An unpleasant contributor can do so any time and 
I would not be able to incorporate his changes if I wanna keep the 
additional freedoms I wanna guarantee for the upstream version.

Bug#835368: RFS: confinedrv/1.7.7-3 [ITP] -- Hi everyone!

[Elmar Stellnberger]

Am 2016-08-25 um 06:52 schrieb Tobias Frost:

Am Mittwoch, den 24.08.2016, 22:06 +0200 schrieb Elmar Stellnberger:



   The license in use, C-FSL v1.0 will still need to be reviewed. A
predecessor license C-FSL v0.8 had already been discussed on
debian-legal some time ago. However v1.0 has been reworked basing
on the input I had received from there and should now hopefully be
without issues.


I think one recommendation has not been followed. If not, I *strongly*
recommend:
PLEASE Do not run your own license. See https://people.debian.org/~bap/
dfsg-faq.html §5

I took me some time to locate this license (please put it somewhere and
link to it).


  The license is online under https://www.elstel.org/license. The URL 
may be a bit hard to find and if you like I can link it from 
https://www.elstel.org/software/. You are right; the URL should probably 
be referred to in the license itself.
  If you have any further improvements towards locating the license 
then please let me know.



I located it then in the header of the xchroot script, and as I only
had 5 minutes to take a look, I come only to this sentence:

"If a specific version number is mentioned then usage rights include
this version as well as any newer version which will always be similar
in spirit to this license. The term Convertible Free Software license
may be abbreviated as C-FSL."

- This will fail the the tentacle of evil test.
- What happens if there is no version number attached? Choose any?
Choose latest?


  It should not fail the tentacle of evil test as the user of the 
program may choose which version of the license to execute: the version 
mentioned with the programme or any newer version. It quasi gives any 
new author the right to re-license within C-FSL. As the original author 
never looses his/her copyright he can always re-license (whatever the 
previous license may look like: BSD/GPL/...); i.e. you can never (fully) 
shield against the case of an evil author re-licensing proprietarily 
under any given license of the universe - with BSD that is not even 
intended.
  The right to switch to a newer version is up to anyone who receives a 
program under C-FSL and it does not forbid to keep an elder version of 
the license if you prefer that. This is due to the principal of legal 
certainity taking precedence over correctness of law and it is a basic 
principle in any legal system I know.
  The clause has just been invented to alleviate me from the pain of 
having to re-publish existing programs with a newer version of the 
license (in which case both versions can be applied forever).


  no version number attached: you have a good point in it as we had 
already discussed v0.8 of the license which was never meant to be 
executed in practice; I should have included the version to default to 
1.0 at least; not sure what it would take to make this good.




"3. It is your obligation that the changed version of your sources will
be available to the public for free within the time frame of a month at
least if there is no undue hindrance by the authors to make it
available. "

As distribution is not limited to the people using the stuff, this is
non-free. Fails Desert Island Test and Dissident Tests.


  You have a good point in this! Thanks for your input. I should 
mention: "You may always distribute a product under C-FSL in unchanged 
form. ..."; otherwise if you change or execute the term 'use' would 
clearly apply to my believe.




(I have stopped here... Above is not a complete analysis of any
section, also not up to 3.I)


PLEASE do not run your own license.


  Yes, I know that usage of an own license is discouraged due to the 
many issues that may arise. However I do certainly have a point in 
creating this license as I wanna keep the right to re-license which is 
not included by GPL. BSD on the other hand has no provisions against 
making software licensed under BSD non-free be it by the application of 
patents, DRM or other stuff. I do also know that the KDE team had a 
problem with their license when Apple came to publish their respective 
amendments in the sources of Safari. They do not run and will never run 
on OSS and this makes Apple publishing their sources rather useless to 
the OSS community. Another issue is that I do not want to 'register' 
i.e. sell my personal data to a company I do not trust just in order to 
fetch their GPL-ed sources.



--
tobi



  If anyone here would be ready to further investigate C-FSL I will 
highly appreciate your effort in doing so. Why not have a discussion at 
debian-legal? I`d personally like to get the issues with it resolved as 
soon as possible. Otherwise if you believe that I do not have sufficient 
stance to do so by the software I have currently released then I would 
need to wait ...


Elmar

Bug#835368: RFS: confinedrv/1.7.7-3 [ITP] -- Hi everyone!

[Elmar Stellnberger]

Package: sponsorship-requests
Subject: RFS: confinedrv/1.7.7-3 [ITP] -- Hi everyone!
Severity: wishlist

Dear mentors,

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

 * Package name: confinedrv
   Version : 1.7.7-3
   Upstream Author : Elmar Stellnberger 
 * URL : https://www.elstel.org/qemu
 * License : C-FSL v1.0
   Section : utils

  It is a little script with a man page wrapped into a package:

confinedrv - mirror an existing drive but with confined access 
rights on a per-partition basis (ro/rw/zero/err); there is also a 
possibilty to use image files for the MBR as well as individual paritions.


  Every now and then I receive an email of people who like and 
successfully deploy the program. That is why I think it would be 
beneficial to promote this little helper script for device mapper into 
Debian and other distributions. It also shows that the script has proven 
quite useful in many situations.



  To access further information about this package, you may also visit 
the following URL:


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

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

  dget [-x] 
https://mentors.debian.net/debian/pool/main/c/confinedrv/confinedrv_1.7.7-3.dsc


  Information about confinedrv can be obtained from the documentation 
that ships with the package as well as online under 
https://www.elstel.org/qemu.


  What will also need to be analysed:

  The license in use, C-FSL v1.0 will still need to be reviewed. A 
predecessor license C-FSL v0.8 had already been discussed on 
debian-legal some time ago. However v1.0 has been reworked basing
on the input I had received from there and should now hopefully be 
without issues. If you decide to review the license do not do it

just for confinedrv but for all programs offered by elstel.org:
bundsteg (printing with inner margin), xchroot (chroot for X11), 
debcheckroot (security aware alternative for debsums), dbschemacmd (tool 
to normalize database schemata), coan for Linux/Qt (coming soon; 
simulate deterministic / non-deterministic FA, PDA, Turing Machines)


  pubkey and SHA512SUMS.signed for all programs at elstel.org 
(DNSSEC/DANE supported) can be found at:


  https://www.elstel.org/software/SHA512SUMS.signed
  https://www.elstel.org/auxil/estellnb.pubkey.asc
 ( also: https://www.elstel.org/auxil/estellnb-offline.pubkey.asc )


  Changes since the last upload:

none; this package has been uploaded newly.

  Kind Regards,
  Elmar Stellnberger

Bug#835288: ITP: confinedrv -- set up a virtual drive with confined access rights

[Elmar Stellnberger]

Package: wnpp
Version: 1.7.7; issued 2013-08-23
Subject: ITP: confinedrv -- set up a virtual drive with confined access 
rights

Severity: wishlist

* Package name : confinedrv
Version : 1.7.7
Upstream Author : Elmar Stellnberger 
* URL : http://www.elstel.org/qemu
* License : C-FSL v1.0; see for the program header or run the program 
with --license
Description : This utility allows you to limit existing partitions to 
read only, no-read access or you can err/zero them out while creating an 
own virtual drive with confined access rights mirroring the original. 
Replacing the master boot record as well as individual partitions by 
image files is also supported. This can f.i. be used by a virtual 
machine to safely boot into one or more operating systems that reside on 
the same disk as your host operating system. The documentation will tell 
you how to use that with qemu or qemu-kvm.


--

confinedrv is a cute little program making use of device-mapper that has 
proven useful in many situations.
Whether you have a dual boot environment with Windows or just prefer to 
really boot one of your Linux or BSD installations on hard disk with 
qemu rather than just using xchroot this little program will come to the 
rescue. The original idea behind writing this program was to analyse a 
cracked system on disk safely after installing a fresh system into a 
free partition. As confinedrv does also allow you to backup the MBR this 
program allows you to fully move an existing installation into a virtual 
machine while keeping things safe by restricting access rights to other 
partitions and the MBR.

Bug#827513: [libreoffice-mysql-connector] bug also in libreoffice-pdfimport package

[Elmar Haneke]

Package: libreoffice-mysql-connector

--- Please enter the report below this line. ---
The same error occurrs on installing libreoffice-pdfimport, I do not
have the mysql-connector installed

--- System information. ---
Architecture: amd64
Kernel: Linux 4.6.0-1-amd64

Debian Release: stretch/sid
800 unstable ftp.uni-kl.de
800 unstable ftp.de.debian.org
700 testing ftp.de.debian.org
600 stable dl.google.com
500 stable-libjpeg62-compat download.mono-project.com
500 nightly download.mono-project.com
500 experimental ftp.de.debian.org
500 debian-stretch apt.dockerproject.org

--- Package information. ---
Package's Depends field is empty.

Package's Recommends field is empty.

Package's Suggests field is empty.




-- 
Mit freundlichen Grüßen

Elmar Haneke

===
|Dr. Elmar Haneke   Tel: +49-2241-39749-0 |
|   Fax: +49-2241-39749-30|
|Haneke SoftwareWWW: www.haneke.de    |
|Dr. Elmar und Hubertus Haneke  Mail: el...@haneke.de |
|Johannesstraße 41|
|53721 Siegburg USt-IdNr. DE 123387209|
===

Bug#821020: [docker.io] Depends on Linux-Kernel

[Elmar Haneke]

Package: docker.io
Version: 1.8.3~ds1-2

--- Please enter the report below this line. ---
The problem seems to be related to linux-kernel.
The Problem does occur when running
linux-image-4.5.0-trunk-amd64 4.5-1~exp1
it is not reproducable on
linux-image-4.4.0-1-amd64 4.4.6-1

--- System information. ---
Architecture: amd64
Kernel: Linux 4.4.0-1-amd64

Debian Release: stretch/sid
900 stable download.mono-project.com
900 stable dl.google.com
850 testing ftp.de.debian.org
800 unstable ftp.uni-kl.de
800 unstable ftp.de.debian.org
500 stable-libjpeg62-compat download.mono-project.com
500 experimental ftp.de.debian.org

--- Package information. ---
Package's Depends field is empty.

Package's Recommends field is empty.

Package's Suggests field is empty.




-- 
Mit freundlichen Grüßen

Elmar Haneke

===
|Dr. Elmar Haneke   Tel: +49-2241-39749-0 |
|   Fax: +49-2241-39749-30|
|Haneke SoftwareWWW: www.haneke.de    |
|Dr. Elmar und Hubertus Haneke  Mail: el...@haneke.de |
|Johannesstraße 41|
|53721 Siegburg USt-IdNr. DE 123387209|
===

Bug#821020: [docker.io] cannot build image

[elmar]

Package: docker.io
Version: 1.8.3~ds1-2
Severity: normal

--- Please enter the report below this line. ---

On building it does fail with an strange error about permissions.

> docker build --tag=haneke_firebird .
Sending build context to Docker daemon 100.5 MB
Step 0 : FROM debian:jessie
 ---> 32f2a4cccab8
Step 1 : MAINTAINER Elmar Haneke 
open 
/var/lib/docker/overlay/8bb27e1d58d9feb96632132f8826ad278de2edb3e6657c5ca5cb7da3cf409943-
init/merged/dev/console: operation not permitted

/var/lib/docker is maintained by docker itself, completely removing that 
directory does not help

--- System information. ---
Architecture: amd64
Kernel:   Linux 4.5.0-trunk-amd64

Debian Release: stretch/sid
  900 stable  download.mono-project.com 
  900 stable  dl.google.com 
  850 testing ftp.de.debian.org 
  800 unstableftp.uni-kl.de 
  800 unstableftp.de.debian.org 
  500 stable-libjpeg62-compat download.mono-project.com 
  500 experimentalftp.de.debian.org 

--- Package information. ---
Package's Depends field is empty.

Package's Recommends field is empty.

Package's Suggests field is empty.

Bug#817192: php5-cgi of version 5.6 tries to load libraries of version 5.4

[Elmar Stellnberger]

Package: php5-cgi
Version: 5.6.17+dfsg-3
Severity: normal

Dear Maintainer,


php5-cgi --version
Failed loading /usr/lib/php5.4/20100525/opcache.so: 
/usr/lib/php5.4/20100525/opcache.so: cannot open shared object file: No 
such file or directory
PHP Warning:  PHP Startup: Unable to load dynamic library 
'/usr/lib/php5.4/20100525/pdo.so' - /usr/lib/php5.4/20100525/pdo.so: 
cannot open shared object file: No such file or directory in Unknown on 
line 0
PHP Warning:  PHP Startup: Unable to load dynamic library 
'/usr/lib/php5.4/20100525/imagick.so' - 
/usr/lib/php5.4/20100525/imagick.so: cannot open shared object file: No 
such file or directory in Unknown on line 0
PHP Warning:  PHP Startup: Unable to load dynamic library 
'/usr/lib/php5.4/20100525/json.so' - /usr/lib/php5.4/20100525/json.so: 
cannot open shared object file: No such file or directory in Unknown on 
line 0
PHP Warning:  PHP Startup: Unable to load dynamic library 
'/usr/lib/php5.4/20100525/readline.so' - 
/usr/lib/php5.4/20100525/readline.so: cannot open shared object file: No 
such file or directory in Unknown on line 0
PHP Warning:  PHP Startup: Unable to load dynamic library 
'/usr/lib/php5.4/20100525/xsl.so' - /usr/lib/php5.4/20100525/xsl.so: 
cannot open shared object file: No such file or directory in Unknown on 
line 0
PHP Warning:  PHP Startup: Unable to load dynamic library 
'/usr/lib/php5.4/20100525/yac.so' - /usr/lib/php5.4/20100525/yac.so: 
cannot open shared object file: No such file or directory in Unknown on 
line 0

PHP 5.6.17-3 (cgi-fcgi)
Copyright (c) 1997-2015 The PHP Group
Zend Engine v2.6.0, Copyright (c) 1998-2015 Zend Technologies

However the /us/lib/php5.4 directory does not exist:


ls -l /usr/lib/php5/20131226/

insgesamt 844
-rw-r--r-- 1 root root 418376 Jun 17  2015 imagick.so
-rw-r--r-- 1 root root  39696 Jul  8  2015 json.so
-rw-r--r-- 1 root root 156152 Jän 15 10:10 opcache.so
-rw-r--r-- 1 root root 118344 Jän 15 10:10 pdo.so
-rw-r--r-- 1 root root  35672 Jän 15 10:10 readline.so
-rw-r--r-- 1 root root  35960 Jän 15 10:10 xsl.so
-rw-r--r-- 1 root root  48224 Okt 23  2014 yac.so

As it seems the php5-cgi binary has been compiled against too old shared 
libaries which are not in sync with the other libraries available for 
debian-testing.

all of it after a successful apt-get upgrade.

-- Package-specific info:
 Additional PHP 5 information 

 PHP 5 SAPI (php5query -S): 
cli
apache2
cgi

 PHP 5 Extensions (php5query -M -v): 
pdo (Enabled for cli by maintainer script)
pdo (Enabled for apache2 by maintainer script)
pdo (Enabled for cgi by maintainer script)
opcache (Enabled for cli by maintainer script)
opcache (Enabled for apache2 by maintainer script)
opcache (Enabled for cgi by maintainer script)
json (Enabled for cli by maintainer script)
json (Enabled for apache2 by maintainer script)
json (Enabled for cgi by maintainer script)
readline (Enabled for cli by maintainer script)
readline (Enabled for apache2 by maintainer script)
readline (Enabled for cgi by maintainer script)
imagick (Enabled for cli by maintainer script)
imagick (Enabled for apache2 by maintainer script)
imagick (Enabled for cgi by maintainer script)
xsl (Enabled for cli by maintainer script)
xsl (Enabled for apache2 by maintainer script)
xsl (Enabled for cgi by maintainer script)
yac (Enabled for cli by maintainer script)
yac (Enabled for apache2 by maintainer script)
yac (Enabled for cgi by maintainer script)

 Configuration files: 
[PHP]
allow_url_include = 0
always_populate_raw_post_data = 0
arg_separator.input = "&"
arg_separator.output = "&"
[Assertion]
assert.active = 1
assert.bail = 0
assert.quiet_eval = 0
assert.warning = 1
[PHP]
auto_detect_line_endings = 0
auto_globals_jit = 1
[bcmath]
bcmath.scale = 0
[cgi]
cgi.check_shebang_line = 1
cgi.discard_path = 0
cgi.fix_pathinfo = 1
cgi.force_redirect = 1
cgi.nph = 0
cgi.rfc2616_headers = 0
[date]
date.default_latitude = 31.7667
date.default_longitude = 35.2333
date.sunrise_zenith = 90.58
date.sunset_zenith = 90.58
[dba]
dba.default_handler = "flatfile"
[PHP]
default_mimetype = "text/html"
default_socket_timeout = 60
disable_functions = "system, show_source, passthru, shell_exec, exec, 
pcntl_exec, popen, posix_setuid, posix_seteuid, proc_open, chown, 
dbmopen, disk_free_space, diskfreespace"

display_errors = 1
enable_dl = 1
enable_post_data_reading = 1
error_reporting = 24567
[exif]
exif.decode_jis_intel = "JIS"
exif.decode_jis_motorola = "JIS"
exif.decode_unicode_intel = "UCS-2LE"
exif.decode_unicode_motorola = "UCS-2BE"
exif.encode_unicode = "ISO-8859-15"
[PHP]
exit_on_timeout = 0
extension_dir = "/usr/lib/php5.4/20100525"
[fastcgi]
fastcgi.logging = 1
[PHP]
file_uploads = 1
[filter]
filter.default = "unsafe_raw"
[gd]
gd.jpeg_ignore_warning = 0
[highlight]
highlight.comment = "#FF8000"
highlight.default = "#BB"
highlight.html = "#00"
highlight.keyword = "#007700"
highlight.string = "#DD"
[PHP]
html_errors = 1
[iconv]
iconv.input_encodi

Bug#785672: Critical ext4 data corruption bug

[Elmar Stellnberger]

Am 19.05.15 um 01:12 schrieb Josh Triplett:

Package: src:linux
Version: 4.0.2-1
Severity: critical
Tags: upstream

4.0.3 includes a fix for a critical ext4 bug that can result in major
data loss.  I believe this is the bug I just hit on my server, resulting
in massive filesystem corruption.  See upstream commit
d2dc317d564a46dfc683978a2e5a4f91434e9711 ("ext4: fix data corruption
caused by unwritten and delayed extents"), which has been added to
stable kernels 4.0.3 as well as much older stable kernels.

Please consider incorporating this patch into the Debian kernels as soon
as possible, including into the Jessie kernel.


Some time ago I also had some massive data corruption problem with an 
ext4 partition
which may also have been caused by the same bug. The notable thing is 
that other ext4
installations have worked fine for a long while in spite of this bug. No 
fsck had helped;

had to reformat having lost all data on the partition.
We need to warn any existing ext4 user! The patch should be distributed 
as soon as
possible. My recommendation would be not to use ext4 or to convert to 
btrfs unless

a fix is available. Otherwise assert your backups!

Elmar


- Josh Triplett

-- Package-specific info:
** Version:
Linux version 4.0.0-1-amd64 (debian-ker...@lists.debian.org) (gcc version 4.9.2 
(Debian 4.9.2-16) ) #1 SMP Debian 4.0.2-1 (2015-05-11)

** Command line:
BOOT_IMAGE=/vmlinuz-4.0.0-1-amd64 root=/dev/mapper/data-root ro quiet

** Not tainted

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

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

Versions of packages linux-image-4.0.0-1-amd64 depends on:
ii  debconf [debconf-2.0]   1.5.56
ii  initramfs-tools [linux-initramfs-tool]  0.120
ii  kmod20-1
ii  linux-base  3.5
ii  module-init-tools   20-1

Versions of packages linux-image-4.0.0-1-amd64 recommends:
ii  firmware-linux-free  3.3
pn  irqbalance   

Versions of packages linux-image-4.0.0-1-amd64 suggests:
pn  debian-kernel-handbook  
ii  grub-pc 2.02~beta2-23
pn  linux-doc-4.0   

Versions of packages linux-image-4.0.0-1-amd64 is related to:
pn  firmware-atheros
pn  firmware-bnx2   
pn  firmware-bnx2x  
pn  firmware-brcm80211  
pn  firmware-intelwimax 
pn  firmware-ipw2x00
pn  firmware-ivtv   
ii  firmware-iwlwifi0.43
pn  firmware-libertas   
pn  firmware-linux  
pn  firmware-linux-nonfree  
pn  firmware-myricom
pn  firmware-netxen 
pn  firmware-qlogic 
pn  firmware-ralink 
pn  firmware-realtek
pn  xen-hypervisor  

-- debconf information:
   linux-image-4.0.0-1-amd64/postinst/depmod-error-initrd-4.0.0-1-amd64: false
   linux-image-4.0.0-1-amd64/prerm/removing-running-kernel-4.0.0-1-amd64: true
   linux-image-4.0.0-1-amd64/postinst/mips-initrd-4.0.0-1-amd64:





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

Bug#751654: ldap-git-backup: runs git commit even if there is nothing to commit

[Elmar Heeb]

Control: tag -1 +unreproducible

Hi Paul

Just for the record: so far I could not reproduce this bug.  On our productive 
system there are enough changes every day that there is always a diff.

In view of the upcoming jessie freeze I looked into the matter during the last 
couple of weeks.  I set up a test system to try out a few things and could not 
reproduce your situation.

> On 15 Jun 2014, at 05:35, Paul Wise  wrote:
> 
> Package: ldap-git-backup
> Version: 1.0.7-1
> Severity: normal
> 
> Every night I get a mail like this. Looks like it is caused by
> ldap-git-backup running git commit even if there is nothing to commit,
> in which case git commit returns failure (1) instead of success (0).
> 
> Subject: Cron  /usr/sbin/ldap-git-backup --ldif-cmd '...' 
> --backup-dir ... --commit-msg "Import $(date --rfc-3339=seconds)"
> 
> commit --message=Import 2014-06-14 00:00:10+08:00 --date=1402675211: command 
> returned error: 1

In a vanilla installation with slapd and its default data two consecutive 
manual runs of ldap-git-backup both give an successful exit code of 0 and no 
output.  The second call is a no-op.  The git log just shows the first backup.  
This is how it is meant to behave.

If I manually run a git commit in the backup directory without any pending 
changes in the git index I do get a non-successful exit code.  However, 
ldap-git-backup does not propagate this up the call chain in my setup.

A vague guess is that some git config setting could trigger the behaviour you 
are seeing.  But unless I can reproduce a test case I hesitate to change my 
code.  Chances are I might introduce some subtle bugs that would prevent making 
a backup in some cases.

I agree that if the situation arises as it does in your case that this is a 
bug.  I also think the severity is appropriately set.

Regards — Elmar

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

Bug#763228: cbmc: FTBFS: ld: final link failed: Bad value

[Elmar Pruesse]

This also occurs with arb:
https://buildd.debian.org/fetch.cgi?pkg=arb&arch=i386&ver=6.0.2-1&stamp=1412337993&file=log

> It seems to be a bug in binutils[1].

I'd say a change in binutils exposed a bug somewhere in the toolchain.

Here's the commit which added the check and the message:

https://www.sourceware.org/ml/binutils/2014-09/msg00094.html

Here's Alan's answer to me asking what I can do to repair this:
https://www.sourceware.org/ml/binutils/2014-09/msg00175.html

Elmar


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

Bug#761942: [RFR] templates://arb/{arb-common.templates}

[Elmar Pruesse]

As a disclaimer up front: I'm actually part of upstream. As a long term
Debian user I couldn't refuse the honor when Andreas asked me to help
with the package. *Thank you all for the great work you do to make
Debian the most awesome software environment on the planet!*

DebConf Template:

"PT server" is probably best regarded as a name. It's meaning to the
user community is really "something I need to do my analysis".

Technically, it is essentially a search engine for DNA sequence data.
The acronym "PT" is historical and spells indeed "positional tree" or
"prefix tree". Today the data structure is known as "suffix trie". Due
to the lengthy index computation process and the high memory
requirements, the engine runs as a "server process" in the background.
Launch, termination and index calculation are managed from within ARB.
For this, several "slots" comprising a location for index data and a
socket (unix or tcp, optionally remote) can be configured in
arb_tcp.dat. These slots are presented in the GUI and are what the users
see as "PT server".

The users do not distinguish between the program, the running instance,
the configuration slot or the index data. I believe the least confusing
description in the template would be "PT server slot", perhaps with
quotes around "PT server".

> http://help.arb-home.de/ says PT is "Prefix Tree" (or occasionally
> "Positional Tree", but usually the former).  It seems to be
> canonically either "PT_SERVER" or hyphenated "PT-server".

I'd prefer the latter as the human readable form. The former probably
originates from C code.

> Given that the .dat file is under /etc/ I assume "preconfigured" means
> "configured by default" rather than "hardwired".  So:

Precisely.

> The default configuration in /etc/arb/arb_tcp.dat gives ARB three
> private Prefix-Tree (PT) servers for each user as well as three
> global PT-servers accessible by all users.

How about:

"""
The default configuration in /etc/arb/arb_tcp.dat gives ARB three
private PT-server slots for each user as well as three global PT-server
slots accessible by all users.
"""

> The part I don't understand is, does this really mean to say that ARB
> will constantly run 3 communal PT-servers *plus* 3n private servers
> where n equals the total number of local users on the system?  That
> sounds like it could be an awful lot of processes.  Or is the "for
> each user" a mistranslation?  Maybe it really means something more
> like a *maximum* of 3 communal servers plus a *maximum* of 3
> non-communal servers which (as it goes on to say) can only be
> activated by members of the arb group?

Prior to ARB 6.0, the administrator would configure one or more "server
slots" for each user on specific TCP ports. As of 6.0, three slots are
configured to use Unix sockets and data locations within the users home
directory. They are only launched upon user request and terminated when
ARB is closed.


Name (ARB vs Arb):
Publications in molecular biology generally use capitalization to
indicate that a word refers to a software. Tool names are typically
acronyms artfully crafted to resemble actual words (e.g. BLAST, MUSCLE)
and lower case would often lead to confusion or even unintended puns. I
could make "Arb" the official name to reduce FORTRANism, but I think
sticking to ARB is ok.


Package description:
The text is perhaps too broken to fix by changing just a bit of the
wording. If this is acceptable to you, I would prefer to take a day to
compose a rewrite that is more to the point and post it for review here.
(And, if you don't mind, I'd then use it upstream as well.)

Elmar


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

Bug#762153: [Reproducible-builds] concrete steps for improving apt downloading security and privacy

[Elmar Stellnberger]

Am 22.09.14 um 01:52 schrieb Paul Wise:

On Mon, Sep 22, 2014 at 2:04 AM, Elmar Stellnberger wrote:


A package with some new signatures added is no more the old package.

That is exactly what we do *not* want for reproducible builds.


It should have a different checksum and be made available again for update.

The Debian archive does not allow files to change their checksum, so
every signature addition requires a new version number. That sounds
like a bad idea to me.

Yes, that is something we definitely do not want.
Nonetheless it would still be an issue to have the package and the 
signatures
in one file because we usually need them together. My only idea to 
realize this

in spite of the said objection would be another proposal:
Put the .deb and the signatures into one .ar called .sdeb and make tools 
like

dpkg work on .sdebs or on .deb + signatures respecively. Whenever someone
offers some packages for download that will be in the form of .sdebs while
official debian repositories may separate both kinds of files. User 
interfaces

like http://debtags.debian.net/search/ could then generate .sdebs on the fly
to satisfy petted users.


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

Bug#761942: [ITR] templates://arb/{arb-common.templates}

[Elmar Prüße]

ACK

Thank you for your work! Please go ahead as soon as you wish.

Elmar

--
message sent from mobile device

> On 21.09.2014, at 09:56, Christian PERRIER  wrote:
> 
> Dear Debian maintainer,
> 
> The Debian internationalisation team and the Debian English
> localisation team will soon begin the review of the debconf
> templates used in arb.
> 
> This review takes place for all packages that use debconf to interact with
> users and its aims are:
> - to improve the use of English in all debconf templates;
> - to make the wording of debconf templates more consistent;
> - to encourage more translations of templates.
> 
> Even if your first language is English, this process is likely to help
> track down typos or errors, and improve consistency between the
> debconf templates of your package and that of other packages in the
> distribution.
> 
> The process involves both debian-l10n-english contributors and
> Debian translators.
> 
> The details of the process are given in
> http://wiki.debian.org/I18n/SmithDebconfReviewProcess.
> 
> I will act as the coordinator of this activity for arb.
> 
> The first step of the process is to review the debconf source
> template file(s) of arb. This review will start on Wednesday, September 24, 
> 2014, or
> as soon as you acknowledge this mail with an agreement for us to
> carry out this process.
> 
> All parts of the process will be carried out in close collaboration
> with you, and, unless you explicitly ask for it, no upload nor NMU
> will happen for arb.
> 
> If you approve this process, please let us know by replying to this
> mail. If some work in progress on your side would conflict with such a
> rewrite (such as adding or removing debconf templates), please say so,
> and we will defer the review to later in the development cycle.
> 
> Thank you for your attention.
> 
> -- 
> 
> 


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

Bug#762153: [Reproducible-builds] concrete steps for improving apt downloading security and privacy

[Elmar Stellnberger]

   A package with some new signatures added is no more the old package.
It should have a different checksum and be made available again for update.
Perhaps someone wants to install the package not before certain signatures
have been added.
  Your thought experiment would this way of course require an adjusted
toolchain i.e. sth. like dpkg-cmp that outputs differences in the 
description
tags, signatures and file content separately. I believe this would be 
the best

way to do it because you seldomly need to compare two packages while you
will need to install individually downloaded packages more often. Just think
f.i. about printer driver, device firmware, 3rd party software or singleton
packages which you do not want to add to apt. Downloading two files all
the time would be far more enervating than a well programmed dpkg-cmp.
... and as long as the tool should not be available simply un-ar and compare
the data.tar.gz-s.

Am 19.09.14 um 15:16 schrieb Daniel Kahn Gillmor:

On 09/19/2014 06:07 AM, Elmar Stellnberger wrote:

Isn`t there really any way to include the signatures in the header of
the .deb files?
Why not simply add multiple signature files in the control.tar.gz of a
.deb just next
to the md5sums which should in deed be a sha256sums (otherwise there is
no way
to establish a 'chain of trust'). That would not add any non-determinism
because
if it is done right then we can have all the signers in the package!

If we succeed in creating reproducible builds (we're farther along
toward that goal than i had dared hope, it's exciting!) then one of the
nice opportunites we have is for other people or organizations to
corroborate the build after the package is first distributed.  For
example, an upload to sid might have one signature (by the original
uploader), but maybe it waits to transition to testing until there are
corroborations from multiple builders. (Note: this is not a concrete
proposal or an expectation of exactly what will happen, just a thought
experiment)

In this scenario, how do you propose to add those signatures into the
package?  If we bundle them into the .deb, then the size and digest of
the .deb itself changes after it is first distributed.  This seems like
it would violate all sorts of existing expectations -- i can't imagine
how many different tools and pieces of infrastructure expect that
foo_1.2-3_mipsel.deb should always have the same size and digest.


It would be far better than detaching the signatures from the package
because
the general use case where you need package signatures is the manual
download
of packages. Detached signatures are completely useless for such a use
case!

I don't think this is the case.  People who download a .deb and verify
it could also download the associated .buildinfo file and whichever
signatures they'd like (or all of them) and verify the package that way.

--dkg




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

Bug#762153: concrete steps for improving apt downloading security and privacy

[Elmar Stellnberger]

Am 19.09.14 um 06:34 schrieb Paul Wise:

On Fri, Sep 19, 2014 at 9:30 AM, Hans-Christoph Steiner wrote:


Finally did this:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=762153

Please note that you proposal to add signatures to .deb files will
break reproducible builds because the hash of the .deb will differ
depending on who signed it:

https://wiki.debian.org/ReproducibleBuilds

I think it would be far better to ship detached signatures in the
archive since that allows for reproducible builds and also means there
could be more than one signer (say one buildd, one Debian sponsor and
one package maintainer).

   Isn`t there really any way to include the signatures in the header 
of the .deb files?
Why not simply add multiple signature files in the control.tar.gz of a 
.deb just next
to the md5sums which should in deed be a sha256sums (otherwise there is 
no way
to establish a 'chain of trust'). That would not add any non-determinism 
because

if it is done right then we can have all the signers in the package!
   It would be far better than detaching the signatures from the 
package because
the general use case where you need package signatures is the manual 
download

of packages. Detached signatures are completely useless for such a use case!


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

Bug#750576: ITP: debdry -- Semi-assisted automatic Debian packaging

[Elmar Heeb]

On 29 Aug 2014, at 11:50, Axel Beckert  wrote:
> For native or near-native (upstream = debian maintainer) packages
> there also exists the idea of doing the opposite: Generating what is
> needed for upstream setup tools based data in e.g. debian/control. In
> the Perl world that would mean to generate dist.ini (preferably),
> Makefile.PL or Build.PL based on data in debian/control.

Just a minor note for the record: the way I imagine this being done is
not to generate dist.ini but to reduce it to one line, ideally.  That
line would contain [@Debian]

Makefile.PL or Build.PL are good candidates to be generated and that is
exactly what Dist::Zilla does.  dist.ini on the other hand is meant to
be written by the maintainer and should contain the minimum information
needed that is not available elsewhere (in the sense that it does not
already belong somewhere else).  Dist::Zilla plugins are used to gather
the rest of the information and produce the boilerplate needed by CPAN.

A fairly typical dist.ini would contain information about the name of
the package, the author, copyright, and version.  These are all
duplicated in the debian/ directory.  For a native package all that is
needed are a few Dist::Zilla plugins and a plugin bundle
(Dist::Zilla::PluginBundle::Debian, hence [@Debian] in dist.ini) and
Dist::Zilla can extract the information from the debian/ directory.
We do have dh-dist-zilla but the plugins and bundles still need to be
written.  I am planing to invest some time but if there are other
people with more experience in writing Dist::Zilla plugins willing
to help out I would be very pleased.

That all being said it covers only a minority of packages.  For the
majority we want to have debdry proper :-)

Regards     — Elmar

-- 
Elmar Heeb
Bläsistrasse 49
CH-8049 Zürich
Tel: +41 79 628 7524



signature.asc
Description: Message signed with OpenPGP using GPGMail

Bug#757229: ITP: dh-dist-zilla -- debhelper add-on to call dzil build and clean up after the build

[Elmar S. Heeb]

Package: wnpp
Severity: wishlist
Owner: "Elmar S. Heeb" 

* Package name: dh-dist-zilla
  Version : 1
  Upstream Author : Elmar S. Heeb ,
Axel Beckert 
* URL : https://github.com/elmar/dh-dist-zilla
* License : GPL v3+
  Programming Lang: Perl
  Description : debhelper add-on to call dzil build and clean up after the 
build

dh-dist-zilla provides a debhelper sequence addon named 'dist_zilla'.

The intention is to be able to build directly from a Dist::Zilla based
package without generating the CPAN package manually first.  It is
analogous to using autoreconf to generate the configure script.

The orig.tar.gz file must only contain the dist.ini and source files but
not the generated files like META.yaml, README, etc.


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

Bug#729537: Bug#756392: enable SIMD and threading support

[Elmar Pruesse]

> However, when thinking about, users might be used to call raxmlHPC
> and thus the wrapper should get this name and we could throw away the
> result of Makefile.gcc.  Is this correct or not?

Sounds about right.

> Is there any possibility that the vanilla raxmlHPC might be used
> under some circumstance in practical cases as last resort?

I don't think so, but maybe Alexis knows better than me.

> What about Makefile.AVX2.PTHREADS.gcc?

I had trouble compiling it on some platforms and Alexis said IIRC that
the performance gain was not very high. If it works in Debian, though,
just add it, whether there are 3 or 4 SIMD variants doesn't increase
complexity much.

> Once we are talking about it:  We have some Debian programs were we 
> deliver a "pure" and a "mpi" binary package.  If I understood Elmar 
> correctly the results of
> 
> Makefile.AVX.HYBRID.gcc Makefile.AVX.MPI.gcc 
> Makefile.AVX2.HYBRID.gcc Makefile.AVX2.MPI.gcc 
> Makefile.SSE3.HYBRID.gcc Makefile.SSE3.MPI.gcc

Yes, those would have to depend on openmpi. The detection, whether to
use non-MPI or MPI binaries could probably be based on environment
variables set by mpirun.

AFAIK, PTHREADS splits work along the lengths of the sequences, with
500bp per thread being about the smallest split that is showing gains.
The MPI parallelization splits work along the number of bootstraps.
HYBRID enables both. So choosing the "optimal" binary would require
interpreting the command line options and possibly the input data. Since
I have rarely used RAxML using MPI parallelization, I cannot say much
about this, though.

Elmar
-- 
Dr. Elmar Pruesse

Max Planck Institute for Marine Microbiology
Microbial Genomics Group
Celsiusstrasse 1 | 28359 Bremen | Germany

Jacobs University Bremen gGmbH
School of Engineering & Science - SES
Campus Ring 1 | 28759 Bremen | Germany

Tel: +49 421 2028 984
Fax: +49 421 2028 580

http://www.arb-silva.de
http://www.microbial-genomics.de


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

Bug#756392: enable SIMD and threading support

[Elmar Pruesse]

Package: raxml
Version: 7.2.8-2
Severity: wishlist

Dear Maintainer,

the current RAxML package contains only the "vanilla" version of RAxML
compiled without support threading or SIMD. Given that typical use cases
of RAxML require days of computation, enabling parallel processing would
improve the utility of the package significantly.

RAxML does not detect the available hardware at runtime. Instead,
separate Makefiles build the various optimized versions. Supported SIMD
variants are: (none), SSE3, AVX and AVX2. Supported threading variants
are: (none), PTHREADS, MPI and HYBRID (both pthreads and MPI).

The makefile names are "Makefile.gcc".

Since most users will have multi-core CPUs and only very few a MPI
environment, focusing on the PTHREAD variants with SIMD extensions
should be a good balance between package complexity and extra value. The
AVX2 extensions apparently do not add much performance. Therefore, I
would suggest building three versions:
- Makefile.PTHREADS.gcc
- Makefile.PTHREADS.SSE3.gcc
- Makefile.PTHREADS.AVX.gcc (depends >= gcc 4.6)

A simple bash wrapper script could then be used to make the appropriate
choice for the user. E.g.:


#!/bin/bash

if grep -q avx /proc/cpuinfo; then
  exec raxml.PTHREADS.AVX "$@"
elif grep -q sse3 /proc/cpuinfo; then
  exec raxml.PTHREADS.SSE3 "$@"
else
  exec raxml.PTHREADS.NOSIMD "$@"
fi


best regards,
Elmar


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

Bug#611842: run-in-terminal defaults broken in preferred applications capplet

[Elmar Hoffmann]

notfound 611842 1:3.4.3.1-2
thanks

Hi althaser,

on Tue, Apr 08, 2014 at 20:43:28 +0100, you wrote:

> Could you please still reproduce this issue with newer gnome-control-center
> version like 1:3.4.3.1-2 or 1:3.8.3-5 ?

Just tried on a wheezy system with GNOME and selecting "Mutt" as preferred
mail application works, opening it in a Terminal window (there is no
checkbox anymore).

It also works with mate-control-center from upstream MATE on jessie, so it
even does not seems to come back that route, either. :)

elmar

-- 

 .'"`.    /"\
| :' :   Elmar Hoffmann ASCII Ribbon Campaign  \ /
`. `'GPG key available via pgp.netagainst HTML email   X
  `-& vCards  / \


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

Bug#741890: arb: FTBFS with libpng16

[Elmar Pruesse]

Hi Andreas!

The 6.0rc1 should come out this week. There are only a few minor things
left to do (such as writing the announcement).

As these things go, there will probably be a 6.0rc2, though. So while
I'd love to see the exposure from getting the rc1 into unstable, I'm not
up to date on Debian policy. The stability of the rc1 is much higher
than when we did the 5.0, so I feel very much at ease with it. Since the
5.5 doesn't work on OSX 10.9, Matt Cottrell will also be uploading the
rc into MacPorts soon (if he hasn't already).

You can find a source tarball here:
ftp://ftp.arb-silva.de/ARB/builds/tagged/arb-5.21/

Elmar

On 03/17/2014 08:56 AM, Andreas Tille wrote:
> Hi Elmar,
> 
> On Mon, Mar 17, 2014 at 05:18:23AM +0100, Elmar Pruesse wrote:
>> Hi!
>>
>> Upstream here :)
> 
> Wow, that's quick response time! ;-)
>  
>> I can confirm the issue, we fixed it in r9003
>> (http://bugs.arb-home.de/changeset/9003). Since ARB 6 is just about
>> ready, we won't do any more releases in the 5.x series, so I've
>> backported the fix for you (patch attached).
> 
> Thanks for the patch.  Since the libpng transition might take some time
> would you consider that it might be sensible to wait for arb 6 and
> simply fix the problem with this new version.  I think if it is a matter
> of say 1-2 weeks this strategy makes sense.  Otherwise I might upload
> the patched package.
> 
> Kind regards and many thanks for your really quick help
> 
>   Andreas.
> 


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

Bug#741890: arb: FTBFS with libpng16

[Elmar Pruesse]

Hi!

Upstream here :)

I can confirm the issue, we fixed it in r9003
(http://bugs.arb-home.de/changeset/9003). Since ARB 6 is just about
ready, we won't do any more releases in the 5.x series, so I've
backported the fix for you (patch attached).

best,
Elmar

On 03/17/2014 01:42 AM, Nobuhiro Iwamatsu wrote:
> Source: arb
> Version: 5.5-5
> Severity: important
> User: lib...@packages.debian.org
> Usertags: libpng15-transition
> 
> Hi,
> 
> libpng maintainers have a plan transition of libpng[0].
> 
> libpng is already installed in experimental, and we are re-building
> the package depending on libpng16.
> 
> We checked that your package was FTBFS.
> Would you check also in your environment?
> And if a problem can be checked, could you fix this?
> 
> -
> 
> cc -O4 -pipe -fmessage-length=0 -funit-at-a-time -fPIC -DARB_OPENGL
> -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat
> -Werror=format-security -W -Wall -DNDEBUG -DARB_64  -DLINUX
> -DFAKE_VTAB_PTR=char -DIN_ARB_GL -DIN_ARB_glpng -c glpng.c -I.
> -I/tmp/buildd/arb-5.5/INCLUDE -I/include
> In file included from glpng.c:35:0:
> /tmp/buildd/arb-5.5/INCLUDE/GL/glpng.h:60:23: error: expected
> identifier or '(' before '-' token
>  #define PNG_CALLBACK  -3 /* Call the callback function to generate alpha   */
>^
> /tmp/buildd/arb-5.5/INCLUDE/GL/glpng.h:60:23: error: expected
> identifier or '(' before '-' token
>  #define PNG_CALLBACK  -3 /* Call the callback function to generate alpha   */
>^
> /tmp/buildd/arb-5.5/INCLUDE/GL/glpng.h:60:23: error: expected
> identifier or '(' before '-' token
>  #define PNG_CALLBACK  -3 /* Call the callback function to generate alpha   */
>^
> /tmp/buildd/arb-5.5/INCLUDE/GL/glpng.h:60:23: error: expected
> identifier or '(' before '-' token
>  #define PNG_CALLBACK  -3 /* Call the callback function to generate alpha   */
> 
> -
> 
> Best regards,
>   Nobuhiro
> 
> [0]http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=650601
> 
> Best regards,
>   Nobuhiro
> 
diff -rNu arbsrc_9167/GL/glpng/glpng.c arbsrc_9167.new/GL/glpng/glpng.c
--- arbsrc_9167/GL/glpng/glpng.c	2012-11-14 13:13:45.0 +0100
+++ arbsrc_9167.new/GL/glpng/glpng.c	2014-03-17 05:04:53.493971219 +0100
@@ -38,9 +38,9 @@
 #include 
 
 #if 0
-#define PNG_CHECK_SIG(header,size) png_check_sig(header,size) // old libpng
+#define GLPNG_CHECK_SIG(header,size) png_check_sig(header,size) // old libpng
 #else
-#define PNG_CHECK_SIG(header,size) (png_sig_cmp(header,0,size)==0)
+#define GLPNG_CHECK_SIG(header,size) (png_sig_cmp(header,0,size)==0)
 #endif
 
 /* Used to decide if GL/gl.h supports the paletted extension */
@@ -284,7 +284,7 @@
 if (pinfo == NULL) return 0;
 
 fread(header, 1, 8, fp);
-if (!PNG_CHECK_SIG(header, 8)) return 0;
+if (!GLPNG_CHECK_SIG(header, 8)) return 0;
 
 png = png_create_read_struct(PNG_LIBPNG_VER_STRING, NULL, NULL, NULL);
 info = png_create_info_struct(png);
@@ -437,12 +437,12 @@
 if (color == PNG_COLOR_TYPE_GRAY || color == PNG_COLOR_TYPE_GRAY_ALPHA)
 png_set_gray_to_rgb(png);
 
-if (color&PNG_COLOR_MASK_ALPHA && trans != PNG_ALPHA) {
+if (color&PNG_COLOR_MASK_ALPHA && trans != GLPNG_ALPHA) {
 png_set_strip_alpha(png);
 color &= ~PNG_COLOR_MASK_ALPHA;
 }
 
-if (!(PalettedTextures && mipmap >= 0 && trans == PNG_SOLID))
+if (!(PalettedTextures && mipmap >= 0 && trans == GLPNG_SOLID))
 if (color == PNG_COLOR_TYPE_PALETTE)
 png_set_expand(png);
 
@@ -493,7 +493,7 @@
 glPixelStorei(GL_UNPACK_ALIGNMENT, 1);
 
 #ifdef SUPPORTS_PALETTE_EXT
-if (PalettedTextures && mipmap >= 0 && trans == PNG_SOLID && color == PNG_COLOR_TYPE_PALETTE) {
+if (PalettedTextures && mipmap >= 0 && trans == GLPNG_SOLID && color == PNG_COLOR_TYPE_PALETTE) {
 png_colorp pal;
 int cols;
 GLint intf;
@@ -517,7 +517,7 @@
 }
 else
 #endif
-if (trans == PNG_SOLID || trans == PNG_ALPHA || color == PNG_COLOR_TYPE_RGB_ALPHA || color == PNG_COLOR_TYPE_GRAY_ALPHA) {
+if (trans == GLPNG_SOLID || trans == GLPNG_ALPHA || color == PNG_COLOR_TYPE_RGB_ALPHA || color == PNG_COLOR_TYPE_GRAY_ALPHA) {
 GLenum glformat;
 GLint glcomponent;
 
@@ -542,9 +542,9 @@
 return 0;
 }
 
-if (mipmap == PNG_BUILDMIPMAPS)
+if (mipmap == GLPNG_BUILDMIPMAPS)
 Build2DMipmaps(glcomponent, width, height, glformat, data, 1);
-

Bug#729543: ldap-git-backup: different filename options

[Elmar Heeb]

On 14.Nov.2013, at 09:22 , Elmar Heeb  wrote:
> 
> I am not quite sure how I would handle the transition from the current scheme 
> to the new one.

Note to self: the transition is actually no problem.  Just let git handle it.  
It will just be a more extensive commit.



signature.asc
Description: Message signed with OpenPGP using GPGMail

Bug#729543: ldap-git-backup: different filename options

[Elmar Heeb]

Hi

On 14.Nov.2013, at 03:50 , Paul Wise  wrote:

> Package: ldap-git-backup
> Version: 1.0.6-2
> Severity: wishlist
> 
> It would be interesting to have some different options for filenames.

This is indeed an interesting idea.

> One option based on ldif files:
> 
> org.ldif
> org/debian.ldif
> org/debian/users.ldif
> org/debian/users/pabs.ldif
> org/debian/hosts.ldif
> org/debian/hosts/ravel.ldif

We could have a hook that, given a ldif file, it should generate a file name 
(potentially including a path).

> One option based on plain files for each field. In this scheme when
> there are multiple fields of the same name you could create a directory
> and put numbers as filenames in there, or just put all the values in the
> same file, one per line.
> 
> org/debian/users/pabs/uid
> org/debian/users/pabs/uidNumber
> org/debian/users/pabs/objectClass/1
> org/debian/users/pabs/objectClass/2
> org/debian/users/pabs/labeledURI

This might also help git to create an even more compact repository as most 
attributes tend to retain their value over time.  On the other hand git is 
already pretty good in dealing with text files like ldif.  Using a directory 
structure for the attributes would certainly be convenient when browsing the 
backup.

I am not quite sure how I would handle the transition from the current scheme 
to the new one.

Anyway, thank you for the suggestions.  Things to ponder…

Yours — Elmar



signature.asc
Description: Message signed with OpenPGP using GPGMail

Bug#728183: Proposed workaround

[Elmar Dolgener]

Am 13.11.2013 12:46, schrieb Maximiliano Curia:
> In article 
> <527CB983.8040901__29266.5923982442$1383905906$gmane$o...@ipna.csic.es> you 
> wrote:
>> This bug has been reported upstream as 324000. Following some hints
>> there I succeeded to workaround it. Just:
>> rm ~/.kde/share/config/plasma-desktop-appletsrc
>> and restart session after.
>> I haven't deal deeper with that to identify the buggy stanza in there
>> though.
> Were you using plasma-widget-veromix as reported in the upstream bug or
> printer-applet (#729088) by any chance?
>
> Thanks for the report,

plasma-widget-veromix: NO (never ever heard of),
printer-applet: YES.

Just now I thereforde tried
# apt-get remove system-config-printer-kde
afterwards tried to start
$ plasma-desktop
And still the same: "KCrash: Application 'plasma-desktop' crashing..."

I would really try to dig into this (identify the relevant cause(s) ), but 
don't know how to manage that in a deftly manner.





-- 

Elmar Dolgener [Tel. 09131-85-25252, Fax -29931, Zi. 01.141]
Lehrstuhl fuer Informatik 9 (Graphische Datenverarbeitung)
Universitaet Erlangen-Nuernberg, Cauerstr. 11, 91058 Erlangen
http://www9.informatik.uni-erlangen.de/people/card/elmar/dolgener


signature.asc
Description: OpenPGP digital signature

Bug#728716: RFS: xchroot/2.3.3-3 [ITP] -- extended chroot with X11/Xorg forwarding and aufs/unionfs support for read only roots

[Elmar Stellnberger]

Am 12.11.2013 10:24, schrieb Andrew Shadura:

Hello,

On 12 November 2013 10:22, Elmar Stellnberger  wrote:

O.K. That is actually what is to be done next.
There are some people whom I know and who I am going to consult.
It will at last be necessary in my very own interest to assert that the
license will work in practice as intended.
I hope you are going to accept the results if and only if I consult
someone who is a lawyer.
Again, thanks for your contribution to the license. It was actually
necessary to make it fit for practical usage.

Unfortunately, it's still unfit for use.


Could you tell me in a short why you do think so.


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

Bug#728716: RFS: xchroot/2.3.3-3 [ITP] -- extended chroot with X11/Xorg forwarding and aufs/unionfs support for read only roots

[Elmar Stellnberger]

O.K. That is actually what is to be done next.
There are some people whom I know and who I am going to consult.
It will at last be necessary in my very own interest to assert that the
license will work in practice as intended.
I hope you are going to accept the results if and only if I consult
someone who is a lawyer.
Again, thanks for your contribution to the license. It was actually
necessary to make it fit for practical usage.

Yours Sincerely,
Elmar Stellnberger

P.S. I hope my postings to the OSI license-discuss mailing list
from last week will get posted soon.

Am 12.11.2013 07:41, schrieb Bart Martens:

Hi Elmar,

It's OK that you write your own non-free license, but this license in
particular has, in my opinion, too many serious flaws to allow it in section
non-free.  I suggest to get professional legal advice or to use an existing
well-known license.

Regards,

Bart Martens



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

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

[Elmar Stellnberger]

Dear Gergely Nagy, Dear members of Debian-legal

   Do you know a license somehow similar in spirit than mine which I 
could use?
It would be nice to have something that oblidges 'closed distributions' 
to publish
at least their sources as required by some software in RHEL which is 
what puts

the CentOS distribution for the broad public into live.

Thanks for Your Review,
Elmar


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

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

[Elmar Stellnberger]

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

  Having clearly considered your critics I have published a reworked 
edition

of S-FSL which should more strictly adhere to the terms of OSS-software.
As you can understand and as I have already partially described there are
still issues to me which discourage me from using an existing license like
f.i. GPL or BSD.

  The new license is posted here for public review.


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

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

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

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

Now nothing that can be called a 'public distribution' needs to send out
patches. The patches as well as the patched programs do automatically
become subject to the same license.

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

Furthermore, there's this part of the license:

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

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

now the term separate branch is clearly defined. It means publishing under
a different name(ing convention).



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

that loophole has been eliminated; thx.



Going further:

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

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

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

'exception' can now be any software or additional service as long as
xchroot is not distributed outside of a distribution;
that should suffice.



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

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

replaced by and/or; forgetting about docs should no more matter


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

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

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

[Elmar Stellnberger]

Am 04.11.13 18:43, schrieb Paul Tagliamonte:




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


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

Perhaps you're interesting in reading our guidelines:

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

point 8 is "License Must Not Be Specific to Debian".

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



> However what I want is being noticed somehow about changed versions
> of my programmes.

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

I hope that will not pose an unnecessary restriction to the 
re-distribution as

the program may f.i. also be especially useful under the rescue-console.



> This is to collect new use cases and get updates quickly
> incorporated (Early versions of
> my program were heavily rewritten and patched as googeling has
> shown; though that time
> not even granted explicitly.). Being notified by third party users
> about their concerns and
> changes would yield major contribution to the future development.
> (There are no copyright
> issues though since the actual code added by me so far has been
> completely different from
> the diversions found out there; though it has been very useful in
> extracting new use cases.).

> >  o One may not change for the software (or use it in a
commercial product),
> >or be used *from* non-free software as a plugin (etc). The
phrasing
> >in here is odd.

> Well this is already the standard for the GPL-license: GPL programs
> as far as being
> compiled can not be incorporated into commercial software; you have
> to use L-GPL.
> Why not establish a similar standard for protecting intellectual
> property also for
> programs written in a script language? (i.e. this is the reason why
> I called it S-FSL).

That's not true; commercial software *can be paid software*. So
long as


can be free software* (sorry!)

the software is compatable (and the work on the whole is
distributed as
GPL), this isn't a problem.

Please, if you don't know how the GPL works, I have to strongly insist
on you not writing your own license.


  Oops there we have an error! (Well I clearly know how it works with GPL.)
Commercial software does not need to be paid software. Well, to me a
similar restriction like for GPL could be very handy: having to put all 
of the

software under any OSS-compliant license as soon as an S-FSL program
is incorporated (That would also limit possible interference with other
licenses).
Would that be acceptible?



> If the phrasing is odd we will have to rework it; it is my intention
> to have a license
> clear to everyone; not only to lawyers.
> >
> >I strongly encourage you to not write your own license terms.
Please
> >consider using a well-known and understood license.
>
> Well to me it is an issue under which license to publish. I do not
> want to burden
> my distributor unncessarily but actually want to retain as much
> rights as possible
> because writing, maintaining the software and supporting also casual
> users is a
> major effort.

It's a lot more effort for the distributors to review this license and
    attempt to figure out how it applies in different jursidictions, with
other licenses and how to properly comply.

> >
> >Cheers,
> >   Paul
>
> Many Thanks for your Commitment,
> Elmar

Cheers,
  Paul

--
 .''`.  Paul Tagliamonte mailto:paul...@debian.org>>
: :'  : Proud Debian Developer
`. `'`  4096R / 8F04 9AD8 2C92 066C 7352  D28A 7B58 5B30 807C 2A87
 `- http://people.debian.org/~paultag
<http://people.debian.org/%7Epaultag>




--
:wq


Cheers and Thx for Your Contribution,
Elmar

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

[Elmar Stellnberger]

Am 04.11.13 18:43, schrieb Paul Tagliamonte:




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


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

Perhaps you're interesting in reading our guidelines:

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

point 8 is "License Must Not Be Specific to Debian".

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



> However what I want is being noticed somehow about changed versions
> of my programmes.

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

I hope that will not pose an unnecessary restriction to the 
re-distribution as

the program may f.i. also be especially useful under the rescue-console.



> This is to collect new use cases and get updates quickly
> incorporated (Early versions of
> my program were heavily rewritten and patched as googeling has
> shown; though that time
> not even granted explicitly.). Being notified by third party users
> about their concerns and
> changes would yield major contribution to the future development.
> (There are no copyright
> issues though since the actual code added by me so far has been
> completely different from
> the diversions found out there; though it has been very useful in
> extracting new use cases.).

> >  o One may not change for the software (or use it in a
commercial product),
> >or be used *from* non-free software as a plugin (etc). The
phrasing
> >in here is odd.

> Well this is already the standard for the GPL-license: GPL programs
> as far as being
> compiled can not be incorporated into commercial software; you have
> to use L-GPL.
> Why not establish a similar standard for protecting intellectual
> property also for
> programs written in a script language? (i.e. this is the reason why
> I called it S-FSL).

That's not true; commercial software *can be paid software*. So
long as


can be free software* (sorry!)

the software is compatable (and the work on the whole is
distributed as
GPL), this isn't a problem.

Please, if you don't know how the GPL works, I have to strongly insist
on you not writing your own license.


  Oops there we have an error! (Well I clearly know how it works with GPL.)
Commercial software does not need to be paid software. Well, to me a
similar restriction like for GPL could be very handy: having to put all 
of the

software under any OSS-compliant license as soon as an S-FSL program
is incorporated (That would also limit possible interference with other
licenses).
Would that be acceptible?



> If the phrasing is odd we will have to rework it; it is my intention
> to have a license
> clear to everyone; not only to lawyers.
> >
> >I strongly encourage you to not write your own license terms.
Please
> >consider using a well-known and understood license.
>
> Well to me it is an issue under which license to publish. I do not
> want to burden
> my distributor unncessarily but actually want to retain as much
> rights as possible
> because writing, maintaining the software and supporting also casual
> users is a
> major effort.

It's a lot more effort for the distributors to review this license and
    attempt to figure out how it applies in different jursidictions, with
other licenses and how to properly comply.

> >
> >Cheers,
> >   Paul
>
> Many Thanks for your Commitment,
> Elmar

Cheers,
  Paul

--
 .''`.  Paul Tagliamonte mailto:paul...@debian.org>>
: :'  : Proud Debian Developer
`. `'`  4096R / 8F04 9AD8 2C92 066C 7352  D28A 7B58 5B30 807C 2A87
 `- http://people.debian.org/~paultag
<http://people.debian.org/%7Epaultag>




--
:wq


Cheers and Thx for Your Contribution,
Elmar

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

[Elmar Stellnberger]

Am 04.11.13 17:56, schrieb Paul Tagliamonte:

Control: tag -1 moreinfo

On Mon, Nov 04, 2013 at 05:31:40PM +0100, Elmar Stellnberger wrote:

  The xchroot S-FSL v1.3.1 license would need some legal review. It was 
especially designed for
  distributions available free of charge like Debian. The license has been 
revised thouroughly
  and should not pose any restrictions concerning re-distribution by Debian 
or any other free
  distro. The author plans to publish more software under this or a 
reworked version of the
  S-FSL license.

This license will be considered non-free in Debian. Please re-upload
targeting non-free or change the license terms.

  o It forces distribution of changes to third parties.
Is it really a problem? If yes then I can add an exception for 
distributors like Debian.
However what I want is being noticed somehow about changed versions of 
my programmes.
This is to collect new use cases and get updates quickly incorporated 
(Early versions of
my program were heavily rewritten and patched as googeling has shown; 
though that time
not even granted explicitly.). Being notified by third party users about 
their concerns and
changes would yield major contribution to the future development. (There 
are no copyright
issues though since the actual code added by me so far has been 
completely different from
the diversions found out there; though it has been very useful in 
extracting new use cases.).

  o One may not change for the software (or use it in a commercial product),
or be used *from* non-free software as a plugin (etc). The phrasing
in here is odd.
Well this is already the standard for the GPL-license: GPL programs as 
far as being
compiled can not be incorporated into commercial software; you have to 
use L-GPL.
Why not establish a similar standard for protecting intellectual 
property also for
programs written in a script language? (i.e. this is the reason why I 
called it S-FSL).


If the phrasing is odd we will have to rework it; it is my intention to 
have a license

clear to everyone; not only to lawyers.


I strongly encourage you to not write your own license terms. Please
consider using a well-known and understood license.
Well to me it is an issue under which license to publish. I do not want 
to burden
my distributor unncessarily but actually want to retain as much rights 
as possible
because writing, maintaining the software and supporting also casual 
users is a

major effort.


Cheers,
   Paul


Many Thanks for your Commitment,
Elmar


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

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

[Elmar Stellnberger]

Package: sponsorship-requests
Subject: RFS: xchroot/2.3.2-9 [ITP] -- Hi Debian!
Severity: wishlist

Dear mentors,

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

 * Package name: xchroot
   Version : 2.3.2-9
   Upstream Author : Elmar Stellnberger 
 * URL : https://www.elstel.org/xchroot
 * License : S-FSL v1.3.1
   Section : x11

  It is a little convenience bash script with man page wrapped into a package:

xchroot - extended chroot with X11/Xorg forwarding and aufs/unionfs support 
for read only roots

  I am sure you will like it; also good for packaging with multiple OS versions.


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

  http://mentors.debian.net/package/xchroot


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

  dget -x 
http://mentors.debian.net/debian/pool/main/x/xchroot/xchroot_2.3.2-9.dsc

  More information about xchroot can be obtained from 
https://www.elstel.org/xchroot.

  Changes since the last upload:

Today I have fixed a lot of warnings shown by the pacakge evaluation of 
mentors

  Note:

The xchroot S-FSL v1.3.1 license would need some legal review. It was 
especially designed for
distributions available free of charge like Debian. The license has been 
revised thouroughly
and should not pose any restrictions concerning re-distribution by Debian 
or any other free
distro. The author plans to publish more software under this or a reworked 
version of the
S-FSL license.

  Kind Regards,
  Elmar Stellnberger

Bug#727023: ITP: xchroot -- extended chroot with X11/Xorg forwarding and aufs/unionfs support for read only roots

[Elmar Stellnberger]

Package: wnpp
Version: 2.3; issued 2013-08-28
Subject: ITP: xchroot -- extended chroot with X11/Xorg forwarding and 
aufs/unionfs support for read only roots

Severity: wishlist

* Package name : xchroot
Version : 2.3
Upstream Author : Elmar Stellnberger 
* URL : http://www.elstel.org/xchroot
* License : QPL-like; see for the program header or run the program with 
--license
Description : xchroot is a little convenience bash script that will 
allow you to run X-based programs in your chroot environment.
You may also chroot to a new environment without touching any of its 
files either by using aufs and unionfs. You
may backup your temporary changes on exit and kill of xchroot as 
squashfs and incrementally restore them.


--
note: xchroot is already packaged experimentally in the obs yet needing 
to be moved to mentors.debian.net (repo is referenced by 
www.elstel.org/xchroot).


why we should prefer packaging xchroot from elstel over xchroot from 
mosquito:
* the program is known to deliver good quality since years and is also 
officially recommended by the openSUSE build service guide
* the program is being actively developed; completely new features are 
planned.
* there is a good online documentation for the program which does also 
leverage usage by casual users and users new to Linux
* the incremental --save and --restore options not supported by mosquito 
will make life of packagers easy and leverage usage from read-only root 
file systems like roots on blue ray
* unionfs as well as aufs support guarantee for a broad applicability; 
f.i. when dual booting between a distribution that only supports unionfs

* support also for casual users

why we should not package xchroot from mosquito:
* no accomplished cleanup, kill -9 of processes, bugs and fallacies I do 
not want to talk about.
* writing a completely different program and then giving it the same 
name as an already existent program will confuse innocent users (mine 
has already been there for years and it has been published under the 
name xchroot for a much longer time.)

* the program has not been tested well under different conditions
* no unionfs, no socat, no incremental restore, no good automounting 
support.

* no backward compatibility with Debian 6.0.x
* the authors did not respond at all on my request to join the work on 
elstel and to put xchroot under a better, generally accepted license


License: should be oss-compliant; author wants patches to be officially 
acknowledged by elstel.org; i.e. to make them available to all users 
even those who continue to download xchroot directly and those who use 
another distro.


Download: may also use https

P.S.: I believe it would also be good choice to support this script 
under the rescue console. When chrooting to a Debian installation you 
will otherwise have to mount a lot while mounting everything of use is 
still too much for manual mounting. This is a very common task for 
maintenance activities; I even do that when running grub-install.

Bug#721447: RFP: xchroot -- extended chroot with X11/Xorg forwarding and aufs/unionfs support for read only roots

[Elmar Stellnberger]

Package: wnpp
Version: 2.3; issued 2013-08-28
Subject: RFP: xchroot -- extended chroot with X11/Xorg forwarding and 
aufs/unionfs support for read only roots

Severity: wishlist

* Package name : xchroot
Version : 2.3
Upstream Author : Elmar Stellnberger 
* URL : http://www.elstel.org/xchroot
* License : QPL-like; see for the program header or run the program with 
--license
Description : xchroot is a little convenience bash script that will 
allow you to run X-based programs in your chroot environment.
You may also chroot to a new environment without touching any of its 
files either by using aufs and unionfs. You
may backup your temporary changes on exit and kill of xchroot as 
squashfs and incrementally restore them.


--
xchroot will be simple to package:
chmod +x and copy the program to /sbin;
changelog, license, and contact address are currently located in the 
header of the bash script; license can be printed with xchroot --license
note: future versions may come as .tar.gz including sub-programs and a 
man page
(as long as there is no man page for xchroot you may simply package the 
index.html into /usr/share/doc)
you will get update notifications via http://www.elstel.org/elstel.rss 
(for xchroot among other content on elstel)


why you should prefer packaging xchroot from elstel over xchroot from 
mosquito:
* the program is known to deliver good quality since years and is also 
officially recommended by the openSUSE build service guide
* the program is being actively developed; completely new features are 
planned.
* there is a good online documentation for the program which does also 
leverage usage by casual users and users new to Linux
* the incremental --save and --restore options not supported by mosquito 
will make life of packagers easy and leverage usage from read-only root 
file systems like roots on blue ray
* unionfs as well as aufs support guarantee for a broad applicability; 
f.i. when dual booting between a distribution that only supports unionfs

* support also for casual users

why you should not package xchroot from mosquito:
* no accomplished cleanup, kill -9 of processes, bugs and fallacies I do 
not want to talk about.
* writing a completely different program and then giving it the same 
name as an already existent program will confuse innocent users (mine 
has already been there for years and it has been published under the 
name xchroot for a much longer time.)

* the program has not been tested well under different conditions
* no unionfs, no socat, no incremental restore, no good automounting 
support.

* no backward compatibility with Debian 6.0.x
* the authors did not respond at all on my request to join the work on 
elstel and to put xchroot under a better, generally accepted license


License: should be oss-compliant; author wants patches to be officially 
acknowledged by elstel.org; i.e. to make them available to all users 
even those who continue to download xchroot directly and those who use 
another distro.


Download: may also use https

P.S.: I believe it would also be good choice to support this script 
under the rescue console. When chrooting to a Debian installation you 
will otherwise have to mount a lot while mounting everything of use is 
still too much for manual mounting. This is a very common task for 
maintenance activities; I even do that when running grub-install.

Bug#720670: aptitude-robot: FTBFS with perl 5.18: test failures

[Elmar Heeb]

Control: tag -1 - unreproducible + confirmed
Control: retitle -1 FTBFS when only Moose is installed

On 25.Aug.2013, at 15:31 , gregor herrmann  wrote:
> On Sat, 24 Aug 2013 13:23:16 +0100, Dominic Hargreaves wrote:
>> TOPDIR=/build/dom-aptitude-robot_1.2.14-1-i386-p0IDb0/aptitude-robot-1.2.14 
>> prove -I/build/dom-aptitude-robot
>> _1.2.14-1-i386-p0IDb0/aptitude-robot-1.2.14 
>> /build/dom-aptitude-robot_1.2.14-1-i386-p0IDb0/aptitude-robot-1.2
>> .14/t
>> /build/dom-aptitude-robot_1.2.14-1-i386-p0IDb0/aptitude-robot-1.2.14/t/001_help-option.t
>>  . ok
>> Use of uninitialized value in concatenation (.) or string at 
>> /build/dom-aptitude-robot_1.2.14-1-i386-p0IDb0/a
>> ptitude-robot-1.2.14/aptitude-robot line 99.
>> Use of uninitialized value in concatenation (.) or string at 
>> /build/dom-aptitude-robot_1.2.14-1-i386-p0IDb0/a
>> ptitude-robot-1.2.14/aptitude-robot line 103.
>> 
>> #   Failed test 'check for error string'
>> #   at 
>> /build/dom-aptitude-robot_1.2.14-1-i386-p0IDb0/aptitude-robot-1.2.14/t/010_simple-calls.t
>>  line 22.
>> #  got: 'Error:  is not a aptitude-robot config directory'
>> # expected: 'Error: /dev/null is not a aptitude-robot config directory'
> 
> That's an interesting case, and I can't reproduce it.
> From the output above it looks like config_dir is not set, but I
> don't see how this can happen; and it doesn't seem to be Perl 5.18
> related.
> 
> Anyway, I'm sure Elmar and Axel know their code better and can come
> up with some insights :)

Finally, we could reproduce this bug.  It has nothing to do with perl 5.18 but 
with Moose vs. Mouse.

aptitude-robot uses Any::Moose which defaults to Mouse unless Moose is already 
installed on the system.  With Mouse it would run the tests without problems 
but with Moose (and no Mouse installed) we get exactly the errors Dominic 
reported.

We still need to find out why Moose would trigger these errors when Mouse does 
not.  Ultimately however, this is the motivation to replace Mouse with Moo, 
which was planned anyway.

Regards -- Elmar



signature.asc
Description: Message signed with OpenPGP using GPGMail

Bug#720904: zombies test (in misc) should indicate parent processes of zombies

[Elmar Heeb]

Package: hobbit-plugins
Version: 20120532
Severity: normal
Tags: patch
X-Debbugs-CC: el...@heebs.ch

Hi

When a system has a zombie process, it is the fault of the parent which does 
not reap the exit status.  Therefore, the zombies test in misc should indicate 
the parent as the culprit.  Likewise, whitelisting via the configuration in 
/etc/hobbit/zombies_ignore should apply to the parent.

The attached patch has been used at our site for more than a month and works 
reliably.  Axel knows the details.

Regards -- Elmar



zombies
Description: Binary data



signature.asc
Description: Message signed with OpenPGP using GPGMail

Bug#720472: add amavis-inject script to amavisd-new package

[Elmar Heeb]

On 22.Aug.2013, at 13:40 , Elmar Heeb  wrote:
> I suggest to add the old amavis-inject script from the amavis-ng package to 
> amavisd-new.  I have taken the script contained in the latest released 
> version of amavis-ng and adjusted it to work with amavisd-new.  The fixed 
> version is attached to this mail.

While I was at it, I refactored the script to use Email::Simple from CPAN.  
This makes the handling of headers more reliable.  There is an additional 
dependency on libemail-simple-perl.

The new version is attached.

Regards -- Elmar



amavis-inject
Description: Binary data



signature.asc
Description: Message signed with OpenPGP using GPGMail

Bug#720472: add amavis-inject script to amavisd-new package

[Elmar Heeb]

Package: amavisd-new
Severity: wishlist
X-Debbugs-CC: el...@heebs.ch

Hi

I suggest to add the old amavis-inject script from the amavis-ng package to 
amavisd-new.  I have taken the script contained in the latest released version 
of amavis-ng and adjusted it to work with amavisd-new.  The fixed version is 
attached to this mail.

I have also fixed the POD documentation in the script so that pod2man produces 
a proper man page.

Regards -- Elmar




amavis-inject
Description: Binary data



signature.asc
Description: Message signed with OpenPGP using GPGMail

Bug#693144: aptitude should honour explicit installation request in connection with markauto package

[Elmar S. Heeb]

Hello

On 11/14/2012 03:02 AM, Daniel Hartwig wrote:
> Note that you can not request of aptitude that a package “remains
> installed”.  You can only request to install, remove, mark manual
> (hint!), etc..  At best, the closest option is “keep”, however, that
> will not work in the example you describe.

Sorry for being vague in my wording.  With "remains installed" I just
wanted to point out the explicit install action that is specified on the
command line.  But anyway, we agree on that issue.

> In the past, it was considered convenient to allow users to upgrade
> packages using “aptitude install foo”, without altering the
> auto-installed state.  However, current apt thinking is that “install”
> should always mark the requested packages as manually installed.  That
> is the default behaviour in libapt-pkg, as used by apt-get, etc..

This puzzled me initially too but as soon as I realized that an install
request does not change the auto-installed state I had no problem with
this behaviour.  This was in fact the motivation to specify a package
explicitly on the command line which would otherwise be autoremoved.

BTW, I am fine with either behaviour but I would strongly vote for a
consistent policy between apt and aptitude.

> What you really want is to mark it as manually installed:
> 
> # aptitude install rsstail- openssl&m

I am aware of this option.  I don't like it because I have to issue a
different command depending on whether openssl is installed or not.  If
I could run

   aptitude install rsstail- openssl+m

it would solve my problem.  However +m is not a supported action (as
opposed to +M).

> The request to install openssl is not ignored, although it has no
> effect, because aptitude processes that install request *before* it
> decides to remove packages that are no longer required.

Interestingly, the interactive behaviour is different here from the one
on the command line.  If I hit '-' on rsstail and the '+' on openssl it
would keep openssl and mark it as manually installed.

Regards, -- Elmar


-- 
Elmar Heeb   Tel-M: +41 79 628 7524
Bläsistrasse 49  Tel-P: +41 44 342 0168
CH-8049 Zürich   Tel-G: +41 44 633 2591


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

Bug#693144: aptitude should honour explicit installation request in connection with markauto package

[Elmar S. Heeb]

Package: aptitude
Version: 0.6.8.2-1
Severity: normal

Hi

If I deinstall a package aptitude will correctly deinstall all
dependencies which are markauto and not required by any other package.
However, if I explicitly request that such a dependent package remains
installed aptitude will still deinstall it.

Example:

Take a squeeze or sid base installation and install rsstail which
requires openssl (among others)
  aptitude install rsstail

Sometime later decide that you don't need rsstail anymore but that you
want to keep openssl
  aptitude install rsstail- openssl+

Since openssl was installed as a dependency it is markauto as far as
aptitudes package state database is concerned.  The explicit request to
install openssl (with the + action) is still ignored.  If I execute the
same command (the latter of the two) a second time, openssl will be
installed again.

Regards,     -- Elmar

-- 
Elmar Heeb   Tel-M: +41 79 628 7524
Bläsistrasse 49  Tel-P: +41 44 342 0168
CH-8049 Zürich   Tel-G: +41 44 633 2591


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

Bug#693131: xen-tools: DomUs should use noop scheduler by default

[Elmar S. Heeb]

Package: xen-tools
Severity: wishlist

Hi

For virtual machines the Dom0 already does the IO scheduling.  The DomUs
should use the simplest scheduling, namely noop.  Anything else requires
advanced knowledge of IO schedulers and good coordination between the
schedulers in the Dom0, the DomUs and possibly the underlying RAID
configuration.

Setting the default for new DomUs is easy to fix.  Just append the line

  extra = 'elevator=noop'

to the file /etc/xen-tools/xm.tmpl

Changing the config files of existing DomUs should be at the discretion
of the admin :-)

Regards,     -- Elmar


-- 
Elmar Heeb   Tel-M: +41 79 628 7524
Bläsistrasse 49  Tel-P: +41 44 342 0168
CH-8049 Zürich   Tel-G: +41 44 633 2591


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

Bug#692499: arb: FTBFS on armhf [PATCH]

[Elmar Pruesse]

Hi Konstantinos!

I suppose you've got no objections against me merging the one-line fix
to GBS_reuse_buffer in the upstream svn/trunk. Would you prefer to be
mentioned or not mentioned?

Elmar


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

Bug#690157: ITP: aptitude-robot -- Automate package choice management

[Elmar S. Heeb]

Package: wnpp
Owner: "Elmar S. Heeb" 
Severity: wishlist
X-Debbugs-CC: aptitude-de...@lists.alioth.debian.org,
debian-de...@lists.debian.org

* Package name: aptitude-robot
  Version : 1.0
  Upstream Author : "Elmar S. Heeb" 
* URL : https://github.com/elmar/aptitude-robot
* License : GPL-3+
  Programming Lang: Perl
  Description : Automate package choice management

Framework to use aptitude for automated package management including
upgrade, installation, removal, hold, etc.  Allows you to automate what
you would manually do with aptitude.


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