Bug#813357: blacs-mpi: FTBFS: /usr/bin/ld: cannot find -lmpi_f77
Source: blacs-mpi Version: 1.1-33.1 Severity: serious Justification: fails to build from source User: reproducible-bui...@lists.alioth.debian.org Usertags: ftbfs X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org Dear Maintainer, blacs-mpi fails to build from source in unstable/amd64: [..] ^ mv Ccgamx2d_.o cgamx2d_.C mpicc.openmpi -o Czgamx2d_.o -c -O4 -DSYSINC -I/usr/lib/openmpi/include -DAdd_ -DBlacsDebugLvl=0 -DUseMpi2 -DCallFromC zgamx2d_.c In file included from zgamx2d_.c:1:0: zgamx2d_.c: In function 'Czgamx2d': Bdef.h:497:9: warning: implicit declaration of function 'BI_dmvcopy' [-Wimplicit-function-declaration] BI_dmvcopy(2*(m), (n), (double *) (A), 2*(lda), (double *) (buff)) ^ zgamx2d_.c:204:7: note: in expansion of macro 'BI_zmvcopy' BI_zmvcopy(Mpval(m), Mpval(n), A, tlda, bp->Buff); ^ zgamx2d_.c:226:7: warning: 'MPI_Type_struct' is deprecated: MPI_Type_struct is superseded by MPI_Type_create_struct in MPI-2.0 [-Wdeprecated-declarations] BI_MPI_Type_struct(i, len, disp, dtypes, &MyType, ierr); ^ In file included from Bconfig.h:20:0, from Bdef.h:8, from zgamx2d_.c:1: /usr/lib/openmpi/include/mpi.h:1796:20: note: declared here OMPI_DECLSPEC int MPI_Type_struct(int count, int array_of_blocklengths[], ^ In file included from zgamx2d_.c:1:0: Bdef.h:499:9: warning: implicit declaration of function 'BI_dvmcopy' [-Wimplicit-function-declaration] BI_dvmcopy(2*(m), (n), (double *) (A), 2*(lda), (double *) (buff)) ^ zgamx2d_.c:283:6: note: in expansion of macro 'BI_zvmcopy' BI_zvmcopy(Mpval(m), Mpval(n), A, tlda, bp2->Buff); ^ zgamx2d_.c:285:16: warning: implicit declaration of function 'BI_TransDist' [-Wimplicit-function-declaration] BI_TransDist(ctxt, tscope, Mpval(m), Mpval(n), rA, cA, tldia, ^ mv Czgamx2d_.o zgamx2d_.C mpicc.openmpi -o Cigamn2d_.o -c -O4 -DSYSINC -I/usr/lib/openmpi/include -DAdd_ -DBlacsDebugLvl=0 -DUseMpi2 -DCallFromC igamn2d_.c igamn2d_.c: In function 'Cigamn2d': igamn2d_.c:203:7: warning: implicit declaration of function 'BI_imvcopy' [-Wimplicit-function-declaration] BI_imvcopy(Mpval(m), Mpval(n), A, tlda, bp->Buff); ^ igamn2d_.c:225:7: warning: 'MPI_Type_struct' is deprecated: MPI_Type_struct is superseded by MPI_Type_create_struct in MPI-2.0 [-Wdeprecated-declarations] BI_MPI_Type_struct(i, len, disp, dtypes, &MyType, ierr); ^ In file included from Bconfig.h:20:0, from Bdef.h:8, from igamn2d_.c:1: /usr/lib/openmpi/include/mpi.h:1796:20: note: declared here OMPI_DECLSPEC int MPI_Type_struct(int count, int array_of_blocklengths[], ^ igamn2d_.c:282:6: warning: implicit declaration of function 'BI_ivmcopy' [-Wimplicit-function-declaration] BI_ivmcopy(Mpval(m), Mpval(n), A, tlda, bp2->Buff); ^ igamn2d_.c:284:16: warning: implicit declaration of function 'BI_TransDist' [-Wimplicit-function-declaration] BI_TransDist(ctxt, tscope, Mpval(m), Mpval(n), rA, cA, tldia, ^ mv Cigamn2d_.o igamn2d_.C mpicc.openmpi -o Csgamn2d_.o -c -O4 -DSYSINC -I/usr/lib/openmpi/include -DAdd_ -DBlacsDebugLvl=0 -DUseMpi2 -DCallFromC sgamn2d_.c sgamn2d_.c: In function 'Csgamn2d': sgamn2d_.c:204:7: warning: implicit declaration of function 'BI_smvcopy' [-Wimplicit-function-declaration] BI_smvcopy(Mpval(m), Mpval(n), A, tlda, bp->Buff); ^ sgamn2d_.c:226:7: warning: 'MPI_Type_struct' is deprecated: MPI_Type_struct is superseded by MPI_Type_create_struct in MPI-2.0 [-Wdeprecated-declarations] BI_MPI_Type_struct(i, len, disp, dtypes, &MyType, ierr); ^ In file included from Bconfig.h:20:0, from Bdef.h:8, from sgamn2d_.c:1: /usr/lib/openmpi/include/mpi.h:1796:20: note: declared here OMPI_DECLSPEC int MPI_Type_struct(int count, int array_of_blocklengths[], ^ sgamn2d_.c:283:6: warning: implicit declaration of function 'BI_svmcopy' [-Wimplicit-function-declaration] BI_svmcopy(Mpval(m), Mpval(n), A, tlda, bp2->Buff); ^ sgamn2d_.c:285:16: warning: implicit declaration of function 'BI_TransDist' [-Wimplicit-function-declaration] BI_TransDist(ctxt, tscope, Mpval(m), Mpval(n), rA, cA, tldia, ^ mv Csgamn2d_.o sgamn2d_.C mpicc.openmpi -o Cdgamn2d_.o -c -O4 -DSYSINC -I/usr/lib/openmpi/include -DAdd_ -DBlacsDebugLvl=0 -DUseMpi2 -DCallFromC dgamn2d_.c dgamn2d_.c: In function 'Cdgamn2d': dgamn2d_.c:204:7: warning: implicit declaration of function 'BI_dmvcopy' [-Wimplicit-function-declaration] BI_dmvcopy(Mpval(m), Mpval(n), A, tlda, bp->Buff); ^ dgamn2d_.c:226:7: warning: 'MPI_Type_
Bug#813358: wcsaxes: FTBFS: assert 1 == 0 # where 1 = len([])
Source: wcsaxes Version: 0.6-4 Severity: serious Justification: fails to build from source User: reproducible-bui...@lists.alioth.debian.org Usertags: ftbfs X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org Dear Maintainer, wcsaxes fails to build from source in unstable/amd64: [..] copying wcsaxes/tests/baseline_images/changed_axis_units.png -> build/lib.linux-x86_64-3.4/wcsaxes/tests/baseline_images copying wcsaxes/tests/baseline_images/rcparams.png -> build/lib.linux-x86_64-3.4/wcsaxes/tests/baseline_images copying wcsaxes/tests/baseline_images/curvlinear_grid_patches_image.png -> build/lib.linux-x86_64-3.4/wcsaxes/tests/baseline_images copying wcsaxes/tests/baseline_images/cube_slice_image_lonlat.png -> build/lib.linux-x86_64-3.4/wcsaxes/tests/baseline_images copying wcsaxes/tests/baseline_images/tick_angles.png -> build/lib.linux-x86_64-3.4/wcsaxes/tests/baseline_images copying wcsaxes/tests/baseline_images/image_plot.png -> build/lib.linux-x86_64-3.4/wcsaxes/tests/baseline_images copying wcsaxes/tests/baseline_images/test_axislabels_regression.png -> build/lib.linux-x86_64-3.4/wcsaxes/tests/baseline_images copying wcsaxes/tests/baseline_images/set_coord_type.png -> build/lib.linux-x86_64-3.4/wcsaxes/tests/baseline_images copying wcsaxes/tests/baseline_images/test_noncelestial_angular.png -> build/lib.linux-x86_64-3.4/wcsaxes/tests/baseline_images copying wcsaxes/tests/baseline_images/test_ticks_regression_1.png -> build/lib.linux-x86_64-3.4/wcsaxes/tests/baseline_images copying wcsaxes/tests/baseline_images/coords_overlay.png -> build/lib.linux-x86_64-3.4/wcsaxes/tests/baseline_images copying wcsaxes/tests/baseline_images/direct_init.png -> build/lib.linux-x86_64-3.4/wcsaxes/tests/baseline_images creating build/lib.linux-x86_64-3.4/wcsaxes/tests/data copying wcsaxes/tests/data/2MASS_k_header -> build/lib.linux-x86_64-3.4/wcsaxes/tests/data copying wcsaxes/tests/data/msx_header -> build/lib.linux-x86_64-3.4/wcsaxes/tests/data copying wcsaxes/tests/data/cube_header -> build/lib.linux-x86_64-3.4/wcsaxes/tests/data copying wcsaxes/tests/data/slice_header -> build/lib.linux-x86_64-3.4/wcsaxes/tests/data copying wcsaxes/tests/data/rosat_header -> build/lib.linux-x86_64-3.4/wcsaxes/tests/data /usr/lib/python3/dist-packages/astropy_helpers/setup_helpers.py:102: AstropyDeprecationWarning: Direct use of the adjust_compiler function in setup.py is deprecated and can be removed from your setup.py. This functionality is now incorporated directly into the build_ext command. 'command.', AstropyDeprecationWarning) I: pybuild base:184: /usr/bin/python3 setup.py build running build running build_py creating build/lib.linux-x86_64-3.5 creating build/lib.linux-x86_64-3.5/wcsaxes copying wcsaxes/utils.py -> build/lib.linux-x86_64-3.5/wcsaxes copying wcsaxes/ticks.py -> build/lib.linux-x86_64-3.5/wcsaxes copying wcsaxes/__init__.py -> build/lib.linux-x86_64-3.5/wcsaxes copying wcsaxes/coordinate_range.py -> build/lib.linux-x86_64-3.5/wcsaxes copying wcsaxes/conftest.py -> build/lib.linux-x86_64-3.5/wcsaxes copying wcsaxes/axislabels.py -> build/lib.linux-x86_64-3.5/wcsaxes copying wcsaxes/version.py -> build/lib.linux-x86_64-3.5/wcsaxes copying wcsaxes/coordinates_map.py -> build/lib.linux-x86_64-3.5/wcsaxes copying wcsaxes/settings.py -> build/lib.linux-x86_64-3.5/wcsaxes copying wcsaxes/rc_utils.py -> build/lib.linux-x86_64-3.5/wcsaxes copying wcsaxes/frame.py -> build/lib.linux-x86_64-3.5/wcsaxes copying wcsaxes/wcs_wrapper.py -> build/lib.linux-x86_64-3.5/wcsaxes copying wcsaxes/coordinate_helpers.py -> build/lib.linux-x86_64-3.5/wcsaxes copying wcsaxes/core.py -> build/lib.linux-x86_64-3.5/wcsaxes copying wcsaxes/wcs_utils.py -> build/lib.linux-x86_64-3.5/wcsaxes copying wcsaxes/_astropy_init.py -> build/lib.linux-x86_64-3.5/wcsaxes copying wcsaxes/grid_paths.py -> build/lib.linux-x86_64-3.5/wcsaxes copying wcsaxes/transforms.py -> build/lib.linux-x86_64-3.5/wcsaxes copying wcsaxes/formatter_locator.py -> build/lib.linux-x86_64-3.5/wcsaxes copying wcsaxes/ticklabels.py -> build/lib.linux-x86_64-3.5/wcsaxes creating build/lib.linux-x86_64-3.5/wcsaxes/datasets copying wcsaxes/datasets/__init__.py -> build/lib.linux-x86_64-3.5/wcsaxes/datasets creating build/lib.linux-x86_64-3.5/wcsaxes/tests copying wcsaxes/tests/__init__.py -> build/lib.linux-x86_64-3.5/wcsaxes/tests copying wcsaxes/tests/test_formatter_locator.py -> build/lib.linux-x86_64-3.5/wcsaxes/tests copying wcsaxes/tests/test_frame.py -> build/lib.linux-x86_64-3.5/wcsaxes/tests copying wcsaxes/tests/test_display_world_coordinates.py -> build/lib.linux-x86_64-3.5/wcsaxes/tests copying wcsaxes/tests/test_transform_coord_meta.py -> build/lib.linux-x86_64-3.5/wcsaxes/tests copying wcsaxes/tests/setup_package.py -> build/lib.linux-x86_64-3.5/wcsaxes/tests copying wcsaxes/tests/test_transforms.py -> build/lib.linux
Bug#813359: xserver-xorg-input-aiptek: FTBFS: xf86Aiptek.c:296:17: error: too many arguments to function 'xf86PostKeyEvent'
Source: xserver-xorg-input-aiptek Version: 1:1.4.1-1 Severity: serious Justification: fails to build from source User: reproducible-bui...@lists.alioth.debian.org Usertags: ftbfs X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org Dear Maintainer, xserver-xorg-input-aiptek fails to build from source in unstable/amd64: [..] checking linux/input.h usability... yes checking linux/input.h presence... yes checking for linux/input.h... yes checking if XINPUT is defined... yes checking for XORG... yes checking that generated files are newer than configure... done configure: creating ./config.status config.status: creating Makefile config.status: creating man/Makefile config.status: creating src/Makefile config.status: creating config.h config.status: executing depfiles commands config.status: executing libtool commands dh_auto_build -O--builddirectory=build/ make -j1 make[1]: Entering directory '/home/lamby/temp/cdt.20160201084729.aY0PW5Ttii/xserver-xorg-input-aiptek-1.4.1/build' make all-recursive make[2]: Entering directory '/home/lamby/temp/cdt.20160201084729.aY0PW5Ttii/xserver-xorg-input-aiptek-1.4.1/build' Making all in src make[3]: Entering directory '/home/lamby/temp/cdt.20160201084729.aY0PW5Ttii/xserver-xorg-input-aiptek-1.4.1/build/src' /bin/bash ../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I../../src -I..-fvisibility=hidden -I/usr/include/pixman-1 -I/usr/include/libdrm -I/usr/include/xorg -I/usr/include/X11/dri -Wall -Wpointer-arith -Wmissing-declarations -Wformat=2 -Wstrict-prototypes -Wmissing-prototypes -Wnested-externs -Wbad-function-cast -Wold-style-definition -Wdeclaration-after-statement -Wunused -Wuninitialized -Wshadow -Wmissing-noreturn -Wmissing-format-attribute -Wredundant-decls -Wlogical-op -Werror=implicit -Werror=nonnull -Werror=init-self -Werror=main -Werror=missing-braces -Werror=sequence-point -Werror=return-type -Werror=trigraphs -Werror=array-bounds -Werror=write-strings -Werror=address -Werror=int-to-pointer-cast -Werror=pointer-to-int-cast -fno-strict-aliasing -g -O2 -c -o xf86Aiptek.lo ../../src/xf86Aiptek.c libtool: compile: gcc -DHAVE_CONFIG_H -I. -I../../src -I.. -fvisibility=hidden -I/usr/include/pixman-1 -I/usr/include/libdrm -I/usr/include/xorg -I/usr/include/X11/dri -Wall -Wpointer-arith -Wmissing-declarations -Wformat=2 -Wstrict-prototypes -Wmissing-prototypes -Wnested-externs -Wbad-function-cast -Wold-style-definition -Wdeclaration-after-statement -Wunused -Wuninitialized -Wshadow -Wmissing-noreturn -Wmissing-format-attribute -Wredundant-decls -Wlogical-op -Werror=implicit -Werror=nonnull -Werror=init-self -Werror=main -Werror=missing-braces -Werror=sequence-point -Werror=return-type -Werror=trigraphs -Werror=array-bounds -Werror=write-strings -Werror=address -Werror=int-to-pointer-cast -Werror=pointer-to-int-cast -fno-strict-aliasing -g -O2 -c ../../src/xf86Aiptek.c -fPIC -DPIC -o .libs/xf86Aiptek.o ../../src/xf86Aiptek.c:136:5: warning: initialization discards 'const' qualifier from pointer target type [-Wdiscarded-qualifiers] "BaudRate", "9600", ^ ../../src/xf86Aiptek.c:136:21: warning: initialization discards 'const' qualifier from pointer target type [-Wdiscarded-qualifiers] "BaudRate", "9600", ^ ../../src/xf86Aiptek.c:137:5: warning: initialization discards 'const' qualifier from pointer target type [-Wdiscarded-qualifiers] "StopBits", "1", ^ ../../src/xf86Aiptek.c:137:21: warning: initialization discards 'const' qualifier from pointer target type [-Wdiscarded-qualifiers] "StopBits", "1", ^ ../../src/xf86Aiptek.c:138:5: warning: initialization discards 'const' qualifier from pointer target type [-Wdiscarded-qualifiers] "DataBits", "8", ^ ../../src/xf86Aiptek.c:138:21: warning: initialization discards 'const' qualifier from pointer target type [-Wdiscarded-qualifiers] "DataBits", "8", ^ ../../src/xf86Aiptek.c:139:5: warning: initialization discards 'const' qualifier from pointer target type [-Wdiscarded-qualifiers] "Parity", "None", ^ ../../src/xf86Aiptek.c:139:21: warning: initialization discards 'const' qualifier from pointer target type [-Wdiscarded-qualifiers] "Parity", "None", ^ ../../src/xf86Aiptek.c:140:5: warning: initialization discards 'const' qualifier from pointer target type [-Wdiscarded-qualifiers] "VMin", "1", ^ ../../src/xf86Aiptek.c:140:21: warning: initialization discards 'const' qualifier from pointer target type [-Wdiscarded-qualifiers] "VMin", "1", ^ ../../src/xf86Aiptek.c:141:5: warning: initialization discards 'const' qualifier from pointer target type [-Wdiscarded-qualifiers] "Vtime","10", ^ ../../src/xf86Ai
Bug#812969: libvmime: FTBFS: net_tls_TLSSession.cpp:120:38: error: 'gnutls_certificate_type_set_priority' was not declared in this scope
Dear GnuTLS maintainers, with the new gnutls v3.4 in unstable we hit some old deprecated marked function now as errors while building the libvmime package. ;) libvmime is a reverse dependency for the zarafa groupware we have packaged and is currently waiting in the new queue. The upstream maintainer of libvmime doesn't released a newer version than 0.9.1 and so we have to fight with this old version (released 2010-11-16). Peter Green has submitted a debdiff with a possibly solution that's seen below. I'm not a security expert on those used functions inside libvmime and found a another solution based on suggestions for upgrading to 3.4 [1] and created a patch that's appended. Can you give us a suggestion how to handle this issues? I've seen a similar solution like mine on the samba package upstream [5]. The zarafa suite isn't using this parts of the libvmime package as they connect locally to localhost. But the we have to provide a secure libvmime package. The full FTBFS log can be found here [2] for amd64. The source can be found on [3] and the file that holds the deprecated functions can be viewd on [4]. Thanks and regards Carsten [1] http://www.gnutls.org/manual/html_node/Upgrading-from-previous-versions.html#Upgrading-from-previous-versions [2] https://buildd.debian.org/status/fetch.php?pkg=libvmime&arch=amd64&ver=0.9.1-4%2Bb1&stamp=1453493127 [3] https://anonscm.debian.org/cgit/pkg-giraffe/libvmime.git/tree/ [4] https://anonscm.debian.org/cgit/pkg-giraffe/libvmime.git/tree/src/net/tls/TLSSession.cpp [5] https://lists.samba.org/archive/samba-technical/2015-April/107008.html On Sun, Jan 31, 2016 at 11:33:16PM +, peter green wrote: > > > > net_tls_TLSSession.cpp:120:38: error: > > 'gnutls_certificate_type_set_priority' was not declared in this scope > > (*m_gnutlsSession, certTypePriority); > > ^ > > net_tls_TLSSession.cpp:131:68: error: 'gnutls_protocol_set_priority' was > > not declared in this scope > > res = gnutls_protocol_set_priority(*m_gnutlsSession, protoPriority); > > ^ > > net_tls_TLSSession.cpp:152:61: error: 'gnutls_cipher_set_priority' was > > not declared in this scope > > gnutls_cipher_set_priority(*m_gnutlsSession, cipherPriority); > >^ > > net_tls_TLSSession.cpp:157:55: error: 'gnutls_mac_set_priority' was not > > declared in this scope > > gnutls_mac_set_priority(*m_gnutlsSession, macPriority); > > ^ > > net_tls_TLSSession.cpp:173:53: error: 'gnutls_kx_set_priority' was not > > declared in this scope > > gnutls_kx_set_priority(*m_gnutlsSession, kxPriority); > >^ > > net_tls_TLSSession.cpp:184:71: error: 'gnutls_compression_set_priority' > > was not declared in this scope > > gnutls_compression_set_priority(*m_gnutlsSession, compressionPriority); > > > The gnutls_*_set_priority functions have been removed. According to. > http://www.gnutls.org/manual/html_node/Upgrading-from-previous-versions.html > the replacement is gnutls_priority_set_direct but in this case the settings > used seem > rather outdated anyway, so rather than converting I just removed them. > (so gnutls will use it's defaults). > > I have uploaded my changes to raspbian stretch-staging. Debdiff attached, no > intent to NMU in Debian. > > diff -Nru libvmime-0.9.1/debian/changelog libvmime-0.9.1/debian/changelog > --- libvmime-0.9.1/debian/changelog 2015-09-22 17:33:22.0 + > +++ libvmime-0.9.1/debian/changelog 2016-01-31 18:41:26.0 + > @@ -1,3 +1,9 @@ > +libvmime (0.9.1-4+rpi1) stretch-staging; urgency=medium > + > + * Remove calls to gnutls_*_set_priority > + > + -- Peter Michael Green Sun, 31 Jan 2016 18:41:14 > + > + > libvmime (0.9.1-4) unstable; urgency=medium > >[ Carsten Schoenert ] > diff -Nru libvmime-0.9.1/debian/patches/gnutls3.4.patch > libvmime-0.9.1/debian/patches/gnutls3.4.patch > --- libvmime-0.9.1/debian/patches/gnutls3.4.patch 1970-01-01 > 00:00:00.0 + > +++ libvmime-0.9.1/debian/patches/gnutls3.4.patch 2016-01-31 > 18:41:03.0 + > @@ -0,0 +1,102 @@ > +Description: remove calls to gnutls_*_set_priority > + The gnutls_*_set_priority functions have been removed. According to > + http://www.gnutls.org/manual/html_node/Upgrading-from-previous-versions.html > + the replacement is gnutls_priority_set_direct but the settings used seem > + rather outdated anyway, so rather than converting I just removed them. > + (so gnutls will use it's defaults). > +uthor: Peter Michael Green > + > +--- > +The information above should follow the Patch Tagging Guidelines, please > +checkout http://dep.debian.net/deps/dep3/ to learn about the format. Here > +are templates for supplementary fields that you m
Bug#810568: openexr transition
Control: tags -1 - moreinfo All packages now do compile with newer openexr. blender is in experimental, and thus will need a SU at some point. -M
Bug#813226: tzdata config script ignores /etc/timezone on non-interactive configuration
On 2016-01-31 00:36, YAMADA Tsuyoshi wrote: > Package: tzdata > Version: 2016a-1 > Severity: minor > > Dear Maintainer, > > After tzdata 2016a-1, automated tzdata configuration with > > echo "Asia/Tokyo" > /etc/timezone > dpkg-reconfigure -fnoninteractive tzdata > > does not work. > > With tzdata 2015g-1, it works. > > root@a26eeeb7b8b7:~# date > Sat Jan 30 15:28:54 UTC 2016 > root@a26eeeb7b8b7:~# echo Asia/Tokyo > /etc/timezone > root@a26eeeb7b8b7:~# dpkg-reconfigure -fnoninteractive tzdata > > Current default time zone: 'Asia/Tokyo' > Local time is now: Sun Jan 31 00:29:12 JST 2016. > Universal Time is now: Sat Jan 30 15:29:12 UTC 2016. > > root@a26eeeb7b8b7:~# date > Sun Jan 31 00:29:13 JST 2016 > > But with tzdata 2016a-1, it does not work well. > > root@fdc1139936e4:~# date > Sat Jan 30 15:30:00 UTC 2016 > root@fdc1139936e4:~# echo Asia/Tokyo > /etc/timezone > root@fdc1139936e4:~# dpkg-reconfigure -fnoninteractive tzdata > > Current default time zone: 'Etc/UTC' > Local time is now: Sat Jan 30 15:30:21 UTC 2016. > Universal Time is now: Sat Jan 30 15:30:21 UTC 2016. > > root@fdc1139936e4:~# date > Sat Jan 30 15:30:23 UTC 2016 > > I have found a workaround, deleting /etc/localtime > before running dpkg-reconfigure solves this problem. > > root@fdc1139936e4:~# date > Sat Jan 30 15:30:50 UTC 2016 > root@fdc1139936e4:~# echo Asia/Tokyo > /etc/timezone > root@fdc1139936e4:~# rm /etc/localtime > root@fdc1139936e4:~# dpkg-reconfigure -fnoninteractive tzdata > > Current default time zone: 'Asia/Tokyo' > Local time is now: Sun Jan 31 00:31:15 JST 2016. > Universal Time is now: Sat Jan 30 15:31:15 UTC 2016. > > root@fdc1139936e4:~# date > Sun Jan 31 00:31:18 JST 2016 > > Is this bug of tzdata config script? Or expected behavior? I don't think it is a bug. The correct way to configure the timezone has always been to change /etc/localtime symlink, ie in your case by doing "ln -sf /usr/share/zoneinfo/Asia/Tokyo /etc/localtime". This is what desktop environments do when changing the timezone and it is what systemd expects. Changing /etc/timezone worked in some cases before as we use to store /etc/localtime as a copy of the file instead of a symlink when possible, in order to allow the timezone to be correct without a /usr partition. This is not needed anymore given /usr is now mount from the initramfs when needed. Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net signature.asc Description: PGP signature
Bug#753809: DICOM Vendor ?
It would be interesting to know which system is producing this kind of buggy DICOM file. Full thread: https://groups.google.com/d/msg/comp.protocols.dicom/SkU5_OUSDxE/PZfjvdU3EwAJ It contains a command line (using DCMTK) to cleanup this file, before passing it to stricter implementation (GDCM <= 2.6.3).
Bug#808644: dmtcp: FTBFS
Control: tags -1 patch fixed-upstream Control: forwarded -1 https://github.com/dmtcp/dmtcp/issues/39 Upstream patch here: https://github.com/dmtcp/dmtcp/commit/ed7843cd044b0b37d91beec6cbe63aacb 3f2d68c.patch Issue in upstream bts: https://github.com/dmtcp/dmtcp/issues/39 Note that this seems to fix compilation issue, but there is further down a testsuite problem (though might be unrelated, I did not investigate further) -- tobi
Bug#813356: wish for glob(7)-like matcher
Package: grep Version: 2.20-4 Severity: wishlist Tags: upstream Sometimes I want to match globs instead of regexps. glob(7) explicitly says: "they match filenames, rather than text" I don't see why globs shouldn't be used for text. In bash this is ugly and *SLOW*, e.g. # Print log lines that match no "whitelisted" patterns. while read -r line do if ! [[ line = glob1 || line = glob2 || ... ]] then echo "$line" fi done https://sv.gnu.org/bugs/?group=grep says I must be a "project member", and I'm not.
Bug#813355: kinfocenter_oui.sh exits with non-zero status
Package: kinfocenter Version: 4:5.4.3-1 Severity: normal Hi! Script /var/lib/ieee-data/update.d/kinfocenter_oui.sh contains next lines: if [ "oui.txt" != $(basename "$filename") ]; then exit 1 fi and it is called from monthly cronjob /usr/bin/update-oui, that calls it with these lines: run-parts -a "$BASEDIR" -a oui.txt update.d/ run-parts -a "$BASEDIR" -a iab.txt update.d/ As you can see, on the second line script kinfocenter_oui.sh is called with filename 'iab.txt', and exits with non-zero status, and that causes overall update-oui to finish with error code, which causes bogus cron report to administrator about failed cronjob. -- System Information: Debian Release: stretch/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.3.0-1-amd64 (SMP w/8 CPU cores) Locale: LANG=uk_UA.UTF-8, LC_CTYPE=uk_UA.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages kinfocenter depends on: ii ieee-data 20150531.1 ii libc6 2.21-7 ii libegl1-mesa [libegl1-x11] 11.1.1-2 ii libgl1-mesa-glx [libgl1]11.1.1-2 ii libglu1-mesa [libglu1] 9.0.0-2.1 ii libkf5completion5 5.16.0-1 ii libkf5configcore5 5.16.0-1 ii libkf5configwidgets55.16.0-1 ii libkf5coreaddons5 5.16.0-1 ii libkf5dbusaddons5 5.16.0-1 ii libkf5i18n5 5.16.0-1 ii libkf5iconthemes5 5.16.0-1 ii libkf5kcmutils5 5.16.0-1 ii libkf5kdelibs4support5 5.16.0-1 ii libkf5kiocore5 5.16.0-1 ii libkf5kiowidgets5 5.16.0-1 ii libkf5quickaddons5 5.16.0-1 ii libkf5service-bin 5.16.0-1 ii libkf5service5 5.16.0-1 ii libkf5solid55.16.0-1 ii libkf5waylandclient54:5.4.3-1 ii libkf5widgetsaddons55.16.0-1 ii libkf5xmlgui5 5.16.0-1 ii libpci3 1:3.3.1-1.1 ii libqt5core5a5.5.1+dfsg-13 ii libqt5dbus5 5.5.1+dfsg-13 ii libqt5gui5 5.5.1+dfsg-13 ii libqt5qml5 5.5.1-3 ii libqt5widgets5 5.5.1+dfsg-13 ii libraw1394-11 2.1.1-2 ii libstdc++6 5.3.1-7 ii libx11-62:1.6.3-1 ii plasma-workspace4:5.4.3-1 ii usbutils1:007-4 kinfocenter recommends no packages. kinfocenter suggests no packages. -- no debconf information
Bug#812969: libvmime: FTBFS: net_tls_TLSSession.cpp:120:38: error: 'gnutls_certificate_type_set_priority' was not declared in this scope
Hello Peter, tanks for your feedback! On Sun, Jan 31, 2016 at 11:33:16PM +, peter green wrote: > The gnutls_*_set_priority functions have been removed. According to. > http://www.gnutls.org/manual/html_node/Upgrading-from-previous-versions.html > the replacement is gnutls_priority_set_direct but in this case the settings > used seem > rather outdated anyway, so rather than converting I just removed them. > (so gnutls will use it's defaults). As the gnutls library is really security related and we currently need the library in Debian only as build dependency for Zarafa Groupware I raised the needed changes on our discussion mailing list [1] there also guys from the Zarafa team subscribed. I'm a bit conservative in doing changes that may have a impact that can't overview right now. But thanks for your diff, we will und have to discuss the best solution, I'm intended to involve the gnutls maintainers for getting a good working solution. > I have uploaded my changes to raspbian stretch-staging. Debdiff attached, no > intent to NMU in Debian. We haven't think about a NMU tag for libvmime. :) [1] https://lists.alioth.debian.org/pipermail/pkg-giraffe-discuss/Week-of-Mon-20160125/000219.html Regards Carsten
Bug#812961: jessie-pu: package php-net-ldap2/2.0.12-1+deb8u1
Hi Adam, On Sun, Jan 31, 2016 at 06:07:26PM +, Adam D. Barratt wrote: > Control: tags -1 + moreinfo > > On Thu, 2016-01-28 at 11:13 +0700, Prach Pongpanich wrote: > > > > Please accept the fixes for php5/5.6.17+dfsg-0+deb8u1 upgrade break > > php-net-ldap2 in jessie (#812892). > > The BTS metadata for #812892 suggests that it also affects the package > in unstable. If that's correct, please fix unstable first; if not, > please fix the metadata by adding an appropriate fixed version. > > Please let us know once one of the above has occurred. > This bug not found in unstable, I already fixed the metadata for #812892. Regards, Prach signature.asc Description: PGP signature
Bug#813354: Ricochet im UI doesn't display characters correctly
Package: ricochet-imVersion: 1.1.1-2+b1When launching the program by command `ricochet`, the font displayed on UI (as shown at http://imgur.com/8kfxw9p) is meaningless (characters can't be recognized and change the language setting still display black block characters). I am using Debian GNU/ Linux stretch/sid, kernel 4.0.0-2-rt-686-pae, and locale en_US.UTF-8$ which ricochet/usr/bin/ricochet$ type ricochetricochet is /usr/bin/ricochet$ dpkg --search /usr/bin/ricochetricochet-im: /usr/bin/ricochet$ dpkg --list ricochet-im Desired=Unknown/Install/Remove/Purge/Hold| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)||/ Name Version Architecture Description+++-==---=ii ricochet-im 1.1.1-2+b1 i386 anonymous metadata-resistant inst$ dpkg --status ricochet-imPackage: ricochet-imStatus: install ok installedPriority: optionalSection: netInstalled-Size: 4524Maintainer: Debian Privacy Tools Maintainers Architecture: i386Source: ricochet-im (1.1.1-2)Version: 1.1.1-2+b1Depends: libasan2 (>= 5), libc6 (>= 2.4), libgcc1 (>= 1:4.1.1), libgl1-mesa-glx | libgl1, libprotobuf9v5, libqt5core5a (>= 5.5.0), libqt5gui5 (>= 5.1.0), libqt5multimedia5 (>= 5.0.2), libqt5network5 (>= 5.0.2), libqt5qml5 (>= 5.1.0), libqt5quick5 (>= 5.0.2), libqt5widgets5 (>= 5.0.2), libssl1.0.2 (>= 1.0.2d), libstdc++6 (>= 5.2), libubsan0 (>= 5), qml-module-qtquick-controls, qml-module-qtquick-dialogs, qml-module-qtmultimedia, tor (>= 0.2.6)Description: anonymous metadata-resistant instant messaging Ricochet is an experiment with a different kind of instant messaging that doesn't trust anyone with your identity, your contact list, or your communications. . - You can chat without exposing your identity (or IP address) to anyone - Nobody can discover who your contacts are or when you talk (metadata-free) - There are no servers or operators to compromise that could access your information - It's cross-platform and easy for non-technical users . Ricochet is a peer-to-peer instant messaging system built on Tor hidden services. Your login is your hidden service address, and contacts connect to you (not an intermediate server) through Tor. The rendezvous system makes it extremely hard for anyone to learn your identity from your address. . Ricochet is not affiliated with or endorsed by The Tor Project. For more information, you can read about Tor and learn about Ricochet's design or protocol (or the old protocol). Everything is open-source and open to contribution. . **This software is an experiment**. It hasn't been audited or formally reviewed by anyone. Security and anonymity are difficult topics, and you should carefully evaluate your risks and exposure with any software. Do not rely on Ricochet for your safety.Homepage: https://github.com/ricochet-im/ricochet
Bug#803253: mosh: diff for NMU version 1.2.5-1.1
Thank you. I'm not sure what the etiquette is here -- I am fine with this proposed change (we have taken the patch upstream but have not released a new version of Mosh or an updated package yet). I'm happy to let your NMU go through as-is, but if you would like me to do a 1.2.5-2 upload that cherry-picks this patch, also fine. -Keith On Sun, Jan 31, 2016 at 7:43 AM, Laurent Bigonville wrote: > Control: tags 803253 + pending > > Dear maintainer, > > I've prepared an NMU for mosh (versioned as 1.2.5-1.1) and > uploaded it to DELAYED/5. Please feel free to tell me if I > should delay it longer. > > Regards. > diff -Nru mosh-1.2.5/debian/changelog mosh-1.2.5/debian/changelog > --- mosh-1.2.5/debian/changelog 2015-07-23 08:45:07.0 +0200 > +++ mosh-1.2.5/debian/changelog 2016-01-31 16:19:12.0 +0100 > @@ -1,3 +1,11 @@ > +mosh (1.2.5-1.1) unstable; urgency=medium > + > + * Non-maintainer upload. > + * debian/mosh.maintscript: Fix /etc/bash_completion.d/mosh removal, > thanks > +to for the patch Jakub Wilk (Closes: #803253) > + > + -- Laurent Bigonville Sun, 31 Jan 2016 16:19:09 > +0100 > + > mosh (1.2.5-1) unstable; urgency=low > >* Version 1.2.5 released. > diff -Nru mosh-1.2.5/debian/mosh.maintscript > mosh-1.2.5/debian/mosh.maintscript > --- mosh-1.2.5/debian/mosh.maintscript 2015-07-23 08:45:07.0 +0200 > +++ mosh-1.2.5/debian/mosh.maintscript 2016-01-31 16:14:18.0 +0100 > @@ -1 +1 @@ > -rm_conffile /etc/bash_completion.d/mosh 1.2.5~ -- "$@" > +rm_conffile /etc/bash_completion.d/mosh 1.2.5~ >
Bug#806169: Error granting trust: Couldn't find a place to store the pinned certificate
> "SDJ" == Sergio Durigan Junior writes: SDJ> I don't believe it's necessary. It mentions .xinitrc, which is a file SDJ> that lives under the $USER directory. IMO, every time I read >> >> I only have .xsession. SDJ> Sure, the same applies to .xsession. Best to say explicitly. You never know how dumb (me) some users are.
Bug#806169: Error granting trust: Couldn't find a place to store the pinned certificate
On Sunday, January 31 2016, 積丹尼 Dan Jacobson wrote: >> "SDJ" == Sergio Durigan Junior writes: > > SDJ> management, and gcr needs gnome-keyring. This is indeed a hassle if > SDJ> you're running GNOME directly (as is your case, and mine), but > > I'm not sure I'm running GNOME directly. Pstree says I mean you're not using GNOME as your Desktop Environment. > SDJ> I don't believe it's necessary. It mentions .xinitrc, which is a file > SDJ> that lives under the $USER directory. IMO, every time I read > > I only have .xsession. Sure, the same applies to .xsession. >>> And on https://selfsigned.notyours.dk:444/menu.gif clicking trust this >>> website does nothing. Though I can now see my taipower site thankfully. > > SDJ> What do you mean "does nothing"? Were you able to access the website > SDJ> after clicking the button? You should. > > I see > Technical Information (for support personnel) > > Error Code: 408. The operation timed out. The remote server did not > respond within the set time allowed. The server might be unavailable > at this time. Try again later or contact the server > administrator. (12002) Oh, I see; that's because the URL is not working anymore. Another bug that should be reported... -- Sergio GPG key ID: 237A 54B1 0287 28BF 00EF 31F4 D0EB 7628 65FC 5E36 Please send encrypted e-mail if possible http://sergiodj.net/ signature.asc Description: PGP signature
Bug#806169: Error granting trust: Couldn't find a place to store the pinned certificate
> "SDJ" == Sergio Durigan Junior writes: SDJ> management, and gcr needs gnome-keyring. This is indeed a hassle if SDJ> you're running GNOME directly (as is your case, and mine), but I'm not sure I'm running GNOME directly. Pstree says ew Description: pstree SDJ> I don't believe it's necessary. It mentions .xinitrc, which is a file SDJ> that lives under the $USER directory. IMO, every time I read I only have .xsession. >> And on https://selfsigned.notyours.dk:444/menu.gif clicking trust this >> website does nothing. Though I can now see my taipower site thankfully. SDJ> What do you mean "does nothing"? Were you able to access the website SDJ> after clicking the button? You should. I see Technical Information (for support personnel) Error Code: 408. The operation timed out. The remote server did not respond within the set time allowed. The server might be unavailable at this time. Try again later or contact the server administrator. (12002)
Bug#806169: Error granting trust: Couldn't find a place to store the pinned certificate
On Saturday, January 30 2016, 積丹尼 Dan Jacobson wrote: >> "SDJ" == Sergio Durigan Junior writes: > > SDJ> The latest Midori package contains a new Recommends for gnome-keyring. > SDJ> Is this enough to fix the bug for you? > > OK in ~/.xsession I put > m=`gnome-keyring-daemon -start` # https://bugs.debian.org/806169 midori > if test $? -eq 0 > then export $m > else echo $0: install gnome-keyring first.|mail -s $0 $USER > fi #What a hassle. Other browsers don't need this. The "problem" is that Midori now uses (since 0.4.7) gcr for certificate management, and gcr needs gnome-keyring. This is indeed a hassle if you're running GNOME directly (as is your case, and mine), but fortunately the fix is "easy" enough. What I can do is write a few more instructions on README.Debian on how to install/enable gnome-keyring. Other than that, there's not much that can be done without actively altering the user's configuration files. > P.S., on > http://midori-browser.org/faqs/#error_granting_trustcouldn_t_find_a_place_to_store_the_imported_certificate > we see 'gnome-keyring –startup' > # gnome-keyring -startup > usage: gnome-keyring command [options] > commands: certificate-exception > import > version Right, that's an error, I'll file it upstream. > Also there it should say if we should be root or not. I don't believe it's necessary. It mentions .xinitrc, which is a file that lives under the $USER directory. IMO, every time I read instructions on a FAQ, and unless otherwise stated, I assume I do not need to be root. > And on https://selfsigned.notyours.dk:444/menu.gif clicking trust this > website does nothing. Though I can now see my taipower site thankfully. What do you mean "does nothing"? Were you able to access the website after clicking the button? You should. -- Sergio GPG key ID: 237A 54B1 0287 28BF 00EF 31F4 D0EB 7628 65FC 5E36 Please send encrypted e-mail if possible http://sergiodj.net/ signature.asc Description: PGP signature
Bug#803909: Assertion `bm->bus->dma->aiocb == ((void *)0)' failed
Restarted VM and then allowed Windows 7 to start normally. Was able to complete defrag C: /H /U /V /X in cmd dos box. Not reproducible. Any interesting comments regarding assertion? Same command line as before: qemu-system-x86_64 -enable-kvm -cpu host -localtime -usb -boot c -drive \ file=win7.qcow2,if=ide,index=0,media=disk,format=qcow2,detect-zeroes=unmap,discard=unmap \ -usbdevice tablet -net nic,vlan=0,model=rtl8139 -net user,vlan=0 \ -soundhw ac97 -m 2047M
Bug#813343: JPEG 2000 -support is missing
On Mon, 01 Feb 2016, +00:43:47 EET (UTC +0200), Bastien ROUCARIES pressed some keys: > On Sun, Jan 31, 2016 at 10:23 PM, Juhapekka Tolvanen wrote: > > > > Package: imagemagick-6.q16 > > Version: 8:6.8.9.9-5 > > Severity: important > > > > Wikipedia claims that ImageMagick can support JPEG 2000: > > > > https://en.wikipedia.org/wiki/JPEG_2000?oldformat=true#Application_support > > > > I downloaded testfiles from here: > > > > https://github.com/uclouvain/openjpeg-data > > > > When trying to watch them with ImageMagick all I got was error messages: > > > > juhtolv@heresy:/home/juhtolv/tmp7/openjpeg-data-master/input/conformance % > > display file1.jp2 > > display: no decode delegate for this image format `JP2' @ > > error/constitute.c/ReadImage/501. > > [1]3181 exit 1 display file1.jp2 > > juhtolv@heresy:/home/juhtolv/tmp7/openjpeg-data-master/input/conformance % > > display p0_01.j2k > > display: no decode delegate for this image format `J2K' @ > > error/constitute.c/ReadImage/501. > > [1]3245 exit 1 display p0_01.j2k > > Did you install exra package ? Yes, and it had no effect at all. Problem still remains. -- Juhapekka ”naula” Tolvanen * http colon slash slash iki dot fi slash juhtolv ”Nää biisit ei oo susta vaik vähän oiski, tunnet mut nii hyvin, et tiedät etten mä voisi ja vaik ne sanat ei ikin tulisi takasi, nii battleräppärinki on oltava joskus alasti.” Paperi T
Bug#813353: "GraphicsCriticalError: |[0][GFX1]: Unknown cairo format 3" on startup with VNC
Package: iceweasel
Version: 44.0-1
Severity: normal
Tags: patch
Forwarded: https://bugzilla.mozilla.org/show_bug.cgi?id=1222171
Dear Maintainer,
iceweasel 44.0-1 crashes on startup with VNC.
> Crash Annotation GraphicsCriticalError: |[0][GFX1]: Unknown cairo format
> 3[GFX1]: Unknown cairo format 3
> segmentation fault (core dumped) iceweasel
iceweasel 43.0.4-1 is ok.
GraphicsCriticalError: |[0][GFX1]: Unknown cairo format 3
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1538724
"GraphicsCriticalError: |[0][GFX1]: Unknown cairo format 3" on startup on Linux
machine with VNC "screen"
https://bugzilla.mozilla.org/show_bug.cgi?id=1222171
rebuilt with upstream patch https://hg.mozilla.org/try/raw-rev/79382e397d1d ,
iceweasel startup normally with VNC.
--
Regards,
dai
GPG Fingerprint = 0B29 D88E 42E6 B765 B8D8 EA50 7839 619D D439 668E
-- System Information:
Debian Release: stretch/sid
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1,
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.3.0-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=ja_JP.UTF-8, LC_CTYPE=ja_JP.UTF-8 (charmap=UTF-8) (ignored: LC_ALL
set to ja_JP.UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages iceweasel depends on:
ii debianutils 4.7
ii fontconfig2.11.0-6.3
ii libasound21.0.29-1
ii libatk1.0-0 2.18.0-1
ii libc6 2.21-7
ii libcairo2 1.14.6-1
ii libdbus-1-3 1.10.6-1
ii libdbus-glib-1-2 0.106-1
ii libevent-2.0-52.0.21-stable-2+b1
ii libffi6 3.2.1-4
ii libfontconfig12.11.0-6.3
ii libfreetype6 2.6.1-0.1
ii libgcc1 1:5.3.1-7
ii libgdk-pixbuf2.0-02.32.3-1.2
ii libglib2.0-0 2.46.2-3
ii libgtk2.0-0 2.24.29-1
ii libhunspell-1.3-0 1.3.3-3+b2
ii libnspr4 2:4.11-1
ii libnss3 2:3.21-1
ii libpango-1.0-01.38.1-1
ii libsqlite3-0 3.10.2-1
ii libstartup-notification0 0.12-4
ii libstdc++65.3.1-7
ii libvpx3 1.5.0-2
ii libx11-6 2:1.6.3-1
ii libxcomposite11:0.4.4-1
ii libxdamage1 1:1.1.4-2+b1
ii libxext6 2:1.3.3-1
ii libxfixes31:5.0.1-2+b2
ii libxrender1 1:0.9.9-2
ii libxt61:1.1.5-1
ii procps2:3.3.11-3
ii zlib1g1:1.2.8.dfsg-2+b1
Versions of packages iceweasel recommends:
pn gstreamer1.0-libav
ii gstreamer1.0-plugins-good 1.6.3-1
Versions of packages iceweasel suggests:
pn fonts-lmodern
pn fonts-stix | otf-stix
ii libcanberra0 0.30-2.1
pn libgnomeui-0
ii libgssapi-krb5-2 1.13.2+dfsg-4
pn mozplugger
-- no debconf information
# HG changeset patch
# User Nicholas Nethercote
# Date 1447161392 -3600
# Node ID 79382e397d1d7ca352e4480548af4efa083d423b
# Parent c492cddc3f2f0578d1cfcf12f54482cb79f9b07f
Bug 1222171 - Re-establish equivalence between gfxImageFormat and
cairo_format_t. r=mstange.
It would be nice to add static assertions for this equivalence but I don't want
to have to include cairo.h in gfxTypes.h. (Indeed, that's why
gfxImageFormatToCairoFormat and gfxCairoFormatToImageFormat are macros in the
first place).
diff --git a/gfx/thebes/gfxTypes.h b/gfx/thebes/gfxTypes.h
--- a/gfx/thebes/gfxTypes.h
+++ b/gfx/thebes/gfxTypes.h
@@ -42,34 +42,38 @@ enum class gfxBreakPriority {
eNoBreak = 0,
eWordWrapBreak,
eNormalBreak
};
/**
* The format for an image surface. For all formats with alpha data, 0
* means transparent, 1 or 255 means fully opaque.
+ *
+ * XXX: it's vital that the values here match the values in cairo_format_t,
+ * otherwise gfxCairoFormatToImageFormat() and gfxImageFormatToCairoFormat()
+ * won't work.
*/
enum class gfxImageFormat {
- ARGB32, ///< ARGB data in native endianness, using premultiplied alpha
- RGB24, ///< xRGB data in native endianness
- A8, ///< Only an alpha channel
- RGB16_565, ///< RGB_565 data in native endianness
+ ARGB32= 0, ///< ARGB data in native endianness, using premultiplied alpha
+ RGB24 = 1, ///< xRGB data in native endianness
+ A8= 2, ///< Only an alpha channel
+ RGB16_565 = 4, ///< RGB_565 data in native endianness
Unknown
};
// XXX: temporary
// This works because the gfxImageFormat enum is defined so as to match the
-// _cairo_format enum.
+// cairo_format_t enum.
#define gfxCairoFormatToImageFormat(aFormat) \
((gfxImageFormat)aFormat)
// XXX: temporary
// This works because the gfxImageFormat enum is defined so as to match the
-// _cairo_format enum.
+// cairo_format_t enum.
#define gfxImageFormatToCair
Bug#813352: iroffer: FTBFS when using -pie and -Werror=format-security
Package: iroffer Version: 1.4.b03 Severity: important Tags: upstream Dear Maintainer, The iroffer does not build when using the -pie and -Werror=format-security flags. To verify this issue, do the following changes in debian/rules file: -- --- rules.orig 2016-02-01 01:09:45.731874079 -0200 +++ rules 2016-02-01 01:10:56.763872059 -0200 @@ -1,7 +1,7 @@ #!/usr/bin/make -f #export DH_VERBOSE=1 -export DEB_BUILD_MAINT_OPTIONS = hardening=+all,-pie +export DEB_BUILD_MAINT_OPTIONS = hardening=+all %: dh $@ @@ -11,7 +11,7 @@ override_dh_auto_build: dh_auto_build -- LDFLAGS="$(LDFLAGS)" CPPFLAGS="$(CPPFLAGS)" \ -CFLAGS="-O2 -g -fstack-protector-strong -Wformat" +CFLAGS="$(CFLAGS)" override_dh_auto_install: $(MAKE) install INSDIR=$(CURDIR)/debian/iroffer/usr/bin -- Regards, Eriberto
Bug#813279: Mousepad closes unexpectedly after renaming file
Sorry, a strange error happened, this should go to the package thunar, not mousepad! Can you please delete this report? Thanks On Sun, Jan 31, 2016 at 5:25 AM, cruncher wrote: > Package: mousepad > Version: 0.4.0-3 > Severity: important > Tags: upstream > > When i rename a file, mousepad closes unexpectedly. > I can create a file, rename it to anything, rename it again, and again, > until > it crashes. > Like that i can reproduce it, so if i can provide further information to > help > you solve this let me know. > > > > -- System Information: > Debian Release: stretch/sid > APT prefers unstable > APT policy: (500, 'unstable') > Architecture: amd64 (x86_64) > Foreign Architectures: i386 > > Kernel: Linux 4.3.0-1-amd64 (SMP w/2 CPU cores) > Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) > Shell: /bin/sh linked to /bin/dash > Init: systemd (via /run/systemd/system) > > Versions of packages mousepad depends on: > ii dconf-gsettings-backend [gsettings-backend] 0.24.0-2 > ii libc62.21-7 > ii libglib2.0-0 2.46.2-3 > ii libgtk2.0-0 2.24.29-1 > ii libgtksourceview2.0-02.10.5-2 > ii libpango-1.0-0 1.38.1-1 > > mousepad recommends no packages. > > mousepad suggests no packages. > > -- no debconf information >
Bug#803909: Assertion `bm->bus->dma->aiocb == ((void *)0)' failed
With just the C: drive. defrag C: /H /U /V /X in cmd dos box seems to upset it. Was hoping to use this to clean up raw image before making it sparse. These raw images can be placed on a USB stick. Normally defrag is just a time waster. Now using qcow2 for general use on desktop. [ 1039.091722] kvm: zapping shadow pages for mmio generation wraparound Linux pdc 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt20-1+deb8u3 (2016-01-17) x86_64 GNU/Linux qemu-system-x86_64 -enable-kvm -cpu host -localtime -usb -boot c -drive \ file=win7.qcow2,if=ide,index=0,media=disk,format=qcow2,detect-zeroes=unmap,discard=unmap \ -usbdevice tablet -net nic,vlan=0,model=rtl8139 -net user,vlan=0 \ -soundhw ac97 -m 2047M
Bug#813351: cannot tell chapter number on Info index
Package: exim4-doc-info Version: 4.86-1 Severity: wishlist /usr/share/doc/exim4-config/README.Debian.gz says Multiple smarthost entries are permitted, semicolon separated. Each of the hosts is tried, in the order specified (See Exim specification, chapter 20.5). But in (info "(spec) Top") there are no chapter numbers. One must do ESC 20 CTRL+N from the top line, and RET, getting us to a info page called 20 The manualroute router * (info "(spec) The manualroute router") But is this really the chapter 20 we are looking for? file:///usr/share/doc/exim4-doc-html/spec_html/index.html file:///usr/share/doc/exim4-doc-html/spec_html/ch-the_manualroute_router.html Shows it is! So what is the problem? On the info pages you need to say Chapter 20 The manualroute router * Which probably means this will become 20 Chapter 20 The manualroute router * Anyway be sure on (info "(spec) Top") one can tell which page is Chapter 20!
Bug#813290: openalrp: Please print frame number to stderr?
Should be resolved in this commit. If JSON is enabled, it doesn't print the Frame #. https://github.com/openalpr/openalpr/commit/da4a84360cddbce5bbc69edc89b304b5875548bb
Bug#812738: openalpr: Mistakes Hurd for Mac OS X in timer.h code
This is added in this commit: https://github.com/openalpr/openalpr/commit/dc6d077fad681beee7e065903bbb0b37251f1f62
Bug#746194: freecad: Rotating rotationally symetric part components changes result
Bug reporter confirmed in private mail that the problem is resolved. Thanks!
Bug#813350: joe: :include ignores other commands in the file
Package: joe Version: 4.1-2 Severity: normal Hi! /usr/share/doc/joe/README.Debian claims you can ":include /etc/joe/jstarrc" to avoid having to copy the entire file and to make it work over upgrades. However, doing so seems to ignore the entirety of ~/.jstarrc Let's say we want to replace -rmsg %S Row %4r Col %3c %t Ctrl-J for help with -rmsg %S Row %4r Col %3c %A The following ~/.jstarrc = :include /etc/joe/jstarrc -rmsg %S Row %4r Col %3c %A = makes "Ctrl-J for help" show up instead of the Unicode code. so does = -rmsg %S Row %4r Col %3c %A :include /etc/joe/jstarrc = so it's not a matter of "first setting stays". Only copying the entire file as ~/.jstarrc and editing it makes the setting work.
Bug#723113: Moving mumble subwindow moves the main window too
A couple of years ago when this bug was filed (before I became the maintainer) I remember testing and I think mumble 1.2.3-349-g315b5f5-2.2 showed this bug in some window managers / desktop environments but not others -- the bug wasn't shown when running KDE but I believe did when running MATE, IIRC. Today I note that mumble 1.2.12-1 doesn't show the issue when running MATE, nor any other WM/DE I have loaded (I tried MATE, LXDE, Xfce4, KDE5). Is this bug fixed now? -- Chris -- Chris Knadle chris.kna...@coredump.us
Bug#600276: mumble: Need to switch speech synthesis language according to translations
Mumble upstream has made a commit which will fix this bug in the upcoming 1.3 release. https://github.com/mumble-voip/mumble/commit/1aae05eba12b06f8aa3604bae84738edb4fbb892 -- Chris -- Chris Knadle chris.kna...@coredump.us
Bug#812611: u-boot should have update-u-boot automatic in postinst like update-grub
On Jan 31, 2016, at 2:42 PM, Rick Thomas wrote: > boot from internal MMC flash that is soldered to the mainboard. Sorry, *not* "MMC flash". That *should* be "MTD flash". see: http://www.linux-mtd.infradead.org/faq/general.html for an explanation of the difference. Enjoy! Rick
Bug#813349: joe: jstar crashes on startup if old config is present
Package: joe
Version: 4.1-2
Severity: important
If a ~/.jstarrc from a previous version exists, jstar will segfault on startup.
This happens even for unmodified configs (ie, a straight copy of
/etc/joe/jstarrc into ~/.jstarrc).
Prior versions complained in the presence of an outdated config, but you
just removed that check (#560182). But in any case, response to even
complete garbage should be an error message rather than a segfault.
Here's a backtrace from the package rebuilt with "noopt":
Program received signal SIGSEGV, Segmentation fault.
0x00417dbc in kcpy (dest=0x7ffb60, src=0x7eca20) at kbd.c:326
326 if (((KMAP *)l->map)->what == 1) {
(gdb) bt full
#0 0x00417dbc in kcpy (dest=0x7ffb60, src=0x7eca20) at kbd.c:326
l = 0x7fd410
#1 0x00417de5 in kcpy (dest=0x7feba0, src=0x7ec2c0) at kbd.c:328
k = 0x7ffb60
l = 0x7ecd30
#2 0x00423c1c in procrc (cap=0x79f110, name=0x79c7c0
"/home/kilobyte/.jstarrc") at rc.c:233
x = 9
c = 13
ch = 32 ' '
o = 0x6a7ea0
context = 0x7feba0
current_menu = 0x0
buf = ":inherit main\000\000t
windows\n\000slide\t\tMWUP\000\000s\n\000lock\n\000story\n\000:\",blkmove,nextword\t^[
t\000\000\"man -P cat -S 2:3 \"\n\000language,\".\",charset,\" -x -c $SPLTMP
/dev/tty;tr -d <$SPLTMP '012';/bin/rm $SPLTMP\","...
buf1 =
"man\000_find\000\000s\000\000\000\000\001\000\000\000\000\000\000\000\362q\021\367\377\177\000\000\000\000\000\000\000\000\000\000\b",
'\000' ,
"\300\330\377\377\377\177\000\000\030\347z\000\000\000\000\000\002\000\000\000\000\000\000\000S\276\025\031\000\000\000\000\002\000\000\000\000\000\000\000\002\000\000\000\000\000\000\000\210\245F\000\000\000\000\000\030\347z\000\000\000\000\000\020\347z\000\000\000\000\000\001\000\000\000\000\000\000\000\256l\025\367\377\177\000\000\271\366G\000\000\000\000\000\340\333\377\377\377\177\000\000X\335\377\377\377\177\000\000\230\366G\000\000\000\000\000X\335\377\377\377\177\000\000\256\237\022\367\377\177\000\000ع\375\367\377\177\000\000p"...
fd = 0x79caa0
line = 956
err = 1
#3 0x0041b894 in main (argc=1, real_argv=0x7fffe098,
envv=0x7fffe0a8) at main.c:430
cap = 0x79f110
argv = 0x7fffe098
sbuf = {st_dev = 27, st_ino = 4987591, st_nlink = 1, st_mode = 33188,
st_uid = 1000,
st_gid = 1000, __pad0 = 0, st_rdev = 0, st_size = 32198, st_blksize =
4096, st_blocks = 64,
st_atim = {tv_sec = 1452846042, tv_nsec = 514591374}, st_mtim =
{tv_sec = 1452846042,
tv_nsec = 514591374}, st_ctim = {tv_sec = 1454283346, tv_nsec =
75858768},
__glibc_reserved = {0, 0, 0}}
s = 0x79c7c0 "/home/kilobyte/.jstarrc"
t = 0x79c790 "/etc/joe/jstarrc"
time_rc = 1454267703
run = 0x7a4bc0 "jstar"
n = 0x0
opened = 0
omid = 0
backopt = 4205184
c = 0
-- System Information:
Debian Release: stretch/sid
APT prefers unstable-debug
APT policy: (500, 'unstable-debug'), (500, 'unstable'), (150, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.4.0-x32 (SMP w/6 CPU cores)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
Versions of packages joe depends on:
ii libc62.21-7
ii libncurses5 6.0+20151024-2
ii libtinfo56.0+20151024-2
joe recommends no packages.
joe suggests no packages.
-- no debconf information
Bug#812969: libvmime: FTBFS: net_tls_TLSSession.cpp:120:38: error: 'gnutls_certificate_type_set_priority' was not declared in this scope
net_tls_TLSSession.cpp:120:38: error: 'gnutls_certificate_type_set_priority' was not declared in this scope (*m_gnutlsSession, certTypePriority); ^ net_tls_TLSSession.cpp:131:68: error: 'gnutls_protocol_set_priority' was not declared in this scope res = gnutls_protocol_set_priority(*m_gnutlsSession, protoPriority); ^ net_tls_TLSSession.cpp:152:61: error: 'gnutls_cipher_set_priority' was not declared in this scope gnutls_cipher_set_priority(*m_gnutlsSession, cipherPriority); ^ net_tls_TLSSession.cpp:157:55: error: 'gnutls_mac_set_priority' was not declared in this scope gnutls_mac_set_priority(*m_gnutlsSession, macPriority); ^ net_tls_TLSSession.cpp:173:53: error: 'gnutls_kx_set_priority' was not declared in this scope gnutls_kx_set_priority(*m_gnutlsSession, kxPriority); ^ net_tls_TLSSession.cpp:184:71: error: 'gnutls_compression_set_priority' was not declared in this scope gnutls_compression_set_priority(*m_gnutlsSession, compressionPriority); The gnutls_*_set_priority functions have been removed. According to. http://www.gnutls.org/manual/html_node/Upgrading-from-previous-versions.html the replacement is gnutls_priority_set_direct but in this case the settings used seem rather outdated anyway, so rather than converting I just removed them. (so gnutls will use it's defaults). I have uploaded my changes to raspbian stretch-staging. Debdiff attached, no intent to NMU in Debian. diff -Nru libvmime-0.9.1/debian/changelog libvmime-0.9.1/debian/changelog --- libvmime-0.9.1/debian/changelog 2015-09-22 17:33:22.0 + +++ libvmime-0.9.1/debian/changelog 2016-01-31 18:41:26.0 + @@ -1,3 +1,9 @@ +libvmime (0.9.1-4+rpi1) stretch-staging; urgency=medium + + * Remove calls to gnutls_*_set_priority + + -- Peter Michael Green Sun, 31 Jan 2016 18:41:14 + + libvmime (0.9.1-4) unstable; urgency=medium [ Carsten Schoenert ] diff -Nru libvmime-0.9.1/debian/patches/gnutls3.4.patch libvmime-0.9.1/debian/patches/gnutls3.4.patch --- libvmime-0.9.1/debian/patches/gnutls3.4.patch 1970-01-01 00:00:00.0 + +++ libvmime-0.9.1/debian/patches/gnutls3.4.patch 2016-01-31 18:41:03.0 + @@ -0,0 +1,102 @@ +Description: remove calls to gnutls_*_set_priority + The gnutls_*_set_priority functions have been removed. According to + http://www.gnutls.org/manual/html_node/Upgrading-from-previous-versions.html + the replacement is gnutls_priority_set_direct but the settings used seem + rather outdated anyway, so rather than converting I just removed them. + (so gnutls will use it's defaults). +uthor: Peter Michael Green + +--- +The information above should follow the Patch Tagging Guidelines, please +checkout http://dep.debian.net/deps/dep3/ to learn about the format. Here +are templates for supplementary fields that you might want to add: + +Origin: , +Bug: +Bug-Debian: https://bugs.debian.org/ +Bug-Ubuntu: https://launchpad.net/bugs/ +Forwarded: +Reviewed-By: +Last-Update: + +--- libvmime-0.9.1.orig/src/net/tls/TLSSession.cpp libvmime-0.9.1/src/net/tls/TLSSession.cpp +@@ -111,78 +111,6 @@ TLSSession::TLSSession(ref
Bug#813335: mdadm: Upgrade from jessie to testing breaks boot with raid on lvm2
> Still subject to test: > - moving/copying /usr/share/initramfs-tools/scripts/local-top/mdadm to > local-bottom > or > - changing the pre-requisites for mdadm to depend on lvm2 for my use > case (madadm on lvm2 instead of lvm2 on mdadm) Tested with a script mdadm-late with pre-req lvm2, no success. I am currently running out of ideas, where to search for the missing activation of the md devices, any help appreciated. pgpkhq0Ti3r58.pgp Description: Digitale Signatur von OpenPGP
Bug#805010: ping: VTK 6.3.0 released
Hello Anton,
well, it turns out that there is no version 6.2.1, so I've added only
the upstream patch to the package.
> OK, just push into git.
Since I'm not (yet) in the debian-science group I don't have write
access to the vtk6 packaging git. Therefore, I've attached the change
set as a patch against the package source tree:
> diffstat vtk6-6.2.0-dfsg1-6-fix-racecondition.patch
changelog | 7
patches/96_concurrent_vtkLookupTableMapData_fix.patch | 198++
patches/series| 1
3 files changed, 206 insertions(+)
--
The 96_ patch applies cleanly, and I'm test building now (right now at
50% well within the Tcl bindings).
Best,
Gert
commit 88349595a1410bbb8670fbd31550c38297f15b68
Author: Gert Wollny
Date: Sun Jan 31 17:40:33 2016 +0100
Add patch to fix race condition
diff --git a/debian/changelog b/debian/changelog
index f8003d3..e2927d0 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+vtk6 (6.2.0+dfsg1-6.1) UNRELEASED; urgency=medium
+
+ * Non-maintainer upload
+ * d/patched/96 Fix race condition in vtkLookupTableMapdata
+
+ -- Gert Wollny Sun, 31 Jan 2016 17:37:41 +0100
+
vtk6 (6.2.0+dfsg1-6) unstable; urgency=medium
* [18cd92a] Add missing libaec-dev to build-depends.
diff --git a/debian/patches/96_concurrent_vtkLookupTableMapData_fix.patch b/debian/patches/96_concurrent_vtkLookupTableMapData_fix.patch
new file mode 100644
index 000..242b2f3
--- /dev/null
+++ b/debian/patches/96_concurrent_vtkLookupTableMapData_fix.patch
@@ -0,0 +1,198 @@
+Description: Fix crash in function called from multiple threads
+ vtkLookupTableMapData() was not thread safe and could lead to
+ crashes when accessed from multiple threads. Added a mutex around
+ the logic to determine if the color table size needed to be
+ increased.
+ .
+ Added a multi-threaded test that crashes on occasion prior
+ to this patch, but does not crash with this patch applied.
+Author: Cory Quammen
+Last-Update: 2016-01-31
+Bug: http://www.vtk.org/Bug/view.php?id=15365
+
+diff --git a/Common/Core/Testing/Cxx/CMakeLists.txt b/Common/Core/Testing/Cxx/CMakeLists.txt
+--- a/Common/Core/Testing/Cxx/CMakeLists.txt
b/Common/Core/Testing/Cxx/CMakeLists.txt
+@@ -32,6 +32,7 @@ vtk_add_test_cxx(${vtk-module}CxxTests tests
+ TestGarbageCollector.cxx
+ # TestInstantiator.cxx # Have not enabled instantiators.
+ TestLookupTable.cxx
++ TestLookupTableThreaded.cxx
+ TestMath.cxx
+ TestMinimalStandardRandomSequence.cxx
+ TestNew.cxx
+diff --git a/Common/Core/Testing/Cxx/TestLookupTableThreaded.cxx b/Common/Core/Testing/Cxx/TestLookupTableThreaded.cxx
+new file mode 100644
+index 000..4330609
+--- /dev/null
b/Common/Core/Testing/Cxx/TestLookupTableThreaded.cxx
+@@ -0,0 +1,57 @@
++/*=
++
++ Program: Visualization Toolkit
++ Module:TestLookupTableThreaded.cxx
++
++ Copyright (c) Ken Martin, Will Schroeder, Bill Lorensen
++ All rights reserved.
++ See Copyright.txt or http://www.kitware.com/Copyright.htm for details.
++
++ This software is distributed WITHOUT ANY WARRANTY; without even
++ the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR
++ PURPOSE. See the above copyright notice for more information.
++
++=*/
++
++#include "vtkLookupTable.h"
++#include "vtkMultiThreader.h"
++#include "vtkNew.h"
++
++namespace {
++
++vtkLookupTable * lut;
++
++VTK_THREAD_RETURN_TYPE ThreadedMethod(void *)
++{
++ int numberOfValues = 25;
++ double* input = new double[numberOfValues];
++ unsigned char* output = new unsigned char[4*numberOfValues];
++ int inputType = VTK_DOUBLE;
++ int inputIncrement = 1;
++ int outputFormat = VTK_RGBA;
++
++ lut->MapScalarsThroughTable2(input, output, inputType, numberOfValues,
++ inputIncrement, outputFormat);
++
++ delete[] input;
++ delete[] output;
++
++ return VTK_THREAD_RETURN_VALUE;
++}
++
++} // end anonymous namespace
++
++int TestLookupTableThreaded(int, char* [])
++{
++ lut = vtkLookupTable::New();
++ lut->SetNumberOfTableValues( 1024 );
++
++ vtkNew threader;
++ threader->SetSingleMethod( ThreadedMethod, NULL );
++ threader->SetNumberOfThreads( 4 );
++ threader->SingleMethodExecute();
++
++ lut->Delete();
++
++ return EXIT_SUCCESS;
++}
+diff --git a/Common/Core/vtkLookupTable.cxx b/Common/Core/vtkLookupTable.cxx
+index 53d9663..2d90054 100644
+--- a/Common/Core/vtkLookupTable.cxx
b/Common/Core/vtkLookupTable.cxx
+@@ -18,6 +18,7 @@
+ #include "vtkBitArray.h"
+ #include "vtkMath.h"
+ #include "vtkMathConfigure.h"
++#include "vtkMutexLock.h"
+ #include "vtkObjectFactory.h"
+ #include "vtkStringArray.h"
+ #include "vtkVariantArray.h"
+@@ -81,6 +82,8 @@ vtkLookupTable::vtkLookupTable(int sze, int ext)
+ this->Scale = VTK_SCALE_LINEAR;
+
+ this
Bug#813311: humble repositories shoud be humble
Hi, On Sun, Jan 31, 2016 at 02:48:52PM +0100, Geert Stappers wrote: > * consider non debian repositories trojan horses [There is a certain irony to read that in a mail signed by an expired key (not online as I can see now, but in the debian-keyring which is where I import from).] > Want I wish is an apt sources.list line like > deb http://nicelookingproject.com/debian version main pl:foo > will only install package foo from the nice looking project repository If at all, that would indeed be a []-option as that is backward compatible with older apt versions (and a proper field in deb822-style sources of course), but… > The idea behind the request/wish is to give users of our system > more control on how far they open a backdoor ... … that is the wrong reason for it. As soon as you have added a repository you have to trust that repository COMPLETELY. Limiting which packages to install from this repository is no protection at all as you can do everything in any package. Why should I go to the trouble of providing a bad 'apt' package, if I can just convince the user to add my repo to install 'awesome-game' which just rsyncs the entire machine to "the cloud" or adds a new user + ssh server or or or… What you could do with it is perhaps a shortcut for pinning, showing an additional message/require an additional confirmation, if a package is picked from that repository, or actually all of that in different features… Best regards David Kalnischkies signature.asc Description: PGP signature
Bug#748936: Re: Bug#748936: apt doesnt understand architecture wildcards
On Wed, Jan 20, 2016 at 01:39:45PM +, Colin Watson wrote: > On Wed, Jan 20, 2016 at 12:31:52PM +0100, Balint Reczey wrote: > > On 06/04/2014 03:41 AM, Guillem Jover wrote: > > > * Other programs could “easily” use dpkg-architecture to check for > > >identity or a match. (This poses problems for programs that do not > > > > I think making apt call dpkg-architecture for matching would be a good > > way of ensuring consistency with dpkg. Caching the results in a hash > > table would make matching even faster than it is currently. > > dpkg-architecture is in dpkg-dev, so not reliably usable at run-time. Also, apt is trying to remain largely independent of the low-level package manager, so bluntly depending on it wouldn't be good, but … … apt could survive this (for now) as these architecture specifications can at the moment only be encountered in a) build-dependencies of source packages (effecting via python-apt also presumably stuff like dak) b) the commandline like 'apt install libfoo:linux-* foo:linux-any' (and aptitude uses it, too, for this) So, we could do that without too much pain, while keeping a fallback around for cases in which we don't have dpkg-architecture around for whatever reason as it doesn't effect apts primary operation (but might effect the primary operation of other tools which would need to be tested first). I wonder through if we aren't creating the debian version of a tar bomb (xkcd#1168) and to illustrate that a little quiz: dpkg-architecture -ai386 -ii386 true dpkg-architecture -ai386 -ilinux-i386 true dpkg-architecture -ai386 -iany-i386 true dpkg-architecture -aarmhf -iarmhf true dpkg-architecture -aarmhf -ilinux-armhf true dpkg-architecture -aarmhf -iany-armhf false dpkg-architecture -aarmhf -iarm false dpkg-architecture -aarmhf -ilinux-arm false dpkg-architecture -aarmhf -iany-arm true Now, given we want to go to -- lets see: dpkg-architecture -aarmhf -iany-linux-arm true dpkg-architecture -aarmhf -iany-any-arm true dpkg-architecture -aarmhf -ignu-any-arm false dpkg-architecture -aarmhf -ignueabihf-any-arm true And to cool off, think about what matches any-arm, linux-any, and if gnu-any is even supported and if what that matches… Truth be told, I would have died on 'any-armhf' already even through that is "obvious" as 'linux-armhf' is interpreted as a literal architecture, while 'any-armhf' is a pattern (just that neither dpkg nor the policy highlight that such a difference exists explicitly). Anyway, I somehow doubt it will be a good idea to trouble mere mortals with the difference between gnu and gnueabihf for matching proposes, so I wonder why we have to trouble them with the difference of armhf and arm depending on if that specification is a literal architecture or an architecture pattern – especially if the two are different only for some architectures… I would personally be more happy with any-armhf working (and a special case letting arm match all of the arms). So, I actually like how apt behaves currently as it just makes more sense in my head to expand armhf to gnu-linux-armhf and match it against gnu-any-armhf instead of gnueabihf-linux-arm and and gnueabihf-any-arm, but so be it – it tends to be more important to have a consistent answer in Debian than to keep me sane… (yeah, I know, that triplet makes perfect sense if you know history, Debian and arm – I just don't). I am therefore going to happily accept any patch flying my way implementing architecture wildcards differently if need be, but I am not going to do it myself mainly because I expect that to have fallout – not in apt, but in things using apt – and I don't have the energy (or the rights) to deal with such things efficiently. Best regards David Kalnischkies signature.asc Description: PGP signature
Bug#803197: gnutls library re-init clobbers fd closed by application
On Sat, Jan 30, 2016 at 03:51:54PM -0800, Ryan Tandy wrote: Hi gnutls team, I realized, unfortunately after sending that, that this: please consider that SOGo and Sope do not actually use gnutls and are not even aware that it is being loaded is totally incorrect. Therefore I have canceled my post to the gnutls list (it was still awaiting moderation) and will follow up with Sope upstream about calling gnutls_global_init after the mass-fd-closing, as recommended by the gnutls documentation.
Bug#812611: u-boot should have update-u-boot automatic in postinst like update-grub
On Jan 31, 2016, at 11:37 AM, Kilian Krause wrote: > If you have the impression that "most" of the > ARM systems out there are only equipped with a single boot device that's not > removable, please do give a list. Otherwise, unbricking a vfat or ext4 > partition on a PC should be piece of cake. I agree that installing U-boot to a removable μSD is, as you say, "a piece of cake" for most Linux users. And as long as you keep an old, working, μSD around, you're safe enough if you know what you're doing. Except for three things: 1) Not all machines that run U-boot have their boot firmware on removable media. I know of at least two fairly popular, though admittedly old, armel architecture series of machines, each with several models -- SheevaPlug and OpenRD -- all of which boot from internal MMC flash that is soldered to the mainboard. I believe there are others as well. Modern machines are less likely to be that way, but I'm not willing to bet that the upcoming IoT generation will follow that trend. If manufacturers can save a few pennies by soldering the boot ROM, they probably will -- even if it inconveniences a few of us Linux hackers. 2) We're talking about auto-updating, not about a manual process that involves pulling out the old μSD and replacing it with a new one that you have prepared off-line. In those circumstances, the risk of corrupting the only working copy is not small. 3) The users of such devices can hardly be expected to be very hardware/software/firmware sophisticated, regardless of whether the boot firmware is on removable media. I know a lot of people who might want a smart thermostat, but I wouldn't trust more than a tiny handful of them with the man page for the dd command and a μSD card to recover from a U-boot auto-update that went catastrophically wrong. So, if the feature is optional, and the default is OFF, do what you like. But I would recommend for most users to leave the feature turned off. Just my two cents worth... Rick
Bug#813327: linux-image-3.16.0-4-amd64: cryptroot + VIA padlock fails with message from testmgr.c
Control: tag -1 moreinfo Control: severity -1 important On Sun, 2016-01-31 at 16:03 +0100, Carsten Wolff wrote: > Package: src:linux > Version: 3.16.7-ckt20-1+deb8u3 > Severity: normal > > Hi, > > I'm not at all sure I'm filing this against the right package. Maybe > cryptsetup, maybe linux, ... > > After upgrading this system from wheezy to jessie, unlocking the cryptroot > from > initrd with padlock-aes and padlock-sha loaded stopped working. After entering > the passphrase, cryptsetup fails with a message like > "cryptsetup check that kernel supports aes-cbc-essiv:sha265" > > In dmesg, there's another message: > [ 233.196927] alg: skcipher: Result buffer corruption in chunk test 1 on > encryption at page 0 for cbc-aes-padlock: 32 bytes: > [ 233.196998] : 4f 1c 0e cd 0b 96 fd bf 26 50 95 5f 63 a6 7e eb > [ 233.197007] 0010: f2 01 6e 42 a4 8f 6f 86 d3 c6 17 85 4a d4 1d 71 > [ 233.202194] device-mapper: table: 254:0: crypt: Error allocating crypto tfm > [ 233.202259] device-mapper: ioctl: error adding target to table > > Things I found out so far: > - booting with latest wheezy kernel (initrd updated by jessie): works, with > padlock support. > - from initrd, rmmod padlock-aes and padlock-sha, then modprobe sha256 and > cbc, > then luksOpen: works (slower, of course). > - The code generating the "alg: skcipher:"-message is in crypto/testmgr.c and > it seems, these lines have only be changed in one commit between 3.2 and > 3.16: > > https://github.com/torvalds/linux/commit/08d6af8c160b6bd9b21a3177e2b1bebc72a21041 > > Any ideas? That suggests a regression in the padlock-aes driver, although I don't see any functional changes there. As a workaround, you can blacklist it by adding "blacklist=padlock-aes" to the kernel command line. I wonder whether the compiler version makes a difference. Does the 3.16 kernel in the wheezy-backports suite behave any differently? Ben. -- Ben Hutchings Larkinson's Law: All laws are basically false. signature.asc Description: This is a digitally signed message part
Bug#813278: minidlna: scanner crashes on invalid flac files
On Sun, Jan 31, 2016 at 10:04:06PM +0300, Alexander Gerasiov wrote: > Please use current version from testing (or backports). I believe you > will like it more, then 1.1.2 with hotfixes. The version in backports has the fix and it's working great. Thanks!
Bug#813339: isc-dhcp-server: Update to 4.3.3-7 today makes isc-dhcp-server unable to work
On Sun, 31 Jan 2016 19:34:22 + Russel Winder wrote: > I aptitude upgraded the machine running my DHCP server at around > 2016-01-31T17:18 which included an upgrade > to isc-dhcp-(server,common,client). Since this update the server will not > start. Restarting just causes it > to exit. The variable to define which interface the dhcpd runs on has changed, but unfortunately the contents of /etc/default/isc-dhcp-server were not adapted at the same time. You need to change INTERFACES="..." to INTERFACESv4="..." to be able to start the DHCP server again. And I guess this bug is not just important but of severity "grave". Grüße, Sven.
Bug#813237: transition: ruby2.3
On Sat, Jan 30, 2016 at 04:18:16PM -0200, Antonio Terceiro wrote: > I am filing this bug now to keep this transition under the radar of > both the Release and Ruby teams. Of course I meant "on the radar", not under. ;-) signature.asc Description: PGP signature
Bug#813311: humble repositories shoud be humble
Hi, On Sun, Jan 31, 2016 at 03:35:49PM +0100, Simon Richter wrote: > > I also think that we shouldn't encourage non-Debian repositories too > much. It makes sense for fast-moving projects like Jenkins who refactor > their entire codebase every three months, but I'd really prefer upstream > authors to be involved in the long term support. > That is the idea of getting non-Debian repostories to behave humble. Currently is an extra repository a trojan horse that is inside the city wall. Nicelookingproject might be very tempted to push / enforce their modified packages to get "foo" working without putting effort in the rest of the eco-system they are using. Groeten Geert Stappers -- Leven en laten leven
Bug#805010: ping: VTK 6.3.0 released
2016-01-31 23:25 GMT+01:00 Gert Wollny : > Hello Anton, > > in that case I'll prepare an upload for 6.2.1, since this already fixes > the bug, could be uploaded without passing through NEW, and shouldn't > need much work. With this we would at least get this fix into testing > without a vtk-7 transition. > OK, just push into git. > Since 6.3.0 breaks some things, i.e. legacy code was removed and with > this itksnap required some fixes, directly moving to vtk-7 later on > really makes more sense, but I wonder whether vtk 6 and 7 should co > -exist in Stretch, whether we should push for updating all to vtk-7, > Well, I think it would be better to update ParaView first, which is outdated in Debian. VTK 7 for Stretch is an open question for now. Thanks Anton
Bug#805010: ping: VTK 6.3.0 released
Hello Anton, in that case I'll prepare an upload for 6.2.1, since this already fixes the bug, could be uploaded without passing through NEW, and shouldn't need much work. With this we would at least get this fix into testing without a vtk-7 transition. Since 6.3.0 breaks some things, i.e. legacy code was removed and with this itksnap required some fixes, directly moving to vtk-7 later on really makes more sense, but I wonder whether vtk 6 and 7 should co -exist in Stretch, whether we should push for updating all to vtk-7, As for co-maintaining - I'll see what I can do, but so far I'm only DM, which means I will need at least sponsoring. Best, Gert
Bug#813344: wx3.0-i18n and trustedqsl: error when trying to install together
Agreed: clearly trustedqsl's fault (they're in the upstream tarball for some reason!). I'll fix it post-haste. -Kamal
Bug#813343: JPEG 2000 -support is missing
On Sun, Jan 31, 2016 at 10:23 PM, Juhapekka Tolvanen wrote: > > Package: imagemagick-6.q16 > Version: 8:6.8.9.9-5 > Severity: important > > Wikipedia claims that ImageMagick can support JPEG 2000: > > https://en.wikipedia.org/wiki/JPEG_2000?oldformat=true#Application_support > > I downloaded testfiles from here: > > https://github.com/uclouvain/openjpeg-data > > When trying to watch them with ImageMagick all I got was error messages: > > juhtolv@heresy:/home/juhtolv/tmp7/openjpeg-data-master/input/conformance % > display file1.jp2 > display: no decode delegate for this image format `JP2' @ > error/constitute.c/ReadImage/501. > [1]3181 exit 1 display file1.jp2 > juhtolv@heresy:/home/juhtolv/tmp7/openjpeg-data-master/input/conformance % > display p0_01.j2k > display: no decode delegate for this image format `J2K' @ > error/constitute.c/ReadImage/501. > [1]3245 exit 1 display p0_01.j2k Did you install exra package ? > > > -- System Information: > Debian Release: 8.3 > APT prefers stable-updates > APT policy: (500, 'stable-updates'), (500, 'proposed-updates'), (500, > 'stable') > Architecture: i386 (i686) > > Kernel: Linux 4.3.0-0.bpo.1-686-pae (SMP w/1 CPU core) > Locale: LANG=fi_FI.utf8, LC_CTYPE=fi_FI.utf8 (charmap=UTF-8) > Shell: /bin/sh linked to /bin/dash > Init: systemd (via /run/systemd/system) > > Versions of packages imagemagick-6.q16 depends on: > ii hicolor-icon-theme 0.13-1 > ii libc6 2.19-18+deb8u2 > ii libmagickcore-6.q16-2 8:6.8.9.9-5 > ii libmagickwand-6.q16-2 8:6.8.9.9-5 > > Versions of packages imagemagick-6.q16 recommends: > ii ghostscript 9.06~dfsg-2+deb8u1 > pn libmagickcore-6.q16-2-extra > ii netpbm 2:10.0-15.2 > > Versions of packages imagemagick-6.q16 suggests: > pn autotrace > ii cups-bsd [lpr] 1.7.5-11+deb8u1 > ii curl 7.38.0-4+deb8u3 > ii enscript 1.6.5.90-2+b1 > ii ffmpeg 10:2.6.5-dmo1 > ii gimp 2.8.14-1+b1 > ii gnuplot5 [gnuplot] 5.0.1+dfsg1-2~bpo8+1 > pn grads > pn graphviz > ii groff-base 1.22.2-8 > pn hp2xx > ii html2ps 1.0b7-1 > pn imagemagick-doc > ii libwmf-bin 0.2.8.4-10.3+deb8u1 > ii mplayer 3:1.1.1+20150226+svn37375-dmo5 > ii mplayer2 [mplayer] 1:2.0~git20130903-dmo7 > pn povray > pn radiance > ii sane-utils 1.0.24-8 > ii texlive-binaries [texlive-base-bin] 2014.20140926.35254-6 > pn transfig > pn ufraw-batch > ii xdg-utils1.1.0~rc1+git20111210-7.4 > > -- no debconf information > > -- > Juhapekka ”naula” Tolvanen * http colon slash slash iki dot fi slash juhtolv > ”Perustuu tositapahtumii, tai ainaki tosi todelle tuntuvii unii. Älä ota > tätä oikein. Sä tiedät et mä oon hyvin huono kuuntelemaa toiveit. Siks sori, > jos mä oon liian avoin, mut räpis on vaa liikaa sanoi. Ei mitä sanoo, vaa > mitä jättää sanomatta. Jokainen säe ku pakomatka.” Paperi T >
Bug#812844: 812844 upower segfault on my ARM laptop
Found in upstream bug tracker: https://bugs.freedesktop.org/show_bug.cgi?id=93095
Bug#813319: [Aptitude-devel] Bug#813319: aptitude: customizing output: "%O" switch breaks the search
Control: retitle -1 aptitude: No error message and no output at all if unknown escape sequence is used with -F Control: reopen -1 Control: found -1 0.7.5-3 Hi, Axel Beckert wrote: > Florian Zieboll wrote: > > Package: aptitude > > Version: 0.6.11-1+b1 […] > > The "%O" switch for "aptitude -F" does not work, tested with Debian/i386, > > Devuan/amd64 and Armbian/armhf, all Jessie. While e.g. > > No wonder: "%O" only got introduced very recently in 0.7.5-1. It also > works fine with that version. after having had some conversation with Florian by private mail, we came to the conclusion that his bug report was caused by the following two real issues: * The documentation on https://aptitude.alioth.debian.org/ only covers the newest version of aptitude. We might want to put up documentation also for other versions in currently supported Debian releases. * Even on Debian unstable, "aptitude -F '%X' search '?installed'" just exits with return code 255, but gives no error message at all and hence causes confusion about what happened if a user tries escape sequences only supported by newer versions of aptitude or if there's a typo in an escape sequence. The latter definitely should be fixed in aptitude. The former is a nice to have in our documentation update infrastructure at https://anonscm.debian.org/cgit/aptitude/aptitude-documentation-fetcher.git/ Regards, Axel -- ,''`. | Axel Beckert , http://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
Bug#813344: wx3.0-i18n and trustedqsl: error when trying to install together
Control: reassign -1 trustedqsl Control: affects -1 wx3.0-i18n On Sun, Jan 31, 2016 at 10:30:15PM +0100, Ralf Treinen wrote: > Package: trustedqsl,wx3.0-i18n > Version: trustedqsl/2.2-1 > Version: wx3.0-i18n'3.0.2+dfsg-1.2@all, wx3.0-i18n/3.0.2+dfsg-1 > Severity: serious > User: trei...@debian.org > Usertags: edos-file-overwrite > Here is a list of files that are known to be shared by both packages > (according to the Contents file for sid/amd64, which may be > slightly out of sync): > > /usr/share/locale/de/LC_MESSAGES/wxstd.mo > /usr/share/locale/es/LC_MESSAGES/wxstd.mo > /usr/share/locale/fr/LC_MESSAGES/wxstd.mo > /usr/share/locale/it/LC_MESSAGES/wxstd.mo > /usr/share/locale/ja/LC_MESSAGES/wxstd.mo > > This bug has been filed against both packages. If you, the maintainers of > the two packages in question, have agreed on which of the packages will > resolve the problem please reassign the bug to that package. You may then > also register in the BTS that the other package is affected by the bug. Looking at these files in trustedsql, they're i18n from wxWidgets 2.5.2. Clearly this is a bug in trustedqsl - wx should contain its own i18n, other packages should not. Cheers, Olly
Bug#813348: isc-dhcp-server: drop_privileges during config test fails in some cases
Package: isc-dhcp-server Version: 4.3.3-5 Severity: minor As part of a move to continuous integration, I am looking to add dhcpd.conf syntax checks to our testing. as I am using travis-ci.org a quick install of isc-dhcp-server and a quick run of `/usr/sbin/dhcpd -t -cf ./dhcpd.conf` looked to be the easiest solution. It works fine locally but fails on Travis with `drop_privileges: could not set group id: Operation not permitted`. Any help would be appreciated. -- System Information: Debian Release: stretch/sid APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'testing'), (500, 'stable') Architecture: i386 (i686) Kernel: Linux 4.2.0-1-686-pae (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages isc-dhcp-server depends on: ii debconf [debconf-2.0] 1.5.58 ii debianutils4.5.1 ii libc6 2.21-6 ii libdns-export100 1:9.9.5.dfsg-12.1 ii libirs-export911:9.9.5.dfsg-12.1 ii libisc-export951:9.9.5.dfsg-12.1 ii lsb-base 9.20160110 Versions of packages isc-dhcp-server recommends: ii isc-dhcp-common 4.3.3-5 ii policycoreutils 2.4-3 Versions of packages isc-dhcp-server suggests: pn isc-dhcp-server-ldap -- Configuration Files: /etc/dhcp/dhcpd.conf changed [not included] /etc/logcheck/ignore.d.server/isc-dhcp-server [Errno 13] Permission denied: u'/etc/logcheck/ignore.d.server/isc-dhcp-server' -- debconf information excluded
Bug#813285: debian-installer: Error in DHCP
On Sun, Jan 31, 2016 at 12:34:51PM +0300, ioann@gmail.com wrote: > On Sunday 31 January 2016 10:32:02 Ben Hutchings wrote: > > On Sun, 2016-01-31 at 09:15 +0300, ioann sys wrote: > > > > > And this device can not recive IP-address. My router using option: > > > "Address Reservation". > > > > Some Realtek Ethernet cards require non-free firmware to make a > > reliable connection. > > > > Guys, I still have to be supplemented? :-) > I'm telling you, that was faced with installing Debian on a physical machine > in UEFI mode. A router that uses add-in "Address Reservation", can not tell > the installer to Debian ip address. But if you enter manually - that all is > well. At least - I can write you. Frankly, I don't understand the problem. I do understand manual config was needed and that working DHCP is expected. And I do understand that an unreliable connection can make DHConfigP fail. I wonder what the effect of router option "Address Reservation" is. I think it is 'A router that uses add-in "Address Reservation", can not tell the installer to Debian ip address.' that I don't understand. > > Did you include this firmware? > How i can include firmware, when i install OS? https://duckduckgo.com/html?q=debian+install+firmware+non-free and please report back. ( on "Address Reservation", non-free firmware or both ) Groeten Geert Stappers -- Leven en laten leven signature.asc Description: Digital signature
Bug#813347: inadyn: fails to run as daemon
Package: inadyn Version: 1.99.4-1 Severity: important Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? clean install, just tryed to run as daemon * What exactly did you do (or not do) that was effective (or ineffective)? chown debian-inadyn.debian-inadyn /var/run/inadyn What was the outcome of this action? daemon started without problems *** End of the template - remove these template lines *** -- System Information: Debian Release: 8.3 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: armhf (armv7l) Kernel: Linux 4.4.0-1-osmc (SMP w/4 CPU cores; PREEMPT) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) (ignored: LC_ALL set to C) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages inadyn depends on: ii adduser 3.113+nmu3 ii libc62.19-18+deb8u2 inadyn recommends no packages. inadyn suggests no packages. -- Configuration Files: /etc/inadyn.conf [Errno 13] Permission denied: u'/etc/inadyn.conf' -- no debconf information
Bug#812848: mailutils: FTBFS: libmu_auth.so: undefined reference to `gnutls_mac_set_priority'
Package: libmailutils4 Version: 1:2.99.98-2+b2 Severity: grave Followup-For: Bug #812848 -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 In fact, on a sid box with the recently landed gnutls28 3.4.8-2 which seem to lack gnutls_mac_set_priority(), aptitude happily installs mailutils but mail.mailutils actually fails to launch: $ mail.mailutils mail.mailutils: symbol lookup error: /usr/lib/x86_64-linux-gnu/libmu_auth.so.4: undefined symbol: gnutls_mac_set_priority That is, the current version of mailutils is unusable with gnutls28 3.4.8-2. So I changed the severity to "grave". - -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 4.3.0-1-amd64 (SMP w/2 CPU cores) Locale: LANG=ja_JP.UTF-8, LC_CTYPE=ja_JP.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages libmailutils4 depends on: ii guile-2.0-libs 2.0.11+1-10+b1 ii libc62.21-7 ii libgc1c2 1:7.4.2-7.3 ii libgnutls30 3.4.8-2 ii libgsasl71.8.0-8+b1 ii libkyotocabinet16v5 1.2.76-4.1 ii libldap-2.4-22.4.42+dfsg-2+b2 ii libltdl7 2.4.2-1.11 ii libmysqlclient18 5.6.28-1 ii libpam0g 1.1.8-3.2 ii libpython2.7 2.7.11-3 ii mailutils-common 1:2.99.98-2 libmailutils4 recommends no packages. libmailutils4 suggests no packages. - -- no debconf information -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBAgAGBQJWrmKeAAoJENU+ddTERR/CX0YP/2IGgp9sUr69gomuTmIKtyvt +qduMxgVBaO9uDhcblbuQSGS6/Qh4y+q9LvHvBfO2kdLACWk1InG3QXMzz4NrodK pmKPxBobD+17BDF4me9T7+Hp2xkwoZ7K6FpHkMrTwXcVVaTVwMk5x0RUXf+oVsUG 6Ax4wmxc1p7wPbhFDQugIlNj0XEDEqFczwSEb2mZpKxRsUdOZJVWzcsWB8YbTH1K vhveX+DJFEWROGHNq76G3Fcd8QYD22uCi92Aggfj3iCDMlybv4WiLPGzOwJIERJK KDBtSxdcxZFuIM0kvt2qkY7Y6e+NF9/qL7s5yaN94NyY28ZhmwJK4hOViUnPFjK8 7mUZ9PQNuinfqnuLi9nsHrLNftiGuPQ1tiWTYInaCbXozk3K7EQ1QpBIWKAx61oI osf8pMaA+iAYAUnSnomkciB4eM7o+GO63DLvp/Mv3ho0f8UxI0xKXY4VypI4VfyT 8gMb7nuTvU2tM4p+oInXekh35GmLo/IF1b0NMWzvqhoCrn+CIb3khhm3CHpcua+A USeK1wTAmtrRupfdCEpSgdzwLuS2Fg5eWntYCYy8t+rMl5QRM0nWP0nWW3S2tgLI f68qXVwGBbnz48uwTiAPHQ+N2TDHOBN1mVMTsSXfyIUAJucoZG97tNzLNVuPbLCO RXkOVQ4ZVkMFu3n1Kq+1 =X4Oo -END PGP SIGNATURE-
Bug#812723: Wontfix
control: tags -1 + wontfix control: block -1 by 720903
Bug#813346: pius option -S is wrong in the manpage
Package: pius Version: 2.2.1-2 Severity: normal Dear Maintainer, The manpage for pius is written by Debian. The -S option is incorrectly documented. The manpage says thay -S is an alias for --mail-tls and will make pius use STARTTLS when talking to the SMTP server. However, pius --help shows that -S is equal to --no-mail-tls and will, instead, not use STARTTLS when talking to the SMTP server. Also, there is no --mail-tls option at all. As a consequence, the documentation for -u states that -S is implied. However, using -u and -S simultaneously will, instead, turn off -S, as shown by the following warning: > NOTE: -u is present, turning off -S. Thank you. -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.2.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages pius depends on: ii gnupg 1.4.19-6 ii gnupg2 2.1.9-1 ii python 2.7.9-1 pn python:any pius recommends no packages. pius suggests no packages. -- no debconf information
Bug#812611: u-boot should have update-u-boot automatic in postinst like update-grub
Hi Rick, On Mon, Jan 25, 2016 at 08:13:04PM -0800, Rick Thomas wrote: ... > If something goes wrong with installing grub, you can boot from a CD or > via ethernet and recover or re-install. > If something goes wrong with installing u-boot, you have bricked your > device. The only recourse is J-tag. Not fun at all! Especially when your boot device is a SD or microSD card, I don't see why J-tag would be anywhere near what you need to recover. Even when a system usually runs off an eMMC my impression is that most devices out there still would allow booting off the SD cards slot if you only inserted a properly formatted card. T.b.h. I don't really see the risk you try to outline here (for the platforms I have). If you have the impression that "most" of the ARM systems out there are only equipped with a single boot device that's not removable, please do give a list. Otherwise, unbricking a vfat or ext4 partition on a PC should be piece of cake. > Installing u-boot is something that should only be undertaken very > carefully if you know what you're doing and are prepared to recover from a > mishap. Doing it automatically every time there's an update is not wise. Well, let's assume this: 1.) We've got a growing platform (i.e. current popcon isn't anywhere near what we expect to have in the next 3-4 year - read: lifespan of next stable). And we're not talking about the one single box in a lab or being your one-and-only private server plattform. We're talking about larger deployments where you would *want* to have unattended-upgrades and needrestart and alike mechanisms to take certain tasks off your shoulders (which is what I assume/hope IoT will look like). 2.) We're talking about a Debian stretch being stable (or maybe even what comes after stretch) - i.e. the u-boot package does only receive maintenance and security updates. 3.) You're installing u-boot on a platform that you very well know and where the procedure for updating u-boot is clearly outlined, i.e. no fancy magic, e.g. just a plain dd file into constant partition. 4.) Assume that we have security hole in u-boot that needs fixing. Debian security is putting together a DSA and the backported security fix for the stable release version. 5.) The admin of each and every system has had the chance to enable auto-updates for u-boot if they feel this a good thing for them under the configuration they run (e.g. booting from uSD card). The default of u-boot (for now) shall safely remain that auto-updates aren't enabled (unless of course the maintainer feels that there's reason to default otherwise on a given installation). In this scenario I would think DSA is much happier to just roll out the fix as-is compared to what we have now. Updating u-boot in jessie will catch at best 30%, probably rather 3% (or even less) due to the lack of people understand they need this update *and* knowing how to manually install it. The part of which platforms and setups can be considered auto-upgrade-safe would be something I'd leave for further discussion once we have a hook mimic in place and have some first experiences (and maybe some bugreports). So, to summarize: all I'm asking for is a hook that I can configure willingly (if I feel confident enough) to enable this auto-updating for my systems, in case there'd be any security issues with u-boot in the future and ensure I don't forget to enable/install them. Best, Kilian signature.asc Description: Digital signature
Bug#813339: isc-dhcp-server: Update to 4.3.3-7 today makes isc-dhcp-server unable to work
Package: isc-dhcp-server Version: 4.3.3-7 Severity: important Dear Maintainer, I aptitude upgraded the machine running my DHCP server at around 2016-01-31T17:18 which included an upgrade to isc-dhcp-(server,common,client). Since this update the server will not start. Restarting just causes it to exit. I tried the ln -s /etc/dhcp/dhcpd.conf /etc/dhcpd.conf thing but that didn't work. -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.3.0-1-amd64 (SMP w/2 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages isc-dhcp-server depends on: ii debconf [debconf-2.0] 1.5.58 ii debianutils4.7 ii libc6 2.21-7 ii libdns-export100 1:9.9.5.dfsg-12.1 ii libirs-export911:9.9.5.dfsg-12.1 ii libisc-export951:9.9.5.dfsg-12.1 ii lsb-base 9.20160110 Versions of packages isc-dhcp-server recommends: ii isc-dhcp-common 4.3.3-7 ii policycoreutils 2.4-4 Versions of packages isc-dhcp-server suggests: pn isc-dhcp-server-ldap -- Configuration Files: /etc/dhcp/dhcpd.conf changed [not included] -- debconf information excluded
Bug#812926: tads2-mode is out-of-date and should be removed
On Sun, Jan 31, 2016 at 11:22 AM, oldtechaa wrote: > I see you already filed one; never mind. > > On Sun, Jan 31, 2016 at 7:21 PM, oldtechaa wrote: >> >> So should I file an RM: bug instead to remove it from all suites? For reference: the RM bug is #813336. -- Daniel Schepler
Bug#813256: flex: C++ style comment in C output
Control: forwarded -1 http://sourceforge.net/p/flex/bugs/195/ Hi For the record, this should be the mentioned commit: https://github.com/westes/flex/commit/07d89829 Regards, Salvatore
Bug#813345: elastix: please fix patch to make the build reproducible (timestamps)
Source: elastix
Version: 4.8-3
Severity: wishlist
User: reproducible-bui...@lists.alioth.debian.org
Usertags: timestamps
Hi!
While working on the “reproducible builds” effort [1], we have noticed
that elastix could not be built reproducibly [2] because it is using the
current date to replace the @ELASTIX_DOXYGEN_DATE@ variable [3].
It seems an unsuccessful attempt has been made to use SOURCE_DATE_EPOCH
[4]. The patch has two problems:
- The if statement instead of checking for the environment variable
SOURCE_DATE_EPOCH it is checking for the cmake variable
SOURCE_DATE_EPOCH. To check for the environment variable use
$ENV{SOURCE_DATE_EPOCH}
- Instead of directly saving the content of the environment variable
SOURCE_DATE_EPOCH into ELASTIX_DOXYGEN_DATE, the value of the
environment variable should be formated into a datetime string.
Formating can be done as follows using GNU date:
date -u -d $SOURCE_DATE_EPOCH '+%d-%m-%Y'
A different approach to fixing the reproducibility problem is to instead
of using the DoxygenFooter.html.in you could just have a
DoxygenFooter.html and use the placeholder $datetime which is processed
by Doxygen instead of using the @ELASTIX_DOXYGEN_DATE@ placeholder.
Kind regards,
akira
[1]: https://wiki.debian.org/ReproducibleBuilds
[2]: https://reproducible.debian.net/rb-pkg/unstable/amd64/elastix.html
[3]:
https://sources.debian.net/src/elastix/4.8-3/dox/doxygen/DoxygenFooter.html.in/
[4]:
http://sources.debian.net/src/elastix/4.8-3/debian/patches/doxygen_use_epoch_for_data_if_given.patch/?hl=18#L18
Bug#804591: [Pkg-iscsi-maintainers] Bug#804591: open-iscsi: iscsi_auto flag should use iscsistart --fwparam_network in addition to -b
Control: tags -1 + pending On 11/09/2015 08:39 PM, Scott Moser wrote: > It seems that 'iscsi_auto' should invoke 'iscsistart --fwparam_network' in > addition to -b. > The --fwparam_network will set up networking that was declared in iBFT. I've implemented (and tested) this and pushed it to git. It will be part of the next upload to Debian. Regards, Christian signature.asc Description: OpenPGP digital signature
Bug#813285: marked as done (debian-installer: Error in DHCP)
Control: reopen -1 stop Hi Stephen, On Sun, Jan 31, 2016 at 03:54:25PM +, Debian Bug Tracking System wrote: > Your message dated Sun, 31 Jan 2016 15:52:57 + > with message-id > and subject line Bug#813285: fixed in units 2.12-2 > has caused the Debian Bug report #813285, > regarding debian-installer: Error in DHCP > to be marked as done. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=813285 > > Date: Sun, 31 Jan 2016 16:15:28 +0100 > Source: units > Binary: units > Version: 2.12-2 > Maintainer: Stephen Kitt > Changed-By: Stephen Kitt > Description: > units - converts between different systems of units > Closes: 410935 803679 813104 813285 > Changes: > units (2.12-2) unstable; urgency=medium > . >* Switch to https: VCS URIs (see #810378). >* Link to the actual homepage for units (thanks ? Dan Jacobson; > closes: #813285). Probably #813275 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=813275 If so, please close that bugreport. >* Correct the documentation for '-H' (thanks to Jakub Wilk; closes: > #803679). >* Describe °C???°F conversions as non-proportional rather than non- > linear (thanks to Lionel Elie Mamane for the suggestion; closes: > #410935). >* Apply upstream fix for µs (closes: #813104). Groeten Geert Stappers Who re-opened #813285 -- Leven en laten leven signature.asc Description: Digital signature
Bug#813344: wx3.0-i18n and trustedqsl: error when trying to install together
Package: trustedqsl,wx3.0-i18n Version: trustedqsl/2.2-1 Version: wx3.0-i18n'3.0.2+dfsg-1.2@all, wx3.0-i18n/3.0.2+dfsg-1 Severity: serious User: trei...@debian.org Usertags: edos-file-overwrite Date: 2016-01-31 Architecture: amd64 Distribution: sid Hi, automatic installation tests of packages that share a file and at the same time do not conflict by their package dependency relationships has detected the following problem: Extracting templates from packages: 26% Extracting templates from packages: 53% Extracting templates from packages: 79% Extracting templates from packages: 100% Preconfiguring packages ... Selecting previously unselected package libwrap0:amd64. (Reading database ... 10944 files and directories currently installed.) Preparing to unpack .../libwrap0_7.6.q-25_amd64.deb ... Unpacking libwrap0:amd64 (7.6.q-25) ... Selecting previously unselected package libexpat1:amd64. Preparing to unpack .../libexpat1_2.1.0-7_amd64.deb ... Unpacking libexpat1:amd64 (2.1.0-7) ... Selecting previously unselected package libpng12-0:amd64. Preparing to unpack .../libpng12-0_1.2.54-1_amd64.deb ... Unpacking libpng12-0:amd64 (1.2.54-1) ... Selecting previously unselected package libfreetype6:amd64. Preparing to unpack .../libfreetype6_2.6.1-0.1_amd64.deb ... Unpacking libfreetype6:amd64 (2.6.1-0.1) ... Selecting previously unselected package ucf. Preparing to unpack .../archives/ucf_3.0033_all.deb ... Moving old data out of the way Unpacking ucf (3.0033) ... Selecting previously unselected package fonts-dejavu-core. Preparing to unpack .../fonts-dejavu-core_2.35-1_all.deb ... Unpacking fonts-dejavu-core (2.35-1) ... Selecting previously unselected package fontconfig-config. Preparing to unpack .../fontconfig-config_2.11.0-6.3_all.deb ... Unpacking fontconfig-config (2.11.0-6.3) ... Selecting previously unselected package libfontconfig1:amd64. Preparing to unpack .../libfontconfig1_2.11.0-6.3_amd64.deb ... Unpacking libfontconfig1:amd64 (2.11.0-6.3) ... Selecting previously unselected package fontconfig. Preparing to unpack .../fontconfig_2.11.0-6.3_amd64.deb ... Unpacking fontconfig (2.11.0-6.3) ... Selecting previously unselected package libasyncns0:amd64. Preparing to unpack .../libasyncns0_0.8-5_amd64.deb ... Unpacking libasyncns0:amd64 (0.8-5) ... Selecting previously unselected package libdirectfb-1.2-9:amd64. Preparing to unpack .../libdirectfb-1.2-9_1.2.10.0-5.1_amd64.deb ... Unpacking libdirectfb-1.2-9:amd64 (1.2.10.0-5.1) ... Selecting previously unselected package x11-common. Preparing to unpack .../x11-common_1%3a7.7+13_all.deb ... Unpacking x11-common (1:7.7+13) ... Selecting previously unselected package libice6:amd64. Preparing to unpack .../libice6_2%3a1.0.9-1+b1_amd64.deb ... Unpacking libice6:amd64 (2:1.0.9-1+b1) ... Selecting previously unselected package libffi6:amd64. Preparing to unpack .../libffi6_3.2.1-4_amd64.deb ... Unpacking libffi6:amd64 (3.2.1-4) ... Selecting previously unselected package libglib2.0-0:amd64. Preparing to unpack .../libglib2.0-0_2.46.2-3_amd64.deb ... Unpacking libglib2.0-0:amd64 (2.46.2-3) ... Selecting previously unselected package libjpeg62-turbo:amd64. Preparing to unpack .../libjpeg62-turbo_1%3a1.4.1-2_amd64.deb ... Unpacking libjpeg62-turbo:amd64 (1:1.4.1-2) ... Selecting previously unselected package libjbig0:amd64. Preparing to unpack .../libjbig0_2.1-3.1_amd64.deb ... Unpacking libjbig0:amd64 (2.1-3.1) ... Selecting previously unselected package libtiff5:amd64. Preparing to unpack .../libtiff5_4.0.6-1_amd64.deb ... Unpacking libtiff5:amd64 (4.0.6-1) ... Selecting previously unselected package libxau6:amd64. Preparing to unpack .../libxau6_1%3a1.0.8-1_amd64.deb ... Unpacking libxau6:amd64 (1:1.0.8-1) ... Selecting previously unselected package libxdmcp6:amd64. Preparing to unpack .../libxdmcp6_1%3a1.1.2-1.1_amd64.deb ... Unpacking libxdmcp6:amd64 (1:1.1.2-1.1) ... Selecting previously unselected package libxcb1:amd64. Preparing to unpack .../libxcb1_1.11.1-1_amd64.deb ... Unpacking libxcb1:amd64 (1.11.1-1) ... Selecting previously unselected package libx11-data. Preparing to unpack .../libx11-data_2%3a1.6.3-1_all.deb ... Unpacking libx11-data (2:1.6.3-1) ... Selecting previously unselected package libx11-6:amd64. Preparing to unpack .../libx11-6_2%3a1.6.3-1_amd64.deb ... Unpacking libx11-6:amd64 (2:1.6.3-1) ... Selecting previously unselected package libgdk-pixbuf2.0-common. Preparing to unpack .../libgdk-pixbuf2.0-common_2.32.3-1.2_all.deb ... Unpacking libgdk-pixbuf2.0-common (2.32.3-1.2) ... Selecting previously unselected package libgdk-pixbuf2.0-0:amd64. Preparing to unpack .../libgdk-pixbuf2.0-0_2.32.3-1.2_amd64.deb ... Unpacking libgdk-pixbuf2.0-0:amd64 (2.32.3-1.2) ... Selecting previously unselected package libnotify4:amd64. Preparing to unpack .../libnotify4_0.7.6-2_amd64.deb ... Unpacking libnotify4:amd64 (0.7.6-2) ... Selecting previously unselected package libogg0:amd64. Preparing to unpack .../libogg0_1.3.2-1_amd64.deb ... Unpacking libogg0:
Bug#813338: Please add minimal autopkgtest
Source: icu
Severity: wishlist
Hi,
when doing security fixes on the package (e.g. during LTS work) its
always nice to know one didn't break the package completely (e.g. by an
error in the build environment). The time is better spent on testing
the specific results of the security change.
The attached autopkgtest aims to provide that certainty by building a
small example program and by executing some of the toos.
Please consider it for the next version.
Cheers,
-- Guido
-- System Information:
Debian Release: stretch/sid
APT prefers testing
APT policy: (990, 'testing'), (500, 'stable-updates'), (500, 'unstable'),
(500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.1.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
>From 6baef176a37a8d0d35bcc2b732221120529d467c Mon Sep 17 00:00:00 2001
Message-Id: <6baef176a37a8d0d35bcc2b732221120529d467c.1454268283.git@sigxcpu.org>
From: =?UTF-8?q?Guido=20G=C3=BCnther?=
Date: Sun, 31 Jan 2016 12:01:16 +0100
Subject: [PATCH] Add build and smoke autopkgtest
When working on security updates besides looking for specific
regressions one wants to also check basic functionality. To not have to
do this by hand add some very basic autopkgtests.
---
debian/tests/build-test | 10 +
debian/tests/control | 7 +
debian/tests/smoke | 11 +
debian/tests/ustring.cpp | 600 +++
4 files changed, 628 insertions(+)
create mode 100755 debian/tests/build-test
create mode 100644 debian/tests/control
create mode 100755 debian/tests/smoke
create mode 100644 debian/tests/ustring.cpp
diff --git a/debian/tests/build-test b/debian/tests/build-test
new file mode 100755
index 000..1de6ecb
--- /dev/null
+++ b/debian/tests/build-test
@@ -0,0 +1,10 @@
+#!/usr/bin/make -f
+
+CFLAGS=$(shell pkg-config --cflags icu-io)
+LIBS=$(shell pkg-config --libs icu-io)
+
+a.out: debian/tests/ustring.cpp
+ g++ $(CFLAGS) $< $(LIBS)
+ @echo "Build test of $< succeeded"
+ ./a.out
+ @rm -f a.out
diff --git a/debian/tests/control b/debian/tests/control
new file mode 100644
index 000..ce2c1e5
--- /dev/null
+++ b/debian/tests/control
@@ -0,0 +1,7 @@
+Tests: smoke
+Depends: @
+Restrictions: allow-stderr
+
+Tests: build-test
+Depends: libicu-dev, pkg-config
+Restrictions: allow-stderr
diff --git a/debian/tests/smoke b/debian/tests/smoke
new file mode 100755
index 000..88c2f1f
--- /dev/null
+++ b/debian/tests/smoke
@@ -0,0 +1,11 @@
+#!/bin/sh
+
+set -e
+set -x
+
+# Smoke test some of the tools
+uconv -f utf8 -t latin1 /etc/hostname
+icu-config --unicode-version
+
+echo 'Smoke test of test driver succesful'
+exit 0
diff --git a/debian/tests/ustring.cpp b/debian/tests/ustring.cpp
new file mode 100644
index 000..43254d8
--- /dev/null
+++ b/debian/tests/ustring.cpp
@@ -0,0 +1,600 @@
+/*
+ * Simple compile test, based on samples/ustring which is:
+***
+*
+* Copyright (C) 2000-2014, International Business Machines
+* Corporation and others. All Rights Reserved.
+*
+***
+*/
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define UPRV_LENGTHOF(array) (int32_t)(sizeof(array)/sizeof((array)[0]))
+
+// helper functions ***
+
+// default converter for the platform encoding
+static UConverter *cnv=NULL;
+
+static void
+printUString(const char *announce, const UChar *s, int32_t length) {
+static char out[200];
+UChar32 c;
+int32_t i;
+UErrorCode errorCode=U_ZERO_ERROR;
+
+/*
+ * Convert to the "platform encoding". See notes in printUnicodeString().
+ * ucnv_fromUChars(), like most ICU APIs understands length==-1
+ * to mean that the string is NUL-terminated.
+ */
+ucnv_fromUChars(cnv, out, sizeof(out), s, length, &errorCode);
+if(U_FAILURE(errorCode) || errorCode==U_STRING_NOT_TERMINATED_WARNING) {
+printf("%sproblem converting string from Unicode: %s\n", announce, u_errorName(errorCode));
+return;
+}
+
+printf("%s%s {", announce, out);
+
+/* output the code points (not code units) */
+if(length>=0) {
+/* s is not NUL-terminated */
+for(i=0; i0; /* U16_PREV pre-decrements */) {
+U16_PREV(input, 0, i, c);
+/* Iterating backwards
+ Codepoint at offset 5: U+0062
+ Codepoint at offset 3: U+10
+ Codepoint at offset 2: U+dc00 -- unpaired surrogate because lead surr. overwritten
+ Codepoint at offset 1: U+0062 -- by this BMP code point
+ Codepoint at offset 0: U+0061
+*/
+printf("Codepoint at offset %d: U+%04x\n", i, c);
+}
+}
+
+// sample code for Unicode string
Bug#812926: tads2-mode is out-of-date and should be removed
I see you already filed one; never mind. On Sun, Jan 31, 2016 at 7:21 PM, oldtechaa wrote: > So should I file an RM: bug instead to remove it from all suites? > > > On Sun, Jan 31, 2016 at 7:12 PM, Daniel Schepler > wrote: > >> On Sun, Jan 31, 2016 at 11:06 AM, oldtechaa wrote: >> > The package should be autoremoved by an RC bug, correct? >> >> Only from testing. As far as I know, there's no process to autoremove >> packages with RC bugs from unstable - though certainly, an RC bug >> without any response from the maintainer within a reasonable time >> could be grounds for removal. >> -- >> Daniel Schepler >> > >
Bug#813343: JPEG 2000 -support is missing
Package: imagemagick-6.q16 Version: 8:6.8.9.9-5 Severity: important Wikipedia claims that ImageMagick can support JPEG 2000: https://en.wikipedia.org/wiki/JPEG_2000?oldformat=true#Application_support I downloaded testfiles from here: https://github.com/uclouvain/openjpeg-data When trying to watch them with ImageMagick all I got was error messages: juhtolv@heresy:/home/juhtolv/tmp7/openjpeg-data-master/input/conformance % display file1.jp2 display: no decode delegate for this image format `JP2' @ error/constitute.c/ReadImage/501. [1]3181 exit 1 display file1.jp2 juhtolv@heresy:/home/juhtolv/tmp7/openjpeg-data-master/input/conformance % display p0_01.j2k display: no decode delegate for this image format `J2K' @ error/constitute.c/ReadImage/501. [1]3245 exit 1 display p0_01.j2k -- System Information: Debian Release: 8.3 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'proposed-updates'), (500, 'stable') Architecture: i386 (i686) Kernel: Linux 4.3.0-0.bpo.1-686-pae (SMP w/1 CPU core) Locale: LANG=fi_FI.utf8, LC_CTYPE=fi_FI.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages imagemagick-6.q16 depends on: ii hicolor-icon-theme 0.13-1 ii libc6 2.19-18+deb8u2 ii libmagickcore-6.q16-2 8:6.8.9.9-5 ii libmagickwand-6.q16-2 8:6.8.9.9-5 Versions of packages imagemagick-6.q16 recommends: ii ghostscript 9.06~dfsg-2+deb8u1 pn libmagickcore-6.q16-2-extra ii netpbm 2:10.0-15.2 Versions of packages imagemagick-6.q16 suggests: pn autotrace ii cups-bsd [lpr] 1.7.5-11+deb8u1 ii curl 7.38.0-4+deb8u3 ii enscript 1.6.5.90-2+b1 ii ffmpeg 10:2.6.5-dmo1 ii gimp 2.8.14-1+b1 ii gnuplot5 [gnuplot] 5.0.1+dfsg1-2~bpo8+1 pn grads pn graphviz ii groff-base 1.22.2-8 pn hp2xx ii html2ps 1.0b7-1 pn imagemagick-doc ii libwmf-bin 0.2.8.4-10.3+deb8u1 ii mplayer 3:1.1.1+20150226+svn37375-dmo5 ii mplayer2 [mplayer] 1:2.0~git20130903-dmo7 pn povray pn radiance ii sane-utils 1.0.24-8 ii texlive-binaries [texlive-base-bin] 2014.20140926.35254-6 pn transfig pn ufraw-batch ii xdg-utils1.1.0~rc1+git20111210-7.4 -- no debconf information -- Juhapekka ”naula” Tolvanen * http colon slash slash iki dot fi slash juhtolv ”Perustuu tositapahtumii, tai ainaki tosi todelle tuntuvii unii. Älä ota tätä oikein. Sä tiedät et mä oon hyvin huono kuuntelemaa toiveit. Siks sori, jos mä oon liian avoin, mut räpis on vaa liikaa sanoi. Ei mitä sanoo, vaa mitä jättää sanomatta. Jokainen säe ku pakomatka.” Paperi T
Bug#813336: RM: tads2-mode -- RoM: obsolete
Package: ftp.debian.org Severity: normal As pointed out in #812926, tads2-mode is obsolete. Please remove it from unstable (and testing as well, assuming it hasn't already been autoremoved due to the RC bug by the time this is processed). -- Daniel Schepler
Bug#813342: [debhelper] dh_installdocs: add maintscript automatically
Package: debhelper
Version: 9.20151225
Severity: wishlist
Tags: patch
Hi niels,
could you apply the following patch about allowing to run maintscript-helper
dir2symlink
Will save me some time on imagemagick
>From 87feddf6cb42fbd94e5507dfd8a1c37efb1bf221 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Bastien=20ROUCARI=C3=88S?=
Date: Sun, 31 Jan 2016 21:50:20 +0100
Subject: [PATCH] Allow to run maintscript helper automatically
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Signed-off-by: Bastien ROUCARIÈS
---
dh_installdocs | 9 +
1 file changed, 9 insertions(+)
diff --git a/dh_installdocs b/dh_installdocs
index da7b517..8e9cf2c 100755
--- a/dh_installdocs
+++ b/dh_installdocs
@@ -163,6 +163,7 @@ sub ensure_docdir {
init(options => {
"link-doc=s" => \$dh{LINK_DOC},
+ "previous-version=s" => \$dh{PREVIOUS_VERSION},
});
my $called_getpackages = 0;
@@ -173,6 +174,7 @@ foreach my $package (@{$dh{DOPACKAGES}}) {
my $tmp=tmpdir($package);
my $file=pkgfile($package,"docs");
my $link_doc=($dh{LINK_DOC} && $dh{LINK_DOC} ne $package);
+ my $previous_version=$dh{PREVIOUS_VERSION};
if ($link_doc) {
getpackages('both') unless $called_getpackages++;
@@ -197,6 +199,13 @@ foreach my $package (@{$dh{DOPACKAGES}}) {
# directory a symlink, then you have to depend on
# the target.
addsubstvar($package, 'misc:Depends', "$dh{LINK_DOC} (= \${binary:Version})");
+ # add maintscript helper
+ if ($previous_version) {
+foreach my $script (qw{postinst preinst prerm postrm}) {
+ autoscript($package, $script, "maintscript-helper",
+ "s!#PARAMS#!dir_to_symlink /usr/share/doc/$package $link_doc $previous_version!g");
+}
+ }
}
}
else {
--
2.7.0.rc3
Bug#813278: minidlna: scanner crashes on invalid flac files
fixed 813278 1.1.4+dfsg-1 thanks Hello toby, I know that current stable version if full of problems, but most of them are not critical: they are not really security problems (or may be used in really rare vector of attack) nor make minidlna unusable. https://www.debian.org/doc/manuals/developers-reference/pkgs.html#upload-stable > Basically, a package should only be uploaded to stable if one of the > following happens: > > a truly critical functionality problem > > the package becomes uninstallable > > a released architecture lacks the package So I see no reason to update stable version in this case =( Please use current version from testing (or backports). I believe you will like it more, then 1.1.2 with hotfixes. -- Best regards, Alexander Gerasiov Contacts: e-mail: g...@cs.msu.su Homepage: http://gerasiov.net Skype: gerasiov PGP fingerprint: 04B5 9D90 DF7C C2AB CD49 BAEA CA87 E9E8 2AAC 33F1
Bug#812926: tads2-mode is out-of-date and should be removed
On Sun, Jan 31, 2016 at 11:06 AM, oldtechaa wrote: > The package should be autoremoved by an RC bug, correct? Only from testing. As far as I know, there's no process to autoremove packages with RC bugs from unstable - though certainly, an RC bug without any response from the maintainer within a reasonable time could be grounds for removal. -- Daniel Schepler
Bug#813240: nmu: lazarus_1.4.4+dfsg-2
Hi On 30-01-16 20:07, Paul Gevers wrote: > Do you want a separate bug for castle-game-engine, or can it be done in this > same bug? > > nmu caste-game-engine_5.2.0-1 . ALL . -m "Rebuild against fpc 3.0.0" No need to do this (it fails to build currently). We will upload a new source. So please only binNMU lazarus as the bug title says. Paul signature.asc Description: OpenPGP digital signature
Bug#812926: tads2-mode is out-of-date and should be removed
The package should be autoremoved by an RC bug, correct?
Bug#753809: ginkgocadx and certain dicom files
> > > Orthanc will not modify the file by itself, except if the input file is > > corrupted > > I hadn't been made aware of this "except" so far. This means > more testing will need to be done because eventually Orthanc > _does_ modify input files sometimes. Sigh. > Well, Orthanc does not modify the *content* of the DICOM file, BUT syntactic variants such as the padding or the explicit/implicit length encoding might change. > which could lead to undefined behavior. Garbage in, garbage out. > > Sure, but so far I'd have assumed "garbage in, SAME garbage out". > Unfortunately, you cannot make this assumption, as the decoder might behave in some undefined fashion when faced with a corrupted DICOM file. > Note that I fully understand the desire to accept and store > the garbage (as [part of] the saying goes "be liberal in what > you accept"). However, it'd be helpful if there was either > documentation that Orthanc does indeed sometimes modify files > on its own or else if there was even a configuration option > for skip improworsening of DICOM files handed out. Orthanc > would be the tool of the day if it offered a REST field / > DICOM tag / whatever saying "Orthanc thinks this file is > broken because ..." and the web frontend would offer buttons > "display original", "display fixed", "fix permanently" ;-) > > Yeah, I know, making suggestions is cheap... :-) > The philosophy of Orthanc is indeed to accept any DICOM file, as soon as it can be parsed and it contains the 4 mandatory tags PatientID + StudyInstanceUID + SeriesInstanceUID + SOPInstanceUID. This is the most liberal approach in the DICOM (I often talk about "least common denominator"). However, a third-party C/C++ plugin for Orthanc could be implemented to check the validity of each incoming DICOM file thanks to David Clunie's dicom3tools (more precisely by calling "dciodvfy"). This would allow to track corrupted files in the way you suggest. Incoming files could be tagged and/or send to a kind of purgatory. Check out the "OrthancPluginRegisterOnStoredInstanceCallback()" function for this purpose: https://orthanc.chu.ulg.ac.be/sdk/group__Callbacks.html#ga1af7c8c9877aaf670208bfc53164b9fb As always, because I have already way too much work but few development support, I unfortunately cannot implement such a plugin by myself in the next few months...
Bug#807904: mathicgb: wrong spelling for Gröbner in package description
On Mon, 14 Dec 2015 12:16:37 +0100 Daniele Forsi wrote: > in the description for this package, I think that the name Groebner is > wrongly spelled twice as Grobner (without the "e"): > signature Grobner bases... > "Practical Grobner Basis Computation"... Thanks for the report! It's true that "Gröbner" (the original German spelling) is usually anglicized "Groebner" and not "Grobner". I'll upload a new version of this package soon with a corrected description.
Bug#813341: www.debian.org: Decide a place where to store logos so services can hotlink there
Package: www.debian.org
Severity: normal
Dear all
We have the official logos in https://www.debian.org/logos/ in several sizes
and formats.
People running other Debian services may hotlink there instead of storing local
copies of the logo.
In addition to that, we may create a folder under english/logos, with some name
('special', or other), where to store, for example, mourning logos, so we can
better coordinate when we want to change the logos in all the Debian service
infrastructure.
-- System Information:
Debian Release: 8.3
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: i386 (i686)
Kernel: Linux 3.16.0-4-686-pae (SMP w/2 CPU cores)
Locale: LANG=es_ES.UTF-8, LC_CTYPE=es_ES.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Bug#805574:
I'm having the same issue when trying to rename files. I have yet to encounter such crash when using the batch renamer, but when renaming individual files, Thunar randomly crashes on me every 4 or 5 rename attempts. If I could help with anything in debugging this, please let me know!
Bug#753809: ginkgocadx and certain dicom files
On Sun, Jan 31, 2016 at 09:23:16AM -0500, David Clunie wrote: > The Implementation Version Name in the meta information header > says "OFFIS_DCMTK_360", but dcmtk doesn't make this kind > of error, as far as I know, so Karsten, it would be good > to know what system actually encoded this bad DICOM file. That doesn't matter because: - initially, GinkgoCADx (and hence GDCM ?) reads the file just fine from local storage (say, CD-ROM) - it then sends the file to a PACS - it then retrieves the file from the same PACS - it then does not read the very same file anymore I am CCing the PACS programmer such that he may reconfirm that Orthanc doesn't modify DICOM files it receives for storage via DICOM - Sebastien ? The bug is: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=753809 Karsten -- GPG key ID E4071346 @ eu.pool.sks-keyservers.net E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346
Bug#801413: wheezy: update for polarssl's CVE-2015-5291
On Sun, Jan 31, 2016 at 09:12:38AM +0100, Sébastien Delafond wrote: > On Jan/29, Sébastien Delafond wrote: > > thanks for the debdiff. It looks OK, so feel free to upload it. Once > > that's done, I'll release the DSA. > > Hi Guido, > > are you still willing to upload polarssl to security-master ? :) Uploaded now. Thanks! -- Guido
Bug#812411: cgit: CVE-2016-1899 CVE-2016-1900 CVE-2016-1901
Control: tags -1 + patch
Hi Alexander,
On Sat, Jan 23, 2016 at 02:16:51PM +0100, Salvatore Bonaccorso wrote:
> Source: cgit
> Version: 0.10.2.git2.0.1-3
> Severity: important
> Tags: security upstream patch fixed-upstream
>
> Hi,
>
> the following vulnerabilities were published for cgit.
>
> CVE-2016-1899[0]:
> | CRLF injection vulnerability in the ui-blob handler in CGit before
> | 0.12 allows remote attackers to inject arbitrary HTTP headers and
> | conduct HTTP response splitting attacks or cross-site scripting (XSS)
> | attacks via CRLF sequences in the mimetype parameter, as demonstrated
> | by a request to blob/cgit.c.
>
> CVE-2016-1900[1]:
> | CRLF injection vulnerability in the cgit_print_http_headers function
> | in ui-shared.c in CGit before 0.12 allows remote attackers with
> | permission to write to a repository to inject arbitrary HTTP headers
> | and conduct HTTP response splitting attacks or cross-site scripting
> | (XSS) attacks via newline characters in a filename.
>
> CVE-2016-1901[2]:
> | Integer overflow in the authenticate_post function in CGit before 0.12
> | allows remote attackers to have unspecified impact via a large value
> | in the Content-Length HTTP header, which triggers a buffer overflow.
>
> If you fix the vulnerabilities please also make sure to include the
> CVE (Common Vulnerabilities & Exposures) ids in your changelog entry.
>
> For further information see:
>
> [0] https://security-tracker.debian.org/tracker/CVE-2016-1899
> [1] https://security-tracker.debian.org/tracker/CVE-2016-1900
> [2] https://security-tracker.debian.org/tracker/CVE-2016-1901
Attached is proposed debdiff, but I was not able to test the resulting
package on a cgit instance. The patches are straightforward taken from
git repo.
Regards,
Salvatore
diff -Nru cgit-0.11.2.git2.3.2/debian/changelog
cgit-0.11.2.git2.3.2/debian/changelog
--- cgit-0.11.2.git2.3.2/debian/changelog 2015-08-11 10:24:04.0
+0200
+++ cgit-0.11.2.git2.3.2/debian/changelog 2016-01-27 20:54:36.0
+0100
@@ -1,3 +1,15 @@
+cgit (0.11.2.git2.3.2-1.1) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * CVE-2016-1899: Reflected XSS and header injection in mimetype query
+string (Closes: #812411)
+ * CVE-2016-1900: Stored cross site scripting and header injection in
+filename paramenter (Closes: #812411)
+ * CVE-2016-1901: Integer overflow resulting in buffer overflow
+(Closes: #812411)
+
+ -- Salvatore Bonaccorso Wed, 27 Jan 2016 20:54:12 +0100
+
cgit (0.11.2.git2.3.2-1) unstable; urgency=medium
* [7f8779f] Imported Upstream version 0.11.2.git2.3.2
diff -Nru
cgit-0.11.2.git2.3.2/debian/patches/filter-avoid-integer-overflow-in-authenticate_post.patch
cgit-0.11.2.git2.3.2/debian/patches/filter-avoid-integer-overflow-in-authenticate_post.patch
---
cgit-0.11.2.git2.3.2/debian/patches/filter-avoid-integer-overflow-in-authenticate_post.patch
1970-01-01 01:00:00.0 +0100
+++
cgit-0.11.2.git2.3.2/debian/patches/filter-avoid-integer-overflow-in-authenticate_post.patch
2016-01-27 20:53:36.0 +0100
@@ -0,0 +1,34 @@
+From 4458abf64172a62b92810c2293450106e6dfc763 Mon Sep 17 00:00:00 2001
+From: "Jason A. Donenfeld"
+Date: Tue, 24 Nov 2015 11:28:00 +0100
+Subject: [PATCH] filter: avoid integer overflow in authenticate_post
+
+ctx.env.content_length is an unsigned int, coming from the
+CONTENT_LENGTH environment variable, which is parsed by strtoul. The
+HTTP/1.1 spec says that "any Content-Length greater than or equal to
+zero is a valid value." By storing this into an int, we potentially
+overflow it, resulting in the following bounding check failing, leading
+to a buffer overflow.
+
+Reported-by: Erik Cabetas
+Signed-off-by: Jason A. Donenfeld
+---
+ cgit.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/cgit.c b/cgit.c
+index 5937b9e..05e5d57 100644
+--- a/cgit.c
b/cgit.c
+@@ -651,7 +651,7 @@ static inline void open_auth_filter(const char *function)
+ static inline void authenticate_post(void)
+ {
+ char buffer[MAX_AUTHENTICATION_POST_BYTES];
+- int len;
++ unsigned int len;
+
+ open_auth_filter("authenticate-post");
+ len = ctx.env.content_length;
+--
+2.7.0
+
diff -Nru cgit-0.11.2.git2.3.2/debian/patches/series
cgit-0.11.2.git2.3.2/debian/patches/series
--- cgit-0.11.2.git2.3.2/debian/patches/series 2015-08-10 22:13:06.0
+0200
+++ cgit-0.11.2.git2.3.2/debian/patches/series 2016-01-27 20:53:36.0
+0100
@@ -8,3 +8,6 @@
assume-highlight-version-3-in-filter-script
add-highlighting-rules-to-cgit.css
Use-debian-binary-name-rst2html
+ui-blob-Do-not-accept-mimetype-from-user.patch
+ui-shared-prevent-malicious-filename-from-injecting-.patch
+filter-avoid-integer-overflow-in-authenticate_post.patch
diff -Nru
cgit-0.11.2.git2.3.2/debian/patches/ui-blob-Do-not-accept-mimetype-from-user.patch
cgit-0.11.2.git2.3.2/debian/patches/ui-blob-Do-not-accept-mimetype-from-user.pat
Bug#812990: jessie-pu: package gummi/0.6.5-3+deb8u1
On 31.01.2016 19:20, Adam D. Barratt wrote: > Control: tags -1 -moreinfo +confirmed > > On Sun, 2016-01-31 at 19:09 +0100, Daniel Stender wrote: >> On 31.01.2016 18:57, Adam D. Barratt wrote: >>> Control: tags -1 + moreinfo >>> >>> On Thu, 2016-01-28 at 12:49 +0100, Daniel Stender wrote: I propose an update of Gummi in Jessie. It's a fix of #812577 [1]. The same patch/changes are also included in gummi/0.6.3-1.2+deb7u2, please see the wheezy-pu for the background [2]: >>> [...] I've build the package with Sbuild against stable [3]. Please see the attached debdiff for the whole set of changes. >>> >>> That appears to be the wheezy debdiff. >>> >>> Regards, >>> >>> Adam >> >> Ah, yes! >> >> Here we go ... > > Thanks. Please go ahead. > > Regards, > > Adam In: gummi_0.6.5-3+deb8u2_amd64.changes ACCEPTED into proposed-updates->stable-new Thanks, Daniel -- 4096R/DF5182C8 46CB 1CA8 9EA3 B743 7676 1DB9 15E0 9AF4 DF51 82C8 LPI certified Linux admin (LPI000329859 64mz6f7kt4) http://www.danielstender.com/blog/
Bug#813339: isc-dhcp-server: Update to 4.3.3-7 today makes isc-dhcp-server unable to work
On Sun, 31 Jan 2016 21:33:35 +0100 Sven Hartge wrote: > On Sun, 31 Jan 2016 19:34:22 + Russel Winder wrote: >> I aptitude upgraded the machine running my DHCP server at around >> 2016-01-31T17:18 which included an upgrade >> to isc-dhcp-(server,common,client). Since this update the server will not >> start. Restarting just causes it >> to exit. > > The variable to define which interface the dhcpd runs on has changed, > but unfortunately the contents of /etc/default/isc-dhcp-server were not > adapted at the same time. Addition: This change is fallout from the changes done to resolve Bug#592539. But please note that the solution to that bug is also faulty: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=592539#181 Grüße, Sven.
Bug#753809: ginkgocadx and certain dicom files
On Sun, Jan 31, 2016 at 09:10:48PM +0100, Sébastien Jodogne wrote: > Orthanc will not modify the file by itself, except if the input file is > corrupted I hadn't been made aware of this "except" so far. This means more testing will need to be done because eventually Orthanc _does_ modify input files sometimes. Sigh. I will see whether I can manage to find out more. > which could lead to undefined behavior. Garbage in, garbage out. Sure, but so far I'd have assumed "garbage in, SAME garbage out". Note that I fully understand the desire to accept and store the garbage (as [part of] the saying goes "be liberal in what you accept"). However, it'd be helpful if there was either documentation that Orthanc does indeed sometimes modify files on its own or else if there was even a configuration option for skip improworsening of DICOM files handed out. Orthanc would be the tool of the day if it offered a REST field / DICOM tag / whatever saying "Orthanc thinks this file is broken because ..." and the web frontend would offer buttons "display original", "display fixed", "fix permanently" ;-) Yeah, I know, making suggestions is cheap... :-) Thanks for everyone's work so far, Karsten -- GPG key ID E4071346 @ eu.pool.sks-keyservers.net E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346
Bug#812848: mailutils: FTBFS: libmu_auth.so: undefined reference to `gnutls_mac_set_priority'
tags 812848 +patch
thanks
The code in question is
static int protocol_priority[] = {GNUTLS_TLS1, GNUTLS_SSL3, 0};
static int kx_priority[] = {GNUTLS_KX_RSA, 0};
static int cipher_priority[] = {GNUTLS_CIPHER_3DES_CBC,
GNUTLS_CIPHER_ARCFOUR_128,
0};
static int comp_priority[] = {GNUTLS_COMP_NULL, 0};
static int mac_priority[] = {GNUTLS_MAC_SHA, GNUTLS_MAC_MD5, 0};
gnutls_init (&sp->session, GNUTLS_CLIENT);
gnutls_protocol_set_priority (sp->session, protocol_priority);
gnutls_cipher_set_priority (sp->session, cipher_priority);
gnutls_compression_set_priority (sp->session, comp_priority);
gnutls_kx_set_priority (sp->session, kx_priority);
gnutls_mac_set_priority (sp->session, mac_priority);
As well as using removed functions the settings this is trying to
apply are extremely outdated. MD5, RC4 and SSLv3 are considered no
longer fit for use. Most of the other things specified are considered
barely acceptable at best.
According to
http://www.gnutls.org/manual/html_node/Upgrading-from-previous-versions.html#Upgrading-from-previous-versions
the whole set of gnutls_*_set_priority functions used here were replaced
by gnutls_priority_set_direct. I could have tried to reformulate the
settings specified above in the form needed by that function but doing
so would be perverse given those settings make no sense nowadays
So instead I replaced them with a call to gnutls_set_default_priority
I have uploaded the fixed package to raspbian stretch-staging . Debdiff
attatched, no intent to NMU in Debian.
diff -Nru mailutils-2.99.98/debian/changelog mailutils-2.99.98/debian/changelog
--- mailutils-2.99.98/debian/changelog 2014-10-07 22:16:53.0 +
+++ mailutils-2.99.98/debian/changelog 2016-01-31 18:06:50.0 +
@@ -1,3 +1,10 @@
+mailutils (1:2.99.98-2+rpi1) stretch-staging; urgency=medium
+
+ * Remove calls to removed gnutls_*_set_priority functions replace them
+with a call to gnutls_set_default_priority .
+
+ -- Peter Michael Green Sun, 31 Jan 2016 18:06:22
+
+
mailutils (1:2.99.98-2) unstable; urgency=low
* Ack NMU's, thanks! (Closes: #759359)
diff -Nru mailutils-2.99.98/debian/patches/gnutls3.4.patch
mailutils-2.99.98/debian/patches/gnutls3.4.patch
--- mailutils-2.99.98/debian/patches/gnutls3.4.patch1970-01-01
00:00:00.0 +
+++ mailutils-2.99.98/debian/patches/gnutls3.4.patch2016-01-31
18:10:49.0 +
@@ -0,0 +1,43 @@
+Description: replace calls to gnutls_*_set_priority with call to
gnutls_set_default_priority
+ The code was using the removed gnutls_*_set_priority functions to apply a set
+ of settings that make no sense anymore. Replace them with a call to
+ gnutls_set_default_priority
+Author: Peter Michael Green
+
+---
+The information above should follow the Patch Tagging Guidelines, please
+checkout http://dep.debian.net/deps/dep3/ to learn about the format. Here
+are templates for supplementary fields that you might want to add:
+
+Origin: ,
+Bug:
+Bug-Debian: https://bugs.debian.org/
+Bug-Ubuntu: https://launchpad.net/bugs/
+Forwarded:
+Reviewed-By:
+Last-Update:
+
+--- mailutils-2.99.98.orig/libmu_auth/tls.c
mailutils-2.99.98/libmu_auth/tls.c
+@@ -428,20 +428,9 @@ prepare_client_session (mu_stream_t stre
+ struct _mu_tls_stream *sp = (struct _mu_tls_stream *) stream;
+ int rc;
+ mu_transport_t transport[2];
+- static int protocol_priority[] = {GNUTLS_TLS1, GNUTLS_SSL3, 0};
+- static int kx_priority[] = {GNUTLS_KX_RSA, 0};
+- static int cipher_priority[] = {GNUTLS_CIPHER_3DES_CBC,
+-GNUTLS_CIPHER_ARCFOUR_128,
+-0};
+- static int comp_priority[] = {GNUTLS_COMP_NULL, 0};
+- static int mac_priority[] = {GNUTLS_MAC_SHA, GNUTLS_MAC_MD5, 0};
+
+ gnutls_init (&sp->session, GNUTLS_CLIENT);
+- gnutls_protocol_set_priority (sp->session, protocol_priority);
+- gnutls_cipher_set_priority (sp->session, cipher_priority);
+- gnutls_compression_set_priority (sp->session, comp_priority);
+- gnutls_kx_set_priority (sp->session, kx_priority);
+- gnutls_mac_set_priority (sp->session, mac_priority);
++ gnutls_set_default_priority (sp->session);
+
+ gnutls_certificate_allocate_credentials (&x509_cred);
+ if (mu_tls_module_config.ssl_cafile)
diff -Nru mailutils-2.99.98/debian/patches/series
mailutils-2.99.98/debian/patches/series
--- mailutils-2.99.98/debian/patches/series 2014-10-03 07:26:05.0
+
+++ mailutils-2.99.98/debian/patches/series 2016-01-31 18:08:58.0
+
@@ -5,3 +5,4 @@
pop3d_auth_crash.patch
readline.patch
10_guile-snarf-CPP.patch
+gnutls3.4.patch
Bug#813334: colord: syslog spam after failure to get session
Package: colord Version: 1.2.12-1 Severity: important Every time the CUPS scheduler wakes up and runs, colord drops 3 messages in the message log: Jan 30 09:02:02 dell2800 colord[587]: (colord:587): Cd-WARNING **: failed to get session [pid 485]: No such device or address Jan 30 09:02:02 dell2800 colord[587]: (colord:587): Cd-WARNING **: failed to get session [pid 485]: No such device or address Jan 30 09:02:02 dell2800 colord[587]: (colord:587): Cd-WARNING **: failed to get session [pid 485]: No such device or address Jan 30 09:07:42 dell2800 colord[587]: (colord:587): Cd-WARNING **: failed to get session [pid 4198]: No such device or address Jan 30 09:07:42 dell2800 colord[587]: (colord:587): Cd-WARNING **: failed to get session [pid 4198]: No such device or address Jan 30 09:07:42 dell2800 colord[587]: (colord:587): Cd-WARNING **: failed to get session [pid 4198]: No such device or address I'm guessing there is a message for each CUPS printer queue as I have 3 defined. This has become more of a problem because it seems like the CUPS mechanism to keep cupsd alive forever is broken, but that's another issue. -- System Information: Debian Release: stretch/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 4.3.0-1-686-pae (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages colord depends on: ii acl 2.2.52-2 ii adduser 3.113+nmu3 ii colord-data 1.2.12-1 ii dconf-gsettings-backend [gsettings-backend] 0.24.0-2 ii libc62.21-7 ii libcolord2 1.2.12-1 ii libcolorhug2 1.2.12-1 ii libdbus-1-3 1.10.6-1 ii libglib2.0-0 2.46.2-3 ii libgudev-1.0-0 230-2 ii libgusb2 0.2.8-1 ii liblcms2-2 2.6-3+b3 ii libpolkit-gobject-1-00.105-14.1 ii libsane 1.0.25-2 ii libsqlite3-0 3.9.2-1 ii libsystemd0 228-4+b1 ii libusb-1.0-0 2:1.0.20-1 ii policykit-1 0.105-14.1 colord recommends no packages. Versions of packages colord suggests: pn colord-sensor-argyll -- no debconf information
Bug#731634: xz-utils: new upstream version 5.2.1
On 2016-01-19 10:44:06 [-0800], Jonathan Nieder wrote: > Hi Sebastian, Hi Jonathan, > > I package new upstream at > >git://git.breakpoint.cc/bigeasy/xz-utils-debian.git > > Beautiful. I'll merge this and make an upload today. Is there something that you need to get done before the upload and I could help you with or is it just patience? :) > Thanks, > Jonathan Sebastian
Bug#492367: Bug #492367: open-iscsi: Enable static IP to iscsi root using initramfs and virtual machine Xen
Control: tags -1 + moreinfo Hi, I'm looking through the bug list of open-iscsi and I've noticed this really old wishlist bug. Is this still relevant? Or has Xen changed in the mean time? (Sorry, I don't use Xen, I have no idea about it.) I'd rather not merge something where I'm not sure that it actually works in the current environment. Could you perhaps provide a bit of details on what exactly is wrong when calling configure_networking? Regards, Christian signature.asc Description: OpenPGP digital signature
Bug#812860: /usr/bin/uscan: [uscan] failure to download and verify package.tar.xz with package.sign
Hello Osamu, On 01/31/2016 09:41 AM, Osamu Aoki wrote: > I think I have fix for this bug report. Thanks for you quick reaction. > On Sun, Jan 31, 2016 at 08:03:22AM +0900, Osamu Aoki wrote: >> On Wed, Jan 27, 2016 at 10:26:49PM -0500, James McCoy wrote: > > Your comment on --force-download is correct. > >>> Thanks for the report. There are a few things going on here. >>> >>> On Wed, Jan 27, 2016 at 11:36:52AM +0100, Uwe Kleine-König wrote: now running > > [snip] > uscan: Successfully downloaded package rt-tests-0.96.tar.xz Could not read ../rt-tests-0.96.tar.xz: No such file or directory at /usr/bin/mk-origtargz line 361. uscan: error: mk-origtargz --package rt-tests --version 0.96 --compression gzip --directory .. --copyright-file debian/copyright ../rt-tests-0.96.tar.xz gave error exit status 2 where the problem seems to be that uscan decompresses the archive but in the same go removes the tar.xz for mk-origtargz. >>> >>> Actually, it keeps the tar.xz when it should be passing the filename as >>> rt-tests-0.96.tar, if the current verification behavior isn't changed. > > uscan keeps filename for tar.xz in its internal variable but > gunzip/unxz/bunzip2 were invoked without --keep in uscan I tested your change, and it works fine here now. \o/ > Script started on Sun 31 Jan 2016 05:23:24 PM JST > [...] > uscan info: Matching pattern: > > (?:(?:http://www.kernel.org)?\/pub\/linux\/utils\/rt\-tests\/)?rt-tests-(.*)\.tar\.xz > > (?:(?:https://www.kernel.org)?\/pub\/linux\/utils\/rt\-tests\/)?rt-tests-(.*)\.tar\.xz Using (?:.)? at the start of a regexp doesn't give any advantage, and probably can be dropped without any loss. If you want to keep it: Why is the - quoted? You might want to make "http:" optional, because otherwise //www.kernel.org/pub/linux/utils/rt-tests/... isn't matched. Best regards Uwe signature.asc Description: OpenPGP digital signature
Bug#753809: ginkgocadx and certain dicom files
Orthanc will not modify the file by itself, except if the input file is corrupted, which could lead to undefined behavior. Garbage in, garbage out. Regards, Sébastien- On Sun, Jan 31, 2016 at 7:45 PM, Karsten Hilbert wrote: > On Sun, Jan 31, 2016 at 07:42:26PM +0100, Karsten Hilbert wrote: > > > > The Implementation Version Name in the meta information header > > > says "OFFIS_DCMTK_360", but dcmtk doesn't make this kind > > > of error, as far as I know, so Karsten, it would be good > > > to know what system actually encoded this bad DICOM file. > > > > That doesn't matter because: > > > > - initially, GinkgoCADx (and hence GDCM ?) reads the file > > just fine from local storage (say, CD-ROM) > > - it then sends the file to a PACS > > - it then retrieves the file from the same PACS > > - it then does not read the very same file anymore > > And, may I add, this behaviour happens with DICOM files from > various (commercial) sources. >
Bug#813004: jessie-pu: package ruby-defaults/1:2.1.5+deb8u2
On Sun, Jan 31, 2016 at 06:04:48PM +, Adam D. Barratt wrote: > Control; tags -1 + confirmed > > On Thu, 2016-01-28 at 11:34 -0200, Antonio Terceiro wrote: > > This fixes a serious bug which stops a transitional package from being > > installed on jessie: > > > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=798712 > > > > The debdiff is very simple, and goes attached. > > Please go ahead. just uploaded signature.asc Description: PGP signature
Bug#813340: rhythmbox-ampache: KeyError when selecting the tab
Package: rhythmbox-ampache
Version: 0.11.1+svn43-1
Severity: grave
Tags: upstream
Dear maintainer,
rhythmbox-ampache crashes with this error:
Traceback (most recent call last):
File "/usr/lib/rhythmbox/plugins/ampache/AmpacheBrowser.py", line 542,
in handshake_cb
handshake['update'][0:18],
KeyError: 'update'
I added some print statement, and here is the content of “handshake”:
{'error': 'Unauthorized access attempt to API - ACL Error',
'root': 'Unauthorized access attempt to API - ACL Error\n'}
Steps to reproduce:
1. load rhythmbox-ampache from the plugins dialog
2. configure a server's URL and login
3. click the “ampache” tab of Rhythmbox
I checked my login and password, they are correct; and the server allows
stream access (I left the default config).
Server version: 3.6-rzb2752+dfsg-5 (in Jessie)
Regards,
Val
signature.asc
Description: OpenPGP digital signature
Bug#813189: [Pkg-openssl-devel] Bug#813189: libio-socket-ssl-perl: FTBFS with current libssl1.0.2: t/startssl-failed.t hangs
On Sat, Jan 30, 2016 at 10:51:06PM +0100, Salvatore Bonaccorso wrote: > Hi Niko, > > On Sat, Jan 30, 2016 at 09:24:26PM +0200, Niko Tyni wrote: > > On Sat, Jan 30, 2016 at 12:03:27PM +0200, Niko Tyni wrote: > > > Package: libio-socket-ssl-perl > > > Version: 2.022-1 > > > Severity: serious > > > X-Debbugs-Cc: open...@packages.debian.org > > > > > > The libio-socket-ssl-perl started hanging in its test suite > > > with libssl1.0.2 upgrade from 1.0.2e-1 to 1.0.2f-2. > > > > > > The hanging test is t/startssl-failed.t, and running it > > > manually shows > > > > > > perl t/startssl-failed.t > > > 1..9 > > > ok #Server Initialization > > > ok #client tcp connect > > > ok #tcp accept > > > ok #send non-ssl data > > > > It's looping in IO::Socket::SSL::stop_SSL, repeatedly getting 0 from > > Net::SSLeay::shutdown(), which seems to be just a thin wrapper for > > the libssl SSL_shutdown(). > > > > Reverting > > > > https://github.com/openssl/openssl/commit/f73c737c7ac908c5d6407c419769123392a3b0a9 > > makes things work again. > > > > Kurt, which one do you think is wrong? > > FTR, Upstream has released a new version (I have imported in our git > repo already): > > 2.023 2016/01/30 > - OpenSSL 1.0.2f changed the behavior of SSL shutdown in case the TLS > connection > was not fully established (commit: > f73c737c7ac908c5d6407c419769123392a3b0a9). > This somehow resulted in Net::SSLeay::shutdown returning 0 (i.e. keep > trying) > which caused an endless loop. It will now ignore this result in case the TLS > connection was not yet established and consider the TLS connection closed > instead. > > But this does not seem to fully resolve the issue yet. When I try to > build the testsuite still get stuck. So as I understand it, the problem is that the client just sends crap, the server tells the client it sends crap, but then waits for the client to properly terminate the question which it never does? It's at least not behaviour I can reproducing using s_server, the server actually closes the connection for me. Kurt
Bug#650601: Update on libpng's transition status
Am Sonntag, den 31.01.2016, 17:52 + schrieb Mattia Rizzolo: > On Sun, Jan 31, 2016 at 05:46:07PM +0100, Tobias Frost wrote: > > Still FTBFS are, I've put an analysis why so on the titanpad [1], > > but > > those are all _not_ libpng related and many of those packages are > > not > > in testing. > > Analysis of what is in testing atm: > > > > blender > > notice that blender should be ready for libpng1.6 once the ilmbase > and > openexr transition start, so that the experimental version can be > used > (which should be fine). > Actually, Those 2 transitions are way smaller than libpng, and I > would > have expected them to be already started... #810568 I just scheduled a build of the experimental version on my server, and it looks good so far. (It needs experimental B-Ds as well) > > criticalmass > > I was able to build this just fine here. > I also tested it against libpng16 and built a binary depending on it > just fine. > I believe there is something fishy on your part here :) Yes, you're right: It has been building fine also on my server already.[1], it was an left over from my list; (I had lately problems with somepackage in conjunction with parallel build and pbuilder -- criticalmass is one of those) [1] http://libpng.sviech.de/!summary.txt > > gmsh > > vtk6 > > These 2 at the moment are not buildable because they are several > levels > down of the openmpi transition and need other libs to be built first. > I just believe openmpi needs to be done first before of this. vtk6 built fine previously with libpn1.6, as well as gmsh. (For gmsh I still have the old buildlog: https://libpng.sviech.de/old/gmsh.build, for vtk6 they've got overwritten but there are still the resulting packages at https://libpng.sviech.de/libpng16/pool/main/v/vtk6/ ) So, I guess we could ignore this collision? > > yt > > yt is going to be autoremoved soon (Feb 9) so this can be ignored. > > > [1] https://titanpad.com/libpng16-transistion > > > So if I'm not blind or anything, I belive this transition has no > actual > blocker (but other transitions to be done first, though). > > Of course in something so big something will come out during the > transition, but hey ^^ It would be a miracle, as we see with openmpi.. Knocking wood, though. But I have the feeling we are in a good position, and at least the next few weeks I'm able to commit some time to this. For the procedure, does it help the case / would it make sense to upload a libpng16 *without* provding libconfig-dev to sid, to have it in testing already, when we pull the trigger? (As you know, said trigger is the Provides: libpng-dev line; without it all the packages will use libpng12-dev..) -- tobi
Bug#811054: obexftp needs upgrade to Version 0.24
Hi, as mentioned at http://sourceforge.net/projects/openobex/files/openobex/1.7/ the obexftp package must be updated to >= 0.24 to be source compatible with openobex >= 1.7 Regards, HS
Bug#812926: tads2-mode is out-of-date and should be removed
So should I file an RM: bug instead to remove it from all suites? On Sun, Jan 31, 2016 at 7:12 PM, Daniel Schepler wrote: > On Sun, Jan 31, 2016 at 11:06 AM, oldtechaa wrote: > > The package should be autoremoved by an RC bug, correct? > > Only from testing. As far as I know, there's no process to autoremove > packages with RC bugs from unstable - though certainly, an RC bug > without any response from the maintainer within a reasonable time > could be grounds for removal. > -- > Daniel Schepler >
Bug#813323: Second window of Eye of MATE don't get focus
What exactly is the point of reporting non-critical bugs against ancient upstream versions? I don't think anyone will ever start fixing usability bugs in MATE 1.8.0. Adrian > On Jan 31, 2016, at 5:20 PM, Strelok wrote: > > Package: eom > Version: 1.8.0 > > I'm try open jpg file in Eye of MATE. Eye of MATE show this file in > new window and system switch to this window automatically. Very good. > When Eye of MATE window is still open, I'm try open another jpg file. > Eye of MATE show this file in one more window... But this one more > window don't automatically get focus (but I'm can switch to this > window manually). This bug appear in LiveCD and in usual Debian with > Mate desktop. And yes, I'm really need open two files in one time (to > compare this files between them). > > ___ > pkg-mate-team mailing list > pkg-mate-t...@lists.alioth.debian.org > http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-mate-team
Bug#753809: ginkgocadx and certain dicom files
On Sun, Jan 31, 2016 at 07:42:26PM +0100, Karsten Hilbert wrote: > > The Implementation Version Name in the meta information header > > says "OFFIS_DCMTK_360", but dcmtk doesn't make this kind > > of error, as far as I know, so Karsten, it would be good > > to know what system actually encoded this bad DICOM file. > > That doesn't matter because: > > - initially, GinkgoCADx (and hence GDCM ?) reads the file > just fine from local storage (say, CD-ROM) > - it then sends the file to a PACS > - it then retrieves the file from the same PACS > - it then does not read the very same file anymore And, may I add, this behaviour happens with DICOM files from various (commercial) sources. Karsten -- GPG key ID E4071346 @ eu.pool.sks-keyservers.net E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346
Bug#813335: mdadm: Upgrade from jessie to testing breaks boot with mdadm on lvm2
Package: mdadm Version: 3.3.4-1.1+b1 Severity: important Dear Maintainer, after upgrading from jessie to testing the boot sequence times out when trying to mount the configured raid1/10 arrays and drops me into the emergency shell. Inspection in the emergency shell shows, that neither kernel modules for raid1/10 are loaded nor any device is present in /dev/md. Arrays can be assembled at that stage without problem by # mdadm --assemble --scan and after # mount -a I get to a working system. I looked up the several related bugs, but couldn't find any that really looked the same to me, thus filing this one as new. I tried several workarounds proposed in other issues like - rootdelay=10 (Note: my root is not on raid, so I didn't really expect a change) - running with INITRDSTART= - starting with sysvinit failing with message "failed to assemble all arrays" (#796624) - copying the mdadm udev rules to higher numbers after lvm2 rules - Changing mdadm raid init script to use runlevels 1 2 3 4 5 instead of S (#763315). - using a /lib/udev/rules.d/63-md-raid-arrays.rules with reverted patch use-external-blkid.diff (#793631) Still subject to test: - moving/copying /usr/share/initramfs-tools/scripts/local-top/mdadm to local-bottom or - changing the pre-requisites for mdadm to depend on lvm2 for my use case (madadm on lvm2 instead of lvm2 on mdadm) Thanks for looking into the problem, Mathias -- Package-specific info: --- mdadm.conf CREATE owner=root group=disk mode=0660 auto=yes HOMEHOST MAILADDR root ARRAY /dev/md/efi_hd metadata=1.2 name=monsterix:efi_hd UUID=23fcca26:90c930ea:d241a4fc:b2f89cae ARRAY /dev/md/root_hd metadata=1.2 name=monsterix:root_hd UUID=e8e40488:a69568c5:f521da1f:35e995da ARRAY /dev/md/var metadata=1.2 name=monsterix:var UUID=fa370095:32920a14:7c914259:bfe47356 ARRAY /dev/md/boot_hd metadata=1.2 name=monsterix:boot_hd UUID=191b5317:e1ffb4e3:54fd75d7:c259d38d ARRAY /dev/md/home metadata=1.2 name=monsterix:home UUID=b855a499:ed54711c:8b73c73c:d1a784fe ARRAY /dev/md/home_crypt metadata=1.2 name=monsterix:home_crypt UUID=bbaf4693:c8047a79:52ab0458:41a2fb3d ARRAY /dev/md/data_crypt metadata=1.2 name=monsterix:data_crypt UUID=9b86aaf9:21f19c42:d283e5c8:03996411 --- /etc/default/mdadm INITRDSTART='all' AUTOCHECK=true START_DAEMON=true DAEMON_OPTIONS="--syslog" VERBOSE=true --- /proc/mdstat: Personalities : [raid10] [raid1] md121 : active (auto-read-only) raid10 dm-23[0] dm-13[1] 209584128 blocks super 1.2 2 near-copies [2/2] [UU] bitmap: 0/2 pages [0KB], 65536KB chunk md122 : active (auto-read-only) raid10 dm-5[0] dm-22[1] 52396032 blocks super 1.2 2 near-copies [2/2] [UU] md123 : active raid1 dm-1[0] dm-19[2](W) 104792064 blocks super 1.2 [2/2] [UU] md124 : active (auto-read-only) raid10 dm-17[0] dm-10[2] 265216 blocks super 1.2 2 near-copies [2/2] [UU] md125 : active raid1 dm-18[0] dm-6[1] 31449088 blocks super 1.2 [2/2] [UU] md126 : active raid10 dm-14[0] dm-9[1] 15720448 blocks super 1.2 2 near-copies [2/2] [UU] md127 : active (auto-read-only) raid10 dm-16[0] dm-11[1] 551936 blocks super 1.2 2 near-copies [2/2] [UU] unused devices: --- /proc/partitions: major minor #blocks name 8 32 1953514584 sdc 8 338741888 sdc1 8 34 1943748608 sdc2 8 16 1953514584 sdb 8 178741888 sdb1 8 18 1943748608 sdb2 80 244198584 sda 81 524288 sda1 82 249856 sda2 83 243423232 sda3 2510 15728640 dm-0 1101048575 sr0 2511 104857600 dm-1 25123145728 dm-2 2513 10485760 dm-3 2514 10485760 dm-4 2515 52428800 dm-5 2516 31457280 dm-6 2517 524288000 dm-7 2518 209715200 dm-8 2519 15728640 dm-9 251 10 266240 dm-10 251 11 552960 dm-11 251 12 209715200 dm-12 251 13 209715200 dm-13 251 14 15732736 dm-14 251 15 209715200 dm-15 251 16 552960 dm-16 251 17 266240 dm-17 251 18 31457280 dm-18 251 19 104869888 dm-19 251 20 20971520 dm-20 251 21 10485760 dm-21 251 22 52428800 dm-22 251 23 209715200 dm-23 9 127 551936 md127 9 126 15720448 md126 9 125 31449088 md125 9 124 265216 md124 9 123 104792064 md123 9 122 52396032 md122 9 121 209584128 md121 --- LVM physical volumes: PV VG Fmt Attr PSize PFree /dev/sda3 vg_sd0 lvm2 a-- 232.14g 44.14g /dev/sdb2 vg_hd0 lvm2 a--1.81t 1.20t /dev/sdc2 vg_hd1 lvm2 a--1.81t 707.92g --- mount output sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime) proc on /proc type proc (rw,nosuid,nodev,noexec,relatime) udev on /dev type devtmpfs (rw,relatime,size=10240k,nr_inodes=2009492,mode=755) devpts on /dev/pts type
