Bug#932909: Bug #932909: xchroot/2.7.5-1 [ITP] -- extended chroot with X11/Xorg forwarding
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
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#941993: cheese: Pixart Imaging, Inc. Typhoon Easycam USB 330K does no more work with cheese
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#941993: common libraries these programs depend on
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
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#941993: cheese: Pixart Imaging, Inc. Typhoon Easycam USB 330K does no more work with cheese
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
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
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
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
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
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
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
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
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
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
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
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
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)
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
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)
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#913488: [pkg-gnupg-maint] Bug#913488: scdaemon: gnupg --card-status does not recognize smart card via usb reader
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
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#904612: packaging of qcoan fully revised
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]
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#838344: linux-image-4.6.0-1-amd64: allow a patch that makes elder radeon cards UltraHD ready
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
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!
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!
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!
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!
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!
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
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#817192: php5-cgi of version 5.6 tries to load libraries of version 5.4
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
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#762153: [Reproducible-builds] concrete steps for improving apt downloading security and privacy
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#762153: [Reproducible-builds] concrete steps for improving apt downloading security and privacy
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
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#728716: RFS: xchroot/2.3.3-3 [ITP] -- extended chroot with X11/Xorg forwarding and aufs/unionfs support for read only roots
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
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!
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!
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!
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!
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!
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!
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
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
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#670972: debian-installer: include remote-repo URIs for offline installations in /etc/apt/sources.list
Package: debian-installer Version: 20110106+squeeze3+b1 Severity: normal The remote-repo URIs should always get included into /etc/apt/sources.list on installation. It is possible that we install in a place without internet access and want to connect our computer later. Some security hints also suggest to always install offline and shut all services down before connecting the first time. Moreover we still have computers being offline most or all of the time. My suggestion simply is to put all remote repo URIs into /etc/apt/sources.list in any way also if the installation is proceeded offline. If we select offline or abort a connection attempt these lines should simply be commented out rather than fully deleted. We will also need them for computers kept 100% of the time offline since we can transport software to them via a USB disk or stick taking our sources.list and /var/lib/dpkg/status with us to feed apt with the necessary information for an offline installation. -- System Information: Debian Release: 6.0.3 Architecture: i386 (i686) Kernel: Linux 2.6.32-5-686 (SMP w/1 CPU core) Locale: LANG=de_AT.UTF-8, LC_CTYPE=de_AT.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#669358: hal causes the disk access led to blink regularely by eSATA BD burner
Subject: hal causes the disk access led to blink regularely by eSATA BD burner Package: hal Version: 0.5.14-3 Severity: normal Tags: squeeze As soon as my system enters runlevel 2 the disk access led is blinking every 2 seconds. This is caused by hal, exactly by hald-addon-storage. ps ax | grep hal ... 7901 ?S 0:00 hald-addon-acpi: listening on acpid socket /var/run/acpid.socket 7914 ?S 0:00 hald-addon-storage: polling /dev/sr1 (every 2 sec) 7915 ?S 0:00 hald-addon-storage: polling /dev/sr0 (every 2 sec) ... a kill 7915 helps. While the integrated BD drive (/dev/sr1) doesn`t cause this error my eSATA BD (/dev/sr0) does. -- System Information: Debian Release: 6.0.4 Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-5-amd64 (SMP w/2 CPU cores) Locale: LANG=de_AT.UTF-8, LC_CTYPE=de_AT.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages hal depends on: ii adduser3.112+nmu2add and remove users and groups ii dbus 1.2.24-4+squeeze1 simple interprocess messaging syst ii hal-info 20091130-1Hardware Abstraction Layer - fdi f ii libblkid1 2.17.2-9 block device id library ii libc6 2.11.3-2 Embedded GNU C Library: Shared lib ii libdbus-1-31.2.24-4+squeeze1 simple interprocess messaging syst ii libdbus-glib-1-2 0.88-2.1 simple interprocess messaging syst ii libexpat1 2.0.1-7 XML parsing C library - runtime li ii libglib2.0-0 2.24.2-1 The GLib library of C routines ii libhal-storage10.5.14-3 Hardware Abstraction Layer - share ii libhal10.5.14-3 Hardware Abstraction Layer - share ii libusb-0.1-4 2:0.1.12-16 userspace USB programming library ii lsb-base 3.2-23.2squeeze1 Linux Standard Base 3.2 init scrip ii mount 2.17.2-9 Tools for mounting and manipulatin ii pciutils 1:3.1.7-6 Linux PCI Utilities ii udev 164-3 /dev/ and hotplug management daemo ii usbutils 0.87-5squeeze1Linux USB utilities Versions of packages hal recommends: ii consolekit0.4.1-4framework for defining and trackin ii eject 2.1.5+deb1+cvs20081104-7.1 ejects CDs and operates CD- Changer ii pm-utils 1.3.0-3utilities and scripts for power ma Versions of packages hal suggests: pn gnome-device-manager (no description available) -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#511193: pciutils_2.2: no backport available for debian sarge.
Subject: pciutils_2.2: no backport available for debian sarge.
Package: pciutils
Version: 1:2.1.11-15
Severity: normal
*** Please type your report below this line ***
Using the backported package linux-image-xen-686_2.6.18+6~bpo.1
it becomes possible to paravirtualise debian sarge.
However it will not be possible to access the network because
of bug #422713 "lspci does not list anything (etch and dailies)".
Consequently a backport of pciutils_2.2 would be necessary
to make use of the backported xen kernel.
However such a backport does not seem to be available:
# apt-cache search pciutils/backports
# tail -1 /etc/apt/sources.list
deb http://www.backports.org/debian/ sarge-backports main
-- System Information:
Debian Release: 3.1
Architecture: i386 (x86_64)
Kernel: Linux 2.6.25.18-0.2-xen
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=locale: Cannot
set LC_CTYPE to default locale: No such file or directory
locale: Cannot set LC_MESSAGES to default locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory
ANSI_X3.4-1968)
Versions of packages pciutils depends on:
ii libc6 2.3.2.ds1-22sarge6 GNU C Library: Shared
libraries an
-- debconf information:
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LANGUAGE = (unset),
LC_ALL = (unset),
LANG = "de_DE.UTF-8"
are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").
locale: Cannot set LC_CTYPE to default locale: No such file or directory
locale: Cannot set LC_MESSAGES to default locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
