Bug#1067778: retroarch ftbfs in unstable
Control: forcemerge 1064681 1067778 On Tue, Mar 26, 2024 at 05:20:33PM +0100, Matthias Klose via Pkg-games-devel wrote: > Package: src:retroarch > Version: 1.16.0.3+dfsg-1 > Severity: serious > Tags: sid trixie ftbfs > > retroarch ftbfs in unstable > > [...] > Checking existence of -lglslang ... yes > Checking existence of -lOSDependent ... yes > Checking existence of -lOGLCompiler ... no > Checking existence of -lMachineIndependent ... yes > Checking existence of -lGenericCodeGen ... yes > Checking existence of -lHLSL ... no > Checking existence of -lSPIRV ... yes > Checking existence of -lSPIRV-Tools-opt ... yes > Checking existence of -lSPIRV-Tools ... yes > Notice: System glslang libraries not found, disabling glslang support. > Notice: glslang is disabled, slang support will also be disabled. > Error: glslang is disabled and forced to build with SPIRV-Cross support. > make[1]: *** [debian/rules:48: override_dh_auto_configure] Error 1 > make[1]: Leaving directory '/home/packages/tmp/retroarch-1.16.0.3+dfsg' > make: *** [debian/rules:42: binary] Error 2 > > ___ > Pkg-games-devel mailing list > pkg-games-de...@alioth-lists.debian.net > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-games-devel J. -- 101 things you can't have too much of : 1 - Cable ties.
Bug#1067263: [Pkg-electronics-devel] Bug#1067263: sigrok-firmware-fx2lafw: FTBFS: sdcpp: fatal error: cannot execute 'cc1': execvp: No such file or directory
Control: reassign -1 sdcc This is going to be a result of the 4.4.0 sdcc upload I did over the weekend. On Wed, Mar 20, 2024 at 10:04:12PM +0100, Lucas Nussbaum wrote: > Source: sigrok-firmware-fx2lafw > Version: 0.1.7-1 > Severity: serious > Justification: FTBFS > Tags: trixie sid ftbfs > User: lu...@debian.org > Usertags: ftbfs-20240319 ftbfs-trixie > > Hi, > > During a rebuild of all packages in sid, your package failed to build > on amd64. > > > Relevant part (hopefully): > > make[1]: Entering directory '/<>' > > sdcc -mmcs51 -I./include -I./fx2lib/include -c fx2lafw.c -o fx2lafw.rel > > sdcc -mmcs51 -I./include -I./fx2lib/include -c gpif-acquisition.c -o > > gpif-acquisition.rel > > sdcpp: fatal error: cannot execute 'cc1': execvp: No such file or directory > > compilation terminated. > > sdcpp: fatal error: cannot execute 'cc1': execvp: No such file or directory > > at 1: warning 190: ISO C forbids an empty translation unit > > subprocess error 256 > > compilation terminated. > > at 1: warning 190: ISO C forbids an empty translation unit > > subprocess error 256 > > make[1]: *** [Makefile:991: fx2lafw.rel] Error 1 > > > The full build log is available from: > http://qa-logs.debian.net/2024/03/19/sigrok-firmware-fx2lafw_0.1.7-1_unstable.log > > All bugs filed during this archive rebuild are listed at: > https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=ftbfs-20240319;users=lu...@debian.org > or: > https://udd.debian.org/bugs/?release=na=ign=7=7=only=ftbfs-20240319=lu...@debian.org=1=1=1=1#results > > A list of current common problems and possible solutions is available at > http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute! > > If you reassign this bug to another package, please mark it as 'affects'-ing > this package. See https://www.debian.org/Bugs/server-control#affects > > If you fail to reproduce this, please provide a build log and diff it with > mine > so that we can identify if something relevant changed in the meantime. > > ___ > Pkg-electronics-devel mailing list > pkg-electronics-de...@alioth-lists.debian.net > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-electronics-devel J. -- ] https://www.earth.li/~noodles/ [] Shopping is hard. Let's do Math! [ ] PGP/GPG Key @ the.earth.li[][ ] via keyserver, web or email. [][ ] RSA: 4096/0x94FA372B2DA8B985 [][
Bug#1064731: [Pkg-electronics-devel] Bug#1064731: sdcc: FTBFS: /bin/sh: 1: inkscape: not found
Control: retitle -1 sdcc: FTBFS: Error building LyX documentation On Sun, Feb 25, 2024 at 08:45:34PM +0100, Lucas Nussbaum via Pkg-electronics-devel wrote: > Source: sdcc > Version: 4.2.0+dfsg-1 > Severity: serious > Justification: FTBFS > Tags: trixie sid ftbfs > User: lu...@debian.org > Usertags: ftbfs-20240224 ftbfs-trixie > > Hi, > > During a rebuild of all packages in sid, your package failed to build > on amd64. The inkscape error here is a red herring; even switching from librsvg2-bin back to inkscape doesn't do any better. Something in the LyX -> LaTeX dependency tree must have changed. :( J. -- ... "What the f**k was that?" -- Mayor of Hiroshima
Bug#1064681: retroarch: FTBFS: make[1]: *** [debian/rules:48: override_dh_auto_configure] Error 1
Control: tags -1 - trixie Control: severity -1 important On Sun, Feb 25, 2024 at 08:48:32PM +0100, Lucas Nussbaum via Pkg-games-devel wrote: > Source: retroarch > Version: 1.16.0.3+dfsg-1 > Severity: serious > Justification: FTBFS > Tags: trixie sid ftbfs > User: lu...@debian.org > Usertags: ftbfs-20240224 ftbfs-trixie > > Hi, > > During a rebuild of all packages in sid, your package failed to build > on amd64. This looks like a glslang issue; #1062799 and the associated autopkgtest failures for glslang's migration to trixie (e.g. https://ci.debian.net/packages/g/glslang/testing/amd64/43341664/). I'm dropping this to important until glslang is fixed. > Relevant part (hopefully): > > make[1]: Entering directory '/<>' > > sed 's/@DEB_HOST_MULTIARCH@/x86_64-linux-gnu/g' \ > > retroarch.cfg > debian/retroarch.cfg > > # See ./configure --help for valid flags > > # disable flags (i.e. --disable-ffmpeg for example) if there is no package > > relative to the feature in Build-Depends > > ./configure --prefix=/usr \ > > --disable-builtinmbedtls \ > > --disable-builtinbearssl \ > > --disable-builtinflac \ > > --disable-builtinglslang \ > > --disable-builtinzlib \ > > --disable-update_assets \ > > --disable-oss \ > > --disable-vg \ > > --enable-dbus \ > > --enable-spirv_cross \ > > --enable-vulkan \ > > --enable-sse > > Checking operating system ... Linux > > Checking for suitable working C compiler ... /usr/bin/gcc works > > Checking for suitable working C++ compiler ... /usr/bin/g++ works > > Checking for pkg-config ... /usr/bin/pkgconf > > Checking for availability of switch -std=gnu99 in /usr/bin/gcc ... yes > > Checking for availability of switch -std=c++17 in /usr/bin/g++ ... yes > > Checking for availability of switch -Wno-unused-result in /usr/bin/gcc ... > > yes > > Checking for availability of switch -Wno-unused-variable in /usr/bin/gcc > > ... yes > > Checking function sd_get_machine_names in -lsystemd ... no > > Checking presence of package bcm_host ... no > > Checking function bcm_host_init in -lbcm_host ... no > > Checking presence of header file EGL/eglext.h ... yes > > Checking presence of package egl ... 1.5 > > Checking function ass_library_init in -lfribidi -lass ... no > > Checking existence of -msse -msse2 ... yes > > Checking function pthread_create in -lpthread ... yes > > Checking function pthread_key_create in -lpthread ... yes > > Checking presence of package check >= 0.15 ... no > > Checking presence of header file scsi/sg.h ... yes > > Checking function dlopen in -ldl ... yes > > Checking function socket in -lc ... yes > > Checking function getaddrinfo in -lc ... yes > > Checking function fcntl in -lc ... yes > > Checking function getopt_long in -lc ... yes > > Checking presence of package alsa ... 1.2.10 > > Checking presence of package libsixel >= 1.6.0 ... no > > Checking presence of predefined macro AUDIO_SETINFO in sys/audioio.h ... no > > Checking presence of package rsound >= 1.1 ... no > > Checking presence of package libroar >= 1.0.12 ... no > > Checking presence of package jack >= 0.120.1 ... 1.9.21 > > Checking presence of package libpulse ... 16.1 > > Checking presence of package sdl >= 1.2.10 ... no > > Checking presence of package sdl2 >= 2.0.0 ... 2.30.0 > > Checking presence of package Qt5Core >= 5.2 ... 5.15.10 > > Checking presence of package Qt5Gui >= 5.2 ... 5.15.10 > > Checking presence of package Qt5Widgets >= 5.2 ... 5.15.10 > > Checking presence of package Qt5Concurrent >= 5.2 ... 5.15.10 > > Checking presence of package Qt5Network >= 5.2 ... 5.15.10 > > Checking presence of package openssl >= 1.0.0 ... no > > Checking presence of package flac ... 1.4.3 > > Checking existence of -lmbedtls -lmbedx509 -lmbedcrypto ... no > > Notice: HID is disabled, libusb support will also be disabled. > > Checking existence of -ldinput8 ... no > > Checking existence of -ld3d9 ... no > > Checking existence of -ldsound ... no > > Checking existence of -ld3dx8 ... no > > Checking existence of -ld3dx9 ... no > > Checking presence of header file GL/gl.h ... yes > > Checking existence of -lGL ... yes > > Checking function cgCreateContext in -lCg -lCgGL ... no > > Checking presence of package zlib ... 1.3 > > Checking presence of package libavcodec >= 57 ... 60.31.102 > > Checking presence of package libavformat >= 57 ... 60.16.100 > > Checking presence of package libavdevice >= 57 ... 60.3.100 > > Checking presence of package libswresample >= 2 ... 4.12.100 > > Checking presence of package libavutil >= 55 ... 58.29.100 > > Checking presence of package libswscale >= 4 ... 7.5.100 > > Checking presence of header file libavutil/channel_layout.h ... yes > > Checking function dlopen in -ldl ... yes > > Checking presence of package gbm >= 9.0 ... 24.0.1-1 > > Checking presence of package libdrm ... 2.4.120 > > Checking presence of package dbus-1 ... 1.14.10 > > Checking presence of package libudev ... 255 > > Checking presence of
Bug#1034524: libretro-bsnes-mercury: uses invalid architecture wildcards
Control: severity -1 important On Mon, Apr 17, 2023 at 05:32:06PM +0100, Graham Inggs wrote: > Source: libretro-bsnes-mercury > Version: 094+git20220807-6 > Severity: serious > > Hi Maintainer > > Since the upload of 094+git20220807-6, the > kodi-game-libretro-bsnes-mercury-* binary packages are no longer built > on armel and armhf [1][2][3]. This is due to the use of invalid > architecture wildcards 'any-armel' and 'any-armhf'. These should be > replaced by 'any-arm' for each of three This is an unfortunate mistake on my part, but given the stage we're at in the release process, the fact these are leaf packages and the fact the packages didn't ship as part of bullseye I don't think this counts as release critical. > kodi-game-libretro-bsnes-mercury-* binary packages in debian/control, > as follows: > > -Architecture: any-amd64 any-arm64 any-armel any-armhf any-i386 > any-powerpc any-ppc64 any-ppc64el any-riscv64 any-s390x any-sparc64 > > +Architecture: any-amd64 any-arm64 any-arm any-i386 any-powerpc > any-ppc64 any-ppc64el any-riscv64 any-s390x any-sparc64 > > Regards > Graham > > > [1] > https://packages.debian.org/unstable/kodi-game-libretro-bsnes-mercury-accuracy > [2] > https://packages.debian.org/unstable/kodi-game-libretro-bsnes-mercury-balanced > [3] > https://packages.debian.org/unstable/kodi-game-libretro-bsnes-mercury-performance J. -- ... If we sleep together, will you like me better?
Bug#1032731: Fails to start: AttributeError: 'TrezorctlGroup' object has no attribute 'resultcallback'
Package: trezor
Version: 0.12.4-1
Severity: grave
X-Debbugs-Cc: nood...@earth.li
Control: forwarded -1 https://github.com/trezor/trezor-firmware/issues/2199
Installed trezor and tried to run it, got a traceback:
$ trezorctl
Traceback (most recent call last):
File "/usr/bin/trezorctl", line 33, in
sys.exit(load_entry_point('trezor==0.12.4', 'console_scripts',
'trezorctl')())
^^
File "/usr/bin/trezorctl", line 25, in importlib_load_entry_point
return next(matches).load()
File "/usr/lib/python3.11/importlib/metadata/__init__.py", line 202, in load
module = import_module(match.group('module'))
File "/usr/lib/python3.11/importlib/__init__.py", line 126, in import_module
return _bootstrap._gcd_import(name[level:], package, level)
File "", line 1206, in _gcd_import
File "", line 1178, in _find_and_load
File "", line 1149, in _find_and_load_unlocked
File "", line 690, in _load_unlocked
File "", line 940, in exec_module
File "", line 241, in _call_with_frames_removed
File "/usr/lib/python3/dist-packages/trezorlib/cli/trezorctl.py", line 171,
in
@cli.resultcallback()
^^
AttributeError: 'TrezorctlGroup' object has no attribute 'resultcallback'. Did
you mean: 'result_callback'?
Looks like this is an issue with the Click usage and was fixed upstream in
0.13.1.
-- System Information:
Debian Release: bookworm/sid
APT prefers testing-security
APT policy: (500, 'testing-security'), (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 6.1.0-5-amd64 (SMP w/16 CPU threads; PREEMPT)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8),
LANGUAGE=en_GB:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages trezor depends on:
ii python3 3.11.2-1
ii python3-trezor 0.12.4-1
trezor recommends no packages.
trezor suggests no packages.
-- no debconf information
Bug#994758: Bug#1031927: Handling the libsgutils2-2 #994758 bookworm-ignore
On Wed, Mar 01, 2023 at 08:07:09AM +, Jonathan McDowell wrote: > On Mon, Feb 27, 2023 at 09:11:46PM +0100, Paul Gevers wrote: > > On 25-02-2023 14:30, Adrian Bunk wrote: > > > With the bookworm-ignore for #994758, > > > > I'll admit that I misjudged that bug; with this message I'll clear the > > bookworm-ignore tag. > > > > > bullseye and bookworm > > > will ship libsgutils2-2 packages with different so-name. > > > > Although the transition freeze has started long time ago, it seems that > > doing a proper transition is the best way to fix this issue. If somebody is > > up to the task to prepare the upload, we can ask ftp-master to process the > > upload swiftly. (Please upload to experimental to avoid the ftp-master from > > rejecting the package immediately and to enable reviewing if that's not done > > before the upload.) > > This does not look overly hard and I have some familiarity with the > package having uploaded in the past. If no one else is already looking > at it I'll aim to have a version with a libsgutils2-1.46 library package > uploaded to experimental by the end of today. Now sitting in NEW for experimental: https://ftp-master.debian.org/new/sg3-utils_1.46-2.html I have confirmed: * It will not co-exist with the libsgutils2-2 package in bookworm (thanks to the versioned breaks/replaces) * It will co-exist with the libsgutils2-2 package in bullseye (which is 1.45-1 and has no overlapping files) * Operation of the sg3-utils package with this new build It turns out I do not have access to the salsa git repo at present, but I've requested it and will push the changes there when it is granted. J. -- No one told you when to run, you missed the starting gun. This .sig brought to you by the letter L and the number 39 Product of the Republic of HuggieTag signature.asc Description: PGP signature
Bug#994758: Bug#1031927: Handling the libsgutils2-2 #994758 bookworm-ignore
On Mon, Feb 27, 2023 at 09:11:46PM +0100, Paul Gevers wrote: > Control: tags 994758 - bookworm-ignore > > Hi Adrian, > > Thanks for caring. > > On 25-02-2023 14:30, Adrian Bunk wrote: > > With the bookworm-ignore for #994758, > > I'll admit that I misjudged that bug; with this message I'll clear the > bookworm-ignore tag. > > > bullseye and bookworm > > will ship libsgutils2-2 packages with different so-name. > > Although the transition freeze has started long time ago, it seems that > doing a proper transition is the best way to fix this issue. If somebody is > up to the task to prepare the upload, we can ask ftp-master to process the > upload swiftly. (Please upload to experimental to avoid the ftp-master from > rejecting the package immediately and to enable reviewing if that's not done > before the upload.) This does not look overly hard and I have some familiarity with the package having uploaded in the past. If no one else is already looking at it I'll aim to have a version with a libsgutils2-1.46 library package uploaded to experimental by the end of today. J. -- /-\ | If at first you don't succeed, |@/ Debian GNU/Linux Developer | create an "NT" version. \- | signature.asc Description: PGP signature
Bug#978819: marked as pending in gcc-xtensa-lx106
Control: tag -1 pending Hello, Bug #978819 in gcc-xtensa-lx106 reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/electronics-team/toolchains/gcc-xtensa-lx106/-/commit/d49af29d02fefbfc78e7d4d736aa467e5da787bb Depend on autoconf2.69 instead of just autoconf. (Closes: #978819) Both gcc-10 and gcc-11 in unstable do this, so alter our dependency now autoconf 2.71 is in unstable. (this message was generated automatically) -- Greetings https://bugs.debian.org/978819
Bug#980589: [Pkg-electronics-devel] Bug#980589: libsigrok: FTBFS: tests/strutil.c:157:2: error: too few arguments to function ‘_ck_assert_failed’
This is a result of the new "check" 0.15.2 package (updated from 0.12.0), in particular upstream commit 82540c5428d3818b64d6a8aefb601e722520651f: https://github.com/libcheck/check/commit/82540c5428d3818b64d6a8aefb601e722520651f "For users of these APIs who do pass a message there will be a new warning about too many arguments." Gee, thanks. These are deprecated functions so I'll look at getting sigrok updated to use the new ones. On Wed, Jan 20, 2021 at 09:28:27PM +0100, Lucas Nussbaum wrote: > Source: libsigrok > Version: 0.5.2-2 > Severity: serious > Justification: FTBFS on amd64 > Tags: bullseye sid ftbfs > Usertags: ftbfs-20210120 ftbfs-bullseye > > Hi, > > During a rebuild of all packages in sid, your package failed to build > on amd64. > > Relevant part (hopefully): > > gcc -DHAVE_CONFIG_H -Iinclude -I./include -I./src -I. > > -Ibindings/cxx/include -I./bindings/cxx/include -Ibindings/cxx > > -DFIRMWARE_DIR='"/usr/share/sigrok-firmware"' -Wdate-time > > -D_FORTIFY_SOURCE=2 -std=c99 -fvisibility=hidden -Wall -Wextra > > -Wmissing-prototypes -pthread -I/usr/include/libftdi1 -I/usr/include/hidapi > > -I/usr/include/libusb-1.0 -I/usr/include/libmount -I/usr/include/blkid > > -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -g -O2 > > -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat > > -Werror=format-security -c -o tests/driver_all.o tests/driver_all.c > > In file included from tests/strutil.c:21: > > tests/strutil.c: In function ‘test_sr_vsnprintf_ascii’: > > tests/strutil.c:63:4: warning: too many arguments for format > > [-Wformat-extra-args] > >63 |"Invalid result for '%s': len = %i.", expected, len); > > |^~~~ > > tests/strutil.c:65:4: warning: too many arguments for format > > [-Wformat-extra-args] > >65 |"Invalid result for '%s': %s.", expected, s); > > |^~ > > tests/strutil.c: In function ‘test_sr_vsprintf_ascii’: > > tests/strutil.c:87:4: warning: too many arguments for format > > [-Wformat-extra-args] > >87 |"Invalid result for '%s': len = %i.", expected, len); > > |^~~~ > > tests/strutil.c:89:4: warning: too many arguments for format > > [-Wformat-extra-args] > >89 |"Invalid result for '%s': %s.", expected, s); > > |^~ > > tests/strutil.c: In function ‘test_samplerate’: > > tests/strutil.c:100:7: warning: too many arguments for format > > [-Wformat-extra-args] > > 100 | "Invalid result for '%s': %s.", expected, s); > > | ^~ > > tests/strutil.c: In function ‘test_period’: > > tests/strutil.c:111:7: warning: too many arguments for format > > [-Wformat-extra-args] > > 111 | "Invalid result for '%s': %s.", expected, s); > > | ^~ > > tests/strutil.c: In function ‘test_rational’: > > tests/strutil.c:121:28: warning: too many arguments for format > > [-Wformat-extra-args] > > 121 | fail_unless(ret == SR_OK, "Unexpected rc for '%s': %d, errno %d.", > > |^~~ > > tests/strutil.c:124:7: warning: too many arguments for format > > [-Wformat-extra-args] > > 124 | "Invalid result for '%s': %ld/%ld'.", > > | ^~~~ > > tests/strutil.c: In function ‘test_rational_fail’: > > tests/strutil.c:134:28: warning: too many arguments for format > > [-Wformat-extra-args] > > 134 | fail_unless(ret != SR_OK, "Unexpected success for '%s'.", input); > > |^~ > > tests/strutil.c: In function ‘test_voltage’: > > tests/strutil.c:144:7: warning: too many arguments for format > > [-Wformat-extra-args] > > 144 | "Invalid result for '%s': %s.", expected, s); > > | ^~ > > tests/strutil.c: In function ‘test_locale_fn’: > > tests/strutil.c:157:2: error: too few arguments to function > > ‘_ck_assert_failed’ > > 157 | ck_assert_msg(saved_locale != NULL); > > | ^ > > /usr/include/check.h:505:27: note: declared here > > 505 | CK_DLL_EXP void CK_EXPORT _ck_assert_failed(const char *file, int > > line, > > | ^ > > gcc -DHAVE_CONFIG_H -Iinclude -I./include -I./src -I. > > -Ibindings/cxx/include -I./bindings/cxx/include -Ibindings/cxx > > -DFIRMWARE_DIR='"/usr/share/sigrok-firmware"' -Wdate-time > > -D_FORTIFY_SOURCE=2 -std=c99 -fvisibility=hidden -Wall -Wextra > > -Wmissing-prototypes -pthread -I/usr/include/libftdi1 -I/usr/include/hidapi > > -I/usr/include/libusb-1.0 -I/usr/include/libmount -I/usr/include/blkid > > -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -g -O2 > > -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat > > -Werror=format-security -c -o
Bug#978512: marked as pending in gcc-xtensa-lx106
Control: tag -1 pending Hello, Bug #978512 in gcc-xtensa-lx106 reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/electronics-team/toolchains/gcc-xtensa-lx106/-/commit/ca827700133f639db1340ea90d80393908df9aa0 Update to GCC 10 (Closes: #978512) (this message was generated automatically) -- Greetings https://bugs.debian.org/978512
Bug#975199: [Pkg-electronics-devel] Bug#975199: pulseview: FTBFS: dh_auto_configure: error: cd obj-x86_64-linux-gnu && cmake -DCMAKE_INSTALL_PREFIX=/usr -DCMAKE_BUILD_TYPE=None -DCMAKE_INSTALL_SYSCONF
Control: severity -1 important On Thu, Nov 19, 2020 at 10:47:32AM +0100, Lucas Nussbaum wrote: > Source: pulseview > Version: 0.4.2-1 > Severity: serious > Justification: FTBFS on amd64 > Tags: bullseye sid ftbfs > Usertags: ftbfs-20201119 ftbfs-bullseye > > Hi, > > During a rebuild of all packages in sid, your package failed to build > on amd64. I think this has managed to happen during the Python3.9 default transition. In particular: > > -- Package 'python-3.8-embed', required by 'libsigrokdecode', not found libsigrokdecode has only just been updated to fix this, but it seems a build-dep on python3-dev is not actually sufficient to tie the versioning together for the -dev package i.e. the build dependency check should have failed rather than it getting this far. J. -- Web [ 101 things you can't have too much of : 31 - Hot showers. ] site: https:// [ ] Made by www.earth.li/~noodles/ [ ] HuggieTag 0.0.24
Bug#972769: Still fine in unstable
Control: severity -1 important Control: tag -1 pending This is still building fine with the python3-defaults in unstable so doesn't warrant the serious severity. Upstream has a minor fix to enable Python3.9 which I will pull in. J. -- /-\ | 101 things you can't have too much |@/ Debian GNU/Linux Developer | of : 18 - Roleplaying. \- |
Bug#959622: marked as pending in gcc-xtensa-lx106
Control: tag -1 pending Hello, Bug #959622 in gcc-xtensa-lx106 reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/electronics-team/toolchains/gcc-xtensa-lx106/-/commit/4afbfe037e224e90f107fca9f57d2bf2a9d958c2 Update force-m32 patch for GCC 9.3.0 (Closes: #959622) (this message was generated automatically) -- Greetings https://bugs.debian.org/959622
Bug#944181: [Pkg-electronics-devel] Bug#944181: ghdl: non-standard gcc/g++ used for build (gcc-8)
Control: block -1 with 954826 On Thu, Mar 26, 2020 at 10:48:27PM +0100, Emilio Pozuelo Monfort wrote: > On Tue, 05 Nov 2019 13:23:02 + Matthias Klose wrote: > > Package: ghdl > > Severity: important > > Tags: sid bullseye > > User: debian-...@lists.debian.org > > Usertags: non-standard-compiler, gcc-8, gcc-8-legacy > > > > This package builds with a non standard compiler version; please check > > if this package can be built with the default version of gcc/g++, or > > with gcc-9/g++-9. > > > > Please keep this report open until the package uses the default > > compiler version (or gcc-9) for the package build. > > > > If the package cannot be built anymore, please file a bug report for > > ftp.debian.org, asking for the removal of the package. > > > > The severity of this report is likely to be raised before the release, > > so that the gcc-8 package can be removed for the release. > > GCC 8 is being removed, so this is now serious. I started pulling in 0.37 from upstream and switching to GCC 9, but unfortunately #954826 currently means GHDL can't compile as it wants LLVM which then wants libgcc-8-dev which is now uninstallable. J. -- Is it real, or is it Mimozine?
Bug#951980: [Pkg-electronics-devel] Bug#951980: sigrok-cli: FTBFS: configure: error: Package requirements (glib-2.0 >= 2.32.0 libsigrok >= 0.5.0 libsigrokdecode >= 0.5.0) were not met
Control: reassign -1 libsigrok-dev Control: retitle -1 Missing bluetooth + hidapi deps on -dev package cause FTBFSes On Sun, Feb 23, 2020 at 07:53:00AM +0100, Lucas Nussbaum wrote: > Source: sigrok-cli > Version: 0.7.1-1 > Severity: serious > Justification: FTBFS on amd64 > Tags: buster sid > Usertags: ftbfs-20200222 ftbfs-buster This has been caused by the update to libsigrok 0.5.2 with bluetooth + hidapi support, and missing deps on the -dev. J. -- "Remind me never to buy software from you." -- Geraint Jones, marking an Operating Systems question.
Bug#930890: [Pkg-electronics-devel] Bug#930890: Bug#930890: ghdl: Debian ghdl.wrapper prevents build when GHDL is not already installed.
On Sat, Sep 28, 2019 at 07:02:31AM +0200, Gianfranco Costamagna wrote: > control: severity -1 serious > control: found -1 0.35+git20181129+dfsg-3 > > I know this isn't the right bug, but since this bug is about a non-existing > version that FTBFS, lets recycle it :) I think you wanted to alter #923190 instead, which is about adding LLVM 8 support. J. -- ... 101 things you can't have too much of : 38 - clean underwear.
Bug#935274: [Pkg-electronics-devel] Bug#935274: binutils-xtensa-lx106: FTBFS on amd64
On Wed, Aug 21, 2019 at 10:40:29AM +, Ivo De Decker wrote: > A binnmu of binutils-xtensa-lx106 in unstable fails on amd64: > > https://buildd.debian.org/status/package.php?p=binutils-xtensa-lx106 > > It probably needs to be updated for the newer binutils. binutils has helpfully changed its version string to not match the directory the source untars to. I had a look at fixing this up yesterday but then hit a problem compiling readelf (which isn't patched by binutils-xtensa-lx106). I'll try to fight it some more this week. J. -- 101 things you can't have too much of : 10 - CDs.
Bug#930890: [Pkg-electronics-devel] Bug#930890: ghdl: Debian ghdl.wrapper prevents build when GHDL is not already installed.
Control: severity -1 wishlist Control: retitle -1 Update GHDL packaging for newer releases On Sun, Jun 23, 2019 at 11:57:33PM +0200, Pavel Pisa wrote: > On Sunday 23 of June 2019 10:52:47 Jonathan McDowell wrote: > > On Sat, Jun 22, 2019 at 12:26:36AM +0200, Pavel Pisa wrote: > > > Source: ghdl > > > Version: 0.36+20190617 > > > > This is not a version of GHDL from Debian. testing/unstable both have > > 0.35+git20181129+dfsg-3. I don't think this is a valid bug against the > > Debian package - it seems that you've obtained an updated package from > > somewhere else, or have manually updated to a newer release? > > I have used original Debian package as "debian" directory > source to port newer GHDL version for Debian Buster. > > I am not sure if the problem applies to old version, > but solution should work for all versions. I have built older > version but on the system where GHDL has already been installed. > So I expect that the problem may be there as well. You have raised a release critical bug stating the package currently in Debian fails to build from source. I think what you wanted to raise was a wishlist bug requesting the packaging be updated to support newer versions of GHDL. Retitling and updating the severity to indicate this fact. This can be looked at once we have Buster released. (I've confirmed that I can still build 0.35+git20181129+dfsg-3 in a clean sbuild environment, so the FTBFS does not apply to the Debian package and thus there's no need to fix it to ensure it's ok for Buster.) J. -- /-\ | Evil is as evil does, but evil |@/ Debian GNU/Linux Developer | doesn't wear shoes. \- |
Bug#930890: [Pkg-electronics-devel] Bug#930890: ghdl: Debian ghdl.wrapper prevents build when GHDL is not already installed.
On Sat, Jun 22, 2019 at 12:26:36AM +0200, Pavel Pisa wrote: > Source: ghdl > Version: 0.36+20190617 This is not a version of GHDL from Debian. testing/unstable both have 0.35+git20181129+dfsg-3. I don't think this is a valid bug against the Debian package - it seems that you've obtained an updated package from somewhere else, or have manually updated to a newer release? > Severity: serious > Tags: ftbfs > Justification: fails to build from source (but built successfully in the past) > > When Debianized GHDL package is build it fails with message > > Error: No installed ghdl backend found. Terminating! > > in context > > install -m 755 -p libghdl-0_37_dev.so ../../debian/tmp/usr/lib/ghdl/mcode/ > ../../debian/tmp/usr/bin/ghdl --disp-standard --std=87 > > ../../debian/tmp/usr/lib/ghdl/mcode/vhdl/src/std/standard.v87 > Error: No installed ghdl backend found. Terminating! > make[2]: *** [Makefile:131: install] Error 2 > make[2]: Leaving directory '/home/user/repo/ghdl/ghdl-git/builddir/mcode' > make[1]: *** [debian/rules:140: override_dh_auto_install] Error 2 > make[1]: Leaving directory '/home/user/repo/ghdl/ghdl-git' > make: *** [debian/rules:54: binary] Error 2 > dpkg-buildpackage: error: fakeroot debian/rules binary subprocess returned > exit status 2 > > The reason for the problem is the file /debian/ghdl.wrapper which prevents > install when there is not already installed some "ghdl" package because > it ignores "ghdl-mcode" already redy to be run in "debian/tmp/usr/bin" > directory. J. -- /-\ | I am afraid of the dark. |@/ Debian GNU/Linux Developer | \- |
Bug#924337: debdiff re-enabling mqtt/varnish plugins
Attached patch re-enables the plugins and builds fine for me within sbuild on sid (and works fine for MQTT on buster). J. -- Professional Geek + recovering Law Student https://www.linkedin.com/in/noodles 101 things you can't have too much of : 51 - News. diff -Nru collectd-5.8.1/debian/changelog collectd-5.8.1/debian/changelog --- collectd-5.8.1/debian/changelog 2018-12-25 11:08:23.0 + +++ collectd-5.8.1/debian/changelog 2019-04-03 21:56:47.0 +0100 @@ -1,3 +1,10 @@ +collectd (5.8.1-1.3) unstable; urgency=medium + + * Non-maintainer upload. + * Re-enable mqtt + varnish plugins. (Closes: #924337) + + -- Jonathan McDowell Wed, 03 Apr 2019 21:56:47 +0100 + collectd (5.8.1-1.2) unstable; urgency=medium * Non-maintainer upload. diff -Nru collectd-5.8.1/debian/control collectd-5.8.1/debian/control --- collectd-5.8.1/debian/control 2018-12-19 14:51:04.0 + +++ collectd-5.8.1/debian/control 2019-04-03 21:55:59.0 +0100 @@ -32,6 +32,7 @@ libmicrohttpd-dev, libmodbus-dev, libmongoc-dev, + libmosquitto-dev, libmnl-dev [linux-any], libnotify-dev, libopenipmi-dev, @@ -54,7 +55,7 @@ libtokyotyrant-dev [linux-any], libudev-dev [linux-any], libupsclient-dev | libupsclient1-dev, -# libvarnishapi-dev, + libvarnishapi-dev, libvirt-dev (>= 0.4.0-6) [linux-any], libxen-dev [amd64 arm64 armhf i386], libxml2-dev, diff -Nru collectd-5.8.1/debian/rules collectd-5.8.1/debian/rules --- collectd-5.8.1/debian/rules 2018-12-19 14:51:28.0 + +++ collectd-5.8.1/debian/rules 2019-04-03 21:56:12.0 +0100 @@ -88,14 +88,6 @@ # Cf. https://github.com/collectd/collectd/issues/1574 confflags += --disable-sigrok -# temporarily disable varnish plugin, as #879471 blocks collectd from -# migrating to testing. -confflags += --disable-varnish - -# temporarily disable mqtt plugin, as #911265, #911266 blocks collectd from -# migrating to testing. -confflags += --disable-mqtt - # disable lvm plugin, liblvm2app is deprecated upstream, #915692 # Cf. https://github.com/collectd/collectd/issues/2647 confflags += --disable-lvm
Bug#921851: [Pkg-electronics-devel] Bug#921851: unnecessary b-d's libisl-0.18-dev and libcloog-isl-dev, to be removed for buster
On Sat, Feb 09, 2019 at 01:39:34PM +0100, Matthias Klose wrote: > Package: src:binutils-xtensa-lx106 > Version: 1 > Severity: serious > Tags: sid buster > unnecessary b-d's libisl-0.18-dev and libcloog-isl-dev, to be removed > for buster Where should I have been paying attention to find this out? It seems prudent to do the removal well enough in advance of the freeze rather than the packages in question still being present less than a week before soft freeze. J. -- Web [Why are we here? Because we're here. Roll the bones.] site: https:// [ ] Made by www.earth.li/~noodles/ [ ] HuggieTag 0.0.24
Bug#917692: [Pkg-electronics-devel] Bug#917692: sdcc: FTBFS: LaTeX Error: File `footnotehyper.sty' not found.
On Sat, Dec 29, 2018 at 10:39:07PM +0100, Lucas Nussbaum wrote:
> During a rebuild of all packages in sid, your package failed to build
> on amd64.
...
> > ! LaTeX Error: File `footnotehyper.sty' not found.
> >
> > Type X to quit or to proceed,
> > or enter new name. (Default extension: sty)
> >
> > Enter file name:
> > ! Emergency stop.
> >
> >
> > l.22 \usepackage
> > {amstext}^^M
> > No pages of output.
> > Transcript written on sdccman.log.
> > make[1]: *** [Makefile:67: sdccman.dvi] Error 1
Looks like lyx has changed again; we now need a build-dep on
texlive-latex-extra for this (lyx only recommends it).
J.
--
No program done by a hacker will | .''`. Debian GNU/Linux Developer
work unless he is on the system. | : :' : Happy to accept PGP signed
| `. `' or encrypted mail - RSA
| `-key on the keyservers.
Bug#909995: LyX issues with Python 3 move
Control: retitle -1 Clean LyX install fails to configure correctly
Control: reassign -1 lyx
Control: tag -1 patch
Control: affects -1 sdcc
Confirmed that this is a LyX issue. A fresh install of LyX results in
the same /usr/share/lyx/configure.py failure, and removing ~/.lyx/ on an
existing install reproduces the issue. It does not occur when ~/.lyx/ is
already setup. Problem is related to the move to Python 3 and
comparisons of bytes and strings.
Following patch fixes things for me:
-
--- configure.py.old2018-10-05 10:45:21.568724157 +0100
+++ configure.py2018-10-05 10:40:04.494039200 +0100
@@ -1312,8 +1312,8 @@
prereq_latex = b','.join(prereq_list)
prereq_docbook = {'true':b'', 'false':b'docbook'}[bool_docbook]
prereq = {b'LaTeX':prereq_latex,
b'DocBook':prereq_docbook}[classtype]
-classdeclaration = (b'"%s" "%s" "%s" "%s" "%s"'
- % (classname, opt, desc, avai, prereq))
+classdeclaration = ('"%s" "%s" "%s" "%s" "%s"'
+ % (classname, opt, desc, avai, prereq)).encode()
if categorydeclaration != b'""':
return classdeclaration + b" " + categorydeclaration
if qres != None:
@@ -1367,7 +1367,7 @@
foundClasses.append(cleanclass)
retval = processLayoutFile(file, bool_docbook)
if retval != b"":
-tx.write(retval + os.linesep)
+tx.write(retval + os.linesep.encode())
tx.close()
logger.info('\tdone')
if not os.path.isfile('packages.lst') or not check_config:
-
J.
--
/-\ | Trust me, you wouldn't like us
|@/ Debian GNU/Linux Developer | when we're angry.
\- |
Bug#909995: Looks like LyX?
Weird. This built fine in my sbuild environment for upload to the archive, but is now failing, so looks like one of the deps has changed. The failing build log includes: Traceback (most recent call last): File "/usr/share/lyx/configure.py", line 1886, in ret = checkLatexConfig(lyx_check_config and LATEX != '', bool_docbook) File "/usr/share/lyx/configure.py", line 1368, in checkLatexConfig retval = processLayoutFile(file, bool_docbook) File "/usr/share/lyx/configure.py", line 1316, in processLayoutFile % (classname, opt, desc, avai, prereq)) TypeError: %b requires a bytes-like object, or an object that implements __bytes__, not 'str' support/Systemcall.cpp (294): Systemcall: 'python3 -tt "/usr/share/lyx/configure.py" --binary-dir="/usr/bin/"' finished with exit code 1 LyX: Done! LayoutFile.cpp (172): LayoutFileList::Read: no textclasses found! Error: Document class not found and later: Error: Cannot convert file No information for converting svg format files to eps. Define a converter in the preferences. which implies LyX wants something extra now. Will poke. J. -- They say that sex is like napalm.
Bug#897838: Pulseview GCC8 fix pending
Control: tags -1 + pending Control: block -1 by 897895 I've backported the upstream fix to 0.4.0 but the build still fails due to #897895 in libsigc++2.0. It's fixed upstream so once that hits unstable I can upload: https://github.com/libsigcplusplus/libsigcplusplus/issues/1 J. -- Life would be easier if I had | .''`. Debian GNU/Linux Developer the source code. | : :' : Happy to accept PGP signed | `. `' or encrypted mail - RSA | `-key on the keyservers.
Bug#887488: marked as pending
tag 887488 pending thanks Hello, Bug #887488 reported by you has been fixed in the Git repository. You can see the changelog below, and you can check the diff of the fix at: https://anonscm.debian.org/cgit/pkg-electronics/openocd.git/commit/?id=ca095a1 --- commit ca095a1fcbf9bc80d4bae493c2833e615b54b51f Author: Jonathan McDowell <nood...@earth.li> Date: Thu Jan 18 09:40:26 2018 + Prevent some forms of Cross Protocol Scripting attacks (Closes: #887488) OpenOCD does not detect when a browser attempts to send data to it using HTTP POST, allowing for a cross-protocol scripting attack. This is mitigated by detecting a POST or Host: "command", neither of which are valid but will come as part of the HTTP POST, and terminating the telnet connection if they are seen. (CVE-2018-570) diff --git a/debian/changelog b/debian/changelog index 2d45901..f451a14 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,6 +1,8 @@ -openocd (0.10.0-4) UNRELEASED; urgency=medium +openocd (0.10.0-4) UNRELEASED; urgency=high * Bind to localhost by default + * Prevent some forms of Cross Protocol Scripting attacks (CVE-2018-5704) +(Closes: #887488) -- Jonathan McDowell <nood...@earth.li> Thu, 18 Jan 2018 09:27:37 +
Bug#887488: [Pkg-electronics-devel] Bug#887488: openocd: CVE-2018-5704 cross protocol scripting attack
On Wed, Jan 17, 2018 at 10:50:44AM +0100, Guido Günther wrote: > the following vulnerability was published for openocd. > > CVE-2018-5704[0]: > | Open On-Chip Debugger (OpenOCD) 0.10.0 does not block attempts to use > | HTTP POST for sending data to 127.0.0.1 port , which allows remote > | attackers to conduct cross-protocol scripting attacks, and consequently > | execute arbitrary commands, via a crafted web site. > > If you fix the vulnerability please also make sure to include the > CVE (Common Vulnerabilities & Exposures) id in your changelog entry. > > For further information see: > > [0] https://security-tracker.debian.org/tracker/CVE-2018-5704 > https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-5704 > > Please adjust the affected versions in the BTS as needed. I see Salvatore has marked this as affecting 0.10.0-3, I'm not sure there's any reason to believe 0.9.0-1 isn't affected as well but I will need to check later today. Upstream still seem to be discussing the best fix but I think at least: http://openocd.zylin.com/#/c/4335/ and http://openocd.zylin.com/#/c/4331/ seem appropriate pending anything more complete. J. -- Revd Jonathan McDowell, ULC | I've got a trigger inside.
Bug#878348: Patch was provided in 873717
Just to note that I provided prior warning of this in 873717, a pointer to upstream's report about it and also a patch in upstream's tracker. J. -- After a number of decimal places, nobody gives a damn. This .sig brought to you by the letter M and the number 25 Product of the Republic of HuggieTag
Bug#871172: Uploading pending on dependencies
Just as a piece of additional information I have an updated Pulseview 0.4 pending which fixes the FTBFS + does various other cleanups. Its upload is pending on acceptance of updated libsigrok + libsigrokdecode packages, both of which are currently sitting in NEW. J. -- ... Sunday morning is every day for all I care... and I'm not scared.
Bug#817837: closed by Jonathan McDowell <nood...@earth.li> (Bug#817837: fixed in l2tpns 2.2.1-2)
On Thu, May 25, 2017 at 06:54:53PM +0300, Adrian Bunk wrote: > On Thu, May 18, 2017 at 08:02:49PM +0100, Jonathan McDowell wrote: > > On Sun, May 14, 2017 at 09:15:50PM +0300, Adrian Bunk wrote: > > > On Tue, Jul 05, 2016 at 10:09:57AM +, Debian Bug Tracking System > > > wrote: > > > >... > > > > l2tpns (2.2.1-2) unstable; urgency=low > > > > . > > > >* Fix log buffer overrun, thanks to Dave Reeve (closes: #817837) > > > >... > > > > > > Hi Jonathan, > > > > > > thanks a lot for fixing this bug for stretch. > > > > > > It is still present in jessie, could you also fix it there? > > > Alternatively, I can fix it for jessie if you don't object. > > > > I had avoided fixing it on jessie because it wasn't clear to me it would > > be permitted by the stable-release masters, > > It looks like a rightfully RC bug to me and has a one-line fix. > > > and there had been little > > indication there was active use of the package (I'm planning to have it > > removed post stretch as no one has stepped up to my intent to orphan > > it). If you want to take the package over entirely you're more than > > welcome to do so. > > I am just going through RC bugs in jessie, trying to fix some of them. > > According to popcon l2tpns has some users left. Feel free to go for it then. > If you want to get rid of the package, it would be perfectly fine if > you retitle the RFA to O to make it clear that you do no longer want > to be responsible for l2tpns and that QA should maintain it instead. That's been the plan once stretch released, or a complete removal request. J. -- "Commercial IP providers are writing 'Halloween' documents about our development model" -- opencores.org third phase goal.
Bug#817837: closed by Jonathan McDowell <nood...@earth.li> (Bug#817837: fixed in l2tpns 2.2.1-2)
On Sun, May 14, 2017 at 09:15:50PM +0300, Adrian Bunk wrote: > On Tue, Jul 05, 2016 at 10:09:57AM +, Debian Bug Tracking System wrote: > >... > > l2tpns (2.2.1-2) unstable; urgency=low > > . > >* Fix log buffer overrun, thanks to Dave Reeve (closes: #817837) > >... > > Hi Jonathan, > > thanks a lot for fixing this bug for stretch. > > It is still present in jessie, could you also fix it there? > Alternatively, I can fix it for jessie if you don't object. I had avoided fixing it on jessie because it wasn't clear to me it would be permitted by the stable-release masters, and there had been little indication there was active use of the package (I'm planning to have it removed post stretch as no one has stepped up to my intent to orphan it). If you want to take the package over entirely you're more than welcome to do so. J. -- Web [Know Thy User.] site: http:// [ ] Made by www.earth.li/~noodles/ [ ] HuggieTag 0.0.24
Bug#854354: sssd prevents system booting up
Package: sssd Version: 1.50.0-2 Severity: grave I updated my stretch system this morning which led to it failing to reach a login prompt; the system would start up and then avahi-daemon, ModemManager and NetworkManager would all fail to start, then systemd-logind would fail. This repeated in a continuous loop. Initially suspecting ModemManager or NetworkManager I tried removing them (the machine has wired ethernet, configured via /etc/network/interfaces), but this did not help. Looking at the errors provided by systemd in my logs led me to: https://lists.debian.org/debian-user/2017/02/msg00025.html which provided the clue I needed to try downgrading ssd from 1.15.0-2 (which was pulled in by the update this morning) to 1.14.2-1 (the previously installed version). The machine subquently rebooted cleanly. A coworker's machine was similiarly affected, and the same solution worked there. There seems to be a lack of errors in logs relating to sssd, but I can try to provide any extra information that might be helpful. In particular daemon.log contained many, many instances of: apus systemd[1]: Looping too fast. Throttling execution a little. -- System Information: Debian Release: 9.0 APT prefers testing APT policy: (900, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.9.0-1-amd64 (SMP w/8 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 sssd depends on: ii python-sss 1.14.2-1 ii sssd-ad 1.14.2-1 ii sssd-common 1.14.2-1 ii sssd-ipa 1.14.2-1 ii sssd-krb51.14.2-1 ii sssd-ldap1.14.2-1 ii sssd-proxy 1.14.2-1 sssd recommends no packages. sssd suggests no packages. -- no debconf information
Bug#811960: pulseview NMU?
On Mon, Nov 07, 2016 at 11:55:13PM +0100, Uwe Hermann wrote: > On Mon, Nov 07, 2016 at 04:25:14PM +0000, Jonathan McDowell wrote: > > Uwe, do you have any plans for this? > > Yeah, might upload some new packages soonish, but long-term > I'd be happy to hand over the full sigrok suite of packages to another > interested + active developer, so I can focus more on upstream development. Sorry for the delay in a reply; I've been kicking around thoughts about the best response. I am interested in having up to date tools such as the sigrok suite in Debian, but don't use them enough to be able to justify taking over maintainership. I'd like to help out where possible though. I was wondering if perhaps some sort of team maintenance would be appropriate for these sorts of tools (and maybe things like openocd as well) - there's the existing pkg-electronics-devel (cc'd) that might be a suitable home? I'd be prepared to try and help keep up to date with upstream releases in such an environment. J. -- /-\ | Design a system any fool can use, |@/ Debian GNU/Linux Developer | and only a fool will want to use \- | it. signature.asc Description: Digital signature
Bug#811960: pulseview NMU?
Graham, is there any reason you haven't performed an NMU with your patch? I've applied it successfully to pulseview 0.2.0-1.1 (currently in sid) and thrown it at my sbuild setup and it builds fine, and it would be nice to get this package back into testing. Even nicer would be an update both of PulseView and the rest of the sigrok infrastructure, which all seems to be lagging behind upstream. Uwe, do you have any plans for this? J. -- ... I pretend to work. They pretend to pay me. signature.asc Description: Digital signature
Bug#822182: [PATCH] Fix dvbtune FTBFS due to missing stdint.h include
Control: tags 822182 + patch This is caused by a missing stdint.h include in dvbtune.c. The attached patch (for debian/patches/) fixes this. I intend to do an NMU with this fix later today, but it is possibly worth considering whether dvbtune is still useful in the archive. J. -- Conscience is the fear of getting caught. --- a/dvbtune.c 2016-07-05 09:43:47.41200 +0100 +++ b/dvbtune.c 2016-07-05 09:44:26.74000 +0100 @@ -39,6 +39,7 @@ // Linux includes: #include #include +#include #include #include #include
Bug#817837: l2tpns: *** buffer overflow detected ***: l2tpns terminated
On Tue, Jun 14, 2016 at 03:59:19PM +0200, Jérémie Courrèges-Anglas wrote: > On Tue, 15 Mar 2016 14:17:08 +0000 Jonathan McDowell <nood...@earth.li> > wrote: > > On Thu, Mar 10, 2016 at 07:50:22PM +, Dave Reeve wrote: > > > Running l2tpns causes an instance crash as follows: > > > > > > # l2tpns -v > > > *** buffer overflow detected ***: l2tpns terminated > > > (full trace removed as it doesn't help) > > > > > > The problem exists in the ring buffer logging code. Specially the > > > vsprintf is called with a length of 4095 when the size of the > > > buffer is MAX_LOG_LENGTH (defined as 512 in l2tpns.h). The result > > > is that as soon as the program is executed it crashes as soon as a > > > few log messages are printed. The following patch resolves the > > > problem. > > > > > > I also have some more minor fixes, which resolve compiler > > > warnings. I am happy to share these if you let me know where to > > > send them! > > > > Upstream these days is at http://git.sameswireless.fr/l2tpns.git and > > I note Fernando has been maintaining Debian packaging. As I haven't > > been using l2tpns for some time I have emailed him asking if he > > would like to take over maintenance of the package in Debian. It's > > probably best to send fixes directly upstream. > > Last time I looked at Fernando's work he had implemented quite nice > functionalities. However, as long as no one attempts an update to his > version, Debian users are stuck with... no l2tpns package in > testing[1]. As a first step, the patch that Dave submitted is enough > to fix l2tpns and make it usable on jessie at my ISP. It would be nice > if it could be integrated. Letting it be removed from testing rather than just applying the patch was a deliberate choice on my part. I haven't been using the package myself for some time, and I'm not sure just applying patches as they come into the BTS is doing the best service to l2tpns users. I contacted Fernando to see if he wanted to take over the package maintainership, but it sounds like he'd need more help with the packaging side than I really have time to provide at present. I haven't ruled that out as an option, but if there's someone reading who'd like to take over I'm prepared to help with sponsored uploads. Otherwise the right choice may be requesting the package's removal from Debian. J. -- ... "Where else in computing can a random government that isn't even in your country force you to make a change to your servers on three day's notice?" -- Russ Allbery on DST
Bug#822293: uuid broken in tcllib
Control: reassign 822293 tcllib Control: found 822293 1.18-dfsg-1 Control: retitle 822293 uuid broken in tcllib when /sbin not in PATH The UUID generation routines in tcllib 1.18 add in information from nettool about the network information to help generate unique UUIDs. However nettool shells out to ifconfig without a path. As ifconfig is in /sbin this makes UUID generation broken for the typical user. In particular this breaks password-gorilla from being able to save new passwords. Either nettool needs fixed to include the path to sbin (probably best) or the uuid package should stop using it. J. -- If I, um, err. Yeah, it probably | .''`. Debian GNU/Linux Developer rounds down. -- Simon Huggins | : :' : Happy to accept PGP signed | `. `' or encrypted mail - RSA | `-key on the keyservers.
Bug#817837: l2tpns: *** buffer overflow detected ***: l2tpns terminated
On Thu, Mar 10, 2016 at 07:50:22PM +, Dave Reeve wrote: > Running l2tpns causes an instance crash as follows: > > # l2tpns -v > *** buffer overflow detected ***: l2tpns terminated > (full trace removed as it doesn't help) > > The problem exists in the ring buffer logging code. Specially the vsprintf > is called with a length of 4095 when the size of the buffer is MAX_LOG_LENGTH > (defined as 512 in l2tpns.h). The result is that as soon as the program is > executed it crashes as soon as a few log messages are printed. The following > patch resolves the problem. > > I also have some more minor fixes, which resolve compiler warnings. I > am happy to share these if you let me know where to send them! Upstream these days is at http://git.sameswireless.fr/l2tpns.git and I note Fernando has been maintaining Debian packaging. As I haven't been using l2tpns for some time I have emailed him asking if he would like to take over maintenance of the package in Debian. It's probably best to send fixes directly upstream. J. -- /-\ | Do I BELIEVE in the Bible?! Hell, |@/ Debian GNU/Linux Developer |man I've SEEN one!!! \- |
Bug#710665: onak: postinst uses /usr/share/doc content (Policy 12.3): /usr/share/doc/onak/noodles.key.gz
tags 710665 pending thanks On Sat, Jun 01, 2013 at 01:43:51PM +0200, Andreas Beckmann wrote: a test with piuparts revealed that your package uses files from /usr/share/doc in its maintainer scripts which is a violation of Policy 12.3: Packages must not require the existence of any files in /usr/share/doc/ in order to function. http://www.debian.org/doc/debian-policy/ch-docs.html#s12.3 These files must be moved to /usr/share/$PACKAGE and may be symlinked from /usr/share/doc/$PACKAGE. This has been outstanding for too long; apologies. I plan to tag a new upstream onak release in the next week or two and will fix this as part of the upload of that to Debian. J. -- I don't bite. Well, that's wrong. I do bite. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#691802: debian-keyring: Getting rather stale
On Mon, Oct 29, 2012 at 05:46:17PM -0400, Samuel Bronson wrote: Package: debian-keyring Version: 2012.06.01 Severity: serious Dear Maintainer, The debian-keyring package seems to be getting a little stale; your usual at-least-monthly updates stopped abruptly at the beginning of June (around the start of the testing freeze). I don't really see how the testing freeze prevents updating the keyrings in unstable, though... We've been continuing to do keyring updates (the active keyring is unrelated to the state of what's in sid), but the package doesn't get updated every time we do so. We do make an effort to ensure an up to date package is uploaded before release, but our priority is the active keyring rather than the package. If you need to keep in sync with that then you should be using rsync against keyring.debian.org. J. -- How the f**k did you work that out? -- Pythagoras -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#650544: onak: does not rotate /var/log/onak.log
fixed 650544 0.4.0-1 thanks On Wed, Nov 30, 2011 at 07:59:48PM +0100, Helmut Grohne wrote: Package: onak Version: 0.3.8-1 Severity: serious Justification: Policy 10.8 The onak package creates /var/log/onak.log, but this file is never rotated. Instead it grows indefinitely. Rotation is a must according to policy section 10.8. The policy also lists an example logrotate config file. The version of onak in testing/unstable is 0.4.0-1 and already has a logrotate config file in /etc/logrotate.d/onak. J. -- Web [ I'm from the tax office. I'm here to take all your money. ] site: http:// [ ] Made by www.earth.li/~noodles/ [ ] HuggieTag 0.0.24 -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#626183: gnome-keyring-prompt segfaults on use
Package: gnome-keyring Version: 3.0.0-3 Severity: grave Justification: renders package unusable I debated over whether this should be grave or just important, but the inhumanity of having to type my SSH passwords first thing on a Monday morning rather than being able to use my SSH key led me to choose grave. Feel free to downgrade if you think it's appropriate. On booting up my (up-to-date) Debian/testing system this morning gnome-keyring-prompt is no longer working. I see: [ 60.136641] gnome-keyring-p[3062]: segfault at 157 ip 7fb030080fe6 sp 7fff65c519d0 error 4 in libgdk-3.so.0.0.8[7fb030056000+78000] [ 60.201739] gnome-keyring-p[3065]: segfault at 157 ip 7f5dc6169fe6 sp 7fff918f47e0 error 4 in libgdk-3.so.0.0.8[7f5dc613f000+78000] [ 60.249657] gnome-keyring-p[3066]: segfault at 157 ip 7feb4cb0dfe6 sp 7fff2eb0f8e0 error 4 in libgdk-3.so.0.0.8[7feb4cae3000+78000] [ 60.294314] gnome-keyring-p[3069]: segfault at 157 ip 7f182aec4fe6 sp 7fff59683640 error 4 in libgdk-3.so.0.0.8[7f182ae9a000+78000] in dmesg. I see: 2011-05-03 10:04:43 upgrade gnome-keyring 2.30.3-5 3.0.0-3 in /var/log/dpkg.log, so once my morning coffee has kicked in I will attempt a downgrade to see if that helps (I had not rebooted or logged out of the system since that upgrade). -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (900, 'testing'), (800, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.38-2-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 Versions of packages gnome-keyring depends on: ii dbus-x11 1.4.8-3simple interprocess messaging syst ii libc6 2.11.2-11 Embedded GNU C Library: Shared lib ii libcap2 1:2.20-1 support for getting/setting POSIX. ii libcap2-bin 1:2.20-1 basic utility programs for using c ii libdbus-1-3 1.4.8-3simple interprocess messaging syst ii libgck0 3.0.0-3Glib wrapper library for PKCS#11 - ii libgcr-3-03.0.0-3Library for Crypto UI related task ii libgcrypt11 1.4.6-5LGPL Crypto library - runtime libr ii libglib2.0-0 2.28.6-1 The GLib library of C routines ii libgtk-3-03.0.8-1The GTK+ graphical user interface Versions of packages gnome-keyring recommends: ii libpam-gnome-keyring 3.0.0-3PAM module to unlock the GNOME key gnome-keyring suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#626183: gnome-keyring-prompt segfaults on use
On Mon, May 09, 2011 at 10:03:52AM -0700, Jonathan McDowell wrote: Package: gnome-keyring Version: 3.0.0-3 Severity: grave Justification: renders package unusable I debated over whether this should be grave or just important, but the inhumanity of having to type my SSH passwords first thing on a Monday morning rather than being able to use my SSH key led me to choose grave. Feel free to downgrade if you think it's appropriate. This is cute. I run a triple head setup; 2 monitors on an nvidia card, 1 on a USB Displaylink adaptor. Turns out the problem is only when gnome-keyring-prompt is run on the nvidia display; it works fine on the Displaylink side. I'm running the Evil Binary nvidia drivers (unfortunately this is a work machine and I didn't get to specify the hardware, and the nouveau stuff crashes too often for it to be a suitable solution). J. -- Revd. Jonathan McDowell, ULC | I'm not popular enough to be different. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#475036: kernel-package works for me...
I'm a bit confused by the statement that kernel-package does not work with the current set of kernels; I built a 2.6.27-rc4 kernel from vanilla upstream sources using it over the weekend (on i386) and tend to build the latest vanilla kernels as they come out on my AMD64 box. I haven't hit any issues. What sort of thing should I be looking out for? J. -- /-\ | I've got a trigger inside. |@/ Debian GNU/Linux Developer | \- | -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#460575: onak fails to install with aptitude
On Sun, Jan 13, 2008 at 07:41:58PM +0100, Jan Prunk wrote: Package: onak Version: 0.3.4-1 Severity: critical Justification: breaks unrelated software Please clarify this justification; what unrelated software is broken? onak fails to install on lenny platforms tested were sparc i386. gateway:/var/lib/mediawiki/images/thumb# aptitude install onak Reading package lists... Done Building dependency tree Reading state information... Done Reading extended state information Initializing package states... Done Reading task descriptions... Done Building tag database... Done The following packages have been automatically kept back: apache2 apache2-mpm-prefork apache2-utils apache2.2-common libapt-pkg-perl libpq5 libsensors3 libsnmp-base libsnmp15 mailx psmisc snmp sysvinit-utils The following packages have been kept back: apt apt-utils aptitude cpio hostname initscripts libncurses5 libncursesw5 login ncurses-base ncurses-bin passwd phpmyadmin snmpd sysv-rc sysvinit tzdata The following NEW packages will be installed: onak 0 packages upgraded, 1 newly installed, 0 to remove and 30 not upgraded. Need to get 349kB of archives. After unpacking 926kB will be used. Writing extended state information... Done Get:1 http://ftp.de.debian.org lenny/main onak 0.3.4-1 [349kB] Fetched 349kB in 1s (260kB/s) Selecting previously deselected package onak. (Reading database ... 23236 files and directories currently installed.) Unpacking onak (from .../onak_0.3.4-1_sparc.deb) ... Does i386 fail in exactly the same way? Is the onak binary left installed in /usr/bin? Can you run it or does it error out in some manner if so? Setting up onak (0.3.4-1) ... Adding system user `onak' (UID 106) ... Adding new user `onak' (UID 106) with group `nogroup' ... Not creating home directory `/var/lib/onak'. dpkg: error processing onak (--configure): subprocess post-installation script returned error exit status 1 Errors were encountered while processing: onak E: Sub-process /usr/bin/dpkg returned an error code (1) A package failed to install. Trying to recover: Setting up onak (0.3.4-1) ... The user `onak' already exists. Exiting. dpkg: error processing onak (--configure): subprocess post-installation script returned error exit status 1 Errors were encountered while processing: onak Reading package lists... Done Building dependency tree Reading state information... Done Reading extended state information Initializing package states... Done Writing extended state information... Done Reading task descriptions... Done Building tag database... Done J. -- ] http://www.earth.li/~noodles/ [] Get off my turf! screamed Pooh, [ ] PGP/GPG Key @ the.earth.li [] as he shot at Paddington. [ ] via keyserver, web or email. [] [ ] RSA: 4DC4E7FD / DSA: 5B430367 [] [ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#413762: Fix for config structure using dynamic backends...
On Sat, Aug 11, 2007 at 05:54:32PM +0100, Brett Parker wrote: The attached patch fixes the config structure when dynamic backends are used - the basic issue is that when the backend was loaded, it wouldn't (neccessarily) share the config structure with the program that called it (and had therefore read the config). The problem with this is that we get multiple functions with the same name. I'm not sure we can be certain which will evaluate first? In particular, using the db4 backend through the dynamic backend with an error during DB initialisation causes a segfault. The initdb in keydb_db4 will call cleanupdb() when it hits an error, but this now maps to the cleanupdb() in keydb_dynamic. Which, although it calls the version in keydb_db4, will also call dlclose on the keydb_db4.so. Meaning that control returns to a function that's no longer in memory... The easy option is to have the cleanup end up as an internal function that cleanupdb calls, but I'd need to be certain there aren't other artifacts that will be seen from these changes. J. -- Illiterate? Write for FREE HELP! signature.asc Description: Digital signature
Bug#434066: asterisk: Fails to restart after upgrade due to dep on libpt.so.1.10.2
Package: asterisk Version: 1:1.4.8~dfsg-1 Severity: grave Justification: renders package unusable After performing my daily sid upgrade Asterisk fails to restart: Setting up asterisk-config (1:1.4.8~dfsg-1) ... Stopping Asterisk PBX: asterisk. Starting Asterisk PBX: /usr/sbin/asterisk: error while loading shared libraries: libpt.so.1.10.2: cannot open shared object file: No such file or directory invoke-rc.d: initscript asterisk, action restart failed. dpkg: error processing asterisk-config (--configure): subprocess post-installation script returned error exit status 127 dpkg: dependency problems prevent configuration of asterisk: asterisk depends on asterisk-config (= 1:1.4.8~dfsg-1) | asterisk-config-custom; however: Package asterisk-config is not configured yet. Package asterisk-config-custom is not installed. dpkg: error processing asterisk (--configure): dependency problems - leaving unconfigured I don't appear to have a libpt.so.1.10.2: [EMAIL PROTECTED] ~]$ ls /usr/lib/libpt.so.1.* /usr/lib/libpt.so.1.10.0@ /usr/lib/libpt.so.1.10.3@ /usr/lib/libpt.so.1.9.3@ /usr/lib/libpt.so.1.10.1@ /usr/lib/libpt.so.1.10.7 -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.22 (PREEMPT) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages asterisk depends on: ii adduser 3.104add and remove users and groups pn asterisk-config | aster none (no description available) ii asterisk-sounds-main1:1.4.8~dfsg-1 sound files for asterisk ii libasound2 1.0.14a-2ALSA library ii libc6 2.6-2GNU C Library: Shared libraries ii libct3 0.63-3.2 libraries for connecting to MS SQL ii libcurl3-gnutls 7.16.4-1 Multi-protocol file transfer libra ii libexpat1 1.95.8-3.4 XML parsing C library - runtime li ii libgcc1 1:4.2.1-0GCC support library ii libgcrypt11 1.2.4-2 LGPL Crypto library - runtime libr ii libgnutls13 1.6.3-1 the GNU TLS library - runtime libr ii libgpg-error0 1.4-2library for common error values an ii libgsm1 1.0.10-13Shared libraries for GSM speech co ii libiksemel3 1.2-3C library for the Jabber IM platfo ii libkrb531.6.dfsg.1-6 MIT Kerberos runtime libraries ii libldap22.1.30-13.4 OpenLDAP libraries ii libncurses5 5.6+20070716-1 Shared libraries for terminal hand ii libnewt0.52 0.52.2-10Not Erik's Windowing Toolkit - tex ii libogg0 1.1.3-2 Ogg Bitstream Library ii libopenh323-1.18.0 1.18.0.dfsg-1+b1 H.323 aka VoIP library ii libpopt01.10-3 lib for parsing cmdline parameters ii libpq5 8.2.4-2 PostgreSQL C client library ii libpri1.2 1.4.0-2 Primary Rate ISDN specification li ii libpt-1.10.01.10.7~dfsg1-3 Portable Windows Library ii libradiusclient-ng2 0.5.5-1 Enhanced RADIUS client library ii libsasl2-2 2.1.22.dfsg1-13 Authentication abstraction library ii libsdl1.2debian 1.2.11-9 Simple DirectMedia Layer ii libsensors3 1:2.10.4-1 library to read temperature/voltag ii libsnmp10 5.3.1-7 SNMP (Simple Network Management Pr ii libspeex1 1.1.12-3 The Speex Speech Codec ii libsqlite0 2.8.17-2 SQLite shared library ii libssl0.9.8 0.9.8e-5 SSL shared libraries ii libstdc++6 4.2.1-0 The GNU Standard C++ Library v3 ii libtonezone11:1.4.4~dfsg-1 tonezone library (runtime) ii libvorbis0a 1.1.2.dfsg-2 The Vorbis General Audio Compressi ii libvorbisenc2 1.1.2.dfsg-2 The Vorbis General Audio Compressi ii libwrap07.6.dbs-13 Wietse Venema's TCP wrappers libra ii unixodbc2.2.11-15ODBC tools libraries ii zlib1g 1:1.2.3.3.dfsg-5 compression library - runtime asterisk recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#413762: database files being created in the root ('/') directory
On Wed, Mar 14, 2007 at 10:29:52AM +, Jonathan McDowell wrote: On Tue, Mar 13, 2007 at 09:21:51PM +, Rafal Czlonka wrote: Jonathan McDowell wrote: When you have the package installed, does running onak index noodles as the onak user provide any output? Can you try strace -o onak.strace onak index noodles and send me the resulting onak.strace? That's the output I get. [13/03/2007 21:16:16] [28761]: Couldn't open num_keydb: No such file or directory [13/03/2007 21:16:16] [28761]: Couldn't write num_keydb: No such file or directory Key not found. When I run strace on onak, the files I've mentioned before are being created in the working directory. Hmmm. Somehow db_dir is getting set to NULL. Have you tried the onak-0.3.2 package (it's in testing)? If not can you give it a try and let me know if you still see the problem? I'm wondering if it's the change to dynamically loaded backend plugins that might have caused this. I've got access to a PPC machine now and been able to verify this; it does indeed appear to be an issue with the new dynamic loading of backends resulting in the loaded backend not seeing the config structure correctly. J. -- jid: [EMAIL PROTECTED] Remember - if all you have is an axe, every problem looks like hours of fun. -- Frossie, asr. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#413762: database files being created in the root ('/') directory
On Tue, Mar 13, 2007 at 09:21:51PM +, Rafal Czlonka wrote: Jonathan McDowell wrote: When you have the package installed, does running onak index noodles as the onak user provide any output? Can you try strace -o onak.strace onak index noodles and send me the resulting onak.strace? That's the output I get. [13/03/2007 21:16:16] [28761]: Couldn't open num_keydb: No such file or directory [13/03/2007 21:16:16] [28761]: Couldn't write num_keydb: No such file or directory Key not found. When I run strace on onak, the files I've mentioned before are being created in the working directory. Hmmm. Somehow db_dir is getting set to NULL. Have you tried the onak-0.3.2 package (it's in testing)? If not can you give it a try and let me know if you still see the problem? I'm wondering if it's the change to dynamically loaded backend plugins that might have caused this. J. -- Why are Chinese fortune cookies written in English? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#413762: database files being created in the root ('/') directory
On Thu, Mar 08, 2007 at 08:19:26PM +, Rafal Czlonka wrote: Jonathan McDowell wrote: Can you at least give me the md5sum of the file; I want to be certain it's pristine. f0cb6bc3f8c2a40d63e7deb1cd4b3131 Right, that matches my local copy. When you have the package installed, does running onak index noodles as the onak user provide any output? Can you try strace -o onak.strace onak index noodles and send me the resulting onak.strace? J. -- [ Ok ramblers, let's get rambling. ] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#413762: database files being created in the root ('/') directory
On Thu, Mar 08, 2007 at 09:55:26PM +, Rafal Czlonka wrote: Tried on non-virtual kernel, it doesn't have anything to do with it - - still the same thing. This is on the same host, right? A PPC? And you've completed purged the old package and ensured there are no such files in / before installing it again? J. -- ] http://www.earth.li/~noodles/ [] The truth is out there, but also [ ] PGP/GPG Key @ the.earth.li [] in here. [ ] via keyserver, web or email. [] [ ] RSA: 4DC4E7FD / DSA: 5B430367 [] [ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#408270: patch + NMU
On Thu, Feb 01, 2007 at 10:46:42AM +0100, Bastian Venthur wrote: I've created a patch adding adduser to the depends and NMU'ed it to DELAYED/0 according to http://lists.debian.org/debian-devel-announce/2006/09/msg00020.html In order to be as minimal invasive as possible I did not touch the postrm as Masami did in his proposed patch. Meh. I'd seen this bug, but missed the fact it was RC somehow; I've been holding off on uploading anything that wasn't of an RC nature in the vain hope that we might actually release and the less changes the better to achieve that. Minimal changes you've made look fine; I'll include them when I next upload. J. -- Revd. Jonathan McDowell, ULC | Make friends. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#401742: l2tpns Heartbeat Packets Buffer Overflow Vulnerability
On Tue, Dec 05, 2006 at 05:36:32PM +0100, Stefan Fritsch wrote: Package: l2tpns Severity: grave Tags: security Justification: user security hole A vulnerabilit has been found in l2tpns. See http://secunia.com/advisories/23230/ for details. According to secunia, it is fixed in 2.1.21. I have already uploaded 2.1.21 to unstable and have contacted the security team about a backport to 2.0.14 (in sarge). J. -- Bother, said Pooh, as Tennents Live put him on the dole. This .sig brought to you by the letter L and the number 10 Product of the Republic of HuggieTag -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#382844: Can fidogate be removed?
On Thu, Aug 17, 2006 at 03:12:06PM +0200, Thijs Kinkhorst wrote: fidogate: * Has had a security issue reported; * Has a number of policy violations; * Has been orphaned for two months; * Has 4 popcon installs with 1 vote; * Is a couple of versions behind upstream; * Is a gateway for Fidonet, does that even exist anymore nowadays? In my opinion, we'd better not ship it with etch. Given I only picked it up because it was orphaned and no one else was interested I'm inclined to agree. Fidonet does still exist in a limited form from my understanding, but obviously there isn't enough interest in maintaining it in Debian. My own Fido involvement ended some time ago. J. -- Covered in paint and high as a kite.
Bug#374783: seems to be broken in SSL only
On Sun, Jul 02, 2006 at 11:42:56AM -0400, Jaldhar H. Vyas wrote: On Fri, 23 Jun 2006, Wouter Verhelst wrote: I'm seeing the same issue; however, while IMAPS does indeed not work, netstat -tl shows me that dovecot does properly listen to port 143, i.e., the regular IMAP port. Hi Jonathan and Wouter, Upstream thinks this is fixed in 1.0rc1 which is in unstable. Can you try it and confirm? Upgraded to 1.0.rc1-1 today and IPv6 functionality is restored. Excellent stuff - thanks. J. -- [ noodles is angry with him ] [ http://www.blackcatnetworks.co.uk/ - IPv6 enabled ADSL/dialup/colo ] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#359232: libcrypt-cbc-perl security update broken.
Package: libcrypt-cbc-perl Severity: grave Version: 2.12-1sarge1 The security update of libcrypt-cbc-perl to 2.12-1sarge1 causes breakage; when the upgrade is applied I see the following errors: Use of uninitialized value in pattern match (m//) at /usr/share/perl5/Crypt/CBC.pm line 240, GEN0 line 4. Use of uninitialized value in pattern match (m//) at /usr/share/perl5/Crypt/CBC.pm line 240, GEN0 line 4. Use of uninitialized value in concatenation (.) or string at /usr/share/perl5/Crypt/CBC.pm line 171, GEN0 line 4. This is using the module with libopensrs-perl (backported to sarge) and causes the authentication to OpenSRS to fail. Downgrading to 2.12-1 fixes things. I'll try to do some more investigation later if I have time; apologies for the limited details here. J. -- Counselor, can I, uh, use your | .''`. Debian GNU/Linux Developer com-badge? - Riker | : :' : Happy to accept PGP signed | `. `' or encrypted mail - RSA + | `-DSA keys on the keyservers. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
