Bug#965846: ufiformat: diff for NMU version 0.9.9-1.1
Thank you for fixing these; I completely missed both of these bugs when they got filed. On Mon, 20 Dec 2021 at 15:33, Stephen Kitt wrote: > Package: ufiformat > Version: 0.9.9-1 > Severity: normal > Tags: patch pending > > Dear maintainer, > > I've prepared an NMU for ufiformat (versioned as 0.9.9-1.1) and > uploaded it to DELAYED/10. Please feel free to tell me if I > should delay it longer. > > Regards, > > Stephen >
Bug#999883: wordgrinder FTCBFS: multiple issues
Thanks --- yes, that needs fixing. Unfortunately, while wearing my upstream hat, I've rewritten the build system, but I've applied some changes to make it honour variables like CC and PKG_CONFIG. The diff is here, if you're interested: https://github.com/davidgiven/wordgrinder/pull/181/files The new version's not packaged for Debian yet as there are still some upstream fixes to be done. Is there actually a formal spec for the expected interface that polite Makefiles should honour to make cross building possible? And can you point me at the Debian tools you're using to do these checks? On Thu, 18 Nov 2021 at 06:24, Helmut Grohne wrote: > Source: wordgrinder > Version: 0.8-1 > Tags: patch > User: debian-cr...@lists.debian.org > Usertags: ftcbfs > > wordgrinder fails to cross build from source for multiple reasons. It > starts with wordgrinder running plain make without passing any cross > tools. That part is best solved by using dh_auto_build. Then, the > makefile runs a build.lua script that hard codes the build architecture > pkg-config. PKG_CONFIG support should be added to both Makefile and > build.lua. Beyond that, it strips with the build architecture strip. In > addition to breaking cross compilation, that approach also breaks > generation of -dbgsym packages as well as DEB_BUILD_OPTIONS=nostrip. It > is best to defer stripping to dh_strip and that happens to fix the cross > build aspect as well. > > The attached patch fixes all of the issues mentioned above. However, it > does not make cross builds succeed as the test suite fails. Cross builds > do pass nocheck via DEB_BUILD_OPTIONS, but wordgrinder does not honour > that. So the next step is adding nocheck support. > > Anyway, please consider applying the attached patch as an incremental > step and close this bug when doing so even without adding nocheck > support. > > Helmut >
Bug#998365: libstdc++-arm-none-eabi-newlib: Version of libstdc++-arm-none-eabi-newlib and gcc-arm-none-eabi must match or the C++ libraries can't be found
Ah, I've just spotted (via the automatically reported bug data...) that there is such a constraint but it's only at a Recommends level. I think this should be upgraded to a Depends. On Tue, 2 Nov 2021 at 23:57, David Given wrote: > Package: libstdc++-arm-none-eabi-newlib > Version: 15:8-2019-q3-1+13 > Severity: important > X-Debbugs-Cc: d...@cowlark.com > > Dear Maintainer, > > Currently the testing/unstable version of gcc-arm-none-eabi is > 15:10.3-2021.07-2 (a.k.a. 10.3.1) and the version of > libstdc++-arm-none-eabi- > newlib is 15:8-2019-q3-1+13 (a.k.a. 8.3.1). > > The problem is that gcc looks for the newlib include files using the > compiler > internal version, which makes newlib unusable --- the compiler is looking > for > /usr/include/newlib/c++/10.3.1 and failing to find the files in > /usr/include/newlib/c++/8.3.1. > > The solution for me was to downgrade gcc to the same version as newlib, > which > lets it find the library, but that's not very satisfactory. As it stands > newlib > is unusable on testing or unstable systems. > > I would suggest adding a constraint to newlib to ensure that the version of > gcc-arm-none-eabi is the same as that of libstdc++-arm-none-eabi-newlib. > > > -- System Information: > Debian Release: bookworm/sid > APT prefers oldoldstable > APT policy: (500, 'oldoldstable'), (500, 'unstable'), (500, 'stable'), > (500, 'oldstable') > Architecture: amd64 (x86_64) > Foreign Architectures: i386 > > Kernel: Linux 5.14.0-3-amd64 (SMP w/8 CPU threads) > Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, > TAINT_UNSIGNED_MODULE > Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), > LANGUAGE=en_GB:en > Shell: /bin/sh linked to /bin/dash > Init: systemd (via /run/systemd/system) > LSM: AppArmor: enabled > > Versions of packages libstdc++-arm-none-eabi-newlib depends on: > ii libnewlib-arm-none-eabi 3.3.0-1 > ii libnewlib-dev3.3.0-1 > > Versions of packages libstdc++-arm-none-eabi-newlib recommends: > ii binutils-arm-none-eabi 2.37-7+15 > ii gcc-arm-none-eabi 15:8-2019-q3-1+b1 > > libstdc++-arm-none-eabi-newlib suggests no packages. > > -- no debconf information >
Bug#998365: libstdc++-arm-none-eabi-newlib: Version of libstdc++-arm-none-eabi-newlib and gcc-arm-none-eabi must match or the C++ libraries can't be found
Package: libstdc++-arm-none-eabi-newlib Version: 15:8-2019-q3-1+13 Severity: important X-Debbugs-Cc: d...@cowlark.com Dear Maintainer, Currently the testing/unstable version of gcc-arm-none-eabi is 15:10.3-2021.07-2 (a.k.a. 10.3.1) and the version of libstdc++-arm-none-eabi- newlib is 15:8-2019-q3-1+13 (a.k.a. 8.3.1). The problem is that gcc looks for the newlib include files using the compiler internal version, which makes newlib unusable --- the compiler is looking for /usr/include/newlib/c++/10.3.1 and failing to find the files in /usr/include/newlib/c++/8.3.1. The solution for me was to downgrade gcc to the same version as newlib, which lets it find the library, but that's not very satisfactory. As it stands newlib is unusable on testing or unstable systems. I would suggest adding a constraint to newlib to ensure that the version of gcc-arm-none-eabi is the same as that of libstdc++-arm-none-eabi-newlib. -- System Information: Debian Release: bookworm/sid APT prefers oldoldstable APT policy: (500, 'oldoldstable'), (500, 'unstable'), (500, 'stable'), (500, 'oldstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.14.0-3-amd64 (SMP w/8 CPU threads) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages libstdc++-arm-none-eabi-newlib depends on: ii libnewlib-arm-none-eabi 3.3.0-1 ii libnewlib-dev3.3.0-1 Versions of packages libstdc++-arm-none-eabi-newlib recommends: ii binutils-arm-none-eabi 2.37-7+15 ii gcc-arm-none-eabi 15:8-2019-q3-1+b1 libstdc++-arm-none-eabi-newlib suggests no packages. -- no debconf information
Bug#976239: qemu-user: emulator crash with minimal test program
Package: qemu-user Version: 1:5.1+dfsg-4+b2 Severity: normal Tags: upstream X-Debbugs-Cc: d...@cowlark.com I have a test program for the PowerPC which reliably causes qemu-ppc to crash, apparently on startup. I haven't been able to get it to tell me what it's doing during the crash. The minimal program is: ---snip--- .text .global _start _start: li 3,0 li 0,1 sc # call _exit() .section .bss .byte 0 ---snip--- To reproduce, do: $ powerpc-linux-gnu-as -o test.o test.s $ powerpc-linux-gnu-ld -o test test.o $ qemu-ppc ./test Segmentation fault I believe this is a bug in qemu as the same binary works absolutely fine on real hardware. Removing the `.byte 0` line causes the crash to go away. -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (500, 'oldstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.9.0-1-amd64 (SMP w/8 CPU threads) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages qemu-user depends on: ii libc6 2.31-4 ii libcapstone3 4.0.1+really+3.0.5-2+b1 ii libgcc-s1 10.2.0-16 ii libglib2.0-0 2.66.2-1 ii libgnutls30 3.6.15-4 ii libstdc++610.2.0-16 ii zlib1g1:1.2.11.dfsg-2 Versions of packages qemu-user recommends: ii qemu-user-static [qemu-user-binfmt] 1:5.1+dfsg-4+b2 Versions of packages qemu-user suggests: ii sudo 1.9.3p1-1 -- debconf-show failed
Bug#971114: wordgrinder: FTBFS: src/c/arch/unix/cursesw/dpy.c:219:8: error: ‘KEY_EVENT’ undeclared (first use in this function); did you mean ‘KEY_SLEFT’?
It looks like ncurses has dropped KEY_EVENT: https://invisible-island.net/ncurses/NEWS.html#index-t20200817 I'll fix this upstream and produce a new package --- it's about time anyway. On Sun, 27 Sep 2020 at 20:51, Lucas Nussbaum wrote: > Source: wordgrinder > Version: 0.7.2-1 > Severity: serious > Justification: FTBFS on amd64 > Tags: bullseye sid ftbfs > Usertags: ftbfs-20200926 ftbfs-bullseye > > Hi, > > During a rebuild of all packages in sid, your package failed to build > on amd64. > > Relevant part (hopefully): > > cc -MMD -MF .obj/lua-5.3-curses-release/src/c/arch/unix/cursesw/dpy.o.d > -Wdate-time -D_FORTIFY_SOURCE=2 -g -O2 > -fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat > -Werror=format-security -g -DVERSION='"0.7.2"' -DFILEFORMAT=7 -DNOUNCRYPT > -DNOCRYPT -Isrc/c -Wall -Wno-unused-function -ffunction-sections > -fdata-sections -Werror=implicit-function-declaration --std=gnu99 > -D_DEFAULT_SOURCE -D_XOPEN_SOURCE=600 -Os -I/usr/include/lua5.3 > -I/usr/include/lua5.3 -DARCH='"unix"' -D_XOPEN_SOURCE_EXTENDED > -D_XOPEN_SOURCE -D_GNU_SOURCE -I/usr/include/minizip -c > src/c/arch/unix/cursesw/dpy.c -o > .obj/lua-5.3-curses-release/src/c/arch/unix/cursesw/dpy.o > > : warning: "_XOPEN_SOURCE" redefined > > : note: this is the location of the previous definition > > src/c/arch/unix/cursesw/dpy.c: In function ‘dpy_getkeyname’: > > src/c/arch/unix/cursesw/dpy.c:219:8: error: ‘KEY_EVENT’ undeclared > (first use in this function); did you mean ‘KEY_SLEFT’? > > 219 | case KEY_EVENT: return "KEY_EVENT"; > > |^ > > |KEY_SLEFT > > src/c/arch/unix/cursesw/dpy.c:219:8: note: each undeclared identifier is > reported only once for each function it appears in > > [14/82] cc -MMD -MF .obj/lua-5.3-curses-release/src/c/main.o.d > -Wdate-time -D_FORTIFY_SOURCE=2 -g -O2 > -fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat > -Werror=format-security -g -DVERSION='"0.7.2"' -DFILEFORMAT=7 -DNOUNCRYPT > -DNOCRYPT -Isrc/c -Wall -Wno-unused-function -ffunction-sections > -fdata-sections -Werror=implicit-function-declaration --std=gnu99 > -D_DEFAULT_SOURCE -D_XOPEN_SOURCE=600 -Os -I/usr/include/lua5.3 > -I/usr/include/lua5.3 -DARCH='"unix"' -D_XOPEN_SOURCE_EXTENDED > -D_XOPEN_SOURCE -D_GNU_SOURCE -I/usr/include/minizip -c src/c/main.c -o > .obj/lua-5.3-curses-release/src/c/main.o > > : warning: "_XOPEN_SOURCE" redefined > > : note: this is the location of the previous definition > > [15/82] cc -MMD -MF .obj/lua-5.3-curses-release/src/c/lua.o.d > -Wdate-time -D_FORTIFY_SOURCE=2 -g -O2 > -fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat > -Werror=format-security -g -DVERSION='"0.7.2"' -DFILEFORMAT=7 -DNOUNCRYPT > -DNOCRYPT -Isrc/c -Wall -Wno-unused-function -ffunction-sections > -fdata-sections -Werror=implicit-function-declaration --std=gnu99 > -D_DEFAULT_SOURCE -D_XOPEN_SOURCE=600 -Os -I/usr/include/lua5.3 > -I/usr/include/lua5.3 -DARCH='"unix"' -D_XOPEN_SOURCE_EXTENDED > -D_XOPEN_SOURCE -D_GNU_SOURCE -I/usr/include/minizip -c src/c/lua.c -o > .obj/lua-5.3-curses-release/src/c/lua.o > > : warning: "_XOPEN_SOURCE" redefined > > : note: this is the location of the previous definition > > [16/82] cc -MMD -MF .obj/lua-5.3-curses-release/src/c/screen.o.d > -Wdate-time -D_FORTIFY_SOURCE=2 -g -O2 > -fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat > -Werror=format-security -g -DVERSION='"0.7.2"' -DFILEFORMAT=7 -DNOUNCRYPT > -DNOCRYPT -Isrc/c -Wall -Wno-unused-function -ffunction-sections > -fdata-sections -Werror=implicit-function-declaration --std=gnu99 > -D_DEFAULT_SOURCE -D_XOPEN_SOURCE=600 -Os -I/usr/include/lua5.3 > -I/usr/include/lua5.3 -DARCH='"unix"' -D_XOPEN_SOURCE_EXTENDED > -D_XOPEN_SOURCE -D_GNU_SOURCE -I/usr/include/minizip -c src/c/screen.c -o > .obj/lua-5.3-curses-release/src/c/screen.o > > : warning: "_XOPEN_SOURCE" redefined > > : note: this is the location of the previous definition > > [17/82] cc -MMD -MF .obj/lua-5.3-x11-release/.obj/luascripts.o.d > -Wdate-time -D_FORTIFY_SOURCE=2 -g -O2 > -fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat > -Werror=format-security -g -DVERSION='"0.7.2"' -DFILEFORMAT=7 -DNOUNCRYPT > -DNOCRYPT -Isrc/c -Wall -Wno-unused-function -ffunction-sections > -fdata-sections -Werror=implicit-function-declaration --std=gnu99 > -I/usr/include/freetype2 -I/usr/include/libpng16 -I/usr/include/X11 -Os > -I/usr/include/lua5.3 -I/usr/include/lua5.3 -DARCH='"unix"' > -D_XOPEN_SOURCE_EXTENDED -D_XOPEN_SOURCE -D_GNU_SOURCE > -I/usr/include/minizip -c .obj/luascripts.c -o > .obj/lua-5.3-x11-release/.obj/luascripts.o > > [18/82] cc -MMD -MF .obj/lua-5.3-curses-release/.obj/luascripts.o.d > -Wdate-time -D_FORTIFY_SOURCE=2 -g -O2 > -fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat > -Werror=format-security -g -DVERSION='"0.7.2"' -DFILEFORMAT=7 -DNOUNCRYPT > -DNOCRYPT -Isrc/c -Wall -Wno-unused-function -ffunction-sections > -fdata-sections -Werror=implicit-function-declaration --std=gnu99 >
Bug#619757: Bug #619757 breaks DVD reading by default now
I've just run into this myself with a Bluray drive: $ uname -a Linux hilfy 4.19.0-5-amd64 #1 SMP Debian 4.19.37-3 (2019-05-15) x86_64 GNU/Linux $ smartctl -i /dev/cdrom smartctl 6.6 2017-11-05 r4594 [x86_64-linux-4.19.0-5-amd64] (local build) Copyright (C) 2002-17, Bruce Allen, Christian Franke, www.smartmontools.org === START OF INFORMATION SECTION === Vendor: HL-DT-ST Product: BD-RE BH16NS55 Revision: 1.02 User Capacity:24,220,008,448 bytes [24.2 GB] Logical block size: 2048 bytes Device type: CD/DVD The workflow with me was: - install brand new drive - burn an image to the drive - attempt to verify the image - drive only returns the first 1073741312 bytes of data, causing the verification to fail This then resulted in me panicing that my brand new drive was faulty! Is this an important enough bug to warrant having the packet driver stuff disabled by default? I never heard of anyone who uses it, and I've tried and failed myself; and the failure mode is pretty severe (non-CD writable optical media simply fails to work). -- ┌─── http://www.cowlark.com ─── │ "I have always wished for my computer to be as easy to use as my │ telephone; my wish has come true because I can no longer figure out │ how to use my telephone." --- Bjarne Stroustrup
Bug#880414: RFS: wordgrinder 0.7-1 -- word processor which runs in a terminal
Aargh, yes --- the extras are documented upstream, but I completely forgot to update the debian/copyright file... I'm usually better than that. Sorry. (That's why there are reviews!) I have: - produced a new upstream version, 0.7.1, with the code rearranged to make it easier to strip out the unneeded dependencies, and much better documentation of third-party code. - produced a special minimal distribution just for Debian with the unused dependencies removed. (Most of them weren't being used anyway; now they're not present.) - updated the packaging. The only thing the package actually uses now is a patched copy of xpattern, which can't be externalised. It's documented in the copyright file. The new package is 0.7.1-1, here: https://mentors.debian.net/package/wordgrinder PTAL and let me know what else is wrong... On Thu, 2 Nov 2017 at 04:15 Adam Borowski <kilob...@angband.pl> wrote: > On Tue, Oct 31, 2017 at 11:33:13AM +0100, David Given wrote: > > * Package name: wordgrinder > > Version: 0.7-1 > > > WordGrinder's not a new package --- it's been in Debian since wheezy. > > Unfortunately my existing sponsor has retired and is unable to upload > > the new version, so for the this version I'm looking for a new > > sponsor. The package should be in pretty good shape as the old sponsor > > waa pretty conscientous; it's lintian clean, has hardening enabled, > > and uses dquilt for patching. > > > > Disclaimer: when I'm wearing my other hat, I am the upstream author. > > > > Changes since the last upload: > > > > - New upstream release > > I'm afraid the new version ships a bunch of big external projects such as > lua-5.1, minizip, uthash (aka "convenience copies"). It'd be better to > remove them from the tarball to ensure only the system version is used -- > this greatly helps the Security Team. This is not strictly needed, but > there should be a good reason to do otherwise. > > You also don't even mention them (other than uthash) in the copyright file, > despite them not having been written by you. > > There's also a bunch of smaller files from external source (lfs, wcwidth, > lua-bitop) -- you also falsely claim that you own copyright for them. > > (Yeah, copyright issues are an unfun thing, but these days lawyers rule the > world.) > > > Meow! > -- > ⢀⣴⠾⠻⢶⣦⠀ Laws we want back: Poland, Dz.U. 1921 nr.30 poz.177 (also Dz.U. > ⣾⠁⢰⠒⠀⣿⡁ 1920 nr.11 poz.61): Art.2: An official, guilty of accepting a gift > ⢿⡄⠘⠷⠚⠋⠀ or another material benefit, or a promise thereof, [in matters > ⠈⠳⣄ relevant to duties], shall be punished by death by shooting. > -- ┌─── http://cowlark.com ─── │ "There is nothing in the world so dangerous --- and I mean *nothing* │ --- as a children's story that happens to be true." --- Master Li Kao, │ _The Bridge of Birds_
Bug#880414: RFS: wordgrinder 0.7-1 -- word processor which runs in a terminal
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "wordgrinder": * Package name: wordgrinder Version: 0.7-1 Upstream Author: David Given <d...@cowlark.com> * URL: http://cowlark.com/wordgrinder * License: MIT Section: editors It builds those binary packages: wordgrinder wordgrinder-x11 wordgrinder-ncurses wordgrinder-doc ...and it's uploaded on Mentors: https://mentors.debian.net/package/wordgrinder (Both 0.7-1 and a now obsolete 0.6-3~bpo8+1 version are uploaded there. Please ignore the 0.6 version; I haven't figured out how to delete it yet.) WordGrinder's not a new package --- it's been in Debian since wheezy. Unfortunately my existing sponsor has retired and is unable to upload the new version, so for the this version I'm looking for a new sponsor. The package should be in pretty good shape as the old sponsor waa pretty conscientous; it's lintian clean, has hardening enabled, and uses dquilt for patching. Disclaimer: when I'm wearing my other hat, I am the upstream author. Changes since the last upload: - New upstream release PTAL, and LMKWYT.
Bug#867973: jessie-pu: package wordgrinder/0.5.1-1
Unfortunately, that's not feasible --- upstream fixed that bug by reworking the entire internal document model, and it's all interdependent on the rest of the changes, so it'd be a major engineering effort to do. I wouldn't be desireable anyway, as the end result would be a version of the package which is substantially different from any upstream release of WordGrinder. Why is it problematic to pushing the stable version into oldstable? It's a completely trivial build, being *literally* apt-get source && debuild. Here's the backport I prepared to prove it: https://mentors.debian.net/package/wordgrinder What's the user value in keeping 0.5.1 in oldstable rather than just upgrading to the stable version? On Tue, 11 Jul 2017 at 00:22 Cyril Brulebois <k...@debian.org> wrote: > David Given <d...@cowlark.com> (2017-07-10): > > Well, I actually approached backports, and they firmly told me to come > > here instead (and even provided instructions)... > > > > Okay, so what now? I don't really want a backport anyway; I just want > > the version that's currently in stable pushed to jessie as well. That > > version has been in Debian since late 2015, so it's not precisely new; > > it's not like I'm proposing an unstable version. > > > > I do *not* want the package removed from jessie. It turns out there's > > still a fair number of people who use it, on jessie, and I want to make > > sure that they're supported. > > Then extract targeted patches to fix specific bugs in jessie, and propose > a smaller debdiff/diffstat than the one Adam pointed out. > > > KiBi. > -- ┌─── http://cowlark.com ─── │ "There is nothing in the world so dangerous --- and I mean *nothing* │ --- as a children's story that happens to be true." --- Master Li Kao, │ _The Bridge of Birds_
Bug#867973: jessie-pu: package wordgrinder/0.5.1-1
Well, I actually approached backports, and they firmly told me to come here instead (and even provided instructions)... Okay, so what now? I don't really want a backport anyway; I just want the version that's currently in stable pushed to jessie as well. That version has been in Debian since late 2015, so it's not precisely new; it's not like I'm proposing an unstable version. I do *not* want the package removed from jessie. It turns out there's still a fair number of people who use it, on jessie, and I want to make sure that they're supported. On Mon, 10 Jul 2017 at 22:27 Adam D. Barratt <a...@adam-barratt.org.uk> wrote: > On Mon, 2017-07-10 at 22:21 +0200, Alexander Wirt wrote: > > On Mon, 10 Jul 2017, Adam D. Barratt wrote: > > > > > Control: tags -1 + moreinfo > > > > > > On Mon, 2017-07-10 at 19:44 +, David Given wrote: > > > > The version in jessie of my package WordGrinder is painfully old and > has a > > > > number of showstopping bugs (document corruption and loss of data). > The next > > > > available version in Debian is the version in stable, 0.6-3, which > has fixed > > > > these bugs and also contains major functionality improvements. > > > > > > > > 0.6-3 builds on jessie out-of-the-box with no repackaging required, > and so I > > > > would like to propose the version from stable to be included in the > next jessie > > > > point release. > > > > > > That sounds like you're looking for jessie-backports, rather than a > > > stable update. > > jessie-backports is not for fixing critical bugs like document > corruption. > > Those should really get fixed in stable (of course not with an upload of > the > > version in testing). > > Yes, true, and sorry for being imprecise. > > I meant that if the reporter was looking to get newer upstream versions > available to users of jessie, rather than specific bug fixes, then > backports was a more applicable approach. > > Regards, > > Adam > > -- ┌─── http://cowlark.com ─── │ "There is nothing in the world so dangerous --- and I mean *nothing* │ --- as a children's story that happens to be true." --- Master Li Kao, │ _The Bridge of Birds_
Bug#867973: jessie-pu: package wordgrinder/0.5.1-1
Package: release.debian.org Severity: normal Tags: jessie User: release.debian@packages.debian.org Usertags: pu The version in jessie of my package WordGrinder is painfully old and has a number of showstopping bugs (document corruption and loss of data). The next available version in Debian is the version in stable, 0.6-3, which has fixed these bugs and also contains major functionality improvements. 0.6-3 builds on jessie out-of-the-box with no repackaging required, and so I would like to propose the version from stable to be included in the next jessie point release. (No debdiff is attached as it's empty!) Disclaimer: as well as being the package maintainer I'm also the upstream author of WordGrinder (and it's my considered opinion that WordGrinder 0.5.1 needs to be taken out of circulation as quickly as possible before it starts hurting people). -- System Information: Debian Release: 8.8 APT prefers oldstable APT policy: (500, 'oldstable') Architecture: armhf (armv7l) Kernel: Linux 3.18.0-trunk-rpi2 (SMP w/4 CPU cores; PREEMPT) 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)
Bug#801909: wordgrinder-ncurses: wordgrinder should depend on lua-ldoc
On 16/10/15 01:12, Jean Charles Delépine wrote: [...] > Installing lua-ldoc makes wordgrinder happy. lua-filesystem, actually, but yes, there's an embarrassingly missing dependency there. Thanks; will fix. -- ┌─── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ─ http://www.cowlark.com ─ │ "There is nothing in the world so dangerous --- and I mean *nothing* │ --- as a children's story that happens to be true." --- Master Li Kao, │ _The Bridge of Birds_ signature.asc Description: OpenPGP digital signature
Bug#801697: wordgrinder: FTBFS: tries to install into home
On 13/10/15 20:12, Aaron M. Ucko wrote: [...] > Good question. You could probably achieve the desired effect by running > > cowbuilder --login --save-after-login I had a play and couldn't make it do anything useful --- I've asked on debian-mentors@ and will try to figure it out. Ta. [...] > No problem. Thanks for the quick analysis! This was so stupid it barely counts as analysis. I'm just embarrassed it that it made it past me, my mentor, and ftpmasters... 0.6-2 should be along real soon now. -- ┌─── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ─ http://www.cowlark.com ─ │ "There is nothing in the world so dangerous --- and I mean *nothing* │ --- as a children's story that happens to be true." --- Master Li Kao, │ _The Bridge of Birds_ signature.asc Description: OpenPGP digital signature
Bug#801697: wordgrinder: FTBFS: tries to install into home
On 13/10/15 16:39, Aaron M. Ucko wrote: [...] > Automatic builds of wordgrinder failed due to trying to install > something into the builder's home directory, which is deliberately > absent on the autobuilders because builds should leave it alone. Bah. I'm both upstream and maintainer, so... (I built this on cowbuilder and it was fine, so the autobuilders are obviously set up differently. Is there an option to replicate this behaviour on cowbuilder?) This is, in fact, a debian/rules bug where dh_auto_install hasn't been overridden, so it's running the upstream 'make install' twice. The fix is trivial. Sorry about that. However, what do I do with it? Do I need to add a changelog entry and bounce this through my mentor to get it reuploaded, or are there any shortcuts? -- ┌─── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ─ http://www.cowlark.com ─ │ "There is nothing in the world so dangerous --- and I mean *nothing* │ --- as a children's story that happens to be true." --- Master Li Kao, │ _The Bridge of Birds_ signature.asc Description: OpenPGP digital signature
Bug#801697: wordgrinder: FTBFS: tries to install into home
For reference, the $HOME-not-being-read-only-issue in pbuilder is known about: https://bugs.debian.org/441052 -- ┌─── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ─ http://www.cowlark.com ─ │ "There is nothing in the world so dangerous --- and I mean *nothing* │ --- as a children's story that happens to be true." --- Master Li Kao, │ _The Bridge of Birds_ signature.asc Description: OpenPGP digital signature
Bug#785483: python2.7: distutils uses the wrong compiler version
Package: python2.7
Version: 2.7.9-1
Severity: normal
I am unable to build programs using Python's distutils, because it's
invoking the wrong compiler. It's trying to use a gcc 4.9 flag, but is
invoking gcc 4.7, which aborts due to an unrecognised flag.
I think what's happened here is that it's picked up the non-versioned
gcc symlink from the system where Python was compiled. That system only
had gcc 4.9 installed, so the symlink pointed at the right compiler. My
system has the symlink provided by the stock gcc package, which points
at gcc 4.7.
The simplest fix is probably to change Python to use a versioned
compiler executable.
$ python
Python 2.7.9 (default, Mar 1 2015, 12:57:24)
[GCC 4.9.2] on linux2
Type help, copyright, credits or license for more information.
from distutils import sysconfig
sysconfig.get_config_var('CC')
'x86_64-linux-gnu-gcc -pthread'
sysconfig.get_config_var('CFLAGS')
'-fno-strict-aliasing -DNDEBUG -g -fwrapv -O2 -Wall -Wstrict-prototypes
-D_FORTIFY_SOURCE=2 -g -fstack-protector-strong -Wformat
-Werror=format-security '
$ x86_64-linux-gnu-gcc -fstack-protector-strong
x86_64-linux-gnu-gcc: error: unrecognized command line option
‘-fstack-protector-strong’
x86_64-linux-gnu-gcc: fatal error: no input files
compilation terminated.
$ x86_64-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=x86_64-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.7/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.7.4-3'
--with-bugurl=file:///usr/share/doc/gcc-4.7/README.Bugs
--enable-languages=c,c++,go,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.7 --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/include/c++/4.7 --libdir=/usr/lib
--enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-gnu-unique-object --disable-libmudflap
--enable-plugin --with-system-zlib --enable-objc-gc --enable-multiarch
--with-arch-32=i586 --with-abi=m64 --with-multilib-list=m32,m64,mx32
--with-tune=generic --enable-checking=release --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 4.7.4 (Debian 4.7.4-3)
$ ls -l /usr/bin/x86_64-linux-gnu-gcc
lrwxrwxrwx 1 root root 7 Sep 27 2012 /usr/bin/x86_64-linux-gnu-gcc -
gcc-4.7
-- System Information:
Debian Release: 7.8
APT prefers stable
APT policy: (990, 'stable'), (500, 'sid'), (500, 'unstable'), (500,
'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.2.0-4-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: sysvinit (via /sbin/init)
Versions of packages python2.7 depends on:
ii libpython2.7-stdlib 2.7.9-2
ii mime-support 3.52-1+deb7u1
ii python2.7-minimal2.7.9-2
python2.7 recommends no packages.
Versions of packages python2.7 suggests:
ii binutils 2.25-6
pn python2.7-doc none
-- no debconf information
--
┌─── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ─ http://www.cowlark.com ─
│ There is nothing in the world so dangerous --- and I mean *nothing*
│ --- as a children's story that happens to be true. --- Master Li Kao,
│ _The Bridge of Birds_
signature.asc
Description: OpenPGP digital signature
Bug#732696: os-prober: Fails to detect new package-management Haiku builds
On 7/15/14, 12:09 PM, Jeroen Oortwijn wrote: [...] Current nightly builds have different package names, so the patch doesn't work anymore. Oh, well... [...] Because David's patch doesn't work anymore, I have created a new patch. See attached file. This patch can also be found at my bazaar branch [3]. The resulting packages can be found in my PPA [4]. I don't have a Haiku setup any more, so I can't comment on the details, but after a quick glance the patch looks reasonable, and it's good that this is getting some love. -- ┌─── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ─ http://www.cowlark.com ─ │ Feminism encourages women to leave their husbands, kill their │ children, practice withcraft, destroy capitalism and become lesbians. │ --- Rev. Pat Robertson signature.asc Description: OpenPGP digital signature
Bug#732696: os-prober: Fails to detect new package-management Haiku builds
On 3/11/14, 1:22 AM, Cyril Brulebois wrote: Hi David, Sorry for the delay --- very busy with other things. David Given d...@cowlark.com (2013-12-20): [...] Currently package management builds are only available in nightly releases but there should be an official release Real Soon Now, and package management should become the norm. It'd be nice to get this fixed before this happens. I'm not familiar with haiku, is that out yet? Still in alpha, and it looks like there'll be at least one alpha before the beta comes along. It's actually pretty solid mostly, although with a few rough edges. I enclose a patch which should fix this (to be applied to /usr/lib/os- probes/mounted/83haiku). Did that get tested against said release if it's published? Against a nightly build (currently the only place where you can get the Package Management kernels). [...] -if head -c 512 $partition | grep -qs system.haiku_loader; then +if head -c 512 $partition | grep -qs 'system.*haiku_loader'; then [...] -if system=$(item_in_dir system $mpoint) +system=$(item_in_dir system $mpoint) +packages=$(item_in_dir packages $mpoint/$system) +found= +if [ $system != ] [...] Do we need to hardcode checking both version? Looking at item_in_dir's implementation, the pattern is passed to grep, so we could use 'kernel_.*' instead? It's been a while, so I've forgotten the details, but I have a vague memory of trying that and it not working. It was very likely something else I was doing wrong, but I'm not terribly keen on using grep on binaries because I don't know where the edge cases are, and it all felt sufficiently brittle that once it *did* work I didn't want to play with it. TBH if this were mine I'd be inclined to remove most of this logic. The prober doesn't do anything with the files other than to look to see if they're there. Simply checking the boot loader for 'haiku' would be a lot simpler and more robust. Unfortunately, I don't have access to the machine I've got which has Haiku on it right now, so I'm afraid I won't be able to do any work on this for a bit. I did post the patch to one of the Haiku mailing lists and they didn't spot anything wrong with it, and it *did* work when I sent it... -- ┌─── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ─ http://www.cowlark.com ─ │ │ You cannot truly appreciate _Atlas Shrugged_ until you have read it │ in the original Klingon. --- Sea Wasp on r.a.sf.w signature.asc Description: OpenPGP digital signature
Bug#732696: os-prober: Fails to detect new package-management Haiku builds
Package: os-prober Version: 1.63 Severity: important Tags: patch Haiku's new package management builds have changed the way the kernel and boot sector is laid out, and os-prober's detection routines no longer detect such Haiku partitions. Currently package management builds are only available in nightly releases but there should be an official release Real Soon Now, and package management should become the norm. It'd be nice to get this fixed before this happens. I enclose a patch which should fix this (to be applied to /usr/lib/os- probes/mounted/83haiku). -- System Information: Debian Release: 7.2 APT prefers stable APT policy: (990, 'stable'), (500, 'sid'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.2.0-4-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 Versions of packages os-prober depends on: ii libc6 2.17-97 os-prober recommends no packages. os-prober suggests no packages. -- no debconf information --- /usr/lib/os-probes/mounted/83haiku 2012-08-22 19:21:32.0 +0100 +++ /tmp/83haiku 2013-12-20 12:17:29.143209425 + @@ -13,18 +13,34 @@ *) debug $partition is not a BeFS partition: exiting; exit 1 ;; esac -if head -c 512 $partition | grep -qs system.haiku_loader; then +if head -c 512 $partition | grep -qs 'system.*haiku_loader'; then debug Stage 1 bootloader found else debug Stage 1 bootloader not found: exiting exit 1 fi -if system=$(item_in_dir system $mpoint) +system=$(item_in_dir system $mpoint) +packages=$(item_in_dir packages $mpoint/$system) +found= +if [ $system != ] item_in_dir -q haiku_loader $mpoint/$system (item_in_dir -q kernel_x86 $mpoint/$system || item_in_dir -q kernel_x86_64 $mpoint/$system) then + found=1 +fi + +if [ $found = ] [ $packages != ] + item_in_dir -q haiku_loader\-.* $mpoint/$system/$packages + (item_in_dir -q haiku_x86\-.* $mpoint/$system/$packages || + item_in_dir -q haiku_x86_64\-.* $mpoint/$system/$packages) +then + found=1 +fi + +if [ $found != ] +then debug Stage 2 bootloader and kernel found label=$(count_next_label Haiku) result $partition:Haiku:$label:chain signature.asc Description: OpenPGP digital signature
Bug#725555: ufiformat: FTBFS: configure.in:11: error: required file './compile' not found
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 15/10/13 11:53, Hideki Yamane wrote: [...] Attached patch would fix this FTBFS, could you consider to apply it, please? Thank you very much --- that works fine, although I've removed the -f option to avoid changing the autoconf files that already exist and inflating the diff size. I noticed there was also a new upstream release, and a few other things that needed fixing, so I've bumped it to 0.9.9-1. I've had to replace your entry in the changelog because I can't sign entries with your name. I hope that's all right. (I don't think you've uploaded it.) https://mentors.debian.net/package/ufiformat If you think that's all okay, I'll push it. - -- ┌─── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ─ http://www.cowlark.com ─ │ I must have spent at least ten minutes out of my life talking to │ this joker like he was a sane person. I want a refund. --- Louann │ Miller, on rasfw -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iD8DBQFSXUiYf9E0noFvlzgRAkX0AJoCe/EmNPQxltR+HhTlLCIP5jAHYQCfYTvt Mmh6KvTu5birXfkaYNxjkS4= =MXyl -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#690455: Please build android-tools-adb on more architectures
I have just successfully built adb on armhf by manually editing the control file. I can't test to see whether it works because this is on an Android chroot, so not all the device nodes exist and it won't run, but there weren't any problems with the build. Was there any specific reason for restricting it to amd64 and i386, or was that just inherited from the ADK? -- ┌─── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ─ http://www.cowlark.com ─ │ There is nothing in the world so dangerous --- and I mean *nothing* │ --- as a children's story that happens to be true. --- Master Li Kao, │ _The Bridge of Birds_ signature.asc Description: OpenPGP digital signature
Bug#691214: lua-wsapi: wsapi.cgi won't run because it has DOS file endings
Package: lua-wsapi Version: 1.5-2 Severity: grave Justification: renders package unusable Dear Maintainer, The /usr/bin/wsapi.cgi script is unrunnable as it has DOS line endings. When it is run the Lua interpreter cannot be found, as it tries to look for a file called lua5.1\r, which of course doesn't exist. If the file is converted to Unix format (I used vim) it works fine. -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.2.0-3-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages lua-wsapi depends on: ii lua-coxpcall 1.13.0-6 ii lua-filesystem 1.5.0+16+g84f1af5-1 ii lua-rings 1.2.3-1 ii lua5.1 5.1.5-4 ii multiarch-support 2.13-35 lua-wsapi recommends no packages. Versions of packages lua-wsapi suggests: ii lua-cgi 5.1.4+dfsg-2 -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#688895: npm prefix changes depending on the user
Package: npm Version: 1.1.4~dfsg-2 Severity: normal Short summary: $ npm -g get prefix /usr $ sudo npm -g get prefix /usr/local I've tried to investigate what's going on, but have gotten lost in the maze of npm configuration files. I suspect that the tweak that Debian's done to split the prefix where npm is installed from the prefix where npm installs packages isn't quite working right. This is making impossible for a script I'm trying to write to determine where the global modules are installed. -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.2.0-3-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/bash Versions of packages npm depends on: ii node-abbrev 1.0.3-1 ii node-fstream 0.1.13-1 ii node-graceful-fs 1.1.8-1 ii node-ini 1.0.2-1 ii node-minimatch0.2.0-1 ii node-mkdirp 0.3.1-2 ii node-node-uuid1.3.3-1 ii node-nopt 1.0.10-2 ii node-request 2.9.153-1 ii node-rimraf 2.0.1-1 ii node-semver 1.0.13-2 ii node-tar 0.1.13-1 ii node-which1.0.5-1 ii nodejs0.6.19~dfsg1-5 ii nodejs-dev0.6.19~dfsg1-5 npm recommends no packages. Versions of packages npm suggests: ii build-essential 11.5 -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#611409: ITP: spey -- SMTP proxy with greylisting, RBL, authentication support
Package: wnpp Severity: wishlist I am intending to package the next version of the spey SMTP proxy for Debian. It is available at: http://spey.sourceforge.net It is licensed under the GPL v2. (Disclaimer: I am upstream.) -- ┌─── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ─ http://www.cowlark.com ─ │ │ I have a mind like a steel trap. It's rusty and full of dead mice. │ --- Anonymous, on rasfc signature.asc Description: OpenPGP digital signature
Bug#464002: Do not start
Juhapekka Tolvanen wrote: [...] % wordgrinder Lua error: /usr/share/wordgrinder/main.lua:16: module 'lfs' not found: Yes, indeed --- incompetence on my part, I'm afraid, I put the appropriate dependencies in Build-Depends instead of Depends. Workaround: install liblua5.1-filesystem0 and it should start. I shall get to work on this (and try to find a way of testing this in the future). -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#464007: wordgrinder: can't bind keys that have a default keybinding
Package: wordgrinder Version: 0.2-1 Severity: normal You can unbind the default keybinding, but then trying to assign a new keybinding doesn't work. (Known upstream.) -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.22-3-486 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 wordgrinder depends on: ii libc6 2.7-6 GNU C Library: Shared libraries ii liblua5.1-0 5.1.2-4Simple, extensible, embeddable pro ii libncursesw5 5.6+20080105-1 Shared libraries for terminal hand wordgrinder recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#461515: RFP: wordgrinder -- a text mode word processor
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Package: wnpp Severity: wishlist WordGrinder is a simple word processor designed to run in a terminal (written by myself). It very lightweight, supports basic style only and is designed for text entry rather than typesetting. It is available here: http://wordgrinder.sourceforge.net It is available under the New BSD license. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHkZWtf9E0noFvlzgRAiqAAJwLnCsSNlww6M9pPPaeYdYOqXA33ACeIZzU jDsFF4ttvpJ7kjuFwjiV+7E= =MPAX -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#369453: makecontext/setcontext/getcontext not implemented on ARM architecture
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Robert Millan wrote: [...] I'm interested in these functions too. I might be able to implement them; please could you provide a minimal architecture-independent test case? Even if I can't do it, having this might be helpful to someone else. Sorry, I don't use them any more. I eventually got fed up with poor support for those functions in most software and when I discovered that pretty much *all* code that ever called a Linux 2.4 pthreads function would crash if you tried to use it from a user context, I gave up. I eventually rewrote my coroutines implementation to emulate them using pthreads and a single giant lock. Now, there's pointless for you... - -- ┌─── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ─ http://www.cowlark.com ─ │ │ Uglúk u bagronk sha pushdug Internet-glob bbhosh skai. │ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHYp7of9E0noFvlzgRAnScAJ9NCVtW7uW0zPdfao8xMHah/j73MACdFaHa z8M3mwj8ZaU8r9TEyS+VlB0= =fz/h -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#436134: RFP: ufiformat -- USB floppy disk formatter
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Package: wnpp Severity: wishlist ufiformat is a simple command-line utility for formatting floppy disks when using external USB floppy drives. (superformat and fdformat cannot do this.) It is available here: http://www.geocities.jp/tedi_world/format_usbfdd_e.html It is GPL licensed and appears to be stable. I have been using a locally-built version without any problems. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGtfpXf9E0noFvlzgRAp2EAKCuxy2n+03crip5aOEx10lGKInImgCeOkH1 8xIYxNx/Dq068aQ2uYQ/36s= =7OYn -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#370060: Segmentation fault if linked with the pthread library
Package: libpcl1 Version: 1.6-1 I have a situation on the ARM platform where if I compile an executable to use both libpcl and libpthread, then even if I'm not actually using threads, trying to do anything to a coroutine causes an immediate segmentation fault. To replicate: $ gcc /usr/share/doc/libpc1-dev/examples/cobench.c -lpcl -- produces working executable. $ ldd ./a.out libpcl.so.1 = /usr/lib/libpcl.so.1 (0x4001e000) libc.so.6 = /lib/libc.so.6 (0x40029000) /lib/ld-linux.so.2 (0x4000) gcc /usr/share/doc/libpc1-dev/examples/cobench.c -lpcl -lpthread -- produces failing executable. $ ldd ./a.out libpcl.so.1 = /usr/lib/libpcl.so.1 (0x4001e000) libpthread.so.0 = /lib/libpthread.so.0 (0x40029000) libc.so.6 = /lib/libc.so.6 (0x40083000) /lib/ld-linux.so.2 (0x4000) The reason why this is an issue is that I have an application which uses coroutines, but not pthreads, which wants to link to the sqlite library. When sqlite was built, it was done so with its threading support enabled; which means that it tries to call mutex primitives in the pthreads library. This means that linking an application against libsqlite will implicitly pull in libpthread, which then causes it to fail. This actually sounds suspiciously similar to a problem I previously encountered on the i386, Debian bug 339827. To summarise: on i386 when running a sufficiently old kernel that does not have thread-local storage, the threading library figures out which thread is running by the location of the stack pointer. If the application has allocated a user stack, it fails to cope and crashes. This means that calling any thread-safe function which needs to know what the calling thread is will fail when it is called from any user stack. The only workaround I've got for this is to recompile sqlite without threading support, which is painful. Architecture: Linux pyanfar 2.6.15-1-nslu2 #2 Tue Mar 7 17:36:32 UTC 2006 armv5tel GNU/Linux Debian version: Etch (current) signature.asc Description: OpenPGP digital signature
Bug#369453: makecontext/setcontext/getcontext not implemented on ARM architecture
Package: libc6 Version: 2.3.6-7 Attempting to use any of the ucontext family of functions --- makecontext, setcontext, getcontext, swapcontext --- produces the following link-time error: makecontext is not implemented and will always fail It's right; it does. I realise they're a bit exotic, but they *are* specified in the standard, and more to the point my program requires them (for a coroutines implementation). Said program was developed on i386 and works fine there. I currently don't have any workarounds. Is this worth doing anything about in Debian, or should it be referred upstream? signature.asc Description: OpenPGP digital signature
Bug#339827: linuxthreads crashes when using user stacks
On Saturday 19 November 2005 05:10, Daniel Jacobowitz wrote: [...] We could ship a fourth variant of fifth variant of glibc for i686 using LinuxThreads. I am not particularly motivated to do this considering how rarely anyone encounters this problem, and the corresponding cost in archive space, build time, and maintenance. I understand your reasoning, but unfortunately it still leaves me in the lurch. I'm the author of the application in question, and I was hoping to do a Debian package for it. The current situation is that it simply won't work on Debian systems with a 2.4 kernel. The only possible workaround is to have the package compile its own version of the library, without pthreads support, which is a maintenance nightmare. (There are lots of references to TLS in the linuxthreads code, all in files in the sysdeps/i386 directory. I assume that this is only used on i686 and above, and that i386 systems genuinely *don't* support TLS, and this isn't just an oversight?) Since this *is* a bug in linuxthreads, no matter how obscure, I'm hoping that it's less effort all around to simply fix it... but the alternatives all seem to involve keeping a shared data structure between threads containing all the necessary information. I suspect that maintaining this structure is going to be considerably more work than it first appears. pgp57Qz1re0gk.pgp Description: PGP signature
Bug#339827: linuxthreads crashes when using user stacks
Package: glibc Version: 2.3.5-8 Severity: important When using 2.4 kernels, the linuxthreads library makes an incorrect assumption about stack usage that causes applications to crash if they use user stacks. This does not occur on 2.6 kernels (because they use a different threading library). I haven't tested this on 2.2 or below. The reason: because 2.4 kernels don't support thread local storage, linuxthreads puts a pointer to its current thread state just beyond the end of the stack block. By looking at the stack pointer, it can work out whether it's in the initial thread, the manager thread, or one of its slave threads. Unfortunately, using a user stack causes the logic to go wrong, resulting in it following a bogus pointer and dying. (See linuxthreads/descr.h, about line 250.) The case where I am running across this bug is as follows: I have an application that uses coroutines, implemented with setcontext/getcontext. Each coroutine gets its on stack. The application itself does not use pthreads. However, the application is linked with libsqlite3, which on Debian has been compiled with pthread support; this causes the linker to use the thread-aware version of malloc(), which on 2.4 kernels causes the application to die the first time it does a memory allocation from a coroutine. It works fine on 2.6 kernels and on non-Linux pthread implementations. (I suspect this would fail if a pthread-aware function was called from a signal handler set up to use an alternate stack with sigaltstack() as well; but this is less important as the available functionality in signal handlers is so limited.) linuxthreads *does* have a workaround that appears to solve a related problem, but it is enabled by setting an internal switch (the __pthread_nonstandard_stacks variable), which is not publicly accessible, and it still relies on letting pthreads initialise the stack frame. (This is used when a thread is created with an explicit stack specified.) This would not help in this situation. This bug is causing the application to be unusable on Debian systems with a 2.4 kernel. The current workaround I'm suggesting is to compile a private copy of the Sqlite library without pthreads enabled, and statically linking against that; this is not really satisfactory. Unfortunately, I can't suggest a fix --- this appears to be a fundamental design problem with linuxthreads. This appears on current Debian unstable systems. The application in question is Spey, available from http://spey.sf.net; this can be reliably reproduced on 2.4 kernel systems. Is there any more information that would be useful? pgpRxiyMZvH30.pgp Description: PGP signature
