Bug#1053826: gcc-12: internal compiler error with template specialization on floating point non-type-param in C++20 mode
Package: gcc-12
Version: 12.3.0-10
Severity: normal
X-Debbugs-Cc: andre.nauj...@keysight.com
Hello.
The following piece of code generates a compiler error with gcc-12 in C++20
mode:
template
struct F {
static double foo() { return D; }
};
template
struct F {
static double foo() { return 1.0; }
};
int main()
{
return F::foo();
}
gcc-13 in sid does compile this correctly. on godbolt only gcc-trunk, not
gcc-13, compiles this, so from my point of view, it may be a Debian patch in
gcc-13 in sid, which fixes this.
The error (on gcc-12 from sid) is this:
$ g++-12 -std=c++20 -o test test.cpp
test.cpp: In function ‘int main()’:
test.cpp:13:29: internal compiler error: in unify, at cp/pt.cc:24903
13 | return F::foo();
| ^~
0x7f41729256c9 __libc_start_call_main
../sysdeps/nptl/libc_start_call_main.h:58
0x7f4172925784 __libc_start_main_impl
../csu/libc-start.c:360
Please submit a full bug report, with preprocessed source (by using -freport-
bug).
Please include the complete backtrace with any bug report.
See for instructions.
gcc in bookworm looks a little different but should be the same bug:
$ g++ -std=c++20 -o test test.cpp
test.cpp: In function 'int main()':
test.cpp:13:29: internal compiler error: in unify, at cp/pt.cc:24832
13 | return F::foo();
| ^~
0x1afaeb6 internal_error(char const*, ...)
???:0
0x69ec5a fancy_abort(char const*, int, char const*)
???:0
0x813491 most_specialized_partial_spec(tree_node*, int)
???:0
0x830231 instantiate_class_template(tree_node*)
???:0
0x86621b complete_type(tree_node*)
???:0
0x7f5c79 c_parse_file()
???:0
0x8e019d c_common_parse_file()
???:0
Please submit a full bug report, with preprocessed source (by using -freport-
bug).
Please include the complete backtrace with any bug report.
See for instructions.
Thanks in advance!
Andre
-- System Information:
Debian Release: trixie/sid
APT prefers unstable-debug
APT policy: (500, 'unstable-debug'), (500, 'unstable')
Architecture: amd64 (x86_64)
Kernel: Linux 6.5.0-2-amd64 (SMP w/16 CPU threads; PREEMPT)
Locale: LANG=C.UTF-8, 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)
LSM: AppArmor: enabled
Versions of packages gcc-12 depends on:
ii binutils 2.41-6
ii cpp-12 12.3.0-10
ii gcc-12-base12.3.0-10
ii libc6 2.37-12
ii libcc1-0 13.2.0-5
ii libgcc-12-dev 12.3.0-10
ii libgcc-s1 13.2.0-5
ii libgmp10 2:6.3.0+dfsg-2
ii libisl23 0.26-3
ii libmpc31.3.1-1
ii libmpfr6 4.2.1-1
ii libstdc++6 13.2.0-5
ii libzstd1 1.5.5+dfsg2-2
ii zlib1g 1:1.2.13.dfsg-3
Versions of packages gcc-12 recommends:
ii libc6-dev 2.37-12
Versions of packages gcc-12 suggests:
ii gcc-12-doc 12.2.0-1
pn gcc-12-locales
pn gcc-12-multilib
-- no debconf information
Bug#1028104: libboost-dev: Boost with C++20 uses unavailable std functions.
For anyone stumbling upon this. A simple workaround is to '#include ' before '#include ' utility is the header that declares std::exchange this does not look like a C++20 problem but a simple missing include in the boost headers. Maybe this is actually worth a small patch in debian, since its such a simple problem to avoid. And I don't think an added include would break anything(?). best regards Andre
Bug#1042001: [Pkg-utopia-maintainers] Bug#1042001: libblockdev3 leaks empty directories in bd_fs_get_free_space on btrfs partition
Hi Micahel, Thanks for the very quick reply. I'd do that, but I do not have (or plan to have) a github account. And I don't see a way to file an issue there without one. Some more info here actually. You can trigger this even easier by just calling 'udiskctl status' as a user and I'd assume some other commands from udiskctl as well. I guess thats the way steam gets to trigger this, too. When using udiskctl the directories actually belong to root and no longer to the user, that issued the query. Regards, Andre On 25.07.23 16:27, Michael Biebl wrote: Hi Andre, thanks for the elaborate bug report. Would you mind filing it upstream at https://github.com/storaged-project/libblockdev/ either as an issue or directly as a PR. Regards, Michael
Bug#1042001: libblockdev3 leaks empty directories in bd_fs_get_free_space on btrfs partition
Package: libblockdev3
Version: 3.0.2-1
Severity: normal
Tags: upstream
Dear Maintainer,
libblockdev seems to leak empty temporary directories, when the function
bd_fs_get_free_space is called (even unsuccessfully) on a btrfs partition as it
calls fs_mount internally, which then either fails and exhibits the behavior OR
succeeds and btrfs_get_info leaks the directory.
I am relatively sure that this is not limited to btrfs, but that is what I have
here.
I noticed this while steam was running and my /tmp directory was suddenly
overflowing with hundreds of blockdev.XX directories. I don't know what
steam does there or if it is in fact steam itself, proton or something else,
but libblockdev should not leak the directories.
This little piece of code demonstrates the problem. It does not matter, if the
device exists or not. It just cannot be mounted already.
Run it and an empty blockdev.XX dir remains in /tmp
#include
#include
#include
int main()
{
GError *err = NULL;
BDPluginSpec fs_plugin = {BD_PLUGIN_FS, NULL};
BDPluginSpec *plugins[] = {_plugin, NULL};
if (!bd_init(plugins, NULL, )) {
fprintf(stdout, "failed to init lib: %s\n", err->message);
}
err = NULL;
guint64 space = bd_fs_get_free_space("/dev/sda1", "btrfs", );
if (space == 0) {
fprintf(stdout, "failed to get fs size: %s\n", err->message);
} else {
fprintf(stdout, "%d\n", space);
}
return 0;
}
As far as I can see, the following patch should remedy at least the unsuccessul
path, where the device cannot be mounted. However, I have not tested this!!
diff --git a/src/plugins/fs/generic.c b/src/plugins/fs/generic.c
index 21032b8a..843de8b1 100644
--- a/src/plugins/fs/generic.c
+++ b/src/plugins/fs/generic.c
@@ -650,6 +650,7 @@ static gchar* fs_mount (const gchar *device, gchar *fstype,
gboolean read_only,
if (!ret) {
g_propagate_prefixed_error (error, l_error, "Failed to mount '%s':
", device);
g_free (mountpoint);
+g_rmdir (tempdir);
return NULL;
} else
*unmount = TRUE;
I am not sure how to handle the successful calls to fs_mount from the other
functions in that file. Do we really need to delete the dir downstream in all
the calling functions? Seems strange to me, but I don't see a different
solution right now.
Ps:
fs_mount() might also leak a little memory in case it creates the tmp mount,
but I am not certain enough about the behavior of glib2 here (i.e. valgrind
does not immediately see this as a definite leak). reassigning 'mountpoint'
with the result of g_mkdtemp() looks as if the original memory, returned by
g_build_path() is lost? The glib documentation at least suggests a leak here.
from line 642ff:
mountpoint = g_build_path (G_DIR_SEPARATOR_S, g_get_tmp_dir (),
"blockdev.XX", NULL);
mountpoint = g_mkdtemp (mountpoint);
Regards
Andre
-- System Information:
Debian Release: trixie/sid
APT prefers unstable-debug
APT policy: (500, 'unstable-debug'), (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 6.3.0-2-amd64 (SMP w/12 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages libblockdev3 depends on:
ii libblockdev-utils3 3.0.2-1
ii libc6 2.37-6
ii libglib2.0-02.76.4-3
libblockdev3 recommends no packages.
libblockdev3 suggests no packages.
-- no debconf information
Bug#1041973: capnproto: not usable with gcc-13 and c++20
Source: capnproto
Version: 0.9.2-3
Severity: normal
Tags: upstream,fixed-upstream
X-Debbugs-Cc: andre.nauj...@keysight.com
Currently the C++ generated code from capnproto does not work with gcc-13 and
C++20.
This can be reproduced by generating and compiling code for e.g. the sample
addressbook capnp file
(https://github.com/capnproto/capnproto/tree/v0.9.2/c%2B%2B/samples), which is
part of capnproto, like this:
# capnpc -oc++ addressbook.capnp
# g++ -std=c++20 -c addressbook.capnp.c++ -o a.o
^^^ this fails
This seems to be fixed upstream in the current version (0.10.4).
I am currently helping myself by applying the following patch locally on the
installed libcapnp-dev package, which is not really sustainable as a solution
and further limits it to my machine. I am not sure, if this has other
implications, either and the upstream fix is different to (and looks to be more
involved than) this as well.
--- /usr/include/kj/string.h_up 2023-07-25 13:11:59.197903043 +0200
+++ /usr/include/kj/string.h2023-07-25 09:57:21.938385607 +0200
@@ -159,10 +159,8 @@
friend class SourceLocation;
};
-#if !__cpp_impl_three_way_comparison
inline bool operator==(const char* a, const StringPtr& b) { return b == a; }
inline bool operator!=(const char* a, const StringPtr& b) { return b != a; }
-#endif
template <> char StringPtr::parseAs() const;
template <> signed char StringPtr::parseAs() const;
@@ -268,10 +266,8 @@
Array content;
};
-#if !__cpp_impl_three_way_comparison
inline bool operator==(const char* a, const String& b) { return b == a; }
inline bool operator!=(const char* a, const String& b) { return b != a; }
-#endif
String heapString(size_t size);
// Allocate a String of the given size on the heap, not including NUL
terminator. The NUL
-- System Information:
Debian Release: trixie/sid
APT prefers unstable-debug
APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 6.4.0-1-amd64 (SMP w/16 CPU threads; PREEMPT)
Locale: LANG=C.UTF-8, 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)
LSM: AppArmor: enabled
Bug#1023204: (no subject)
Just FYI. This is "fixed" in the current samba-libs version. Am 5. November 2022 19:05:19 MEZ schrieb Andre Naujoks : >I am also affected by this. I worked around this by installing the samba-libs >package from testing and pinning the version to 2:4.16* > >This workaround will go away though, when 2:4.17 migrates to testing as well. > >-- >To unsubscribe, send mail to 1023204-unsubscr...@bugs.debian.org.
Bug#1023204: (no subject)
I am also affected by this. I worked around this by installing the samba-libs package from testing and pinning the version to 2:4.16* This workaround will go away though, when 2:4.17 migrates to testing as well.
Bug#998877: can-utils asc2log timestamp generation error
On 10.11.21 12:14, Alexander Gerasiov wrote: On Tue, 09 Nov 2021 10:16:01 +0100 Andre Naujoks wrote: Package: can-utils Version: 2020.11.0-1 Severity: normal Tags: upstream Dear Maintainer, the asc2log log file converter tool generates wrongly formatted timestamps in some rare cases. I.e. it writes e.g. 1.100 instead of 2.00 into the resulting log file. This bugs is fixed upstream in commit 9c2de072a076236410f6c5a112bd7b9075a9e77d. Would it be possible to update the package to a version, which contains this fix? I've prepared new package will check and upload it to archive this weekend. Thanks for your work. Highly appreciated. Andre
Bug#998877: can-utils asc2log timestamp generation error
Package: can-utils Version: 2020.11.0-1 Severity: normal Tags: upstream Dear Maintainer, the asc2log log file converter tool generates wrongly formatted timestamps in some rare cases. I.e. it writes e.g. 1.100 instead of 2.00 into the resulting log file. This bugs is fixed upstream in commit 9c2de072a076236410f6c5a112bd7b9075a9e77d. Would it be possible to update the package to a version, which contains this fix? Best Regards Andre -- System Information: Debian Release: bookworm/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386, arm64, armhf Kernel: Linux 5.14.0-4-amd64 (SMP w/12 CPU threads) Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages can-utils depends on: ii libc6 2.32-4 can-utils recommends no packages. can-utils suggests no packages. -- no debconf information
Bug#981372: keepassxc: new upstream version 2.6.6
Am 14.07.21 um 18:02 schrieb Julian Andres Klode: On Wed, Jul 14, 2021 at 04:46:30PM +0200, Andre Naujoks wrote: Hi. While ignoring the last rather rude comment, I'd like to ask, if there is anything that needs to be done to update this to the current version. I just tried to build the Debian package by just importing the new 2.6.6 version into the git repository and bumping the version accordingly on my machine and it "just works". Is there anything else in the way of getting a current version into unstable? An update would "fix" #894964 as well. We are still frozen. Hi. Well .. next time, I'll read up on that before. I wasn't aware of the effect of the freeze on unstable. Sorry for the noise then :-) Regards Andre
Bug#981372: keepassxc: new upstream version 2.6.6
Hi. While ignoring the last rather rude comment, I'd like to ask, if there is anything that needs to be done to update this to the current version. I just tried to build the Debian package by just importing the new 2.6.6 version into the git repository and bumping the version accordingly on my machine and it "just works". Is there anything else in the way of getting a current version into unstable? An update would "fix" #894964 as well. Regards and thanks for taking the time maintaining this! Andre
Bug#907541: [openjdk-8] Bind to a multicast address fails
Am 15.06.21 um 18:39 schrieb Thorsten Glaser: Hi Andre, This was supposed to be fixed upstream in Java 12: https://bugs.openjdk.java.net/browse/JDK-8210493 However it was taken back again (see last comment in that issue) and is now supposedly fixed in java 13: https://bugs.openjdk.java.net/browse/JDK-8215294 https://bugs.openjdk.java.net/browse/JDK-8216417 thanks for this information bundle, it helps tremendously. As far as I am aware, it works with current Java versions in Debian (>= 13). I am not sure if Debian actually wants to carry this for the versions <13, as the patch somehow introduced other issues (see the upstream bug-reports). As far as I understand, the original patch indeed introduced issues, so it’s probably not something we want to have in 8 and 11. The fix in 13+ is not backportable because they basically rewrote the entire socket classes’ implementations. I guess this won’t be fixed in 8 and, more importantly, 11 currently. Sad but understandable. I guess this can be closed again then. Thanks for taking a look at this, though. Regards Andre bye, //mirabilos
Bug#907541: [openjdk-8] Bind to a multicast address fails
Am 15.06.21 um 00:54 schrieb Thorsten Glaser: tags 907541 + confirmed upstream found 907541 openjdk-8/8u292-b10-1 found 907541 openjdk-11/11.0.12+4-1 thanks On Wed, 29 Aug 2018, Andre Naujoks wrote: This bugs affects all currently available Java versions in Debian (7, 8, 10 and 11). I don't know how to mark this here. Normally, cloning the bug against all affected packages, but I’m Cc’ing Doko on this hoping he’ll DTRT ☺ The contents of the patch should be usable for all versions with very little change. […] The attached patch fixes/adds this in the jvm. This is another of these things where it’d be preferable to fix this upstream first then apply the patch in Debian packages. However it’s small and easily applied ahead of time. It’d be no good if I’d fix this in openjdk-8 but 11 (and 17, possibly) are unfixed; Doko? Andre, can you report this upstream? Hi Thorsten. This was supposed to be fixed upstream in Java 12: https://bugs.openjdk.java.net/browse/JDK-8210493 However it was taken back again (see last comment in that issue) and is now supposedly fixed in java 13: https://bugs.openjdk.java.net/browse/JDK-8215294 https://bugs.openjdk.java.net/browse/JDK-8216417 As far as I am aware, it works with current Java versions in Debian (>= 13). I am not sure if Debian actually wants to carry this for the versions <13, as the patch somehow introduced other issues (see the upstream bug-reports). It would be nice to have, but I'd understand if you'd decided against taking the patch after the back and forth that happened upstream. Regards Andre Thanks, //mirabilos
Bug#962266: btrfs-progs: btrfs subvolume list changes path format with and without -o
Package: btrfs-progs Version: 5.6-1 Severity: normal Dear Maintainer, If the output of 'btrfs subvolume list ..' is not supposed to be stable (.. or consistent?) then this bug-report would belong in the wish-list category. Since the last package update I see that the output format of 'btrfs subvolume list -o ' has changed. It now prepends the path of the parent volume to the path of the subvolume, which it did not do before. The parents path does not refer to a mount point or anything else, it is the actual name of the parent subvolume. E.g.: # btrfs subvolume list -o / ID 15016 gen 1116509 top level 257 path root/.snapshots/monthly/2020-04-01T065201 ID 15771 gen 1168742 top level 257 path root/.snapshots/monthly/2020-05-01T065202 as opposed to: # btrfs subvolume list / ID 257 gen 1238711 top level 5 path root ID 15016 gen 1116509 top level 257 path .snapshots/monthly/2020-04-01T065201 ID 15771 gen 1168742 top level 257 path .snapshots/monthly/2020-05-01T065202 the "root/" part is not a mounted directory. The only reference to that name is this: # mount | grep root /dev/vda4 on / type btrfs (rw,relatime,space_cache,subvolid=257,subvol=/root) I am not sure how to handle this correctly without considerable work on my side. I would expect the path to the subvolume to be displayed the same way, no matter if I add -o to the command line to limit the output to sub-subvolumes. Best Regards nautsch -- System Information: Debian Release: bullseye/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.6.0-2-amd64 (SMP w/12 CPU cores) Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages btrfs-progs depends on: ii libblkid12.35.2-2 ii libc62.30-8 ii libcom-err2 1.45.6-1 ii libext2fs2 1.45.6-1 ii liblzo2-22.10-2 ii libuuid1 2.35.2-2 ii libzstd1 1.4.4+dfsg-3 ii zlib1g 1:1.2.11.dfsg-2 btrfs-progs recommends no packages. Versions of packages btrfs-progs suggests: pn duperemove -- no debconf information
Bug#961707: impressive immediately crashes under python 3
Package: impressive
Version: 0.13.0~beta1a-1
Severity: grave
Justification: renders package unusable
Dear Maintainer,
impressive crashes with the following output for me, when used with any PDF:
###
Welcome to Impressive version 0.13.0-beta1a (SVN r285)
pygame 1.9.6
Hello from the pygame community. https://www.pygame.org/contribute.html
Detected screen size: 1920x1080 pixels
PDF renderer: Xpdf/Poppler
OpenGL renderer: Radeon RX 580 Series (POLARIS10, DRM 3.36.0, 5.6.0-2-amd64,
LLVM 10.0.0)
===
OOPS! Impressive crashed!
This shouldn't happen. Please report this incident to the author, including the
full output of the program, particularly the following lines. If possible,
please also send the input files you used.
Impressive version: 0.13.0-beta1a (SVN r285)
Python version: 3.8.3 (default, May 14 2020, 11:03:12)
[GCC 9.3.0]
PyGame version: 1.9.6
PIL version: Pillow 7.0.0
PDF renderer: Xpdf/Poppler
OpenGL vendor: X.Org
OpenGL renderer: Radeon RX 580 Series (POLARIS10, DRM 3.36.0, 5.6.0-2-amd64,
LLVM 10.0.0)
OpenGL version: 4.6 (Compatibility Profile) Mesa 20.0.7
Operating system: Linux 5.6.0-2-amd64 (x86_64)
Linux distribution: Debian GNU/Linux bullseye/sid
Command line: /usr/bin/impressive GiT.pdf
Traceback (most recent call last):
File "/usr/bin/impressive", line 6451, in run_main
main()
File "/usr/bin/impressive", line 6368, in main
RenderPage(Pcurrent, Tcurrent)
File "/usr/bin/impressive", line 3679, in RenderPage
gl.TexImage2D(gl.TEXTURE_2D, 0, gl.RGB, TexWidth, TexHeight, 0, gl.RGB,
gl.UNSIGNED_BYTE, PageImage(page))
File "/usr/bin/impressive", line 3599, in PageImage
img = RenderPDF(page, not(ZoomMode), ZoomMode)
File "/usr/bin/impressive", line 3399, in RenderPDF
img = PDFRenderer.render(SourceFile, RealPage, useres, use_aa)
File "/usr/bin/impressive", line 3282, in render
try_digits.sort(key=lambda n: abs(n - digits))
AttributeError: 'range' object has no attribute 'sort'
This is a general python3 incompatibility and is already fixed upstream in SVN,
though not released yet AFAICS
The following is the change, that fixes the issue:
--- /a/impressive 2020-05-28 10:01:59.841029102 +0200
+++ /b/impressive 2020-05-28 10:02:10.217064169 +0200
@@ -3278,7 +3278,7 @@
TempFileName
])
digits = GetFileProp(filename, 'digits', 6)
-try_digits = range(6, 0, -1)
+try_digits = list(range(6, 0, -1))
try_digits.sort(key=lambda n: abs(n - digits))
try_digits = [(n, TempFileName + ("-%%0%dd.ppm" % n) % page) for n in
try_digits]
for digits, imgfile in try_digits:
I don't know how this would be handled, since there is no new release yet, but
the bug is effectively fixed upstream.
Would the patch be carried by debian until a new release is done?
-- System Information:
Debian Release: bullseye/sid
APT prefers unstable-debug
APT policy: (500, 'unstable-debug'), (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 5.6.0-2-amd64 (SMP w/12 CPU cores)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages impressive depends on:
ii poppler-utils 0.71.0-6
ii python3 3.8.2-3
ii python3-pil 7.0.0-4+b1
ii python3-pygame 1.9.6+dfsg-2+b1
Versions of packages impressive recommends:
ii ffmpeg 7:4.2.2-1+b1
ii mplayer2:1.3.0-8+b6
ii perl 5.30.2-1
ii xdg-utils 1.1.3-2
Versions of packages impressive suggests:
ii ghostscript 9.52~dfsg-1
pn latex-beamer
ii pdftk 2.02-5+b1
ii pdftk-java [pdftk] 3.1.1-1
-- no debconf information
-- debsums errors found:
debsums: changed file /usr/share/impressive/impressive.py (from impressive
package)
Bug#960227: [firefox] Can't do videoconference
I am also affected by this with webex web conferences. I am not using video, so I cannot say if it works or not, but audio just does not work any more. Neither recording nor receiving audio. Screenshares are still visible on my end, however. Regards Andre
Bug#951135: zeromq3: zmq_addons.hpp missing from installed headers
Hi. I strongly second this. The zmq.hpp, which is currently installed by this package is fairly old and actually contains bugs, which are fixed upstream. The version in the upstream git I found, that matches the installed zmq.hpp is from 2016 (commit 68a7b09cfce01c4c279fba2cf91686fcfc566848), so I think this file definitely deserves an update. Regards Andre
Bug#920809: [src:linux] Please enable CONFIG_CAN_PEAK_PCIEFD as module
Hi again. I created a patch (attached) against the current master of https://salsa.debian.org/kernel-team/linux If you prefer git as a source then here's a pull-request for the same repository: The following changes since commit 03e2a159aaa286ed569e561f5e9a1804a0ccf03c: Update to 4.20.5 (2019-01-28 16:15:01 +0100) are available in the Git repository at: https://git.nautsch.de/git/nautsch/linux-debian.git master for you to fetch changes up to 33b8506cc7b3a616ad9d6f2b7f55ebdbc7193f88: enable CAN_PEAK_PCIEFD (2019-02-05 09:21:58 +0100) Andre Naujoks (1): enable CAN_PEAK_PCIEFD debian/config/config | 5 + 1 file changed, 5 insertions(+) Regards Andre From 33b8506cc7b3a616ad9d6f2b7f55ebdbc7193f88 Mon Sep 17 00:00:00 2001 From: Andre Naujoks Date: Tue, 5 Feb 2019 09:21:58 +0100 Subject: [PATCH] enable CAN_PEAK_PCIEFD --- debian/config/config | 5 + 1 file changed, 5 insertions(+) diff --git a/debian/config/config b/debian/config/config index a92295d9b44a..68f77c424d6d 100644 --- a/debian/config/config +++ b/debian/config/config @@ -2897,6 +2897,11 @@ CONFIG_CAN_CALC_BITTIMING=y ## # CONFIG_CAN_M_CAN is not set +## +## file: drivers/net/can/peak_canfd/Kconfig +## +CONFIG_CAN_PEAK_PCIEFD=m + ## ## file: drivers/net/can/sja1000/Kconfig ## -- 2.20.1
Bug#920809: [src:linux] Please enable CONFIG_CAN_PEAK_PCIEFD as module
Package: src:linux Version: 4.19.16-1 Severity: normal --- Please enter the report below this line. --- Hi. Would it be possible to enable CONFIG_CAN_PEAK_PCIEFD as a kernel module in upcoming kernels? It is a device driver for a PCI express CAN Bus adapter. Thanks in advance Regards Andre --- System information. --- Architecture: Kernel: Linux 4.19.0-2-amd64 Debian Release: buster/sid 500 unstable-debug debug.mirrors.debian.org 500 unstable deb.debian.org 1 experimental-debug deb.debian.org 1 experimentaldeb.debian.org --- Package information. --- Package's Depends field is empty. Package's Recommends field is empty. Package's Suggests field is empty.
Bug#918672: [vim] XML auto indentation misbehaves (adds/removes additonal/wrong indentation)
Package: vim Severity: normal --- Please enter the report below this line. --- Hello. Since the last update to vim, the XML auto indentation seems to be broken and is misbehaving. This bug needs vim-nox, vim-athena or similar to appear. I.e. something where automatic XML-indentation works out of the box. Every time a tag is closed or return is pressed after a closing '>', vim indents the line one more step without taking the actual indentation into account. This only affects non-root nodes. (so all nodes except the very outer node) For example: - create a file with an .xml extension (e.g. 'vi /tmp/tmp.xml'), so the XML indentation is used. - create a root node - add another node - while entering the closing '>', the node is indented one additional step. - when pressing return after the closing '>' the node is indented another additional step. - insert the closing tag in the new line. '' - after entering the closing tags '>' the tag is indented one step back. (- pressing return/adding another line break after the closing tag again removes another level of indentation) The resulting buffer looks something like this: I would expect: Regards Andre --- System information. --- Architecture: Kernel: Linux 4.19.0-1-amd64 Debian Release: buster/sid 500 unstable-debug debug.mirrors.debian.org 500 unstable deb.debian.org 1 experimental-debug deb.debian.org 1 experimentaldeb.debian.org --- Package information. --- Package's Depends field is empty. Package's Recommends field is empty. Package's Suggests field is empty.
Bug#907541: [openjdk-8] Bind to a multicast address fails
Package: openjdk-8
Version: 8u181-b13-1
Severity: normal
Tags: patch
--- Please enter the report below this line. ---
This bugs affects all currently available Java versions in Debian (7, 8, 10 and
11).
I don't know how to mark this here. The contents of the patch should
be usable for all versions with very little change.
If a java program tries to bind a datagram/UDP socket to a link- or node-local
multicast
address and also sets the needed interface index, the bind operation on the
socket
fails with "java.net.SocketException: Invalid argument".
This is because the JVM only transfers the interface index to the scope_id
field in the struct sockaddr_in6,
if the address to bind to is a link local address (IN6_IS_ADDR_LINKLOCAL()).
A bind to a multicast address of link- or node-local scope needs the scope_id
field as well.
(There might be an additional problem here, when binding to a higher scoped
multicast address and trying to use
the non-default-route interface)
The attached patch fixes/adds this in the jvm.
I applied the patch by copying it to an "apt-get source"d openjdk-8 packages
debian/patches dir and including it
in the debian/rules file in the COMMON_PATCHES variable. The resulting debian
packages work as expected.
Additionally attached is a very small test program that wrongly throws the
mentioned exception.
When run with the patched VM it works.
You might have to edit the interface name in line 33 when trying this out.
Regards
Andre
--- System information. ---
Architecture:
Kernel: Linux 4.17.0-3-amd64
Debian Release: buster/sid
500 unstable-debug debug.mirrors.debian.org
500 unstabledeb.debian.org
--- Package information. ---
Package's Depends field is empty.
Package's Recommends field is empty.
Package's Suggests field is empty.
diff -Naur jdk/src/solaris/native/java/net/net_util_md.c jdk.new/src/solaris/native/java/net/net_util_md.c
--- a/jdk/src/solaris/native/java/net/net_util_md.c 2018-05-17 22:24:20.0 +0200
+++ b/jdk/src/solaris/native/java/net/net_util_md.c 2018-08-28 10:54:00.022607297 +0200
@@ -838,7 +838,9 @@
* cases the used value is cached for further use.
*/
#ifdef __linux__
-if (IN6_IS_ADDR_LINKLOCAL(&(him6->sin6_addr))) {
+if (IN6_IS_ADDR_LINKLOCAL(&(him6->sin6_addr))
+|| IN6_IS_ADDR_MC_NODELOCAL(&(him6->sin6_addr))
+|| IN6_IS_ADDR_MC_LINKLOCAL(&(him6->sin6_addr))) {
int cached_scope_id = 0, scope_id = 0;
if (ia6_cachedscopeidID) {
import java.net.DatagramSocket;
import java.net.InetAddress;
import java.net.InetSocketAddress;
import java.net.Inet6Address;
import java.net.NetworkInterface;
import java.lang.Error;
class mcast_test {
private static final byte[] ADDR = new byte[]{
(byte) 0xff,
(byte) 0x12,
(byte) 0x00,
(byte) 0x00,
(byte) 0x00,
(byte) 0x00,
(byte) 0x00,
(byte) 0x00,
(byte) 0x00,
(byte) 0x00,
(byte) 0x00,
(byte) 0x00,
(byte) 0x47,
(byte) 0x49,
(byte) 0x47,
(byte) 0x50
};
public static void main(String[] args) throws Exception
{
Inet6Address addr = Inet6Address.getByAddress(
"", ADDR, NetworkInterface.getByName("enp6s0")
);
System.out.println(addr);
DatagramSocket s = new DatagramSocket(
new InetSocketAddress(
addr,
29550
)
);
}
};
Bug#903581: valgrind: can't understand libc6 symbols: ELF section outside all mapped regions
Hi. this is the same as bug #903389. Regards Andre
Bug#903389: glibc/2.27-4 appears to break unrar-free/1:0.0.1+cvs20140707-4 autopktest: different Valgrind status codes
Hi. Just my two cents. I think this might be the same as this: https://bugs.kde.org/show_bug.cgi?id=395682 and respectively https://sourceware.org/bugzilla/show_bug.cgi?id=23357 It seems a default option for ld (-z separate-code) was changed, which makes valgrind unable to read the binaries info. This in turn (and here is where the guessing starts) may lead to valgrind not being able to apply its default suppressions!? Regards Andre On 10.07.2018 11:43, Aurelien Jarno wrote: > On 2018-07-09 13:00, Paul Gevers wrote: >> Source: glibc, unrar-free >> Version: glibc/2.27-4 >> Version: unrar-free/1:0.0.1+cvs20140707-4 >> User: debian...@lists.debian.org >> Usertags: breaks needs-update >> >> Dear maintainers, >> >> With a recent upload of glibc the autopkgtest of unrar-free started to >> fail in unstable and testing. I have copied the error below. >> >> Currently this regression is delaying the migration of glibc to >> testing by 13 days. Could you please investigate the situation and >> determine which package needs to fix something, and assign appropriately? > > From what I have investigated so far, valgrind returns many "Conditional > jump or move depends on uninitialised value" issues when libc6 is built > using binutils 2.30.90.20180705-1. When rebuilding libc6 2.27-4 with > binutils 2.30-22, the issue disappears. > > I don't know yet, if it's an issue in glibc, binutils or valgrind, > however I doubt it's an issue in unrar-free. > > Aurelien > signature.asc Description: OpenPGP digital signature
Bug#881146: [multistrap] apt 1.5~alpha1 breaks initial multstrap repository updates
Package: multistrap
Version: 2.2.9
Severity: important
--- Please enter the report below this line. ---
Hi.
Since (I assume) apt 1.5~alpha1 the following change is in apt (from
apts changelog):
* fail instead of warn on insecure repositories in apt-get
This makes multistraps initial package download/repository update fail.
I could work around this by applying the attached patch to the
multistrap script in /usr/sbin/multistrap
It adds another option to the apt-get call unconditionally: "-o
Acquire::AllowInsecureRepositories=true"
I am not sure about the implications of this, since I am not familiar
with multistraps code base. Maybe it needs the same guard as the -o
Apt::Get::AllowUnauthenticated=true option?
Marked as important, because the package is unusable like this.
Regards
Andre
--- System information. ---
Architecture: Kernel: Linux 4.13.0-1-amd64
Debian Release: buster/sid
500 unstable-debug debug.mirrors.debian.org 500 unstable
jenkins.piavpn.nordsys.de 500 unstableftp.de.debian.org 500
testing-debug debug.mirrors.debian.org 500 testing
ftp.de.debian.org
--- Package information. ---
Depends(Version) | Installed
-+-===
perl:any | apt
| 1.6~alpha3
libconfig-auto-perl | 0.44-1
liblocale-gettext-perl | 1.07-3+b3
libparse-debian-packages-perl| 0.03-2
Package's Recommends field is empty.
Suggests (Version) | Installed
===-+-===
fakeroot| 1.22-1
--- multistrap.orig 2017-11-08 08:55:15.066979371 +0100
+++ multistrap 2017-11-08 08:55:00.847310585 +0100
@@ -317,6 +317,7 @@
$config_str .= " -o Apt::Architecture=" . shellescape($arch);
$config_str .= " -o Dir::Etc::TrustedParts=" . shellescape("${dir}${etcdir}trusted.gpg.d");
$config_str .= " -o Dir::Etc::Trusted=" . shellescape("${dir}${etcdir}trusted.gpg");
+$config_str .= " -o Acquire::AllowInsecureRepositories=true";
$config_str .= " -o Apt::Get::AllowUnauthenticated=true"
if (defined $noauth);
$config_str .= " -o Apt::Get::Download-Only=true";
Bug#872302: vim sends cursor-blink sequence to terminal
This has the "slight" drawback of printing some garbage onto the current screen from time to time. The current buffer is unaffected. It just shows the inappropriateness of this workaround. I would be thankful for any tips on this. On 17.08.2017 11:05, Andre Naujoks wrote: > To answer my own question: > > Putting the following line into .vimrc does it for me: > > :au VimEnter * silent exec "!printf '\033[?12l'" > > I don't think this is supposed to be this hard. > > Regards > Andre > >
Bug#872302: vim sends cursor-blink sequence to terminal
To answer my own question: Putting the following line into .vimrc does it for me: :au VimEnter * silent exec "!printf '\033[?12l'" I don't think this is supposed to be this hard. Regards Andre On 17.08.2017 10:43, Andre Naujoks wrote: > Just to add my "me too!" here. Took me a while to pinpoint this to vim > and it's really annoying. > > Is there a workaround to disable the blinking? Setting guicursor/gcr > does nothing in a terminal. > > Regards > Andre >
Bug#872302: vim sends cursor-blink sequence to terminal
Just to add my "me too!" here. Took me a while to pinpoint this to vim and it's really annoying. Is there a workaround to disable the blinking? Setting guicursor/gcr does nothing in a terminal. Regards Andre
Bug#870357: [gf-complete-tools] Package in wrong Section "libs"
Package: gf-complete-tools Version: 1.0.2-2+b1 Severity: minor --- Please enter the report below this line. --- The package gf-complete-tools is packaged in the Debian-Section "libs", which leads to false positives from e.g. deborphan. (running deborphan on a system with the package installed outputs the package as removable) The package only consists of binaries and does not even contain a library. I would see the package in "math" (or "science"). Regards Andre --- System information. --- Architecture: Kernel: Linux 4.11.0-2-amd64 Debian Release: buster/sid 500 unstable-debug debug.mirrors.debian.org 500 unstable ftp.de.debian.org --- Package information. --- Depends (Version) | Installed ==-+-=== libgf-complete1 (= 1.0.2-2+b1) | 1.0.2-2+b1 libc6(>= 2.14) | 2.24-13 Package's Recommends field is empty. Package's Suggests field is empty.
Bug#869632: [libgf-complete1] Please remove C++ keywords (xor) from function declarations in header
Package: libgf-complete1
Version: 1.0.2-2+b1
Severity: wishlist
--- Please enter the report below this line. ---
Hi.
I am using the gf-complete library from C++ code and I wrapped the
header include in an extern "C" {...}.
However, I get an error, when trying to compile:
/usr/include/gf_general.h:51:51: error: expected ‘,’ or ‘...’ before
‘xor’ token
int bytes, int xor);
^~~
The reason is the "xor" parameter name, which is a keyword in C++.
I know I can work around this by giving g++ the -fno-operator-names
switch, but it would be nice, if the file was usable without that.
I would suggest to rename the parameter in the header or remove the name
completely.
Since the change would be minuscule and would not break compatibility
and this is not really a bug for a C-library, I am filing this as a
wishlist item and hope for someone to have mercy with C++ users out there.
Regards
Andre
--- System information. ---
Architecture: Kernel: Linux 4.11.0-2-amd64
Debian Release: buster/sid
500 unstable-debug debug.mirrors.debian.org 500 unstable
ftp.de.debian.org
--- Package information. ---
Depends (Version) | Installed
==-+-===
libc6(>= 2.14) | 2.24-12
Package's Recommends field is empty.
Package's Suggests field is empty.
Bug#862322: [xml/sgml-pkgs] Bug#862322: [libxml2] Wrong warning/error about "colons are forbidden from PI names"
On 05/12/17 09:19, Mattia Rizzolo wrote: > Control: forwarded -1 https://bugzilla.gnome.org/show_bug.cgi?id=782520 > > On Thu, May 11, 2017 at 03:55:33PM +0200, Andre Naujoks wrote: >> Done: https://bugzilla.gnome.org/show_bug.cgi?id=782520 > > Great, thank you! > >> Is it possible to link this bug to the upstream bug? I mean in a more >> direct way than the textual link above. > > Yap, does the above fit what you had in mind? (now at the top of the > bug page there will be a "Forwarded" line) > Yes that is exactly what I had in mind. Thank you!
Bug#862322: [xml/sgml-pkgs] Bug#862322: [libxml2] Wrong warning/error about "colons are forbidden from PI names"
On 05/11/17 11:40, Mattia Rizzolo wrote:
> Control: tag -1 upstream
>
> On Thu, May 11, 2017 at 10:44:54AM +0200, Andre Naujoks wrote:
>> When parsing an XML Document, libxml2 wrongly reports an error
>> (seemingly without further consequences) about colons not being allowed
>> in Processing-Instruction names.
>>
>> This is not true. The XML Specification
>> (https://www.w3.org/TR/REC-xml/#sec-pi and
>> https://www.w3.org/TR/REC-xml/#NT-Name) explicitly allows a colon (':')
>> as part of a PITarget, which is a Name in the XML specifications terms.
>> The last Version of the XML Specification, where a colon was not allowed
>> in a processing instruction name is over 20 years old and I think can be
>> safely ignored by now: https://www.w3.org/TR/WD-xml-lang-970331#NT-Name
>>
>> Attached is a test document (test.xml), which triggers the warning, when
>> used for example with xmlstarlet like this:
>>
>> Also attached is a patch (libxml2_patch_colons_in_pinames.patch), that
>> removes the bit of code from libxml2, that triggers the message.
>>
>> I am not sure about the side effects of the removed function-call, but
>> from the comments in the code it seems it should have aborted
>> processing. It specifically states for xmlNsErr: "Handle a fatal parser
>> error, i.e. violating Well-Formedness constraints". However it does not
>> really abort, which might warrant another bug report.
>
> Please, could you file this bug upstream?
> We don't want to include patches that are not upstream, exactly because
> there might very well be side effects otherwise not clear.
> Here is where:
> https://bugzilla.gnome.org/buglist.cgi?product=libxml2
> https://bugzilla.gnome.org/enter_bug.cgi?product=libxml2
>
Done: https://bugzilla.gnome.org/show_bug.cgi?id=782520
Is it possible to link this bug to the upstream bug? I mean in a more
direct way than the textual link above.
Regards
Andre
signature.asc
Description: OpenPGP digital signature
Bug#862322: [libxml2] Wrong warning/error about "colons are forbidden from PI names"
Package: libxml2
Version: 2.9.4+dfsg1-2.2
Severity: normal
Tags: patch
--- Please enter the report below this line. ---
Hi.
When parsing an XML Document, libxml2 wrongly reports an error
(seemingly without further consequences) about colons not being allowed
in Processing-Instruction names.
This is not true. The XML Specification
(https://www.w3.org/TR/REC-xml/#sec-pi and
https://www.w3.org/TR/REC-xml/#NT-Name) explicitly allows a colon (':')
as part of a PITarget, which is a Name in the XML specifications terms.
The last Version of the XML Specification, where a colon was not allowed
in a processing instruction name is over 20 years old and I think can be
safely ignored by now: https://www.w3.org/TR/WD-xml-lang-970331#NT-Name
Attached is a test document (test.xml), which triggers the warning, when
used for example with xmlstarlet like this:
$ xmlstarlet fo test.xml
test.xml:2.8: colons are forbidden from PI names 'pi:pi'
^
Also attached is a patch (libxml2_patch_colons_in_pinames.patch), that
removes the bit of code from libxml2, that triggers the message.
I am not sure about the side effects of the removed function-call, but
from the comments in the code it seems it should have aborted
processing. It specifically states for xmlNsErr: "Handle a fatal parser
error, i.e. violating Well-Formedness constraints". However it does not
really abort, which might warrant another bug report.
Regards
Andre
--- System information. ---
Architecture: Kernel: Linux 4.9.0-3-amd64
Debian Release: 9.0
500 unstable-debug debug.mirrors.debian.org 500 unstable
ftp2.de.debian.org 500 testing-debug debug.mirrors.debian.org 500
testing ftp2.de.debian.org 1 experimental-debug
ftp.de.debian.org 1 experimentalftp.de.debian.org
--- Package information. ---
Package's Depends field is empty.
Package's Recommends field is empty.
Package's Suggests field is empty.
--- parser.c 2017-05-11 09:46:59.227102287 +0200
+++ parser.c 2017-05-11 09:47:07.854898587 +0200
@@ -5180,10 +5180,6 @@
"xmlParsePITarget: invalid name prefix 'xml'\n",
NULL, NULL);
}
-if ((name != NULL) && (xmlStrchr(name, ':') != NULL)) {
- xmlNsErr(ctxt, XML_NS_ERR_COLON,
- "colons are forbidden from PI names '%s'\n", name, NULL, NULL);
-}
return(name);
}
Bug#367129: Namespace lost during schema validation
Hi. This bug still seems to be valid. (or is valid again?) The upstream bug is still in stage "NEW". Attached is a far simpler example, which triggers the bug. "bugged.xsd" is a schema, that should validate "test.xml", but does not. "workaround.xsd" is an equivalent schema, which does validate the "test.xml" file. It seems people either do not design their schemas the "bugged" way. If anyone is interested, the schema that triggered this bug for me in the first place is this one: http://www.omg.org/spec/XMI/20131001/XMI.xsd Regards Andre bugged.xsd Description: XML document http://www.example.com; > workaround.xsd Description: XML document
Bug#842792: [gpsd-dbg] gpsd-dbg does not contain debug symbols for gpsd
On 11/01/16 22:21, Bernd Zeimetz wrote: Hi Andre, If I am missing anything else, please tell me what it is. Which package do I have to install in order to get the debug symbols for gpsd? I really don't know where to look. actually I failed to realize that upstream changed the strip=no option, so gpsd needs to be built with nostrip=yes. So there were no debug symbols :( sorry for that! I'll upload a fixed version! I was beginning to really doubt myself. :-) Thanks again for the quick response and the help. Regards Andre best regards, bernd
Bug#842792: [gpsd-dbg] gpsd-dbg does not contain debug symbols for gpsd
On 11/01/16 15:57, Bernd Zeimetz wrote: I don't see the connection. Would this be fixed with the transition to the automatic -dbgsym package? Because currently the symbols are just missing. the transition is long done, just install the proper package. https://lists.debian.org/debian-devel/2015/12/msg00262.html explains it a bit better probably. I am sorry, if this is obvious, but I don't get it. (I am starting to feel stupid here. :-( ) I am on debian sid. I added the unstable-debug line "deb http://debug.mirrors.debian.org/debian-debug/ unstable-debug main contrib non-free" to my sources.list. There are now a bunch of -dbgsym packages available to me. There is no gpsd-dbgsym package. I manually looked for it here: http://debug.mirrors.debian.org/debian-debug/pool/main/g/, where I would expect the gpsd-dbgsym package. I could not find it. I built the .debs myself with sbuild (apt-get download ...). There were no dbgsym packages (other packages on my system generate them during build.). None of the resulting .deb files contain the debug info. If I am missing anything else, please tell me what it is. Which package do I have to install in order to get the debug symbols for gpsd? I really don't know where to look. Regards Andre
Bug#842792: [gpsd-dbg] gpsd-dbg does not contain debug symbols for gpsd
On 11/01/16 14:37, Bernd Zeimetz wrote: Hi, Somehow the debug symbols contained in the gpsd-dbg package only cover the binaries that are included in the gpsd-dbg package (the test_* stuff in /usr/lib/gpsd/debug/...) I would expect it to contain the debug symbols for all the binaries built from the gpsd source package, as it is stated in the packages description. First and foremost the gpsd binary itself. ... Or am I missing something? yes - https://wiki.debian.org/AutomaticDebugPackages Which is indeed a bit confusing now. I'll leave the bug open until I have an idea how to make this a bit more obvious. I don't see the connection. Would this be fixed with the transition to the automatic -dbgsym package? Because currently the symbols are just missing. Regards Andre Best regards, Bernd
Bug#842792: [gpsd-dbg] gpsd-dbg does not contain debug symbols for gpsd
Package: gpsd-dbg Version: 3.16-3 Severity: normal --- Please enter the report below this line. --- Hi. Somehow the debug symbols contained in the gpsd-dbg package only cover the binaries that are included in the gpsd-dbg package (the test_* stuff in /usr/lib/gpsd/debug/...) I would expect it to contain the debug symbols for all the binaries built from the gpsd source package, as it is stated in the packages description. First and foremost the gpsd binary itself. ... Or am I missing something? Regards Andre Naujoks --- System information. --- Architecture: amd64 Kernel: Linux 4.7.0-1-amd64 Debian Release: stretch/sid 500 unstablesnapshot.debian.org 500 unstable ftp.de.debian.org 500 testing ftp.de.debian.org --- Package information. --- Depends(Version) | Installed -+-== libbluetooth3 (>= 4.91) | 5.41-1 libc6 (>= 2.17) | libdbus-1-3 (>= 1.9.14) | libgcc1 (>= 1:3.0) | libstdc++6(>= 4.1.1) | libusb-1.0-0(>= 2:1.0.8) | python-dbg:any (>= 2.3~) | python:any (>= 2.7.5-5~) | libgps22 (= 3.16-3) | OR gpsd (= 3.16-3) | OR gpsd-clients (= 3.16-3) | OR python-gps(= 3.16-3) | Package's Recommends field is empty. Package's Suggests field is empty.
Bug#833698: icedove: SIGSEGV, Segmentation fault in js::jit::HandleExceptionIon
The culprit seems to be the google calendar provider (calendar-google-provider debian Package), when I disable that, icedove comes up again. Regards Andre
Bug#832602: [libxml2] Schema validation with attribute checks fails (upstream #766834)
Package: libxml2 Version: 2.9.4+dfsg1-1 Severity: important --- Please enter the report below this line. --- XML Schema validation fails, when attribute values are checked against a pattern or otherwise non-empty attributes would not validate. Attached are a very simple schema and an XML file, which validates with 2.9.3 but not with 2.9.4 The generated errors are: # xmlstarlet val -e -s test.xsd test.xml test.xml:1.18: Element 'Test', attribute 'test': [facet 'pattern'] The value '' is not accepted by the pattern '.+'. test.xml:1.18: Element 'Test', attribute 'test': '' is not a valid value of the atomic type 'mytype'. test.xml - invalid The bug is known upstream: https://bugzilla.gnome.org/show_bug.cgi?id=766834 A patch is available there, too. The patch solves the problem. I am not attaching the patch, because I did not write it. There is a mailing-list thread, which mentions the patch and why it is not yet applied, and it seems they are waiting for a review by the author of libxml2, which did not happen until now. https://mail.gnome.org/archives/xml/2016-June/msg3.html I'd like to ask, if Debian could carry the patch from the upstream bug-tracker until it lands upstream and a new version is released, because this bug breaks basically all schema validation, that is not trivial. Regards Andre --- System information. --- Architecture: amd64 Kernel: Linux 4.6.0-1-amd64 Debian Release: stretch/sid 500 unstableftp.de.debian.org 500 testing ftp.de.debian.org 1 experimentalftp.de.debian.org --- Package information. --- Depends (Version) | Installed =-+-= libc6 (>= 2.15) | libicu55 (>= 55.1-1~) | liblzma5 (>= 5.1.1alpha+20120614) | zlib1g (>= 1:1.2.3.3) | Recommends (Version) | Installed =-+-=== xml-core | 0.13+nmu2 Package's Suggests field is empty. test.xsd Description: XML document
Bug#826722: Wrong system information in initial bug report
The additional package versions and system information in the initial bug report are wrong. I used reportbug-ng on the host, that runs the vm, where the testing took place. Please ignore.
Bug#826722: [systemd] insserv-generator does not generate target file for additional system facilities
Package: systemd Version: 215-17+deb8u4 Severity: normal Tags: patch --- Please enter the report below this line. --- When creating a new system facility via /etc/insserv.conf.d/, the insserv generator generates drop-in files with ordering info for the sysv-generator-created service files (which correspond to the init-scripts with a "Required-Start: $" line in their LSB-headers). The problem is, that the ordering is in relation to a non-existent target and the ordering info is just ignored. The attached patch creates this target via the insserv-generator. The same bug is present in sids version, but the attached patch alone does not seem to solve the problem completely for sid. For jessie everything is well after this. I suspect some changes in the sysv-generator, which might cause this. One more thing. I don't know if this is actually the right approach to make this work i.e. creating an almost empty .target file. If there is a better/correct way of doing this, then I am very open to that. I created a test setup to demonstrate the issue in the attached tarball. It contains: # the definition of the system factility: $testsysfac etc/insserv.conf.d/testsysfac # the first member of the system facility (basically a "sleep 2") etc/init.d/testsysmem1 # the second member of the system facility (basically a "sleep 2") etc/init.d/testsysmem2 # a service depending on the system facility (also a "sleep 2") etc/init.d/testsysdep to enable all of this: update-rc.d testsysmem1 defaults; update-rc.d testsysmem2 defaults; update-rc.d testsysdep defaults; After this the links in /etc/rc*.d should have the right order i.e. testsysdep after the testsysmems, which are basically irrelevant for systemd. However, when I boot with systemd the following happens (journalctl -b, edited to only include relevant lines): > Jun 08 12:34:40 jessie-vm systemd[1]: Cannot add dependency job for unit > testsysfac.target, ignoring: Unit testsysfac.target failed to load: No such > file or directory. > Jun 08 12:34:40 jessie-vm systemd[1]: Cannot add dependency job for unit > testsysfac.target, ignoring: Unit testsysfac.target failed to load: No such > file or directory. > ... > Jun 08 12:34:42 jessie-vm systemd[1]: Starting LSB: test system fac mem 2... > Jun 08 12:34:42 jessie-vm systemd[1]: Starting LSB: test system fac mem 1... > ... > Jun 08 12:34:42 jessie-vm systemd[1]: Starting LSB: test system fac > dependency... > ... > Jun 08 12:34:44 jessie-vm systemd[1]: Started LSB: test system fac mem 1. > Jun 08 12:34:44 jessie-vm systemd[1]: Started LSB: test system fac mem 2. > Jun 08 12:34:44 jessie-vm systemd[1]: Started LSB: test system fac dependency. The plain ordering here is accidentally correct, but "test system fac dependency" should not even have been started without first reaching the testsysfac.target. Note that the 2 second pauses are also missing between the starting of the services. Depending on the load order of files, I have also seen a completely random order on another boot. After the patch is applied: > Jun 08 12:42:33 jessie-vm systemd[1]: Starting LSB: test system fac mem 2... > ... > Jun 08 12:42:33 jessie-vm systemd[1]: Starting LSB: test system fac mem 1... > ... > Jun 08 12:42:35 jessie-vm systemd[1]: Started LSB: test system fac mem 2. > Jun 08 12:42:35 jessie-vm systemd[1]: Started LSB: test system fac mem 1. > Jun 08 12:42:35 jessie-vm systemd[1]: Starting testsysfac.target. > Jun 08 12:42:35 jessie-vm systemd[1]: Reached target testsysfac.target. > Jun 08 12:42:35 jessie-vm systemd[1]: Starting LSB: test system fac > dependency... > Jun 08 12:42:37 jessie-vm systemd[1]: Started LSB: test system fac dependency. Which honours the order of the services and actually uses the target. The 2 second pauses are there and everything looks good. Regards Andre --- System information. --- Architecture: amd64 Kernel: Linux 4.6.0-trunk-amd64 Debian Release: stretch/sid 500 unstableftp.de.debian.org 1 experimental ftp.de.debian.org --- Package information. --- Depends(Version) | Installed -+-== libacl1(>= 2.2.51-8) | 2.2.52-3 libapparmor1 (>= 2.9.0-3+exp2) | 2.10-4 libaudit1 (>= 1:2.2.1) | 1:2.5.2-1 libblkid1(>= 2.19.1) | 2.28-5 libcap2 (>= 1:2.10) | 1:2.25-1 libcryptsetup4 (>= 2:1.4.3) | 2:1.7.0-2 libgpg-error0 (>= 1.14) | 1.22-2 libkmod2 (>= 5~) | 22-1.1 libmount1(>= 2.26.2) | 2.28-5 libpam0g (>= 0.99.7.1) | 1.1.8-3.3 libseccomp2 (>= 2.1.0) | 2.3.1-2 libselinux1 (>= 2.1.9) | 2.5-3 libsystemd0(= 230-2) | 230-2 util-linux (>= 2.27.1) | 2.28-5 mount (>= 2.26) | 2.28-5 adduser | 3.114 libcap2-bin | 1:2.25-1 Package Status (Version) |
Bug#825990: [partclone] partclone exits as non-root user
Package: partclone
Version: 0.2.88-1
Severity: normal
Tags: patch
--- Please enter the report below this line. ---
If partclone(.ext4 in my case) is run as a non-root user (i.e. to write
an image to a file from a backup), it emits a warning:
> You are not logged as root. You may have "access denied" errors when >
working.
. but then just exits.
Attached is a patch, that disables the automatic exit, as the warning
already suggests that it would not just exit.
The call that triggerd this for me was:
cat sdc1.ext4-ptcl-img.gz.a* | gzip -d -c | /usr/sbin/partclone.ext4 -r
--restore_raw_file -s - -O sdc1.img -L mylog.log
Regards
nautsch
--- System information. ---
Architecture: amd64
Kernel: Linux 4.5.0-2-amd64
Debian Release: stretch/sid
500 unstableftp.de.debian.org 1 experimental
ftp.de.debian.org
--- Package information. ---
Depends (Version) | Installed
=-+-
e2fslibs(>= 1.42) | 1.43-3
libblkid1 (>= 2.17.2) | 2.28-5
libc6 (>= 2.14) | libcomerr2 (>= 1.01) |
libncursesw5 (>= 6) | libntfs-3g871 |
libtinfo5 (>= 6) | libuuid1(>= 2.16) |
nilfs-tools |
Package's Recommends field is empty.
Package's Suggests field is empty.
Index: partclone-0.2.88/src/main.c
===
--- partclone-0.2.88.orig/src/main.c
+++ partclone-0.2.88/src/main.c
@@ -201,7 +201,7 @@ int main(int argc, char **argv) {
#ifndef CHKIMG
if (geteuid() != 0)
- log_mesg(0, 1, 1, debug, "You are not logged as root. You may have \"access denied\" errors when working.\n");
+ log_mesg(0, 0, 1, debug, "You are not logged as root. You may have \"access denied\" errors when working.\n");
else
log_mesg(1, 0, 0, debug, "UID is root.\n");
#endif
Bug#798543: [valgrind] false positives on socket calls with not specially handled address families
Package: valgrind
Version: 1:3.10.1-4
Severity: normal
Tags: patch
--- Please enter the report below this line. ---
Hi.
Wenn using socket syscalls (bind in my case) with address families not
specially handled by valgrind (i.e. not AF_INET(6), AF_UNIX,
AF_BLUETOOTH, AF_NETLINK), I get false positives for unitialized memory.
The problem is, that for an unknown address-family the memory of the
sockaddr struct is checked from AFTER the sa_family field for salen bytes,
which then (correctly) finds uninitialized memory AFTER the actual struct.
Either the memory has to be checked for salen - sizeof(sa_family) or the
whole sockaddr struct has to be checked.
These are the two ways to fix this (also attached as patches). I'd prefer
way 1, since I see no reason not to check the sa_family field again, when
it makes the code more readable.
way 1:
--- valgrind-3.10.1.orig/coregrind/m_syswrap/syswrap-generic.c
+++ valgrind-3.10.1/coregrind/m_syswrap/syswrap-generic.c
@@ -1126,7 +1126,7 @@ void pre_mem_read_sockaddr ( ThreadId ti
Note that this can give false positive if this (unknown)
struct sockaddr_ has padding bytes between its elements. */
VG_(sprintf) ( outmsg, description, "sa_data" );
- PRE_MEM_READ( outmsg, (Addr)>sa_family + sizeof(sa->sa_family),
+ PRE_MEM_READ( outmsg, (Addr)>sa_family,
salen );
break;
}
way 2:
--- valgrind-3.10.1.orig/coregrind/m_syswrap/syswrap-generic.c
+++ valgrind-3.10.1/coregrind/m_syswrap/syswrap-generic.c
@@ -1127,7 +1127,7 @@ void pre_mem_read_sockaddr ( ThreadId ti
struct sockaddr_ has padding bytes between its elements. */
VG_(sprintf) ( outmsg, description, "sa_data" );
PRE_MEM_READ( outmsg, (Addr)>sa_family + sizeof(sa->sa_family),
- salen );
+ salen - sizeof(sa->sa_family) );
break;
}
Regards
Andre Naujoks
--- System information. ---
Architecture: amd64
Kernel: Linux 4.1.0-2-amd64
Debian Release: stretch/sid
500 unstableftp.de.debian.org
500 stable dl.google.com
--- Package information. ---
Depends(Version) | Installed
-+-===
libc6 (>= 2.16) |
libc6-dbg|
Recommends(Version) | Installed
===-+-===
valgrind-dbg| 1:3.10.1-4
gdb | 7.10-1
Suggests (Version) | Installed
===-+-===
valgrind-mpi|
kcachegrind |
alleyoop|
valkyrie (>> 1.3.0) |
Index: valgrind-3.10.1/coregrind/m_syswrap/syswrap-generic.c
===
--- valgrind-3.10.1.orig/coregrind/m_syswrap/syswrap-generic.c
+++ valgrind-3.10.1/coregrind/m_syswrap/syswrap-generic.c
@@ -1126,7 +1126,7 @@ void pre_mem_read_sockaddr ( ThreadId ti
Note that this can give false positive if this (unknown)
struct sockaddr_ has padding bytes between its elements. */
VG_(sprintf) ( outmsg, description, "sa_data" );
- PRE_MEM_READ( outmsg, (Addr)>sa_family + sizeof(sa->sa_family),
+ PRE_MEM_READ( outmsg, (Addr)>sa_family,
salen );
break;
}
Index: valgrind-3.10.1/coregrind/m_syswrap/syswrap-generic.c
===
--- valgrind-3.10.1.orig/coregrind/m_syswrap/syswrap-generic.c
+++ valgrind-3.10.1/coregrind/m_syswrap/syswrap-generic.c
@@ -1127,7 +1127,7 @@ void pre_mem_read_sockaddr ( ThreadId ti
struct sockaddr_ has padding bytes between its elements. */
VG_(sprintf) ( outmsg, description, "sa_data" );
PRE_MEM_READ( outmsg, (Addr)>sa_family + sizeof(sa->sa_family),
- salen );
+ salen - sizeof(sa->sa_family) );
break;
}
Bug#798543: [valgrind] false positives on socket calls with not specially handled address families
Hi. Sorry for the noise. I just noticed, that this fix is already in the upstream svn. Not yet released though. I don't know how something like this is handled, so .. - again - sorry for the noise. Regards Andre
Bug#770158: [vim-scripts] xmledit / xml-plugin is out of date
Package: vim-scripts Version: 20130814 Severity: normal --- Please enter the report below this line. --- Hi. the xmledit / xml-plugin ftplugin is now located in a git repository as the xml-plugin page at vim-org claims http://www.vim.org/scripts/script.php?script_id=1397 The git is located at https://github.com/othree/xml.vim and it holds an updated version with much more functionality. Would you consider to include the new version of the plugin? Regards Andre --- System information. --- Architecture: amd64 Kernel: Linux 3.17-1-amd64 Debian Release: jessie/sid 500 unstable ftp.de.debian.org 500 unstable debian.netcologne.de 1 experimental ftp.de.debian.org --- Package information. --- Package's Depends field is empty. Package's Recommends field is empty. Package's Suggests field is empty. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#759534: [libapr1] apr_mcast_interface does not work for IPv6
This also affects apr_mcast_join() with the iface argument set, which makes apr pretty much unusable for multicasting data over ipv6 on the non-default interface. Regards Andre -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#749892: make package_source with only symlinks in a subdirectory fails
On 06.08.2014 12:32, Andre Naujoks wrote:
Hi.
I reported this bug to the debian bug-tracker some time ago, but there
seems to be no activity regarding this.
So I report this here as well and hope for someone to respond. I created
a patch (see below), which works for me,
but might change things in a completely wrong place.
I am on cmake version 2.8.12.1 (debian version 2.8.12.1-1.6)
This is the text of the debian bug report
(http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=749892):
If I try to create a source package with cmake via CPack and make
package_source and there is a directory in the sources, that only
contains symlinks (only one in my case), the generation of the
source package fails with:
CPack Error: Cannot create symlink: source -- destination
where source and destination are the file/symlink names of course.
It seems CPack tries to create the paths for the destination only if
it copies files and not when creating symlinks.
The following patch fixes this for me. I don't know, if this is
actually the right place to put this, but it should point to the
exact problem.
diff -Naur cmake-2.8.12.1_orig/Source/kwsys/SystemTools.cxx
cmake-2.8.12.1/Source/kwsys/SystemTools.cxx
--- cmake-2.8.12.1_orig/Source/kwsys/SystemTools.cxx 2013-11-05
20:07:23.0 +0100
+++ cmake-2.8.12.1/Source/kwsys/SystemTools.cxx 2014-05-30
14:25:23.912154919 +0200
@@ -2835,6 +2835,9 @@
#else
bool SystemTools::CreateSymlink(const char* origName, const char* newName)
{
+ kwsys_stl::string destination_dir = newName;
+ destination_dir = GetFilenamePath(destination_dir);
+ MakeDirectory(destination_dir.c_str());
return symlink(origName, newName) = 0;
}
#endif
Regards
Andre
Hi again.
Attached is a small example which reproduces the problem.
To reproduce:
- Unpack the attached tar.gz.
- create a build directory next to it
- from inside the build directory issue the command:
cmake ../cmake_make_package_source_error
- then issue:
make package_source
The following error occurs for me:
Run CPack packaging tool for source...
CPack: Create package using TGZ
CPack: Install projects
CPack: - Install directory:
/home/nautsch/test/cmake_make_package_source_error
CPack Error: Cannot create symlink: tstlnk/thisishello.c-- ../hello.c
CPack Error: Error when generating package: Project
Makefile:75: recipe for target 'package_source' failed
make: *** [package_source] Error 1
Regards
nautsch
cmake_make_package_source_error.tar.gz
Description: application/gzip
Bug#759534: [libapr1] apr_mcast_interface does not work for IPv6
Package: libapr1
Version: 1.5.1-2
Severity: normal
Tags: patch
--- Please enter the report below this line. ---
Hi.
When trying to set the mcast interface with apr_mcast_interface(), apr
goes through all interfaces and tries to match the given address to the
interfaces address. This does not work as it is currently implemented in
linux, since the match is tried by comparing (memcmp()) the sin6_addr
field of the given struct sockaddr_in6 and sa_data from a generic
struct sockaddr, which do not line up.
The attached patch fix_ipv6_find_if_index.patch fixes this for me.
Also attached is a test program, that does not work correctly without
the patch applied. The program goes through all interfaces of a host,
chooses the ipv6 ones, that are not the loopback device, and tries to
send a multicast packet on each address.
There has to be a second ipv6 interface, for this error to actually have
any effect.
Regards
nautsch
--- System information. ---
Architecture: amd64
Kernel: Linux 3.14-2-amd64
Debian Release: jessie/sid
500 unstableftp.de.debian.org 500 stable ftp.uni-kl.de
--- Package information. ---
Depends (Version) | Installed
===-+-===
libc6 (= 2.15) | libuuid1 (= 2.16) |
Package's Recommends field is empty.
Package's Suggests field is empty.
Index: apr-1.5.1/network_io/unix/multicast.c
===
--- apr-1.5.1.orig/network_io/unix/multicast.c
+++ apr-1.5.1/network_io/unix/multicast.c
@@ -62,7 +62,7 @@ static unsigned int find_if_index(const
for (ifp = ifs; ifp; ifp = ifp-ifa_next) {
if (ifp-ifa_addr != NULL ifp-ifa_addr-sa_family == AF_INET6) {
if (memcmp(iface-sa.sin6.sin6_addr,
- ifp-ifa_addr-sa_data[0],
+ ((struct sockaddr_in6*)ifp-ifa_addr)-sin6_addr,
sizeof(iface-sa.sin6.sin6_addr)) == 0) {
index = if_nametoindex(ifp-ifa_name);
break;
#include stdlib.h
#include stdio.h
#include unistd.h
#include netdb.h
#include sys/ioctl.h
#include net/if.h
#include ifaddrs.h
#include sys/socket.h
#include sys/types.h
#include arpa/inet.h
#include apr.h
#include apr_errno.h
#include apr_network_io.h
#define BCADDR_SITE ff15::1234
#define MC_PORT 3
int main(int argc, char **argv)
{
apr_socket_t *s;
apr_sockaddr_t *addr;
apr_pool_t *pool;
apr_status_t err;
char buffer[1024];
apr_initialize();
atexit(apr_terminate);
apr_pool_create(pool, NULL);
if ((err = apr_socket_create(s, APR_INET6, SOCK_DGRAM, 0, pool)) != APR_SUCCESS) {
fprintf(stderr, failed to create socket\n);
return 1;
}
if ((err = apr_sockaddr_info_get(addr, BCADDR_SITE, APR_INET6, MC_PORT, 0, pool)) != APR_SUCCESS) {
fprintf(stderr, could not create mcast addrinfo %s\n, apr_strerror(err, buffer, 1024));
return 1;
}
{
struct ifaddrs *ifaddrs;
struct ifaddrs *ia;
getifaddrs(ifaddrs);
for (ia = ifaddrs; ia; ia = ia-ifa_next) {
apr_sockaddr_t *src_addr;
char addr_str[INET6_ADDRSTRLEN + 1];
apr_size_t len = 6;
apr_status_t ret;
if (!ia-ifa_addr) {
continue;
}
switch (ia-ifa_addr-sa_family) {
case AF_INET6:
// we cannot send multicasts on the loopback interface
if (IN6_IS_ADDR_LOOPBACK(((struct sockaddr_in6*)ia-ifa_addr)-sin6_addr)) {
continue;
}
if (inet_ntop(AF_INET6, ((struct sockaddr_in6*)ia-ifa_addr)-sin6_addr, addr_str, INET6_ADDRSTRLEN) == NULL) {
fprintf(stderr, failed to create string v6 address: %s\n, strerror(errno));
return 1;
}
fprintf(stderr, v6 addr: %s belongs to device %d\n, addr_str, if_nametoindex(ia-ifa_name));
break;
default:
continue;
}
if ((ret = apr_sockaddr_info_get(src_addr, addr_str, APR_INET6, MC_PORT, 0, pool)) != APR_SUCCESS) {
fprintf(stderr, could no create sockaddr for mcast_interface %s\n, apr_strerror(ret, buffer, 1024));
return 1;
}
if (apr_mcast_interface(s, src_addr) != APR_SUCCESS) {
fprintf(stderr, could not set mcast interface);
return 1;
}
if ((err = apr_socket_sendto(s, addr, 0, hallo\n, len)) != APR_SUCCESS) {
fprintf(stderr, failed to send %s\n, apr_strerror(err, buffer, 1024));
return 1;
}
fprintf(stderr, sent\n);
}
freeifaddrs(ifaddrs);
}
return 0;
}
Bug#753674: [dash] dash aborts a script, when 'shift' tested by 'while' fails
Package: dash Version: 0.5.7-4 Severity: normal --- Please enter the report below this line. --- Hi. dash seems to abort the following script, when reaching the expected error when the shift command has nothing more to shift and fails. #!/bin/sh # just output all parameters echo $1 while shift; do echo $1 done echo done It never reaches the echo done part, which it should in my eyes. bash behaves differently (and IMHO correctly) in this case and reaches the end of the script. Additionally an error string is output from dash, which is probably not needed but documented that way in the manpage. This is a run with dash (echo done is not reached): $ ./shifttest.sh 1 2 3 4 1 2 3 4 ./shifttest.sh: 4: shift: can't shift that many $ This is a run with bash: $ ./shifttest.sh 1 2 3 4 1 2 3 4 done $ The problem seems only to happen when shift is tested. Other things, like checking for the existence of a file, do not trigger an immediate exit. Regards Andre --- System information. --- Architecture: amd64 Kernel: Linux 3.14-1-amd64 Debian Release: jessie/sid 500 unstableftp.de.debian.org 500 unstableftp-stud.hs-esslingen.de --- Package information. --- Depends (Version) | Installed ===-+- debianutils (= 2.15) | 4.4 dpkg(= 1.15.0) | 1.17.10 Package's Recommends field is empty. Package's Suggests field is empty. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#753674: [dash] dash aborts a script, when 'shift' tested by 'while' fails
I just noticed Bug #627856, which deals with a very similar issue. Is a shift without an argument also considered a syntax error if it is called too often? If yes, then this bug can be closed and I am sorry for the noise. IMHO this should not be considered a syntax error, because it is (again IMHO) a valid way of getting all arguments of a script or shell function. Regards Andre -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#749892: [cmake] CPack make package_source with only symlinks in a subdirectory fails
Package: cmake
Version: 2.8.12.1-1.3
Severity: normal
Tags: patch
--- Please enter the report below this line. ---
Hi.
If I try to create a source package with cmake via CPack and make
package_source and there is a directory in the sources, that only
contains symlinks (only one in my case), the generation of the
source package fails with:
CPack Error: Cannot create symlink: source -- destination
where source and destination are the file/symlink names of course.
It seems CPack tries to create the paths for the destination only if
it copies files and not when creating symlinks.
The following patch fixes this for me. I don't know, if this is
actually the right place to put this, but it should point to the
exact problem.
diff -Naur cmake-2.8.12.1_orig/Source/kwsys/SystemTools.cxx
cmake-2.8.12.1/Source/kwsys/SystemTools.cxx
--- cmake-2.8.12.1_orig/Source/kwsys/SystemTools.cxx2013-11-05
20:07:23.0 +0100
+++ cmake-2.8.12.1/Source/kwsys/SystemTools.cxx 2014-05-30 14:25:23.912154919
+0200
@@ -2835,6 +2835,9 @@
#else
bool SystemTools::CreateSymlink(const char* origName, const char* newName)
{
+ kwsys_stl::string destination_dir = newName;
+ destination_dir = GetFilenamePath(destination_dir);
+ MakeDirectory(destination_dir.c_str());
return symlink(origName, newName) = 0;
}
#endif
Regards
Andre
--- System information. ---
Architecture: amd64
Kernel: Linux 3.14-rc7-amd64
Debian Release: jessie/sid
500 unstableftp.de.debian.org
500 unstableftp-stud.hs-esslingen.de
--- Package information. ---
Depends (Version) | Installed
=-+-=
libarchive13 | 3.1.2-8
libc6 (= 2.15) |
libcurl3 (= 7.16.2) |
libexpat1 (= 2.0.1) |
libgcc1 (= 1:4.1.1) |
libstdc++6 (= 4.6) |
zlib1g (= 1:1.2.3.3) |
cmake-data (= 2.8.12.1-1.3) |
procps|
Recommends (Version) | Installed
=-+-===
make | 4.0-7
gcc | 4:4.8.2-4
Suggests(Version) | Installed
=-+-===
codeblocks|
eclipse | 3.8.1-5.1
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#718423: [kile] Files and Projects view broken, with nested \input
Package: kile
Version: 4:2.1.3-2
Severity: normal
--- Please enter the report below this line. ---
Hi.
In the Files and Projects view, the tree of files breaks, when more
than one level of nesting is done and the input'ed file is inside a
subdirectory.
To reproduce:
- Create a new project (I use the scrreprt template to get a compilable
file right away) with main.tex as main document.
- create two new files (l1.tex, l2.tex) in a subdirectory of the project
dir (I name the dir level1) and add them to the project
- input l1.tex in main.tex
- input l2.tex in l1.tex.
- save everything
Now the tree in the Files and Projects view should be:
main.tex
+-- l1.tex
+-- l2.tex
but kile seems to use the path from the input statement as a relative
path from the position of the file which uses the input statement, where
it should use a relative path from the position of the main document. So
the resulting tree looks like this:
l2.tex
main.tex
+-- l1.tex
because kile cannot find the reference to l2.tex in l1.tex
For clarification these would be the files:
main.tex:
---
\documentclass[a4paper,10pt]{scrreprt}
\usepackage[utf8]{inputenc}
% Title Page
\title{}
\author{}
\begin{document}
\maketitle
\begin{abstract}
\end{abstract}
\input{level1/l1}
\end{document}
---
l1.tex
---
\input{level1/l2}
---
l2.tex can be empty.
The directory structure is:
$ ls -R
.:
level1 test.kilepr main.tex
./level1:
l1.tex l2.tex
if the level1/ part of the path in l1.tex's input is removed, kile
recognizes the project structure, but obviously the document no longer
compiles.
I hope I explained the problem clearly. If there are any questions, I
will do my best to answer them.
Regards
Andre Naujoks
--- System information. ---
Architecture: amd64
Kernel: Linux 3.10.0+
Debian Release: jessie/sid
500 unstable ftp.de.debian.org
500 stable dl.google.com
--- Package information. ---
Depends (Version) | Installed
=-+-===
konsole | 4:4.8.4-3
texlive-latex-base | 2013.20130530-1
kde-runtime | 4:4.8.4-2+b1
libc6 (= 2.14) |
libgcc1 (= 1:4.1.1) |
libkdecore5 (= 4:4.4.95) |
libkdeui5 (= 4:4.5.2) |
libkfile4 (= 4:4.4.4) |
libkhtml5 (= 4:4.4.4) |
libkio5 (= 4:4.4.4) |
libkjsapi4 (= 4:4.4.4) |
libkparts4 (= 4:4.5.85) |
libkrosscore4 (= 4:4.4.4) |
libktexteditor4 (= 4:4.4.95) |
libnepomuk4 (= 4:4.4.4) |
libnepomukutils4 (= 4:4.5.85) |
libphonon4 (= 4:4.2.0) |
libqt4-dbus (= 4:4.5.3) |
libqt4-network (= 4:4.5.3) |
libqt4-script (= 4:4.5.3) |
libqt4-svg (= 4:4.5.3) |
libqt4-xml (= 4:4.5.3) |
libqtcore4 (= 4:4.7.0~beta1) |
libqtgui4 (= 4:4.8.0) |
libsoprano4 (= 2.1.1) |
libstdc++6 (= 4.1.1) |
Recommends (Version) | Installed
==-+-===
dvipng | 1.14-1+b2
ghostscript | 9.05~dfsg-8
imagemagick | 8:6.7.7.10-5
psutils | 1.17.dfsg-1
texlive | 2013.20130530-1
Suggests (Version) | Installed
===-+-===
aspell | 0.60.7~20110707-1
OR ispell |
OR hspell |
asymptote |
context |
dblatex | 0.3.4-3
kile-doc |
kile-l10n |
kbibtex |
latex2html | 2008-debian1-10
lilypond |
tex4ht |
texlive-doc-base | 2012.20120611-1
texlive-xetex | 2013.20130530-1
zip | 3.0-7
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#710971: [qemu-system-x86] segfaults with ubuntu 10.04.4 i368 and -vga vmware
Package: qemu-system-x86 Version: 1.5.0+dfsg-3 Severity: normal --- Please enter the report below this line. --- Hi. After updating my system to the latest qemu, a virtual machine of mine no longer boots. This is a ubuntu 10.04.4 installation but can be reproduced with the installer of ubuntu 10.04.4 desktop for i368. To reproduce: - Download the ubuntu installer for the desktop version for i368 (http://old-releases.ubuntu.com/releases/lucid/) - run: qemu-system-i386 -cdrom ubuntu-10.04.4-desktop-i386.iso -vga vmware After a minute or so, qemu segfaults. It looks like it happens right after the boot splash screen. (with -machine pc,accel=kvm it happens much faster) I can reproduce this on two of my machines. qemu version 1.1.2 from testing does work however. Best regards and thanks in advance for any help with this. nautsch --- System information. --- Architecture: amd64 Kernel: Linux 3.8-2-amd64 Debian Release: jessie/sid 500 unstable www.deb-multimedia.org 500 unstable ftp.de.debian.org 1 experimental ftp.de.debian.org --- Package information. --- Depends (Version) | Installed ==-+- libaio1 (= 0.3.93) | 0.3.109-4 libasound2 (= 1.0.16) | 1.0.27.1-1 libbluetooth3 (= 4.91) | 4.99-2 libbrlapi0.6 | 4.5-2 libc6 (= 2.14) | 2.17-4 libcairo2 (= 1.6.0) | 1.12.14-4 libcurl3-gnutls (= 7.16.2) | 7.30.0-2 libfdt1 | 1.3.0-4 libgdk-pixbuf2.0-0 (= 2.22.0) | 2.28.1-2 libglib2.0-0 (= 2.24.0) | 2.36.1-2build1 libgnutls26 (= 2.12.17-0) | 2.12.23-5 libgtk2.0-0 (= 2.20.0) | 2.24.18-1 libiscsi1 (= 1.4) | 1.4.0-3 libjpeg8 (= 8d) | 8d-1 libncurses5 (= 5.5-5~) | 5.9+20130504-1 libpixman-1-0 (= 0.15.16) | 0.26.0-4 libpng12-0 (= 1.2.13-4) | 1.2.49-4 libpulse0 (= 0.99.1) | 2.0-6.1 libsasl2-2 (= 2.1.24) | 2.1.25.dfsg1-6 libsdl1.2debian (= 1.2.11) | 1.2.15-5 libseccomp1 (= 0.0.0~20120605) | 1.0.1-2 libspice-server1 (= 0.12.3) | 0.12.3-0nocelt1 libssh2-1 (= 1.2.8) | 1.4.3-1 libtinfo5 | 5.9+20130504-1 libusb-1.0-0 (= 2:1.0.12) | 2:1.0.15-1 libusbredirparser1 (= 0.6) | 0.6-2 libuuid1 (= 2.16) | 2.20.1-5.4 libvdeplug2 | 2.3.2-4 libvte9 (= 1:0.28.0) | 1:0.28.2-5 libx11-6 | 2:1.5.0-1+deb7u1 libxen-4.2 (= 4.2.1) | 4.2.1-2 libxenstore3.0 (= 4.1.0~rc6) | 4.2.1-2 zlib1g (= 1:1.1.4) | 1:1.2.8.dfsg-1 qemu-system-common (= 1.5.0+dfsg-3) | 1.5.0+dfsg-3 qemu-keymaps (= 1.5.0+dfsg-3) | 1.5.0+dfsg-3 vgabios (= 0.6c-3~) | 0.7a-3 seabios (= 1.7.2-2~) | 1.7.2-3 ipxe-qemu | 1.0.0+git-20120202.f6840ba-3 Recommends (Version) | Installed =-+-=== qemu-utils | 1.5.0+dfsg-3 Suggests (Version) | Installed ===-+-=== samba | 2:3.6.15-1 vde2 | kmod | 9-3 sgabios | -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#710971: [qemu-system-x86] segfaults with ubuntu 10.04.4 i368 and -vga vmware
On 03.06.2013 22:28, Michael Tokarev wrote: Control: tag -1 + confirmed upstream Control: forwarded -1 https://bugs.launchpad.net/qemu/+bug/1187121 03.06.2013 23:45, Andre Naujoks wrote: Package: qemu-system-x86 Version: 1.5.0+dfsg-3 Severity: normal --- Please enter the report below this line. --- Hi. After updating my system to the latest qemu, a virtual machine of mine no longer boots. This is a ubuntu 10.04.4 installation but can be reproduced with the installer of ubuntu 10.04.4 desktop for i368. To reproduce: - Download the ubuntu installer for the desktop version for i368 (http://old-releases.ubuntu.com/releases/lucid/) - run: qemu-system-i386 -cdrom ubuntu-10.04.4-desktop-i386.iso -vga vmware After a minute or so, qemu segfaults. It looks like it happens right after the boot splash screen. (with -machine pc,accel=kvm it happens much faster) Thank you for the bugreport. You're welcome and thank you for the -display sdl workaround. I had no idea where to start looking for something like this. Best regards nautsch I can reproduce this on two of my machines. I confirmed this issue on my machine too. qemu version 1.1.2 from testing does work however. This is specific to vmware AND gtk. With traditional sdl display (-display sdl) it does not happen. 1.1.x had only sdl display. Thanks! /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#691391: libcurl3-gnutls: git push on libcurl3-gnutls_7.28-2 fails when changes, pushed
Hi. I 'think' this is the same thing as my problem. I have the same issue. To reproduce make sure that the push is bigger than 1 MiB (or whatever your http.postBuffer is configured to), so the data has to be sent chunked. To do that, I just created a 1.5 MB file added it to a commit and then pushed. # dd if=/dev/urandom of=file1 count=1 bs=150 # git add file1 # git commit # git push -v This (at least for me) provoked the error. I get however a slightly different result= in the error line: Pushing to https://scm.nordsys.de/git/sandbox/naujoks/testrepo.git Counting objects: 9, done. Delta compression using up to 6 threads. Compressing objects: 100% (8/8), done. POST git-receive-pack (chunked) Writing objects: 100% (9/9), 1.43 MiB | 607 KiB/s, done. Total 9 (delta 1), reused 0 (delta 0) Unable to rewind rpc post data - try increasing http.postBuffer error: RPC failed; result=65, HTTP code = 401 fatal: The remote end hung up unexpectedly fatal: The remote end hung up unexpectedly Everything up-to-date This is a gitolite server, but the error only appears on my machine after the last update. increasing http.postBuffer actually helps, but it cannot be a solution to just set this value to 100MB and try to live with that and hope every server accepts that. Regards Andre -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#689293: dia menu entry should use /usr/bin/dia not /usr/bin/dia-normal
On 03.10.2012 12:38, schrieb Roland Stigge: Hi! Thanks you for your report! On 01/10/12 10:30, Andre Naujoks wrote: The installation of dia should add a menu entry to start dia with the link in /usr/bin/dia, so the choice of the alternatives system is taken into account. Currently /usr/bin/dia-normal is used, which bypasses the alternatives system. Interesting question. Currently, dia just installs menu files for dia(-normal) and dia-gnome each, which will both appear in the menu, if available. Now I wonder if menu entries should follow alternative system choices or not. Is there a policy about that or some common practice in other packages? Now that you mention it, I think I don't know any other package that uses the alternatives system the way dia does. The choice is basically a command line parameter. But I think dia should start in the same configuration regardless of where it is started from, be it a menu or the command line. Andre Roland -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#689293: dia menu entry should use /usr/bin/dia not /usr/bin/dia-normal
On 04.10.2012 09:57, schrieb Roland Stigge: Hi! On 10/04/2012 09:07 AM, Andre Naujoks wrote: On 01/10/12 10:30, Andre Naujoks wrote: The installation of dia should add a menu entry to start dia with the link in /usr/bin/dia, so the choice of the alternatives system is taken into account. Currently /usr/bin/dia-normal is used, which bypasses the alternatives system. Interesting question. Currently, dia just installs menu files for dia(-normal) and dia-gnome each, which will both appear in the menu, if available. Now I wonder if menu entries should follow alternative system choices or not. Is there a policy about that or some common practice in other packages? Now that you mention it, I think I don't know any other package that uses the alternatives system the way dia does. The choice is basically a command line parameter. But I think dia should start in the same configuration regardless of where it is started from, be it a menu or the command line. Now I understand what you mean :-) : Dia actually has 4 alternatives entries: dia-normal and dia-gnome, with an -integrated variant each, to provide the integrated window view as default. The upstream default (without command line option) is non-integrated, and on the Debian desktop, --integrated would be best. For consolidation, we can consider doing only the integrated variant, at least for the menus. That would mean the problem is just switched around. If I choose to change what my dia points to (via update-alternatives) I'd expect this change to be used when I start dia via a menu. I think it would be best to remove the alternatives to the non integrated forms and use the alternative chosen to launch dia from a menu. This way dia is consistently used in its integrated form and only if you really want to, you can start dia-normal. Still, we have dia-normal and dia-gnome. Does your report apply to this as well? My question about other packages referred to possible examples of menu entries interacting with alternatives config. I don't know of any, but I don't really know that many packages in depth. dia-gnome should be one alternative in the alternatives group. Andre Roland -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#689293: dia menu entry should use /usr/bin/dia not /usr/bin/dia-normal
Package: dia Version: 0.97.2-8 Severity: normal --- Please enter the report below this line. --- Hi. The installation of dia should add a menu entry to start dia with the link in /usr/bin/dia, so the choice of the alternatives system is taken into account. Currently /usr/bin/dia-normal is used, which bypasses the alternatives system. Regards Andre Naujoks --- System information. --- Architecture: amd64 Kernel: Linux 3.5-trunk-amd64 Debian Release: wheezy/sid 500 unstablewww.debian-multimedia.org 500 unstableftp.de.debian.org 500 stable dl.google.com 1 experimentalftp.de.debian.org --- Package information. --- Depends(Version) | Installed -+-== libart-2.0-2 (= 2.3.18) | libatk1.0-0 (= 1.12.4) | libc6 (= 2.7) | libcairo2 (= 1.2.4) | libfontconfig1(= 2.8.0) | libfreetype6 (= 2.2.1) | libgdk-pixbuf2.0-0 (= 2.22.0) | libglib2.0-0 (= 2.24.0) | libgtk2.0-0 (= 2.12.0) | libpango1.0-0(= 1.18.0) | libpng12-0 (= 1.2.13-4) | libxml2 (= 2.7.4) | zlib1g (= 1:1.1.4) | dia-common (= 0.97.2-8) | dia-libs(= 0.97.2-8) | Recommends (Version) | Installed ==-+-=== gsfonts-x11| 0.22 Package's Suggests field is empty. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#681303: apt: Dependency resolution fails for foreign architecture with architecture independent dependency
Package: apt Version: 0.9.7.1 Severity: normal Dear Maintainer, Hi I told my amd64 system to be able to install i386 packages with 'dpkg --add-architecture i386' After an apt-get update I am now able to tell apt to use i386 versions of packages. I need this for a third party package, that is not available in 64bit. apt seems to try to resolve packages from the foreign architecture only from the foreign architecture, which fails if the dependency is for a package, that is available for 'all' I hit this, while trying to install libgnomeprint2.2-0:i386 # apt-get install libgnomeprint2.2-0:i386 Reading package lists... Done Building dependency tree Reading state information... Done Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. The following information may help to resolve the situation: The following packages have unmet dependencies: libgnomeprint2.2-0:i386 : Depends: libgnomeprint2.2-data:i386 (= 2.18.8-3) but it is not installable E: Unable to correct problems, you have held broken packages. The Problem is, that libgnomeprint2.2-data is in the 'all' architecture, so apt should use that package to satisfy the dependency. Or am I doing something horribly wrong here? Regards nautsch -- Package-specific info: -- apt-config dump -- APT ; APT::Architecture amd64; APT::Build-Essential ; APT::Build-Essential:: build-essential; APT::Install-Recommends 1; APT::Install-Suggests 0; APT::Authentication ; APT::Authentication::TrustCDROM true; APT::NeverAutoRemove ; APT::NeverAutoRemove:: ^firmware-linux.*; APT::NeverAutoRemove:: ^linux-firmware$; APT::NeverAutoRemove:: ^linux-image.*; APT::NeverAutoRemove:: ^kfreebsd-image.*; APT::NeverAutoRemove:: ^linux-restricted-modules.*; APT::NeverAutoRemove:: ^linux-ubuntu-modules-.*; APT::NeverAutoRemove:: ^gnumach$; APT::NeverAutoRemove:: ^gnumach-image.*; APT::Never-MarkAuto-Sections ; APT::Never-MarkAuto-Sections:: metapackages; APT::Never-MarkAuto-Sections:: restricted/metapackages; APT::Never-MarkAuto-Sections:: universe/metapackages; APT::Never-MarkAuto-Sections:: multiverse/metapackages; APT::Never-MarkAuto-Sections:: oldlibs; APT::Never-MarkAuto-Sections:: restricted/oldlibs; APT::Never-MarkAuto-Sections:: universe/oldlibs; APT::Never-MarkAuto-Sections:: multiverse/oldlibs; APT::Periodic ; APT::Periodic::Update-Package-Lists 1; APT::Periodic::Download-Upgradeable-Packages 0; APT::Periodic::AutocleanInterval 0; APT::Update ; APT::Update::Post-Invoke ; APT::Update::Post-Invoke:: touch /var/lib/apt/periodic/update-success-stamp 2/dev/null || true; APT::Update::Post-Invoke-Success ; APT::Update::Post-Invoke-Success:: [ ! -f /var/run/dbus/system_bus_socket ] || /usr/bin/dbus-send --system --dest=org.debian.apt --type=signal /org/debian/apt org.debian.apt.CacheChanged || true; APT::Update::Post-Invoke-Success:: /usr/bin/test -e /usr/share/dbus-1/system-services/org.freedesktop.PackageKit.service /usr/bin/test -S /var/run/dbus/system_bus_socket /usr/bin/gdbus call --system --dest org.freedesktop.PackageKit --object-path /org/freedesktop/PackageKit --timeout 1 --method org.freedesktop.PackageKit.StateHasChanged cache-update /dev/null; /bin/echo /dev/null; APT::Archives ; APT::Archives::MaxAge 30; APT::Archives::MinAge 2; APT::Archives::MaxSize 500; APT::Architectures ; APT::Architectures:: amd64; APT::Architectures:: i386; APT::Compressor ; APT::Compressor::. ; APT::Compressor::.::Name .; APT::Compressor::.::Extension ; APT::Compressor::.::Binary ; APT::Compressor::.::Cost 1; APT::Compressor::gzip ; APT::Compressor::gzip::Name gzip; APT::Compressor::gzip::Extension .gz; APT::Compressor::gzip::Binary gzip; APT::Compressor::gzip::Cost 2; APT::Compressor::gzip::CompressArg ; APT::Compressor::gzip::CompressArg:: -9n; APT::Compressor::gzip::UncompressArg ; APT::Compressor::gzip::UncompressArg:: -d; APT::Compressor::bzip2 ; APT::Compressor::bzip2::Name bzip2; APT::Compressor::bzip2::Extension .bz2; APT::Compressor::bzip2::Binary bzip2; APT::Compressor::bzip2::Cost 3; APT::Compressor::bzip2::CompressArg ; APT::Compressor::bzip2::CompressArg:: -9; APT::Compressor::bzip2::UncompressArg ; APT::Compressor::bzip2::UncompressArg:: -d; APT::Compressor::xz ; APT::Compressor::xz::Name xz; APT::Compressor::xz::Extension .xz; APT::Compressor::xz::Binary xz; APT::Compressor::xz::Cost 4; APT::Compressor::xz::CompressArg ; APT::Compressor::xz::CompressArg:: -6; APT::Compressor::xz::UncompressArg ; APT::Compressor::xz::UncompressArg:: -d; APT::Compressor::lzma ; APT::Compressor::lzma::Name lzma; APT::Compressor::lzma::Extension .lzma; APT::Compressor::lzma::Binary xz; APT::Compressor::lzma::Cost 5; APT::Compressor::lzma::CompressArg ; APT::Compressor::lzma::CompressArg:: --format=lzma; APT::Compressor::lzma::CompressArg:: -9; APT::Compressor::lzma::UncompressArg ;
Bug#676182: rxvt-unicode: Scrolling/rendering is very slow
Package: rxvt-unicode Version: 9.15-1 Severity: normal Hi. Sorry for filing this with rxvt-unicode, but this is what I am using. The same problem exists with rxvt and aterm. I don't exactly know when it started, but I think this wasn't the case, when I first used rxvt. To reproduce, open a file in vim with some syntax highlighting (vim and syntax highlighting just worsen the problem, so it is easier to see). For example save the ebay homepage to a html file and open it in vim. Now scroll around (doesn't matter if mouse or keyboard). Now do the same in xterm. For me rxvt is noticably slower and very hard to use. However, if I start rxvt-unicode with xft fonts, it seems to be ok. I tried removing the X-ressources for rcvt-unicode (transparency, shading ...), but to no effect. Scrolling is still very slow. If you need any additional information, I will try my best to provide it, because I really like rxvt-unicode. Regards nautsch -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.3.0-trunk-amd64 (SMP w/6 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages rxvt-unicode depends on: ii base-passwd 3.5.24 ii libc6 2.13-33 ii libfontconfig12.9.0-6 ii libgcc1 1:4.7.0-11 ii libgdk-pixbuf2.0-02.26.1-1 ii libglib2.0-0 2.32.3-1 ii libperl5.14 5.14.2-11 ii libstartup-notification0 0.12-1 ii libx11-6 2:1.4.99.901-2 ii libxft2 2.2.0-3 ii libxrender1 1:0.9.7-1 ii ncurses-base 5.9-8 Versions of packages rxvt-unicode recommends: ii fonts-vlgothic [fonts-japanese-gothic] 20120325-2 ii ttf-dejavu 2.33-2 rxvt-unicode suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#669007: libcppunit-1.12-1: German short description is worded poorly
Package: libcppunit-1.12-1 Version: 1.12.1-4 Severity: minor Tags: l10n Hi. The short description for this Package in german was probably just put through google translate and is .. well lets say poorly worded. I suggest Unittest-bibliothek für C++. Einheiten-Testbibliothek ... is very uncommon at least. Regards Andre Naujoks -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-1-amd64 (SMP w/6 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages libcppunit-1.12-1 depends on: ii libc6 2.13-27 ii libgcc1 1:4.6.2-16 ii libstdc++6 4.6.2-16 libcppunit-1.12-1 recommends no packages. libcppunit-1.12-1 suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#648965: comixcursors-righthanded: update-alternatives not used
Package: comixcursors-righthanded Version: 0.7.2-2 Severity: normal Dear Maintainer, I was installing the cursor theme package and I am using the update- alternatives approach for choosing my cursor theme. However during install of the package the themes are not added to the list of alternatives. I helped myself by manually adding the alternatives to the list like this. for i in `dpkg -L comixcursors-righthanded | grep .theme | grep X11`; do update-alternatives --install /usr/share/icons/default/index.theme x-cursor- theme $i 10; done , but I think, this should be done by the package itself. Regards, Andre Naujoks -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 3.0.0-2-amd64 (SMP w/6 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash comixcursors-righthanded depends on no packages. comixcursors-righthanded recommends no packages. Versions of packages comixcursors-righthanded suggests: pn comixcursors-lefthanded none pn comixcursors-lefthanded-opaque none pn comixcursors-righthanded-opaque none -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#612893: fluxbox: Keypresses are lost after changing
Hi. I have the same issues here. For me its almost always two keypresses lost. It took me a while to pin this error to fluxbox but I do not have those problems in gnome for example. This is not *relatively* annoying but _really_ annoying. As an addition: It does not happen, when I just switch around workspaces, but only if I linger/work some time in one workspace and then switch to another one. It isn't application dependent either. I am not using sloppy focus or anything (I have to click or Alt+TAB to focus a window). Regards Andre -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#586273: flashplugin-nonfree: flash website says it's available now
Hi. I really can't find the download. I see the link to the labs page, but there is no download. At least none that I can find. It looks like someone at Adobe made a joke/mistake here. nautsch Am 15.09.2010 03:20, schrieb Tyler MacDonald: Package: flashplugin-nonfree Version: 1:2.8.1 Severity: normal Hi, I went to the adobe site today and it claims that the 64-bit version of 10.1 has been released from labs and is now available for download. I haven't tried installing it yet, but I thought I'd let you know! - Tyler -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#586273: fixed native amd64 version has being available for a while now
Hi. Where exactly do you see a 64 Bit version of the flash player? I can't find one in the links provided by you. As far as I know, there is no 64 Bit version for any platform at the moment. So, yes, you might be missing something Regards Andre Naujoks Am 20.07.2010 23:02, schrieb Yaroslav Halchenko: Just want to complement that according http://www.adobe.com/support/security/bulletins/apsb10-14.html and http://www.adobe.com/software/flash/about/ version 10.1.53.64 has been available since June 25, 2010, so I guess that would be logical to return support for amd64? or am I missing something? Thanks in advance! -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#577510: [icedove] icedove forgets virtual inbox configuration after restart
Package: icedove Version: 3.0.4-2 Severity: normal --- Please enter the report below this line. --- Hi. This is maybe a minor bug, but its unnerving nevertheless. I have two E-Mail accounts configured in icedove. One IMAP one POP3 (don't know if it matters). If I configure the global Inbox virtual folder to show only the inbox of one particular account (via RMB - Properties - choose ..: uncheck the unwanted accounts inbox), it works as long as icedove is not restarted. After the restart the configuration is simply gone and all accounts inboxes are shown again. Regards and thanks for the great work. Andre Naujoks --- System information. --- Architecture: amd64 Kernel: Linux 2.6.34-rc3 Debian Release: squeeze/sid 500 unstableftp2.de.debian.org --- Package information. --- Depends (Version) | Installed =-+-= fontconfig| 2.8.0-2 psmisc| 22.10-1 debianutils (= 1.16) | 3.2.2 libasound2( 1.0.18) | 1.0.22-2 libatk1.0-0 (= 1.29.3) | 1.30.0-1 libc6 (= 2.3.2) | 2.10.2-6 libcairo2 (= 1.8.8) | 1.8.8-2 libdbus-1-3(= 1.0.2) | 1.2.24-1 libdbus-glib-1-2(= 0.78) | 0.84-1 libfontconfig1 (= 2.8.0) | 2.8.0-2 libfreetype6 (= 2.2.1) | 2.3.11-1 libgcc1 (= 1:4.1.1) | 1:4.4.3-7 libglib2.0-0 (= 2.24.0) | 2.24.0-1 libgtk2.0-0 (= 2.18.0) | 2.20.0-2 libjpeg62 | 6b-16.1 libnspr4-0d (= 4.7.0~1.9b1) | 4.8.4-1 libnss3-1d(= 3.12.6) | 3.12.6-1 libpango1.0-0 (= 1.14.0) | 1.26.2-1 libsqlite3-0(= 3.6.23.1) | 3.6.23.1-1 libstartup-notification0(= 0.10) | 0.10-1 libstdc++6 (= 4.1.1) | 4.4.3-7 libx11-6 (= 0) | 2:1.3.3-2 libxrender1 | 1:0.9.5-2 libxt6| 1:1.0.7-1 zlib1g (= 1:1.1.4) | 1:1.2.3.4.dfsg-3 Recommends (Version) | Installed ==-+-=== myspell-en-us | OR hunspell-dictionary| OR myspell-dictionary | libbonobo2-0 (= 2.15.0) | 2.24.3-1 libgconf2-4(= 2.27.0) | 2.28.1-1 libgnome2-0(= 2.17.3) | 2.28.0-1 libgnomevfs2-0 (= 1:2.17.90) | 1:2.24.3-1 liborbit2 (= 1:2.14.10) | 1:2.14.17-2 libpopt0 (= 1.15) | 1.15-1 Suggests (Version) | Installed ===-+-=== ttf-lyx | 1.6.5-1 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#490384: upstream version on debian mentors
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi. Its now almost 2 years since Giuseppe tried this and I think he did a better job than me, but his package vanished. So here it goes. I uploaded a package to debian mentors and you might consider it or give it a look. Since this is a first try, it might only be a starting point. http://mentors.debian.net/debian/pool/main/n/nload Regards Andre Naujoks -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQEcBAEBAgAGBQJLlS+xAAoJEFjpxyF47AzYMtwIAIrFlXcfB0XATCYd1mdSOLEK w6RY6qiDmr/grWuRESwUwNDeLs08hSVVuBoZAQII4/wbUZbM6qilcVYoey6bYOn6 L5Htt8v7Ocg8xGfbkC5XhA0TBGRPz6yD1BXSxNIBrPznDNaKD2Uu7s7iKB0J7zcF 9NIYaF+qBmZSriQgF65CnDrVk/q4K5xpAG7xYAZh+07fslFbng0AhmTbuOGtQKL0 XLUtXyRec8d1ITA9EsQuQwEHD9zm2w0jCeWIJmHrU/EMgWmqjQ7rs7smBDfSq/mg BEKZN1UCZtu1pv1i62RcBn5131Yximj0YgtndPSedvVptmC0bL0+dE2UNQO4C2w= =tBf6 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#490384: New Version is available
Hi. Is there a reason why the new (1 and a half year old) version is not being packaged? Is there something wrong with it? Can I help in some way? It compiles and runs just fine on my system. And I'd rather use a packaged version of some software, than cluttering my system with who knows what. Greetings Andre Naujoks -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#567645: [acpi-support] Thinkpad T61 volume buttons don't work
Package: acpi-support Version: 0.132-1 Severity: normal --- Please enter the report below this line. --- Hi all. On my Thinkpad T61 the volume buttons don't work. I don't really know if this is the correct package to file the bug for, but I thought, since it is an acpi feature I'd try it here. When I run acpi_listen I get events form the buttons in this form: button/mute MUTE 0080 button/volumedown VOLDN 0080 button/volumeup VOLUP 0080 So the buttons are registered somewhere and just don't trigger volume changes. The event names correspond to the action the button should do. Where are those events processed normally? because they seem quite generic. Am I missing something? Some additional package? Regards Andre Naujoks --- System information. --- Architecture: amd64 Kernel: Linux 2.6.32-trunk-amd64 Debian Release: squeeze/sid 500 unstable localhost --- Package information. --- Depends (Version) | Installed ==-+-= acpi-support-base (= 0.109-1) | 0.132-1 x11-xserver-utils | 7.5+1 acpid (= 1.0.4) | 1:2.0.1-1 lsb-base (= 1.3-9) | 3.2-23 pm-utils | 1.2.6.1-3 libc6 (= 2.2.5) | 2.10.2-5 Recommends (Version) | Installed -+-=== dbus | 1.2.16-2 hal | 0.5.14-1 vbetool | 1.1-2 xscreensaver | 5.10-6 OR gnome-screensaver | radeontool | 1.5-5 Suggests (Version) | Installed -+-=== nvclock | dmidecode (= 2.7-1) | 2.9-1.2 rfkill | -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#556542: valgrind: missing dependency for libc6-dbg
Package: valgrind Version: 1:3.5.0-2 Severity: important Hi. I recently updated my libc6 and after the update (which probably removed my libc6-dbg due to some other problem), valgrind threw huge amounts of false positives. I asked at the valgrind-users mailinglist and the problem is with valgrind not knowing the right glibc version or assuming a wrong one. I don't know the details, but valgrind has to know the version of it to be able to warn the user about missing debug symbols. This is not the case, if the debug symbols are there. And those are in the libc6-dbg package. Valgrind (memcheck at least) needs the debug symbols from libc6 to function properly. If valgrind knows the libc version it can tell the user to install them, but if not, it breaks. Setting the libc6-dbg package as a dependency will resolve this problem. It needs them anyway. For the original thread on the valgrind-users list see: http://sourceforge.net/mailarchive/forum.php?thread_name=4B010952.8000709%40googlemail.comforum_name=valgrind-users Greetings Andre -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.30-2-amd64 (SMP w/4 CPU cores) Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages valgrind depends on: ii libc6 2.10.1-7 GNU C Library: Shared libraries Versions of packages valgrind recommends: ii gdb6.8.50.20090628-4 The GNU Debugger Versions of packages valgrind suggests: pn alleyoop none (no description available) ii kcachegrind 4:4.3.2-1 visualisation tool for the Valgrin ii libc6-dbg 2.10.1-7 GNU C Library: detached debugging -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#550237: vim: mouse clicks produce bogus, if clicked too far to the right.
Package: vim Version: 2:7.2.245-2 Severity: normal Hi. I am using quite a large screen (1920x1200) and if I enable mouse support in vim (:set mouse=a, in my case its in ~/.vimrc), I get wierd results, when I try to use the mouse on the far right side of the screen. By wierd I mean, that the clicks are not registred as clicks but as key presses. The keys pressed are mostly harmless, but it inserts text or deletes lines or does things according to which key was just recognized. To reproduce this, open vim on a wide screen (two screens will do, too) or with a very tiny (narrow) font. And write a long line. On my screen the clicks are no longer correctly registered after the 223rd column of text, so clicking on the 224th or any later column brakes the mouse support. It has obviously something to do with the 223 columns, because, when I increase the font size, to something, so no 223 columns have room on the screen, the error is no longer there. When i decrease the size, the limit for the mouse moves further to the left. By the way: I had the sam eproblem on an x86 32Bit machine, but I thought it was a problem with my dual head setup. Now I am using only one screen and get the same problem. Greetings Andre -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-rc2nautsch (SMP w/4 CPU cores) Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages vim depends on: ii libacl1 2.2.48-1 Access control list shared library ii libc6 2.9-27 GNU C Library: Shared libraries ii libgpm2 1.20.4-3.2 General Purpose Mouse - shared lib ii libncurses5 5.7+20090803-2 shared libraries for terminal hand ii libselinux1 2.0.85-4 SELinux runtime shared libraries ii vim-common2:7.2.245-2Vi IMproved - Common files ii vim-runtime 2:7.2.245-2Vi IMproved - Runtime files vim recommends no packages. Versions of packages vim suggests: pn ctags none (no description available) pn vim-doc none (no description available) pn vim-scripts none (no description available) -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#501532: kile: Wrong file in errors and warnings (FIXED in upstream)
Package: kile Version: 1:2.0.1-1 Severity: important This Bug is already fixed in the upstream Version of Kile. See Bug #172286 in the kde bugtracker. So this package should be updated to version 2.0.2. The behaviour is that kile always shows the main document as the source of a latex error or warning in an multifile document. greetings nautsch -- System Information: Debian Release: sid APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.25-2-686 (SMP w/1 CPU core) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages kile depends on: ii kdelibs4c2a 4:3.5.9.dfsg.1-6 core libraries and binaries for al ii konsole 4:3.5.9.dfsg.1-5 X terminal emulator for KDE ii libc6 2.7-13 GNU C Library: Shared libraries ii libqt3-mt 3:3.3.8b-5 Qt GUI Library (Threaded runtime v ii libstdc++6 4.3.2-1 The GNU Standard C++ Library v3 ii texlive-latex-base 2007.dfsg.1-4TeX Live: Basic LaTeX packages Versions of packages kile recommends: ii dvipng1.11-1 convert DVI files to PNG graphics ii kdvi 4:3.5.9-3 dvi viewer for KDE ii kghostview4:3.5.9-3 PostScript viewer for KDE pn kpdf none (no description available) Versions of packages kile suggests: pn gbib none(no description available) ii gv 1:3.6.5-2 PostScript and PDF viewer for X pn kile-i18n none(no description available) pn latex2html none(no description available) pn pybliographer none(no description available) ii xfig 1:3.2.5-rel-2 Facility for Interactive Generatio -- no debconf information -- Ist Ihr Browser Vista-kompatibel? Jetzt die neuesten Browser-Versionen downloaden: http://www.gmx.net/de/go/browser -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#479247: 1.0.0 again
OK here without the wrong linebreaks. It should work with the 1.0.1 with the according line movements patch should use. --- xbattbar/xbattbar-acpi.c2008-05-22 21:27:15.0 +0200 +++ xbattbar/xbattbar-acpi.c.new2008-05-22 21:25:32.0 +0200 @@ -174,7 +174,7 @@ values[0]= 1; //values[1] = XCB_EVENT_MASK_EXPOSURE | XCB_EVENT_MASK_ENTER_WINDOW | XCB_EVENT_MASK_LEAVE_WINDOW ; - values[1] = XCB_EVENT_MASK_ENTER_WINDOW | XCB_EVENT_MASK_LEAVE_WINDOW ; + values[1] = XCB_EVENT_MASK_ENTER_WINDOW | XCB_EVENT_MASK_LEAVE_WINDOW | XCB_EVENT_MASK_VISIBILITY_CHANGE; xcb_unmap_window(c,win); @@ -523,6 +523,11 @@ case XCB_LEAVE_NOTIFY: xosd_destroy (osd); break; + case XCB_VISIBILITY_PARTIALLY_OBSCURED: + case XCB_VISIBILITY_FULLY_OBSCURED: + case XCB_VISIBILITY_NOTIFY: + draw(); + break; } free(e); } -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#479247: 1.0.0
Hi. I tried the 1.0.0 and am missing the always on top option. I was looking into the code and found another issue, which is easily adressed. The baris not redrawn until the polling timeout runs out. What do you think of this for the 1.0.0? --- xbattbar/xbattbar-acpi.c2008-05-22 21:27:15.0 +0200 +++ xbattbar/xbattbar-acpi.c.new2008-05-22 21:25:32.0 +0200 @@ -174,7 +174,7 @@ values[0]= 1; //values[1] = XCB_EVENT_MASK_EXPOSURE | XCB_EVENT_MASK_ENTER_WINDOW | X CB_EVENT_MASK_LEAVE_WINDOW ; - values[1] = XCB_EVENT_MASK_ENTER_WINDOW | XCB_EVENT_MASK_LEAVE_WINDOW ; + values[1] = XCB_EVENT_MASK_ENTER_WINDOW | XCB_EVENT_MASK_LEAVE_WINDOW |XCB_EVENT_MASK_VISIBILITY_CHANGE; xcb_unmap_window(c,win); @@ -523,6 +523,11 @@ case XCB_LEAVE_NOTIFY: xosd_destroy (osd); break; + case XCB_VISIBILITY_PARTIALLY_OBSCURED: + case XCB_VISIBILITY_FULLY_OBSCURED: + case XCB_VISIBILITY_NOTIFY: + draw(); + break; } free(e); } -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#479247: xbattbar-acpi: only updates if touched with mouse
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 You're welcome. And thanks for taking over the package maintaining. (hope you do) Greetings ~ Andre -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIH0QLHmg69W6dq94RAne4AJ936eh/6JtzUF3fwiA843b5cU53qQCeLoze 10cnCf2jSQAFY7b7OKdRZKA= =k6rR -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#479247: xbattbar-acpi: only updates if touched with mouse
Package: xbattbar-acpi Version: 0.4.0-1 Severity: normal Hi! The bar is only redrawn if i touch it with the mouse. So what i mean is, that the battery level changes, but the bar does not. When i move the mouse over it, so the OSD is shown, the bar is also redrawn. I compiled the package with DEBUG and the output states, that a redraw takes place and also the battery info is retrieved every 5 seconds (which is the standard interval). As far as i can see, the problem is setting the read battery info internally. Greetings nautsch -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.25 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/bash Versions of packages xbattbar-acpi depends on: ii libacpi0 0.2-4 general purpose library for ACPI ii libc6 2.7-10 GNU C Library: Shared libraries ii libx11-6 2:1.0.3-7 X11 client-side library ii libxext6 2:1.0.4-1 X11 miscellaneous extension librar ii libxinerama1 2:1.0.3-1 X11 Xinerama extension library ii libxosd2 2.2.14-1.5 X On-Screen Display library - runt xbattbar-acpi recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
