Bug#778363: ardour3: Segfault when importing a midi file
i can reproduce the problem. attached you can find a backtrace. however: the segfault seems to have gone in ardour-4 (as provided by the "ardour" package). i don't think fixing the problem is worth it, esp. since the "ardour3" package will be removed from the archives in the (near?) future. gfmrdsa IOhannes #0 __memcpy_sse2_unaligned () at ../sysdeps/x86_64/multiarch/memcpy-sse2-unaligned.S:33 #1 0x74c0e4b7 in ?? () from /usr/lib/x86_64-linux-gnu/libglibmm-2.4.so.1 #2 0x007b4a14 in Editor::add_sources(std::vector, std::allocator >, std::allocator, std::allocator > > >, std::vector, std::allocator > >&, long&, Editing::ImportDisposition, Editing::ImportMode, int, int, boost::shared_ptr&, bool) () #3 0x007b6a95 in Editor::import_sndfiles(std::vector, std::allocator >, std::allocator, std::allocator > > >, Editing::ImportDisposition, Editing::ImportMode, ARDOUR::SrcQuality, long&, int, int, boost::shared_ptr&, bool) () #4 0x007b6f39 in Editor::do_import(std::vector, std::allocator >, std::allocator, std::allocator > > >, Editing::ImportDisposition, Editing::ImportMode, ARDOUR::SrcQuality, long&) () #5 0x00c25bc3 in SoundFileOmega::do_something(int) () #6 0x74c0c6f8 in Glib::SignalProxyNormal::slot0_void_callback(_GObject*, void*) () from /usr/lib/x86_64-linux-gnu/libglibmm-2.4.so.1 #7 0x749722d5 in g_closure_invoke () from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 #8 0x74984342 in ?? () from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 #9 0x7498c698 in g_signal_emit_valist () from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 #10 0x7498c8ff in g_signal_emit () from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 #11 0x73c8e225 in ?? () from /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0 #12 0x74972504 in ?? () from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 #13 0x7498bfa7 in g_signal_emit_valist () from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 #14 0x7498c8ff in g_signal_emit () from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 #15 0x73c8d119 in ?? () from /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0 #16 0x73d33a7f in ?? () from /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0 #17 0x749722d5 in g_closure_invoke () from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 #18 0x74983f32 in ?? () from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 #19 0x7498c1a5 in g_signal_emit_valist () from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 #20 0x7498c8ff in g_signal_emit () from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 #21 0x73e4aecc in ?? () from /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0 Quit signature.asc Description: OpenPGP digital signature
Bug#692201: ardour: Segfaults when using the freezing regions
unable to reproduce this problem with ardour_1:4.2~dfsg-2 can you confirm that the problem has been fixed? gfmasrd IOhannes signature.asc Description: OpenPGP digital signature
Bug#799649: stk: ABI transition needed for libstdc++ v5
On 2015-09-21 14:54, Felipe Sateler wrote: > > Please go ahead. I do not know when I will have time to look at this, > so do not wait on me. afaik, sramacher has expressed his intention to take care of stk "tonight" (sent ~5 mins after simons mail) to take care of STK. so you might want to wait another day :-) fgamnsdr IOhannes
Bug#603177: pd-syslog: changing back from RFP to ITP
retitle 603177 ITP: pd-syslog -- syslog facilities for Pd owner 603177 ! thanks
Bug#795898: ITP: pd-tclpd -- Tcl objects for Pd
On 08/17/2015 10:07 PM, Marco d'Itri wrote: > On Aug 17, IOhannes m zmoelnig wrote: > >> This library allows to to write externals for Pd using the Tcl language. > In this and the other packages maybe it would be a good idea to expand > the "Pd" acronym at least once? > good idea. thanks. gfamdsr IOhannes signature.asc Description: OpenPGP digital signature
Bug#857910: gsequencer: GObject::dispose() is not implemented
severity -1 serious thanks. Message-ID: <149069136526.17474.11614453442888250327.reportbug@xenakis.iemnet> X-Mailer: reportbug 7.1.5 Date: Tue, 28 Mar 2017 10:56:05 +0200 Package: src:gsequencer Followup-For: Bug #857910 justification: gsequencer appears to be not-yet releasable. after a major post-freeze upload that fixed numerous memory leaks and threading issues, the package has assembled another 10 severe issues during the last few weeks. assuming that there are a number of yet-unknown similar issues, i conclude that gsequencer is not in a state fit for release as debian stable yet. -- System Information: Debian Release: 9.0 APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'stable-updates'), (500, 'unstable'), (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.8.0-2-amd64 (SMP w/8 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)
Bug#857910: gsequencer: GObject::dispose() is not implemented
Package: src:gsequencer Followup-For: Bug #857910 Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? * What exactly did you do (or not do) that was effective (or ineffective)? * What was the outcome of this action? * What outcome did you expect instead? *** End of the template - remove these template lines *** gsequencer appears to be not-yet releasable. after a major post-freeze upload that fixed numerous memory leaks and threading issues, the package has assembled another 10 severe issues during the last few weeks. assuming that there are a number of yet-unknown similar issues, i conclude that gsequencer is not in a state fit for release as debian stable yet. -- System Information: Debian Release: 9.0 APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'stable-updates'), (500, 'unstable'), (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.8.0-2-amd64 (SMP w/8 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)
Bug#858771: icedove: migration fails if $HOME is a symlink
Package: icedove
Version: 1:45.8.0-2
Followup-For: Bug #858771
Dear Maintainer,
i was going to report that thunderbird fails to start if:
${HOME}/.thunderbird is a symlink to ${HOME}/.iceweasel
AND
${HOME} is a symlink itself.
the reason being that `readlink -e` is resolving both the .thunderbird symlink
and the ${HOME} symlink, thus invalidating the comparision (${HOME} != expanded
${HOME}).
it seems that the fix proposed by thomas fixes this.
one more note though (i haven't had a look at the pending upload so it might be
obsolete):
i think you can simplify the logic quite a bit from checking whether one if
${ID_PROFILE_FOLDER} resp ${TB_PROFILE_FOLDER} is a directory and the other a
symlink pointing to it AND vice-versa, to just do a single comparision whether
they actually resolve to the same path (not caring about which of the two is the
real directory; also allowing for both to be a symlink to some 3rd directory)
resp. that they don't resolve to the same path.
see attachment
--- thunderbird.org 2017-03-28 14:54:38.528598030 +0200
+++ thunderbird 2017-03-28 14:59:31.602320302 +0200
@@ -164,10 +164,12 @@
# We found both profile folder, and .thunderbird is a symlink,
# we need to check if .thunderbird is symlinked to .icedove
-if { [ -d "${ID_PROFILE_FOLDER}" ] && [ -L "${TB_PROFILE_FOLDER}" ]; } && \
- [ "$(readlink -e "${TB_PROFILE_FOLDER}")" = "${ID_PROFILE_FOLDER}" ];then
+if { [ -d "${ID_PROFILE_FOLDER}" ] || [ -L "${ID_PROFILE_FOLDER}" ]; } && \
+ { [ -d "${TB_PROFILE_FOLDER}" ] || [ -L "${TB_PROFILE_FOLDER}" ]; }; then
-output_debug "Found folder ${ID_PROFILE_FOLDER}, found a symlink
${TB_PROFILE_FOLDER} pointing to ${ID_PROFILE_FOLDER}"
+ if [ "$(readlink -e "${TB_PROFILE_FOLDER}")" = "$(readlink -e
"${ID_PROFILE_FOLDER}")" ];then
+
+output_debug "Both ${ID_PROFILE_FOLDER} and ${TB_PROFILE_FOLDER} resolve
to $(readlink -e ${ID_PROFILE_FOLDER})"
# Check if we need to do some migration, the linking could be existing
# before we switched back to Thunderbird.
@@ -180,31 +182,11 @@
do_migrate_old_icedove_desktop
fi
-# ... or the opposite if .icedove is symlinked to .thunderbird
-elif { [ -d "${TB_PROFILE_FOLDER}" ] && [ -L "${ID_PROFILE_FOLDER}" ]; } && \
- [ "$(readlink -e "${ID_PROFILE_FOLDER}")" = "${TB_PROFILE_FOLDER}" ];then
-
-output_debug "Found folder ${TB_PROFILE_FOLDER}, found a symlink
${ID_PROFILE_FOLDER} pointing to ${TB_PROFILE_FOLDER}"
-output_debug "You may want to remove the symlink ${ID_PROFILE_FOLDER}?
It's probably not needed anymore."
-
-# Check if we need to do some migration ...
-if [ ! -f "${TB_PROFILE_FOLDER}/.migrated" ]; then
-# Fixing mimeTypes.rdf which may have registered the iceweasel binary
-# as browser, instead of x-www-browser
-do_fix_mimetypes_rdf
-
-# Fix local mimeapps.list and *.desktop entries
-do_migrate_old_icedove_desktop
-fi
-
# We found both profile folder, but they are not linked to each other! This
# is a state we can't solve on our own !!! The user needs to interact and
# has probably an old or otherwise used Thunderbird installation. Which one
# is the correct one to use?
-elif { [ -d "${ID_PROFILE_FOLDER}" ] || [ -L "${ID_PROFILE_FOLDER}" ]; } && \
- { [ -d "${TB_PROFILE_FOLDER}" ] || [ -L "${TB_PROFILE_FOLDER}" ]; } && \
- [ "$(readlink -e "${TB_PROFILE_FOLDER}")" != "${ID_PROFILE_FOLDER}" ];
then
-
+ elif [ "$(readlink -e "${TB_PROFILE_FOLDER}")" != "$(readlink -e
"${ID_PROFILE_FOLDER}")" ];then
for CHECK in ${ID_PROFILE_FOLDER} ${TB_PROFILE_FOLDER}; do
FILE_CHECK=$(readlink -e "${CHECK}")
if [ "${FILE_CHECK}" != "" ] && [ -L "${CHECK}" ]; then
@@ -225,6 +207,7 @@
# display a graphical advice if possible
do_thunderbird2icedove_error_out
+ fi
fi
if [ "${FAIL}" = 1 ]; then
Bug#792720: pd-ggee: array_getfloat() is buggy in 64bit environments
Control: Severity -1 important thanks escalating this, as it really makes parts of the library unusable on amd64 (which - after all - is the most prominent arch). dasr IOhannes signature.asc Description: OpenPGP digital signature
Bug#341811: audacity: Clicking "Stop" after recording makes the program hang
Control: Tags -1 moreinfo Thanks Thanks Frédéric for the additional info. since the original bug is about 10 years old, i don't think that you have the very same setup as the original reporter (OSS?). esp, it would be interesting to know which audio backend you are using (alsa, jack, pulseaudio,...?). could you provide the contents of your ~/.audacity-data/audacity.cfg file? also, could you please provide a step-by-step guide to reproduce the problem? something like "Start audacity via the menu; Click on Record; ..." would be great. gamrds IOhannes On Mon, 13 Mar 2017 12:22:09 +0100 =?utf-8?b?RnLDqWTDqXJpYyBNZXNwbMOoZGU=?= wrote: > Package: audacity > Version: 2.0.6-2 > Followup-For: Bug #341811 > > Dear Maintainer, > > Each time I stop a recording while playing, audacity hangs. > Thank you for your work. > > > > -- System Information: > Debian Release: 8.7 > APT prefers stable-updates > APT policy: (500, 'stable-updates'), (500, 'stable') > Architecture: amd64 (x86_64) > Foreign Architectures: i386 > > Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores) > Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8) > Shell: /bin/sh linked to /bin/dash > Init: systemd (via /run/systemd/system) > > Versions of packages audacity depends on: > ii audacity-data 2.0.6-2 > ii libasound21.0.28-1 > ii libavcodec56 10:2.6.9-dmo1 > ii libavformat56 10:2.6.9-dmo1 > ii libavutil54 10:2.6.9-dmo1 > ii libc6 2.19-18+deb8u7 > ii libexpat1 2.1.0-6+deb8u3 > ii libflac++61.3.0-3 > ii libflac8 1.3.0-3 > ii libgcc1 1:4.9.2-10 > ii libglib2.0-0 2.42.1-1+b1 > ii libid3tag00.15.1b-11 > ii libmad0 0.15.1b-8 > ii libmp3lame0 1:3.99.5-dmo4 > ii libogg0 1.3.2-1 > ii libportaudio2 19+svn20140130-1 > ii libportsmf0 0.1~svn20101010-4 > ii libsbsms102.0.2-1 > ii libsndfile1 1.0.25-9.1+deb8u1 > ii libsoundtouch01.8.0-1 > ii libsoxr0 0.1.1-1 > ii libstdc++64.9.2-10 > ii libtwolame0 0.3.13-1.1 > ii libvamp-hostsdk3 1:2.5-dmo6 > ii libvorbis0a 1.3.4-2 > ii libvorbisenc2 1.3.4-2 > ii libvorbisfile31.3.4-2 > ii libwxbase3.0-03.0.2-1+b1 > ii libwxgtk3.0-0 3.0.2-1+b1 > > audacity recommends no packages. > > Versions of packages audacity suggests: > pn ladspa-plugin > > -- no debconf information signature.asc Description: OpenPGP digital signature
Bug#857717: unblock: pd-iemmatrix/0.3-3
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Please unblock package pd-iemmatrix
the purpose of this upload is to get rid of the versioned build-dependency on
'automake1.11' (and use the generic 'automake' instead), in accordance to the
recent announcement on debian-devel wrt mass bug filing.
admittedly this is a minor upload.
unblock pd-iemmatrix/0.3-3
-- System Information:
Debian Release: 9.0
APT prefers unstable-debug
APT policy: (500, 'unstable-debug'), (500, 'testing-debug'), (500,
'stable-updates'), (500, 'unstable'), (500, 'testing'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.8.0-2-amd64 (SMP w/8 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)
diff -Nru pd-iemmatrix-0.3/debian/changelog pd-iemmatrix-0.3/debian/changelog
--- pd-iemmatrix-0.3/debian/changelog 2015-12-01 13:32:58.0 +0100
+++ pd-iemmatrix-0.3/debian/changelog 2017-03-14 09:26:54.0 +0100
@@ -1,3 +1,11 @@
+pd-iemmatrix (0.3-3) unstable; urgency=medium
+
+ * Dropped versioned dependency on automake
+ * Canonical Vcs-Git stanza
+ * Bumped standards version to 3.9.8
+
+ -- IOhannes m zmölnig (Debian/GNU) Tue, 14 Mar 2017
09:26:54 +0100
+
pd-iemmatrix (0.3-2) unstable; urgency=medium
* Fallback B-D on libgsl0-dev
diff -Nru pd-iemmatrix-0.3/debian/control pd-iemmatrix-0.3/debian/control
--- pd-iemmatrix-0.3/debian/control 2015-12-01 13:34:26.0 +0100
+++ pd-iemmatrix-0.3/debian/control 2017-03-14 09:26:54.0 +0100
@@ -3,29 +3,30 @@
Maintainer: Debian Multimedia Maintainers
Uploaders: Roman Haefeli ,
IOhannes m zmölnig (Debian/GNU) ,
- Jonas Smedegaard
-Build-Depends: cdbs (>= 0.4.91~),
+ Jonas Smedegaard ,
+Build-Depends: cdbs (>= 0.4.123~),
+ autotools-dev,
debhelper,
dh-buildinfo,
- automake1.11,
+ automake,
autoconf,
dh-autoreconf,
- devscripts,
+ licensecheck,
puredata-dev | puredata,
libfftw3-dev,
libsndfile1-dev,
- libgsl-dev | libgsl0-dev
-Standards-Version: 3.9.6
+ libgsl-dev | libgsl0-dev,
+Standards-Version: 3.9.8
Section: sound
Homepage: https://git.iem.at/pd/iemmatrix
-Vcs-Git: git://anonscm.debian.org/pkg-multimedia/pd-iemmatrix
+Vcs-Git: https://anonscm.debian.org/git/pkg-multimedia/pd-iemmatrix.git
Vcs-Browser: https://anonscm.debian.org/cgit/pkg-multimedia/pd-iemmatrix.git
Package: pd-iemmatrix
Architecture: any
Depends: ${shlibs:Depends},
${misc:Depends},
- puredata | pd
+ puredata | pd,
Description: Pd-objects for simple matrix operations
This library contains about 100 objects for matrix manipulation within
the dataflow language Pure Data.
diff -Nru pd-iemmatrix-0.3/debian/control.in pd-iemmatrix-0.3/debian/control.in
--- pd-iemmatrix-0.3/debian/control.in 2015-12-01 13:31:56.0 +0100
+++ pd-iemmatrix-0.3/debian/control.in 2017-03-14 09:25:04.0 +0100
@@ -3,23 +3,23 @@
Maintainer: Debian Multimedia Maintainers
Uploaders: Roman Haefeli ,
IOhannes m zmölnig (Debian/GNU) ,
- Jonas Smedegaard
+ Jonas Smedegaard ,
Build-Depends: @cdbs@,
puredata-dev | puredata,
libfftw3-dev,
libsndfile1-dev,
- libgsl-dev | libgsl0-dev
-Standards-Version: 3.9.6
+ libgsl-dev | libgsl0-dev,
+Standards-Version: 3.9.8
Section: sound
Homepage: https://git.iem.at/pd/iemmatrix
-Vcs-Git: git://anonscm.debian.org/pkg-multimedia/pd-iemmatrix
+Vcs-Git: https://anonscm.debian.org/git/pkg-multimedia/pd-iemmatrix.git
Vcs-Browser: https://anonscm.debian.org/cgit/pkg-multimedia/pd-iemmatrix.git
Package: pd-iemmatrix
Architecture: any
Depends: ${shlibs:Depends},
${misc:Depends},
- puredata | pd
+ puredata | pd,
Description: Pd-objects for simple matrix operations
This library contains about 100 objects for matrix manipulation within
the dataflow language Pure Data.
diff -Nru pd-iemmatrix-0.3/debian/copyright_hints
pd-iemmatrix-0.3/debian/copyright_hints
--- pd-iemmatrix-0.3/debian/copyright_hints 2015-11-12 20:37:43.0
+0100
+++ pd-iemmatrix-0.3/debian/copyright_hints 2017-03-14 09:26:54.0
+0100
@@ -574,7 +574,7 @@
tests/runtests.txt
tests/runtests_nogui.pd
tests/testunit.pd
-Copyright: *No copyright*
+Copyright: NONE
License: UNKNOWN
FIXME
@@ -641,7 +641,7 @@
src/mtx_trace.c
src/mtx_transpose.c
src/mtx_zeros.c
-Copyright: IOhannes m zmölnig, forum::für::umläute
+Copyright: IOhannes m zmölnig, forum::für::umläute
License: UNKNOWN
FIXME
@@ -661,8 +661,6 @@
src/mtx_index.c
src/mtx_minmax.c
src/mtx_qhull.c
- src/mtx_qhull/list.c
- src/mtx_qhull/list.h
src/mtx_qhull/vectors.c
src/mtx_qhull/vectors.h
src/mtx_qhull/zhull.c
@@ -691,34 +689,31 @@
License: UNKNOWN
FIXME
-Files: m4/iem_fat.m4
- m4/iem_operatingsystem.m4
+Files: m4/iem_checkflags.m4
+ m4/iem_fat.m4
m4/
Bug#857868: unblock: pd-mediasettings/0.1.1-2
Control: tags -1 - moreinfo thanks On 2017-03-15 21:15, Emilio Pozuelo Monfort wrote: > Control: tags -1 confirmed moreinfo > > On 15/03/17 21:04, IOhannes m zmoelnig wrote: >> Package: release.debian.org >> Severity: normal >> User: release.debian@packages.debian.org >> Usertags: unblock >> >> Please unblock package pd-mediasettings >> >> this fixes a recently discovered piuparts issue (dangling symlinks). >> it also fixes minor documentation issues (spelling errors in long desc). >> since this is a leave package, impact should be minimal. >> >> unblock pd-mediasettings/0.1.1-2 > > I don't see 0.1.1-2 in unstable. Please go ahead and remove the moreinfo tag > once the package is uploaded and built on all release architectures. oops sorry. it was the outcome of a somewhat streamlined workflow on my side, (uploading source-only and immediately filing an unblock request) which didn't take into account that the release team would react so fast (instead hoping that by the time someone would look at the unblock request, the package would be properly available. i see however, that its not much fun on your side if you have to look into unblock request which miss important parts. anyhow. the package is now built on all archs and has entered unstable. thanks for your work! gfad IOhannes
Bug#857908: python3-tlslite-ng: should recommend python3-ecdsa
Package: python3-tlslite-ng Version: 0.6.0-1 Severity: important Dear Maintainer, i was trying to use python3-tlslite-ng to parse some X.509 certificates (which didn't work out anyhow, but that's a different story). so i did `aptitude install python3-tlslite-ng` and fired up a python-session: ~~~ $ python3 Python 3.5.3 (default, Jan 19 2017, 14:11:04) [GCC 6.3.0 20170118] on linux Type "help", "copyright", "credits" or "license" for more information. >>> import ssl, socket >>> from tlslite import X509 Traceback (most recent call last): File "", line 1, in File "/usr/lib/python3/dist-packages/tlslite/__init__.py", line 27, in from tlslite.api import * File "/usr/lib/python3/dist-packages/tlslite/api.py", line 7, in from .checker import Checker File "/usr/lib/python3/dist-packages/tlslite/checker.py", line 6, in from .x509 import X509 File "/usr/lib/python3/dist-packages/tlslite/x509.py", line 9, in from .utils.asn1parser import ASN1Parser File "/usr/lib/python3/dist-packages/tlslite/utils/asn1parser.py", line 7, in from .compat import * File "/usr/lib/python3/dist-packages/tlslite/utils/compat.py", line 11, in import ecdsa ImportError: No module named 'ecdsa' ~~~ after installing the `python3-ecdsa` package, that error goes away: ~~~ $ python3 Python 3.5.3 (default, Jan 19 2017, 14:11:04) [GCC 6.3.0 20170118] on linux Type "help", "copyright", "credits" or "license" for more information. >>> import ssl, socket >>> from tlslite import X509 >>> ~~~ i would therefore ask you to *Recommend* the python*-ecdsa package from the python*-tlslite-ng package. (at least, if the package can be used without X509; else go for *Depends*) -- System Information: Debian Release: 9.0 APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'stable-updates'), (500, 'unstable'), (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.8.0-2-amd64 (SMP w/8 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 python3-tlslite-ng depends on: pn python3:any Versions of packages python3-tlslite-ng recommends: ii python3-crypto 2.6.1-7 python3-tlslite-ng suggests no packages. -- no debconf information
Bug#856490: thunderbird fails to start if there is a ~/.icedove/ directory (or symlink)
Package: thunderbird Version: 1:45.7.1-1 Severity: important Dear Maintainer, thanks for bringing back the unbranded thunderbird. However, I'm rather unhappy with the currect state of the migration from the old ~/.icedove/ profile to the new ~/.thunderbird/ profile. My ~/.icedove/ profile is about 3.5 GB in size. i have no desire to have a *copy* of that directory lying around on my harddisk. one reason are the security implications. another reason is, that it takes ages. it would be *very* helpful if the popup that informs me of the migration, would have an option to [Cancel] the operation (the current state reminds me of those famous w32 dialogs: "Do you really want to destroy the world? [OK]"). it's obviously easy to just Ctrl-C the process when starting thunderbird from the cmdline, but it's hard to stop when starting via a GUI launcher. of course i first killed the dialog window, but that was *only* the dialog window and killing it would immediately start the copy process. somewhat contradictory, i also would like to be able to use my old ~/.icedove/ directory around, as my homedirectory is on an NFS mount, shared by multiple computers (some of them using icedove, some being upgraded to thunderbird). i see little merit in insisting on ~/.icedove/ not being there. afaik, ~/.icedove/ and ~/.thunderbird/ are practically identical, and could be shared between icedove and thunderbird clients, if it wasn't for thunderbird refusing to start if there is an ~/.icedove/ (even it is just a symlink to ~/.thunderbird/). so please allow me to have both ~/.icedoce and ~/.thunderbird folders, side by side (without having to ressort to calling /usr/lib/thunderbird/thunderbird instead of /usr/bin/thunderbird) gmfadr IOhannes PS: i think that #855330 suggests something similar. -- System Information: Debian Release: 9.0 APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'stable-updates'), (500, 'unstable'), (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.8.0-2-amd64 (SMP w/8 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 thunderbird depends on: ii debianutils 4.8.1 ii fontconfig2.11.0-6.7+b1 ii libasound21.1.3-5 ii libatk1.0-0 2.22.0-1 ii libc6 2.24-9 ii libcairo2 1.14.8-1 ii libdbus-1-3 1.10.16-1 ii libdbus-glib-1-2 0.108-2 ii libevent-2.0-52.0.21-stable-3 ii libffi6 3.2.1-6 ii libfontconfig12.11.0-6.7+b1 ii libfreetype6 2.6.3-3+b2 ii libgcc1 1:6.3.0-8 ii libgdk-pixbuf2.0-02.36.5-2 ii libglib2.0-0 2.50.3-1 ii libgtk2.0-0 2.24.31-2 ii libhunspell-1.4-0 1.4.1-2+b1 ii libicu57 57.1-5 ii libnspr4 2:4.12-6 ii libnss3 2:3.26.2-1 ii libpango-1.0-01.40.4-1 ii libpangocairo-1.0-0 1.40.4-1 ii libpangoft2-1.0-0 1.40.4-1 ii libpixman-1-0 0.34.0-1 ii libsqlite3-0 3.16.2-3 ii libstartup-notification0 0.12-4 ii libstdc++66.3.0-8 ii libvpx4 1.6.1-2 ii libx11-6 2:1.6.4-3 ii libxcomposite11:0.4.4-2 ii libxdamage1 1:1.1.4-2+b1 ii libxext6 2:1.3.3-1 ii libxfixes31:5.0.3-1 ii libxrender1 1:0.9.10-1 ii libxt61:1.1.5-1 ii psmisc22.21-2.1+b1 ii zlib1g1:1.2.8.dfsg-5 Versions of packages thunderbird recommends: ii hunspell-de-at [hunspell-dictionary] 20161207-1 ii hunspell-en-us [hunspell-dictionary] 20070829-7 ii lightning 1:45.7.1-1 Versions of packages thunderbird suggests: pn apparmor pn fonts-lyx ii libgssapi-krb5-2 1.15-1 -- no debconf information
Bug#856490: thunderbird fails to start if there is a ~/.icedove/ directory (or symlink)
On 03/01/2017 04:50 PM, Carsten Schoenert wrote: > Hello IOhannes, > > On Wed, Mar 01, 2017 at 03:56:37PM +0100, IOhannes m zmölnig wrote: > >> However, I'm rather unhappy with the currect state of the migration from the >> old >> ~/.icedove/ profile to the new ~/.thunderbird/ profile. > > we know. There are other bug reports that are also complaining about the > current behavior. thanks for confirmation. i was pretty sure that there were other reports sharing my sentiments, but i admit that i didn't feel like wading through the 200+ open tickets in detail (i see know that that's the total count of bugs from the src:icedove package; the bug-count for thunderbird is much lower). the only obvious related issue was > >> My ~/.icedove/ profile is about 3.5 GB in size. i have no desire to have a >> *copy* of that directory lying around on my harddisk. >> one reason are the security implications. >> another reason is, that it takes ages. > > The security reason I can not really share, there is no real difference > to the real profile and if some person has access to your home it > doesn't matter what folder he is "using". A waste of space may be a > valid issue in some cases. the security issue is about hiding sensitive data in a stale directory (which makes it harder to purge sensitive data from within the application). but anyhow. > My profile is also about 3GB, to say it takes ages to copy is a relative > thing. The copy takes about 4-5 seconds. lucky you. it definitely took longer here: after finding no cancel button in the dialog, and "kill -KILL"ing the zenity process, i had time to discover that there was still a `cp` process running, finding its PID and killing that. after having done that (and i'm sure that took longer that 4-5 seconds), the copy had finished just about 20%. > And even if it takes more time > for copying the folder I would't say that is critical for a migration. agreed. > > We had some reasons in the past to decide we want to copy the old folder > as we expected to see much more problems with the switch. But yeah, more > or less nothing was happen! So the concerns are not valid any longer and > we can do symlinking now as we know what to fix after the adoption. > > So anyway, the next upload will do trying to symlink ~/.thunderbird to > ~/.icedove instead of copying the folder into a new folder. cool. > Booth symlink constellations are working by the next version Christoph > is preparing. So as long ~/.thunderbird is pointing to ~/.icedove, or > ~/.icedove is pointing to ~/.thunderbird the script will start Thunderbird. > > I've written the new (and final) behavior of the wrapper script into the > Debian wiki. It should be expanded and correct by every user who has > found something. > > https://wiki.debian.org/Thunderbird > thanks for the quick response and the fixes. gfmards IOhannes signature.asc Description: OpenPGP digital signature
Bug#861014: unblock: python-pyelftools/0.24-2
hi tomasz, On Sun, 23 Apr 2017 23:04:08 +0200 Ivo De Decker wrote: > Control: tags -1 moreinfo > > Hi, > > On Sun, Apr 23, 2017 at 07:51:24PM +0200, Tomasz Buchert wrote: > > Please unblock package python-pyelftools > > > > The package FTBFSes on i386. The version in unstable fixes it. > > > > unblock python-pyelftools/0.24-2 > > You changed the debhelper compat version from 9 to 10. That is not appropriate > during the freeze. Please revert this. > since once of my packages is threatened by autoremoval due to this bug, i wonder whether i can do something to help with the issue at hand. gfmadr IOhannes signature.asc Description: OpenPGP digital signature
Bug#854390: python-bottle-cork: insecure default hashing algorithm
Source: python-bottle-cork Severity: grave Tags: upstream security Justification: user security hole As reported on https://github.com/FedericoCeratto/bottle-cork/issues/112, the "bottle-cork" module uses a very unsecure hashing algorithm (sha1 with 10 iterations) as default. the defaults should be changed to use a secure hash (or even better: the user should select the hashing algorithm, rather than Cork)
Bug#807690: libassimp-dev: CMake files gives incorrect info
Control: tags -1 pending Thanks. On 12/11/2015 04:52 PM, Leopold Palomo-Avellaneda wrote: > Package: libassimp-dev > Version: 3.2~dfsg-2 > Severity: normal > > Dear Maintainer, > > I would like to tell you one bug I have found. thanks for the fix. > Sorry for the noise produced. I hope that not too much package had the FTBFS > label. i don't think it is likely that the issue produced and FTBFS (for Debian packages). the cmake-config was introduced a few weeks ago, and up to then all (2) packages that used libassimp where builing without it... fmdsar IOhannes signature.asc Description: OpenPGP digital signature
Bug#603176: pd-iemxmlrpc: changing back from RFP to ITP
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 retitle 603176 ITP: pd-iemxmlrpc -- XML-RPC implementation for Pd owner 603176 ! thanks -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCAAGBQJVzKdqAAoJELZQGcR/ejb4VikQAILMiO6SnVnx15dsRoiPQUlm H7A1Va93NQkfrm9MM2qojP9eOaW4iJlsHQJtErqjJygxYcTxAlyTFEKFUYkQeo7F pZe/NHAe/dtwqIACWpaS6JAxK8OPEJsNMR40H0qlBGl62MD+M7/iSG5KMZUx6xy/ xY+lJLXK3vPvkJIqM8HpTeMxJMH+V0MGo56AoEABXFA/7yeSQhiUg1KNCiasdcb2 UN/cE/Kqkjh7AFM0KtuPjDEyq/GoIx1bTNsePMUohTYwSIRna4c9CMm5IbsJ8xEq J3Xqtq9pHD/k6231svZJocz5sJ3D9lKDkQLW6XrazmyKYtJT2hO9T+/74lPKdne/ i1Rkrc/0f784ENq8QACUf05z3jvYVj7MMXG3c6JZHjxCOHCzG4vSvI+LMVgSA2wA r/kG6nshSQOuwNYlmRGS2FH5M8ppflIXqshSLpo3qK3dI33fQ0A1Z1b7sX/hlYx6 OCGRHmZtm3kG6bpMQ+N+7tiz/phjA+pFNMXOxJkmGSBh6o0xwGrmePbHQX8owXqM osQEx6IXaHiZWdOXjTHC5J7/8NzTux/w6MVsFwgWXYMkyeCqteXbT0iVWgSbmxR2 9Qv7aQ/nZXkgfDM/CqlwOvVbr1eRGsPYt4UcsJXNytKcRX6w/7Cb0zL/giD0TaM6 ggQqzh5gK5Vr/pPAumcO =nVax -END PGP SIGNATURE-
Bug#825993: Rosegarden is not proposed when opening .rg files
On 2016-06-01 10:34, Petter Reinholdtsen wrote: > I agree that the approach has some disadvantage, and the one you quotes > is the major one, but I believe it is less of a disadvantage for > unskilled users than having Rosegarden fail to show up as an alternative > when he is trying to open a Rosegarden file in the file manager. i think associating rosegarden with *any* gzip file is more harm than not being able to open rosegarden files via the file-manager (and i think this is shat sebastinas also thinks) > > I believe it is better to get several options and be able to pick a > working one from them than it is to not get any options. i think the only valid option is to associate rosegarden with rg files only (and not with gz files it cannot handle). however, i don't really see the problem: afaict, rosegarden.desktop associates with a lot of mimetypes (audio/x-rosegarden-composition;audio/x-rosegarden-device;audio/x-rosegarden-project;audio/x-rosegarden-template), but rosegarden.sharedmimeinfo registers "audio/rosegarden" as the mimetype for .rg files - a mimetype that is *not* listed in the desktop file. maybe we should fix this first (and maybe provide a rosegarden.mime file if this doesn't help). fmasdr IOhannes
Bug#819531: Invalid user name 'Debian-snmp' for adduser
Package: snmpd Version: 5.7.3+dfsg-1.1 Followup-For: Bug #819531 Confirmed. WHile I don't have a strong opinion about the "Debian-" prefix (vs a leading underscore), in any case the postinst script needs to call adduser with the "--force-badname" (as is done e.g. by exim4-config) -- System Information: Debian Release: stretch/sid APT prefers testing-updates APT policy: (500, 'testing-updates'), (500, 'stable-updates'), (500, 'unstable'), (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.4.0-1-amd64 (SMP w/8 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 snmpd depends on: ii adduser3.114 ii debconf [debconf-2.0] 1.5.59 ii libc6 2.22-5 ii libsnmp-base 5.7.3+dfsg-1.1 ii libsnmp30 5.7.3+dfsg-1.1 ii lsb-base 9.20160110 snmpd recommends no packages. Versions of packages snmpd suggests: pn snmptrapd -- Configuration Files: /etc/snmp/snmpd.conf [Errno 13] Keine Berechtigung: u'/etc/snmp/snmpd.conf' -- debconf information excluded
Bug#825109: FTBFS: mv: cannot stat './config.guess': No such file or directory
Control: reassign -1 cdbs thanks This is really a regression in CDBS. mgfsar IOhannes signature.asc Description: OpenPGP digital signature
Bug#775490: ITP: natron -- Natron is an open-source, crossplatform, nodal compositing software
any news on this? natron-2.0.5 has been released two weeks ago, and there have been properly tagged releases since 2016/03. also i would like to offer to package this under the pkg-multimedia-team umbrella. fgamrds IOhannes signature.asc Description: OpenPGP digital signature
Bug#823423: ITA: faust -- functional programming language for realtime audio applications
Control: retitle -1 ITA: faust -- functional programming language for realtime audio applications Control: owner -1 umlae...@debian.org Thanks. hi mario, i'm interested in adopting faust (within the pkg-multimedia-maintainers team). the PTS has no link to a packaging git. does such a thing exist? mdsar IOhannes signature.asc Description: OpenPGP digital signature
Bug#828829: libsane-common: spelling errors in manpage (overridden)
Package: libsane-common
Version: 1.0.25-2
Severity: minor
Dear Maintainer,
the manpages sane-epson.5, sane-epson2.5 and sane-epsonds.5 contain a spelling
error: "Newer scanners allow to select either 8 bits, [...]" instead of the
correct "Newer scanners allow one to select either 8 bits, [...]" ("allow to" is
a transitive verb and requires an object).
This is reported correctly by lintian, but for whatever reasons rather than
fixing the error the lintian warning got overridden.
while i can possibly understand your unwillingness to fix the typo (e.g. being
to
minor¹) i don't understand why you go to the length of lintian-overriding it.
if there is a good reason, you might want to add it to the lintian-override
file.
fgmasdr
IOhannes
¹ otoh, there's also a patch to fix "developpment" in a comment...
*** Reporter, please consider answering these questions, where appropriate ***
* What led up to the situation?
* What exactly did you do (or not do) that was effective (or
ineffective)?
* What was the outcome of this action?
* What outcome did you expect instead?
*** End of the template - remove these template lines ***
-- System Information:
Debian Release: stretch/sid
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'unstable'), (500, 'testing'),
(500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.5.0-2-amd64 (SMP w/8 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 libsane-common depends on:
ii dpkg 1.18.7
libsane-common recommends no packages.
libsane-common suggests no packages.
-- no debconf information
Bug#821955: gtk 3.20 issue
Control: tags -1 confirmed Thanks. On 04/20/2016 09:41 PM, di dit wrote: > Package: gramps > Version: 4.2.2~dfsg-1 > > Gramps is currently unusable in unstable. The following message is > displayed very often. > > ERROR: grampsapp.py: line 107: Unhandled exception > Traceback (most recent call last): > File > "/usr/lib/python3/dist-packages/gramps/gui/widgets/styledtexteditor.py", > line 289, in on_motion_notify_event > self.match = self.textbuffer.match_check(iter_at_location.get_offset()) > AttributeError: '_ResultTuple' object has no attribute 'get_offset' > > According to the following upstream bug report, the culprit is the gtk > 3.20 migration. > https://gramps-project.org/bugs/view.php?id=9335 > > This issue has been fixed upstream in the 4.2.3 release. > > signature.asc Description: OpenPGP digital signature
Bug#822597: deken: depends on gksu which is deprecated
Control: tags -1 fixed-upstream Thanks. On 04/25/2016 05:01 PM, po...@debian.org wrote: > Source: deken > Severity: important > Tags: sid stretch > User: pkg-gnome-maintain...@lists.alioth.debian.org > Usertags: oldlibs gksu > > Hi, > > deken depends on gksu, which is deprecated and unmaintained. Thus we > want to remove it from the archive. > > deken should switch to a supported and securer way to become root, > particularly one that doesn't mean running your whole application as > root (including the GUI), e.g. using polkit. upstream is now using pkexec. so for the next release (i expect that to be soonish), the gksu dependency can be dropped in the Debian package. > > Please try to do this before the Stretch release as we're going to > try to remove gksu this cycle. > > We'll bump this to serious when the list of rdeps is small and we're > getting ready to removing gksu completely. > > If you have any question don't hesitate to ask. > > https://www.freedesktop.org/wiki/Software/polkit/ > https://wiki.debian.org/PolicyKit > > Cheers, Emilio > > ___ > pkg-multimedia-maintainers mailing list > pkg-multimedia-maintain...@lists.alioth.debian.org > http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers > signature.asc Description: OpenPGP digital signature
Bug#795125: transition: libassimp3 -> libassimp3v5
On 08/19/2015 09:48 AM, Simon McVittie wrote: > On Mon, 10 Aug 2015 at 21:34:24 +0200, IOhannes m zmoelnig wrote: >> I have uploaded "assimp_3.1.1~dfsg-4" to "experimental". > ... >> Please schedule binNMUs for the above mentioned packages on all >> architectures. > > Packages in unstable are not binNMU'd against dependencies from > experimental, and this transition is mostly about what happens in > unstable. yes sure. i've uploaded to experimental in order to clear the NEW status. my mail / this bug is mostly about coordinating the upload to unstable + binNMU. (i'm in the lucky position that my libs haven't needed transitions yet; so i'm a bit of a newbie here...) > > assimp does not appear to have any C++ dependencies other than libstdc++, > and the current policy is that the v5 transitions can be started for any > package whose dependencies have started their transitions, so please upload > either 3.0 or 3.1.1 to unstable with the libassimp3v5 package name. > Upload whichever version you consider to be lower-risk. great. in this case i will upload 3.1.1 to unstable. mvsadr IOhannes signature.asc Description: OpenPGP digital signature
Bug#806029: gem: FTBFS when built with dpkg-buildpackage -A (No such file or directory)
Control: tags -1 pending thanks. On 11/24/2015 04:25 PM, Santiago Vila wrote: > Package: src:gem > Version: 1:0.93.3-9 > User: sanv...@debian.org > Usertags: binary-indep > Severity: important > > Dear maintainer: > > I tried to build this package with "dpkg-buildpackage -A" > (i.e. only architecture-independent packages), and it failed: > > > [...] > fakeroot debian/rules binary-indep > dh --with autoreconf binary-indep >dh_testroot -i >dh_prep -i >dh_auto_install -i > make -j1 install DESTDIR=/<>/debian/tmp > AM_UPDATE_INFO_DIR=no > make[1]: Entering directory '/<>' > Making install in src > make[2]: Entering directory '/<>/src' > Making install in Gem > make[3]: Entering directory '/<>/src/Gem' > /bin/bash ./../pkgversion.sh ../version.h.in > version_current.h > /bin/bash ../../libtool --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H -I. > -I../../src -I../../src -D_FORTIFY_SOURCE=2 -DHAVE_VERSION_H -DPD > -I/usr/include/pd -I/usr/include/GL -I/usr/include/libdrm -g -O2 > -fstack-protector-strong -Wformat -Werror=format-security -freg-struct-return > -O3 -falign-loops -falign-functions -falign-jumps -funroll-loops -ffast-math > -mmmx -MT libGem_la-Version.lo -MD -MP -MF .deps/libGem_la-Version.Tpo -c -o > libGem_la-Version.lo `test -f 'Version.cpp' || echo './'`Version.cpp > libtool: compile: g++ -DHAVE_CONFIG_H -I. -I../../src -I../../src > -D_FORTIFY_SOURCE=2 -DHAVE_VERSION_H -DPD -I/usr/include/pd -I/usr/include/GL > -I/usr/include/libdrm -g -O2 -fstack-protector-strong -Wformat > -Werror=format-security -freg-struct-return -O3 -falign-loops > -falign-functions -falign-jumps -funroll-loops -ffast-math -mmmx -MT > libGem_la-Version.lo -MD -MP -MF .deps/libGem_la-Version.Tpo -c Version.cpp > -fPIC -DPIC -o .libs/libGem_la-Version.o > libtool: compile: g++ -DHAVE_CONFIG_H -I. -I../../src -I../../src > -D_FORTIFY_SOURCE=2 -DHAVE_VERSION_H -DPD -I/usr/include/pd -I/usr/include/GL > -I/usr/include/libdrm -g -O2 -fstack-protector-strong -Wformat > -Werror=format-security -freg-struct-return -O3 -falign-loops > -falign-functions -falign-jumps -funroll-loops -ffast-math -mmmx -MT > libGem_la-Version.lo -MD -MP -MF .deps/libGem_la-Version.Tpo -c Version.cpp > -o libGem_la-Version.o >/dev/null 2>&1 > mv -f .deps/libGem_la-Version.Tpo .deps/libGem_la-Version.Plo > /bin/bash ../../libtool --tag=CXX --mode=link g++ -DHAVE_VERSION_H -DPD > -I/usr/include/pd -I/usr/include/GL -I/usr/include/libdrm -g -O2 > -fstack-protector-strong -Wformat -Werror=format-security -freg-struct-return > -O3 -falign-loops -falign-functions -falign-jumps -funroll-loops -ffast-math > -mmmx -Wl,-z,relro -o libGem.la libGem_la-glew.lo libGem_la-Cache.lo > libGem_la-ContextData.lo libGem_la-Dylib.lo libGem_la-Event.lo > libGem_la-Exception.lo libGem_la-Files.lo libGem_la-GLStack.lo > libGem_la-Image.lo libGem_la-ImageLoad.lo libGem_la-ImageSave.lo > libGem_la-PixConvertAltivec.lo libGem_la-PixConvertSSE2.lo > libGem_la-Loaders.lo libGem_la-Manager.lo libGem_la-PBuffer.lo > libGem_la-Properties.lo libGem_la-Settings.lo libGem_la-Setup.lo > libGem_la-State.lo libGem_la-SynchedWorkerThread.lo libGem_la-ThreadMutex.lo > libGem_la-ThreadSemaphore.lo libGem_la-Version.lo libGem_la-WorkerThread.lo > -L/usr/include/pd -lGLEW -lGLU -lGL -lXxf86vm -ldl -lz -lm -L/usr/include/pd > libtool: link: rm -fr .libs/libGem.a .libs/libGem.la > libtool: link: ar cru .libs/libGem.a .libs/libGem_la-glew.o > .libs/libGem_la-Cache.o .libs/libGem_la-ContextData.o .libs/libGem_la-Dylib.o > .libs/libGem_la-Event.o .libs/libGem_la-Exception.o .libs/libGem_la-Files.o > .libs/libGem_la-GLStack.o .libs/libGem_la-Image.o .libs/libGem_la-ImageLoad.o > .libs/libGem_la-ImageSave.o .libs/libGem_la-PixConvertAltivec.o > .libs/libGem_la-PixConvertSSE2.o .libs/libGem_la-Loaders.o > .libs/libGem_la-Manager.o .libs/libGem_la-PBuffer.o > .libs/libGem_la-Properties.o .libs/libGem_la-Settings.o > .libs/libGem_la-Setup.o .libs/libGem_la-State.o > .libs/libGem_la-SynchedWorkerThread.o .libs/libGem_la-ThreadMutex.o > .libs/libGem_la-ThreadSemaphore.o .libs/libGem_la-Version.o > .libs/libGem_la-WorkerThread.o > ar: `u' modifier ignored since `D' is the default (see `U') > libtool: link: ranlib .libs/libGem.a > libtool: link: ( cd ".libs" && rm -f "libGem.la" && ln -s "../libGem.la" > "libGem.la" ) > > [... snipped ...] > > make[1]: Leaving directory '/<>' >debian/rules override_dh_install > make[1]: Entering directory '/<>' > dh_install > # remove libtool files, they are not needed > find debian/gem-extra/usr/lib/ -name '*.la' -delete > find: `debian/gem-extra/usr/lib/': No such file or directory > debian/rules:53: recipe for target 'override_dh_install' failed > make[1]: *** [override_dh_install] Error 1 > make[1]: Leaving directory '/<>' > debian/rules:40: recipe for target 'binary-indep' failed > make: *** [binary-ind
Bug#806317: libassimp-dev: Missing CMake package files
Control: tags -1 pending Thanks. On 11/26/2015 01:25 PM, Leopold Palomo-Avellaneda wrote: > Package: libassimp-dev > Version: 3.2~dfsg-1 > Severity: normal > Tags: patch > [...] > > Just modifiying libassimp-dev.install and adding: > > debian/tmp/usr/lib/*/cmake > > the user that use cmake just doing: > find_package(assimp REQUIRED NO_MODULE) > > cmake will found the library filling the needed information. > signature.asc Description: OpenPGP digital signature
Bug#806942: ldap2zone: leaving ldap2zone unconfigured will make cron send an email each hour
Package: ldap2zone Version: 0.2-6 Severity: normal Dear Maintainer, * What led up to the situation? I installed ldap2zone for testing purposes (not for production). Since i installed it, the administrator gets an email every hour with the content: > Subject: Cron /usr/sbin/ldap2bind >> ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1) >> No domains configured. Exiting... * What exactly did you do (or not do) that was effective (or ineffective)? I did not configure ldap2zone. Esp. i did not modify (or even create) a file /etc/defaults/ldap2zone. I also do not remember being told to craete (or modify) such a file during the installation process. * What was the outcome of this action? ldap2zone sets up a cronjob to run /usr/sbin/ldap2bind each hour, and ldap2bind generates a (non-descript) error because of the missing /etc/defaults/ldap2zone. flooding the admin's mailbox. * What outcome did you expect instead? i *expected* to not get an error-message each hour simply because i installed a package. i think the proper procedure would be: - during installation, tell the administrator that they need to create/configure a file "/etc/defaults/ldap2zone" in order to use that service. AND - skip the cron-job if that file is not present. something like the following $ cat /etc/cron.d/ldap2zone PATH=/sbin:/bin:/usr/sbin:/usr/bin @reboot bind test -x /usr/sbin/ldap2bind && test -e /etc/defaults/ldap2zone && /usr/sbin/ldap2bind @hourly bind test -x /usr/sbin/ldap2bind && test -e /etc/defaults/ldap2zone && /usr/sbin/ldap2bind *** End of the template - remove these template lines *** -- System Information: Debian Release: stretch/sid APT prefers testing-updates APT policy: (500, 'testing-updates'), (500, 'stable-updates'), (500, 'unstable'), (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.2.0-1-amd64 (SMP w/8 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 ldap2zone depends on: ii bind9 1:9.9.5.dfsg-12+b1 ii libc6 2.19-22 ii libldap-2.4-2 2.4.42+dfsg-2 ldap2zone recommends no packages. ldap2zone suggests no packages. -- no debconf information
Bug#800022: ardour3: Last upgrade removed Ardour4
On 09/25/2015 03:55 PM, Massimo Barbieri wrote: > Package: ardour3 > Version: 1:3.5.403~dfsg-4 > Severity: important > > Dear Maintainer, > > last upgrade of my Debian testing removed ardour4 and now I have ardour3. > > Thanks for your work. that's rather by intention: the "ardour3" package should never have installed ardour-4. in any case, we are currently in a state of transition: the "ardour3" packaged is being *removed* from Debian entirely, and the "ardour" package provides an up-to-date version of ardour (currently ardour-4.2). the next upload of ardour (currently building) will also feature a transitional "ardour3" package, that will ease migration for existing users. gmasdr IOhannes signature.asc Description: OpenPGP digital signature
Bug#773246: hydrogen-drumkits: DFSG-ness of the drumkits
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Control: tags -1 pending thanks i've uploaded hydrogen-drumkits_2015.09.28-1 to unstable (currently lingering in NEW), which has re-evaluated the licenses for all included drumkits (and dropped the drumkits of dubious license/provenience). the new package also has an updated debian/copyright (following dep5) that lists all licenses of the included kits.
Bug#800605: v4l2loopback-dkms: Can't pipe modified video stream to a loopback device
Control: tags -1 confirmed thanks On 10/01/2015 05:25 PM, Roland Mas wrote: > > I'm trying to intercept a video stream from a webcam and crop it a bit > before passing it on for further processing. I found v4l2loopback, > which sounds like it's exactly what I'm looking for. However, I get > crashes as soon as I try to insert processing in the pipeline. > > The following works: > > , > | $ gst-launch-1.0 v4l2src device=/dev/video0 ! v4l2sink device=/dev/video1 > ` > > (Works as in I'm able to see the video with "gst-launch-1.0 v4l2src > device=/dev/video1 ! xvimagesink") interesting. to the best of my knowledge, v4l2loopback and GStreamer-1.0 don't work together at all. good to hear that they finally do work together. > The following, however, doesn't (I added some debugging): [...] > | 0:00:00.247794498 8590 0x13bd050 WARNv4l2 > gstv4l2object.c:2167:gst_v4l2_object_probe_caps_for_format_and_size: > Unknown frame interval type at YVYU@48x32: 0 > | 0:00:00.618841172 8590 0x13bd050 ERROR v4l2allocator > gstv4l2allocator.c:1299:gst_v4l2_allocator_dqbuf: > buffer 1 was not queued, this indicate a driver bug. > | 0:00:00.618972830 8590 0x13bd050 WARN basesrc > gstbasesrc.c:2943:gst_base_src_loop: error: Internal data flow > error. > | 0:00:00.619019484 8590 0x13bd050 WARN basesrc > gstbasesrc.c:2943:gst_base_src_loop: error: streaming task paused, > reason error (-5) > | ERROR: from element /GstPipeline:pipeline0/GstV4l2Src:v4l2src0: Internal > data flow error. which is *not* a crash. GStreamer just tells you that it can't play this pipeline, and gst-launch does a controlled quit after that. > > I'm pretty sure the problem lies with v4l2loopback, since replacing > the v4l2sink with a simple xvimagesink in both pipelines gives me the > unaltered stream in the first case and a cropped one in the second case. > > This takes out much of the value of v4l2loopback, if I can only resend > video as-is :-) as v4l2loopback doesn't do any deep inspection of the video processing (how is it supposed to know what's the original and what's the altered stream?) the problem must lie somewhere else. probably even with GStreamer (check the negotiated caps in both cases). gmadsr IOhannes signature.asc Description: OpenPGP digital signature
Bug#800834: ardour: Freesound search stops work
Control: tags -1 confirmed Control: tags -1 upstream thanks On 10/04/2015 09:37 AM, Massimo Barbieri wrote: > Package: ardour > Version: 1:4.2~dfsg-5 > Severity: minor > > Dear Maintainer, > in the add media window the freesound search by tag doesn't show any results. > Thanks for your work! this is a known upstream issue (see [1], [2]): ardour still only supports the FreeSound v1 query API, which seems t ohave finally retired. gfmads IOhannes [1] http://tracker.ardour.org/view.php?id=6197 [2] http://tracker.ardour.org/view.php?id=6493 signature.asc Description: OpenPGP digital signature
Bug#800576: gitk --all doesn’t work anymore in some locales
Package: gitk Version: 1:2.6.1-1 Followup-For: Bug #800576 just confirming that this bug is still present in 2.6.1-1 i also did some further tests which locales are affected, and it seems that *all* locales that are shipped with gitk fail: bg, ca, de, es, fr, hu, it, ja, pt_br, ru, sv, vi mfgvadrt IOhannes -- System Information: Debian Release: stretch/sid APT prefers testing-updates APT policy: (500, 'testing-updates'), (500, 'stable-updates'), (500, 'unstable'), (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.2.0-1-amd64 (SMP w/8 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 gitk depends on: ii git 1:2.6.1-1 ii tk 8.6.0+8 gitk recommends no packages. Versions of packages gitk suggests: pn git-doc -- no debconf information
Bug#798341: [inkscape] impossible to install inkscape
On 2015-09-09 09:52, Marco Righi wrote: [...] > inkscape : Depends: libatkmm-1.6-1 (>= 2.22.1) but it is not going to > be installed in the past few weeks, Debian has seen a major transition (of the core components for any C++-related software in Debian) that affected *many* packages and included the renaming of some dependencies of inkscape. only within the last days, this big change started migrating from "unstable" to "testing". this basically means big disruption which should eventually go away "automatically", once all packages have been transitioned from unstable to testing. in the meantime you could try using a better dependency resolver, e.g. by intalling the packages with aptitude: # aptitude udpate # LC_ALL=C.UTF-8 aptitude install inkscape i also see that you are running a mixed jessie/stretch (aka "stable/testing") system, which i don't think is supported at all (i think that one of the reasons for this is exactly because it is impossible to support working systems that depend on a state both *before* and *after* such big transitions we are currently seeing). fgmasdr IOhannes
Bug#760758: amb-plugins: spurious LADSPA_PROPERTY_REALTIME
On 09/09/2015 06:40 PM, Jaromír Mikeš wrote: > Hi all, > > Is there any progress with this topic? Does any body contacted Richard Furse > as has been suggested? i have now. http://lists.linuxaudio.org/pipermail/linux-audio-dev/2015-September/036096.html gcmsr IOhannes signature.asc Description: OpenPGP digital signature
Bug#798341: [inkscape] impossible to install inkscape
On 2015-09-09 14:46, Marco Righi wrote: > The problem is not resolved (the test are below). > > Regarding the hybrid configuration, I think it is a problem > because there not exists the last version of a library but your are > branching them so my Linux "lives" using some library from a branch > and some library from another branch. It seems to me that is not a > good practice if you want that Debian will continues to be a Linux > leader. i have a hard time understanding this paragraph. > > Moreover, a pure Debian testing freezes on a Supermicro board > after the installation at the first reboot. The problem has born > during these day so I think that it is bind to the new Debian > release. The [...] your hardware problems are a totally unrelated issue. i understand that this issue is the reason why you are mixing both "stable" aka "jessie" (which seems to work fine for you) and "testing" aka "stretch" (picking the parts you want updated). but this doesn't mean that Debian supports such a setup, (and as a consequence: that bugs caused by this setup are valid). furthermore, you have plenty of other repositories outside of debian enabled. some of them are known to make problems (e.g. deb-multimedia), that's why you might get heated replies about them. others are from other distributions (e.g. linuxmint). others are totally unknown. if you have only a single package installed from any of those non-Debian repositories, this package might depend on a certain version that is *conflicting* with an official package like 'inkscape' as found in testing, making it uninstallable. so who do you think is to blame? so to conclude: a large eco-system like an entire operating system with thousands of libraries and applications is a complex system. it takes a lot of man power to make all its components work together. Debian does this work. if you (the user) deliberately replaces some of it's components, then Debian cannot be held responsible for any damage you do to your system. that's why your bug report is considered invalid and has been closed. the good news is: even though you have tampered with your system, it still is consistent (everything works). it just won't let you install things that are known to break your existing setup (this is the actual reason why you cannot install 'inkscape'). /this doesn't mean however, that finally: there *is* a way to install newer versions of (selected) packages on a "stable" system. it's called "backports", and provides specially buit packages that integrate into e.g. "jessie". http://backports.debian.org/ note however, that backports only provides a small subset of the ~5 packages available in Debian. and of course (to reiterate what others have already said): if you do want to have support from Debian, you need to first /use Debian/: that means uninstalling all packages from unofficial (wrt Debian) repositories and disabling all unofficial repositories. gmfsdr IOhannes
Bug#802448: supervisor: Please package new upstream version 3.1
Package: supervisor Severity: wishlist Dear Maintainer, supervisor-3.1.3 has been released about a year ago. Please consider upgrading the Debian package. -- System Information: Debian Release: stretch/sid APT prefers testing-updates APT policy: (500, 'testing-updates'), (500, 'stable-updates'), (500, 'unstable'), (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.2.0-1-amd64 (SMP w/8 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)
Bug#802471: libopenraw1v5: Try to overwrite file in libopenraw1
Package: libopenraw1v5 Version: 0.0.9-3.7 Followup-For: Bug #802471 Dear Maintainer, it seems an attempt has been made to fix this problem, by adding Replaces/Conflicts stanzas. Unfortunately these stanzas are wrong, as they currently make 'libopenraw1v5' replace 'libopenraw1v5' and replace 'libopenraw1v5' (yes, that's three times the same package name). this basically means, that the 'libopenraw1v5' package cannot be co-installed with another version of itself (which is to be expected; Debian does not allow multiple versions of a single package to be co-installed in general). the proper replace/conflict stanzas should express a relationship towards the original 'libopenraw1' package (the non-v5 version): Replaces: libopenraw1 Conflicts: libopenraw1 thanks for re-uploading :-) fgmasdr IOhannes -- System Information: Debian Release: stretch/sid APT prefers testing-updates APT policy: (500, 'testing-updates'), (500, 'stable-updates'), (500, 'unstable'), (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.2.0-1-amd64 (SMP w/8 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 libopenraw1v5 depends on: ii libc62.19-22 ii libgcc1 1:5.2.1-22 ii libjpeg62-turbo 1:1.4.1-2 ii libstdc++6 5.2.1-22 libopenraw1v5 recommends no packages. libopenraw1v5 suggests no packages. -- no debconf information
Bug#802315: subversion: https authentication with gnome-keyring (the default) hangs forever
Package: subversion
Version: 1.9.2-2
Severity: important
Dear Maintainer,
Trying to checkout (or commit to) a repository that requires authentication via
https:// hangs forever.
I first came across this when trying to checkout some github repository via svn
(they offer a git/svn bridge); checkout would work fine (as it doesn't require
authentication) but commits would stall.
In the meantime I have been able to confirm the problem with my local svn
servers (so it's *not* a gh problem).
I noticed this problem on two separate machines.
Attaching an strace to the svn process indicates that it is waiting:
Process 28117 attached
restart_syscall(<... resuming interrupted call ...>) = 0
poll([{fd=6, events=POLLIN}], 1, 200) = 0 (Timeout)
poll([{fd=6, events=POLLIN}], 1, 200) = 0 (Timeout)
poll([{fd=6, events=POLLIN}], 1, 200) = 0 (Timeout)
poll([{fd=6, events=POLLIN}], 1, 200) = 0 (Timeout)
poll([{fd=6, events=POLLIN}], 1, 200) = 0 (Timeout)
[ad infinitum]
I removed the entire ~/.subversion/ folder, but to no avail.
Also IIRC, it works fine with http:// authentication.
after a little digging, it turns out that the problem is related to the
gnome-keyring password store.
At least, if i set
password-stores =
the problem goes away, and if i set
password-stores = gnome-keyring
the problem re-appears.
(It might be that http:// works in any case, because this is in any case so
insecure that svn doesn't even bother to use a password-store.)
The problem might be really a gnome-keyring problem, but I haven't found a way
to quickly test the functionality of gnome-keyring alone and I haven't noticed
hickups with other applications.
$ gnome-keyring version
gnome-keyring: 3.18.1
$ zcat /usr/share/doc/gnome-keyring/changelog.Debian.gz | head -1
gnome-keyring (3.18.1-1) unstable; urgency=medium
I'm running xfce4 (NOT gnome), in case this is related.
mfgadr
IOhannes
-- System Information:
Debian Release: stretch/sid
APT prefers testing-updates
APT policy: (500, 'testing-updates'), (500, 'stable-updates'), (500,
'unstable'), (500, 'testing'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.2.0-1-amd64 (SMP w/8 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 subversion depends on:
ii libapr11.5.2-3
ii libaprutil11.5.4-1
ii libc6 2.19-22
ii libldap-2.4-2 2.4.42+dfsg-2
ii libsasl2-2 2.1.26.dfsg1-14
ii libsvn11.9.2-2
subversion recommends no packages.
Versions of packages subversion suggests:
pn db5.3-util
ii patch 2.7.5-1
ii subversion-tools 1.9.2-2
-- no debconf information
Bug#804250: san...@debian.org, l...@alaxarxa.net
On 11/13/2015 08:24 AM, Riku Voipio wrote: > found 804250 3.0~dfsg-3 > thanks > >> Linker script needs adjustment to include typeinfo as need? > > I've confirmed that rebuilding assimp with removing the following bit: > > > -DCMAKE_SHARED_LINKER_FLAGS="-Wl,--version-script=$(CURDIR)/debian/libassimp3.ver > $(LDFLAGS)" \ > > Makes armhf linking against assimp3 work. I don't know anything about > linker scripts, and much less about c++ symbols, so I can't propose a change > against libassimp3.ver that would export only the neccesary symbols. thanks anyhow, for narrowing down the problem to the symbols file. > > As a quick fix one could disable linker script on armhf and armel archs? > that's a hack i would rather not have in the package (but then i guess i am one of the very few people who maintain a symbols file for a c++ library :-)) gfamrds IOhannes signature.asc Description: OpenPGP digital signature
Bug#814985: spf-tools-python: update-alternatives misses manpage
Package: spf-tools-python
Version: 2.0.12t-1
Severity: normal
Dear Maintainer,
after installing the spf-tools-python package, i can run "/usr/bin/spfquery" not
read its manpage:
$ man spfquery
No manual entry for spfquery
See 'man 7 undocumented' for help when manual pages are not available.
now, spfquery is an "alternative" provided by spfquery.pyspf and there IS a
manpage for this:
$ man spfquery.pyspf
so it seems that the problem really is the update-alternatives registration in
the postinst script which lacks a "--slave" directive and should read:
update-alternatives --install /usr/bin/spfquery spfquery
/usr/bin/spfquery.${source_package} 75 \
--slave /usr/share/man/man1/spfquery.1.gz spfquery.1.gz
/usr/share/man/man1/spfquery.${source_package}.1.gz
-- System Information:
Debian Release: stretch/sid
APT prefers testing-updates
APT policy: (500, 'testing-updates'), (500, 'stable-updates'), (500,
'unstable'), (500, 'testing'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.3.0-1-amd64 (SMP w/8 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 spf-tools-python depends on:
ii python3 3.5.1-1
ii python3-spf 2.0.12t-1
pn python3:any
spf-tools-python recommends no packages.
spf-tools-python suggests no packages.
-- no debconf information
Bug#815656: python3-easywebdav: fails to upload files
Package: python3-easywebdav
Version: 1.2.0-2
Severity: important
Dear Maintainer,
using the python3 version of this package, i found that it fails with an
exception, indicating that this package is not python3 ready.
~~~
>>> import easywebdav
>>> easywebdav.connect("example.com").upload("nada", "/dev/null")
Traceback (most recent call last):
File "", line 1, in
File "/usr/lib/python3/dist-packages/easywebdav/client.py", line 153, in
upload
if isinstance(local_path_or_fileobj, basestring):
NameError: name 'basestring' is not defined
~~~
'basestring' is a python2 thing, in python3 all strings are 'str'.
-- System Information:
Debian Release: stretch/sid
APT prefers testing-updates
APT policy: (500, 'testing-updates'), (500, 'stable-updates'), (500,
'unstable'), (500, 'testing'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.3.0-1-amd64 (SMP w/8 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 python3-easywebdav depends on:
ii python3-requests 2.9.1-3
pn python3:any
python3-easywebdav recommends no packages.
python3-easywebdav suggests no packages.
-- no debconf information
Bug#673203: ITA: snd -- Sound file editor
Control: retitle -1 ITA: snd -- Sound file editor thanks. i intend to adopt this package under the pkg-multimedia umbrella. (volunteers step forward!) gfamrds IOhannes signature.asc Description: OpenPGP digital signature
Bug#810006: supercollider-language: sclang should not Depend on scsynth
Package: supercollider-language Version: 1:3.6.6~repack-2-2 Severity: normal Dear Maintainer, sclang (supercollider-lang) and scsynth (supercollider-synth) can be run on different machines, so sclang does not strictly require the scsynth to be installed. as a consequence i would suggest to drop the *Depends* relationship. however, since sclang and scsynth will *normally* be installed together, the relationship should be *Recommends*, as defined in the policy: > This declares a strong, but not absolute, dependency. > The Recommends field should list packages that would be found together with > this one in all but unusual installations. thanks. -- System Information: Debian Release: stretch/sid APT prefers testing-updates APT policy: (500, 'testing-updates'), (500, 'stable-updates'), (500, 'unstable'), (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.3.0-1-amd64 (SMP w/8 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 supercollider-language depends on: ii libasound21.0.29-1 ii libavahi-client3 0.6.32~rc+dfsg-1 ii libavahi-common3 0.6.32~rc+dfsg-1 ii libbluetooth3 5.36-1 ii libboost-atomic1.58.0 1.58.0+dfsg-4.1 ii libboost-filesystem1.58.0 1.58.0+dfsg-4.1 ii libboost-regex1.58.0 1.58.0+dfsg-4.1 ii libboost-system1.58.0 1.58.0+dfsg-4.1 ii libboost-thread1.58.0 1.58.0+dfsg-4.1 ii libc6 2.21-6 ii libcwiid1 0.6.00+svn201-3.2 ii libfftw3-single3 3.3.4-2 ii libgcc1 1:5.3.1-5 ii libjack-jackd2-0 [libjack-0.116] 1.9.10+20150825git1ed50c92~dfsg-1 ii libqt4-network4:4.8.7+dfsg-5 ii libqtcore44:4.8.7+dfsg-5 ii libqtgui4 4:4.8.7+dfsg-5 ii libqtwebkit4 2.3.4.dfsg-6 ii libreadline6 6.3-8+b4 ii libscsynth1 1:3.6.6~repack-2-2 ii libsndfile1 1.0.25-10 ii libstdc++65.3.1-5 ii libx11-6 2:1.6.3-1 ii supercollider-common 1:3.6.6~repack-2-2 ii supercollider-server 1:3.6.6~repack-2-2 supercollider-language recommends no packages. Versions of packages supercollider-language suggests: ii subversion 1.9.3-1+b1 pn supercollider-ide -- no debconf information
Bug#810216: letsencrypt: fails to run as unprivileged user
Package: letsencrypt
Version: 0.1.1-3
Severity: normal
Dear Maintainer,
letsencrypt gives me a hard time when being run as unprivileged user.
i understand that quite a number of operations require supercow powers, but the
error messages are rather cryptic (being generic python exceptions):
$ letsencrypt
An unexpected error occurred:
OSError: [Errno 13] Permission denied: '/etc/letsencrypt'
Please see the logfile 'letsencrypt.log' for more details.
$ cat letsencrypt.log
Traceback (most recent call last):
File "/usr/bin/letsencrypt", line 9, in
load_entry_point('letsencrypt==0.1.1', 'console_scripts',
'letsencrypt')()
File "/usr/lib/python2.7/dist-packages/letsencrypt/cli.py", line 1359, in
main
"--strict-permissions" in cli_args)
File "/usr/lib/python2.7/dist-packages/letsencrypt/le_util.py", line 103,
in make_or_verify_dir
os.makedirs(directory, mode)
File "/usr/lib/python2.7/os.py", line 157, in makedirs
mkdir(name, mode)
OSError: [Errno 13] Permission denied: '/etc/letsencrypt'
$ sudo letsencrypt
No installers seem to be present and working on your system; fix that or try
running letsencrypt with the "certonly" command
$ letsencrypt
Traceback (most recent call last):
File "/usr/bin/letsencrypt", line 9, in
load_entry_point('letsencrypt==0.1.1', 'console_scripts',
'letsencrypt')()
File "/usr/lib/python2.7/dist-packages/letsencrypt/cli.py", line 1364, in
main
setup_logging(args, _cli_log_handler, logfile='letsencrypt.log')
File "/usr/lib/python2.7/dist-packages/letsencrypt/cli.py", line 1277, in
setup_logging
args, logfile=logfile, fmt=fmt)
File "/usr/lib/python2.7/dist-packages/letsencrypt/cli.py", line 1248, in
setup_log_file_handler
log_file_path, maxBytes=2 ** 20, backupCount=10)
File "/usr/lib/python2.7/logging/handlers.py", line 117, in __init__
BaseRotatingHandler.__init__(self, filename, mode, encoding, delay)
File "/usr/lib/python2.7/logging/handlers.py", line 64, in __init__
logging.FileHandler.__init__(self, filename, mode, encoding, delay)
File "/usr/lib/python2.7/logging/__init__.py", line 905, in __init__
StreamHandler.__init__(self, self._open())
File "/usr/lib/python2.7/logging/__init__.py", line 935, in _open
stream = open(self.baseFilename, self.mode)
IOError: [Errno 13] Permission denied:
'/var/log/letsencrypt/letsencrypt.log'
$
if the letsencrypt binary is only meant to be run as superuser, please move it
from /usr/bin/ to /usr/sbin/ and/or add additional checks whether the user has
the required privileges and provide them with a meaningful error message.
otoh, i guess that some functionality of letsencrypt does not require root
priviliges at all, at least it should not require such privilges (e.g. i don't
see why `letsencrypt plugins` must be run as root).
*** Reporter, please consider answering these questions, where appropriate ***
* What led up to the situation?
* What exactly did you do (or not do) that was effective (or
ineffective)?
* What was the outcome of this action?
* What outcome did you expect instead?
*** End of the template - remove these template lines ***
-- System Information:
Debian Release: stretch/sid
APT prefers testing-updates
APT policy: (500, 'testing-updates'), (500, 'stable-updates'), (500,
'unstable'), (500, 'testing'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.3.0-1-amd64 (SMP w/8 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 letsencrypt depends on:
ii dialog 1.2-20150920-1
ii python-letsencrypt 0.1.1-3
pn python:any
letsencrypt recommends no packages.
Versions of packages letsencrypt suggests:
pn python-letsencrypt-apache
ii python-letsencrypt-doc 0.1.1-3
-- no debconf information
Bug#603178: iem_bin_ambi will be integrated into iem_ambi
Control: Tags -1 pending thanks upstream assures me that the next version of "iem_ambi" (packaged as "pd-iemambi") will include the "iem_bin_ambi", making this ITP/RFP obsolete. gdmasr IOhannes
Bug#810765: ardour: FTBFS[!linux]: depends on cwiid, alsa
Control: Tags -1 pending thanks On 01/12/2016 02:28 AM, Steven Chamberlain wrote: > Package: ardour > Version: 1:4.4~dfsg-1 > Severity: normal > Tags: patch > > Hi, > > ardour has become BD-Uninstallable on kfreebsd and hurd due to > Build-Depends: > - cwiid, which is linux-specific; > - libasound2-dev, which is linux-specific (although kfreebsd has > a compatibility wrapper around OSS, I think it will be inadequate > for ardour's purposes; better to use JACK instead). > > Please find attached patch adjusting the build-dependencies, and also > to only enable the ALSA backend on Linux. > > (p.s. `BACKENDS+=,alsa` might have looked neater, but doesn't work) > > Thanks! > > -- System Information: > Debian Release: stretch/sid > APT prefers unstable > APT policy: (500, 'unstable'), (1, 'experimental') > Architecture: kfreebsd-amd64 (x86_64) > > Kernel: kFreeBSD 10.1-0-amd64 > Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) > Shell: /bin/sh linked to /bin/dash > signature.asc Description: OpenPGP digital signature
Bug#816599: lintian: false-positive spelling error 'homogenous'
Package: lintian Version: 2.5.41 Severity: normal Dear Maintainer, In one of my packages, lintian reported a spelling error 'homogenous' which should be fixed to 'homogeneous'. Not being a native English speaker, I trusted lintian, created a patch and submitted it upstream, only to get a reply: > My dictionary (American Heritage) says 'homogenous' is an acceptable spelling > of 'homogeneous', and it's how I pronounce the word. So I did a quick check, and Merriam-Webster [1] seems to allow the 'homogenous' spelling as well. Other sources [2] even suggest that 'homogenous' is the de-facto spelling of the word, while the Online Etymology Dictionary - which according to [3] suggested that this is an 'erroneous spelling of "homogeneous"' - claims in it's current edition [4] that it is 'a spelling of "homogeneous" that represents a common pronunciation' (thus accepting the spelling). I would therefore suggest to consider 'homogenous' to be a false positive and drop it from the lintian database. [1] http://www.merriam-webster.com/dictionary/homogenous [2] http://grammarist.com/usage/homogenous-homogeneous/ [3] http://dictionary.reference.com/browse/homogenous [4] http://www.etymonline.com/index.php?search=homogenous -- System Information: Debian Release: stretch/sid APT prefers testing-updates APT policy: (500, 'testing-updates'), (500, 'stable-updates'), (500, 'unstable'), (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.3.0-1-amd64 (SMP w/8 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 lintian depends on: ii binutils 2.26-5 ii bzip2 1.0.6-8 ii diffstat 1.61-1 ii file 1:5.25-2 ii gettext 0.19.7-2 ii hardening-includes2.8+nmu2 ii intltool-debian 0.35.0+20060710.4 ii libapt-pkg-perl 0.1.29+b5 ii libarchive-zip-perl 1.56-2 ii libclass-accessor-perl0.34-1 ii libclone-perl 0.38-1+b1 ii libdpkg-perl 1.18.4 ii libemail-valid-perl 1.198-1 ii libfile-basedir-perl 0.07-1 ii libipc-run-perl 0.94-1 ii liblist-moreutils-perl0.413-1+b1 ii libparse-debianchangelog-perl 1.2.0-8 ii libperl5.22 [libdigest-sha-perl] 5.22.1-8 ii libtext-levenshtein-perl 0.13-1 ii libtimedate-perl 2.3000-2 ii liburi-perl 1.71-1 ii libyaml-libyaml-perl 0.41-6+b1 ii man-db2.7.5-1 ii patchutils0.3.4-1 ii perl 5.22.1-8 ii t1utils 1.39-2 ii xz-utils 5.1.1alpha+20120614-2.1 Versions of packages lintian recommends: ii dpkg 1.18.4 ii libperlio-gzip-perl 0.19-1+b1 ii perl 5.22.1-8 ii perl-modules-5.22 [libautodie-perl] 5.22.1-8 Versions of packages lintian suggests: pn binutils-multiarch ii dpkg-dev 1.18.4 ii libhtml-parser-perl3.72-1 ii libtext-template-perl 1.46-1 -- no debconf information
Bug#816638: mhonarc: fails to run with perl5.22
Package: mhonarc Version: 2.6.19-1 Severity: grave Justification: renders package unusable Dear Maintainer, I just installed 'mhonarc' for the first time, only to find that running 'mhonarc' fails: $ mhonarc Can't use 'defined(%hash)' (Maybe you should just omit the defined()?) at /usr/share/mhonarc/mhamain.pl line 1568. Compilation failed in require at /usr/bin/mhonarc line 39. $ mhonarc -help Can't use 'defined(%hash)' (Maybe you should just omit the defined()?) at /usr/share/mhonarc/mhamain.pl line 1568. Compilation failed in require at /usr/bin/mhonarc line 39. This obviously makes the package useless. Since #768132 has a similar errors, that seem to come from an incompatible version of perl, i guess that this error is again related to the version of perl. -- System Information: Debian Release: stretch/sid APT prefers testing-updates APT policy: (500, 'testing-updates'), (500, 'stable-updates'), (500, 'unstable'), (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.3.0-1-amd64 (SMP w/8 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 mhonarc depends on: ii perl 5.22.1-8 Versions of packages mhonarc recommends: ii libperl5.22 [libdigest-md5-perl] 5.22.1-8 mhonarc suggests no packages. -- no debconf information
Bug#816603: Ardour (4) - Adding FR translation to the desktop file
salut, thanks for your contribution. i have one question though: On 03/03/2016 01:42 PM, treb...@tuxfamily.org wrote: > GenericName[fr]=Enregistreur audio numérique Ardour 4 my french is a bit rusty, but this translation seems to be a bit too specific (ardour is much more than just a recording tool). according to wikipedia, the french equivalent for DAW would be "station audionumérique" gfmdsdt IOhannes signature.asc Description: OpenPGP digital signature
Bug#816768: v4l2loopback-dkms: simply fails with "Internal data flow error" on basi usage
On 03/04/2016 10:52 PM, Anonymous wrote: > If the same hardware boots Linux Mint instead of Debian stable, there > is no problem. This package installs completely, so that modprobe is > automatically run on boot, and the gstreamer test works, as well as > any other content given over gstreamer. So this is likely a problem > with the debian packaging. which version of Linux Mint is this? more importantly: which version of v4l2loopback are you running on Mint? for whatever reasons Mint doesn't list which v4l2loopback version it ships [1]. which version of GStreamer are you running on Mint? which version of GStreamer are you running on Debian? afaik, Mint only takes the Debian packages, so i doubt that there is an issue with packaging. [1] http://packages.linuxmint.com/search.php?keyword=v4l2loopback&release=any§ion=any signature.asc Description: OpenPGP digital signature
Bug#812088: ghostscript: Recommend gsfonts rather than Depend on them
Package: ghostscript Version: 9.16~dfsg-2 Severity: normal Dear Maintainer, since ghostscript can be used in various ways that do not require an installed font (e.g. ps2ascii), the 'gsfonts' package is not a strict dependency. the policy §7.2 says: > Recommends: > > This declares a strong, but not absolute, dependency. > The Recommends field should list packages that would be found together with > this one in all but unusual installations. as such i would recommend to demote the dependency to 'Recommends', to cater for the "unusual installation" case (e.g. limited ressources on a system that uses ghostscript for analyzing ps-files rather than to generate them) -- System Information: Debian Release: stretch/sid APT prefers testing-updates APT policy: (500, 'testing-updates'), (500, 'stable-updates'), (500, 'unstable'), (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.3.0-1-amd64 (SMP w/8 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 ghostscript depends on: ii debconf [debconf-2.0] 1.5.58 ii gsfonts1:8.11+urwcyr1.0.7~pre44-4.2 ii libc6 2.21-6 ii libgs9 9.16~dfsg-2 ghostscript recommends no packages. Versions of packages ghostscript suggests: pn ghostscript-x -- no debconf information
Bug#812182: /usr/bin/omindex: support wildcard mime-types
Package: xapian-omega Version: 1.2.21-2 Severity: wishlist File: /usr/bin/omindex Tags: upstream Dear Maintainer, i would like to suggest to support wildcard mimetypes as fallbacks. e.g. the following would use 'exiv2' for jpeg-images, 'mediainfo' for all other images and 'strings' for any other format for which there is no filter defined: $ omindex \ -Fimage/jpg:exiv2 \ -F"image/*":mediainfo \ -F"*/*":'strings -n8'" \ [...] please forward to the appropriate upstream channels. fgamsdr IOhannes -- System Information: Debian Release: stretch/sid APT prefers testing-updates APT policy: (500, 'testing-updates'), (500, 'stable-updates'), (500, 'unstable'), (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.3.0-1-amd64 (SMP w/8 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 xapian-omega depends on: ii libc6 2.21-6 ii libgcc11:5.3.1-5 ii libmagic1 1:5.25-2 ii libpcre3 2:8.38-1 ii libstdc++6 5.3.1-5 ii libxapian22v5 1.2.21-1.2 Versions of packages xapian-omega recommends: ii apache2 [httpd-cgi] 2.4.18-1 Versions of packages xapian-omega suggests: ii antiword 0.37-10+b1 ii catdoc 1:0.94.3~git20151007.fd634c2+dfsg-3 ii catdvi 0.14-12.1 ii djvulibre-bin 3.5.27.1-5 ii ghostscript9.16~dfsg-2 pn libemail-outlook-message-perl ii libhtml-parser-perl3.71-2+b1 ii libwpd-tools 0.10.1-1 ii libwps-tools 0.4.2-1 ii perl 5.22.1-3 ii poppler-utils [xpdf-utils] 0.38.0-2 pn rpm ii unrtf 0.21.9-clean-2 ii unzip 6.0-20 -- Configuration Files: /etc/omega.conf changed [not included] -- no debconf information
Bug#854431: dehydrated: please chown/chmod *.pem to root:ssl-cert
Package: dehydrated Version: 0.3.1-3 Followup-For: Bug #854431 +1 for this feature from my side. I was actually going to suggest to use a separate group (e.g. 'letsencrypt-cert') but re-using the 'ssl-cert' group sounds good for me as well.
Bug#864408: ITP: dehydrated-dnspython-hook -- dehydrated dns-01 challenge response support
Package: wnpp Severity: wishlist Owner: =?utf-8?q?IOhannes_m_zm=C3=B6lnig_=28Debian/GNU=29?= * Package name: dehydrated-dnspython-hook Version : 0.1 Upstream Author : Elizabeth Ferdman * URL : https://github.com/eferdman/dnspython-hook * License : GPL-3 Programming Lang: Python Description : dehydrated dns-01 challenge response support This package provides a hook script to serve dns-01 challenge responses for dehydated. . It uses the dnspython API to perform dynamic DNS updates, creating a temporary TXT record for the given domain, thereby proving ownership of the domain. It requires a DNS-server capable of performing dynamic DNS updates, like bind9. There is no need for the DNS-server to run on the local machine. . This is especially useful if you want to create ACME certificates for servers that do not serve HTTP and/or are not exposed to the public internet. Most ACME-related packages in Debian only deal with http-01 challenges. This one deals with dns-01. I intend to maintain this package under the "Debian Let's Encrypt" umbrella (provided that the team accepts this :-))
Bug#872906: gem: fails to load with Pd<<0.48
Package: gem Version: 1:0.93.3-11 Severity: normal Dear Maintainer, the fix for #872678 creates a Gem.pd_linux that is ABI incompatible with pd<<0.48. loading Gem fails with: > /usr/lib/pd/extra/Gem/Gem.pd_linux: /usr/lib/pd/extra/Gem/Gem.pd_linux: > undefined symbol: pd_maininstance either tighten the dependency on pd>=0.48, or provide a backwards compatible fix (which is preferred).
Bug#872905: pd-pdp: fails to load with Pd<0.47
Package: pd-pdp Version: 1:0.14.1-4 Severity: normal Dear Maintainer, the fix for #872675 creates a pdp.pd_linux that is ABI incompatible with pd<<0.48. loading pdp fails with: > /usr/lib/pd/extra/pdp/pdp.pd_linux: /usr/lib/pd/extra/pdp/pdp.pd_linux: > undefined symbol: pd_maininstance either tighten the dependency on pd>=0.48, or provide a backwards compatible fix (which i think is preferred). -- System Information: Debian Release: buster/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'oldstable-updates'), (500, 'unstable'), (500, 'testing'), (500, 'oldstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.9.0-3-amd64 (SMP w/8 CPU cores) Locale: LANG=de_AT.utf8, LC_CTYPE=de_AT.utf8 (charmap=UTF-8), LANGUAGE=de_AT.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages pd-pdp depends on: ii libc6 2.24-12 ii libgl1-mesa-glx [libgl1] 17.1.4-1 ii libglu1-mesa [libglu1]9.0.0-2.1 ii libgsl23 2.4+dfsg-6 ii libgslcblas0 2.4+dfsg-6 ii libpng16-16 1.6.30-2 ii libquicktime2 2:1.2.4-11 ii libsdl1.2debian 1.2.15+dfsg1-4 ii libv4l-0 1.12.5-1 ii libx11-6 2:1.6.4-3 ii libxext6 2:1.3.3-1+b2 ii libxv12:1.0.11-1 ii puredata 0.47.1-3 ii puredata-core [pd]0.47.1-3 ii zlib1g1:1.2.8.dfsg-5 Versions of packages pd-pdp recommends: pn pd-3dp pn pd-scaf pd-pdp suggests no packages. -- no debconf information
Bug#864408: Acknowledgement (ITP: dehydrated-dnspython-hook -- dehydrated dns-01 challenge response support)
Control: rename -1 ITP: dehydrated-hook-ddns-tsig Thanks. thankfully, upstream renamed the project to from "dnspython-hook" to "dehydrated-hook-ddns-tsig". signature.asc Description: OpenPGP digital signature
Bug#864408: Acknowledgement (ITP: dehydrated-dnspython-hook -- dehydrated dns-01 challenge response support)
Control: retitle -1 ITP: dehydrated-hook-ddns-tsig Thanks. thankfully, upstream renamed the project to from "dnspython-hook" to "dehydrated-hook-ddns-tsig". On 2017-06-08 09:21, Debian Bug Tracking System wrote: > Thank you for filing a new Bug report with Debian. > > 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. > > As you requested using X-Debbugs-CC, your message was also forwarded to > debian-de...@lists.debian.org, letsencrypt-de...@lists.alioth.debian.org > (after having been given a Bug report number, if it did not have one). > > Your message has been sent to the package maintainer(s): > w...@debian.org > =?utf-8?q?IOhannes_m_zm=C3=B6lnig_=28Debian/GNU=29?= > > If you wish to submit further information on this problem, please > send it to 864...@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#865419: ITP: libmysofa -- C library to read HRTFs stored in the AES69-2015 SOFA format
Package: wnpp Severity: wishlist Owner: =?utf-8?q?IOhannes_m_zm=C3=B6lnig_=28Debian/GNU=29?= * Package name: libmysofa Version : 0.4 Upstream Author : Christian Hoene * URL : https://github.com/hoene/libmysofa * License : BSD-3-clause Programming Lang: C Description : C library to read HRTFs stored in the AES69-2015 SOFA format Libmysofa is a light weight C-library intended to read SOFA (Spatially Oriented Format for Acoustics) files for spatial rendering. It hardly has any library dependencies and is suitable for embedded devices. . It reads SOFA files and checks whether the data complies to the "SimpleFreeFieldHRIR" conventions. In addition, it provides functions to look-up and interpolate the filters for a given orientation and to normalize the HRTFs (Head-Related Transfer Functions) to a reference level. apart from their general usefulness (for the spatial audio community), ffmpeg and vlc recently switched to libmysofa for reading SOFA-files, it might be a good idea to have these dependencies in Debian. I intend to maintain libmysofa under the pkg-multimedia umbrella.
Bug#873415: ITP: hyperlink -- A featureful, correct URL for Python
hi, On 08/27/2017 04:15 PM, Free Ekanayaka wrote: > Description : A featureful, correct URL for Python > > Hyperlink is a featureful, pure-Python implementation of the URL, with > an emphasis on correctness. imho, "A featureful, correct URL for Python" would be https://python.org (admittedly not *very* featureful), and I don't think that this can be packaged. so i'd like to suggest to improve both the short and the long description of this package. both speak of "the URL" as if it was an algorithm or the like. signature.asc Description: OpenPGP digital signature
Bug#35733: debhelper: dh_strip, dh_fixperms, dh_shlibdeps don't recognize all shared libs
On 09/13/2017 10:59 AM, IOhannes m zmölnig (Debian/GNU) wrote: > i've prepared a patch for dh_strip and dh_shlibdeps that is supposed to > fix this problem. > > https://anonscm.debian.org/git/users/umlaeute/debhelper.git the patch-set is in the "add-shlib" branch, in case anybody wondered... signature.asc Description: OpenPGP digital signature
Bug#35733: debhelper: dh_strip, dh_fixperms, dh_shlibdeps don't recognize all shared libs
i've prepared a patch for dh_strip and dh_shlibdeps that is supposed to
fix this problem.
https://anonscm.debian.org/git/users/umlaeute/debhelper.git
the patch adds a "--add-shlib=" option to dh_strip and dh_shlibdeps, to
specify additional globbing patterns to take into account for shared
libraries.
the option can be given multiple times to specify multiple patterns.
i've *not* prepared a patch for dh_fixperms because it is trivial enough
to fix the permissions manually.
also, the patch hit the size-limit ("<200 lines") of dh_strip (even
though i added only 8 lines of code, and removed 1...)
therefore, i've trimmed down the dh_strip code a bit, hopefully without
affecting code readability (however, some style checkers might
complain). it still feels a bit like cheating (and is done in a separate
commit, so it can be reverted).
mgfasdr
IOhannes
signature.asc
Description: OpenPGP digital signature
Bug#35733: [debhelper-devel] Bug#35733: debhelper: dh_strip, dh_fixperms, dh_shlibdeps don't recognize all shared libs
On 09/14/2017 10:46 PM, Niels Thykier wrote: > Assuming it is viable, I prefer it as it > means less work for maintainers (notably, no manual "--add-shlib" > arguments). fair enough (ah no: *way better*) > > * If you have time to spare, please consider testing this branch >[bug-35733-elf-detection] i've tested one of my pd-packages with the new debhelper in both compat=9 and compat=11 and compat=11 indeed does as advertised: dh_shlibdeps finds all dependencies automatically and dh_strip makes automatic debug packages! so from my side: heads up, please include this (that's going to be the first time i'll actively embrace bumping to a new dh-compat level asap) signature.asc Description: OpenPGP digital signature
Bug#872853: ruby-rugged: New upstream version 0.26.0
On Thu, 14 Sep 2017 10:19:00 + Ximin Luo wrote: > Control: severity -1 serious > > I've uploaded libgit2 to unstable and therefore bumping the severity of this > bug as described below. it seems that ruby-rugged_0.26.0-1 has been uploaded to experimental over a week ago, but the changelog forgot to close this bug (probably forgotten). please close this bug at your convenience. (for now, i'm not closing this myself due to the "sid"/"buster" tags and the updated package not yet appearing in any of these) fgasmdr IOhannes
Bug#876096: closing 876096
On 2017-09-18 15:31, Jonas Smedegaard wrote: > Quoting IOhannes m zmölnig (Debian/GNU) (2017-09-18 14:42:19) >> On 2017-09-18 14:14, Jonas Smedegaard wrote: >>> close 876096 0.9.7-3 >>> thanks >>> >> >> honestly i think this is a rather pointless exercise. > > Point is to provide our users with Free licensed software by default. hmm, the drumkits aren't software per se. i'm not saying that we shouldn't prefer free data. but we don't patch our browsers to only access free webservers. > > >> what's the difference between the drumkits provided by the >> "hydrogen-drumkits" package and the ones that can be downloaded via >> the "free" feed? > > The difference is that hydrogen-drumkits package provides our users with > all the drumkits that Debian has to offer which are packaged, whereas > the default Hydrogen feed provides our users with access to drumkits > claimed to be Free licensed. so what's the difference? which drumkits are included in hydrogen-drumkits that are not "claimed to be Free licensed" (regardless of RC#869180; even so all of the kits included in hydrogen-drumkits are *claimed* to be under a free license)? which drumkits do you get by using the feed URL but not having hydrogen-drumkits installed? is this an issue about reducing downloaded data/disk space? >> why is the upstream URL being removed from the source-code? (rather >> than just *adding* the only-free URL and making it the default?) > > URL is replaced (not removed) because it contains non-free items. well, yes; my point was that the upstream URL is no longer there. > > Sorry, I thought that was obvious: That is the very bug being addressed. i concur that it is a bug for a free software to allow users to fetch data from non-free sources. i'm with you that we should offer free data as the forst choice. i don't know why we should hide away the fact that there *is* non-free data which might. there's a slight difference between "offer only free dumkits by default" (which is the changelog entry for the patch) and "pretend that there are only free drumkits". >> this is actively taking away the freedom-of-choice from our users, and >> thus harmful. > > Our users have the freedom to add additional feed URLs, same as they can > add non-free sources to their APT configuration. I fail to see how > non-free stuff being opt-in is removal of freedoms. sure. users also have the freedom to just run 'apt-get source hydrogen; cd hydrogen-*; sed -e '/^2001/d' -i debian/patches; dpkg-buildpackge -rfakeroot' but in practice: how are they supposed to even know that there are non-free sources available? all documentation (that i could find) silently assumes that the user will be able to install the "official Hydrogen drumkits" from within the application by clicking "Update List" in the "Import Library" section. >> i would suggest to: >> - undo the fix for #876096 >> - have hydrogen-drumkits only include non-disputed drumkits (which i >> think are *much* more than the 2 kits provided by the current feed) > > I am currently working on setting up a service addons.debian.net > offering a automatically curated feed, subscribing to one or more > upstream feeds and stripping non-free and unlicensed items. this is great. but afaict this is only a replacement for the freepats list; it doesn't address the issue i'm having. fgmsdr IOhannes
Bug#868024: maintainer address broken
Control: submitter -1 umlae...@debian.org thanks On 2017-07-11 12:00, Debian Bug Tracking System wrote: > Thank you for filing a new Bug report with Debian. sorry for the mess in this bugreport (i was fighting a crashing reportbug). for the sake of readability, i repeat the actual bug-report: the email address of fusiondirectory's maintainer is . Unfortunately this mailinglist rejects mails from non-subscribers with the following message: On 2017-07-10 16:37, SYMPA wrote: > Your message for list 'packages' (attached below) was rejected. > You are not allowed to send this message for the following reason: > > Message distribution in the list is restricted to list subscribers. > If you are subscribed to the list with a different email address, you > should > either use that other email address or update your list membership > with the > new email address. > > > For further information, please contact packages- > requ...@lists.fusiondirectory.org this is a direct violation of the Debian policy, which states in §3.3: > The email address given in the Maintainer control field must accept > mail from those role accounts in Debian used to send automated mails > regarding the package. please fix this issue. gfmasdr IOhannes
Bug#868024: [packages] Processed: Re: Bug#868024: maintainer address broken
please keep the debian bug-report in the CC. the address is 868...@bugs.debian.org On 07/14/2017 04:01 PM, Benoit Mortier wrote: > Hello, > > the message are comming correctly into the mailing list as we receive it > and you can see it here > > https://lists.fusiondirectory.org/wws/arc/packages/2017-07/msg4.html hmm, well. then please downgrade the severity. in any case, if i get an automated reply from a bug report saying that "Your message [...] was rejected", then i must conclude that bugreport was rejected. after all, this is the only information i have. (sorry: you cannot expect some bug reporter to check whether the email shows up on some "random mailinglist archive". for all purposes, the reporter doesn't even know that they are posting to a mailinglist). gmadsr IOhannes signature.asc Description: OpenPGP digital signature
Bug#868736: watchcatd: non-Englishness in description
Package: watchcatd Severity: minor Dear Maintainer, the long description of the packages contains the sentence "[...], the watchcat helps killing him." from the context it is clear that "him" refers to a locked up process. but in English - unlike in other languages lke German or French - things (like "processes") are referred to via a neutral pronoun "it", rather than it's gendered versions "he" or "she". thus the sentence should read: "[...], the watchcat helps killing it." -- System Information: Debian Release: buster/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'oldstable-updates'), (500, 'unstable'), (500, 'testing'), (500, 'oldstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.9.0-3-amd64 (SMP w/8 CPU cores) Locale: LANG=de_AT.utf8, LC_CTYPE=de_AT.utf8 (charmap=UTF-8), LANGUAGE=de_AT.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages watchcatd depends on: ii libc6 2.24-12 ii libevent-2.0-5 2.0.21-stable-3 watchcatd recommends no packages. watchcatd suggests no packages.
Bug#847988: pd-libdir: does not respect current loader path
On 12/12/2016 10:06 PM, IOhannes m zmoelnig wrote: > please fix the loader, so it respects the 'path' argument. afaict, this is fixed in the upstream-clone at https://github.com/pure-data/libdir however, the code there needs review. gfamrd IOhannes signature.asc Description: OpenPGP digital signature
Bug#848224: [Letsencrypt-devel] Bug#848224: dehydrated-apache2: does not handle .well-known directory hidden by mod_rewrite
On 12/15/2016 06:03 PM, Mattia Rizzolo wrote: >> Unfortunately it had no effect on my system: accessing >> /.well-known/acme-challenge/ via my webserver would just give me a 404 page. >> >> Now, my webserver has the following characteristics >> - multiple VirtualHosts >> - use of mod_rewrite to do complex routing (in virtually all VirtualHosts). > > umh. > where do you configure the virtualhosts? If you have them on > /etc/apache2/sites-enabled those should not conflict and the conf this > package ships would be honored (I think?!). the vhosts are configured via /etc/apache2/sites-enabled, and i don't think there is a conflict per se. but i think that the mod_rewrite somehow cancels the conf from dehydrated-apache2. i probably should add, that mod_rewrite is rewriting the entire page (apache2 is the front-end to a plone CMS; for vhost support on the CMS side, i need complex proxying/rewriting capabilities such as offerend by mod_rewrite) > > In my systems I have a lot of virtulhosts too (although I don't have > that many rewrite rules) and everything works. > >> RewriteRule ^/\.well-known/acme-challenge/ - [L] >> >> Of course I would prefer a solution that would fix this in a central place >> (/etc/apache2/conf-available/dehydrated.conf). >> However, my feeble (and short-lived) attempts did not have any effect. > > Have you tried adding that line to > /etc/apache2/conf-enabled/dehydrated.conf? > that was precisely my unsatisfying and "feeble attempt" to fix it. fgmrs IOhannes signature.asc Description: OpenPGP digital signature
Bug#833271: librtaudio-dev: rtaudio.pc depends on libpulse-simple
Package: librtaudio-dev Version: 4.1.2~ds0-3 Severity: important Dear Maintainer, the rtaudio.pc as shipped with librtaudio-dev declares a dependency on libpulse-simple: $ cat /usr/lib/x86_64-linux-gnu/pkgconfig/rtaudio.pc | grep pulse Requires: alsa libpulse-simple $ Unfortunately the librtaudio-dev package does declare a dependency on a package providing libpulse-simple. basically the following is missing: > Depends: libpulse-dev This results in rendering the pkg-config file rather useless: $ pkg-config --cflags rtaudio Package libpulse-simple was not found in the pkg-config search path. Perhaps you should add the directory containing `libpulse-simple.pc' to the PKG_CONFIG_PATH environment variable Package 'libpulse-simple', required by 'rtaudio', not found $ This is in turn is rather important, as it prevents any package that relies on rtaudio's pkg-config and does not have an explicit Build-Depends on libpulse-dev (because it doesn't use libpulse-dev functionality itself) to FTBFS, due to the changed search path for the header-files. See [1] for a failed build. fgmasdr IOhannes [1] https://buildd.debian.org/status/fetch.php?pkg=jacktrip&arch=amd64&ver=1.1~repack-4%2Bb1&stamp=1470133103 -- System Information: Debian Release: stretch/sid APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'unstable'), (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.6.0-1-amd64 (SMP w/8 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 librtaudio-dev depends on: ii libasound2-dev1.1.1-2 ii libjack-jackd2-dev [libjack-dev] 1.9.10+20150825git1ed50c92~dfsg-2 ii librtaudio5a 4.1.2~ds0-3 librtaudio-dev recommends no packages. Versions of packages librtaudio-dev suggests: pn librtmidi-dev -- no debconf information
Bug#833429: git-import-orig: please provide (upstream) version to postimport hook
Package: git-buildpackage Version: 0.7.5 Severity: wishlist Dear Maintainer, as you might have noticed, i'm discovering the joys of gbp hooks and keep coming up with new issues... now: would it be possible to make the upstream version of the just-imported package available to a postimport-hook? in theory one could use dpkg-parsechangelog and mangle the debian version to the upstream version. but this is fragile, and gbp know the upstream-version anyhow, so why not use it directly. i'm dreaming of having a GBP_UPSTREAM_VERSION environment variable. (and while you are there, you could add a GBP_DEBIAN_VERSION variable as well, so there is *no* need at all to call dpkg-parsechangelog) such an env-variable (or a different one) could also be used to "determine" whether the hook is run from gbp or directly (something i eventually would like to know) thanks for your kind attentions. -- System Information: Debian Release: stretch/sid APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'unstable'), (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.6.0-1-amd64 (SMP w/8 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 git-buildpackage depends on: ii devscripts2.16.6 ii git 1:2.8.1-1 ii man-db2.7.5-1 ii python-dateutil 2.4.2-1 ii python-pkg-resources 20.10.1-1.1 ii python-six1.10.0-3 pn python:any Versions of packages git-buildpackage recommends: ii cowbuilder 0.80 ii pbuilder 0.225.2 ii pristine-tar 1.34 ii python-requests 2.10.0-2 Versions of packages git-buildpackage suggests: ii python-notify 0.1.1-4 ii sudo 1.8.17p1-2 ii unzip 6.0-20 -- no debconf information
Bug#833431: spf-tools-python: missing line-continuation in postinst
Package: spf-tools-python Version: 2.0.12t-2 Severity: grave Justification: renders package unusable Dear Maintainer, the postinst script calls update-alternative, which - due to the excessive length of the call - is split onto two lines (postinst:12-13) unfortunately the line-continuation (trailing "\"(´) is missing in postinst:12 which gives an error and renders the package uninstallable. > E: Sub-process /usr/bin/dpkg returned an error code (1) > spf-tools-python (2.0.12t-2) wird eingerichtet ... > /var/lib/dpkg/info/spf-tools-python.postinst: 13: > /var/lib/dpkg/info/spf-tools-python.postinst: --slave: not found > dpkg: Fehler beim Bearbeiten des Paketes spf-tools-python (--configure): > Unterprozess installiertes post-installation-Skript gab den Fehlerwert 127 > zurück > Fehler traten auf beim Bearbeiten von: > spf-tools-python -- System Information: Debian Release: stretch/sid APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'unstable'), (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.6.0-1-amd64 (SMP w/8 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 spf-tools-python depends on: ii python3-spf 2.0.12t-2 pn python3:any spf-tools-python recommends no packages. spf-tools-python suggests no packages. -- no debconf information
Bug#792534: ITP: pd-flext -- Flext C++ external layer for Pd (and similar)
control: retitle -1 ITP: pd-flext -- Flext C++ external layer for Pd thanks finally finding the time to do the packaging... fgmadf IOhannes
Bug#842970: dh-make: use .ex suffix consistently
Package: dh-make Version: 2.201608 Severity: normal Dear Maintainer, alll the example-files have a '.ex' suffix, with a single exception: .doc-base.EX please use the lower-case '.ex' throughout. -- System Information: Debian Release: stretch/sid APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'unstable'), (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.7.0-1-amd64 (SMP w/8 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 dh-make depends on: ii debhelper 10.2.2 ii dpkg-dev 1.18.10 ii make 4.1-9 ii python-enum34 1.1.6-1 pn python:any dh-make recommends no packages. Versions of packages dh-make suggests: ii build-essential 12.2 -- no debconf information
Bug#842995: dh-make: invalid Vcs-Git stanza
Package: dh-make
Version: 2.201608
Severity: normal
Dear Maintainer,
the Vcs-Git stanza generated by dh-make is simply wrong.
It reads:
https://anonscm.debian.org/collab-maint/${PKGNAME}.git
Whereas it should read:
https://anonscm.debian.org/git/collab-maint/${PKGNAME}.git
-- System Information:
Debian Release: stretch/sid
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'unstable'), (500, 'testing'),
(500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.7.0-1-amd64 (SMP w/8 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 dh-make depends on:
ii debhelper 10.2.2
ii dpkg-dev 1.18.10
ii make 4.1-9
ii python-enum34 1.1.6-1
pn python:any
dh-make recommends no packages.
Versions of packages dh-make suggests:
ii build-essential 12.2
-- no debconf information
Bug#842970: dh-make: use .ex suffix consistently
On 12/03/2016 11:12 AM, Craig Small wrote: >> alll the example-files have a '.ex' suffix, with a single exception: >>.doc-base.EX > It's done for a good reason. See #138785 i was not aware of that bug-report and i can follow it's arguing. however, my bug-report is mainly about a consistent suffix for all the example-files (rather than about using the literal `.ex`, even though this is what i suggested). so how about making all examples use the `.EX` suffix instead? gfdsamr IOhannes signature.asc Description: OpenPGP digital signature
Bug#847054: enigmail: keeps imap connections open
Package: enigmail Version: 2:1.9.6-2 Severity: normal Dear Maintainer, for a while, 'icedove' has tried to tell me that my user-password on one of my imap-accounts is invalid. Checking the imap server logs, it seeems that the account has exhausted its "maximum allowed connections per IP" (and thus the imap-server refuses any new connection attempts from my client). Restarting 'icedove' did *not* really help, so i checked what is eating up all my connections, and it turned out to be: gpg2! Because the processes are coupled with an imaps connection, i have a strong suspicion that the actual culprit is enigmail (which is the only piece of software that could possibly associate my imap-accounts from icedove with gpg2). Some of the gpg2 processes that keep a connection alive are quite long-lived, e.g. as of today (Dec.5), i have one that started on Nov.22 as an additional data point, i'm experiencing random crashes of icedove. while this might be unrelated to enigmail, these might be the reason why the forked gpg2 processes do not get cleaned up... -- System Information: Debian Release: stretch/sid APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'unstable'), (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.7.0-1-amd64 (SMP w/8 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 enigmail depends on: ii gnupg2.1.16-2 ii gnupg-agent 2.1.16-2 ii gnupg2 2.1.16-2 ii icedove 1:45.5.0-1 Versions of packages enigmail recommends: ii pinentry-gnome3 [pinentry-x11] 0.9.7-9 ii pinentry-gtk2 [pinentry-x11]0.9.7-9 enigmail suggests no packages. -- no debconf information
Bug#839952: libambix: FTBFS on *i386: basic2extended_identity4x4_float32__{f64, i32} fail
control: tags -1 upstream confirmed
thanks
On 2016-10-06 20:09, Aaron M. Ucko wrote:
> Source: libambix
> Version: 0.1-1
> Severity: important
> Justification: fails to build from source
>
> Builds of libambix for i386 and the non-release architectures
> hurd-i386 and kfreebsd-i386 all failed because the
> basic2extended_identity4x4_float32__{f64,i32} tests both did (along
> with the matrix test, reported separately just now as #839950). Could
> you please take a look?
>
> Thanks!
>
Bug#839950: libambix: FTBFS: matrix test fails
control: tags -1 upstream confirmed thanks On 2016-10-06 20:06, Aaron M. Ucko wrote: > Source: libambix > Version: 0.1-1 > Severity: important > Justification: fails to build from source > > Builds of libambix for several architectures failed due to an error in > the matrix test. These builds didn't log further details, but I > presume you should be able to reproduce the error on a porterbox. > FWIW, the architectures that failed so far in this fashion are arm64, > i386, powerpc, ppc64, and s390x, plus the non-release architectures > hurd-i386, kfreebsd-i386, and ppc64. However, builds for several more > architectures are still pending, so the problem may turn out to be > somewhat wider. > > The *i386 builds also encountered two other test suite errors, which > I'll report separately since they have not (so far) occurred elsewhere. >
Bug#733053: python-iptables has now been packaged
On 10/12/2016 05:18 PM, Adrian Bunk wrote: > python-iptables has now been packaged, unfortunately under > a new ITP (#836234) instead of the old one. > indeed. sorry for the confusion. i obviously wasn't aware of the old ITP. (there seems to be something about python-iptables so people miss the /other/ ITP :-)) fmard IOhannes signature.asc Description: OpenPGP digital signature
Bug#836163: ITP: python-bottle-cork -- authentication for the bottle web framework
Package: wnpp Severity: wishlist Owner: "IOhannes m zmölnig (Debian/GNU)" * Package name: python-bottle-cork Version : 0.12.0 Upstream Author : Federico Ceratto * URL : http://cork.firelet.net/ * License : LGPL Programming Lang: Python Description : authentication for the bottle web framework Cork provides a simple set of methods to implement Authentication and Authorization in web applications based on Bottle. . It is designed to stay out of the way and let you focus on what your application should do. I intend to maintain this package (and a few other bottle-related packages) within the Debian Python Modules Team.
Bug#836165: ITP: python-bottle-sqlite -- SQLite3 database integration for Bottle.
Package: wnpp Severity: wishlist Owner: "IOhannes m zmölnig (Debian/GNU)" * Package name: python-bottle-sqlite Version : 0.1.3 Upstream Author : Marcel Hellkamp * URL : http://bottlepy.org/docs/dev/plugins/sqlite.html * License : MIT Programming Lang: Python Description : SQLite3 database integration for Bottle. Bottle-sqlite is a plugin that integrates SQLite3 with your Bottle application. It automatically connects to a database at the beginning of a request, passes the database handle to the route callback and closes the connection afterwards. . To automatically detect routes that need a database connection, the plugin searches for route callbacks that require a db keyword argument (configurable) and skips routes that do not. This removes any overhead for routes that don’t need a database connection. I intend to maintain this package (and a few other bottle-related packages) within the Debian Python Modules Team.
Bug#836167: ITP: python-bottle-beaker -- Bottle plugin to session and caching library with WSGI Middleware
Package: wnpp Severity: wishlist Owner: "IOhannes m zmölnig (Debian/GNU)" * Package name: python-bottle-beaker Version : 0.1.3 Upstream Author : Thiago Avelino * URL : https://github.com/bottlepy/bottle-beaker * License : MIT Programming Lang: Python Description : Bottle plugin to session and caching library with WSGI Middleware beaker is a middleware for the bottle web framework, that adds session and caching management in a transparent way. For all practical use-cases, this is a dependency for projects using python-bottle-cork. I intend to maintain this package (and a few other bottle-related packages) within the Debian Python Modules Team,
Bug#836261: RM: python-pytz -- ROM; already packaged as python-tz
Package: ftp.debian.org Severity: normal this time everything was very fast: it took <2 hours between filing an ITP and uploading the package, and <8 hours for the package to be accepted into unstable. while being busy with packaging, i missed sramacher's message that the package is already in Debian (although under a different name that made me miss it when i searched for it). therefore, please remove it. fgmasdr IOhannes
Bug#832120: ardour3: could not create project in "/home/rouven/Ardour/blablabla"
Control: reassign -1 src:ardour3 thanks This bug really concerns the ardour3 sourcepackage (no longer found in Debian/stretch). gfmsrd IOhannes signature.asc Description: OpenPGP digital signature
Bug#833917: open-iscsi: LVM fails to see iSCSI targets for non-mounted devices with systemd.
thanks for the prompt reply.
On 2016-08-10 15:52, Christian Seiler wrote:
> Could you give me the output of the following?
>
> journalctl -u open-iscsi
attached as open-iscsi.log
i have also attached a 2nd logfile open-iscsi2.log, which contains some
more messages (after the initial connection to the iSCSI target failed
and before open-iscsi tries to reactivate the VG) from the kernel,
shwing how the interface is being brought up.
/dev/sdb and /dev/sdc are both LUNs on the iSCSI target, with /dev/sdc1
being the PV that is "missing" for the virthosts VG:
# pvdisplay /dev/sdc1
--- Physical volume ---
PV Name /dev/sdc1
VG Name virthosts
PV Size 4.57 TiB / not usable 2.98 MiB
Allocatable yes
PE Size 4.00 MiB
Total PE 1199270
Free PE 937126
Allocated PE 262144
PV UUID aLUEMH-r0mE-JubT-GB13-H6Hr-4ECS-wcHCBp
#
>
> Also, since you upgraded from squeeze could you also check the
> following?
>
> md5sum /etc/init.d/open-iscsi
> dpkg-query --showformat='${Conffiles}\n' --show open-iscsi
# md5sum /etc/init.d/open-iscsi
817ffebd8f614186bc8b71bf04fc5e74 /etc/init.d/open-iscsi
# dpkg-query --showformat='${Conffiles}\n' --show open-iscsi
/etc/default/open-iscsi 9ee140f93df0f1dbacb2b31f10f3e048
/etc/init.d/open-iscsi 817ffebd8f614186bc8b71bf04fc5e74
/etc/init.d/umountiscsi.sh 3979757143a96910fa4c9a6237cbd58c
/etc/iscsi/initiatorname.iscsi 300e739ab922027433765db3a88921c1
/etc/iscsi/iscsid.conf f156fdcd48f575760452f8d72ad8546a
#
so it seems that my /etc/init.d/open-scsi is pristine enough...
and while i'm there:
# uname -a
Linux HOST 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt25-2+deb8u3
(2016-07-02) x86_64 GNU/Linux
mgfasdr
IOhannes
-- Logs begin at Mon 2016-08-08 12:01:24 CEST, end at Thu 2016-08-11 10:53:22 CEST. --
Aug 08 12:01:53 HOST iscsid[1126]: iSCSI logger with pid=1129 started!
Aug 08 12:01:53 HOST open-iscsi[1084]: Starting iSCSI initiator service: iscsid.
Aug 08 12:01:53 HOST open-iscsi[1084]: Setting up iSCSI targets:
Aug 08 12:01:54 HOST iscsid[1129]: iSCSI daemon with pid=1130 started!
Aug 08 12:01:57 HOST iscsid[1129]: connect to 192.168.134.100:3260 failed (No route to host)
Aug 08 12:01:59 HOST open-iscsi[1084]: Logging in to [iface: default, target: iqn.2002-10.com.infortrend:raid.sn7802675.001, portal: 192.168.134.100,3260] (multiple)
Aug 08 12:01:59 HOST open-iscsi[1084]: Login to [iface: default, target: iqn.2002-10.com.infortrend:raid.sn7802675.001, portal: 192.168.134.100,3260] successful.
Aug 08 12:01:59 HOST open-iscsi[1084]: .
Aug 08 12:01:59 HOST open-iscsi[1084]: Activating iSCSI volume groups: virthosts Couldn't find device with uuid aLUEMH-r0mE-JubT-GB13-H6Hr-4ECS-wcHCBp.
Aug 08 12:01:59 HOST open-iscsi[1084]: Refusing activation of partial LV virthosts/bardata. Use '--activationmode partial' to override.
Aug 08 12:01:59 HOST open-iscsi[1084]: 20 logical volume(s) in volume group "virthosts" now active
Aug 08 12:01:59 HOST open-iscsi[1084]: .
Aug 08 12:01:59 HOST open-iscsi[1084]: Mounting network filesystems:.
Aug 08 12:01:59 HOST open-iscsi[1084]: Enabling network swap devices:.
Aug 08 12:02:00 HOST iscsid[1129]: Connection1:0 to [target: iqn.2002-10.com.infortrend:raid.sn7802675.001, portal: 192.168.134.100,3260] through [iface: default] is operational now
-- Logs begin at Mon 2016-08-08 12:01:24 CEST, end at Thu 2016-08-11 10:53:22 CEST. --
Aug 08 12:01:53 HOST iscsid[1126]: iSCSI logger with pid=1129 started!
Aug 08 12:01:53 HOST open-iscsi[1084]: Starting iSCSI initiator service: iscsid.
Aug 08 12:01:53 HOST open-iscsi[1084]: Setting up iSCSI targets:
Aug 08 12:01:54 HOST iscsid[1129]: iSCSI daemon with pid=1130 started!
Aug 08 12:01:57 HOST iscsid[1129]: connect to 192.168.134.100:3260 failed (No route to host)
Aug 08 12:01:58 HOST kernel: igb :02:00.1 eth1: igb: eth1 NIC Link is Up 100 Mbps Full Duplex, Flow Control: RX/TX
Aug 08 12:01:59 HOST kernel: scsi8 : iSCSI Initiator over TCP/IP
Aug 08 12:01:59 HOST kernel: scsi 8:0:0:0: Direct-Access IFT A16E-G2130-4 373I PQ: 0 ANSI: 5
Aug 08 12:01:59 HOST kernel: sd 8:0:0:0: Attached scsi generic sg4 type 0
Aug 08 12:01:59 HOST kernel: sd 8:0:0:0: [sdb] 4096000 512-byte logical blocks: (20.9 TB/19.0 TiB)
Aug 08 12:01:59 HOST kernel: scsi 8:0:0:1: Direct-Access IFT A16E-G2130-4 373I PQ: 0 ANSI: 5
Aug 08 12:01:59 HOST kernel: sd 8:0:0:0: [sdb] Write Protect is off
Aug 08 12:01:59 HOST kernel: sd 8:0:0:0: [sdb] Mode Sense: 8f 00 00 08
Aug 08 12:01:59 HOST kernel: sd 8:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
Aug 08 12:01:59 HOST kernel: sd 8:0:0:1: Attached scsi generic sg5 type 0
Aug 08 12:01:59 HOST kernel: sd 8:0:0:1: [sdc] 9824428032 512-byte logical blocks: (5.03 TB/4.57 TiB)
Aug 08 12:01:59 HOST kernel: scsi 8:0:0:2: Enclosure IFT A16E-G2130-4 373I PQ: 0 ANSI: 4
Aug 08 12:01:59 HOST kernel: sd 8:0
Bug#833917: open-iscsi: LVM fails to see iSCSI targets for non-mounted devices with systemd.
On 08/11/2016 11:30 AM, Christian Seiler wrote: In the init scripts, there's line 110 that contains udevadm settle || true; Could you add a sleep 1 _before_ that line and see if that fixes things for you? indeed. i did a reboot and now all the virtual machines are running! thanks for the workaround. but given that a race-condition cannot be "fixed" with a sleep, do you think that there is a proper solution for the problem as well? for now, the suggested hack will need to do. gfmadsr IOhannes
Bug#841868: Segfault in Gtk::Widget::show() since upgrading to 5.*
On 2016-10-24 13:48, Pietro Battiston wrote: > Il giorno lun, 24/10/2016 alle 12.06 +0200, Fabian Greffrath ha > scritto: >> It's just a wild guess, but this >> >> Pietro Battiston wrote: >>> >>> Package: ardour >>> Version: 1:5.4.0~dfsg-1 >> [...] >>> >>> ii ardour-data 1:4.2~dfsg-5 >> >> just doesn't seem corect to me! >> > > Oooohhh... > right. > This explains everything. > > Package "ardour" should probably depend on the same exact version of > package "ardour-data". this is the fix i uploaded today with 1:5.4.0~dfsg-2 fgasdr IOhannes
Bug#837805: Acknowledgement (ITP: python-can -- Controller Area Network interface module for Python)
Control: retitle -1 ITP: python-can -- Controller Area Network interface module for Python Thanks. Ooops, seems like i forgot the subject in this ITP On Wed, Sep 14, 2016 at 08:09:05PM +, Debian Bug Tracking System wrote: > Thank you for filing a new Bug report with Debian. > > 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. > > As you requested using X-Debbugs-CC, your message was also forwarded to > debian-pyt...@lists.debian.org, debian-de...@lists.debian.org > (after having been given a Bug report number, if it did not have one). > > Your message has been sent to the package maintainer(s): > w...@debian.org > IOhannes m zmölnig (Debian/GNU) > > If you wish to submit further information on this problem, please > send it to 837...@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. > > -- > 837805: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=837805 > Debian Bug Tracking System > Contact ow...@bugs.debian.org with problems >
Bug#614502: [xlwt] new upstream comes with Python 3 support
hi, since once of my packages (python3-canmatrix) also depends on/recommends xlwt, i also hope that xlwt could support py3 in the near future. luckily,... On Wed, 23 Feb 2011 14:55:02 +0100 Jan Dittberner wrote: > tags 614502 + help upstream > thanks ...it seems that the upstream version 1.1.2 (released 2016/06) already covers python3 support, at least according to https://pypi.python.org/pypi/xlwt so please package new upstream, and include py3 support. thanks for making Debian a better place. gfmasrd IOhannes signature.asc Description: OpenPGP digital signature
Bug#820347: juce: diff for NMU version 4.1.0+repack-4.1
On 04/07/2016 08:38 PM, Tobias Frost wrote: > On Thu, 7 Apr 2016 18:40:41 +0200 Gianfranco Costamagna debian.org> wrote: [...] >> >> Dear maintainer, >> >> I have prepared a patch for juce, but I don't feel confident with it, > so I didn't upload as NMU. [...] > > Hi Gianfranco, > > Patch looks good to me. > I'll take it and schedula an NMU. > thanks gianfranco or the patch and tobi for checking doing an NMU. i have just uploaded the package (including some other changes i was preparing while the NMU came in). just for the record: i would prefer if you did not close the NMU-bug manually right after an upload to DELAYED/*. instead it would be great if the bug was closed automatically once the ixed package entered the archive (so if you are doing an NMU that has a bug attached to it, please close the bug via the changelog). of course feel free to tag the bug as "pending" in the meantime. speaking of DELAYED: using DELAYED/5 stresses me a *little* bit, but so far i was always able to manage a proper upload in time, so i guess it is not a big issue :-) gfmadsr IOhannes signature.asc Description: OpenPGP digital signature
Bug#820431: smplayer: Please keep the package in the repository up-to-date
Control: found -1 15.11.0~ds0-1 Control: notfound -1 16.4.0 Control: severity -1 wishlist Control: tags -1 pending Thanks On 04/08/2016 01:22 PM, Simon wrote: > Package: smplayer > Version: 16.4.0 hmm, as far as i understand, if the package version was 16.4.0 than this bug-report would be void. > Severity: normal > > Dear Maintainer, > > Currently the version in the repository is 15.11 while the version available > from the developer website is 16.4. > Wouldn't it be possible to keep the repository version alligned with the > official version? we (the package maintainers) strive to keep our packages up-to-date. if they are not at the same version as upstream, there is usually a reason for this (mostly lack of manpower). The good news is that an updated package has been uploaded an hour ago by sramacher. gfmards IOhannes signature.asc Description: OpenPGP digital signature
Bug#820653: juce: incorrect Homepage
Control: tags -1 pending Thanks. On 04/11/2016 05:28 AM, Paul Wise wrote: > Source: juce > Severity: normal > > The Homepage for juce is incorrect, it should be this instead: > > https://www.juce.com/ > > The current homepage redirects to a domain squatter website: > > http://www.igloo.com/domain/juce.org > signature.asc Description: OpenPGP digital signature
Bug#1073176: gramps: Error with loss of data: TypeError: '<' not supported between instances of 'str' and 'NoneType'
On 14/06/2024 05:59, Mark Robinson wrote: Package: gramps Version: 5.2.2+dfsg-0.1 Severity: grave Justification: causes non-serious data loss bummer. Dear Maintainer, New version of gramps in Trixie upgrade. Insisted on upgrading database advising to create backup without means. the latter would be an upstream bug. Upgraded and loaded database. Spat error, lost new record. could you get into detail with the last bit? - when was the new record created? - how was it lost? i would expect that either the db migration fails (in which case records might get lost, but regardless of being "new" or not). or the db migration succeeds, and then everything should work™ (if it doesn't then it should also not work with a completely new db - and gramps would be seriously broken) gmdsar IOhannes
Bug#1016685: v4l2loopback: CVE-2022-2652 - leaking kernel memory via crafted card labels
On Mon, 8 Aug 2022 07:29:01 +0100 Neil Williams wrote: No changes are required in the misfiled bug report. so how to proceed? should i just close this bug-report? mgfdsa IOhannes
