Bug#1071084: Updated patch
A slightly adjusted patch which uses one more newline:
--- /usr/update-locale 2024-05-13 23:42:46.584127893 +0200
+++ /usr/sbin/update-locale 2024-05-14 11:18:56.086121879 +0200
@@ -88,7 +88,7 @@
{
# Check that this locale does exist
my $charset = `LANG= LC_CTYPE= LC_NUMERIC= LC_TIME= LC_COLLATE=
LC_MONETARY= LC_MESSAGES= LC_PAPER= LC_NAME= LC_ADDRESS= LC_TELEPHONE=
LC_MEASUREMENT= LC_IDENTIFICATION= LC_ALL= $env locale charmap 2>&1`;
- die "*** $progname: Error: invalid locale settings: $env\n"
+ die "*** $progname: Error: invalid locale settings:
$env\n\n--\n$charset--\n"
if ($charset =~ m/Cannot set/);
# If LANGUAGE is set, its first value must be compatible with
LC_MESSAGES
if (defined $arg{LANGUAGE})
Bug#1071084: locales: update-locale hides error information when invoking 'locale charmap'
Package: locales
Version: 2.38-10
Severity: normal
Tags: newcomer, patch
The perl script update-local internally invokes 'locale charmap' to perform
additional checks.
However if this call fails for some reason, update-locale always only prints
"Error: invalid locale settings: LANG=" which can be very misleading when
the root-cause is actually different.
I.e. sample output of "sudo /usr/sbin/update-locale LANG=de_AT.UTF-8" on Debian
Trixie:
*** update-locale: Error: invalid locale settings: LANG=de_AT.UTF-8
After applying the following patch:
==
--- /usr/update-locale 2024-05-13 23:42:46.584127893 +0200
+++ /usr/sbin/update-locale 2024-05-13 23:40:25.160121142 +0200
@@ -88,7 +88,7 @@
{
# Check that this locale does exist
my $charset = `LANG= LC_CTYPE= LC_NUMERIC= LC_TIME= LC_COLLATE=
LC_MONETARY= LC_MESSAGES= LC_PAPER= LC_NAME= LC_ADDRESS= LC_TELEPHONE=
LC_MEASUREMENT= LC_IDENTIFICATION= LC_ALL= $env locale charmap 2>&1`;
- die "*** $progname: Error: invalid locale settings: $env\n"
+ die "*** $progname: Error: invalid locale settings:
$env\n\n--$charset--\n"
if ($charset =~ m/Cannot set/);
# If LANGUAGE is set, its first value must be compatible with
LC_MESSAGES
if (defined $arg{LANGUAGE})
==
The output contains the actual information why the call to "locale chaarmap"
failed, thus making it possible to investigate why the call actually failed:
===
*** update-locale: Error: invalid locale settings: LANG=de_AT.UTF-8
--locale: Cannot set LC_CTYPE to default locale: No such file or
directory
locale: Cannot set LC_MESSAGES to default locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory
ANSI_X3.4-1968
--
===
-- System Information:
Debian Release: trixie/sid
APT prefers testing
APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 6.5.0-2-amd64 (SMP w/2 CPU threads; PREEMPT)
Locale: LANG=de_AT.UTF-8, LC_CTYPE=C.UTF-8 (charmap=locale: Cannot set
LC_MESSAGES to default locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory
UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages locales depends on:
ii debconf [debconf-2.0] 1.5.86
ii libc-bin 2.38-10
ii libc-l10n 2.38-10
locales recommends no packages.
locales suggests no packages.
-- debconf information:
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LANGUAGE = (unset),
LC_ALL = (unset),
LC_TIME = "de_AT.UTF-8",
LC_MONETARY = "de_AT.UTF-8",
LC_CTYPE = "C.UTF-8",
LC_ADDRESS = "de_AT.UTF-8",
LC_TELEPHONE = "de_AT.UTF-8",
LC_NAME = "de_AT.UTF-8",
LC_MEASUREMENT = "de_AT.UTF-8",
LC_IDENTIFICATION = "de_AT.UTF-8",
LC_NUMERIC = "de_AT.UTF-8",
LC_PAPER = "de_AT.UTF-8",
LANG = "de_AT.UTF-8"
are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").
locales/locales_to_be_generated:
locales/default_environment_locale: None
Bug#973883: comment
I see the same issue about invalid permissions of /var/log/apt-cacher-ng when installing the latest package on bookworm. I installed it multiple times on this VM before without this issue, not sure why it started to fail in this way now. Somehow the /var/log/apt-cacher-ng directory has owner = "root", no manual intervention was done as far as I am aware. When apt-cacher-ng package is installed it fails with the error about permission on /var/log/apt-cacher-ng folder. Could it be some sort of regression via some other package which adjusts permission of files in /var/log? apt-cacher-ng does not seem to have had any release lately so no regression there. Could either the installation of the package perform a check and fix or the systemd service could adjust access rights during startup to make apt-cacher-ng more robust against such invalid permissions?
Bug#1033436: retitle
retitle 1033436 Failed to execute goal org.apache.maven.plugins:maven-surefire-plugin:2.22.3:test
Bug#1033407: duplicate bugs
merge 1033407 1032989 -- These two bug-reports sound very similar, #1032989 has a lot of investigation already.
Bug#1032468: More info needed
Works as expected on a fresh installation of bookworm. Can you provide the output of the following command dpkg --list | grep dbus P.S. Regarding "First, any recommended application is expected to work without any issue" => This sounds a bit strange when you are actually using a totally free operating system built by volunteers! Please consider how much you can "expect" or "request" here. Better to spend time yourself to improve Debian. If you think the application or X-Windows itself should do things differently, you are welcome to provide improvements and patches to the upstream projects!
Bug#1028713: Comment
A stacktrace from the segmentation fault looks like follows.
It triggers consistently for me with the following steps in a source-tree
fakeroot debian/rules binary
cd sample_data/
/tmp/salmon-1.9.0+ds1/obj-x86_64-linux-gnu/src/salmon index -t
transcripts.fasta -i sample_salmon_quasi_index
#0 0x77495993 in __GI__IO_fwrite (buf=0x7fffc978, size=1,
count=82,
fp=0x76060400) at ./libio/iofwrite.c:37
#1 0x5560f55d in spdlog::details::file_helper::write
(this=0x7607f980,
msg=...) at ./include/spdlog/details/../sinks/../details/file_helper.h:90
#2 0x556299dd in
spdlog::sinks::simple_file_sink::_sink_it
(msg=...,
this=0x7607f970) at ./include/spdlog/details/../sinks/file_sinks.h:45
#3 spdlog::sinks::base_sink::log
(this=0x7607f970,
msg=...) at ./include/spdlog/sinks/base_sink.h:37
#4 0x55618aa3 in spdlog::logger::_sink_it
(this=0x76025810, msg=...)
at /usr/include/c++/12/bits/shared_ptr_base.h:1665
#5 0x55a8ae19 in spdlog::logger::log (fmt=0x55cd7f0b
"mphf size = {} MB", lvl=spdlog::level::info, this=0x76025810) at
./external/pufferfish/include/spdlog/details/logger_impl.h:74
#6 spdlog::logger::info (arg1=, fmt=0x55cd7f0b
"mphf size = {} MB", this=0x76025810) at
./external/pufferfish/include/spdlog/details/logger_impl.h:145
#7 pufferfishIndex (indexOpts=...) at
./external/pufferfish/src/PufferfishIndexer.cpp:660
#8 0x556636ae in SalmonIndex::buildPuffIndex_ (idxOpt=...,
indexDir=...,
this=0x7603e280) at ./include/SalmonIndex.hpp:111
#9 SalmonIndex::build (idxOpt=..., indexDir=..., this=0x7603e280) at
./include/SalmonIndex.hpp:76
#10 salmonIndex (argc=, argv=) at
./src/BuildSalmonIndex.cpp:247
#11 0x555fe510 in std::function
>&)>::operator()(int, char const**, std::unique_ptr >&) const (__args#2=std::unique_ptr = {...},
__args#1=, __args#0=, this=0x7604e1a8) at
/usr/include/c++/12/bits/std_function.h:591
#12 main (argc=, argv=0x7fffe028) at ./src/Salmon.cpp:267
Bug#1027305: Bug-Investigation
It seems the module does not yet support Python newer than 3.7 (3.9 in the latest version on Github), see https://github.com/ilius/pyglossary/tree/master/pyglossary/plugin_lib Copying the folder pyglossary/plugin_lib/py37 to py310 and py311 fixes this build-error for me.
Bug#1026725: Comment
The next minor version 20.2.0 has this test removed as part of removing support for Python2 and 3.5, see commit https://github.com/hynek/structlog/commit/f65309d4f66fbd44c09288a485107d725c3da1d4#diff-673441c4b6dbee451d8130f1e9bb48f3dbc44d5d3acf1c21d52d0904002342d5 So it might be justified to simply remove or disable this test until the next version-upgrade is done for the package.
Bug#1019455: laminard: WebUI of laminar fails because newer incompatible version of Chart.js is included
Package: laminard Version: 1.1-1+b2 Severity: grave Justification: renders package unusable laminar currently uses Chart.js 2.7.2 (also in newer version 1.2 and on latest master) Debian packaging replaces this with the version packaged in Debian, which is 3.9.x curently, the bookworm-package of laminar seems to actually include 3.7.1. Version 2 and 3 of Chart.js are not compatible and thus the WebUI of laminar cannot be used at all! The JavaScript error in Browser-console is "Chart.scaleService is undefined". See https://github.com/ohwgiles/laminar/issues/175 for the related upstream report. -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.18.0-3-amd64 (SMP w/2 CPU threads; PREEMPT) Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) Versions of packages laminard depends on: ii init-system-helpers 1.64 ii libc62.34-7 ii libcapnp-0.9.1 0.9.1-4+b1 ii libgcc-s112.2.0-1 ii libsqlite3-0 3.39.3-1 ii libstdc++6 12.2.0-1 ii sysuser-helper 1.3.7+really1.4.1 ii zlib1g 1:1.2.11.dfsg-4.1 Versions of packages laminard recommends: ii daemon 0.8-1 laminard suggests no packages. -- Configuration Files: /etc/laminar.conf changed [not included] -- no debconf information
Bug#978201: Add link to upstream patch/commit
The necessary fix seems to be at https://github.com/crossbario/autobahn-cpp/commit/eac22bd61117ac18b5efee3c6da16a97835055de, applying this fixes building the package.
Bug#931926: tiger: removing tiger package fails in postrm because /var/log/tiger is removed before somehow
Package: tiger
Version: 1:3.2.4~rc1-1
Severity: normal
Dear Maintainer,
I am installing debian machines via Ansible and also clean out some packages
sometimes.
When trying to uninstalling tiger, sometimes the postrm script fails because
/var/log/tiger
does not exist any more when the postrm script is run.
I verified that before removal of the package the directory /var/log/tiger did
still exist,
but uninstalling did still fail somehow, so it seems the uninstallation of
tiger somehow
removes this directory as part of normal package removal and then the postrm
script fails
because the directory is not available any more.
However it was not always reproducible and I could not pinpoint the exact
circumstances for this
to happen.
Maybe the postrm script should handle this more gracefully by not failing when
the directory
is not there any more.
This is the output of my Ansible playbook
TASK [Uninstall tiger first to work around a bug in postrm]
*
task path: /opt/svn/Ansible/tasks/cleanout.yml:60
fatal: [bionic]: FAILED! => {
"changed": false,
"rc": 100
}
STDOUT:
Reading package lists...
Building dependency tree...
Reading state information...
The following packages were automatically installed and are no longer required:
chkrootkit john john-data tripwire
Use 'sudo apt autoremove' to remove them.
The following packages will be REMOVED:
tiger*
0 upgraded, 0 newly installed, 1 to remove and 3 not upgraded.
After this operation, 2545 kB disk space will be freed.
(Reading database ... 346436 files and directories currently installed.)
Removing tiger (1:3.2.4~rc1-1) ...
Processing triggers for mime-support (3.62) ...
Processing triggers for gnome-menus (3.31.4-3) ...
Processing triggers for man-db (2.8.5-2) ...
Processing triggers for desktop-file-utils (0.23-4) ...
(Reading database ... 346061 files and directories currently installed.)
Purging configuration files for tiger (1:3.2.4~rc1-1) ...
find: '/var/log/tiger/': No such file or directory
dpkg: error processing package tiger (--purge):
installed tiger package post-removal script subprocess returned error exit
status 1
Errors were encountered while processing:
tiger
libdvd-pkg: Checking orig.tar integrity...
/usr/src/libdvd-pkg/libdvdcss_1.4.2.orig.tar.bz2: OK
libdvd-pkg: `apt-get check` failed, you may have broken packages. Aborting...
STDERR:
E: Sub-process /usr/bin/dpkg returned an error code (1)
MSG:
'apt-get remove 'tiger'' failed: E: Sub-process /usr/bin/dpkg returned an error
code (1)
-- System Information:
Debian Release: 10.0
APT prefers stable
APT policy: (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.19.0-5-amd64 (SMP w/1 CPU core)
Kernel taint flags: TAINT_CRAP
Locale: LANG=de_AT.UTF-8, LC_CTYPE=de_AT.UTF-8 (charmap=UTF-8),
LANGUAGE=de_AT.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages tiger depends on:
ii binutils 2.31.1-16
ii bsdmainutils 11.1.2+b1
ii debconf [debconf-2.0] 1.5.71
ii libc6 2.28-10
ii net-tools 1.60+git20180626.aebd88e-1
ii ucf3.0038+nmu1
Versions of packages tiger recommends:
ii chkrootkit 0.52-3+b10
ii john1.8.0-2+b1
ii postfix [mail-transport-agent] 3.4.5-1
ii tripwire2.4.3.7-1+b10
Versions of packages tiger suggests:
ii lsof 4.91+dfsg-1
-- debconf information excluded
Bug#931581: Acknowledgement (tiger: purging tiger package fails in postrm because /var/log/tiger is removed before somehow)
I use the following patch in a PPA package at
https://launchpad.net/~dominik-stadler/+archive/ubuntu/ppa/+packages to
make it work for me
--- tiger-3.2.4~rc1.orig/debian/postrm
+++ tiger-3.2.4~rc1/debian/postrm
@@ -11,9 +11,8 @@
purge)
for dir in /var/log/tiger/ /var/lib/tiger/work /var/lib/tiger/
/var/run/tiger/
do
- [ -d "$dir" ] && {
- find "$dir" -type d -o -exec rm -f {} \;
- find "$dir" -type d -exec rmdir {} \;
+ [ -d "$dir" ] && {
+ rm -rf "$dir"
}
done
# Do we have any tigerXX files under /var/log/? if so we should remove
On Sun, Jul 7, 2019 at 10:45 PM Debian Bug Tracking System <
ow...@bugs.debian.org> wrote:
> Thank you for filing a new Bug report with Debian.
>
> You can follow progress on this Bug here: 931581:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=931581.
>
> This is an automatically generated reply to let you know your message
> has been received.
>
> Your message is being forwarded to the package maintainers and other
> interested parties for their attention; they will reply in due course.
>
> Your message has been sent to the package maintainer(s):
> Javier Fernández-Sanguino Peña
>
> If you wish to submit further information on this problem, please
> send it to 931...@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.
>
> --
> 931581: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=931581
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems
>
Bug#931581: tiger: purging tiger package fails in postrm because /var/log/tiger is removed before somehow
Package: tiger Version: 1:3.2.4~rc1-1 Severity: normal Dear Maintainer, I am installing debian machines via Ansible and also clean out some packages sometimes. When trying to uninstalling tiger via "apt-get purge", sometimes the postrm script fails because /var/log/tiger does not exist any more when the postrm script is run. I verified that before removal of the package the directory /var/log/tiger did still exist, but uninstalling does still fail, it seems the uninstallation of tiger somehow removes this directory as part of normal package removal and then the postrm script fails because the directory is not available any more. Maybe the postrm script should handle this more gracefully by not failing when the directory is not there any more. This is the output of my Ansible playbook The following packages will be REMOVED: tiger* 0 upgraded, 0 newly installed, 1 to remove and 3 not upgraded. After this operation, 2545 kB disk space will be freed. (Reading database ... 346436 files and directories currently installed.) Removing tiger (1:3.2.4~rc1-1) ... Processing triggers for mime-support (3.62) ... Processing triggers for gnome-menus (3.31.4-3) ... Processing triggers for man-db (2.8.5-2) ... Processing triggers for desktop-file-utils (0.23-4) ... (Reading database ... 346061 files and directories currently installed.) Purging configuration files for tiger (1:3.2.4~rc1-1) ... find: '/var/log/tiger/': No such file or directory dpkg: error processing package tiger (--purge): installed tiger package post-removal script subprocess returned error exit status 1 Errors were encountered while processing: tiger libdvd-pkg: Checking orig.tar integrity... /usr/src/libdvd-pkg/libdvdcss_1.4.2.orig.tar.bz2: OK libdvd-pkg: `apt-get check` failed, you may have broken packages. Aborting... -- System Information: Debian Release: 10.0 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-5-amd64 (SMP w/1 CPU core) Kernel taint flags: TAINT_CRAP Locale: LANG=de_AT.UTF-8, LC_CTYPE=de_AT.UTF-8 (charmap=UTF-8), LANGUAGE=de_AT.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages tiger depends on: ii binutils 2.31.1-16 ii bsdmainutils 11.1.2+b1 ii debconf [debconf-2.0] 1.5.71 ii libc6 2.28-10 ii net-tools 1.60+git20180626.aebd88e-1 ii ucf3.0038+nmu1 Versions of packages tiger recommends: ii chkrootkit 0.52-3+b10 ii john1.8.0-2+b1 ii postfix [mail-transport-agent] 3.4.5-1 ii tripwire2.4.3.7-1+b10 Versions of packages tiger suggests: ii lsof 4.91+dfsg-1 -- debconf information excluded
Bug#907183: can be closed?
as far as I see this is resolved since some time already via lirc (0.10.1-1) unstable; urgency=medium * New minor upstream release. * Add fix for lirc-setup(1) crash on startup. * Services besides lircd.socket disabled after install. * Bump standards-version to 4.2.1 without changes. * Drop 0001-build... patch now upstreamed. * Obsolete priority: extra => optional. -- Alec Leamas Fri, 12 Oct 2018 16:51:50 -0400
Bug#929472: facedetect: Facedetect can depend only on opencv-data instead of libopencv-dev
Package: facedetect
Version: 0.1-2
Severity: normal
Tags: patch
This package currently has libopencv-dev as a runtime-dependency.
However the README states that either opencv-data or libopencv-dev need to
be installed.
In fact, when scanning the sources of the package, it seems only stuff from
/usr/share/opencv
is required, which is provided by opencv-data.
So the dependencies of facedetect can be reduced a lot by only depending on
opencv-data.
Otherwise many development packages are dragged in as part of
libopencv-data.
This also resolves #856593 as it would make the actually required
dependency on opencv-data explicit
-- System Information:
Debian Release: 10.0
APT prefers testing
APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.19.0-4-amd64 (SMP w/1 CPU core)
Kernel taint flags: TAINT_CRAP, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages facedetect depends on:
ii libopencv-dev 3.2.0+dfsg-6
ii python3 3.7.2-1
ii python3-opencv 3.2.0+dfsg-6
Versions of packages facedetect recommends:
ii imagemagick 8:6.9.10.23+dfsg-2.1
ii imagemagick-6.q16 [imagemagick] 8:6.9.10.23+dfsg-2.1
facedetect suggests no packages.
-- no debconf information
From 716a5bc890389c3ca9877a01738bcb280ac3b465 Mon Sep 17 00:00:00 2001
From: Dominik Stadler
Date: Thu, 23 May 2019 19:27:19 +0200
Subject: [PATCH] Replace dependency on libopencv-dev with opencv-data
---
debian/control | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/debian/control b/debian/control
index fd73cbb..c31695c 100644
--- a/debian/control
+++ b/debian/control
@@ -15,7 +15,7 @@ Package: facedetect
Architecture: any
Depends: ${misc:Depends},
${python3:Depends},
- libopencv-dev,
+ opencv-data,
python3,
python3-opencv
Recommends: imagemagick
--
2.17.1
Bug#929470: facedetect: Facedetect can depend on opencv-data instead of libopencv-dev
Package: facedetect
Version: 0.1-2
Severity: normal
Tags: patch
This package currently has libopencv-dev as a runtime-dependency.
However the README states that either opencv-data or libopencv-dev need to be
installed.
In fact, when scanning the sources of the package, it seems only stuff from
/usr/share/opencv
is required, which is provided by opencv-data.
So the dependencies of facedetect can be reduced a lot by only depending on
opencv-data.
Otherwise many development packages are dragged in as part of libopencv-data.
-- System Information:
Debian Release: 10.0
APT prefers testing
APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.19.0-4-amd64 (SMP w/1 CPU core)
Kernel taint flags: TAINT_CRAP, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages facedetect depends on:
ii libopencv-dev 3.2.0+dfsg-6
ii python3 3.7.2-1
ii python3-opencv 3.2.0+dfsg-6
Versions of packages facedetect recommends:
ii imagemagick 8:6.9.10.23+dfsg-2.1
ii imagemagick-6.q16 [imagemagick] 8:6.9.10.23+dfsg-2.1
facedetect suggests no packages.
-- no debconf information
>From 716a5bc890389c3ca9877a01738bcb280ac3b465 Mon Sep 17 00:00:00 2001
From: Dominik Stadler
Date: Thu, 23 May 2019 19:27:19 +0200
Subject: [PATCH] Replace dependency on libopencv-dev with opencv-data
---
debian/control | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/debian/control b/debian/control
index fd73cbb..c31695c 100644
--- a/debian/control
+++ b/debian/control
@@ -15,7 +15,7 @@ Package: facedetect
Architecture: any
Depends: ${misc:Depends},
${python3:Depends},
- libopencv-dev,
+ opencv-data,
python3,
python3-opencv
Recommends: imagemagick
--
2.17.1
Bug#850627: Note
Bug #914217 would fix this one via update to the latest version from Git, see Changelog at https://github.com/afrantzis/bless/blob/master/NEWS
Bug#914217: Update
This would also fix bugs #767216 and #850627 and maybe one or two more.
Bug#924635: Update
Bug #925533 re-adds the messaging and jms modules in libspring, so this bug could be merged as duplicate with that one now.
Bug#924634: Update
Bug #925533 re-adds the messaging and jms modules in libspring, so this bug could be merged as duplicate with that one now.
Bug#924634:
Not sure if I read the package-pages correctly, but https://packages.debian.org/search?keywords=libspring-jms-java=names=all=all looks to me like libspring-jms-java is still (or again) available both in buster and sid, so this bug is not a problem any more, right?
Bug#923759: Bug update
Yes, sorry, I found how it was fixed by a followup upload, -5 did not as far as I see, only -6 will fix it I think. I am also a bit new to the Debian Bug-via-mail interface, I'll try to fix the bug-state. Sorry for the spam.
Bug#923759: Update
I think the current changes do not properly fix this, I created https://salsa.debian.org/java-team/netlib-java/merge_requests/2 with the set of changes based on previous patches that I think would make the classes be built again and also improve error handling slightly to make it easier to spot the actual error during building.
Bug#924804: Duplicate
This is the same as bug #923759 as far as I see
Bug#725787: I've packaged svn 1.8.4 and serf 1.3.2 by myself
Thanks for this, I was trying to do this myself but stumbled over some issues. With your packages I was able to create packages for Ubuntu precise at a so called PPA at https://launchpad.net/~dominik-stadler/+archive/subversion-1.8, for serf I used a different way of packaging, not sure where I got that one from. For the Subversion package I only did minor changes compared to your version mostly because apache-packaging is a bit different in Precise. Unfortunately I cannot help much with the Debian packaging as I am not a Debian maintainer... FYI, locally also some tests were failing, but on the automated build machine for the PPA, the packages built just fine with all tests passing, not sure where the difference is here, but this was the same with 1.7.x versions of Subversion as well. On Mon, Nov 11, 2013 at 4:35 PM, vita...@yourcmc.ru wrote: Hello everyone! I've recently packaged svn 1.8.4 and serf 1.3.2 (which is needed by svn) by myself. I've never tried to perform any package maintenance, but I would be very happy if these packages could be reviewed in some way and taken as the base for real debian upload... So can you (someone? maintainers?) review it? Source and binary packages are here (add to /etc/apt/sources.list): deb http://vmx.yourcmc.ru/var/debian/ unstable/ deb-src http://vmx.yourcmc.ru/var/debian/ unstable/ The public key for my mini-archive can be taken here (run as command): apt-key adv --keyserver pgp.mit.edu --recv c9d991da5f98c882 I've taken the 1.7 debian package as a base and removed/added/adjusted some patches. Most tests pass... sqlite query plan tests with sqlite 3.8 were a tricky part, I've added a patch which loads correct index statistics in every SVN working copy database (without that SQLite 3.8 with NGQP didn't want to use indexes correctly)... Yet most tests doesn't mean all, and I don't know how to correctly fix those that don't pass - it seems they're not related to build environment. So build it with: DEB_BUILD_OPTIONS=nocheck dpkg-buildpackage -- To unsubscribe, send mail to 725787-unsubscr...@bugs.debian.org. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#716793:
The related Ubuntu bug at https://bugs.launchpad.net/bugs/1200715 has links to a package with some related fixes that are necessary to build the new version.
Bug#621692: Subversion-1.7 packages for Debian/Ubuntu
FYI, the package are now updated at https://launchpad.net/~dominik-stadler/+archive/subversion-1.7/, changes include: * take perl-related files from /usr/local for libsvn-perl to actually deliver SVN::Core et. al. Not sure why they now end up in /usr/local, probably a different fix is needed to fix this correctly. * adjust dependency on libserf, get rid of libserf-private in serf for now which blocked packages from installation * fix building svn-make-config on Ubuntu Oneiric and Precise by adding some dependencies to the link statement If you are interested in taking a look at the actual changes, I have a git-repository for this and the push to https://gitorious.org/subversion-ppais currently underway. Thanks... Dominik. On Thu, Nov 3, 2011 at 8:28 AM, Jonathan Nieder jrnie...@gmail.com wrote: Hi Dominik, Dominik Stadler wrote: I have a git repository where I host the packaging-changes, I can put that on gitorious or github, if anybody is interested. Yes, please. Thanks, Jonathan
Bug#621692: Subversion-1.7 packages for Debian/Ubuntu
Hi,
I invested some time and worked on a package, based on this Bug. You can
find the resulting packages compiled for Ubuntu Lucid (10.4) in my
Ubuntu-PPA at https://launchpad.net/~dominik-stadler/+archive/subversion-1.7,
packages for other versions of Ubuntu are in progress in my other PPAs.
I tried to keep Patches that are still valid and backport necessary newer
versions of some packages to Lucid, which is what I still run locally.
Remaining Items/Problems:
* Had to remove subversion-tools as most items are not part of the
Subversion source package any more, are they added by Debian?
* Had to disable some patches for ruby as I do not know enough to even try
to apply them
* Could not apply patch no-extra-libs, had strange errors when trying to
refresh it
* for me aprutils was needed in some additional libraries, patch
needs_aprutil takes care of this, probably a different fix is needed here
* I had some trouble updating the libsvn1.symbols, I am sure they are not
completely correct now
* perl-manpage seems to be gone
* some contrib items are gone, I had to remove the lines from
.install-files
* something needed symbols from an *_fs_* library, I therefore removed the
exclude on dh_makeshlibs in rules, again the proper fix probably is
different
* not all tests run fine, but according to changelog entries this seems to
be partly because of problems in Subversion itself.
* Of the patches above,
04-build-fixes-vs-swig_checkedhttp://bugs.debian.org/cgi-bin/bugreport.cgi?msg=20;filename=04-build-fixes-vs-swig_checked;att=4;bug=621692,
08-rpath-refreshhttp://bugs.debian.org/cgi-bin/bugreport.cgi?msg=20;filename=08-rpath-refresh;att=8;bug=621692,
09-apr-abi-refresh,
http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=20;filename=09-apr-abi-refresh;att=9;bug=621692
10-loosen-sqlite-version-check-refreshhttp://bugs.debian.org/cgi-bin/bugreport.cgi?msg=20;filename=10-loosen-sqlite-version-check-refresh;att=10;bug=621692are
not applied, not sure about
07-no-extra-libs-2-refreshhttp://bugs.debian.org/cgi-bin/bugreport.cgi?msg=20;filename=07-no-extra-libs-2-refresh;att=7;bug=621692
Other changes:
* Somehow the libraries ended up with name *.0.0.0 instead of *.1.0.0
previously, I created a patch to fix this again
* Had to add -r to some calls to ${RM} in rules
* Update compatibility for debhelper to 8
* Added dependencies on libserf-dev and libmagic-dev
* Update to 1.7.1 underway
* added --with-serf=/usr to try to include support for libserf
I have to confess that I do not know enough about debian packaging, even
much less about how Subversion is built and packaged so the package is
surely not done, however it does the job for me, i.e. the resulting binaries
allow me to run subversion client and other svn-based tools like kdesvn, I
do not run a SVN Server, so I could not check this part.
I hope this helps in creating official packages, I have a git repository
where I host the packaging-changes, I can put that on gitorious or github,
if anybody is interested.
Dominik
Bug#607426: mtools: Add support for zip-files to uz/lz
Package: mtools
Version: 4.0.10-1ubuntu2~ppa2
Severity: wishlist
I created a small patch to mtools that enables support for zip-files for
uz/lz, which I find very handy as I now have one utility to look at and
extract archive files.
-- System Information:
Debian Release: squeeze/sid
APT prefers lucid-updates
APT policy: (500, 'lucid-updates'), (500, 'lucid-security'), (500,
'lucid-backports'), (500, 'lucid')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.32-24-generic-tuxonice (SMP w/2 CPU cores)
Locale: LANG=de_AT.utf8, LC_CTYPE=de_AT.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages mtools depends on:
ii dpkg 1.15.5.6ubuntu4.4 Debian package management system
ii install-info 4.13a.dfsg.1-5ubuntu1 Manage installed documentation in
ii libc6 2.11.1-0ubuntu7.6 Embedded GNU C Library: Shared lib
mtools recommends no packages.
Versions of packages mtools suggests:
pn floppyd none (no description available)
-- no debconf information
Index: mtools-4.0.10/scripts/uz
===
--- mtools-4.0.10.orig/scripts/uz 2010-04-13 22:55:33.0 +0200
+++ mtools-4.0.10/scripts/uz 2010-04-13 23:02:34.0 +0200
@@ -42,10 +42,12 @@
case $0 in
*uz)
tarparam=-pxvf
+ zipparam=
action=Extracting from
;;
*lz)
tarparam=-tvf
+ zipparam=-l
action=Reading directory of
;;
*)
@@ -64,23 +66,31 @@
echo 2
found=
- for suffix in .gz .tgz .tar.gz .z .tar.z .taz .tpz .Z .tar.Z .tar.bz2; do
+ for suffix in .gz .tgz .tar.gz .z .tar.z .taz .tpz .Z .tar.Z .tar.bz2 .zip .jar .war .ear .aar; do
if [ -r ${1}$suffix ]; then
found=$1$suffix
break
fi
done
+ unzip=0
case $found in
*.tar.bz2 | *.tb2)
uzcmd='bzip2 -cd'
;;
+ *.zip | *.jar | *.war | *.ear | *.aar)
+ unzip=1
+ ;;
esac
if [ -z $found ]; then
echo $0: could not read \$1\. 2
else
echo $action \$found\. 2
- $uzcmd -- $found | tar $tarparam -
+ if [ $unzip = 1 ]; then
+ unzip $zipparam -- $found
+ else
+ $uzcmd -- $found | tar $tarparam -
+ fi
fi
shift
done
Bug#574883: libqjson-dev: FindQJSON.cmake is not found when using cmake-2.8
Actually the official Debian build of tellico-2.3 uses a much simpler solution, namely to add -DCMAKE_MODULE_PATH=/usr/share/apps/cmake/modules to the cmake command in debian/rules This allows the file to be found and used correctly. Thanks... Dominik. On Sun, Aug 22, 2010 at 9:57 PM, Dominik Stadler dominik.stad...@gmx.atwrote: FYI, the same problem happens when packaging the new tellico version 2.3, I used the attached patch to build it.
Bug#574883: libqjson-dev: FindQJSON.cmake is not found when using cmake-2.8
FYI, the same problem happens when packaging the new tellico version 2.3, I
used the attached patch to build it.
Index: tellico-2.3/cmake/modules/FindQJson.cmake
===
--- /dev/null 1970-01-01 00:00:00.0 +
+++ tellico-2.3/cmake/modules/FindQJson.cmake 2010-08-22 21:55:16.0 +0200
@@ -0,0 +1,39 @@
+# - Try to find the QJson library
+# Once done this will define
+#
+# QJSON_FOUND - system has the QJson library
+# QJSON_INCLUDE_DIR - the QJson include directory
+# QJSON_LIBRARY - Link this to use the QJson library
+#
+# Copyright (c) 2010, Pino Toscano, toscano.p...@tiscali.it
+#
+# Redistribution and use is allowed according to the terms of the BSD license.
+# For details see the accompanying COPYING-CMAKE-SCRIPTS file.
+
+if (QJSON_INCLUDE_DIR AND QJSON_LIBRARY)
+
+ # in cache already
+ set(QJSON_FOUND TRUE)
+
+else (QJSON_INCLUDE_DIR AND QJSON_LIBRARY)
+ if (NOT WIN32)
+find_package(PkgConfig)
+pkg_check_modules(PC_QJSON QJson)
+ endif(NOT WIN32)
+
+ find_path(QJSON_INCLUDE_DIR qjson/parser.h
+HINTS
+${PC_QJSON_INCLUDE_DIRS}
+ )
+
+ find_library(QJSON_LIBRARY NAMES qjson
+HINTS
+${PC_QJSON_LIBRARY_DIRS}
+ )
+
+ include(FindPackageHandleStandardArgs)
+ find_package_handle_standard_args(QJson DEFAULT_MSG QJSON_LIBRARY QJSON_INCLUDE_DIR)
+
+ mark_as_advanced(QJSON_INCLUDE_DIR QJSON_LIBRARY)
+
+endif (QJSON_INCLUDE_DIR AND QJSON_LIBRARY)
Index: tellico-2.3/CMakeLists.txt
===
--- tellico-2.3.orig/CMakeLists.txt 2010-08-22 21:55:23.0 +0200
+++ tellico-2.3/CMakeLists.txt 2010-08-22 21:55:30.0 +0200
@@ -90,7 +90,7 @@
include_directories(${LIBEXEMPI_INCLUDE_DIR})
endif(LIBEXEMPI_FOUND)
-macro_optional_find_package(QJSON)
+find_package(QJson REQUIRED)
macro_log_feature(QJSON_FOUND QJSON Support for searching OpenLibrary and Freebase http://qjson.sourceforge.net; FALSE )
# once we make webcam support enabled by default, we can remove this logic
Bug#589624: fop-0.95 has a race condition in using ICC_Profile from java awt
Package: fop Version: 1:0.95.dfsg-11 FOP has a race condition through it's usage of class ICC_Profile from java.awt, it is more likely to trigger this if more cores are used on newer machines. See the discussion at http://old.nabble.com/Re:-ConcurrentModificationException-error-td27166097.html, fix is very localized and is available as diff in latest trunk at http://svn.apache.org/viewvc?view=revisionrevision=904467 Fop 1.0 will contain this fix in will be available soon, but as 0.95 will stay for a while still, it would be good to get this fix backported to 0.95 as well as we are hitting this problem with the current version. Thanks... Dominik. Dominik Stadler, Team Lead F +43 732 21018 | E dominik.stad...@dynatrace.commailto:dominik.stad...@dynatrace.com | Skype: stadler.dominik dynaTrace is Continuous APM Monitor. Resolve. Prevent. Web: http://www.dynatrace.comhttp://www.dynatrace.com/ | Blog: http://blog.dynatrace.comhttp://blog.dynatrace.com/ Learn about dynaTrace in 2 minuteshttp://www.dynatrace.com/twominutedemo/Default.aspx | Forrester rates dynaTrace On Firehttp://applicationperformance.dynatrace.com/Forrester_Business_Transaction_Management_Report.html. Get your copy of the report herehttp://applicationperformance.dynatrace.com/Forrester_Business_Transaction_Management_Report.html. This e-mail message, including any attachments, is confidential and may contain legally privileged information. This message is intended solely for the use of the addressee. Use by others is prohibited. Disclosure, copying and distribution of this information to third parties is not permitted. If you have received this message in error, please notify us immediately and delete it from your system. The integrity and security of this message cannot be guaranteed and it may be subject to data corruption, interception and unauthorized amendment, for which we accept no liability.
Bug#589624:
Yes, it should be fixed in 1.0 according to the SVN-log. As it is hard to reproduce for me, I cannot actually verify it in 1.0. It only appeared once during 2 months of testing and thus might be appearing only in certain specific conditions. Review of code-change in SVN looks good, though. Thanks... Dominik. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
