Bug#678947: Aw: Re: RFP: M64Py -- Mupen64Plus 2.0 GUI frontend written in python
> you've seem to upload your PPA random-stuff to Debian. This is really awesome. > But will you also upload mupen64plus-ui-python > ( https://github.com/mupen64plus/mupen64plus-ui-python ) to resolve the WNPP > bug #678947 in Debian? Just saw the import of your package to the Debian pkg-games git repository at http://anonscm.debian.org/cgit/pkg-games/mupen64plus-ui-python.git/ When will you upload it to Debian unstable?
Bug#678947: RFP: M64Py -- Mupen64Plus 2.0 GUI frontend written in python
Hi Sérgio, you've seem to upload your PPA random-stuff to Debian. This is really awesome. But will you also upload mupen64plus-ui-python ( https://github.com/mupen64plus/mupen64plus-ui-python ) to resolve the WNPP bug #678947 in Debian?
Bug#780673: gitolite3: git-annex shell is not working: FATAL: bad git-annex-shell command - patch available
patch 780673 + jessie severity 780673 serious thanks I've just upgraded to Jessie and tried to download some data and now my repositories are broken and I cannot do anything with them. I only get get foo/bar (not available) Try making some of these repositories available: 52f2bae6-e67e-11e4-a474-0021ccb48233 (Note that these git remotes have annex-ignore set: origin) failed git-annex: get: 1 failed and it doesn't even want to work after I've applied the patch. New clones seem to work with the data which was already on the server but my other ones seem to be now broken and I have possible data loss. I will most likely spend the rest of the weekend getting the lost data out of the backups... hoping that the backup software in Jessie isn't also broken :( -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#781354: [cuneiform] Buffer overflow triggered by user supplied image
Package: cuneiform Version: 1.1.0+dfsg-5 Severity: normal Images can be used to cause an buffer overflow. An example image is attached. This can be debugged the easiest when adding -fsanitize=address to the CFLAGS/CXXFLAGS If you want to build it yourself without the debian packaging stuff then you can easily do it with: mkdir build cd build cmake -DCMAKE_C_FLAGS_RELWITHDEBINFO=-g3 -fsanitize=address -DCMAKE_CXX_FLAGS_RELWITHDEBINFO=-g3 -fsanitize=address -DCMAKE_BUILD_TYPE=relwithdebinfo -DCMAKE_VERBOSE_MAKEFILE=ON -DCMAKE_INSTALL_PREFIX=/usr .. make I ran the test as follows: cuneiform -l ger -f hocr -o hocr.html ~/cuneiform_crash.tiff Output with Debian build: Cuneiform for Linux 1.1.0 *** buffer overflow detected ***: cuneiform terminated === Backtrace: = /lib/x86_64-linux-gnu/libc.so.6(+0x731ff)[0x7f623b8e31ff] /lib/x86_64-linux-gnu/libc.so.6(__fortify_fail+0x37)[0x7f623b9664c7] /lib/x86_64-linux-gnu/libc.so.6(+0xf46e0)[0x7f623b9646e0] /usr/lib/x86_64-linux-gnu/cuneiform/libfon32.so.0(+0x1fdca)[0x7f6235f8ddca] /usr/lib/x86_64-linux-gnu/cuneiform/libfon32.so.0(+0x20008)[0x7f6235f8e008] /usr/lib/x86_64-linux-gnu/cuneiform/libfon32.so.0(FONRecog2Glue+0x17f)[0x7f6235f7d91f] /usr/lib/x86_64-linux-gnu/cuneiform/libpass2.so.0(+0x7265)[0x7f6235b1a265] /usr/lib/x86_64-linux-gnu/cuneiform/libpass2.so.0(+0x74ba)[0x7f6235b1a4ba] /usr/lib/x86_64-linux-gnu/cuneiform/libpass2.so.0(+0xa544)[0x7f6235b1d544] /usr/lib/x86_64-linux-gnu/cuneiform/libpass2.so.0(p2_proc+0xa59)[0x7f6235b1e479] /usr/lib/x86_64-linux-gnu/cuneiform/librstr.so.0(+0x8f1fa)[0x7f6238ab51fa] /usr/lib/x86_64-linux-gnu/cuneiform/librstr.so.0(RSTRRecognizeMain+0x39e)[0x7f6238ac895e] /usr/lib/x86_64-linux-gnu/cuneiform/librstr.so.0(RSTRRecognize+0x11)[0x7f6238ac8c91] /usr/lib/x86_64-linux-gnu/libcuneiform.so.0(+0xb4ec)[0x7f623c3af4ec] /usr/lib/x86_64-linux-gnu/libcuneiform.so.0(PUMA_XFinalRecognition+0xb9)[0x7f623c3b0ca9] cuneiform[0x402cb7] /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf5)[0x7f623b891b45] cuneiform[0x402fa9] === Memory map: 0040-00404000 r-xp 00:10 4199338 /usr/bin/cuneiform 00603000-00604000 r--p 3000 00:10 4199338 /usr/bin/cuneiform 00604000-00605000 rw-p 4000 00:10 4199338 /usr/bin/cuneiform 0146a000-04ea2000 rw-p 00:00 0 [heap] 7f6231a5-7f6231a55000 r-xp 00:10 4598675 /usr/lib/x86_64-linux-gnu/libXdmcp.so.6.0.0 7f6231a55000-7f6231c54000 ---p 5000 00:10 4598675 /usr/lib/x86_64-linux-gnu/libXdmcp.so.6.0.0 7f6231c54000-7f6231c55000 rw-p 4000 00:10 4598675 /usr/lib/x86_64-linux-gnu/libXdmcp.so.6.0.0 7f6231c55000-7f6231c58000 r-xp 00:10 532763 /usr/lib/x86_64-linux-gnu/libXau.so.6.0.0 7f6231c58000-7f6231e57000 ---p 3000 00:10 532763 /usr/lib/x86_64-linux-gnu/libXau.so.6.0.0 7f6231e57000-7f6231e58000 r--p 2000 00:10 532763 /usr/lib/x86_64-linux-gnu/libXau.so.6.0.0 7f6231e58000-7f6231e59000 rw-p 3000 00:10 532763 /usr/lib/x86_64-linux-gnu/libXau.so.6.0.0 7f6231e59000-7f6231e7a000 r-xp 00:10 4340365 /usr/lib/x86_64-linux-gnu/libxcb.so.1.1.0 7f6231e7a000-7f6232079000 ---p 00021000 00:10 4340365 /usr/lib/x86_64-linux-gnu/libxcb.so.1.1.0 7f6232079000-7f623207a000 r--p 0002 00:10 4340365 /usr/lib/x86_64-linux-gnu/libxcb.so.1.1.0 7f623207a000-7f623207b000 rw-p 00021000 00:10 4340365 /usr/lib/x86_64-linux-gnu/libxcb.so.1.1.0 7f623207b000-7f623207f000 r-xp 00:10 4730118 /lib/x86_64-linux-gnu/libuuid.so.1.3.0 7f623207f000-7f623227e000 ---p 4000 00:10 4730118 /lib/x86_64-linux-gnu/libuuid.so.1.3.0 7f623227e000-7f623227f000 r--p 3000 00:10 4730118 /lib/x86_64-linux-gnu/libuuid.so.1.3.0 7f623227f000-7f623228 rw-p 4000 00:10 4730118 /lib/x86_64-linux-gnu/libuuid.so.1.3.0 7f623228-7f6232287000 r-xp 00:10 4199110 /usr/lib/x86_64-linux-gnu/cuneiform/libr3532.so.1.1.0 7f6232287000-7f6232486000 ---p 7000 00:10 4199110 /usr/lib/x86_64-linux-gnu/cuneiform/libr3532.so.1.1.0 7f6232486000-7f6232487000 r--p 6000 00:10 4199110 /usr/lib/x86_64-linux-gnu/cuneiform/libr3532.so.1.1.0 7f6232487000-7f6232488000 rw-p 7000 00:10 4199110 /usr/lib/x86_64-linux-gnu/cuneiform/libr3532.so.1.1.0 7f6232488000-7f623248b000 rw-p 00:00 0 7f623248b000-7f623248c000 r-xp 00:10 4199145 /usr/lib/x86_64-linux-gnu/cuneiform/libcpu32.so.1.1.0 7f623248c000-7f623268b000 ---p 1000 00:10 4199145 /usr/lib/x86_64-linux-gnu/cuneiform/libcpu32.so.1.1.0
Bug#777753: [Reproducible-builds] Bug#777753: gcc: LTO produces unreproducible debug information
tags 53 + fixed-upstream thanks Backport for 4.9.x: https://gcc.gnu.org/viewcvs/gcc?view=revisionrevision=220935 Backport for 4.8.x: https://gcc.gnu.org/viewcvs/gcc?view=revisionrevision=220938 Versions including the fix: 4.8.5, 4.9.3, 5.0 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#777753: [Reproducible-builds] Bug#777753: gcc: LTO produces unreproducible debug information
I have to correct my last statement. It is still necessary to add
-flto-partition=none when using -flto in a package. My earlier statement
came from the wrong understanding of buildid as explained in the gcc bug [3].
A new patch [4] was submitted by Richard Biener. Together these patches [1,2,3]
were enough to fix all my testcases and at least build some of the affected
packages reproducible (I haven't tested all of them).
-flto-partition=none wasn't necessary anymore in my tests
The gcc-4.9 patch used for this test is attached.
[1] https://gcc.gnu.org/viewcvs/gcc?view=revisionrevision=220678
[2] https://gcc.gnu.org/viewcvs/gcc?view=revisionrevision=220613
[3] https://gcc.gnu.org/viewcvs/gcc?view=revisionrevision=220735
[4] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65015#c22diff -u gcc-4.9-4.9.2/debian/rules.patch gcc-4.9-4.9.2/debian/rules.patch
--- gcc-4.9-4.9.2/debian/rules.patch
+++ gcc-4.9-4.9.2/debian/rules.patch
@@ -232,6 +232,7 @@
sys-auxv-header \
libcilkrts-targets \
go-use-gold \
+ drop_opt \
ifeq ($(with_softfloat),yes)
debian_patches += arm-multilib-soft-float
only in patch2:
unchanged:
--- gcc-4.9-4.9.2.orig/debian/patches/drop_opt.diff
+++ gcc-4.9-4.9.2/debian/patches/drop_opt.diff
@@ -0,0 +1,46 @@
+Bug: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65015
+
+--- a/src/gcc/dwarf2out.c
b/src/gcc/dwarf2out.c
+@@ -19196,6 +19196,9 @@ gen_producer_string (void)
+ case OPT__sysroot_:
+ case OPT_nostdinc:
+ case OPT_nostdinc__:
++ case OPT_fpreprocessed:
++ case OPT_fltrans_output_list_:
++ case OPT_fresolution_:
+ /* Ignore these. */
+ continue;
+ default:
+@@ -23984,8 +23987,13 @@ dwarf2out_finish (const char *filename)
+ gen_remaining_tmpl_value_param_die_attribute ();
+
+ /* Add the name for the main input file now. We delayed this from
+- dwarf2out_init to avoid complications with PCH. */
+- add_name_attribute (comp_unit_die (), remap_debug_filename (filename));
++ dwarf2out_init to avoid complications with PCH.
++ For LTO produced units use a fixed artificial name to avoid
++ leaking tempfile names into the dwarf. */
++ if (!in_lto_p)
++add_name_attribute (comp_unit_die (), remap_debug_filename (filename));
++ else
++add_name_attribute (comp_unit_die (), artificial);
+ if (!IS_ABSOLUTE_PATH (filename) || targetm.force_at_comp_dir)
+ add_comp_dir_attribute (comp_unit_die ());
+ else if (get_AT (comp_unit_die (), DW_AT_comp_dir) == NULL)
+--- a/src//gcc/varasm.c
b/src//gcc/varasm.c
+@@ -6964,7 +6964,12 @@ default_file_start (void)
+ fputs (ASM_APP_OFF, asm_out_file);
+
+ if (targetm.asm_file_start_file_directive)
+-output_file_directive (asm_out_file, main_input_filename);
++{
++ if (in_lto_p)
++output_file_directive (asm_out_file, artificial);
++ else
++output_file_directive (asm_out_file, main_input_filename);
++}
+ }
+
+ /* This is a generic routine suitable for use as TARGET_ASM_FILE_END
Bug#777753: Aw: [Reproducible-builds] Bug#777753: gcc: LTO produces unreproducible debug information
The patches are now upstream [1, 2]. The last test [2] showed that these really seemed to be the culprit of the problem. In the meantime, Richard Biener proposed patches which can solve this problem. I've compiled my own version of gcc-4.9 using the attached patch and can confirm that the LTO builds are now working perfectly fine and no changes to the affected packages are necessary anymore. I have to correct my last statement. It is still necessary to add -flto-partition=none when using -flto in a package. My earlier statement came from the wrong understanding of buildid as explained in the gcc bug [3]. I've used the updated patches in my tests (see attachment) [1] https://gcc.gnu.org/viewcvs/gcc?view=revisionrevision=220678 [2] https://gcc.gnu.org/viewcvs/gcc?view=revisionrevision=220613 [3] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65015#c9diff -u gcc-4.9-4.9.2/debian/rules.patch gcc-4.9-4.9.2/debian/rules.patch --- gcc-4.9-4.9.2/debian/rules.patch +++ gcc-4.9-4.9.2/debian/rules.patch @@ -232,6 +232,7 @@ sys-auxv-header \ libcilkrts-targets \ go-use-gold \ + drop_opt \ ifeq ($(with_softfloat),yes) debian_patches += arm-multilib-soft-float only in patch2: unchanged: --- gcc-4.9-4.9.2.orig/debian/patches/drop_opt.diff +++ gcc-4.9-4.9.2/debian/patches/drop_opt.diff @@ -0,0 +1,30 @@ +Bug: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65015 + +--- a/src/gcc/dwarf2out.c b/src/gcc/dwarf2out.c +@@ -19196,6 +19196,9 @@ gen_producer_string (void) + case OPT__sysroot_: + case OPT_nostdinc: + case OPT_nostdinc__: ++ case OPT_fpreprocessed: ++ case OPT_fltrans_output_list_: ++ case OPT_fresolution_: + /* Ignore these. */ + continue; + default: +@@ -23984,8 +23987,13 @@ dwarf2out_finish (const char *filename) + gen_remaining_tmpl_value_param_die_attribute (); + + /* Add the name for the main input file now. We delayed this from +- dwarf2out_init to avoid complications with PCH. */ +- add_name_attribute (comp_unit_die (), remap_debug_filename (filename)); ++ dwarf2out_init to avoid complications with PCH. ++ For LTO produced units use a fixed artificial name to avoid ++ leaking tempfile names into the dwarf. */ ++ if (!in_lto_p) ++add_name_attribute (comp_unit_die (), remap_debug_filename (filename)); ++ else ++add_name_attribute (comp_unit_die (), artificial); + if (!IS_ABSOLUTE_PATH (filename) || targetm.force_at_comp_dir) + add_comp_dir_attribute (comp_unit_die ()); + else if (get_AT (comp_unit_die (), DW_AT_comp_dir) == NULL)
Bug#777753: gcc: LTO produces unreproducible debug information
affects 53 + apt-cacher-ng affects 53 + avian affects 53 + batctl affects 53 + batmand affects 53 + cloop affects 53 + encfs affects 53 + exactimage affects 53 + kwalletcli affects 53 + makefs affects 53 + mupen64plus-audio-sdl affects 53 + mupen64plus-core affects 53 + mupen64plus-input-sdl affects 53 + mupen64plus-rsp-hle affects 53 + mupen64plus-rsp-z64 affects 53 + mupen64plus-ui-console affects 53 + mupen64plus-video-arachnoid affects 53 + mupen64plus-video-glide64 affects 53 + mupen64plus-video-rice affects 53 + mupen64plus-video-z64 affects 53 + pax affects 53 + py3cairo affects 53 + rna-star affects 53 + rs affects 53 + simgrid affects 53 + systemd thanks I just tried to extract the visible -flto parameters from the reproducible build [1] logs and got this list of packages. There might be even more packages which are affected. [1] https://reproducible.debian.net/reproducible.html -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#777753: gcc: LTO produces unreproducible debug information
Source: gcc-4.9 Version: 4.9.2-10 Severity: normal Tags: patch User: reproducible-bui...@lists.alioth.debian.org Usertags: randomness toolchain X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org Forwarded: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65015 The GCC produced binaries seem to be only reproducible when not using link time optimization. This was discussed on the mailing list [1]. Both Jérémy Bobbio and Richard Biener pointed me in the direction of debug information which contained artifacts from the randomly generated temporary files of the LTO builds. The last test [2] showed that these really seemed to be the culprit of the problem. In the meantime, Richard Biener proposed patches which can solve this problem. I've compiled my own version of gcc-4.9 using the attached patch and can confirm that the LTO builds are now working perfectly fine and no changes to the affected packages are necessary anymore. Other versions of gcc might also have this problem but this is right now only for the default gcc version used by the build infrastructure. A small testcase is attached to the upstream bug. [1] http://lists.alioth.debian.org/pipermail/reproducible-builds/Week-of-Mon-20150209/000933.html [2] http://lists.alioth.debian.org/pipermail/reproducible-builds/Week-of-Mon-20150209/000942.htmldiff -u gcc-4.9-4.9.2/debian/rules.patch gcc-4.9-4.9.2/debian/rules.patch --- gcc-4.9-4.9.2/debian/rules.patch +++ gcc-4.9-4.9.2/debian/rules.patch @@ -232,6 +232,7 @@ sys-auxv-header \ libcilkrts-targets \ go-use-gold \ + drop_opt \ ifeq ($(with_softfloat),yes) debian_patches += arm-multilib-soft-float only in patch2: unchanged: --- gcc-4.9-4.9.2.orig/debian/patches/drop_opt.diff +++ gcc-4.9-4.9.2/debian/patches/drop_opt.diff @@ -0,0 +1,28 @@ +Bug: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65015 + +--- a/src/gcc/dwarf2out.c b/src/gcc/dwarf2out.c +@@ -19196,6 +19196,9 @@ gen_producer_string (void) + case OPT__sysroot_: + case OPT_nostdinc: + case OPT_nostdinc__: ++ case OPT_fpreprocessed: ++ case OPT_fltrans_output_list_: ++ case OPT_fresolution_: + /* Ignore these. */ + continue; + default: +@@ -23984,8 +23987,11 @@ dwarf2out_finish (const char *filename) + gen_remaining_tmpl_value_param_die_attribute (); + + /* Add the name for the main input file now. We delayed this from +- dwarf2out_init to avoid complications with PCH. */ +- add_name_attribute (comp_unit_die (), remap_debug_filename (filename)); ++ dwarf2out_init to avoid complications with PCH. ++ Avoid doing this for LTO produced units as it adds random ++ tempfile names. */ ++ if (!in_lto_p) ++add_name_attribute (comp_unit_die (), remap_debug_filename (filename)); + if (!IS_ABSOLUTE_PATH (filename) || targetm.force_at_comp_dir) + add_comp_dir_attribute (comp_unit_die ()); + else if (get_AT (comp_unit_die (), DW_AT_comp_dir) == NULL)
Bug#774155: [linux] Remote crash of kernel via batman-adv module
Package: linux Version: 3.16.7-ckt2-1 Severity: normal Tags: security X-Debbugs-CC: secure-testing-t...@lists.alioth.debian.org The current linux kernel version in Jessie can be crashed from remote when it uses the batman-adv module. More information can be found at http://thread.gmane.org/gmane.linux.network/343494 --- System information. --- Architecture: amd64 Kernel: Linux 3.16.0-4-amd64 Debian Release: 8.0 500 testing http.debian.net -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
